Save state format (is there a standard?)

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

Save state format (is there a standard?)

Post by jwdonal »

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. :)
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Save state format (is there a standard?)

Post by rainwarrior »

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Save state format (is there a standard?)

Post by tepples »

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.
ccovell
Posts: 1045
Joined: Sun Mar 19, 2006 9:44 pm
Location: Japan
Contact:

Re: Save state format (is there a standard?)

Post by ccovell »

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...
User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

Re: Save state format (is there a standard?)

Post by jwdonal »

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. :)
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: Save state format (is there a standard?)

Post by creaothceann »

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.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

Re: Save state format (is there a standard?)

Post by jwdonal »

Great info! Thanks a ton! :beer:
Post Reply