Re: A82: Game Wizard v2.0 bug discovered!!!

[Prev][Next][Index][Thread]

Re: A82: Game Wizard v2.0 bug discovered!!!


This method will mess up the memory, so it wont be possible to use
KEY_HAND. Besides that the VAT will be invalid, so you wont know where the
other programs are. Lets say the memory looks like this :

------------------ End of Ash
Y1,Y2,Y3...
L1,L2,....
----------------- Start of free mem

----------------- End of free mem
Program 1
Program 2
----------------- Start of VAT 

If program 2 had to be relocated you would move it down 500 bytes at a
time. This would mean that the memory ended up looking like this.

------------------ End of Ash
Program 2
(this mem is free)
----------------- Start of free mem

Y1,Y2,Y3... (this part of the mem seems to be free, but it is not)
L1,L2,....

----------------- End of free mem
(this mem is free)
Program 1
----------------- Start of VAT 

As you can see the memory is really messed up, and since the VAT contains
pointer to the old locations, locating a program will be very hard. This
means that it wont be possibel to use the build in VAR routines, and that
using other variable will be almost impossible. In Game wizard you would
have a big problem finding the var which holds the code. 

Another problem with the method is that a lot of bytes have to be moved.
Moving a block of 500 bytes, means moving the following number of bytes.
(Assuming that the memory there is  24000 bytes from the end of Ash to the
beginning of the VAT)

Block -> GRAPH_MEM = 500
Mem down = 24000
GRAPH_MEM -> block = 500
Total = 25000 bytes

If you need the last program stored in mem you have to move it app 24000
bytes = 48 blocks. This means you have to move 48*25000 bytes = 1200000
bytes. An LDDR takes 10.5 micros/byte @ 2 MHz, so lets assume that the
TI82 uses 3 micros. This means the relocation would take 1.2*3 s = 3.6 s!

I think that more than 3 secs to relocate a program is way too much.
Besides that there are a few other problems with your method.

1. How do you locate another variable in your program ?
2. It wont be possible to use the VAR routines.
3. It wont be possible to use the FP Stack for FP math 
4. How would you make it possible to use KEY_HAND ?


Also there is another problem which moght be hard to solve. If a new
version of the shell is released (minor bug fixes, but the old programs
should work otherwise), and it is larger then the old version. If you used
your method the last part of the shell would be moved to another place in
the mem, where it would be place bewteen to vars. If you have pieces of
code like this in wierd places in the mem, finding external veriables will
become a lot harder.

Another question, how would you locate Game Wizard, if another program was
relocate at the time ?  

As far as i can see Simpel relocation is a lot better than this (with
a minor bug fix in Ash, all programs would work (except for Game
Wizard, but if you inserted the 10 lines of code there would be no
problem)).

Dines
-----Original Message-----
From: Thomas J. Hruska <thruska@tir.com>
To: assembly-82@lists.ticalc.org <assembly-82@lists.ticalc.org>
Date: 8. februar 1998 05:15
Subject: Re: A82: Game Wizard v2.0 bug discovered!!!


>
>At 10:12 PM 2/6/98 -0800, you wrote:
>>
>>>HINT to Dines:  Use the block relocation method that I previously
have
>>>mentioned which will preserve programs such as Game Wizard and will 
allow
>>>for other programs like Dying Eyes (which also has a problem with
>>>relocation due to it's size of over 13K).
>>
>>What block relocation method?  CrASH authors would like
to
know too :)
> >Block relocation was a method of relocation that I previously described
on
>this list as a general idea of relocation that should work better than
the
>swapping bytes method that is used in ASH v3.0 (aka simpel (or is it
>simple) relocation).  The principle is the same except everything is
moved
>in chunks or blocks and preserves all the programs before and after the
>relocated program.  The basic idea is to take about 50-500 bytes of the
>program (author's choice...larger=faster, I recommend the GRAPH_MEM=768
>bytes) that is to be relocated and store it in a temporary location.
Then,
>         http://www.geocities.com/SiliconValley/Heights/8504
>                    http://shinelight.home.ml.org
>
>  Spam-Fighter code is:  14806560   (New technique to fighting spam)
>  Enter "Spam-Fighter:  XXXXXXXX" in the body of a personal message
>  to thruska@tir.com.  Otherwise the message will be filtered as spam.
>

_______________________________________

Dines Justesen
Email: dines@post1.com or
       c958362@student.dtu.dk
WWW  : http://www.gbar.dtu.dk/~c958362/
_______________________________________
Follow-Ups: