Retro emulation works by recreating a console in software, then running an unchanged game image inside that virtual machine. The ROM is not a PC conversion: it is a dump of the original cartridge chips (or a disc image), while the emulator models the CPU, graphics, audio, memory map, timers, controllers and cartridge hardware. An in-game save is the small block of data the game was designed to write to SRAM, EEPROM, flash or a memory card. A save state is separate: the emulator freezes its entire machine state—registers, RAM, video state and timers—and stores that snapshot in a file.
That distinction explains most retro-gaming mysteries: why a cartridge battery can erase a Zelda file, why a .srm save usually moves between emulators but a .state file does not, and why a ROM can fail after you change emulator cores.
How do emulators work?
An emulator supplies a software model of the original console. It repeatedly fetches an instruction from the game image, decodes it, performs the equivalent operation on the host computer, updates registers and flags, and advances the emulated clock. The game code remains the original machine code; it is not rebuilt for Windows, macOS, Linux or a phone.
A typical 8-bit or 16-bit emulator coordinates several models:
- CPU: Executes opcodes, addressing modes, registers, flags and cycle counts.
- System bus and memory map: Connects RAM, ROM windows and memory-mapped hardware registers.
- PPU/GPU: Produces backgrounds, sprites, palettes, video memory, scan timing and interrupts.
- APU: Emulates sound registers, channels and sample output.
- Cartridge hardware: Implements bank-switching mappers, coprocessors and save-memory chips.
- Input and timing: Presents controller reads and synchronizes video, audio and interrupts.
For the NES, Klika describes the core loop as reading the instruction at the program counter, decoding its type and operands, running the matching routine, then updating memory and registers. The NES address space is 64 kB, and different instructions consume different numbers of clock cycles. If those cycles are wrong, the CPU, PPU and audio hardware drift out of alignment.
Interpretation, dynamic recompilation and static recompilation
Interpretation decodes and executes one original instruction at a time. It is straightforward to count cycles and is useful when a console depends on exact timing, but it requires more host-CPU work. Dynamic recompilation (JIT or dynarec) translates frequently executed blocks into native host code while the game runs, improving speed while making cycle-accurate behavior harder. Static recompilation translates a program ahead of time; it can be fast but is difficult for software that depends on self-modifying code, interrupts or hardware quirks.
High-level and low-level emulation
Some subsystems are modeled at a high level (HLE), reproducing the result of a service rather than every hardware operation. Others use low-level emulation (LLE), modeling much closer to the original instructions and timing. Dolphin’s documentation, summarized by IndieKings in 2026, describes HLE audio as faster and LLE audio as slower but close to perfect. The trade-off is general: HLE can improve performance, while LLE can preserve behavior that depends on hardware details.
Dolphin’s published host baseline is a CPU with SSE2 support, a modern dual-core processor around 3 GHz, and graphics support for Direct3D 11.1 or OpenGL 3.3. Those are requirements for the emulator on the host computer, not a conversion process for the game.
What is a ROM file?
On original cartridge hardware, the game program lived in mask-ROM chips mounted on the board. NES cartridges normally separated CPU code (PRG ROM) from graphics data (CHR ROM): the CPU could not directly read CHR ROM, and the PPU could not directly read PRG ROM. As games grew, cartridge boards added mapper chips to switch banks and sometimes added coprocessors or writable memory.
A ROM file is a dump of those read-only memory regions, packaged so an emulator knows how to expose them. NesHacker describes the board simply: “Game boards have a chip inside called a program ROM, and it contains all the code and graphics.” In practice, copying is not always one linear read because boards can contain multiple banks and extra hardware.
What is inside an NES iNES file?
The common NES iNES format, designed by Marat Fayzullin, places metadata before the dumped data:
| Part | What it contains | Size or rule |
|---|---|---|
| Header | Format marker, PRG and CHR sizes, mapper number and mirroring information | 16 bytes |
| Trainer | Optional data used by older Famicom copiers | 512 bytes; usually skipped |
| PRG ROM | CPU program data | Measured in 16 KB units |
| CHR ROM | Pattern and graphics data for the PPU | Measured in 8 KB units |
Mirroring can be horizontal, vertical or four-screen. NES 2.0 extends the older header with more cartridge metadata and reduces guesswork for larger or unusual boards. Disc-based systems use other image formats, such as BIN/CUE, ISO, CHD or RVZ; these remain dumps of original media rather than native ports.
Why is a ROM dump not enough by itself?
“Because NES cartridges contain custom hardware, ROM dumps alone are not enough to accurately describe how a game should be emulated,” says Emulation General Wiki. The bytes do not contain the complete behavior of a mapper, scanline counter, sound expansion chip or save controller. The emulator must implement that behavior in code, and the header or a database tells it which implementation to attach.
An unheadered NES dump may therefore fail even when every ROM byte is intact. A newly discovered board can also remain unsupported until someone writes its mapper behavior. Super NES coprocessors create the same problem, while Game Boy Advance titles require the emulator to identify the correct save-memory interface.
How are ROMs made, and how do you dump a cartridge you own?
A physical dump is made by reading the cartridge’s chips with dedicated hardware, not by copying an ordinary computer file. Open-source Sanni Cart Reader projects documented by Hackaday use an Arduino Mega 2560 Pro, custom adapter PCBs and firmware to read ROM data to an SD card. The same class of reader can dump and restore save memory, including unusual Satellaview and Nintendo Power cartridges. Older readers such as Retrode existed but are harder to find.
- Identify the board and connector. Use the correct adapter for the console family; different cartridges expose different buses and voltage requirements.
- Dump the ROM first. Save the raw image to more than one location and retain the reader’s checksum or verification output.
- Dump writable memory separately. A cartridge’s SRAM, EEPROM or flash save is not automatically included in the ROM image.
- Keep the original files untouched. Make working copies for emulators and preserve the raw dump as an archival master.
- Test the image with the appropriate emulator core. Header and mapper metadata must match the board; some tools can repair or add headers, but that changes the file.
Sixteen-bit battery-backed SRAM is often far beyond its original service life. If you plan to replace a cell, dump the save before opening the cartridge. Removing the old battery without keeping SRAM powered can erase it. A tabbed CR2032 and a 3.8 mm Gamebit screwdriver are the appropriate parts for many NES, SNES and N64 boards; a bare store-bought CR2032 lacks the welded tabs those boards require.
How did original cartridges save progress?
Save memory is separate from the read-only game program. The game writes a small record—characters, inventory, map flags or a checksum—to a writable chip. The chip type determines whether a battery is required and what an emulator must simulate.
Battery-backed SRAM
Static RAM is fast and freely writable but volatile. While the console is on, the cartridge supplies operating voltage. When it is off, a lithium coin cell keeps the RAM in low-power retention mode. A diode prevents the battery from powering the whole cartridge, another prevents the console’s 5 V supply from charging the cell, and a resistor keeps the chip deselected during shutdown.
Nintendo Power described the design in 1991: “By putting a battery in the Game Pak, game data can be stored as long as the life of the battery—about five years.” Many cartridges are now decades older, so a dead cell can make the game report an empty or corrupted file. The Legend of Zelda on NES and Super Mario World on SNES are familiar examples of battery-backed saves.
Games commonly store a checksum with the save. If corruption makes the checksum invalid, the game may erase the slot rather than load unsafe data. Editing a .srm file in a hex editor therefore requires the game-specific checksum to be recomputed.
SNES SxROM/MMC1 boards illustrate that the battery was optional: an 8 KB RAM chip could be fitted with an SL solder selection, while the cell, diodes and resistors were omitted on boards that did not retain saves.
EEPROM and flash
EEPROM and flash retain data without a coin cell. Many Nintendo 64 cartridges used EEPROM; others used battery-backed SRAM or flash, so the presence of a battery varies by game. On Game Boy Advance, documented save choices include 512-byte EEPROM, 8 KB EEPROM, 32 KB SRAM, 64 KB flash and 128 KB flash. A game written for one interface cannot simply use another because these devices occupy the same memory-map region.
Why GBA save detection can be wrong
The GBA internal header does not identify its save chip. Nintendo SDK libraries left strings such as EEPROM_V, SRAM_V, FLASH_V, FLASH512_V and FLASH1M_V in the ROM. Emulators scan for them, but developers sometimes edited strings, included multiple libraries or triggered copy-protection behavior. A database of known games and a user override are common fixes. The override can be confusing because it may ask for a flash-chip vendor or device ID that is not visible without opening the cartridge. Emulating EEPROM does not wear out the physical chip; wear is a concern for the real cartridge.
What is a save state?
A save state is an emulator snapshot, not a game save. The core serializes CPU registers, RAM, video memory, timers, controller state, audio state and other internal variables, then writes that blob to disk. Reloading restores the captured frame, so you can save during a jump, before a boss or in a game that never offered a save system.
MVG’s Game Boy example includes the CPU registers, LCD position, scrolling registers, palettes, sound, timers, VRAM tiles, sprites and background. Because every emulator tracks hardware differently, there is no universal save-state format. A state made by one PlayStation core may not load in another, and even a PPSSPP 1.16 state may fail after an update to 1.17.
How rewind uses save states
Rewind keeps a rolling series of snapshots in memory rather than asking you to name files. One implementation described by MVG pushes a state every frame onto a last-in, first-out stack; a 360-state buffer provides six seconds at 60 frames per second. That is an implementation example, not a universal specification. Other emulators use compressed differences or less frequent snapshots.
What is the difference between in-game saves, SRAM and save states?
Use the game’s own save as the archival copy and a save state as a convenient checkpoint. The following differences matter when moving between emulators or preserving a collection.
| Method | What is stored | Exact-frame restore | Portability | Version dependence | Risk to later in-game saves |
|---|---|---|---|---|---|
In-game save / SRAM / .srm or .sav |
Only data the game designed to retain | No; restores the game’s normal save point | Usually portable among compatible emulators and, with hardware tools, the original cartridge | Low, provided the save type and filename match | Low; the game controls when it writes |
Save state / .state |
Whole emulated machine state | Yes, often to a specific frame | Not portable to real hardware; usually limited to the same core and often its version | High | Higher if you stop making normal in-game saves or overwrite a slot |
Held Games states the practical rule plainly: “Use in-game saves as your primary save method. Use save states as a convenience layer on top.” After a difficult section, trigger the game’s normal save and then make a named state. Keep several named slots instead of relying on one quick-save slot that can be overwritten.
Why did my Zelda or Pokémon save disappear?
First determine whether the missing data was an in-game save or only a state. A dead cartridge battery, incorrect save type, wrong filename, corrupted checksum or a changed emulator path can affect normal saves; a core update or accidental overwrite can affect states.
- Original cartridge: A dead CR2032 or another failed battery-backed cell removes SRAM contents. Dump the SRAM before attempting replacement.
- Emulator: Confirm that the ROM and
.srm/.savhave the expected base filename and are in the core’s save directory. Back up the directory before updating firmware or cores. - GBA: Verify EEPROM, SRAM or flash selection. A wrong interface can make a good save appear blank.
- Edited save: Recalculate the title’s checksum or the game may deliberately clear the file.
- Save state: Place the state beside the same ROM, load it with the same core and version, and check that a quick-save slot was not replaced.
Handheld firmware can store both formats in one tree—for example, KNULLI uses /userdata/saves/ for system saves. Back up both, but treat the .srm or .sav as the long-term copy.
Why will a ROM not load after I switch emulators?
The file may be valid while the new emulator lacks the required mapper, coprocessor, BIOS, header interpretation or save-type configuration. A save state is an even stricter case: it belongs to the original core and may depend on an exact version.
- Check that the new emulator supports the console and the cartridge mapper or enhancement chip.
- Confirm the image format and header. Most NES emulators expect a recognized iNES or NES 2.0 header; an unheadered dump may need metadata rather than a new ROM.
- For disc systems, preserve the complete set of BIN/CUE or equivalent files, not only one track.
- Use the emulator’s documented BIOS location when a system requires firmware, and do not assume a BIOS is included with the game image.
- Copy the original
.srm/.savbeside the new ROM using the filename and save directory that core expects. - Load the state only after confirming the same core and version. If it fails, start from the portable in-game save instead.
Are emulators legal, and are ROMs legal?
These questions have different answers and depend on jurisdiction. Independently written emulator software that does not ship copyrighted ROMs, BIOS files or encryption keys is widely described as the legal core. Gizmodo summarized the distinction this way: “These hardware-to-software environments are fair game so long as they don’t contain any ROMs themselves.”
The game image is a copy of copyrighted software. Gizmodo also wrote: “However, the games themselves, those ROMs, are direct copies of the original games. They are breaking copyright, and it is certainly illegal to distribute.” Downloading a commercial ROM from someone else is not automatically made lawful by owning the cartridge.
Personal dumping of media you own is argued as format shifting or archival use in some jurisdictions, but there is no categorical U.S. ruling established here that makes every cartridge dump lawful, especially where copy-protection circumvention is involved. Section 117 of U.S. copyright law is often cited in discussions of necessary software copies, while game audiovisual rights remain a separate issue. A presenter summarized the popular view as “Whatever Nintendo says, emulators are legal – but ROMs are not,” while acknowledging that he was not a lawyer.
Official re-releases, remasters and subscription libraries are the rights-cleared route when available. Older games can remain absent because music, character or publisher licenses have expired or are split among owners.
Which way should you play an old game?
| Approach | Strength | Trade-off |
|---|---|---|
| Official re-release | Rights-cleared distribution and supported saves | Availability depends on the publisher’s catalog and licenses |
| Dump-and-emulate from owned media | Preserves the original image and supports flexible displays and saves | Requires a compatible reader, careful backups and attention to local law |
| FPGA recreation | Uses hardware logic to reproduce console behavior with low latency | Core availability, cartridge support and cost vary by system |
| Original hardware with repair or flash cartridge | Retains the physical console experience | May require battery replacement, specialist tools and maintenance |
What is the safest save-and-backup routine?
- Make an in-game save whenever the game offers one.
- Create a named save state only as a checkpoint, never as the sole copy.
- Copy the ROM,
.srm/.savand state files to separate backups. - Before changing cores, emulators or handheld firmware, back up the entire save directory.
- For physical cartridges, dump SRAM before replacing a battery and install a properly tabbed cell with suitable tools.
- When moving systems, transfer the in-game save first; regard a state as disposable unless the same core and version remain available.
Frequently Asked Questions
Can a save state be converted into an SRAM or .sav file?
Usually not directly, because a state contains emulator-only registers, video timing and other data that the game never writes to its save chip. Some emulator tools can boot a state, return to the game and create a normal in-game save, which is then exported as the title’s regular save format.
Does replacing a cartridge battery always restore a lost save?
No. A replacement preserves data only if the SRAM contents survived until the swap. If the cell was dead long enough for the RAM to lose power, or the game erased a failed checksum, the original progress may already be gone.
Why is my save file the right size but still unreadable?
Size alone does not identify the memory technology. The emulator may be configured for the wrong EEPROM, SRAM or flash interface, or the file may belong to a different revision, region or mapper. Matching the exact game and save type is more important than matching byte count.
Can I use a save state on another console or flash cartridge?
No. A state describes an emulator’s internal machine snapshot and has no standard representation on cartridge hardware. Transfer the game’s normal SRAM, EEPROM or flash save instead, using hardware and software that support that title.