Game Boy Advance cartridges manufactured by Nintendo use a variety of different technologies for non-volatile storage (colloquially, “save files” or “save RAM”), and each type works a little differently. For a real cartridge running on real hardware, there’s no problem because Nintendo made sure that each game cartridge included the kind of storage that the game expected, but for emulation and preservation things get more complicated.
To start with, let’s look at the list of available technologies. As far as we know, every official GBA cartridge shipped by Nintendo used one of the following storage technologies, which I will refer to as “save types”:
A game designed to work with one kind of storage won’t work with the others, and what’s worse is that the hardware interfaces for these storage systems occupy the same portion of the GBA’s memory-map, so it’s impossible for an emulator to emulate more than one at a time. When it boots the software, it needs to know what storage the game needs, before the game needs it. So what does it do?
In previous Nintendo consoles, like the SNES, there’s information in the game’s internal header that specifies the hardware features the game expects to be present, or at least that can be used to make a reliable educated guess. Unfortunately, the GBA’s internal header does not have any such information.
However, by a happy chance it turns out that the official Nintendo SDK seems to have shipped with library functions for dealing with different types of save storage. The code isn’t consistent enough to be fingerprinted, but it generally includes some common byte-strings that the emulator can search for, which I will refer to as “save codes”. These include:
EEPROM_V: Indicates one of the EEPROM save types.SRAM_V: Indicates the SRAM save type.FLASH_V: Indicates the 64 kilobyte Flash RAM save type.FLASH512_V: Also indicates the 64 kilobyte Flash RAM save type (usually found in later games)FLASH1M_V: Indicates the 128 kilobyte Flash RAM save type.These save codes give a pretty good hint about the save code, so if an emulator scans through the game image looking for one of these codes before booting it up, it’s got a pretty good chance of working. Unfortunately, this is not a perfect method, for a variety of reasons:
There are some games that contain two save codes, but only work with one specific save-type. There’s no reliable heuristic for picking the correct save-type.
There’s only one game that contains three save codes, which is “Top Gun - Combat Zones”. It is a filthy liar, and if the game detects any of the storage types described by those save codes, it activates an anti-piracy routine and prevents you from picking any options in the main menu.
There’s two possible sizes of EEPROM storage, but only one save code for both of them. Obviously if the emulator sets up an emulated 512-byte storage area, and the game expects 8 kilobytes of storage, that’s not going to work out too well.
Due to the particular protocol used by the EEPROM storage systems in GBA cartridges, an emulator can pretty reliably guess what storage size a game expects to use before the game actually reads or writes any data, so this isn’t a terrible limitation. It’s still added complexity, however.
The GBA was far from the only device that supported Flash RAM for storage; manufacturers of Compact Flash cards and SD cards and USB thumb-drives were all churning out Flash RAM chips as fast as they could. Although each manufacturer’s chips behaved in more or less the same way at the electrical level, at the software level they all expected the instructions to read or write data in different, manufacturer specific formats. Software written to store information to one brand of Flash RAM chips wouldn’t work at all with Flash RAM chips from another manufacturer.
Nintendo came up with a reasonable solution to this problem: As best I can make out, the story went something like this: they would buy batches of Flash RAM chips from a few manufacturers, then add support for those Flash RAM chips into their official SDK, and send it out to the game developers whose games were scheduled to be manufactured in the near future. At start up, the code in the SDK would talk to the Flash chip and say “what’s your manufacturer code?” and use the protocol corresponding to that manufacturer. When Nintendo’s cartridge-factories began to run out of Flash RAM chips, they’d buy more batches from whichever manufacturer had the best deal, and remove support for the previous manufacturer’s chips from the SDK and replace it with the new.
The upshot of all this is that if a GBA game is designed for one of the Flash RAM save types, the first thing it will do is ask the emulated Flash RAM “what’s your manufacturer code”, and there are half a dozen or so possible answers, some of which will be accepted and some of which will cause error messages or maybe even a crash… and exactly which codes are accepted changes from one game to the next.
Every GBA emulator with reasonable compatibility has some kind of database that specifies save-type information. Some emulators, like VBA-M have carefully-chosen defaults with a list of exceptions, while MAME tries to be exhaustive. Unfortunately, none that I’ve found actually guarantees that every game has been tested, and none of them seem to include Flash RAM manufacturer code information, so reliably emulating GBA games is still somewhat difficult.