What is the actual structure of the file generated when I do CTRL+F1 (or F2, etc)? I notice it looks nothing like the ZSNES save format, and many rom hacking programs use the ZSNES save format to extract data from the game. I have already phased out the old and inferior ZSNES as my SNES emulator of choice (and in fact have deleted it from my system), in favor of SNES9x which is actually a better emulator (at least when comparing the latest version of ZSNES versus the latest version of SNES9x). I'm in serious need of a way to now generate ZSNES format game saves from SNES9x game saves, for use with rom hacking tools (like sprite editors that read graphics data from the rom, but read palette data from ZSNES save states). If there isn't a converter, maybe I can make one, if I knew just how the structure (physical layout of data in the file) of the ZSNES save state compares to the SNES9x save state.

Snes9x 1.51 is compatible with .zst save states because of it's similar SPC sound core. Snes9x 1.52 and later use the blargg sound core for SPC emulation, and have a different structure due to this. This means that .zst save states are incompatible.

Also, if you're trying to extract resources from the game, why not export as a ips file? I know very little about rom hacking so I'm not sure if this is possible or not...

_________________
Snes9x FAQs | Forum Rules
What operating system are you using? 32 or 64bit? Version of Snes9x? Is the text at the bottom of the window white when you load the game?
These suggestions are usually the solution to your issue!

it's not.

besides, if he were manually extracting resources like that, he wouldn't need to use a savestate viewer to do such.

question to the devs: compared between 1.51 and current, is the difference in VRAM location constant or variable? if it's constant, a state file could be modified for usage such as this by trimming the differing amount from the file after the header...

Is this open source, or is the exact specification of the file format used in the SNES9x 1.53 emulator a "company secret", intentionally hidden to PREVENT modification of any give SNES9x save file in a manner that would allow interoperability between SNES9x and ZSNES files, as ZSNES is bitter competition?

1.51 would only read .ZST states, it never outputted them, so I doubt it would help. And ZSNES is not competition. (especially considering its development is effectively dead--Snes9x's is just slow)

The state format for Snes9x isn't a secret--the code for it is in snapshot.cpp in the source tree. I don't believe there is documentation of the specific offsets, and I'm too lazy to write it myself, so you'll have to calculate the offsets on your own by adding up the sizes. The locations of the common memory blocks should be constant because the conditionally included special chip blocks are at the end. You might be able to take only the blocks you need and copy those into a file with a .ZST's offsets, and this will probably work if you just need the palettes. But I wouldn't try to salvage even a whole .ZST back into a working Snes9x state.

Where can I download the source?

In the release thread linked at the top of this forum.

Or directly on github: http://github.com/snes9xgit/snes9x

What I can tell you from simply loading different roms and dumping save states and examining the save states, is that they are COMPRESSED data. I can tell because every dump from every game generates is a different sized file, and when loading the dump into a raw graphics viewer I don't see anything other than random "white noise" like a TV set tuned to a channel with no signal (back when they had analog TVs). It's not just a raw save state with data that's in different locations in the file that it was before. I don't know what algorithm compresses them. It may very well be a unique-to-snes9x algorithm and not a standard algorithm like BZIP or GZIP or ZLib.

Any help with this would be GREAT.

Also proof it's compressed is that when opened in a hex editor, instead of seeing the magic number "#!s9xsnp" at the beginning of the file, I see this instead 1F 8B 08 00 00 00 00 00 00 (hex digits shown because hex value 00 doesn't correspond to any printable text)

Again, any help with this would be GREAT.

Fortunately though, 7zip can autodetect the compression and decompress it to raw data. But still if I'm going to write a program that converts it to a format that has the color palette in the same offset within the file as that of a ZST save file (so that standard SNES graphics rippers can find the palette in the file) I'm going to need to write a piece of sofware that performs this conversion, and the first step will be decompression. And for that I'll need to know the compression algorithm. While 7zip will autodetect and decompress it, it does NOT report back what algorithm it found. So I need to know what compression SNES9x uses.

Again, any help with this would be GREAT.





Also what's up with not being able to edit my posts? Every time I decide some more info in my post would be useful, it says I can't edit my post, so I'm stuck with multi-posting, which looks like spam.

Furthermore, I have discovered after decompressing the snes9x save state and finding the corresponding section of data in a ZST (ZSNES save state), that the SNES9x save state has the opposite endian for multibyte data types, when compared to ZST.

