Snes9x gives you two completely different saving systems, and confusing them is the source of most “I lost my progress” stories. Battery saves are the game’s own saving, stored in a .srm file. Save states are snapshots of the entire emulated machine that you create manually with a key press. This guide explains where both live, how the slot and bank system works, and which files you should back up. It assumes Snes9x 1.63 from the download page; first-time users should start with the Windows setup guide and the setup hub.
One folder for everything: .\Saves
By default, both systems write to the same place: a folder called Saves in the same folder as snes9x.exe — in configuration terms, the save-state directory and the SRAM directory both default to .\Saves. That one detail explains the most common save problem: if you extract Snes9x somewhere Windows will not let it write — inside Program Files, for example — neither your battery saves nor your states can be written reliably. The location can be changed in the settings, and pointing it somewhere sensible is also the foundation of the sync workflow in our cloud save sync guide. When saves go wrong entirely, see Snes9x saves not working.
Battery saves: the .srm file
When a game offers to save — at a save point, after a level, in a menu — it is writing to battery-backed RAM on the original cartridge. Snes9x stores that data in a .srm file named after the game. The file is written out when you unload the ROM or quit, and it is loaded automatically the next time you start the same game, so battery saving needs no hotkey and no menu: just save in-game and close the emulator properly. A related file, .rtc, appears for games with a real-time clock chip and serves the same house-keeping purpose for clock data.
Save states: 10 slots × 10 banks = 100 states
A save state freezes everything — position, health, timers, randomness in flight — so you can return to the exact moment later. Press Shift+F1–F10 to save and F1–F10 to load (the full key list, including the preview dialogs on Shift+F11 and F11, is in the hotkeys reference). Those ten quick slots are only one bank: Snes9x provides 10 banks of 10 slots, up to 100 states per game, a system added in version 1.61. On disk the states are files with a three-digit extension running from .000 to .099, numbered across all banks, saved alongside the .srm in the Saves folder. Older guides claiming “9 slots” are repeating the stale bundled readme text — the current program has ten slots per bank, and 1.63 specifically fixed the QuickSave 0–9 slot shortcuts.
The .oops file: your unsaved-session insurance
There is one more file worth knowing about. If you play for a long time and quit without saving, Snes9x writes an auto-recovery freeze file with the extension .oops into the Saves folder. It is a safety net, not a saving strategy — treat it as a pleasant surprise when it rescues a session, and use real states and battery saves for anything you care about. If you do find yourself relying on it, that is a sign your Saves folder setup needs the attention described in the saves not working fixes.
What the files are, technically
The state (snapshot) format is documented by the project itself: files carry a #!s9xsnp signature and can be gzip-compressed. One consequence matters for archiving: the snapshot format in use since version 1.52 is incompatible with 1.51’s format, a reminder that states are snapshots of one emulator’s internal machinery rather than a universal save format. That is exactly why the portability story below differs between the two systems.
Which saves travel between emulators
This is where the two systems part ways. Per the bundled readme’s compatibility notes, .srm files are shared with all SNES emulators — battery saves are a standard cartridge-RAM dump, so you can move a .srm between Snes9x, other standalone emulators and the Snes9x libretro core and the game will pick up its saves (keep the filename matched to the ROM). .rtc files are likewise shared with bsnes. Save states are the opposite: tied to the emulator and its format version, so treat .000–.099 files as Snes9x-specific and never as your only copy of long-term progress — the .srm is the durable record. Back up the whole Saves folder, keep battery saves for progress that must survive a machine change, and use states for moment-to-moment convenience.
Which system should you trust, when?
Use each system for what it is. A battery save is the game’s own checkpoint: durable, portable between emulators, and written at moments the game designer chose — trust it with anything long-term, especially RPG progress measured in dozens of hours. A save state is a convenience with a shorter memory: perfect for a hard boss attempt, a branching choice, or stopping mid-dungeon, but tied to this emulator’s snapshot format and therefore the wrong place to keep your only copy of anything. The players who lose progress are almost never the ones missing a feature — they are the ones who played for weeks on states alone, or saved only in-game while their Saves folder could not be written. Ten seconds spent knowing which file holds your progress is the entire fix.
Habits that prevent lost progress
- Keep Snes9x in a writable folder so
.\Savescan actually be written - Save in-game (battery) at natural stopping points, not only with states
- Quit the emulator normally so the
.srmis written out on exit - Back up the Saves folder before moving machines or reinstalling
- Rely on
.srmfiles, not states, for progress you move between emulators
Everything else in this series — settings, controllers, cheats, sync — is collected in the setup hub.