Why do Game Boy games have explicit save functions, instead of using battery-backed non-volatile cartridge SRAM to store the game state?

Question

Game Boy games used a battery-backed SRAM module for their save states. Since the SRAM module retains its whole content, why do Game Boy games always need a manual save operation?

Wouldn't it be much easier for the game to just keep its persistent state in the cartridge SRAM? That way, the state would always be retained and there would be no need to manually save.

So e.g. a Pokémon's hit points or the player's position in the world could be held in the cartridge SRAM instead of the console RAM, so when the Game Boy is turned off, those values are automatically retained.

Answer 1

Game Boy games do not always need a manual save operation. There's no hardware reason that would prevent Game Boy games from saving in the way you describe.

For the Game Boy hardware, RAM present on the cart can be used by games for whatever it needs.

SRAM is RAM on the cartridge; most of the time, it's backed up by a battery and used to store save data, but some games also use it as extra work RAM (Pokémon games use SRAM as scratch buffers for sprite decompression, Super Mario Land 2 uses some of its SRAM to store variables and level data).

(Also note all these answers should apply to most of the 8- and 16-bit consoles, I'm thinking of the Mega Drive specifically, since that has the simplest cartridge interface.)

I think there might be a few Game Boy games that have smaller saves, say high scores only (Kirby's Pinball Land?), that do save automatically. Doesn't Super Mario Land 2: Six Golden Coins save automatically on completion of a level?

To take your idea of using SRAM directly for live save games: For a game save to be useful, there needs to be a known-good-state in SRAM to load from, and this has to be the complete state of the game you want to save. Actively updating the game state in SRAM results in loss of the known-good-state quality while the current frame is being executed. While you're running the game, you're constantly modifying the game's values, and this process isn't a single indivisible 'atomic' operation. Take a Pokemon example: when the player walks into a house, you've got to change their current map/room number and then place the player's X,Y at the corresponding entrance of the new room. If the game were turned off half-way through a frame, you've got garbage - the player could be in the new map but in the wrong location in the black tiles surrounding the room, or in a new position but still somewhere on the old map off in the sea.

If the designers split up this process a little bit, and saved the party status at the end of a battle and then saved the player's position and current flags at the conclusion of every Nth out-of-cutscene step on the overworld, it'd still need to, say, keep a double buffer of the player's state in SRAM: a 'hot' page that's being updated, and a 'cold' page as the known-good-state for loading, flipping back and forth between them. That's ugly - but doable.

The simpler alternative is to not use SRAM for the live data, though, and only copy the relevant save data en-masse when it's safe/appropriate. The examples mentioned by Michael and Nick in the comments (SML2 and Pokemon TCG) sound like they do this on a per-level or per-turn basis. (One way a modern game would protect against incomplete-saving problems is to have the two (or more) save page system I mentioned before, with a master 'which page is good' bit that's toggled last, so when the whole save is written the SRAM indicates the old known-good page is still good, or the newly saved page is now good.)

There are two categories of reason that spring to my mind as to why Game Boy games have explicit save functions generally, which is the question you've asked in your title, and again they're not really related to the Game Boy.

One reason why games have save points / discrete save options is that user control of the circumstances reduces chances of a failed save as the game state is copied to SRAM. Handheld games can be interrupted unpredictably in several ways: by running out of battery, physical knocking of the cartridge, jolting of the system by attaching a DC adapter. If a save game were interrupted half way through its process, you'd end up with a damaged save state. Given that saving the state of a complex game can take noticeable time - and it's complex games that would usually have a save game capability - allowing the user to save on their own terms prevents errors. Six Golden Coins presumably just saves the list of levels that have been completed. It can't be more than, say, 1 kilobyte. Pokemon takes noticeable time to save - it would add up if it occured at the conclusion of every wild and trainer battle. (Game Freak have said that the time requirement was one reason.)

This second reason is a bit circular, but I offer it anyway:

Game designs copy from one another and take things that were enjoyable or practical from existing games and incorporate them into themselves. Games from one console generation imitate those from the preceding generation, and those imitate board and tabletop games the designers knew or heard about. A lot of Game Boy games weren't sophisticated enough to need saving, and they were copies of their home console counterparts, and they in turn were ports of arcade games or adaptations of existing board or tabletop games.

Games in general didn't offer auto-saves yet because nobody had demonstrated a game design with auto-saving in a successful game of that genre yet. When a new game appears with a design that works in a coherent manner with the rest of the game and has few technical downsides (small save space (i.e. low cost in components), quick saves, error-tolerant/not error-prone), then other games will copy it.

Sonic 1, 2, CD and 3 are all very similar in gameplay and design: you go to the right and try to achieve a more difficult hidden objective along the way. CD introduced auto-saving with the Mega CD's save RAM, which was also in 3 with its internal SRAM.

(There is also a Mega Drive-specific technical reason why it probably wouldn't be a good idea for Sonic 3 specifically to have used the cartridge SRAM as normal RAM - there's a latch on the board that acts as a mapper, paging the SRAM into the address space in place of part of the ROM. While the SRAM is accessible, that part of ROM isn't, and the game has to be programmed to work around this. Also that SRAM is mapped in only on odd addresses, so it's not as straightforward as regular internal RAM.)

Why do modern JRPGs still have save points? Some even have save points -and- autosaving. :) I recall some old Apple II rpgs (maybe Wizardry?) which stored your party's status on a dedicated 'Party Disk' which was constantly written to as you progressed. If your party died, they were gone if you hadn't suspended the game and duplicated the disk beforehand. So to answer the inverse of your question: why would games -introduce- a manual save operation when auto-saving was already possible? It's because auto-saving is sometimes really annoying. :D

