Re: A82: Dying Eyes demo for ASH 3.0 releas/SOLUTIONS


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

Re: A82: Dying Eyes demo for ASH 3.0 releas/SOLUTIONS




In a message dated 97-12-09 19:59:01 EST, you write:

> At 11:12 PM 12/8/97 -0600, you wrote:
>  >So Thomas, with this relocation thing you think will work. How could 
>  >somebody, lets say ANYBODY, who needs to use a relocation method to make 
>  >his/her game work that is over 14k use this relocation method.  Please 
>  >explain further how this will work. Like type some code with it that I 
>  >could try!!!!! Or just write some simple relocation routine that could 
>  >be cut and pasted into a program.
>  >~Ilya
>  
>  Okay, I think you know pretty much how to search for the start of the
>  program (I tend to use a 15-20 byte checksum containing the first few bytes
>  of the program, however, searching the VAT would be faster and more
>  efficient).  So, once you have found the program, pick some place in memory
>  (most likely the byte right after the relocator program...difficult, but
>  possible to do) to move the program to (make sure START_ADDR points to this
>  location or the game will be screwed up).  Now take the first, let's say 20
>  bytes, and copy it into the TEXT_MEM.  Now move everything, starting from
>  the START_ADDR of the game, down 20 bytes and move the 20 bytes in the
>  TEXT_MEM into the START_ADDR location.  Keep doing this until you have the
>  entire program copied.  To restore everything, just reverse the process
>  before returning to ASH, or OS-82 (which would do the same thing if you
>  wanted relocation in that shell also).  Also, if you wanted to move memory
>  faster, just copy more bytes at a time to/from the TEXT_MEM.  I'm too busy
>  right now to make some code for this, but you can pretty much figure out
>  how to do it.  I must warn you that you have to determine where the file
>  ends (to the byte) since seperating programs such as Game Wizard v2.0 could
>  be devastating.  BTW, I had to use a checksum in Game Wizard v2.0 because
>  ASH relocates memory without updating the VAT.
>  
>  Hope that helps a bit,

The only problem is, the amount of memory moved at a time is not the problem.
The problem is that when you move half of the memory or more, some of it gets
screwed up (at least with the method Ash uses - check out PhatOS because it
uses the same relocation [and the source is available]).  Consider the
following diagram of the calc's memory:

1
2
3
4
5
6
7
8

where each number is 4k.
assume that every Ash program is relocated to 2.  If you move 4k at 7 to 2, it
is not a problem:

1 relocated back to 1
7 relocated back to 2
3 relocated back to 3
4 relocated back to 4
5 relocated back to 5
6 relocated back to 6
2 relocated back to 7
8 relocated back to 8

but say you move 16k starting at 5:

1 relocated back to 1
5 relocated back to 8/2
6 relocated back to 3
7 relocated back to 4
8/2 relocated back to 5
3 relocated back to 6
4 relocated back to 7
5 relocated back to 8/2

we have two 5's, with 8 and 2 overlapping!!!  depending on which order it
relocates in (5 -> 2 or 2 ->5) either 8 or 2 is permanently destroyed!
Then when we relocate back, the memory is all screwed up.
The only solution I see is to use a more TI-OS based relocation of moving the
programs until the desired one is at START_ADDR.  It would probably be easier
to find the functions in the ROM.
I hope this was of help too...

~Adamman