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.

  • 39
    I can't back it up with sources, so I'll just leave it as a comment: Additionally to the technical reasons, having an explicit Save functionality is also often a game design feature. The developers can decide if and when the player is allowed to save. Plus it also gives players an option to return to a previous state in case they screwed up royally at some point or missed something and want to roll back their progress (e.g. in RPGs).
    – Tim
    Commented Jul 12, 2021 at 7:51
  • 2
    Most important: Not every player wants to restart from the last position. Beside, there are games doing exactly that - after all, it's up to the game how it uses the save RAM (if one exists at all).
    – Raffzahn
    Commented Jul 12, 2021 at 12:38
  • 2
    If it's safe to save the game state regardless of what's going on then the game probably isn't complex enough to be worth playing. Pokémon is actually an excellent example of a game which should not "save as you go".
    – MonkeyZeus
    Commented Jul 12, 2021 at 18:47

4 Answers 4


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.

  • 1
    SML2 auto-saved on completion or failure in a level. That's why it was common practice to turn off the gameboy during the death animation. If you were too slow, you risked corrupting the save state, though, IIRC. Commented Jul 12, 2021 at 6:03
  • 3
    The Game Boy Pokemon TCG game also saved progress automatically. If you turned your Game Boy off while in the middle of a match, and then turned it back on, it'd be basically right where you left it. I have a vivid memory of a moment where I discovered that the "randomness" of the game wasn't actually random when the outcome of a match hinged on a single coinflip, and no matter how many times I switched the game off and back on again, the coin never came up any way but the losing option for me.
    – nick012000
    Commented Jul 12, 2021 at 14:22
  • 1
    Pokemon TCG is an awesome game! :D I don't remember that in-match behaviour exactly, I thought it had a temporary (auto-erased) but manual 'memo save' like Shenmue. Thanks for the info.
    – knol
    Commented Jul 12, 2021 at 14:28
  • 3
    +1 for a great answer, but as I read it I kept waiting for a point you never addressed, which I thought you would when mentioning "user control": the user sometimes wants to revert to the latest manual save. Am I right in thinking games with manual save typically kept note of what that would change through an "ephemeral" save along the way, which would be junked if the user save scummed? If so, how similar was that task to the full-scale auto-saving in games that didn't need a manual save at all?
    – J.G.
    Commented Jul 12, 2021 at 15:47
  • 1
    That would depend on the game, I think. I didn't mention it because I was worried my rambling answer went off-topic enough. :) Maybe make a new question about that specifically since I'm not sure exactly what you mean.
    – knol
    Commented Jul 12, 2021 at 15:49

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.

  • 12
    Modern microcontrollers commonly have a feature called "brown-out detection" which monitors the supply voltage and does something if it drops too low. Most commonly it's used to force the chip into reset state when the voltage drops, to avoid corruption, but sometimes it's also possible to handle the BOD interrupt and do something useful with your last moments of life (particularly if you put a big capacitor on the line). Probably not so common in 1989, though :)
    – hobbs
    Commented Jul 12, 2021 at 5:11
  • 2
    I don't know about microcontrollers, but 'real computers' (like the PDP-11) had powerfail interrupts; you had a few milliseconds to save volatile state in core, or later, battery-backed RAM.
    – dave
    Commented Jul 12, 2021 at 12:48
  • 2
    @another-dave: Machines like the Game Boy were designed to a rather lower price point than the PDP-11.
    – supercat
    Commented Jul 12, 2021 at 14:46
  • 2
    Having debugged this very problem; failure of brown-out detector looks like executing random jumps in code.
    – Joshua
    Commented Jul 13, 2021 at 14:11
  • 2
    @supercat: Because it never executed code that didn't exist in the ROM even though it executed code that was unreachable by static analysis.
    – Joshua
    Commented Jul 13, 2021 at 16:51

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.

  • 6
    "All consoles of the era ... save only the main characteristics, not the whole memory." An interesting and tangential comparison is that computer text editors typically DID dump the program memory to disk when saving a file: e.g. that's why early versions of MS-Word each had a different file format.
    – Kaz
    Commented Jul 11, 2021 at 21:07
  • 1
    dumping the whole memory if the whole memory is full text isn't really a problem. Now if the text has specific binary tags that depend on the program, that's a bit dumb for compatibility sake with future versions but saving this information is anyhow required. You can't deduce this information from anything else. Commented Jul 11, 2021 at 21:38
  • 1
    Actually, Game Boy cartridges generally had a rather generous 8Kbytes of RAM even when the games only needed a fraction of that. The 8K of the cart would be sufficient to hold the entire state of internal memory were it not for the issue of data corruption on power-down.
    – supercat
    Commented Jul 12, 2021 at 5:12
  • 1
    what about several save slots then? Commented Jul 12, 2021 at 8:26
  • 1
    At least for Pokémon, having several save slots would have completely broken the concept of trading via the link cable. Of course it was possible to cheat anyways, but with multiple save slots, it would have been outright trivial to duplicate Pokémon.
    – wrtlprnft
    Commented Jul 12, 2021 at 12:05

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.

  • 2
    Nintendo's 'Game Boy Programming Manual' has a lot of references to 'external working RAM' but it doesn't seem to have any guidelines on its intended/discouraged use. As far as I can tell, the programmer is supposed to treat it as just non-volatile external RAM. I haven't read any Lot Check documents though.
    – knol
    Commented Jul 13, 2021 at 13:27
  • 1
    As you already allude in your last sentence: Battery-backed SRAM doesn't have any practical limit on write operation, unlike small EEPROMs (often ~100.000 cycles) or bigger flash memories (often around ~1.000 - 10.000 cycles). Did the approval process you refer to refer to flash-backed save states or was that in fact a Nintendo Gameboy game requirement? Commented Jul 14, 2021 at 8:26
  • @MichaelKarcher I never saw the submission requirements for the GameBoy, I'd assumed that some games utilised flash based backup hardware. If that is not the case, then it is likely that there was no such limit on the writes. Commented Jul 19, 2021 at 7:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .