Sega Saturn RAM backup parser

Okay, here goes nothing.
I'm publishing a public beta of a Sega Saturn RAM backup parser. It is a PC Windows software.
What it does?
It can load/save Backup RAM (aka power memory) and Internal RAM images, both from real hardware and emulators.
It can import compressed Datel images from MemCartPlus.
It can convert cluster size from 64/256/512/whatever bytes to 64/256/512/whatever.
It can extract/insert/delete single saves.

The software is stable now, and the development is freezed. Hardware support is pending, but there is no hardware yet.

Mac/Linux/Android/whatever port could be possibly made upon request. Any other reasonable feature requests are welcome.

Last release page (with binary downloads):
https://github.com/hitomi2500/ss-save-parser/releases/latest

That's how it looks like:

 

Is it open source ?

 

I've no intention to keep it closed source or selling it. So yes, it will be open source, as soon as i will decide where and how to upload the sources (github / sourceforge / etc). I'm just still unfamiliar with all these open source repositories.
Until then, i can send sources to anyone who need them, but i'd rather not, since it's still not debbuged enough and might be unstable.

 

OK, thank you !
If you're unfamiliar with source code control tools, just zipping your development folder is fine

Did you tested with real backup cartridge backup data ?
If you need for testing, you can use my dumps of backup data (both internal memory and cartridge memory) : http://ppcenter.webou.net/files/SaturnMemoryCart_20120119.zip

 

Application cannot run because libgcc_s_dw2-1.dll is missing from your computer.

 

Oops, i suppose it's mingw stuff. I added this dll to the archive, link in the first post updated.
I will link it statically later, to remove all these dll dependencies.

 

This application failed to start because it could not find or load the Qt platform plugin "windows".

 

Oops again. I suppose i know where the root of the problem is, but it will need a bit of futher debugging on machines without qt. I will fix it soon.

Update : i compiled the program statically, it should run without any dlls now. Still i included some of them just in case. Can't test now, all my PCs at home are on linux. But i will test (and further fix if needed) it within a day.
Link is the same, only the archive name is changed.

Update 2: Good news, static build is working, even without all the dlls.

cafealpha2, i managed to load files from "official memory carts" folder, but they look like they've been only half-dumped, and the program does not expect this. For now you need to set 1M load mode in setup, and when the program asks you if it should switch to 512K, decline.
There is some garbage in the file names and comments, maybe it's a font problems on the local machine, or a 0x00 character, but i will check it anyway. And there is some strange cluster in BUP05.BIN at 0xEA00, it is marked as a first save's cluster, but contains neither header nor allocation table.

Datel's card store saves in totally different format. It's not compressed, so parsing it probably won't be a problem.

Internal RAM have a cluster with 64 byte size. Supporting it won't be a problem too, but it's not done yet.

 

...at which point you *will* have to provide the source code if you distribute the binaries, as per the QT license (unless you got a commercial one). Just a heads up.

edit: Also, with MinGW, I believe there's a couple of libraries that can't be linked in statically, so even though you might reduce your dll distribution footprint quite a bit (qt is *huge*) it won't got down to to zero. Don't quote me on this though. Might've confused things with Cygwin.

 

Oh, is that so? Well then, i will include source code into the next update. Some libraries are referenced in the static file indeed, these i included into the zip.

Btw, here's my roadmap: variable file lenght support, variable cluster size support (and variable conversion), datel format support. I intend to test it all the way along , but some testers are surely welcome.

 

Don't just take my word for it - here's a nice human-readable (non-legalese) summary on the qt site. More projects should do that (I've seen a handful but it's still rare).

re: testers - I might have a look and make sure it also works on unices, workload allowing.

 

In one of my cartridges, there was a strange entry with all characters in backup file name set to 0xFF, maybe this was the problem in BUP05.BIN you found.
I though ROM in my cartridges was 512KB sized, but if it's 1MB as you told, I will have to re-dump them ^^;

So do you mean you are planning to support official backup cartridge, internal backup memory, and also Action Replay cartridge ?
Your project looks great ! Please keep the good work :]

 

They are 512KB actually. But they have a 8-bit flash mapped to A-bus as a 16-bit one, with upper 8 bits dangling. I don't know why it is done so, maybe SH-2 or A-bus does not support 8-bit transactions, or 8-bit-aligned transactions. The result is that in the SH-2 address space every odd byte appears as 0xFF (in emulators it might be 0x00 or something else), and every even byte corresponds to the flash's byte with address divided by 2. In other words, the card uses twice the size in the SH-2 address space, and half of this space is just garbage. BIOS is aware of this fact.
But this is not true for datel's card, it is full fledged 16-bit, and no garbage appears in the address space. Maybe this is supported by BIOS, or by datel's resident software.
And i am not sure if big cards (8 MBit and higher) are 8-bit with garbage or full 16 bit, since no official cards were made bigger than 4MBit. But i heard sowhere that BIOS supports up to 32 MBit cards.

 

