Acmlm's Board - I2 Archive - Rom Hacking - Finding free space in the Direct Page
| User | Post |
d4s
Posts: 199/325 |
Originally posted by Lin2tagada
Hi,
For a small ASM hack, I need temporary storage for my routine, maybe only 10 bytes. I'd like to find some unused space in the DP, so I could avoid storing all the accessed RAM locations first and restoring them afterwards.
How would you proceed to find some unused space ?
With Geiger's tracer I monitored the lowest range of the RAM to see what never changes, ... but I cannot test all the events in the game to see if they access those addresses. Similarly, if I set breakpoints on read/write access on those locations, I'd have to test the game thoroughfully to make sure it's really free for my use. Any suggestions ?
in case you didnt know:
the direct page isnt restricted to the first 256 bytes in ram, you can just set it to anywhere in the first ram bank.
find some unused space in bank $7e(there always is some, look for a series of 55 55), point your dp to that space and youre all set.
dont forget to restore the dp when exiting.
typically, a game uses the first $2000 bytes for variables and the rest for processing/decompressing etc data blocks.
you dont have to play through the whole game.
just check all "modes" available.
if you were hacking a final fantasy game, for example, youd start a new game, go to a town and the overworld, fly with an airship, battle an enemy and watch the ending.(using sram saves, not savestates, of course)
now, its pretty safe to assume that everything thats still 55 55 in ram is never
used by the game.
i'd prefer large chunks of 55s at the end of a bank over small ones.
Originally posted by mathonapkins
You'd also have to modify some internal value telling the emu/snes what size sram file to create, possibly. I think it's idiot proof on an emu, but I'm not sure if the SNES pays attention to that value.
the snes doesnt care about anything in the header apart from the reset and irq vectors.
backup units use it to set up their sram size with the purpose of defeating copyprotections, though.
however, increasing sram size for 10 variables isnt worth the effort imho.
im sure theres plenty of unused ram left.
|
Parasyte
Posts: 498/514 |
The first few bytes in the direct page (or zero page) are used for passing args to/from subroutines. It's something you should look for by stepping out and check that the direct page is not used before calling the subroutine you're hacking. Then check that the direct page is not used from the beginning of the subroutine up to your patch. That is an almost certain method to find out if the data is 'currently' being used, or not. |
Lin2tagada
Posts: 7/7 |
Thanks for your suggestions ! I used the first bytes of the DP, and I didn't need to to the popping/pushing to restore them. It was indeed some temporary stuff. |
Euclid
Posts: 166/193 |
From my experience if the first 16 bytes ain't changed in the next 20 or odd instruction, chances are that it's just temporary stuff on there which you can feel free to write over.
If you're working with SNES then it doesn't have to be in the direct page, there's usually heaps of space near the 0x1Fxx places or maybe in the 7F bank.
or you can just use the stack, that's always safe for like 99% of the time. |
MathOnNapkins
Posts: 1802/2189 |
Couple options...
once yuou're in your routine, push the first ten addresses ($0-$9) onto the stack. Do whatever you wanted to do. Then pull (aka pop) them off the stack when you're done. Simple, but consumes a bit of space. You can use loops to make it less dirty. Provided you don't overflow your stack (not extremely likely with 10 bytes), this is pretty safe, even for porting to an SNES.
Or your could use sram locations. If the game doesn't normally use save files, you're fine, b/c it will just create a save file for you. If it does use save files, you can either expand the size of the sram file it creates, or try to find unused locations in the file itself. Depending on the emu, the blank areas will look like #$55, #$60, or #$00.
But if you plan to port your hack to an actual SNES, that will create some extra concerns. Like the fact that your cart will have to have a memory chip to store this stuff on. You'd also have to modify some internal value telling the emu/snes what size sram file to create, possibly. I think it's idiot proof on an emu, but I'm not sure if the SNES pays attention to that value. |
Lin2tagada
Posts: 6/7 |
Hi,
For a small ASM hack, I need temporary storage for my routine, maybe only 10 bytes. I'd like to find some unused space in the DP, so I could avoid storing all the accessed RAM locations first and restoring them afterwards.
How would you proceed to find some unused space ?
With Geiger's tracer I monitored the lowest range of the RAM to see what never changes, ... but I cannot test all the events in the game to see if they access those addresses. Similarly, if I set breakpoints on read/write access on those locations, I'd have to test the game thoroughfully to make sure it's really free for my use. Any suggestions ? |
|
hukka
