Tweet
If you're into debugging, I can give you a few items of interest I found.
I keep the results of my conversion-in-progress Pro Action Replay codes here:
http://66.180.172.235/~gshi/phpbb2/viewtopic.php?t=443
PAR codes should be allowed here, because with the help of SNES9X Debug, you can use the addresses to help determine the location of the code that writes the values. You really only have to be cautious of games that use the SA1, as those are the ones that'll give you a ton of trouble to make Game Genie codes for. Breakpoints don't work in SNES9X Debug if the code modifying the address happens to be in the SA1 processor.
I've made several codes that I've only tested in an emulator, which are outside the normal range that every emulator I've seen searches(which would be 7E0000 to 7FFFFF). Many of the codes seem to be originals for accessing those memory areas. I don't recall ever seeing a 40???? or 303??? code before. It's even hard to find In-Game SRAM modifiers of the type 306??? (see Rockman & Forte (Megaman 9) 'Have All CDs' code on Page 2 of my 3 page post)
I use ZSnes Save States to search memory areas, then use calculations to convert the file addresses into memory modifying codes(the first 6 Hex numbers of PAR codes), onto which I append a 2 digit hex code, which never seems to fail when using SNES9X or ZSNES to test the codes.
I got my information on memory segments to check from here:
http://www.zophar.net/tech/snes.html
Name: SNESMem (Should be file SNESMem2.zip)
All of these addresses assume 0 to be the first address in the file, and that the file is a Save-State from ZSNES(F3 picks slot, F2 saves, F4 loads):
For 7E0000 to 7FFFFF codes:
The file address must be greater than or equal to 3091(0xC13) and must be less than or equal to 134162(0x20C12).
Subtract 3091(0xC13) from file address, and convert the address to Hex, if it's not already in Hex. Add 0x7E0000 to the address, and if it comes out to be less than or equal to 7FFFFF, put the hex value you want the address to remain at contantly at the end, and if that value is 0-F, write it as 00-0F.
For 400000 to 407FFF
The file address must be greater than or equal to 269620(0x41D34) and must be less than or equal to 302387(0x49D33).
Add 3924684(0x3BE2CC) to the file address. Use the rules above for appending a value to the end of the code.
303000 to 3037FF
Still need to test this calculation some more.
This is the test calculation I've made up on the spot, and tested on 2 existing games' codes:
The file address must be greater than or equal to 267571(0x41533) and must be less than or equal to 269618(0x41D32).
Add 2890445(0x2C1ACD) to the file address. Use the rules above for appending a value to the end of the code.
For the 306??? SRAM codes, I just logged the CPU at a point it couldn't have avoided reading from the addresses used, then I wrote codes to modify the addresses I found. The debugger and the codes used the same address displayed. Note that the Memory Viewer won't let you watch the 306000 to 307FFF section of memory.
Edit:
Modified the 400000 - 407FFF section
I keep the results of my conversion-in-progress Pro Action Replay codes here:
http://66.180.172.235/~gshi/phpbb2/viewtopic.php?t=443
PAR codes should be allowed here, because with the help of SNES9X Debug, you can use the addresses to help determine the location of the code that writes the values. You really only have to be cautious of games that use the SA1, as those are the ones that'll give you a ton of trouble to make Game Genie codes for. Breakpoints don't work in SNES9X Debug if the code modifying the address happens to be in the SA1 processor.
I've made several codes that I've only tested in an emulator, which are outside the normal range that every emulator I've seen searches(which would be 7E0000 to 7FFFFF). Many of the codes seem to be originals for accessing those memory areas. I don't recall ever seeing a 40???? or 303??? code before. It's even hard to find In-Game SRAM modifiers of the type 306??? (see Rockman & Forte (Megaman 9) 'Have All CDs' code on Page 2 of my 3 page post)
I use ZSnes Save States to search memory areas, then use calculations to convert the file addresses into memory modifying codes(the first 6 Hex numbers of PAR codes), onto which I append a 2 digit hex code, which never seems to fail when using SNES9X or ZSNES to test the codes.
I got my information on memory segments to check from here:
http://www.zophar.net/tech/snes.html
Name: SNESMem (Should be file SNESMem2.zip)
All of these addresses assume 0 to be the first address in the file, and that the file is a Save-State from ZSNES(F3 picks slot, F2 saves, F4 loads):
For 7E0000 to 7FFFFF codes:
The file address must be greater than or equal to 3091(0xC13) and must be less than or equal to 134162(0x20C12).
Subtract 3091(0xC13) from file address, and convert the address to Hex, if it's not already in Hex. Add 0x7E0000 to the address, and if it comes out to be less than or equal to 7FFFFF, put the hex value you want the address to remain at contantly at the end, and if that value is 0-F, write it as 00-0F.
For 400000 to 407FFF
The file address must be greater than or equal to 269620(0x41D34) and must be less than or equal to 302387(0x49D33).
Add 3924684(0x3BE2CC) to the file address. Use the rules above for appending a value to the end of the code.
303000 to 3037FF
Still need to test this calculation some more.
This is the test calculation I've made up on the spot, and tested on 2 existing games' codes:
The file address must be greater than or equal to 267571(0x41533) and must be less than or equal to 269618(0x41D32).
Add 2890445(0x2C1ACD) to the file address. Use the rules above for appending a value to the end of the code.
For the 306??? SRAM codes, I just logged the CPU at a point it couldn't have avoided reading from the addresses used, then I wrote codes to modify the addresses I found. The debugger and the codes used the same address displayed. Note that the Memory Viewer won't let you watch the 306000 to 307FFF section of memory.
Edit:
Modified the 400000 - 407FFF section
Comment