Add Save States to Your Emulator

Topic Overview

Emulator Save States

Save states serialize entire machine RAM, registers, and peripheral state so players jump backward instantly. Unlike battery saves (just game SRAM), snapshots freeze the full hardware at one instant.

What to Serialize

Minimum payload:

• CPU registers, flags, PC, SP
• All RAM (main memory, VRAM, OAM)
• PPU/APU internal latches and timers
• Cartridge mapper state (bank indices, RAM enable)
• Emulator metadata: version, CRC of ROM

Load must restore bit-identical state or games desync. Version your snapshot format for when you add new chips.

For example, saving mid-jump in Super Mario Bros. requires capturing PPU scroll latch and OAM positions, not just CPU registers.

\`\`\`c fwrite(cpu, sizeof(cpu), 1, fp); fwrite(ram, ram_size, 1, fp); fwrite(&ppu, sizeof(ppu), 1, fp); \`\`\`

Design Notes

Include a hash of the loaded ROM in snapshots so loading state against the wrong game fails fast. Silent mismatches produce ghosts that are miserable to debug.

For This Exercise

This exercise asks you to design save/load for your emulator's CPU and memory subsystems. You will implement serialization that restores identical execution state across save and load cycles.

You will use the same mental model here when reading production interpreter source later in the track. Sketch one concrete input on paper, predict the outcome, then confirm with code. That discipline catches logic errors early and makes debugging far faster when you extend the implementation in follow-on tasks.

Your Task

Add save states to an emulator: serialize the machine into a versioned, chunked, checksummed binary image, and load it back safely. The loader rejects corrupt, truncated, foreign-ROM and future-version images, migrates old versions, and skips chunks it doesn't know. The machine is small: A, X, Y, SP (8-bit), PC (16-bit), a 32-bit frame counter and 256 bytes of RAM. Power-on values are SP=FD and PC=8000, with everything else 0.

Image format (little-endian)

• Chunk order: CPU (A, X, Y, SP, PC as u16), then RAM (256 bytes), then, in version 2 only, TIME (the frame as u32).
• CRC32: the standard reflected polynomial 0xEDB88320, with init and final XOR 0xFFFFFFFF.

Input

One command per line (; starts a comment):

cCopy
Loading…

Loading

Check, in this order:

1. Size: at least 18 bytes, else truncated.
2. Magic: bad magic.
3. Version 1..2: unsupported version N.
4. Length: 14 + P + 4 must equal the image size, else truncated.
5. CRC: CRC mismatch (stored X, computed Y).
6. ROM: ROM mismatch (state was made with X, loaded ROM is Y).
7. Chunks: a chunk running past the payload is truncated. Known tags with the right length are applied, and anything else counts as a skipped unknown chunk. Missing CPU or RAM gives missing CPU chunk / missing RAM chunk.

On failure, print load S: REASON; state unchanged. Nothing is modified. A version 1 image has no TIME chunk, so the frame becomes 0.

Output

cCopy
Loading…

• state lists the non-zero RAM bytes, or all zero. dump prefixes a %04d offset.
• Errors:
  • load S: slot is empty
  • set: unknown field K
  • poke: ADDR VALUE (hex, 00-FF)
  • save: SLOT (0-3) [v1], load: SLOT (0-3)
  • dump: SLOT OFFSET LENGTH (1-32), dump: slot S has N bytes
  • patch: SLOT OFFSET VALUE, patch: slot S has N bytes
  • truncate: SLOT LENGTH
  • append: SLOT TAG(4 chars) HEXBYTES
  • unknown command X

Example

Input:

cCopy
Loading…

Output:

cCopy
Loading…

Requirements

1. Write fields byte by byte in little-endian order. Never fwrite a struct, because padding and endianness would make the format depend on the compiler.
2. Decode into a temporary state and commit it only after every check passes.

Hidden tests cover the byte layout, CRC detection of a flipped byte, ROM mismatch, a v1 image with migration, unknown chunks skipped, truncation, bad magic, an empty slot, and command errors.