How Games Saved Your Progress Before Memory Cards

Imagine a gaming world without the ability to save. Imagine games like Baldur's Gate 3, with hundreds of hours of gameplay, thousands of items to collect in your inventory, and decisions to make without being able to save the game?

Maybe not with games lasting hundreds of hours, but before, you had to sit down and finish the game in one sitting. Sometimes it took two or three hours, but the ability to save a game is something that wasn't so common before.

The advancement of memory cards and internal storage has eliminated these trade-offs. In parallel, rewritable discs and PC storage solved the problem for those with the hardware. But before memory cards, there were two practical options:

• Passwords: No hardware cost, but cumbersome and limited.

• Battery-backed memory (SRAM + battery): Natural experience, more space, but risk of loss when the battery dies.

Saving means storing data that allows you to reopen the game at the same point: level, items, health, defeated bosses, and so on. This memory was called a "state." Remembering this state was a necessity for large games like Final Fantasy or Phantasy Star, where, without a way to save, it was mandatory to finish the game in one sitting. On early consoles and PCs of the time, there were three clear limitations that made saving games difficult:

1. Rewritable memory was too expensive.

2. Many cartridges were read-only (they had nowhere to save).

3. Some game states were too large to fit into simple solutions.

Understanding these solutions reveals two important things: how cost and hardware limitations shape design decisions, and why certain games required you to write down codes. It also explains why some cartridges lose saves over time and why collectors care about saving and migrating data. The challenge was to find something that cost little and worked well enough for both the player and the developers. This led to the solutions you see below.

Passwords

Passwords, or codes, were a purely software-based solution. The game took the "minimum required" state to continue—e.g., level, weapons, defeated bosses, some statistics—and transformed it into a sequence that the player noted down. When they wanted to return, the player entered the password, and the game reconstructed the state. This was widely used because it didn't require additional hardware. A cartridge with only ROM ran normally.

But there's a price: long, error-prone passwords, and the state wasn't always saved completely. You wouldn't return exactly where you were, or you wouldn't have exactly the items you picked up along the way. The process is straightforward:

• They choose what needs to be saved—only the essentials.

• Each piece of data becomes a set of bits (small pieces of information).

• These bits are put together into a sequence.

• The sequence becomes characters (letters, numbers, or symbols) for the player to write down.

• They almost always added a checksum to prevent a wrong password from creating an invalid state.

Some passwords were just letters and numbers. Others used blocks or icons to reduce confusion (0 x O, 1 x I). In some games, there are even short words instead of a long string of characters—this makes it easier to remember and write down.

Passwords work well for level-based games or games with few save states. But when the game has a large inventory, a detailed map, or many variables, the password becomes lengthy. And no one likes typing 40 characters. Plus, getting a single character wrong and losing hours of gameplay was quite frustrating.

Even so, passwords had an advantage: they didn't require a battery or special hardware. If you wrote down a password, it lasted for decades. This helps preserve progress for those who collect or document old games.

A simple password example was:

• Imagine a game where the only important information is: current level (1 to 8), whether boss X was defeated (yes/no), and three items (each 0-3). You can convert all of this into about 12 bits. These 12 bits become 2 or 3 characters in a table created by the game. That's it: a short password. If you need to save more things, you increase the number of bits—and the password grows.

Not every programmer was comfortable writing long passwords. So they used simple compression tricks:

• Grouping frequent combinations and assigning a fixed index.

• Using variable encoding: the most likely states received shorter codes.

• Replacing characters with icons to avoid confusion and reduce human error.

All of this reduced password length without requiring additional hardware.

Cartridges with memory and battery

As games got bigger—especially RPGs with large inventories—passwords became obsolete. The practical solution was to put save memory inside the cartridge. Good examples of this were games like Pokémon, which could save the monsters you had in your inventory and backpack.

This memory is called SRAM, and it loses data if it loses power. To prevent this, cartridges had a battery that kept the SRAM powered even when the console was off. This way, the data "stayed there" until the battery ran out, and since saving this state didn't consume much power, a watch battery like this could last for years. For the user, the process is simple: you save in the menu, and when you return, the game loads automatically. No need to type in any code. A typical cartridge had:

• ROM for the game code.

• An SRAM chip to store the saves.

• A battery that powered the SRAM when the console was off.

• Basic circuitry to switch between the console's power supply and the battery.

Programmers treated the SRAM as if it were a small file. They wrote a header (identification, version), then the data: progression flags, inventory, and statistics. It was also common to have a checksum to detect corruption if the battery was low or something went wrong.

The advantages of this method were clear: saves without typing, much more space, and a natural experience for the player. The disadvantages, however, were the extra cost of the cartridge (memory + battery) and the limited battery life. When the battery died, the saves disappeared. Replacing the battery sometimes required opening the cartridge and unsoldering the component—a task many people avoided, and, of course, you’d lose your save.

Today, collectors replace batteries and back up their saves beforehand. Emulation also allows you to extract the save file and save it to your PC.

Internal console memory

Even before memory cards became standard, some consoles offered a way to save progress using the device's internal memory, rather than relying on battery-powered cartridges or passwords. Consoles like the Sega CD had internal RAM, sometimes battery-powered, that could store data from any compatible game. The player didn't need to type anything, and progress was automatically available whenever they returned to the game.

The internal memory was limited, both in terms of space and the number of simultaneous saves (about 8MB), but it was an interesting alternative when cartridges didn't have batteries or when the game needed a fixed, shared save location. Unlike cartridge SRAM, this memory was fixed and non-removable, working for all console games that used it.

It worked simply: the game wrote directly to the console's memory, generally structuring the data with a header, progress flags, inventory, and statistics, and included a verification system to prevent corruption. Like battery-powered cartridges, this memory made the save experience natural and transparent for the player.

The major drawbacks were the limited space and the fact that it wasn't portable: if the console broke or lost power without protection, the saves would be lost. Even so, it was an important step in the evolution of save methods, creating a bridge between classic cartridges and future removable memory cards.

Besides passwords and battery-operated cartridges, there were alternatives for game saves that were more limited and uncommon but attempted to create solutions so you wouldn't lose your progress on consoles and PCs:

• Famicom Disk System (and other disk-based systems): The game saved to disk. This allowed for complex saves but depended on the peripheral.

• PCs and home computers: They saved to floppy disks or cassette tapes. On PCs, saving to disk was already common.

• Proprietary peripherals and cards: Some consoles or add-ons had their own memory.

• Game design: Some games avoided saving when using frequent checkpoints or short levels—a way to reduce the need for saving.

Since many batteries have died today, collectors and emulators saved these memories from the past. The most common alternatives:

• Extract the SRAM file with equipment and save it to the PC.

• Carefully replace the cartridge battery.

• Rewrite the save to the cartridge, if possible.

There are tutorials and services that do this. You can also play on an emulator using the save file and keep everything saved forever.

The evolution of games, their expansion in size, hours of play, and the need to create ways to save progress forced developers to find practical solutions. Passwords and battery-powered cartridges were two responses to this same need, each with clear advantages and disadvantages. Passwords required effort from the player to write down and remember; battery-powered cartridges required investment in hardware and, consequently, increased price.

Both demonstrate that, in the past, game developers had to compromise between cost, player experience, and technical limitations. Today, technology solves these problems, but for older players, it's worth remembering how it worked, and for younger players, learning about it and understanding why some old measures still appear in games and collections.