Sega Saturn RAM backup parser

As a "20% hardware, 80% software" guy, I'm not so interested in making the hardware part even more difficult

I'm not interested in SD card support via serial connector.
And unfortunately, it wouldn't be as simple as SD card hack for dreamcast : it would requires some or some conversion hardware.

 

Another option would the the Serial Cable from the Sega Saturn Game Basic Kit. It allows you to connect your Sega Saturn to a PC and download programms written in Basic. Probably it's possible to transfer files back to the PC via this cable.
http://www.satakore.com/sega-saturn-game,,T-2111G,,Game-Basic-for-SegaSaturn-JPN.html

I'm sorry if I'm a bit offtopic. I'm just looking for a way to backup my Sega Saturn Memory Cards. The official floppy disk drive is rare and expensive.

 

There's always an option to desolder flash and read its content with an ordinary prom/flash dumper with TSSOP32 adapter. If you don't own one, and don't have a local geek to do the job for you, you can ask people who dump roms/carts/bioses etc here or at another hardware-related forum.

 

With a USB DataLink, you can dump (backup) both internal memory, and the entire contents of an Action Replay Plus cartridge. http://www.gamingenterprisesinc.com/DataLink/

 

I WANT ONE NOW!!! Is it already cloned?

 

Wow!! A new SegaSaturn save manager!! That's super nice!! The only save manager for that system I knew was the SEGASATURN BACKUP MANAGER.

Can I make some suggestions?

