Save state format (is there a standard?)

Hello all,

I'm going to be adding save state support to my FPGA SNES in the near future. Is there a standard (I realize that's probably a dumb question) save state format used by SNES emulators. If so, can someone point me to documentation?

If not, is there documentation on the existing formats for the most popular emulators? It would be nice for people to be able to use save state files from say bsnes or snes9x. I'd rather not just roll my own and have yet another format floating around.

Thanks as usual.

I don't think there's a standard for save states, at least last time I looked. The format tends to change with each revision of an emulator too, e.g. if they emulate a new state they need to throw it in. (If you're lucky they threw a version number into the file format. If you're even luckier they might have documented it instead of having to deduce it from the source code.)

SNES9X applies GZip compression to the whole file after packing it, so you need a GZ decompressor to even get inside (zlib will do).

You'll probably find RAM dumps in blocks like you'd expect, but the layout of the file is going to be totally arbitrary, and everything else (registers, and all the various internal bits) gets very arbitrary indeed.

There's a standard for saved states of the SPC700, but not much else. And even that's just a dump of the audio RAM and S-SMP and S-DSP registers, missing internal states of the DSP channels.

You might have less to store if you always freeze the saved state at the start of vertical blanking, as that's when the PPU has the least material state.

Have you tried contacting the author of vSNES http://www.romhacking.net/utilities/274/ ?
That program can load savestates from ZSNES and '9x. His documentation linked to some other docs about the save state formats, but those links are long dead...

Oh wow, what a great find! It just so happens that the author creaothceann has recently replied on one of my other topics...I wonder if I can coax him in here.

ZSNES has an (almost) fixed savestate format; everything is basically a struct:

http://www.romhacking.net/documents/170/
http://www.romhacking.net/documents/190/
http://www.romhacking.net/documents/171/ (SPC)
(these docs are really just copied from the source code)

IIRC after the fixed parts comes a variable-sized block if the game uses a coprocessor, and at the end there's a 64x56 bitmap that contains the savestate preview picture. There are almost certainly some ROM hackers who prefer this fixed format because the savestates can be edited in a hex editor.

SNES9x uses GZIP compression by default (I think you can disable it though with some menu option). After decompression you can see that the data is arranged in various blocks, each of which has a header with ID (signature) and length in bytes. So if you have a tool (like vSNES) that understands this basic file format structure, you can load savestates from future emulator releases and just ignore the unknown blocks. (I think I used the source code to find out the structure of each block.)

vSNES can also load SNESGT and Super Sleuth (now kindred) savestates, but I don't remember the formats. Super Sleuth also has preview pictures.

bsnes savestates, as far as I know, are created by every system component dumping its state into the savestate file, and loading it from the file again upon savestate loading. Just like with ZSNES' coprocessor block, the only way to know what's inside is to basically recreate the emulator.

Each format is fundamentally incompatible with the others, either by file format structure or because some data is missing / represented differently. vSNES can load a savestate in one format and save it in another, but that's only useful for other savestate tools that understand only a certain format and use only specific parts (like VRAM).

For your own format you would at least need a signature and a version field (unless you want to encode that in the file names). Named blocks with a known structure are good for other tools. (You could also wrap every variable in a block.) You could even use flat INI files, or INI files that encode a hierarchy in the section names. Or XML files.

Great info! Thanks a ton!