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.
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.
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...
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.
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...
Quote from: Matthias_H on 10/Jun/2013 06:07:21 AM
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.
Quote from: BrentNewland on 27/Jan/2014 05:32:03 AM
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.
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 (http://www.advanscene.com/) 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 (http://www.elitendo.com/n64/usa_boot_save_list.html) 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 (http://forum.retrode.org/index.php/topic,66.30.html), 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 (http://bootgod.dyndns.org:7777/) and here (http://tuxnes.sourceforge.net/nesmapper.txt), 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 (http://forum.retrode.org/index.php/topic,66.msg520.html#msg520) who knows PHP, has a Retrode, and has expressed interest in exactly this.
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.
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
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 (http://zork.net/~st/jottings/GBA_saves.html) on the header info that also includes links to MAME (http://mamedev.org/source/hash/gba.xml.html) and VBA-M (http://sourceforge.net/p/vbam/code/HEAD/tree/trunk/src/vba-over.ini) 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.
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.
Oh, we all would love to see that implemented. Are you a programmer?
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).
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 (http://chishm.drunkencoders.com/SendSave/) with source for GBA saves.
If this works everyone is going to want one of the adapters, and I believe it's sold out now. Wish I bought one too. :(
I'm still itching to be able to test any firmware for this when someone gets one ready for testing for dumping N64 saves (and hopefully writing them back to the cartridge as well). I have a decent number of N64 games with various saves types that I am willing to test with. I would be happy even if we have to manually set the save type in the config file for each cartridge just to be able to dump the saves as I think this will make the Retrode the first device since the Doctor 64 to be able to dump all N64 save types if it works.
A Retrode user just contributed some code that can read GBA/N64 saves - but it hasn't been merged into the firmware yet. We'll have to give it some time to make sure we don't break existing functionality.
Quote from: Matthias_H on 22/Jan/2015 06:40:23 PM
A Retrode user just contributed some code that can read GBA/N64 saves - but it hasn't been merged into the firmware yet. We'll have to give it some time to make sure we don't break existing functionality.
Let me know if you need any help testing or regression testing that. I have the Retrode 2 and all of the plugins from the manufacturing run, as well as a wide variety of carts - and in particular, plenty of N64 carts that have been patiently waiting for the day save read support would be available :)
Diddo with starlightknight though I didn't get the SMS plugin as I never had a need for it but I've been itching to play with N64 save support since I found this thread. I'm willing to test any firmware if a new beta is available for it. It's just a shame that there is so much time between updates.
I also would.
I hope this update becomes available soon, I have Oracle of Ages and Oracle of Seasons I want to backup the save data on.
The contributed code does not fully support all types of savegames yet. It's as far as the author got. There are still problems such as save data corruption. Some of the code changes might be breaking other features.
AFAIK, nobody is currently working on those issues. I'm busy with the NES plug-in.
Sad to hear. I've been checking this forum periodically for a number of years now waiting for this functionality to be added. I bought the N64 plugin when Dragonbox got another shipment in and have been patiently waiting ever since. Hopefully the batteries in my N64 cartridges will outlast this process.
Quote from: Amitari on 06/Nov/2015 04:49:27 PM
I hope this update becomes available soon, I have Oracle of Ages and Oracle of Seasons I want to backup the save data on.
FYI: Those are both GBC games which are already supported. I should know, I've backed up my Oracle of Ages save AND transferred it back to the cartridge.
Isn't part of the difficulty with accessing N64 saves in getting the file out in a form where an emulator can use it? The Gameshark method (see, e.g., https://www.kyleniewiada.org/blog/transferring-n64-saves/) involves visually inspecting the save file and using a hex editor to graft the save portion of the file into another file for use by the emulator. However, wouldn't it be easier for the Retrode2 if one were only concerned, for example, with simply copying from the cartridge and writing back to the cartridge the save file in the exact format as it is used by the N64 console for backup, without concern for whether an emulator could use it? That is the case for me, where I only play the games on my original console, and want to be able to use the Retrode2 to back up the save files for games where the cartridge uses battery-powered SRAM. Then when the eventual day comes that the cartridge battery dies, I would replace the battery and use the Retrode2 to copy the save file back into the cartridge. For me, some of this is for sentimental reasons - I have backed up the SNES DKK save file where my son (now grown) and his friends pulled an all-nighter to open up all of the levels, and the file where my nephew accumulated a huge fortune in SNES Vegas Stakes as the character 'Mr. Love', and would like to be able to do the same for the N64 Zelda Ocarina of Time save file that my son and I completed together. Not a programmer myself (patent lawyer), so please forgive any ignorance on my part.
Quote from: pmarshall on 26/Jan/2016 10:25:46 PM
Isn't part of the difficulty with accessing N64 saves in getting the file out in a form where an emulator can use it? (...) However, wouldn't it be easier for the Retrode2 if one were only concerned, for example, with simply copying from the cartridge (...) in the exact format as it is used by the N64 console for backup (...)
It's not about the format. If we end up with something that requires you to use a hex editor, we'll happily release it.
The difficulties of getting N64 save support to the Retrode include:
- N64 cartridges use several different technologies to store saves. Each needs individual support. AFAIK, there is no way to auto-detect which save technology a cartridge is using.
- Lack of qualified personnel.
- Lack of time.
See also reply #22 (http://forum.retrode.org/index.php/topic,154.msg2070.html#msg2070).
I'm surprised so many want to carry their saves to their emus. I thought the vast majority just wants to back up their carts for future use and occasionally to change out the batteries in the carts.
Well, maybe they want to continue their progress when they have time, not specifically at home with their systems. For example, maybe the person want to finish their OOT game during their lunch break at work. An emulator would be the logical choice.
My motivation for wanted saves backed up is simply to future proof them. The cartridge batteries aren't going to last forever.
I also simply want to back up the SRAM based saves. I can use the Gameshark64 to back up some of them, but that thing is buggy and prone to failure. It also can't get at the saves for the WCW games, which I care less about but what if I want to replace a battery for someone else, someone who really cares about their WCW save?
Yeah I've always been saying I think a Retrode that does only backup and restore of saves and promoted as such exclusively would be a huge huge hit, especially in these years where gamers are becoming aware of retro games having dying batteries and many have started replacing them
This is the biggest draw to Retrode for myself and the N64 community I think. I'd love to hear where that firmware went.
Quote from: Matthias_H on 22/Jan/2015 06:40:23 PM
A Retrode user just contributed some code that can read GBA/N64 saves - but it hasn't been merged into the firmware yet. We'll have to give it some time to make sure we don't break existing functionality.
2017 bump and progress inquiry
Any luck on the firmware update? Also, has anyone tried to do a Master System backup as well (need it for Phantasy Star!)?
Sorry, nothing has changed since reply #26 (http://forum.retrode.org/index.php/topic,154.msg2130.html#msg2130).
Also, this is not the top item on my list. In the past six months, I often thought about at least trying to merge the simple pieces that work (according to justin89). But I didn't even get close to having time for that.
nuts
I'm in the same boat. Been waiting years for this or any other way I could back up my N64 cart saves and play them on an emulator. I backed up what I could using a DexDrive/Gameshark 3.0 but it only works for eeprom and AFAIK still no way to get those saves working on an emulator.
Hopefully one of these years someone comes up with something before my carts start to rot lol
The Arduino Cart Reader can backup all of your N64 saves.
Current build info is here: https://github.com/sanni/cartreader/
Project started here: https://forum.arduino.cc/index.php?topic=158974.0
All of my SNES enhanced code that was recently added to the Retrode started on the Arduino reader.
Since many people have asked about the N64 saves, I took a look at the SRAM and it is possible to read out the saves. The timing used to read out the save data seems critical so it isn't working 100% perfect at the moment. If I can get the routines right, then I'll open a new BETA firmware test.
N64 cart SRAM reads are working. Added a lookup table to identify the SRAM carts by cart ID. I still need to add Dezaemon 3D's large SRAM then I'll be working on the SRAM writes.
N64 SRAM save support is complete. I'm sending out the BETA firmware to the members of the test group.
Really appreciate the work you put into this!
If you want to use your SRAM save in the PJ64 emulator, then you'll need to save swap the file.
You can use saturnu's ED64-Saveswap program: http://krikzz.com/forum/index.php?topic=1396.0
If have an Ocarina of Time save and want to check it without using an emulator, you can use this page: https://bkacjios.github.io/OOT-Save-Converter/
After saveswapping the OOT .SRA, then use the first option "Import save file". The save data will show in the bottom. Click on the File# to see the details on each save slot.
I'm going to work on adding FlashRAM save reads.
I've been a long-time lurker of these forums, but I just registered to say that I also really appreciate the work you're putting into this! Can't wait to backup my N64 saves with the Retrode :) The enhanced SNES support sounds terrific as well. Keep up the good work! :D
Thanks!
Quick update. FlashRAM save reads for both flashtypes (old and new) are working.
I don't have all 3 types of flash chips as I'm missing a MX29L1101 cart. I did test a MN63F81 flash chip which is the same category (new flash) as the MX29L1101. I'm hoping that one of the testers has a MX29L1101 cart and will be able to confirm the operation.
I'm moving on to see if I can implement the FlashRAM write code.
Do the different RAM chips have different read / write algorithms? I thought all 3 were interchangeable on the PCBs
FlashRAM is controlled using the status register and command register. We don't see the actual programming algorithms. I've never disassembled an N64 ROM but I would assume that the program identifies the flash type based on the chip ID and adjusts to match. This is what I do in the Retrode firmware.
There is a difference in how the data is addressed. The new flash (MN63F81 and MX29L1101) can be addressed identical to the SRAM. The old flash (MX29L1100) uses 128 byte blocks which presented a problem on the Retrode. I had to shift the addresses for the old flash in order to read out complete blocks.
Quote from: skaman on 23/Aug/2017 06:03:13 PM
FlashRAM is controlled using the status register and command register. We don't see the actual programming algorithms. I've never disassembled an N64 ROM but I would assume that the program identifies the flash type based on the chip ID and adjusts to match. This is what I do in the Retrode firmware.
There is a difference in how the data is addressed. The new flash (MN63F81 and MX29L1101) can be addressed identical to the SRAM. The old flash (MX29L1100) uses 128 byte blocks which presented a problem on the Retrode. I had to shift the addresses for the old flash in order to read out complete blocks.
Is there a list of games that use old flash, I've only seen the list of US games that support flashram. Have you already released an updated beta or are you waiting until writing is done?
FlashRAM is grouped into OLD flash (MX29L1100) and NEW flash (MX29L1101 and MN63F81). The most common flashram chip is the MX29L1100. The least common chip is the MX29L1101.
sanni attempted to gather the FlashRAM info from users across various forums. He posted a list and updated it as users responded. The effort eventually died when we looked at the results and realized that Nintendo could use any flashram chip in any cart.
Here's the last list that I'm aware of. Please don't take it as the definitive list as the sample size was small and, as I mentioned, the effort died pretty quickly.
Animal Crossing
29L1100KC-15B0 or MN63F81MPN
April 2001
Command & Conquer
29L1100KC-15B0
May 1999
Jet Force Gemini
NTSC: 29L1100KC-15B0 PAL: 29L1101KC-15B0
October 1999
Ken Griffey Jr's Slugfest
29L1100KC-15B0
May 1999
Zelda Majora's Mask
29L1100KC-15B0 or MN63F81MPN
April 2000
Megaman 64
MN63F81MPN
November 2000
NBA Courtside 2
29L1100KC-15B0
October 1999
Paper Mario
MN63F81MPN or 29L1100KC-15B0
August 2000
Pokémon Puzzle League
29L1100KC-15B0
September 2000
Pokémon Snap
29L1100KC-15B0
March 1999
Pokémon Stadium
29L1100KC-15B0
February 2000
Pokémon Stadium 2
29L1100KC-15B0 or MN63F81MPN
December 2000
Starcraft 64
29L1100KC-15B0
June 2000
Tigger's Honey Hunt
29L1100KC-15B0 or MN63F81MPN
November 2000
WWF: No Mercy
MN63F81MPN or 29L1100KC-15B0
November 2000
No new BETA yet. I'm working on implementing the FlashRAM erase and write code.
N64 FlashRAM support is complete. New BETA firmware is in the hands of the testers.
Received my Dezaemon 3D cart from Japan. My experimental SRAM code for its 768Kbit SRAM isn't working. I'll need to locate the RAM within the address space and correct the masking.
I've gotten reports from some testers that the SRAM and FlashRAM is working for them.
One tester wanted me to mention that the CONFIG setting "[sramReadonly] 1 ; write protect SRAM? 0=no, 1=yes" affects the SRAM AND FlashRAM files. Maybe I should change the setting to "[saveReadonly]"?
Fixed Dezaemon 3D 768Kbit SRAM. Modified the Config file to change "[sramReadonly]" to "[saveReadonly]" since the same setting is applied to all save files including SRAM, FlashRAM, and Controller Pak.
Amazing work!
Quote from: skaman on 19/Aug/2017 06:27:12 PM
If you want to use your SRAM save in the PJ64 emulator, then you'll need to save swap the file.
You can use saturnu's ED64-Saveswap program: http://krikzz.com/forum/index.php?topic=1396.0
If have an Ocarina of Time save and want to check it without using an emulator, you can use this page: https://bkacjios.github.io/OOT-Save-Converter/
After saveswapping the OOT .SRA, then use the first option "Import save file". The save data will show in the bottom. Click on the File# to see the details on each save slot.
I'm going to work on adding FlashRAM save reads.
In case any non-Windows users want an option that doesn't rely on Wine and can be incorporated into scripts, I whipped up a Python-based, GUI-less alternative to ED64-Saveswap:
https://github.com/ssokolow/saveswap
It's got a complete unit test suite and, aside from one minor usability wart (https://github.com/ssokolow/saveswap/issues/1) I need to fix, it works with every save file I tested.
Given that some virus scanners seem prone to identifying EXE-ified AutoIt scripts (like ED64-Saveswap) as viruses, I'll probably put together a simple GUI version (https://github.com/ssokolow/saveswap/issues/2) and py2exe it for Windows users at some point.
I'm still working on the N64 stuff.
A BETA tester brought up a couple preexisting issues with the firmware. The Config file defaults to using ".n64" for the N64 ROM extension when it should actually be ".z64" to reflect the native big-endian format. I'm changing the default to "z64" in the next release. The other issue is that Paper Mario is overdumped. I checked the N64 cart heuristics and it overlooks the 20MB and 40MB sizes. There are only 3 titles affected - Donald Duck Goin' Quackers, Paper Mario, and Ogre Battle 64. This will also be fixed in the next release.
While fixing the missing N64 ROM sizes, I ran into an interesting problem that I need some help with. I picked up a copy of Donald Duck to test the 20MB size. This cart is listed as using an EEPROM4K save. When I tried dumping my EEPROM4K save (not with the Retrode), it refused to respond. I opened up the cart and there is no EEPROM.
Does anyone have a copy of Donald Duck Goin' Quackers/Quack Attack that they'd be willing to open up? I'd like to see if their cart lacks the EEPROM. Either it was an oversight on my cart or else the existing cart save lists are incorrect.
Thanks!
Nevermind on the Donald Duck cart.
I found a picture of the box and it states "N64 Controller Pak Needed to Save Game Data".
The save lists need to be corrected.
This sounds awesome. Been waiting years for this kind of development. Thanks so much.
Seriously, this is really amazing work. We are all counting on you!
Thanks!
I wanted to give an update since it might look like there hasn't been much recent development.
N64 SRAM and FlashRAM save support is fully working. Tested by multiple testers with multiple carts.
I need to finish the cart heuristics code for the missing 20/40MB cart sizes. I modified the code and got Donald Duck Goin' Quackers (20MB) and Ogre Battle 64 (40MB) working. The lone remaining cart is Paper Mario (40MB). I don't have a copy of Paper Mario so a tester volunteered to run multiple tests. Unfortunately, the code that fixed Ogre Battle doesn't work for Paper Mario and I'm not sure why. I'm waiting on Paper Mario and Mario Story carts to arrive to find the solution but it might be a week or two.
While waiting on the test carts to arrive, I started to look into the cart EEPROM saves. I thought I might need to modify the N64 plugin but the production plugin has the necessary connections to read the cart EEPROM. I've got the cart EEPROM responding and outputting the save data (visible on my logic analyzer). I need to tweak the code to get the data outputting properly to the .eep file.
Once the cart heuristics is fixed and the EEPROM save support is complete then I'll release a new firmware.
More testing to do...
amazing, i cant wait.
N64 Cart EEPROM save support is complete. The production N64 plugin supports EEPROM saves. If you have a prototype N64/GBx plugin, then you'll need to add two connections - CLK and S_DATA. I'll post pictures of a modified prototype adapter if anyone is interested.
The next BETA firmware release is on hold pending the resolution of the Paper Mario heuristics code. Once I'm able to fix Paper Mario, then I'll release the BETA to the test group. A public firmware release will follow after the testers have thoroughly tested the BETA firmware.
Quote from: skaman on 15/Sep/2017 07:46:45 PM
N64 Cart EEPROM save support is complete. The production N64 plugin supports EEPROM saves. If you have a prototype N64/GBx plugin, then you'll need to add two connections - CLK and S_DATA. I'll post pictures of a modified prototype adapter if anyone is interested.
The next BETA firmware release is on hold pending the resolution of the Paper Mario heuristics code. Once I'm able to fix Paper Mario, then I'll release the BETA to the test group. A public firmware release will follow after the testers have thoroughly tested the BETA firmware.
sounds amazing i cant wait :D
is there still work to be done on sms saves? from what i remember that wasnt working correctly.
I have no idea on the SMS saves. If there is anything to be done, then it will have to be done by someone else.
I'm sorry to say that I have no plans or interest in working on support for any other consoles. If there was one console that I might eventually work on, it would be the GBA saves.
After I finish the N64 fixes, I'll be going back to looking for a solution for the SNES SA-1 SRAM writes.
:(
Quote from: skaman on 15/Sep/2017 07:46:45 PM
N64 Cart EEPROM save support is complete. The production N64 plugin supports EEPROM saves. If you have a prototype N64/GBx plugin, then you'll need to add two connections - CLK and S_DATA. I'll post pictures of a modified prototype adapter if anyone is interested.
The next BETA firmware release is on hold pending the resolution of the Paper Mario heuristics code. Once I'm able to fix Paper Mario, then I'll release the BETA to the test group. A public firmware release will follow after the testers have thoroughly tested the BETA firmware.
[Insert
fangirlish manly squeal of delight here]
(I've got some old saves that it'll be nice to see again without having to find the time to diagnose my N64's reboot problem.)
Quote from: ssokolow on 18/Sep/2017 12:40:29 AM
Quote from: skaman on 15/Sep/2017 07:46:45 PM
N64 Cart EEPROM save support is complete. The production N64 plugin supports EEPROM saves. If you have a prototype N64/GBx plugin, then you'll need to add two connections - CLK and S_DATA. I'll post pictures of a modified prototype adapter if anyone is interested.
The next BETA firmware release is on hold pending the resolution of the Paper Mario heuristics code. Once I'm able to fix Paper Mario, then I'll release the BETA to the test group. A public firmware release will follow after the testers have thoroughly tested the BETA firmware.
[Insert fangirlish manly squeal of delight here]
(I've got some old saves that it'll be nice to see again without having to find the time to diagnose my N64's reboot problem.)
when an n64 randomly reboots it usually means its overheating
Quote from: skaman on 15/Sep/2017 07:46:45 PM
If you have a prototype N64/GBx plugin, then you'll need to add two connections - CLK and S_DATA. I'll post pictures of a modified prototype adapter if anyone is interested.
I'd love to see the modifications. Still have 6 or 7 of those prototype adapter boards kicking around. Might as well keep them up to date.
Quote from: RazorX2014 on 18/Sep/2017 01:13:33 AM
when an n64 randomly reboots it usually means its overheating
That, or the memory expansion has gone bad, or the power supply block's connection to the console itself is loose.
Those are the three candidates I looked up but I've been too busy resolving more pressing concerns (eg. I just built some new wall-mounted shelving and I need to finish building the first of two wood sheds before winter comes around) to dig up my jumper pack and extractor tool and break out my line-drive ("game bit") bits and try to identify the problem.
Here are pictures of the modified N64/GBx adapter:
(https://forum.retrode.com/proxy.php?request=http%3A%2F%2Fi65.tinypic.com%2F2sbo16p.jpg&hash=f2cf6be9238843d20a5a7d1a766efd098bc864ee)
(https://forum.retrode.com/proxy.php?request=http%3A%2F%2Fi66.tinypic.com%2F2zgyno0.jpg&hash=15444042a1673973c45457de35c0f5a032900901)
Connect the BLUE pins. Connect the RED pins.
(https://forum.retrode.com/proxy.php?request=http%3A%2F%2Fi63.tinypic.com%2F991c43.jpg&hash=c77ed1060374abcf2c4f87d904be6a4b7af2dd9e)
(https://forum.retrode.com/proxy.php?request=http%3A%2F%2Fi63.tinypic.com%2Frhl3ra.jpg&hash=dd1617577f0a403214525ac71c769f0a2a03e8f0)
When I wired this adapter, I routed the wires from the back thru some vias to get to the front.
THIS IS ONLY FOR THE PROTOTYPE N64/GBX ADAPTER. THERE IS NO MODIFICATION NECESSARY FOR THE PRODUCTION N64 PLUGIN.
Quote from: skaman on 15/Sep/2017 11:37:59 PM
I have no idea on the SMS saves. If there is anything to be done, then it will have to be done by someone else.
I'm sorry to say that I have no plans or interest in working on support for any other consoles. If there was one console that I might eventually work on, it would be the GBA saves.
After I finish the N64 fixes, I'll be going back to looking for a solution for the SNES SA-1 SRAM writes.
Well, I picked up a couple SMS carts that use saves and I think I've fixed the SMS SRAM code. I don't have an SMS console so I don't currently have a way of telling if the save data that I'm dumping is the correct data. The SMS SRAM code was nearly complete but the initialization of the port/pins was incorrect. I'm hoping to get a Powerbase unit soon to test the carts on my Genesis. If I can confirm the save data, then I'll look into adding save data writes.
More testing to do...
Quote from: skaman on 04/Oct/2017 02:02:34 AM
Quote from: skaman on 15/Sep/2017 11:37:59 PM
I have no idea on the SMS saves. If there is anything to be done, then it will have to be done by someone else.
I'm sorry to say that I have no plans or interest in working on support for any other consoles. If there was one console that I might eventually work on, it would be the GBA saves.
After I finish the N64 fixes, I'll be going back to looking for a solution for the SNES SA-1 SRAM writes.
Well, I picked up a couple SMS carts that use saves and I think I've fixed the SMS SRAM code. I don't have an SMS console so I don't currently have a way of telling if the save data that I'm dumping is the correct data. The SMS SRAM code was nearly complete but the initialization of the port/pins was incorrect. I'm hoping to get a Powerbase unit soon to test the carts on my Genesis. If I can confirm the save data, then I'll look into adding save data writes.
More testing to do...
feel free to shoot me a message with a retrode 1 update to test and i will see what i can do, i have a custom cart i made that will let me test pretty much any game.
The SMS SRAM saves appear to work in MEKA. I went ahead and implemented SMS SRAM writes. I'll distribute a new SMS BETA firmware once the N64 BETA testing is complete.
The N64 BETA firmware testing has gone well and is near completion. I'm waiting on one last item before compiling the final version for public distribution. A BETA tester requested modifying the firmware to increase compatibility with one of the new crop of N64 repro boards. If I'm able to get my hands on a board then I'll test it to find the required timings.
Amazing work @skaman!
Really incredible @skaman! You're a hero for working to make this dream come true for those of us who long to preserve our hard earned N64 game save progress.
There's a bug in the SMS SRAM read code that will corrupt two bytes at 0x1878 and 0x18FF. These bytes will be changed to 0xFF when you read any SMS cart with SRAM. The current firmware only outputs saves full of 0xFFs due to missing initialization BUT the bytes are corrupted on the read. I wanted to make the bug known before users corrupt their SMS save games.
I've fixed the bug for the next release of the N64 BETA firmware. I'll eventually release a new SEGA SMS-GG BETA firmware with save support and more fixes.
EPIC KUDOS to skaman.
I tested the Retrode.23e BETA FW and the N64 RAM+ROM files worked flawlessly.
Remember, you will have to save swap the RAM file if it is .FLA, .SRA by using a program.
I used ED64-Saveswap v0.1 beta very easy to use.
Also if you are using Project64: make sure to give it the name Project64 needs.
If you are not sure, run the game once in Project64. Copy that name from the new file.
Rename your Retrode imported file using that name and replace that file in your Project64 save directory.
Sometimes you may have to add spaces or capitalize letters.
Quote from: bluegrassjedi on 14/Oct/2017 09:04:09 AM
Also if you are using Project64: make sure to give it the name Project64 needs.
If you are not sure, run the game once in Project64. Copy that name from the new file.
Rename your Retrode imported file using that name and replace that file in your Project64 save directory.
Sometimes you may have to add spaces or capitalize letters.
Same thing for Mupen64Plus. (Mupen64Plus appears to be using names from GoodN64)
On Linux, the saves are in ~/.local/share/mupen64plus/save
@skaman any updates on public release for N64 save compatibility? Thanks for all that you have done and all that you are doing!
Quote from: BadHombre on 22/Oct/2017 06:04:22 AM
@skaman any updates on public release for N64 save compatibility?
We're close to a public release but the firmware won't be released until all known bugs have been squashed.
The BETA testing group has been great at testing the firmware. The testers have recently found a few carts that don't work properly with the cart heuristics code. The problem carts are PAL versions that I do not have so I'm relying on the testers to verify fixes. A potential bug was also discovered related to the Config file which requires more investigation.
I'll be testing the firmware this week to look for solutions.
I've backed up most of my PAL Nintendo 64 games with v0.23h and those with saves in .eep works in RetroArch/Mupen64Plus just by renaming the save to .srm. I can't get .sra and .fla saves working though, even after byteswapping with the Python tool linked earlier in this thread and then renaming.
Can someone check if my save is correctly dumped? The save is for OOT v1.1 PAL, MD5: d714580dd74c2c033f5e1b6dc0aeac77
Unmodified .sra directly from Retrode:
https://www.mediafire.com/file/nw49n59lccd4o2l/TheLegendOfZelda.NZLP.sra
Your save works in PJ64 after saveswapping with the ED64-Saveswap program.
Slot 1 is Link
015 12 hearts (10.5 filled)
3 stones, 3 medallions
Slot 2 is DAVID
033 18 hearts
3 stones, 6 medallions
Slot 3 is David
000 4 hearts (3.75 filled)
1 stone
You might want to try a different emulator like PJ64 and/or use the original saturnu ED64-Saveswap program.
On a somewhat related note, don't use the bkacjios OOT Save Converter page to test PAL saves. It doesn't seem to fully work with the PAL saves. At least it gave incorrect info on the couple saves that I tested.
Good Luck!
Quote from: skaman on 28/Oct/2017 06:03:07 PM
Your save works in PJ64 after saveswapping with the ED64-Saveswap program.
Slot 1 is Link
015 12 hearts (10.5 filled)
3 stones, 3 medallions
Slot 2 is DAVID
033 18 hearts
3 stones, 6 medallions
Slot 3 is David
000 4 hearts (3.75 filled)
1 stone
You might want to try a different emulator like PJ64 and/or use the original saturnu ED64-Saveswap program.
On a somewhat related note, don't use the bkacjios OOT Save Converter page to test PAL saves. It doesn't seem to fully work with the PAL saves. At least it gave incorrect info on the couple saves that I tested.
Good Luck!
Thank you!
After testing, the save once converted, works in PJ64. The Python tool gives the exact same output as ED64, so either can be used. I however, found the Python one to work better, as Pokemon Stadium 2 gives an error when trying to convert with ED64.
I still can't get it to work in Mupen64 though, a deal braker as a Linux user :(
Hello, The following is based on BizHawk Mupen 64 Core exploration done a while back.. :)
Mupen64 uses its own format for savedata where all savetypes are stacked together into a single file.
To import a save, one needs to hack the raw save data into appropriate offset. I have included the Mupen64 method used for loading save ram and the offsets/file sizes needed.
EXPORT void CALL load_saveram(unsigned char * src)
{
memcpy(eeprom, src, 0x800); --> Size 2048 bytes
memcpy(mempack, src + 0x800, 4 * 0x8000); ---> Size: 131072 + 2048 = 133120 bytes
memcpy(flashram, src + (0x800 + 4 * 0x8000), 0x20000); ---> Size: 131072 + 2048 + 131072= 264192 bytes
memcpy(sram, src + (0x800 + 4 * 0x8000 + 0x20000), 0x8000); --> Size: 2 * 131072 + 2048 + 32768= 296960 bytes
}
One can use it by first creating an empty Mupen64 (stacked) save file and then separating and reconstructing the offsets with eg. gnu head/tail/pipe redirection commands.
Eeprom works just by renaming the raw save file because it is located first in the stacked save file.
The previous is of course after possible byte-swapping.
Quote from: jvh147 on 28/Oct/2017 09:47:15 PM
Hello, The following is based on BizHawk Mupen 64 Core exploration done a while back.. :)
Mupen64 uses its own format for savedata where all savetypes are stacked together into a single file.
To import a save, one needs to hack the raw save data into appropriate offset. I have included the Mupen64 method used for loading save ram and the offsets/file sizes needed.
EXPORT void CALL load_saveram(unsigned char * src)
{
memcpy(eeprom, src, 0x800); --> Size 2048 bytes
memcpy(mempack, src + 0x800, 4 * 0x8000); ---> Size: 131072 + 2048 = 133120 bytes
memcpy(flashram, src + (0x800 + 4 * 0x8000), 0x20000); ---> Size: 131072 + 2048 + 131072= 264192 bytes
memcpy(sram, src + (0x800 + 4 * 0x8000 + 0x20000), 0x8000); --> Size: 2 * 131072 + 2048 + 32768= 296960 bytes
}
One can use it by first creating an empty Mupen64 (stacked) save file and then separating and reconstructing the offsets with eg. gnu head/tail/pipe redirection commands.
Eeprom works just by renaming the raw save file because it is located first in the stacked save file.
The previous is of course after possible byte-swapping.
I think that's specific to the libretro core. I know my standalone copy of Mupen64Plus (as included in the repos for Ubuntu 14.04 LTS) handles it the same way PJ64 does and, while researching to write the Python script, I remember reading that the libretro Mupen64Plus core requires special provisions compared to other N64 emulators.
(That said, thank you for clarifying what it's actually doing differently. I never did get around to tracking that information down. Once I have time to get back to working on it and finish the nearly-completed optional GUI frontend, I'll install the libretro core, do some testing, and add an option to convert to/from that.)
Quote from: ssokolow on 30/Oct/2017 04:57:47 AM
Quote from: jvh147 on 28/Oct/2017 09:47:15 PM
Hello, The following is based on BizHawk Mupen 64 Core exploration done a while back.. :)
Mupen64 uses its own format for savedata where all savetypes are stacked together into a single file.
To import a save, one needs to hack the raw save data into appropriate offset. I have included the Mupen64 method used for loading save ram and the offsets/file sizes needed.
EXPORT void CALL load_saveram(unsigned char * src)
{
memcpy(eeprom, src, 0x800); --> Size 2048 bytes
memcpy(mempack, src + 0x800, 4 * 0x8000); ---> Size: 131072 + 2048 = 133120 bytes
memcpy(flashram, src + (0x800 + 4 * 0x8000), 0x20000); ---> Size: 131072 + 2048 + 131072= 264192 bytes
memcpy(sram, src + (0x800 + 4 * 0x8000 + 0x20000), 0x8000); --> Size: 2 * 131072 + 2048 + 32768= 296960 bytes
}
One can use it by first creating an empty Mupen64 (stacked) save file and then separating and reconstructing the offsets with eg. gnu head/tail/pipe redirection commands.
Eeprom works just by renaming the raw save file because it is located first in the stacked save file.
The previous is of course after possible byte-swapping.
I think that's specific to the libretro core. I know my standalone copy of Mupen64Plus (as included in the repos for Ubuntu 14.04 LTS) handles it the same way PJ64 does and, while researching to write the Python script, I remember reading that the libretro Mupen64Plus core requires special provisions compared to other N64 emulators.
(That said, thank you for clarifying what it's actually doing differently. I never did get around to tracking that information down. Once I have time to get back to working on it and finish the nearly-completed optional GUI frontend, I'll install the libretro core, do some testing, and add an option to convert to/from that.)
Thank you! The script as it is today is fantastic and support for converting to the Libretro core would make it even greater!
Public release of N64 Save Support Firmware v0.23 is here: http://forum.retrode.org/index.php/topic,382.0.html
Quote from: Limero on 02/Nov/2017 04:43:50 PM
Thank you! The script as it is today is fantastic and support for converting to the Libretro core would make it even greater!
Glad I could help. :)
Also, in case you missed it, I did some similar itch-scratching (http://forum.retrode.org/index.php/topic,374.0.html) with regard to updating Retrode firmware on Linux.
(Basically, a convenient little shell-script frontend for dfu-programmer because I kept having to go back and re-read the instructions and it got tedious. Not tested on OSX but should theoretically work there too if you're going the dfu-programmer route.)
Quote from: Wannado on 08/Nov/2015 06:17:25 PM
The contributed code does not fully support all types of savegames yet. It's as far as the author got. There are still problems such as save data corruption. Some of the code changes might be breaking other features.
While the N64 save support has been released, GBA save support is still missing. Is that something you'd be willing to let someone else work on? If so, how would I go about getting involved?
are there any plans for grabbing gba sram? or is that out of the question.
Yeah being able to back up GBA saves is the next thing I'm most hoping for. :)