Thank you for the detailed explanations

The fact that backup memory appears as 0xFF+Data is probably because that 16bit chips were too much expensive at the time Saturn was developped, and also because modifying Saturn hardware in order to cast 8bit device in 16bit bus was too complex/expensive at that time.

There's no special trick required on Saturn side : this is just because two 8bit flash chips are used in Datel cartridge : one chip for even byte, the other chip for odd bytes

It depends on cartridge type. Basically, cartridge that need to boot (Datel, Memory Cart Plus, etc) are full 16bit, while backup cartridges are only 8bit.

Yes, CS0 have 32MB (16MB*16bits) memory space, but I don't know if such huge cartridge exist.

 

Well, here it is, a github entry for the project:
https://github.com/hitomi2500/ss-save-parser

What is done:
-some bugs fixed
-code is polished a bit
-support for variable image size and cluster size added
-interface is simplified a little.

Still have a Datel format to go, save editing support (change name/comment/date/etc, not sure if this is needed at all), maybe hardware interfacing. And testing, of course.

thank you for pointing out LGPL issues, that somehow motivated me to publish sources quickly.

can you please dump memory card plus with some other saves? That might give me some additional info.
It looks like i can extract saves from that image, but some things are yet to be found, for example where is the allocation table or whatever datel uses. And saving in datel format might prove difficult too, since i have no real hardware to debug it with. So i will only implement "import" feature for datel now.

 

Here's the memory card I dumped back in November or so:

https://mega.co.nz/#!dgUQRBwR!_z_OEs8dw9ZrPsY_1p-AKYXx8IC1GWP__7WguBUF1kw

The archive includes all the saves manually extracted. I used a 32-byte header for them, which lists the necessary filename, comment, date, language etc, basically every piece of info except the sector pointers. I had to write my own rudimentary tool to extract those, so if you could double check each save with your own tool for errors, that would be appreciated.

I could not get your app to save in a matching format - seems the only difference is that I included two bytes of null terminators from the sector addresses, just so the header comes out to a handy, even 32 bytes.

Also, some bugs:
- for a game save that has more sectors addresses than what fits into 1 sector (ie. the sector address table is larger than 256 bytes), extraction will fail: it will not read any of the later addresses, AND it will include the addresses in a later sector as save data. Try to extract the Sim City 2k save, and you'll see the problem.
- the 256 <-> 512 converter crashes
- the 00s in the file comment column are displayed as mojibake.

Some other suggestions:
- ability to display all sizes/addresses in hexadecimal.
- sorting by clicking on the top of each column.
- default sorting according to some criteria like name or date or the "counter". Right now it just lists saves in the order their headers are found.
- ability to resize the column view window, to eliminate scrollbars. Or even, make it automatically resize, as you resize the window of the entire program. Right now you just resize and everything stays static, which makes it pointless.
- under the extraction setup, list the file size of each section.
- a bit personal: ability to add the two byte null terminator to the end of the header, so the app can extract saves in the format I already have them (since I have a Saturn program that can write those back to a memory card...)

 

I dumped my memory card plus around 2-3 years ago, and I don't have the hardware to redump it. Sorry.
However, I can try to add some save data by using emulator. Please let me know if you want me to add save data by using emulator.

 

Notice taken. Sorry for my double posts.

Is it just my connection, or is this link dead?

Got it, will try to fix it soon.

Fixed in release 0.9 on github

I thought about it a little, and just added a duplicated bytesize column in hex. Other columns imho are hex-unrelated. Any comments on this? Should i maybe add binary positions of first cluster?

Done in current github source, no release yet. Still not fully completed, since sort order is not indicated yet, and there is no "unsorted" case.

Done for name, as on saturn, in current source. But it doesn't reset after file load. Shoud it?

Oh, thanks a lot for pointing this out, it should be in bug section. Fixed in source, no release yet.

I will think about it, thanks. It looks pretty uninformational indeed.

Okay, i will do it while rethinking extract/insert setup.

No problem, i can do import with that dump alone. And if that import feature fails for someone, that would mean that this someone guy does have another image. That's when i will contact him to get it further debugged.
As for emulator data, that might be useful, but not necessary at this point. Do as you like ^_^

 

Works fine on my end.

The point would be so it displays the same value that you see if you open up the save cart in a hex editor, making it easier to identify parts of the data. So it would be helpful for that 4-byte sector header counter thing, for the date, the filesize, etc.

There are arguments for both reseting it and not. Can't really make a suggestion other than adding an option for it, but that would be the most complex way.