Console Specific Tips
When excavating the memory of these old consoles it helps to know what the original creators of the games were working with in the first place. If you familiarize yourself with the quirks of your favorite console then set making will be easier and more accurate.
When using the memory inspector to find variables for NES games, there will be 4 copies of everything you find. If you're wondering "which one do I use?" or "should I check for all of them?" it's not as complicated as it seems.
This is a feature of the NES that gave developers more ways of looking at memory. Because the NES itself only has 2KB of RAM, the first result (the one below 0x800) should be used for consistency, and applying additional conditions on the others will do nothing.
This applies to RPS and leaderboards as well.
Certain ranges of values mean different things in the context of the Game Boy hardware, so having a map of what's where can help you with eliminating useless addresses. Here's the lowdown:
- ❌ 0x0000 - 0x7FFF: ROM Data (Typically no reason to use. If you're a super-dedicated developer you could use the 16-bit value at 0x14E along with alt groups to support multiple ROM versions/regions)
- ❌ 0x8000 - 0x9FFF: Graphics Data (Some things here might correlate with what you're looking for if you're trying to find a map ID or animation, but there will always be a better way of going about what you're doing than using any of these)
- ✔️ 0xA000 - 0xBFFF: Cartridge RAM (IE. save data. Sometimes using these addresses will be unavoidable but then your set could be prone to cheating by loading 100% save files. More info on protecting against save files to come)
- ✔️ 0xC000 - 0xDFFF: Work RAM (The good stuff; almost everything you should use will fall inside this range)
- ❌ 0xE000 - 0xFDFF: ECHO RAM (Do not use, see below)
- ❌ 0xFE00 - 0xFE9F: More Graphics Data (same as Graphics Data above)
- ❌ 0xFEA0 - 0xFFFF: Miscellaneous (Do not use)
For more info see: http://gameboy.mongenel.com/dmg/asmmemmap.html
Similarly to the NES, certain variables may show up twice when searching in the Memory Inspector. The second result is in what's called the ECHO RAM, which is a mirror of the actual memory. Since some emulators tend to ignore this area or emulate it incorrectly, it's recommended to NOT use it at all and always use the first result.
The Game Boy has 4KB of RAM starting at 0xC000. ECHO RAM starts at 0xE000, so if your address begins with an E you'll want to replace the first non-zero character with a C. Remember: C is correct, E is echo!
0xD000-0xDFFF is a block of memory called the reverse echo ram. Multiple banks of memory are saved here, which will visually display as flickering. 0xFF70 (bits 0 to 2) can tell the CPU which bank of memory of memory to access. It's a "feature" used to expand the storage available to GBC ROMs while still supporting GB.
GameShark codes can be a valuable resource for finding addresses you can't or don't feel like finding. They have 12 characters per line and are fairly easy to parse.
[AA][BBBBBB] [CCCC]
[AA] is the codetype. This is a short instruction to the GameShark that defines what to do with the next value. If you understand what the GameShark code does you can use it to help with condition-making.
- 80, 88: The address is 8-bit. Sets the value [00CC] to the address [BBBBBB].
- 81, 89: The address is 16-bit. Sets the value [CCCC] to the address [BBBBBB].
- D0: The address is 8-bit. Checks if [00CC] is equal to the value at address [BBBBBB] then executes the next line if it is.
- D2: The address is 8-bit. Checks if [00CC] is DIFFERENT to the value at address [BBBBBB] then executes the next line if it is.
- D1: The address is 16-bit. Checks if [CCCC] is equal to the value at address [BBBBBB] then executes the next line if it is.
- D3: The address is 16-bit. Checks if [CCCC] is DIFFERENT to the value at address [BBBBBB] then executes the next line if it is.
Here are some examples:
- Paper Mario: Infinite HP:
[80][10F292] [0032]
Sets the 8-bit value at 0x10F292 to 0x32 (50). So this means Mario's HP is an 8-bit value at 0x10F292.
- Donkey Kong 64: Play as Rambi:
[80][74E77C] [0006]
Sets the 8-bit value at 0x74E77C to 6. So this means the character you're playing as is an 8-bit value at 0x74E77C.
- Chameleon Twist 2: Hold L to Moon Jump:
[D0][18BAB5] [0020] <- Looking at this one
[81][18B9E0] [4200]
Checks if the 8-bit value at 0x18BAB5 is equal to 0x20. This means 0x18BAB5 contains a button press variable and Bit5 (0x20) corresponds to L.
Anti-GSC and GameHacking are both good resources for finding GameShark codes.
UniBIOS allows several debugging options, and also access the database of individual cheats for every game. Therefore all achievements for Neo Geo need to be protected from abusing it. The simpliest solution here is disallowing UniBIOS usage completely, directly from the level of achievement code.
Fortunately part of UniBIOS data seems to be reflected in two address strings in the RAM: 0x00fe30 and 0x00fe50. While UniBIOS is active 0x00fe30 in 32-bit size seems to always brings the same value (for every Neo Geo game) which is 80025632, and it doesn't seem to change after the ROM was loaded. For any other BIOS, the value is always 0, (except for the moment the RAM is overloaded by the diagnostic program, after the ROM was loaded).
To protect achievements from using UniBIOS all we need to do is to include a simple protection which will reset when 0x00fe30 in 32-bit size is not equal to 0. This additionally, eventually protect the achievement from unlocking during RAM diagnostic process.
Here is how the protection should look alike (selected in the Achievement Editor):
Here is how the same RAM region looks when other BIOS are used (here MSV):