I've also thought of another possible reason which could apply: in order to develop a game that uses SRAM as working RAM, all the development cartridges used would have to be a more expensive variant fitted with SRAM or the game wouldn't run at all. Running a game with 'normal' SRAM saves on an EPROM cart with no SRAM will give you loading and saving errors, but you could still test the game/maps/music/assets freely. I'd conjecture that at least some development was done like this to save some money where possible.

Answer 2

Microprocessors have a minimum operating voltage spec, but that generally doesn't mark a threshold where they stop executing code. Instead, it specifies level below which they aren't guaranteed to execute instructions correctly. When a game is powered off, a processor may execute a few hundred or a few thousand instructions between the time the voltage falls below the minimum space and the time it's low enough that the processor can't do anything. If a game cartridge had RAM that could be written at any time and the console were to lose power, the processor would be likely to write some unpredictable data to some unpredictable addresses, making corruption extremely likely.

To guard against this, cartridges often have circuitry which will write-protect its contents unless the processor performs a particular sequence of operations to unlock access. This sequence of operations would be unlikely to occur as a result of processor malfunction during power loss, so if power is lost while a cartridge is write-protected, memory corruption can be prevented.

If a game were to write cartridge RAM continuously while the processor lost voltage, it would be very likely that an attempt to store something to a particular address in the cartridge might get misprocessed as an attempt to store something to a the wrong address. If the Game Boy had an I/O bit that could be polled to determine whether the CPU was guaranteed to have enough power to execute at least 1000 instructions, it might be possible to design a game that would, on each frame, check whether adequate power was available, and if so unlock the memory, update it, and re-lock it. I don't think there's any way that code could receive advance notice of power loss, however.

Answer 3

I'm not a specialist but what I read is that the battery-backed SRAM module is on the cartridge, not in the console itself.

The technique you're describing is roughly the one used in emulators (known as "save states"). Emulators aren't aware of the game mechanics, they just dump the whole RAM + state of hardware registers in a file, and reload it later. But that's a bruteforce approach that actual gamesaves could not afford.

Even if the size of the Gameboy RAM is small (8Kb) and emulators can create savestates in a breeze, the battery-backed SRAM module is much smaller than 8kb (memory was expensive, and keeping memory backed up costs battery with that technology. The battery was reportedly hard to replace too).

So the best way to save a game state (since developpers have the source code) is to save the player state at the end of a level for instance. That way you just have to save lives, scores and current level, and you can restore the game main characterstics (memory needed to save a game depends on the game itself), and the rest of the RAM will derive from it on reloading the game & recomputing other stuff. With that technique, you can even save multiple games (save slots), depending on the game, and not consuming a lot of backed RAM.

You also control when to save and when to load, saving the hassle of being aware of the hardware state at the save/load point (screen, audio, registers...)

This isn't Gameboy-specific. All consoles of the era use explicit save, either on the console itself or on the cartridges, and save only the main characteristics, not the whole memory.

Answer 4

I'd like to offer an additional reason, from the point of view of a game developer.

Part of the requirements for a game to pass the submission/approval process was to limit the number of times the save data is written to. This is actually still in force to some degree on the Nintendo Switch. Flash memory can only handle a finite number of writes before it starts to fail, so developers are required to limit the frequency of the writes.

Examples of 'what not to do' included writing save data every time the player moves, so I think generally auto-saves on level complete should be acceptable, but for some developers it might have been easier just to give the player control over when the save is performed and not risk a failed submission.

This frequency restriction might not have been the case for battery-backed save mechanisms, but it definitely was, and still is, for flash memory mechanisms.