UGETAB's Save-State Hacking Methods (Version 1.02)

Pre-requisites:
Interest in making Pro Action Replay(PAR) codes and/or Game-Genie(ROM hack) codes
My File2File program, or a program of equivalent function.
A binary file editor with the ability to compare files.
The ability to handle sustained reading.

This document is an accumulation of the lower-level knowledge I have about how to use Save-State hacking effectively. I can't describe my higher-level knowledge, as it's made up of 65% persistence, and 25% intuition. The rest is the unquantifiable variable of luck, and potentially, the detrimental effects of sleep deprivation. I've been using this method, and hacking ROM for long enough that I can find stuff when I'm half-asleep, simply because I'm less likely to throw out an idea because it seems to contradict my knowledge of the game's programming.



I use an antique of a program called Universal Game Editor(UGE) to edit file. On the list of programs you'd want to use to edit files, this is probably just above the first program you have to pay for before you can use. For this reason, I've chosen another program that has similar capabilities to substitute for UGE. It's freeware, and works fine.

http://www.willem.org/ZIP/utility/hexfre20.zip

The hexfre20.zip download provided from the program's home page was corrupted, but here's the page anyways:
http://www.hexedit.com/download.htm


If the program doesn't work, you'll also have to download vc6redistsetup_enu.exe and install it. The file can be downloaded from this page:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q259403



The program I made has a mild explaination of Save-State hacking in it's documentation, and can recalculate the formulas needed to turn a Save-State address into a PAR code, just by checking the preferred settings the user has.

You can see the program's 'Help>Conversion Formulas' area for the things I've already deduced about ZSNES(the SNES Emulator) and Fusion(the Genesis emulator). The ZSNES PAR addresses calculated can often be used in 'Geiger's Snes9x Debugger' (Mark 9 Release 8, as of this writing). See http://www.zophar.net/snes.html to be able to download at least this version.

My preferred programs for hacking different systems is as follows:
SNES: ZSNES for as much as possible, SNES9X Debug version for debugger use only
NES: FCEUXDSP (FCEU-XD offshoot-SP offshoot of XD. Has the best NES debugger at this time)
Gameboy: BGB (Has a good debugger, memory and code breakpoints, and superb cheat system)
Genesis: Kega Fusion (Has decent PAR support, and no compressed save states)
Arcade: MAME32 for playing, and play-testing codes. Debug Build of MAME for the debugger I learned disassembly on. See http://cheat.retrogames.com for a place to request and/or post codes. Install the existing cheat.dat file from that site into the same folder as your MAME program, and check it with a text editor before you make or post codes, because a lot of the obvious codes have been made for many games.

Once you've chosen an emulator and a game, you need to make a save-state while playing. One of them should be before you activate the thing you want to make a code for, and one should be after you've activated the feature you wanted. This could include letting yourself die to prevent your death with a code, decreasing your life-bar to find an infinite life code, or using up an item to find infinite items. In most cases, reducing what you have will give you the same address that increasing what you have would. It also almost always lets you change less of the game than an increase to the same value would.

It's very important that you try to change as little as possible when activating the effect you want. If you change too much, you could crash the game when you load the modified save-state. I've even had it where moving the equivalent of a half seconds push of a direction button was the difference between the save-state crashing the game, and the save-state giving me exactly what I was looking for.

If you've got a save-state with the effect you want enabled, and another save-state with the effect you want disabled, then you may continue, no matter how far apart the saves are in terms of completion. It may be a risky investment of time, but if you're determined, a save-state of any type can be exactly what you need to find a value you're after.

