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.
Game Boy (RAVBA)link
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 (No reason to use. This area contains header information that's only read on certain emulators.)
- ❌ 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 8KB 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!
On the GBC, the 4KB of memory from 0xD000-0xDFFF is a bank from a larger 32KB memory block not directly accessible by the processor. Bits 0-2 of 0xFF70 indicate which bank is loaded into the 0xD000-0xDFFF memory block. It's a "feature" used to expand the storage available to GBC ROMs while still supporting GB ROMs.
Bank switching (changing the value of 0xFF70) causes the memory in the 0xD000-0xDFFF range to update. This appears as flickering in the Memory Viewer and makes tracking down values in that memory range difficult. If you are writing conditions dependent on memory in that block, you should also require that 0xFF70 have a specific value to ensure you are looking at the correct bank. The 4KB of memory from 0xC000-0xCFFF is not bank-switched and can be used safely without additional conditions.
It is not advisable to use these addresses for achievements if there is any alternative to doing so. As of January 2018, RALibretro will only display bank 0x00 at 0xFF70. RetroArch has fluctuating memory banks, but the various addresses do not function in the same manner as RAVisualBoyAdvance. At least until RetroArch receives a memory inspector, achievements using addresses from 0xD000-0xDFFF will only work within RAVisualBoyAdvance.
RALibRetro and RetroArch support the GB/GBC BIOS, which shows the "Nintendo" and "GameBoy" logo before starting the game. This provides approximately four seconds where the main memory ($C000-$DFFF) hasn't been initialized and can't be trusted, and may cause achievements to trigger while loading the game for a subset of users who have the BIOS enabled.
To enable this feature, put the bios file (named
gbc_bios.bin) into the system directory of either RALibRetro or RetroArch. When you start the game, you will see the "Nintendo" and "GameBoy" logos before proceeding into the actual game.
If this is causing you problems, you may need to add logic to prevent the achievements from triggering while the BIOS is executing, but it would be preferable to use in-game logic if possible (i.e. a specific screen is being displayed).
The BIOS code is loaded from $0000-$00FF, so identify some chunk of that memory that's unique while the BIOS is running and ignore it. For example, the last four bytes of the GBC BIOS block are
3E 11 E0 50, so you could add this condition to the achievement to prevent it from triggering while the BIOS is running.
32-bit 0x00FC != 0x50E0113E
After the BIOS completes, the block is blanked out with FF's, and repurposed for interrupt vectors. For more detail, see A Look at the GameBoy bootstrap.
NOTE: The last four bytes of the GB BIOS are
3E 01 E0 50. So the GB condition would be:
32-bit 0x00FC != 0x50E0013E
Nintendo 64 (RAP64)link
Using GameShark Codes for Addresseslink
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] 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:
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:
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]  <- Looking at this one
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.
Mandatory UniBIOS protectionlink
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:
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):
The RAM from $0000-$FFFF is reserved for the kernel. The boot executable name appears to reliably be placed at $9E18 AND $B8B0. The boot executable name almost always contains the disc serial, which is unique per region, so this can often be used to determine which version of a game the player is using.
Spyro the Dragon SCUS_942.28 9E18 5C 53 43 55 53 5F 39 34 32 2E 32 38 3B 31 \ S C U S _ 9 4 2 . 2 8 ; 1 B8B0 63 64 72 6F 6D 3A 5C 53 43 55 53 5F 39 34 32 2E 32 38 3B 31 c d r o m : \ S C U S _ 9 4 2 . 2 8 ; 1
Last 10 changes on this page:
[2020-04-25 09:30] Jamiras:add note about disc serial for PSX games
[2019-05-13 22:03] Jamiras:small difference in gb vs gbc bios
[2019-03-03 10:53] Ben-Ghazi:Removed the tip that implies that ROM data can be used to identify different regions since this doesn't work on RetroArch.
[2019-02-17 09:34] Jamiras:add note about GBC BIOS
[2019-01-07 14:48] Scott:Updated Console Specific Tips (markdown)
[2018-12-01 21:29] Scott:Updated Console Specific Tips (markdown)
[2018-12-01 21:27] Scott:Updated Console Specific Tips (markdown)
[2018-11-27 11:35] Jamiras:Updated Console Specific Tips (markdown)
[2018-11-27 11:24] Kvon:added note about reverse echo ram
[2018-04-30 19:35] meleu:added "Mandatory NeoGeo UniBIOS protection" by Salsa