Register | Login
Views: 19364387
Main | Memberlist | Active users | ACS | Commons | Calendar | Online users
Ranks | FAQ | Color Chart | Photo album | IRC Chat
11-02-05 12:59 PM
1 user currently in Rom Hacking: hukka | 2 guests
Acmlm's Board - I2 Archive - Rom Hacking - Finding free space in the Direct Page | |
Add to favorites | "RSS" Feed | Next newer thread | Next older thread
User Post
Lin2tagada
Newcomer
Level: 5

Posts: 6/7
EXP: 281
For next: 248

Since: 03-16-05

Since last post: 182 days
Last activity: 182 days
Posted on 05-03-05 01:34 PM Link | Quote
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 ?
MathOnNapkins

Math n' Hacks
Level: 67

Posts: 1802/2189
EXP: 2495887
For next: 96985

Since: 03-18-04
From: Base Tourian

Since last post: 1 hour
Last activity: 32 min.
Posted on 05-03-05 02:54 PM Link | Quote
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.
Euclid

Cheep-cheep
Level: 23

Posts: 166/193
EXP: 65528
For next: 2195

Since: 03-15-04
From: Australia

Since last post: 24 days
Last activity: 7 days
Posted on 05-03-05 06:24 PM Link | Quote
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.
Lin2tagada
Newcomer
Level: 5

Posts: 7/7
EXP: 281
For next: 248

Since: 03-16-05

Since last post: 182 days
Last activity: 182 days
Posted on 05-04-05 06:05 PM Link | Quote
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.
Parasyte

Bullet Bill
Level: 35

Posts: 498/514
EXP: 267348
For next: 12588

Since: 05-25-04

Since last post: 104 days
Last activity: 32 days
Posted on 05-05-05 07:23 AM Link | Quote
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.
d4s

Panser
Level: 29

Posts: 199/325
EXP: 142151
For next: 5734

Since: 03-23-04

Since last post: 13 days
Last activity: 1 day
Posted on 05-06-05 05:23 AM Link | Quote
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.



(edited by d4s on 05-05-05 12:23 PM)
(edited by d4s on 05-05-05 12:28 PM)
(edited by d4s on 05-05-05 12:35 PM)
Add to favorites | "RSS" Feed | Next newer thread | Next older thread
Acmlm's Board - I2 Archive - Rom Hacking - Finding free space in the Direct Page | |


ABII


AcmlmBoard vl.ol (11-01-05)
© 2000-2005 Acmlm, Emuz, et al



Page rendered in 0.017 seconds.