Skip to content

Save States

mewzers edited this page Mar 27, 2026 · 1 revision

5. Save States

Oxide includes a ROM-specific save-state system with 3 slots per ROM.

Slot model

Each ROM can use 3 save slots.

Slots are available through:

  • top bar menus
  • keyboard shortcuts
  • debug terminal shortcuts
  • explicit .state file loading

What a save state contains

A save state stores:

  • CPU state
  • Display state
  • Memory snapshot
  • ROM identity information
  • Slot metadata

Current save-state data structures include:

  • EmuSnapshot
  • SaveStateMeta
  • PersistedSaveState

Save-state file storage

Save states are stored under savestates/.

Folder names are derived from:

  • sanitized ROM name
  • stable FNV-1a hash of ROM bytes

Typical layout:

savestates/
└── <rom-name>-<rom-hash>/
    ├── <rom-name>_01_<timestamp>.state
    ├── <rom-name>_02_<timestamp>.state
    └── <rom-name>_03_<timestamp>.state

Saving a slot

When saving:

  1. Oxide verifies that a ROM is loaded
  2. runtime state is cloned into a snapshot
  3. metadata is generated
  4. the slot file is written to disk
  5. in-memory slot state is refreshed
  6. a status/overlay message is shown

Manual saves may ask for overwrite confirmation if the slot is already occupied.

Shortcut-triggered saves bypass the manual confirmation dialog.

Loading a slot

When loading:

  1. Oxide checks whether the slot exists
  2. CPU and display state are restored
  3. memory is restored when valid
  4. runtime accumulators are reset
  5. emulation resumes from the restored state

Loading from a .state file

Oxide can also load a save-state file directly from disk.

That path is separate from the in-memory slot cache and can be used even outside the top-bar slot menus.

Automatic slot discovery

When a ROM is loaded, Oxide scans the matching save-state directory and repopulates slot metadata automatically.

This ensures that save/load menus reflect current on-disk slot files.

Clone this wiki locally