I've been writing a savefile editor for my favorite Saturn game and in trying to completely decipher the contents of the file (about 80% done), I've run across something I can't figure out.
When the hook backup library option is checked, SSF creates individual, unpadded files separately for each game. When it is not checked, it does what other emulators do and just writes the savefiles packed into binary files that represent internal memory and external memory. Presumably, exactly as a real Saturn would do.
My problem comes with how the date is represented between the two methods - hook backup vs "real". In the real method, the value representing the date (4 bytes) is the number of minutes elapsed since January 1st, 1980, in big endian format, as you would expect. I've tried this several times at different intervals with several different games and it's consistent.
When hook backup is enabled, it spits the date out as something that I can't figure out. I've tried forwards, backwards, little endian, big endian, and other things, but I can't figure it out. When saving the game in intervals of only a few minutes, only the upper half of the first byte (out of 4) changes, but this didn't really help. So for example, 3D 04 49 10 changing to 6D 04 49 10.
Do you guys know how SSF is recording the date into the file with hook backup enabled? It's still 4 bytes, like the real method, but I can't figure it.
The binary files are how the Saturn saves the data, you are right about that. Their contents are akin to a filesystem, complete with "features" like fragmentation and file recovery (as long as the data is not overwritten). The backup library just saves those "files" onto HDD instead of the space in the Saturn, and it is an extra feature/hack in SSF, and not the norm.
I don't know the technical details (I'd love to read any documentation you have), such as the one you are looking for. As far as I know it's the BIOS that handles all of the backup save functions. The guys at SegaXtreme may have more info on the format.
It is fully featured in every way as far as I can tell, so maybe your time would be better spent trying to translate the few parts of it which still appear in japanese. Or try to, unless you set your system to run non-unicode apps in japanese language, and no, Applocale does not work on it, I tried.
What I meant by savefile editor is having a fully featured program to edit specific things about that particular game - which castles you have, how much experience your generals have, moving them from one location to another, etc. I already checked out SSBKM a few days ago. I followed the instructions to make the buttons in english, but I'm not entirely sure what it does, aside from basically being a standalone memory manager for the saturn? When I opened the internal memory, the box showed a 32x16 grid (the array of blocks), indicating which blocks were used and which ones weren't. Beyond the visual and basic memory management (like natively on the saturn), again, I'm not entirely sure what this program does. If you're supposed to be able to edit individual pieces of the file (at the byte level), I couldn't glean how.
Anyhow, the information about how the internal and external memory are laid out was found at the Shining Force Central forums, posted by someone working on a similar editor for Shining Force 3. I investigated the internal/external memory files after reading the post and it seems spot on. The middle part of the post had enough information for me to figure out the layout.
I still need to figure out the date thing though. It's not important, but once I get too curious about something, I get stuck on it and can't ever quit until I figure it out. Otherwise it just nags at me for forever.
I did sign up for the Segaxtreme forums the other day, I suppose it couldn't hurt to ask over there too.
Oh I see what you mean. Yeah, an editor like that would be cool, I tried doing edits for Madou Monogatari a while ago but I got hung at the CRC check.
Yes, SSBKM is a straight up memory editor, all it does is copy game files from various saves - internal sram, external sram, the ssf backup library, etc. More handy than you think, especially if you want to export backup library saves to another emulator, or export your sram save files into the backup library.