What is the save file format?

[euan-forrester]

Hello, I'm the author of savefileconverter.com (https://github.com/euan-forrester/save-file-converter) and I was hoping to add support for Neon64 save files.

I'm not very familiar with assembly, so I wasn't able to get too much information from looking at the code other than that there appears to be a header and footer attached to each file?

Would it be possible to please explain the format so that I could add support for converting to/from these files?

Thanks very much!

[hcs64]

It's somewhat of a cut-down version of a full savestate format from a fork of 1.2, thus why it starts so far into the address space. This is the portion used in 2.0:

0x10000-0x10003: 0x79783B4A
0x10004-0x10007: 0x985626E0
0x10008-0x12007: battery backed RAM
0x12008-0x1200B: 0x0BDFD303
0x1200C-0x1200F: 0x4579BC39

I've attached some example saves from an ED64.

[euan-forrester]

Thank you for this!

Looking at the example saves you provided (and the one I made myself, also on an ED64), it looks like that signature you mentioned of 0x79783B4A then 0x985626E0 is present before the SRAM data in each file, and 0x0BDFD303 then 0x4579BC39 is always after in each file. Am I correct in understanding that this is the case for all flash carts (or any other ways of running Neon)? So when converting from the Neon format I can look for those signatures and avoid having to assume all games have an SRAM size of 8kB? (even though I think every game I've seen so far has that size)

Then when converting to the Neon format, it looks like I can just pad with 0xAA before and after these signatures? Or is there anything else that I should do there?

Thanks again for your help and I'm looking forward to adding this to the site!

[hcs64]

Yes that should be the same for any method of running Neon64 2.0. The AA is just what the ED64 initially fills SRAM with, 2.0 doesn't look at the memory outside of 0x10000-0x1200F at all so it shouldn't matter what it is.

I might want to change this format, though, since it doesn't make a lot of sense. I looked back over the "with savestates" fork (the SRAM save stuff is in 64drive.inc), it looks like I screwed up my intended backwards compatibility with that. It expects the header at 0x0 and the footer at 0x2010 for a normal battery save from 0x8-0x2007; for a complete save state it instead puts the footer at 0x8000+0x7E60. I was thrown off because there's a different in-memory layout, but I thought I'd tested it... might have been fooled because they don't write to the same regions so there might have been old data at that location.

[hcs64]

Re: SRAM size, Neon64 doesn't support any size other than 8KB, so I wouldn't recommend searching for the footer. If I eventually support different sizes, I'll change the header so the size is stored explicitly.

It is pretty rare to have a different size, usually it's because there's an EEPROM instead of battery-backed RAM, the most common examples are the Bandai FCG boards, none of which are supported in Neon64. These are only specifiable with a field in the the NES 2.0 header.

[euan-forrester]

Okay awesome, this all makes sense -- thank you! I'll just hardcode the SRAM size, and throw a "file is not in the correct format" error if the header/footer aren't found. And I'll pad with 0xAA just to keep the files looking consistent, even if it doesn't matter.

If you do decide to change the format, please keep me in the loop! I'm happy to add logic to detect and convert from both an "old" and "new" format, and then maybe just convert to the "new" format. I did that for files from the Mega SD Genesis flash cart, since they changed their save format somewhere along the line with a firmware update.

And, thank you for the info about EEPROM saves -- I didn't know they had those on NES. I should go and do some tests with those games on different flash carts/emulators.

[hcs64]

For my own notes here's the non-8K sizes I've found for licensed games, searching through the Nesdev wiki, a no-intro romset, and NesCartDB:

Serial EEPROM

• 128 bytes (Bandai FCG, 5 games)
• 256 bytes (Bandai FCG, 6 games)

Battery-backed RAM

• 128 bytes Taito X1-005 (5 games)
• 2K Family Circuit '91 (Namco 175)
• 2K Startropics and Zoda's Revenge: Startropics II (HKROM)
• 2K Family Basic (NROM)
• 4K Family Basic V3.0 (NROM)
• 5K Taito X1-017 (5 games)
• 32K SXROM (2 games)
• 32K EWROM (5 games)

This doesn't include other ways of saving, for instance battery backed CHR-RAM and Namco 163 wavetable.

[euan-forrester]

Awesome, thank you! That's super valuable and I'll add that to my notes for new tests to add -- especially Startropics 1 & 2!

[euan-forrester]

I've added support for this to the site!

Code: https://github.com/euan-forrester/save-file-converter/blob/main/frontend/src/save-formats/FlashCarts/N64/Neon64Emulator.js

Implementation: https://savefileconverter.com/#/flash-carts

Thank you again for your help!