Progress on N64/GBA save support?

[Zerker]

Hello. I was just wondering if there has been any support for EEPROM/FRAM/whatever else for N64 and GBA games? It may not be quite as trivial as the existing save ram support, but a quick Google search should be able to pull up the specs for any chip in question. For example, "Game & Watch Gallery 4" has an MB85R256:
http://www.datasheetcatalog.org/datasheets2/15/157103_1.pdf

Which doesn't look too difficult for the Retrode to support. Read-only support would be fine as a starting point, as there are quite a few games I'd like to be able to resume my on-cart progress.

If you are a bit too busy, I also have some embedded development experience and would be willing to help out here.

[neora]

This is the only reason I haven't got myself a retrode yet.
The ability to dump ROMs or play carts on an emulator isn't something I need, but the retrodes ability to backup my saves is invaluable.

If N64 and GB(A) save backup support was added it would be an instant purchase for me, I really hope this does happen.

[Matthias_H]

The technology is probably manageable, but autodetection isn't. For any game, you'd have to look up the technology (Memory Pak, SRAM, Flash, EEPROM) as well as the memory size by hand, and tell them to the Retrode prior to accessing the save data...

[neora]

I'd be happy even without auto-detection, you can't have everything.

Manually selecting save types and sizes is a small price to pay to be able to backup and restore N64 and GB saves.

[Zerker]

I found some information that may be helpful for the autodetection:

http://nocash.emubase.de/gbatek.htm#gbacartbackupids

Apparently backup ram type is often encoded into the ROM as a String, which the Retrode should be able to locate. That said, scanning the ROM for the string may increase detection time considerably...

[BrentNewland]

The technology is probably manageable, but autodetection isn't. For any game, you'd have to look up the technology (Memory Pak, SRAM, Flash, EEPROM) as well as the memory size by hand, and tell them to the Retrode prior to accessing the save data...

Sorry to bump an old topic, but couldn't you create a database with this information manually and feed the necessary information to the Retrode? I'm assuming the game itself is recognizable, so you could have the Retrode simply load the ROM as usual, and if the (to be made) Retrode software is running, it can look up the game, send the info to the Retrode, which will then load up the save info and present it alongside the ROM.

[Matthias_H]

Sorry to bump an old topic, but couldn't you create a database with this information manually

Someone surely could. I couldn't, since the Retrode project is by far not lucrative enough to become my main occupation.

[BrentNewland]

I'm sure a database could be community made.

You said that to do these saves, you would have to send the Retrode information such as "Memory Pak, SRAM, Flash, EEPROM, and  memory size". If the Retrode firmware had some way to receive this information from the PC, someone could write a program (heck, I could do it, even in an odd language like PHP) to read the ROM, look it up in such a database, and automatically send the necessary information to the Retrode. It could even run as a Service or Daemon.

Some of this information is available. This site has a list of games with the save type, save size, and game CRC for several consoles (specifically the GB based handhelds).

For the N64, this site has a list of N64 games and the save method and size used by each game. And the N64 is known to use the following save types: "EEPROM (512 bytes), 4X EEPROM (2Kbytes), SRAM (32Kbytes), FlashRAM (128Kbytes), and the Controller Pak (256Kbytes)".

Any games that are missed can be researched and submitted by users or volunteers.

The same tool could be used for NES cartridge. As suggested in this thread, Retrode could read the first PRG ROM bank and list it as a file in the Retrode drive interface. The hypothetical software does a CRC check on the 16KB PRG file, looks it up in the database, and if found, sends the necessary information to the Retrode for it to read the cartridge properly. Databases containing info on NES cartridges is available here and here, the time consuming part would be creating the CRC/checksum/hash list to match to each game. Users would have to be presented with a list of known games to choose from and be given the option to submit the 16KB PRG CRC, and the option to choose their own memory controller and chip size for games not on any list.




I believe the biggest technical difficulty was limited storage in the Retrode for information like this, having it done through the PC would eliminate that problem.

What I would need to create such a hypothetical program is config options for "save type" (flash, eeprom, sram, etc.) and "save size". If those are available, creating the software to do everything else is at least possible.