1. Like commented HERE, the SSBKM have the "ability" to restore deleted saves (note: it don't work in save files from emulators). This same "ability" can be added in your Sega Saturn RAM Backup Parser? You can do the test using THIS SAVE FILE extracted using the SegaSaturn DataLink (use the 64 Cluster Size to load this file).
   
   
2. A more obvious memory counter could be added, showing the total of blocks, the used blocks and the free block remaining free block of each memory file...
   
   
3. The option to import and export each individual save is super nice, but it could be even better if, instead a RAW file, a container file (with an proper extension) can be created to backup individual saves. A container file can store the RAW file, a comment (up to 64 characters) and, if possible, an icon (PS1 format). This could help a lot to backup saves in a more organized form, put comments of the save content (even to point if it is a hacked save), and import/create icons (with animations?) to ilustrate the save content, even importing extracted icons from PS1 saves where the game have a SegaSaturn version. This addition can offer export for both RAW and container-format files with individual buttons, and auto-detect and load the format when you try to import the file. When you try to export a save in container-format, a new window can open to put the coments and icon, and when you try to import a container-format save, a window could pop up to show the info of the file before the import operation, with Import and Cancel buttons.
   
   
4. I notice you can edit some contents of the files, like name, lng. code, date, etc... But it is totally free to change these info!! You can edit the date with letters, for example. Could be nicer if the program could do some edit limitation. For example, to edit the save name and description, could have a limit of characters (I don't know the number of characters can store at max) and beep if you try to exceed the number of max characters, the language code could show a drop down menu with the possible options (with comments), the date could just enter proper date information, with reserved spaces (example: __ - __ - __ __ : __ ) and beep invalid entries, and even lock content who are not possible to change in this way, like bytes, blocks, cluster, etc...
   
   
5. Add a "Save as..." button to, if we wish, not overwrite the original file with the alterations we can do, or pop up a windows asking what you will do with a file who was modified (overwrite, create a new file, or cancel) when you click in the Save button.

I hope it these suggestions can have some use in a future update.

Wow!! That's a super cool device... I noticed there's some batteries in your SD Reader device. The controller port don't supply the necessary power to make the adapter work, or it's just a prototype, and the final device will be battery free? If you finish this project and put the adapter battery free, I will want one...

This device will be unique because we will be able to backup any type of Backup Cartridge...

The DataLink is an amazing piece of hardware (I have mine). The main point in this device is you can backup saves from a non modded console. The other ways will need a modded console to run CD-R, or to use the Rhea/Thea, to be able run the needed SegaSaturn software...

 

x

 

Thank you for your suggestions. Currently i'm busy with a hardware cart projects (wasca and SAROO), but i will return to the program development, to support interfacing with wasca directly via USB. I might implement some of these suggestions then.
1,4 and 5 i'm adding to the roadmap.
For 2, "block" itself is a bit of a strange concept, invented by Sega without being related to real hardware. The "free" value shown in BIOS i suppose is how many 64-byte chunks of raw data can you save, if you're saving them as a single file. For example, it is 461 for empty internal memory (SRAM has 512 clusters of 64 bytes, 2 used as markers, remaining 510 can hold 461*64 bytes of data, 477*2 bytes of allocation table (allocation table uses 16 clusters, and they're allocated in allocation table too), and 32 bytes of header, that's 30490 bytes, or 509*60, because every 4 bytes in cluster is used by system). But if you fill the whole internal memory with 28-byte save files, you can theoretically get 510 of these 1-block saves, or 510 blocks. And if you do the same with 29-byte saves, you get... surprise, surprise, only 255 1-block saves, because they don't fit into single cluster with header and table, so they use 2 clusters each. But they're still 1-block, because the size of the raw data is less than 64. So you can get quite a different size in blocks, depending on how big are your files. Do you see how bizzare this "blocks" are? I'm showing file sizes in blocks just for BIOS compatibility, but i'm not sure if i should adopt this concept futher, like showing free blocks, because it's simply confusing. Currently my free space indicator (bottomleft corner)is based on clusters usage.
As for 3, the idea of container is very interesting but there are a few things that should be discussed here. As Druid II pointed out, they'll cease to exist when saves are inserted into image for real hardware. So this feature is mostly for self-notes and for emulators. More than that, container can contain multiple save files, especially if it's XML (i honestly like the idea), and we can convert whole image into single container and vice-versa. And emulator can inject additional data, screenshots, etc into this container automatically.
What bothers me is that creating such a format might be not a very good idea. I'm not very good at creating RFCs (never made one actually), and i may be wrong in some key aspects. So question 1, does ever anyone heard about "standard" game save file container, and question 2, if i'm to make my own with BJ and hookers after all, who should i consult about it, excluding the obvious list (yabause team, ssf author) ?

 

Thanx for the answer, guys... Just to make some points clear.

• The container idea is just to better organize the saves. It will be useful to share saves online and don't miss the file into a big, irreversible mess. Once we need a program to restore a RAW file into the save file again, the same program can do the job of detect if the file is a container and restore just the needed information, and discarding the unnecessary content for the SegaSaturn (comments, icon, etc...). There's no need to add other things like screenshot, once we are talking about save files, not savestates...
  
  
• The icon idea to the container info can be discarted for sure.
  
  
• The Block thing is just to noobs, like me, have a better idea how the saves are represented in the real hardware.
  
  
• The main purpose in the suggestion #4 is to avoid any problem when editing the information of the save and risk to corrupt it. The part of limitation to rename the name and comment of the save file is for the case if an user want, for example, modify the comment of the save because it is in japanese, and don't exceed the number of characters displayed in the SegaSaturn. It have nothing about the comment of the save in the suggested container file. They are two different things...
  
  
• About the example of a container save, I haven't heard nothing about it from a standard save format, but there are a save backup format for PS2. This format is the .PSU save. It's a container can store information who can be lost if you try to extract the files under Windows format. Most of the PS2 games don't use such information, but games like Metal Gear Solid 3 looks for these informations, and if these informations are not present, it will result in a corrupted file message. The Unnoficial Launch ELF program can copy the save folders of the PS2 Memory Card directly, with the risk of lose data, or save them in .PSU format, perserving all information without losing nothing. But I don't think it can be case...

 

I didn't verified if power supply was enough or not. When I made that prototype, I wanted a 3.3V power source, and didn't know anything about step-down power regulator, so I used two 1.5V batteries, which fed my SD card enough in order to dump my cartridges.

 

By the way. satakore database contains a lot of saturn titles with downsampled cover images. It's certainly possible (but maybe illegal) to use these images to auto-generate icons. The only thing user have to supply is product number. It's right there on the box, and also in the CD boot area. So just typing the PN, or inserting game CD into your windows PC will get you correct cover-based icon.

 

I have a question... What is "Lng.code"? It's the region game code of the save? If yes, the numbers represents the region's code? Which is the possible code options?

 

It is a 1-byte language code, 0 means japanese, 1 means english, other possible values are unknown to me. It is not a 4-bit region code SMPC reads from jumpers.
I've heard from Druid II about saves with other values, quite big ones like 250 or something, but i don't know if they're valid. My own saves never had anything but 0 or 1. But then again, i never played anything in other languages.

 

x

 

I got a save file with Croc's save, and the code of this save is 60. You can check it in THIS SAVE and THIS SAVE. Super strange...

By the way, 0 is for japanese and 1 for USA. The 1 value is just for USA games or for Western games (USA, Euro, etc)?

 

x

 

Sorry, looks like i did. First versions of the program were hard-limiting language code to values from 0 to 7, and you pointed out that bug.

It is a language code, not region code. There were 7 different localisations of Croc published (JP, US, UK, FR, DE, SP, BR), with 4 regions (JP,US,EU,BR), i suppose you have the brazilian one (you can check this looking at product code, brazilian is 191X58). Which languages do you have available in game (english? portuguese?), and which one did you actually used when saving?

 

x

 

Croc US and EU versions have the same product code on the CD indeed (T-5029H-50) , but the data is a bit different. For example, US version is allowed to run on US, JP and EU consoled (judjing by compatible area symbols and area code groups in boot area), but EU version have only EU region allowed. JP version have a totally different product code (T-26410G), and only JP region.
All this looks like a US publishing mistake, they took EU version and only added another region (actually two, but who cares?). For BR version, i cannot say anything.
rouken, is your croc CD a brazilian one? Can you please look at the boot area for product code and regions? Simply dump first 128 bytes of the CD, they're all there.

 

I don't have a Croc disc. I get the save from the DATALINK page just to test the save managers and found this case. Probably this Croc save is from the euro version, once the creator of the Datalink lives in Europe (I think...).

In Brazil, most of the games for SegaSaturn are US based (if not all)... I don't know if there's some specific Saturn game with a BR code. The most obvious supposition of a game with this code is Myst, once this is the only SegaSaturn game with a PT-BR translation I have know... But I don't have this game, so I can't say it for sure...