Snes9x uses zlib to apply gzip compression to the savestates (if compiled that way, which is the default for releases).

I'm not using GZip to decompress this. I'm using ZLib, but not ZLib.dll. ZLib.dll requires C programming to use. I'm using VB6, and even though VB6 does have ways of declaring libraries from DLL files, I've tried it and it doesn't work with ZLib.dll (works with most other dll files though). It seems that the ZLib.dll file doesn't like to cooperate with the VB environment (a C-only dll file it seems, compatible with NO OTHER programing language than C?). Instead I'm using CompressZIt.ocx. It is a wrapper that someone made for the DLL file. And this OCX file IS is compatible with VB6. However it only encapsulates the zlib algorithm, not the gzip algorithm. This is MOSTLY directly convertable between the 2 (they both use deflate), however they do NOT use the same checksum. GZIP uses CRC32. ZLIB uses ADLER32.
There is NO WAY to convert CRC32 to ADLER32. Since it is the checksum of the UNCOMPRESSED data this is a real problem. To get the hash of the uncompressed data in a different form, it must be uncompressed, and then the new hash calculated. But the algorithm for ZLIB (or at least the implementation of ZLIB that CompressZIt uses) specifies that it will REFUSE to output the uncompressed data without having first confirmed that the decompressed data has an ADLER32 that matches the supplied ADLER32. So I'm stuck with NO WAY TO PROCEDE with my SNES9x save format converter (which IF ever finished, will decompress the GZIP save file, extract the palette data, and save it to a new file at the same position in the file that a ZSNES save file would have, to make it compatible with most SNES graphics hacking/ripping tools).

Never mind. I did a "last ditch attempt" and just ignored giving it an actual hash (left the 4 bytes of the ADLER32 hash as 00 00 00 00) hoping it would work, and it did. It actually decompressed it successfully! If I checked it's error function it likely would shown it returned a hash fail error (allowing me to add in my own error handling code). Normally ignoring this hash check return value wouldn't be wise, but in this case ignoring the hash check's return value was the the only way to go because the hash is useless in this particular use of the decompressor (decompressing something for which I don't have a proper ADLER32 hash, and for which not having the proper hash is actually an EXPECTED condition rather than an unexpected condition).

Sounds like this may be related to the new board upgrades...

_________________


Unofficial Test Monkey For:
* Snes9X GX (Wii)
* Snes9X EX (Android)
* Snes9X 64-bits

ZSNES|Ben Heck|NSRT|Bob Smiley

OP: out of curiosity, why VB6? it's old, it's unsupported, and the runtimes aren't guaranteed to work on current versions of Windows.

AoL, your sig image has a grammatical error in it. "Dont" you wish they checked it before they made the animation?

I use VB6 because it comes as naturally to me as my own English language. Learning C would be like trying to learn Spanish. I've grown up on GW Basic in DOS since I was a kid. I was born in 1985.

I learned VB when it became available on Windows, and I've been programming with it ever since. I've tried C on a number of occasions. Each time I have had problems not only learning the new syntax, but in fact trouble compiling ALREADY WRITTEN CODE. I mean sometimes I download a C source code of someone's opensource program. I load up a copy of VC++, load the project file, hit the "compile" button, AND SEE OVER9000 ERRORS APPEAR ON THE SCREEN! Seriously C code often doesn't even work on the very compiler it was written in, C.

So I have SWORN OFF C FOR LIFE.

I have made MANY useful pieces of software with VB6. It works just fine for what I use it for. If there's something it CAN'T do directly, I can always google around until I find an addon (OCX or DLL file) that gives me the capability that I desire for the program I'm writing. Also sometimes people much smarter than myself have written their own VB implementations of various complicated algorithms I couldn't even IMAGINE trying to write a program for (AES encryption, MD5 hash, etc). However I can find these peoples' VERY GOOD WORKING IMPLEMENTATIONS in VB6 that some smart people have managed to write. They usually release their code as either VB Modules (.bas files) or VB Class Modules (.cls files). So by downloading these DLL, OCX, BAS, and CLS files that other people have made, I can MASSIVELY expand the capabilities of my own VB programs, to the point that I find ABSOLUTELY NO REASON to stop using VB6.

FINALLY finished my program. I made a thread about it here: viewtopic.php?f=3&t=5344
That thread has a download link for getting a copy of my program, plus instructions on how to use it.