And for implementing NES support, you would need to expand the "forceMapper"  to cover the different memory mappers used in the NES, the "forceSize" would probably need to be like the GB/GBC (pages, since all NES chips should be a multiple of 16KB), and the firmware would have to make available to the PC the 16KB PRG file (for checksum purposes). On top of programming the firmware to support the different MMC's/mappers, but there are resources online (particularly those geared towards Kazzo and USB CopyNES, and the NESDev wiki) that should help with that.

Besides all that, there would need to be some way to let the Retrode know to reload the config file after it's been updated and reprocess the cartridge. Like writing a blank file named "reload" to the Retrode drive.



If you could provide those options (and if I had a Retrode with the necessary adapters) I don't think I would have any problem creating the software necessary to automatically give Retrode the necessary information to access these cartridges and saves.


/edit Wouldn't even need a Retrode, almost all of the program I could write blind, only part a Retrode would be needed for is to verify the checksums the hypothetical program creates are the same as those from other sources, and there's at least one user who knows PHP, has a Retrode, and has expressed interest in exactly this.

[Matthias_H]

We've attempted a few things along the lines of community databases, and experience shows that we're far below the critical mass that it takes for such efforts to take off.

That said, if you want to give it a try, why not? I'd suggest using the four-character game code, which is readily available in GBA and N64 headers and would save us from having to compute a checksum across the entire ROM.

At the end of the day, _someone_ must implement savegame access on the device end, and as sad as it makes me, I simply don't have the time to do any development in the foreseeable future.

[MasterOfPuppets]

May this help in adding N64 save support? He has an account on ASSEMbler.

http://themanbehindcurtain.blogspot.de/2013/08/n64-sramflashram-results.html
http://www.assemblergames.com/forums/showthread.php?53492-reading-writing-save-RAM-on-Nintendo-64&p=773179&viewfull=1#post773179

[justin89]

I'd like to see save support added for the N64 and GBA plugins.

As mentioned above, it's possible to search the GBA ROM for the codes that specify save type. Some games have two or three of these codes, so that isn't perfect. Here's another site on the header info that also includes links to MAME and VBA-M databases with GBA cartridge ID and save type.

N64 uses four cartridge save types: SRAM (32kb, possibly some with 64kb or 128kb?), EEPROM (4kb or 16kb), and FRAM (128kb).
I don't think the N64 ROM specifies the save type (does it?), so use a lookup table of game ID and cartridge save type, with an option for save type in case the cartridge uses a different save or isn't in the table. I found several sites that listed product IDs and save types of N64 games and made a largely complete table of US games and their IDs and save types. I attached that table to this post.

[justin89]

GBA uses several save types: SRAM (seems to be 64kb for most, though I have several 32kb SRAM saves too), EEPROM-4kb, EEPROM-64kb, FLASHRAM-512kb, and FLASHRAM-1M.

I went through the MAME database and collected the game IDs and save types. I don't think the list is completely accurate, because I noticed some errors and games with missing save types and corrected them. I attached the table I made. Besides that, an option to manually select the save type is helpful in case of a different save type or missing ID.

[Matthias_H]

Oh, we all would love to see that implemented. Are you a programmer?

[justin89]

Not full-time, though I can program. I'd be happy to write the N64 and GBA save functions myself if that's convenient. As long as I can compile and test dump functions quickly I think I can figure out how to read and write the saves. Only problem I see is I don't have a full library of games to check if I made functions for all the mappings.

A while ago I did something I think is similar to this. I played around with the Kazzo NES programmer, which is like a Retrode for NES games, and was able to modify a save function to dump saves for several unsupported NES games. The Kazzo NES uses a program which makes you select a script to read the ROM or read/write the SRAM, so I was able to copy and modify another script until it worked with my games. All the code had to do was change a byte to enable the save RAM and turn off write protection, then read/write the save from the correct location with the correct length. I don't know if GBA or N64 has any more complicated mappings than that, but there are already save dumpers for GBA and I doubt N64 is any more complex.

After reading and writing saves works, the next step is to check the game's header and refer to a lookup table so it knows which save type to use. Then, I'd like there to be at least an option in the config file to select the save type manually. If there's a way to use a custom script, that would be better in case there's a game with an unsupported save mapping (like SNES Brain Lord).

[justin89]

I'll see if I can work on the save support myself. If anyone else works on this, the source codes posted above for the N64 saves should help, and I found this program with source for GBA saves.