Progress on N64/GBA save support?

[bluegrassjedi]

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.

[ssokolow]

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

[BadHombre]

@skaman any updates on public release for N64 save compatibility? Thanks for all that you have done and all that you are doing!

[skaman]

@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.

[Limero]

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

[skaman]

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!

[Limero]

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

[jvh147]

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.

Code: [Select]

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.

[ssokolow]

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.

Code: [Select]

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.)

[Limero]

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.

Code: [Select]

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!

[skaman]

Public release of N64 Save Support Firmware v0.23 is here:  http://forum.retrode.org/index.php/topic,382.0.html

[ssokolow]

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 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.)

[HamsterExAstris]

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?

[neogeo567]

are there any plans for grabbing gba sram? or is that out of the question.

[Nori]

Yeah being able to back up GBA saves is the next thing I'm most hoping for.