Announcing the public release of the N64 Save Support Firmware v0.23. This firmware adds the ability to read and write N64 saves (SRAM, FlashRAM, and EEPROM). In addition, the N64 cart heuristics code was modified and cart size recognition should be improved.
N64 EEPROM save support should work with the production N64 plugin. The prototype N64/GBx plugin needs modification to add 2 connections - CLK and S_DAT. More details here: http://forum.retrode.org/index.php/topic,154.msg2625.html#msg2625
I want to give a HUGE THANKS to the BETA testers. As a group, the testers tested dozens, if not hundreds, of carts during the firmware development. This firmware would not have been possible without their testing and feedback.
A few notes on using the firmware:
1) When reading N64 carts, please set the voltage to 3.3V.
2) Remember the [saveReadonly] setting in the Config file. Set it to 0 if you plan to write to the save file.
3) Writes to FlashRAM and EEPROM16K save files take longer. DO NOT RESET OR UNPLUG THE RETRODE WHILE THE LED IS ON.
4) SRAM (.SRA) and FlashRAM (.FLA) save files need to be saveswapped to be used in Project64 (PJ64) and other emulators.
EEPROM (.EEP) save files do not need to be saveswapped.
5) Save swap programs are available here:
saturnu's ED64-Saveswap: https://github.com/sanni/cartreader/tree/master/extras/saveswap
ssokolow's portable (cross-platform) alternative: https://github.com/ssokolow/saveswap
6) There is NO SUPPORT for Reproduction N64 carts. Most reproduction carts will have problems either with cart recognition or accessing saves. YMMV.
Here's the summary of the firmware changes:v0.23 (2017-11-03)
- Changes by skaman:
-- N64 Saves!
-- Added N64 SRAM save support.
-- N64 SRAM carts should be identified by Cart ID and
display the .SRA file. The .SRA file can be read
and written.
-- Added proper Dezaemon 3D 768Kbit SRAM support.
-- Added identification of the Hoshi no Kirby 64 (J)
savetype based on the ROM version. v1.0 & v1.1 are
SRAM, 1.2 & v1.3 are EEPROM4K.
-- Added N64 FlashRAM save support.
-- N64 FlashRAM carts should be identified by Cart ID
and display the .FLA file. The .FLA file can be read
and written.
-- WARNING: FlashRAM writes take time to complete as
the chip must first be erased before writing to it.
** WHEN SAVING AN UPDATED .FLA FILE, DO NOT RESET **
**** OR UNPLUG THE RETRODE WHILE THE LED IS ON! ****
-- Added N64 EEPROM save support.
-- N64 EEPROM carts should be identified by Cart ID and
display the .EEP file. The .EEP file can be read
and written.
-- WARNING: EEPROM16K writes take time to complete.
** WHEN SAVING AN UPDATED .EEP FILE, DO NOT RESET **
**** OR UNPLUG THE RETRODE WHILE THE LED IS ON! ****
-- Added reading of the N64 Gameshark. When a working
Gameshark is attached, the Gameshark.z64 ROM will be
displayed.
-- Fixed the N64 heuristics code to recognize 20MB and
40MB games. These were previously overlooked by the
code. Fixes Donald Duck Goin' Quackers, Paper Mario,
and Ogre Battle 64.
-- Fixed the N64 heuristics code for underdumps of Body
Harvest and Paper Mario (E). Modified the addresses
checked to determine the cart size.
-- Modified the Config file to change the save file
write protection setting from "[sramReadonly]" to
"[saveReadonly]". The change was made since the
same setting is applied to all save types including
SRAM, FlashRAM, and Controller Pak save files.
-- Modified the Config file's default N64 ROM extension
to ".z64". This is the correct extension for the
native big endian format output by the Retrode.
-- WARNING: THERE IS NO SUPPORT FOR REPRODUCTION N64
CARTS. MOST REPRODUCTION CARTS WILL HAVE CART
RECOGNITION PROBLEMS AND/OR SAVE PROBLEMS. YMMV.
The v0.23 firmware is available here: http://www.mediafire.com/file/7gxgtbl0co7m0b8/Retrode-v0.23.zip (http://www.mediafire.com/file/7gxgtbl0co7m0b8/Retrode-v0.23.zip)
FIRMWARE UPDATE: I've fixed the handling of a couple carts and updated the firmware to v0.23a.
Here's the summary of the firmware changes:v0.23a (2018-01-10)
- Changes by skaman:
-- N64 Fixes!
-- Fixed the ROM size for N64 Command & Conquer.
The C&C ROM is padded out with 14MB of 00s at the end
which breaks the cart heuristics.
-- Added Rockman Dash (J) to the N64 FlashRAM list.
The v0.23a firmware is available here: http://www.mediafire.com/file/1bcmyzocrqxrwww/Retrode-v0.23a.zip (http://www.mediafire.com/file/1bcmyzocrqxrwww/Retrode-v0.23a.zip)
*buys Retrode immediately*
You guys are incredible... What a feat! Thank you for all of your hard work and commitment to this project.
Great release. Was fun testing all my cartridges. Now, let's go on to Master System! ;D
Yes, SEGA SMS/GG BETA firmware should be distributed to the BETA test group later today.
UPDATE: There will be a delay in distributing the SMS/GG BETA. I picked up a GG Codemasters cart (Micro Machines) that doesn't read properly with the Codemasters code that I implemented for GG Ernie Els Golf. More testing to do...
UPDATE: Looks like some Codemasters carts need the CLOCK for the mapper to work properly. GG Ernie Els dumps properly without the CLOCK but others may not. Unfortunately, the GG CLOCK pin is not connected on the production SMS adapter.
Quote from: skaman on 04/Nov/2017 01:00:45 AM
Yes, SEGA SMS/GG BETA firmware should be distributed to the BETA test group later today.
UPDATE: There will be a delay in distributing the SMS/GG BETA. I picked up a GG Codemasters cart (Micro Machines) that doesn't read properly with the Codemasters code that I implemented for GG Ernie Els Golf. More testing to do...
UPDATE: Looks like some Codemasters carts need the CLOCK for the mapper to work properly. GG Ernie Els dumps properly without the CLOCK but others may not. Unfortunately, the GG CLOCK pin is not connected on the production SMS adapter.
how easy can this be added, would it just be a single wire?
Yes, single wire from CLOCK pin to the cart edge connector.
I was going to do the mod anyway since the CLOCK is needed for the GG EEPROM save carts. I didn't know about it also being needed for some Codemasters carts.
The SMS connector also lacks the CLOCK connection. I'm waiting on a SMS Codemasters cart to check before I add that connection.
I'll document everything if I get it working. I'm going to release the SMS/GG BETA as is since it isn't my code that is the problem. If I can get the CLOCK mod working then I'll release an updated BETA with any code changes.
Quote from: skaman on 05/Nov/2017 06:46:19 PM
Yes, single wire from CLOCK pin to the cart edge connector.
I was going to do the mod anyway since the CLOCK is needed for the GG EEPROM save carts. I didn't know about it also being needed for some Codemasters carts.
The SMS connector also lacks the CLOCK connection. I'm waiting on a SMS Codemasters cart to check before I add that connection.
I'll document everything if I get it working. I'm going to release the SMS/GG BETA as is since it isn't my code that is the problem. If I can get the CLOCK mod working then I'll release an updated BETA with any code changes.
thanks, i have the official sms plugin with an added game gear connector so if there is a mod i can do to improve it more thats even better.
It might be better to say that mine is a "portable" or "cross-platform" alternative, since there's nothing that should prevent it from working on Windows.
(ie. If it doesn't work on Windows, it's a bug that will be found and squashed when I have time to get back to working on it and set up AppVeyor (https://www.appveyor.com/) CI testing.)
In fact, when I have time to get back to work on it, the partially written optional GUI was envisioned specifically to provide an alternative to ED64-Saveswap for people with over-sensitive virus scanners that hate AutoIt scripts.
Quote from: ssokolow on 06/Nov/2017 12:57:44 AM
It might be better to say that mine is a "portable" or "cross-platform" alternative, since there's nothing that should prevent it from working on Windows.
(ie. If it doesn't work on Windows, it's a bug that will be found and squashed when I have time to get back to working on it and set up AppVeyor (https://www.appveyor.com/) CI testing.)
In fact, when I have time to get back to work on it, the partially written optional GUI was envisioned specifically to provide an alternative to ED64-Saveswap for people with over-sensitive virus scanners that hate AutoIt scripts.
Done. :)
Linux users looking to use their saves with Mupen 64 using the libretro core should read these posts:
http://forum.retrode.org/index.php/topic,154.msg2692.html#msg2692
http://forum.retrode.org/index.php/topic,154.msg2695.html#msg2695
Thank you SO MUCH for figuring this out! My N64 plugin finally works and I can archive my cart saves to PC!
I do have to report that, after testing all the carts I own, Retrode did not detect a save file on my Majora's Mask cart.
EDIT: You said .EEP files didn't need to be altered in any way to work with emulators; this doesn't appear to be the case. Project64 couldn't read any of them.
Maybe the save folder path is wrong?
Quote from: Eureka on 08/Nov/2017 09:25:54 AM
Thank you SO MUCH for figuring this out! My N64 plugin finally works and I can archive my cart saves to PC!
I do have to report that, after testing all the carts I own, Retrode did not detect a save file on my Majora's Mask cart.
EDIT: You said .EEP files didn't need to be altered in any way to work with emulators; this doesn't appear to be the case. Project64 couldn't read any of them.
Which region/version of Majora's Mask is the cart? Try setting [saveReadonly] to 1 then read the Majora's Mask cart.
Do the .EEP files contain data or all FFs? Are you using the early N64/GBx plugin or the later N64 plugin?
Quote from: skaman on 08/Nov/2017 10:38:35 AM
Quote from: Eureka on 08/Nov/2017 09:25:54 AM
Thank you SO MUCH for figuring this out! My N64 plugin finally works and I can archive my cart saves to PC!
I do have to report that, after testing all the carts I own, Retrode did not detect a save file on my Majora's Mask cart.
EDIT: You said .EEP files didn't need to be altered in any way to work with emulators; this doesn't appear to be the case. Project64 couldn't read any of them.
Which region/version of Majora's Mask is the cart? Try setting [saveReadonly] to 1 then read the Majora's Mask cart.
Do the .EEP files contain data or all FFs? Are you using the early N64/GBx plugin or the later N64 plugin?
The Majora cart is the original NTSC release with the lenticular label. "Savereadonly" is already set to 1. I'm using Retrode 2 and the plugin built specifically for N64 carts (the one that says "Plug-In 64" on the label). I don't understand the "files" question.
I put the saves in the "Save" folder of Project64; it's where it gets them from. But I get a "Failed to open EEPROM" message when I try to use them.
You mentioned something about setting the voltage to 3.3V; that is something I forgot to do the first time. But when I dumped the saves again on the correct setting, I got the same results. The Majora cart did finally detect a save, though.
Of course it's an .FLA which means I can't test it immediately. That save-altering program you linked to is all Greek to me -- I have little experience with command line programs so I don't know how to use it. I do know that the .EEP files don't work.
Quote from: skaman on 05/Nov/2017 06:46:19 PM
Yes, single wire from CLOCK pin to the cart edge connector.
I was going to do the mod anyway since the CLOCK is needed for the GG EEPROM save carts. I didn't know about it also being needed for some Codemasters carts.
The SMS connector also lacks the CLOCK connection. I'm waiting on a SMS Codemasters cart to check before I add that connection.
I'll document everything if I get it working. I'm going to release the SMS/GG BETA as is since it isn't my code that is the problem. If I can get the CLOCK mod working then I'll release an updated BETA with any code changes.
I opened up a GG EEPROM cart (World Series Baseball) and it doesn't use the CLOCK pin. The SK pin for the EEPROM is connected to the SEGA 315-5557 chip. The !RESET pin from the cart edge is also connected to the 315-5557 chip. I'll have to connect my logic analyzer to the chips and see what is going on.
I haven't opened up the problem GG Codemasters cart as I've read that they are difficult to open without damaging them. I've seen scans of the PCB and the CLOCK pin is connected. I might build a passthru interface to plug into the GG so that I don't have to open the carts to capture the data.
More testing to do...
Quote from: Eureka on 08/Nov/2017 09:34:03 PM
Quote from: skaman on 08/Nov/2017 10:38:35 AM
Quote from: Eureka on 08/Nov/2017 09:25:54 AM
Thank you SO MUCH for figuring this out! My N64 plugin finally works and I can archive my cart saves to PC!
I do have to report that, after testing all the carts I own, Retrode did not detect a save file on my Majora's Mask cart.
EDIT: You said .EEP files didn't need to be altered in any way to work with emulators; this doesn't appear to be the case. Project64 couldn't read any of them.
Which region/version of Majora's Mask is the cart? Try setting [saveReadonly] to 1 then read the Majora's Mask cart.
Do the .EEP files contain data or all FFs? Are you using the early N64/GBx plugin or the later N64 plugin?
The Majora cart is the original NTSC release with the lenticular label. "Savereadonly" is already set to 1. I'm using Retrode 2 and the plugin built specifically for N64 carts (the one that says "Plug-In 64" on the label). I don't understand the "files" question.
I put the saves in the "Save" folder of Project64; it's where it gets them from. But I get a "Failed to open EEPROM" message when I try to use them.
You mentioned something about setting the voltage to 3.3V; that is something I forgot to do the first time. But when I dumped the saves again on the correct setting, I got the same results. The Majora cart did finally detect a save, though.
Of course it's an .FLA which means I can't test it immediately. That save-altering program you linked to is all Greek to me -- I have little experience with command line programs so I don't know how to use it. I do know that the .EEP files don't work.
I've got a gold, lenticular NTSC Majora's Mask, so I took the liberty of testing it with Retrode firmware v0.23, my Plug-in64 adapter, the 3.3v setting, and the "[saveReadonly] 1" that I just leave on all the time.
I play whatever I can with Mupen64Plus, so I only have Project64 2.2.0.3 installed in Wine right now, but my and my brother's old save files appeared and loaded just fine when I did the following:
1. Copy "ZeldaMajora'sMask.NZSE.fla" from the Retrode to
/home/ssokolow/.wine/drive_c/Program Files/Project64 2.2/Save2. Rename the save file to "ZELDA MAJORA'S MASK.fla"
3. Unset the read-only attribute that the Retrode puts on it
4. Run "saveswap.py ZELDA MAJORA'S MASK.fla" in the terminal
(Mine doesn't have a GUI yet, but ED64-Saveswap does if you want something simpler. As for the name to rename it to, create a new save in your game and see what filename appears in Project64's Save folder.)
Quote from: Eureka on 08/Nov/2017 09:34:03 PM
The Majora cart is the original NTSC release with the lenticular label. "Savereadonly" is already set to 1. I'm using Retrode 2 and the plugin built specifically for N64 carts (the one that says "Plug-In 64" on the label). I don't understand the "files" question.
I put the saves in the "Save" folder of Project64; it's where it gets them from. But I get a "Failed to open EEPROM" message when I try to use them.
You mentioned something about setting the voltage to 3.3V; that is something I forgot to do the first time. But when I dumped the saves again on the correct setting, I got the same results. The Majora cart did finally detect a save, though.
Of course it's an .FLA which means I can't test it immediately. That save-altering program you linked to is all Greek to me -- I have little experience with command line programs so I don't know how to use it. I do know that the .EEP files don't work.
Sorry, I missed this reply.
Now that you can see the Majora's Mask save, you'll need to saveswap it to run on PJ64.
When using save files on PJ64:
1) Make sure that the save file is in the PJ64 SAVE folder and that it is properly named.
2) Make sure that the READ-ONLY attribute is unchecked on the save file in the SAVE folder.
Good Luck!
This is wonderful, thank you so much Skaman.
Perhaps someday I'll buy one of the N64 plugins for my Retrode2 before I purchase a Nintendo 64 (there are some games I'm definitely planning to buy to test with the plugin, and one is definitely going to be Mario Kart 64). I think 2018 will be that time.
Quote from: skaman on 13/Nov/2017 03:51:04 AM
Quote from: Eureka on 08/Nov/2017 09:34:03 PM
The Majora cart is the original NTSC release with the lenticular label. "Savereadonly" is already set to 1. I'm using Retrode 2 and the plugin built specifically for N64 carts (the one that says "Plug-In 64" on the label). I don't understand the "files" question.
I put the saves in the "Save" folder of Project64; it's where it gets them from. But I get a "Failed to open EEPROM" message when I try to use them.
You mentioned something about setting the voltage to 3.3V; that is something I forgot to do the first time. But when I dumped the saves again on the correct setting, I got the same results. The Majora cart did finally detect a save, though.
Of course it's an .FLA which means I can't test it immediately. That save-altering program you linked to is all Greek to me -- I have little experience with command line programs so I don't know how to use it. I do know that the .EEP files don't work.
Sorry, I missed this reply.
Now that you can see the Majora's Mask save, you'll need to saveswap it to run on PJ64.
When using save files on PJ64:
1) Make sure that the save file is in the PJ64 SAVE folder and that it is properly named.
2) Make sure that the READ-ONLY attribute is unchecked on the save file in the SAVE folder.
Good Luck!
The Read-Only box was the big problem. Now the saves work. Thanks very much.
(https://forum.retrode.com/proxy.php?request=http%3A%2F%2Fwww.platypuscomix.net%2Finteractive%2Fn64saves1.jpg&hash=9ba4f39b6f08db3e682c8ea99df231033e4d9552)
NOW I NEVER HAVE TO DO THIS AGAIN!
Can someone please verify whether Pokemon Snap works on their end? I have a cart I just cannot for the life of me seem to confirm.
* Tested and confirmed the save data is still valid and present in the actual cart on an actual N64
* Retrode appeared to read the cart just fine; the .z64 and .fla files were right there and transferred over to PC without incident
* I'm no expert, but peering at the .fla file in a hex editor sure looks like there's data in there and that it's not just an empty file or full of 00/FF or whatever.
* Yet both 1964 and Project 64 act like I've fed it a completely blank file when I load the game, in that there's no "Continue" option on the main menu, etc.
* Yes, I unchecked Read Only and made sure it was on 3.3 volts.
* Possibly a .fla issue? I am afraid I can't test this with any other .fla saves, as the only other game I have that uses .fla is Pokemon Stadium (which doesn't appear to have a save file even when I test the physical cart in the physical system.) My other games all work fine, but they also all use .eep.
I've attached the .fla file for reference. If my attempts to parse the hex editor view are correct and this is a valid data file, then there appears to be some sort of issue with getting either of the emulators I tried to read it. If it's not, then something is up on the Retrode reading/transferring end, since this is definitely a real and working save on the physical system.
Thank you so much for any assistance you can provide!
Try dumping the save twice.
Once with [saveReadonly] set to 0 and once set to 1.
Compare the files in the hex editor to see if there's any difference.
If there's a difference, then try each in the emulator (after saveswapping).
Remember to uncheck the read-only attribute after putting it in the save folder.
Thank you very much for your suggestions!
Alas, there does not appear to be any difference between the two dumps with that setting toggled, and the emulators continue to treat each like a new file.
Ok. That's good that there is no difference.
I'm not familiar with Pokemon Snap save data but it looks like your .FLA has the proper header data at the start of the file.
Maybe someone else can check their Pokemon Snap saves.
This is awesome. Been waiting years for this. Huge props to skaman.
Also shout out to Eureka for making many of the same mistakes I did while getting my saves working and asking about them here so I didn't have to lol. I also used the wrong voltage at first and then didn't know to uncheck the readme.
While I got .eep and .sra working thanks to the ED64 saveswap, I do have the same problem as kjorteo in that PJ64 will not recognize my Pokemon Snap save. Tried everything I know and everything suggested in this thread and no dice. It's the only .fla game I have so I can't test anything else.
Still, a small price to pay for having all my other N64 saves preserved for life. Thanks again!
Are you able to open your Pokemon Snap cart?
I'd like to see the flashram chip on the PCB. I'm wondering if it is an incompatibility with the flash chip.
I've ordered a copy of Pokemon Snap and should be receiving it soon to run tests on.
FWIW, I managed to dump my Pokémon Snap (PAL) save and play it via Mupen64Plus by using ssokolow's saveswap program.
I received the Pokemon Snap cart and it dumps both ROM and SAVE properly. This cart uses the common 29L1100 flashram chip.
I suspect that the problem Pokemon Snap carts are using the 29L1101 flashram chip. EDIT: kjorteo's Pokemon Snap cart uses the common 29L1100 flashram.
I've ordered a copy of Jet Force Gemini (PAL) which apparently has a better chance of using the 29L1101 chip.
To anyone with a Pokemon Snap cart, please dump your save and report whether it works or not. It would be of great help to open the cart and identify the flashram chip. The flashram chip should be one of 29L1100KC-15B0, 29L1101KC-15B0, or MN63F81MPN.
First I want to say thank you for all the hard work you've put into the firmware!
The Retrode has Virtual Boy dumping capabilities (I don't have a adapter, unfortunately, but would like one), but it doesn't read Red Alarm properly (maybe some others?). I realize testing would be difficult, but if you're ever looking for something else to do maybe you could contact [JonY] who built an adapter to test?
http://consolingmyself.co.uk/post/732430949/retrode-virtual-boy-adapter-build-3
Thank you again!
I made a prototype Virtual Boy plugin PCB. I'm waiting for it to arrive from the PCB fab. If I can get it working then I'll post the details. I already have a copy of Red Alarm waiting to be tested.
Awesome to hear! Thank you!
My initial guess on the potential cause of the bad Pokemon Snap save file was proven wrong.
I suspected the use of the uncommon 29L1101 flashram chip but that is incorrect as kjorteo's cart uses the common 29L1100 flashram chip.
I got a copy of Pokemon Snap with the 29L1100 (like kjorteo's cart) and it reads out perfectly. The 29L1100 flashram is probably the most tested flashram type across many different carts.
To completely settle the issue in my mind, I picked up two different carts that use the 29L1101 flashram and I can confirm that the 29L1101 flashram type works properly with the firmware.
kjorteo's save file has some bad data at 0x8000-0xEFFF. There appears to be some issue with his flashram chip responding to the reads in this area. The data output is the address that the Retrode is attempting to read.
If anyone else encounters issues with their Pokemon Snap save, please post your save file.
I found a cart that isn't handled properly with the final N64 firmware.
Command & Conquer (all variants) will show as 20MB when it is actually 32MB. This is because the ROM is padded with a large block of 00s at the end. The firmware assumes that the 00s are garbage and truncates the ROM.
To display the full Command & Conquer ROM, use the HWB button to switch the size to 32MB.
I think I will hardcode the size for the C&C carts into the next firmware release.
Quote from: skaman on 25/Nov/2017 04:53:32 PM
I made a prototype Virtual Boy plugin PCB. I'm waiting for it to arrive from the PCB fab. If I can get it working then I'll post the details. I already have a copy of Red Alarm waiting to be tested.
My prototype VB plugin has an error that I had to fix with a couple jumpers.
I only have a couple test carts but they both read out properly now. I modified the code to correct the handling of Red Alarm. It was underdumping due to the code misidentifying the data used to check the ROM size. Using the HWB button to adjust the size would have produced the proper ROM.
My prototype includes the RAM pins so I'm hoping to figure out how to read out the save game from Wario Land.
skaman you are incredible. This is such great news. Now I can't wait for them to reprint the N64 plugin so that I can get one and put it to use.
I found another cart that isn't handled properly by the v0.23 firmware.
Rockman Dash (NUS-NRHJ) wasn't on the original list of Flashram save carts. The ROM will display but not the .FLA save file. Mega Man 64 (NUS-NM6E) was included on the save list but the Japanese version was overlooked due to the difference in the cart serial.
I'm thinking of releasing an update to v0.23 with this fix and the Command & Conquer ROM size fix.
A few more releases are coming in 2018. I'm still working on the BETA SMS/GG firmware v0.24 and I also made a BETA Virtual Boy firmware v0.25 with SRAM save support.
I fixed the N64 Command & Conquer ROM size and added the N64 Rockman Dash FlashRAM save in the firmware.
New firmware release v0.23a is here: http://www.mediafire.com/file/1bcmyzocrqxrwww/Retrode-v0.23a.zip
Finally after all these years I can backup my n64 saves! This is why I bought a Retrode in the first place (well that and GB/GBC save backup but that was already out when I got it) and you guys have at last made this a reality thank you so much for all of your hard work and I wish I had found this sooner.
Unable to dump Pokemon Snap correctly and Donkey Kong 64 on .25a-beta firmware. Saves both showing up on the N64 but wont work with project 64. Chip in Pokemon snap is 29L1100KC. Save files look OK to me in HEX editor
The Donkey Kong save works for me in PJ64.
The Pokemon Snap save looks like it has correct save data but I couldn't get it to work after saveswapping the file.
Could you try reverting the Retrode FW to v0.23 or v0.23a and redump the Pokemon Snap save?
Good Luck!
After I looked at the Pokemon Snap save, I vaguely recalled that another poster had mentioned problems with their save.
The previously reported problem was on a US Pokemon Snap cart. The issue was exactly the same. If you look in the save file at 0x8000-0xEFFF, that is not valid save data. The data written is actually the block address that the Retrode is trying to read.
I could not duplicate the issue with my US Pokemon Snap (29L1100) cart. Other testers did not report any problems with their carts.
I'm not sure why the two carts have issues specifically at those addresses. It could be a power or timing issue related to the flashram chip. Try connecting the Retrode to different USB connections and redump the save. Check to see if the data at 0x8000-0xEFFF changes.
Good Luck!
Thannks for the info. Got the DK 64 save to work (was using an old US ROM). Dumped my cart and the save works with it. No such luck with the Pokemon snap rom as it was dumped directly from my cart. It works fine but the save as you already know doesn't. Will try reverting the firmware and trying a few different USB ports to see if that works.
On another note, is there anything additional required to get Mempaks working in project 64, i.e. do they need converted or anything like .fla files? I soldered an N64 extension cord to the new N64 plugin and it picks up the Mempak from the controller. However when I test it using TWINE it says the pak is corrupted and forces a reset
I've never worked with the Mempak so I don't know. I'll try to run some tests later.
Ok. I picked up another copy of Pokemon Snap (U) with the 29L1100. I initially could not get the save read properly. I cleaned the pins and retested the cart. The initial save data showed areas with incorrect (address) data. I removed the cart from the plugin, reinserted it, and then tested the read. After a few times of reinserting the cart, the save data showed up complete and intact. My second copy of Pokemon Snap now reads out completely.
My suggestion to anyone experiencing save data corruption is to clean the cart pins first. If the data is still corrupt, then remove the cart and reinsert it into the plugin. The cart pins are most likely oxidized and may need multiple insertions to get through the oxidation.
Quote from: idiotproof on 02/Aug/2018 04:47:21 PM
On another note, is there anything additional required to get Mempaks working in project 64, i.e. do they need converted or anything like .fla files? I soldered an N64 extension cord to the new N64 plugin and it picks up the Mempak from the controller. However when I test it using TWINE it says the pak is corrupted and forces a reset
Did you add the 220R resistors to the board? Another poster was asking about connecting a controller to the plugin and I was reminded about the resistors. They're 1/4W resistors soldered in vertically on the v0.4 PCB.
My board already had the vertical resistors soldered in. Mempaks were showing up but corrupted when loaded into Project64. Took them out and solder 1 220 diagonal same as here http://forum.retrode.org/index.php?topic=386.0 now no Mempaks show up
Diagonal resistor was on the older board revision. V0.4 PCB places them vertically.
:'( just ripped out the resistors for no reason then.
Tested a Memory Pak and it reads out properly. I compared the Mempak1.mpk dump against a dump using a different reader and the files matched. I tested from the v0.18d (first firmware with memory pak support) up to v0.25.
Before attempting to read the memory pak, make sure your Config file [sramReadonly] or [saveReadonly] is set to 1. Wannado mentions dumping your memory pak at least a couple times to confirm the contents before making any changes.
Refer to Wannado's Guide: http://forum.retrode.org/index.php?topic=196.0
@skaman
Thank you for keeping the firmware current. I just received my new Retrode v2 (my first cart Dumper) from dragonbox and something is a bit confusing to me. I see you have a few system specefic firmwares which are significantly newer than the retrode.org official (v0.19 beta (2016-05-01)).
.
Is the recommended process to flash the latest system specific firmware you offer.... And for systems not offered to revert to the retrode official?
.
.thank you greatly!
.
edit RETRODE.CFG indicates that the following firmware shipped: .25a-beta - Config
The Retrode website hasn't been updated in years. I don't have the ability to make changes to it.
The firmware updates are cumulative. If your Retrode shipped with v0.25a beta then you should update to the v0.25a final here: http://www.mediafire.com/file/i2a1q7dft3f4135/Retrode-v0.25a.zip
Thank you!