One of the primary tactics used every time you copy data from 1 save-state to another is the 'Binary Search'. A Binary Search is where you take half of everything you have(in this case, file data), and test it to see if it contains what you want. If it does, then you restrict your perameters(lower the range on the amount of data copied), and reset your variables(restore the file, so that it no longer has the effect you're looking for). You reduce the range as you exclude ranges of data that don't effect the feature you want, and include only ranges that do effect the feature you want.

I'll describe the steps I take for an actual address I intend to find just for the sake of this document. Please read at least all the numbered steps before you try following the example. Comprehending them would also help you.

SNES Kirby 3 'Invincibility' address(you should note that I don't have this address yet)

1. I loaded the game in ZSNES, went through level 1 of the game, and got lucky by there being an invincibility item there. Kirby 3 has 3 types of invincibility possible. First, is the invincibility item, which gives the most benefits. Second, is that you're invincible for a short time when you get hit. Third, would involve removing the 'collision detection' routine, so that you walked right through enemies. I chose the item, because it should be easy to make into a stand-alone code.

2. I saved 3 save-states. The first 2 are for testing. The last is to make sure I have a save-state to fall back on, should I make any errors that would have me restore from before I initiated the effect I wanted. One state holds the character before being invincible, another state holds the character while being invincible.

3. I use a file editing program called UGE(Universal Game Editor) that starts at address 0, and uses decimal addresses, so I'm going to display information in such a format in this document. You can use another program if you want, and since most other programs use hex values and addresses, it will help you integrate your testing with your file editing program.

4. I tested some of the effects of invincibility by just playing the game for a little longer while I had the normal invincibility, so I can identify the value through action rather than through visual cues that appear with invincibility. This test reveals that I can touch a block, and it will break without anything else done on my part. This will be my test for whether or not invincibility is active.

5. I'm using ZSNES, and I'm using slot 1 and 2 in the program for testing, so I choose files KIRBY3.ZST for 'Copy From' and KIRBY3.ZS1 'Copy To'. I realize now, that I have invincibility enabled in slot 2, so I switch the files for 'Copy From' and 'Copy To', because I want it to go from deactivated to activated.

6. I press the 'Backup File 2' button, now that I'm sure of what will happen to the save in Slot 1.

My 'Options' in File2File are:
'Use Hex Addresses' = Not Checked
'First Address in File is 0' = Checked

7. I set the Start Address to 3091, because that's an address I calculated to be the first address in a ZSNES Save-State. I did this more than 2 years ago, so I don't recall my precise method for finding this specific value. Either way, it's the amount subtracted from the address in the 'Help>Conversion Formulas' box for '7E0000 to 7FFFFF' under ZSNES.(I tend to try increasing the start address a bit first if the program or game crashes, and I'm not dealing with a ZSNES or Kega Fusion file)

8. I set the end address to 200000. That's close enough to half for my purposes. I press the 'Copy Data' button, wait till the status message above the 'Copy Data' button says 'Done' and load the state.

9. I'm appearing on top of where the item is normally, so I'm going to try the next range now. I've done other kirby games, and I also know Kirby 3 uses an SA1 chip. My studies of it indicate that it uses more memory than a normal game. I restore the file I copied to.

10. I set the start address to 200000 and the end address to 300000 and copy data. It fails. I set the end address to 400000 and try again. That also fails. I've now eliminated 200000 bytes of data from being possible Invincibility activators, and I've done so in a matter of 30 seconds. I restore the file.

11. Start=100000, End=200000. It moves me where the item would be again. I get an inspiration. I restore the backup. I load the restored save-state, and move my character to a different location, and save the state again. I backup the modified file.

12. I copy the unchanged range of data again. The effect is enabled, and the item that enables the effect is gone, and it's not because I happened to overlap with the item. I restore, set the End Address to 150000, and copy again.

13. I screwed up the effect again. I put invincibility in slot 1, and also switched the files. I recalled that using 100000-200000 didn't remove the effect, so I exclude only those addresses, I restore the file, then I ONLY switch the 2 files selected in my File2File program. I backup the new file.(I'll get this right eventually. These mistakes are from switching back and forth between writing this document and doing what I normally would do until I find the address I'm looking for. I'm so used to doing this that thinking about it is making me error prone.)

