If you've ever loaded a GBA game onto a repro cartridge and had your save disappear — or never work at all — the reason almost always comes down to a mismatch between what the ROM expects and what the cartridge hardware actually provides. Understanding GBA save types isn't just academic: it's the difference between a game that works and one that corrupts your progress every session.

We've dealt with this problem across dozens of carts and emulator configurations. This is everything you need to know.

Why Save Types Matter

The GBA has no universal save standard. Nintendo left it up to game developers to choose their own save hardware, and they chose different solutions depending on cost, capacity needs, and availability at the time. The ROM itself contains code written specifically to talk to one particular type of save chip using that chip's specific read/write protocol.

When a repro cart or a poorly-configured emulator presents the wrong save hardware, the game's save routines either write to nothing, write to the wrong memory addresses, or interpret read data incorrectly. The save appears to work — the game doesn't crash — but the data either isn't persisted or gets corrupted on the next boot.

This is the core mismatch problem: the ROM assumes a specific save chip, and the hardware needs to match.

SRAM: Fast, Simple, Battery-Dependent

Capacity: 32KB (256Kbit)
Volatility: Volatile — requires constant power to retain data
Interface: Parallel (fast)

SRAM (Static RAM) is the simplest save solution. It's mapped directly into the GBA address space, so reading and writing work exactly like accessing regular RAM — the game code is straightforward and the access is fast. The tradeoff is that SRAM loses its contents the moment power is removed. To persist saves, the cartridge includes a small battery that maintains power to the SRAM chip even with the GBA off.

In practice: SRAM saves are reliable as long as the battery lasts. When the battery dies — typically after 10–20 years — saves are gone. You'll see "The internal battery has run dry" messages in older GBA Zelda carts for exactly this reason.

Games that use SRAM include:
- The Legend of Zelda: A Link to the Past / Four Swords
- Metroid Fusion and Metroid: Zero Mission
- Advance Wars and Advance Wars 2
- Many third-party titles

SRAM is also the type that repro cartridges almost universally use, because it's cheap and easy to implement. This is why patching is necessary when you have a ROM that expects Flash or EEPROM — the patch rewrites the save routines to use SRAM's protocol instead.

FRAM: SRAM's Better Replacement

Capacity: 32KB
Volatility: Non-volatile — retains data without power
Interface: Parallel (same as SRAM)

Ferroelectric RAM is a newer technology that behaves identically to SRAM from a software perspective — same interface, same address mapping, same access speed — but doesn't need a battery to retain data. It's non-volatile by design.

FRAM wasn't an option during the original GBA era, but it's now used in premium reproduction and flash cart hardware. From the ROM's perspective, FRAM is indistinguishable from SRAM: if a ROM is patched to use SRAM save routines, it will work identically on a cart with either an SRAM chip backed by a battery or an FRAM chip with no battery at all.

This is why "battery-less SRAM patch" is a thing — it's not really patching out the battery, it's patching the save routine to use SRAM/FRAM-compatible code, then relying on the hardware (FRAM) to handle persistence without a battery.

EEPROM: Serial, Slow, Two Sizes

Capacity: 512 bytes (4Kbit) or 8KB (64Kbit)
Volatility: Non-volatile
Interface: Serial (slow, requires bit-banging)

EEPROM (Electrically Erasable Programmable Read-Only Memory) is non-volatile and doesn't need a battery, but it communicates serially rather than in parallel. The GBA sends data one bit at a time using a specific command protocol, which makes access significantly slower than SRAM.

There are two EEPROM sizes in the GBA library, and this matters:

• EEPROM_V (512 bytes / 4Kbit): Used in games with modest save needs — high score tables, a few option flags, a single save file
• EEPROM_V (8KB / 64Kbit): Used in games that need more save space but still want the cost benefits of EEPROM

The ROM code handles the address width differently for each size. Emulators and patchers that auto-detect save types need to correctly distinguish between them, since the addressing protocol differs.

Games that use EEPROM include:
- Pokémon Ruby and Sapphire (for the first 128KB of save — wait, no, see the table below)
- Many Nintendo first-party titles
- F-Zero: Maximum Velocity
- Mario Kart: Super Circuit

EEPROM is generally not used in repro carts. The serial interface is fussier to implement correctly, and most repro manufacturers just use SRAM for everything. This is another source of save mismatches.

Flash Memory: The Big One

Capacity: 512KB (FLASH512 / 64KB usable) or 1MB (FLASH1M / 128KB usable)
Volatility: Non-volatile
Interface: Parallel with special erase/write commands

Flash memory gives the GBA's largest save capacity and is used in the games that need it most — primarily Pokémon titles, which have complex save structures including Hall of Fame records, Pokédex data, PC box storage, and the active save file.

