Download Gb_bios.bin

0 views
Skip to first unread message

Cristy Borovetz

unread,
Aug 3, 2024, 4:30:35 PM8/3/24
to diterteted

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.

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 gb_bios.bin or 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.

[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.

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 simplest 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.

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.

When working with PSP make sure to check if your game has any DLC as this form of content is able to be accessed by players without altered saves or patched versions of the game and will need to be accounted for and in some cases protected against if it provides advantages that you don't want players to exploit.

c80f0f1006
Reply all
Reply to author
Forward
0 new messages