14. Start=3091, End=100000. I'm now going to be loading from Slot 2 now, where the effect is disabled. I copy the data. It fails. I now go back to 200000 to 300000. The effect has been enabled. I set End=250000, Restore, Copy, Test. It failed. I set Start=End, and End=270000. The game is frozen on the screen, the effect is disabled. I set End=280000. Effect is still off. End=290000. Effect is still off. I set Start=End, End=300000. Restore, Copy, Test. Invincibility Effect is enabled, and has no visual effect on the character, and has no audible effect on the music, until the power runs out, when the music resets.

15. Start=290000,End=295000. Restore, Copy, Test. Effect Still On. Restore. End=291000 = no. End=292000 = yes. Start=291000, End=291500. Restore, Copy. Effect Enabled. Start=291000, End=291100. Effect Not Enabled. End=291200 = no. End=291300 = no. End=291400 = yes.

16. I now have this narrowed down sufficiently that I could potentially find the value with my file editor...but I'm going to go for 10 bytes. Start=291300,End=291350. Had to get up and do something else for about 30 seconds. Restore, Copy, Test. Effect Enabled. Start=291300,End=291310. RCT, enabled. The data is within the range of 291300 and 291310. Now that I know the range, I'll use HexEdit 2.0 to locate the precise bytes changed. 

17. I enable 'View>Display>Decimal Addresses', so the addresses will be in decimal format. I restore the file, so I have a difference to compare between files. I open KIRBY.ZST and KIRBY.ZS1. I put 291300 in the second drop-down box in the 'Edit Bar'(View>Toolbars>Edit Bar), then press Enter, and repeat the entire process to bring the address of the other window in line with the first, and make the display format match.

18. In the KIRBY.ZS1 window, I use the compare feature by pressing ALT+C. The first match is at 291301. Trying to change the address makes the program ask if I want to disable 'Read Only' mode. I choose yes, then type the value that's in KIRBY.ZST into the same position in KIRBY.ZS1. The change fails. The next compare brings me to 291302. Copying the value for this address enables invincibility. I know it does, because when I try to touch a block, the block breaks. Sequentially changing the bytes works best in situations like this. Invincibility has been enabled by the address is 291302. Changing the value to 1 also allows it to work, so I believe it's a count-down timer, and I'm going to err on the side of letting it run out within a reasonable amount of time, so I'm going to use 1 with the code I make.

18. 291302 is 'greater than or equal to 269620 and less than or equal to 302387' according to the 'Conversion Formulas', so it's going to use the calculation:
((Address) - 269620)+4194304=
Convert the result to Hex.

so...
((291302) - 269620)+4194304=4215986

I copied and pasted that into the windows calculator, when it's in 'Scientific' mode.

I clicked the hex option, so that value is 4054B2. I used the value 1 in the save-state, so...
4054B201 is the code. 4054B2, with 01 at the end for the value.

I put the code into ZSNES, which has been on the entire time to let me test if the Invincibility effect was enabled. I complete the level I'm on with invincibility enabled from the code. There's no errors, so I'm going to post this code to http://thegshi.org, the place that this FAQ, and the File2File program, and any updates to them, will go to first.

If you only get a file address for your effort, and use it for testing how the game stores the information, you can either get the current numeric value of an unknown item, like an energy bar, and use other memory editing codes as a basis for you to find the same value in the file as you can find codes for. It won't always be so simple, but it has the potential to be so easy on you. Precise values, like an energy bar's value, are good for using in the program's internal cheat code searchers. For things like timers, it's best to either use a calculation, or find an existing code, then locate that code's effect within the save-state, and add/subtract the distance between the 2 codes in the save state from the known-code's address.

I built my File2File program to generate, rather than recite, the Conversion Formulas. Your preferences for viewing addresses should be visible in the help menu items you view.

1.02: Modified the instructions to use a more modern program than UGE, but that still supports decimal file addresses.
1.01: Repaired some wording, added info suggested by iamstillhiro1112
1.00: Initial Version