Flash saves require special handling: you can't just write to a Flash address like SRAM. Flash must be erased before writing, and erasure happens in sectors. The game code issues manufacturer-specific command sequences to unlock the chip before performing operations.

This is where it gets specific. GBA Flash save chips came from two main manufacturers, and the command sequences are different:

• Sanyo/Panasonic (LE26FV10N1TS): Used in many Nintendo-published GBA games
• Atmel (AT29LV512): A different manufacturer with a different command protocol

The ROM is compiled against one specific chip family. An emulator or flash cart presenting the wrong Flash implementation will fail silently — the game runs, it "saves," but the data doesn't write correctly. This is one reason why even emulator save compatibility isn't guaranteed across all titles without correct configuration.

FLASH512 vs FLASH1M:

• FLASH512 (64KB): Pokémon Ruby and Sapphire use this
• FLASH1M (128KB): Pokémon FireRed, LeafGreen, and Emerald use this (more data needed for the expanded Pokédex and features)

Repro cartridges universally avoid Flash save hardware — it's expensive and requires implementing the erase/write command protocols correctly. Instead, repros use cheap SRAM. This means every Pokémon FireRed or Emerald repro cart needs a save patch to function at all.

Common Games and Their Save Types

Why Repros Always Cause Mismatches

Repro cartridge manufacturers are optimizing for cost, not compatibility. The bill of materials for a repro cart is a few dollars — they use the cheapest available flash ROM chip to store the game data, and SRAM with a small battery for the save. This is fine for games that originally used SRAM. It's a problem for everything else.

When Pokémon FireRed boots on a repro cart with SRAM save hardware, the ROM's save initialization code tries to send Flash memory unlock commands to the save chip. It sends the command, waits for the expected response, gets garbage back (because SRAM doesn't understand Flash commands), and either writes nothing, writes corrupt data, or in some cases enters a retry loop that eventually writes to the wrong address.

The game doesn't crash because the save routines have error handling — they just silently fail. Your save appears to have been written. It hasn't.

Higher-quality repros sometimes use Flash save hardware, but this is the exception. In our experience, even these often use the wrong Flash chip variant and get the command sequence wrong. The only reliable solution is patching.

How the Patcher Fixes It

An SRAM patch replaces the ROM's save routines — the machine code functions that handle writing to and reading from save memory — with new routines written for SRAM's parallel interface. The patched ROM no longer sends Flash or EEPROM commands; it just reads and writes directly to the SRAM address range.

This means:

1. The patched ROM works correctly on any cart with SRAM or FRAM save hardware
2. Existing Flash-based saves aren't compatible with the patched ROM (save data format also changes slightly)
3. The patch is specific to the game — a FireRed SRAM patch won't work on Emerald and vice versa

Our GBA ROM Patcher handles this automatically. You upload the ROM, select the save type patch you need, and download the patched file. The SRAM patch guide covers the full process step by step for the most common cases.

The ROM Header Problem

Here's a detail that surprises most people: the GBA ROM header does not contain a reliable save type field. There's a header byte at offset 0xB2 (the fixed value 0x96) and a few other fields, but nothing that encodes "this game uses FLASH1M" in a standardized way.

Emulators, flash carts, and patching tools all have to determine save type by one of two methods:

1. ROM database lookup — match the game's checksum or game code against a known list of titles and their save types. This is how most emulators handle it.
2. Heuristic scanning — scan the ROM binary for the presence of specific SDK library strings like "EEPROM_V", "SRAM_V", "FLASH_V", "FLASH512_V", or "FLASH1M_V". The Nintendo GBA SDK embedded these strings in the compiled output of games that used those save libraries.

The string scan approach works reliably for official Nintendo SDK-compiled games because the SDK always embedded these identifiers. ROM hacks and homebrew that replace the save routines entirely may not have these strings, which is why heuristic detection can fail on patched ROMs — and why our tool uses both methods together.

Summary

The GBA save type ecosystem is a product of early-2000s hardware economics: different games used whatever save chip made sense for their budget and storage needs. SRAM was fast and cheap but needed a battery. EEPROM was non-volatile but slow. Flash was high-capacity but required manufacturer-specific programming sequences.

Repro carts universally use SRAM because it's the cheapest option. Most valuable GBA games — especially Pokémon titles — used Flash. The mismatch between the two is why repros and flash carts often need patching to work correctly.

The fix is mechanical and predictable: swap out the save routines in the ROM to speak SRAM's language instead. That's exactly what the GBA ROM Patcher does.

Want to know if your specific game needs a patch? Check the complete GBA hardware and patching guide for a full compatibility reference.