Dumping N64 Game Saves with a Gameshark with LPT access

Discussion in 'Nintendo Game Development' started by arbingordon, Mar 9, 2011.

  1. arbingordon

    arbingordon Active Member

    Joined:
    Dec 2, 2010
    Messages:
    36
    Likes Received:
    0
    A few things I'd like to fork out from Marshall's thread.
    Yes, .n64 is just plaintext of the input data with a header.
    Edit: I was thinking of .a64. However, with plain EEP 4k/16k you can just cut the save out of the file with a hex editor, with SRAM it's compressed as mentioned in the thread, so the compression format would have to be reversed.
    I don't think that's the case, but maybe you can show proof that it is actually compressed.
    A similar idea, but a better one I think: using libdragon by DragonMinded and the toolchain provided with it, write minimal c program to do dump the saves onto the mempak (perhaps with a checksum at the end to ensure integrity), and then load it using gsuploader by ppcasm. Although, it doesn't yet have any "easy" ways of reading SRAM/FlashRAM, that should still be doable with some work. Perhaps even just dump it to the PC over the parallel port. I'll write up some code in a bit just as a proof of concept to dump EEPROMs straight onto the mempak if you'd like, but to another point of the thread...
    Edit: here's the sample program, http://pastebin.com/Q6vBCCj5
    Edit 2: note that will overwrite whatever is in the mempak, probably a good idea to back the mempak up first.
    It seems to me like there are some people out there that would appreciate being able to dump their saves, and I wouldn't mind looking into this, but I don't have a gameshark to test stuff on (one with a working parallel port), so, if anyone is willing to test code for the purposes of backing up save data, stop by #n64dev @ efnet and I'll try and set something up.
     
    Last edited: Mar 11, 2011
  2. link83

    link83 Enthusiastic Member

    Joined:
    Mar 22, 2008
    Messages:
    526
    Likes Received:
    8
    I'm afraid I havent got any proof I can show you :redface: All I can tell you is that game cartridge SRAM is 256Kbit and the Controller Pak's SRAM is also 256Kbit, yet when I back up a completed save file from Zelda OoT to the Controller Pak it only used up 21 pages from the 123 pages available. Also on a different copy of Zelda OoT with less progress and only one save slot used it only took up 11 pages - this to me suggests that it is being compressed, otherwise both files should be the same size. Also if it was a 1:1 copy it shouldnt really even fit on the Controller Pak at all, since once you take away the small amount of memory used for Controller Pak memory formatting your left with just less than 256Kbit of usable space.

    Whats interesting is that if there are a couple of save files already on the Controller Pak it wont let me backup cartridge SRAM, even if theres enough free space - possibly this suggests the AR/GS is compressing the save file as it saves and using the Controller Pak's memory as 'workspace'?

    In this review for the later PS2 Action Replay it says:-
    http://uk.gear.ign.com/articles/389/389327p1.html
    "The Memory Manager part of the software lets you copy saved files, and even compress them to save space, both of which are very useful, but you can only keep them for backup or for use with the Action Replay itself."
    Theres some mention that the original PlayStation Action Replay did the same thing and that was developed around the same time as the N64 AR/GS, so maybe they used the same save compression algorithm on all of them?

    That sounds great :) I would love some way to backup my original save files, especially for SRAM games with their limited battery lifetime. If it could backup saves by parallel port to a PC that would probably be best, since you could use the save files with emulators and backup FlashRAM saves as well.

    You probably already know this, but there is an unofficial GS/AR utility called "Game Software Code Creator":-
    http://doc.kodewerx.org/hacking_n64.html#gspro_gscc
    Do you think it would be possible to add the save dump feature to that program? Or would it best to make a standalone program?

    Unfortunately I cant help with testing at the moment since the only PC I have set up has a parallel port that doesnt seem to work with the N64 Action Replay (I tried all the settings in the BIOS) but I do have an extra N64 Action Replay with parallel port which I would be willing to donate, although if you live in an NTSC country it might not be much use since the menu only displays in PAL (Perhaps you could change the firmware?) Alternatively maybe I could donate a little to help you buy an N64 GameShark?
     
    Last edited: Mar 10, 2011
  3. arbingordon

    arbingordon Active Member

    Joined:
    Dec 2, 2010
    Messages:
    36
    Likes Received:
    0
    It might use RLE compression or something, someone is going to be sending me some dumps of these "compressed" saves so I might be able to figure that out. But... see below.

    That's good enough for me to believe it, however, I hear that the FlashRAM / SRAM backup capabilities can be hit-or-miss sometimes, can you confirm this? If so, it might be better to just write a program from scratch to do the dumping, instead of reversing the "compression format".


    With the "dump save to mempak, copy save to cf with 64drive" method, you could still do FlashRAM, just in 4 segments, or maybe RLE.

    Possible, but I don't think I'd go that route, standalone program to do it seems easier.

    Funny that was mentioned, the point of this thread is somewhat voided now as a friend bought one (ebay, not 100% sure it'll have a working parallel port, but we'll see), so that point is a bit less important. Regardless, I think it might be good to still have testers to iron out any bugs if there are any.
     
  4. link83

    link83 Enthusiastic Member

    Joined:
    Mar 22, 2008
    Messages:
    526
    Likes Received:
    8
    I havent tried backing up FlashRAM, but I have backed up EEPROM and SRAM saves with success. SRAM does seem a bit hit-or-miss, that could be why it only works reliably with a completely empty Controller Pak.

    If its not too difficult it would be nice to reverse the compression format, but I dont think backing up through the AR/GS>Controller Pak>Dex Drive>PC route is the best method, it would be much easier (and cheaper) with the AR/GS>PC route.

    I'm not sure why it would need to be 4 segments? As far as I understood it the 64drive will support both SRAM and FlashRAM using the same method, so if that method works at all then it should be possible to make one complete file?

    Sounds great :)

    Thats great to hear, my offer still stand if you need it ;-)

    I am guessing your current N64 GameShark is one of the late V3.3's which were 'cost reduced' and have missing components needed for the parallel port to work?:-
    http://www.kodewerx.org/forum/viewtopic.php?f=18&t=7189&start=0
    I have never come across a European N64 Action Replay that has been cost reduced, so I assume it was something Interact asked Datel to produce to lower production costs for the US market.

    The following is just my little rant about GS/AR reliability problems...

    A lot of people 'broke' the N64 GS/AR by accidentally selecting a 'boot code' for a game they didn't own, which causes the GS/AR to lockup until a game with the correct CIC is used :rolleyes: I have read of people throwing them in the bin because of this.

    Not only that but even entering cheat codes normally can cause the firmware to be corrupted:-
    http://forums.benheck.com/viewtopic.php?f=5&t=30689

    Datel really should have fitted the GS/AR with a manual 'boot code' switch, and used a separate flash chip to store the cheat codes - not used the same flash chips the firmware is stored on.

    The Blaze Xplorer64 seems to solve a lot of these issues and is a lot more reliable:-
    http://doc.kodewerx.org/hacking_n64.html#devices_xp
    But it seems to have only been released in Europe? (I actually have a spare Xplorer64 too, so if you need one let me know)
     
    Last edited: Mar 10, 2011
  5. arbingordon

    arbingordon Active Member

    Joined:
    Dec 2, 2010
    Messages:
    36
    Likes Received:
    0
    I didn't intend to go that route, just to use gameshark to dump the data to the controller pak, and then with a 64drive dump the mempak to the compact flash cart that's inserted.


    I mean there isn't enough room to dump the whole FlashRAM into the mempak, but this is all under the idea of dumping to mempak with GS, then to compact flash with 64drive. The idea of sending it over parallel does sound better though.


    Don't know yet, going to be "4-11 days for shipping".
     
  6. link83

    link83 Enthusiastic Member

    Joined:
    Mar 22, 2008
    Messages:
    526
    Likes Received:
    8
    The only problem I can see is from what I remember you cant access the main GameShark menu to backup saves once you have booted the game? (Its been a while since I last used it) and since the 64drive probably wont allow direct booting to a specific game (It uses SDRAM so the game has to be loaded first) and the 64drive menu probably doesnt 'identify' itself as using a particular memory save type, so the GameShark might not recognise it as a game which uses save memory at all, in which case it probably would not be possible to backup saves this way(?) I hope that makes sense.

    The other alternative is what was suggested by MottZilla/marshallh - that we load a homebrew program on the 64drive which tells it to dump the save contents to system memory:-
    Basically it would work like this:-
    - Load a save backup program from the 64drive into system RAM
    - Hotswap to the game we want to backup
    - Let the program copy the save into system RAM
    - Hotswap back to the 64drive
    - Let the program copy the save contents to the CompactFlash.

    This method seems kind of risky to me though, since you are not meant to hotswap cartridges and I have previously read that it can cause save file corruption. I know the link between Banjo Kazooie and Banjo Tooie was supposed to work in a similar way, but it didnt happen due to later revisions of the N64 motherboard which didnt allow enough time to make the swap before the system locked up.

    Ah I see, well the GameShark itself doesnt allow splitting save files, so im not sure how that would be accomplished :confused: Sending it over parallel does seem better, since not everyone will want to buy a GameShark and a 64drive to backup save files. I think the fewer items needed the better, and the simplest and cheapest method would be using a GameShark with a parallel port to backup directly to PC.
     
    Last edited: Mar 10, 2011
  7. radorn

    radorn Rising Member

    Joined:
    Feb 9, 2007
    Messages:
    66
    Likes Received:
    7
    check PM, link83
     
  8. arbingordon

    arbingordon Active Member

    Joined:
    Dec 2, 2010
    Messages:
    36
    Likes Received:
    0
    The program itself would do the checks to try and find what save data is available, either from probing eeprom/sram/flashram or by checking the cart ID of the game inserted against a list.


    Until recently I didn't think this was doable, but:
    The N64 locks up as soon as the cartridge is removed, because the PIF is (almost) constantly checking for the CIC. In simple terms, you cannot hot swap. However, you can still hold down the reset button on the N64 deck and hot swap, without the program/game dying because the PIF isn't seeing the CIC. So hot swapping in the fashion you mention should be doable, yes.

    It could, and could result in worse (frying the N64 deck or 64drive). However the risk isn't *that* bad, it's just not 100% sure you won't end up frying it. It's about as risky as the "tilted cartridge" OoT trick.

    It would work because it's completely custom code. (well, "custom" code built around the libdragon library to make things easier)
     
  9. link83

    link83 Enthusiastic Member

    Joined:
    Mar 22, 2008
    Messages:
    526
    Likes Received:
    8
    Sorry, I misunderstood what you were suggesting, I thought you meant use the AR/GS in combination with the 64drive to restore the save backup to the CompactFlash just as though it were a standard game, but you meant use a program on the 64drive to backup the Controller Pak contents and then try and then later try and uncompress the files on a PC?

    It would still be nice to just use a AR/GS to dump the save files to a PC directly though :nod:

    Thats really interesting, so if the PIF isnt seeing the CIC could this method be used to load import games?

    Hmm, I think I would rather not take the chance, I could risk loosing an N64 deck and maybe even my save files, but I would not want to risk frying a 64drive!

    Yeah, I definitely misunderstood what you were suggesting - sorry :redface:
     
    Last edited: Mar 11, 2011
  10. arbingordon

    arbingordon Active Member

    Joined:
    Dec 2, 2010
    Messages:
    36
    Likes Received:
    0
    Uncompress (if RLE was used)/append the mempak dumps to each other to give you the full 128KB.
     
  11. sanni

    sanni Intrepid Member

    Joined:
    May 30, 2008
    Messages:
    653
    Likes Received:
    77
    Hey there :)
    Very interesting thread but your pastebin link does not work. :(

    I'm not a programmer but I have some very little experience with libdragon and really would like to read through your sample code =D
    Could you please repost the pastebin?
     
  12. arbingordon

    arbingordon Active Member

    Joined:
    Dec 2, 2010
    Messages:
    36
    Likes Received:
    0
    Oops, my bad :( I think I deleted it accidentally when I was cleaning out my pastebin the other day.
    Anyway, http://pastebin.com/Q6vBCCj5
    If you're interested in playing around with libdragon though, I did a little other work;
    http://pastebin.com/umxa82Qz (displays the EEPROM contents to screen)
    http://pastebin.com/QyRftsBs (displays some information Super Mario 64's save)
    Edit: http://pastebin.com/wdm03jWK should work a bit better at displaying the information accurately, in a bit more understandable manner.
     
    Last edited: Mar 11, 2011
  13. sanni

    sanni Intrepid Member

    Joined:
    May 30, 2008
    Messages:
    653
    Likes Received:
    77
    I like it, thank you :D

    [​IMG]

    Gonna try the new version soon.
     
    Last edited: Mar 12, 2011
  14. arbingordon

    arbingordon Active Member

    Joined:
    Dec 2, 2010
    Messages:
    36
    Likes Received:
    0
    After months of nothing, I figure I might as well post what little has been done (rather than sit on my HDD for another month not benefiting anyone).
    The binary to send is attached, send it with gsuploader.
    It will dump the SRAM to Controller Pak/Mempak, which can then be read off with tools like GSCC, N64 Utils, etc, rather than implementing communications between N64 and PC anew.
    There is no visual confirmation of success, and is poorly put together (not gsuploader- sram2mpk), however it works, and I figure it's benefiting no one by sitting on my PC since I'm not doing anything with it right now.
    Some games known to work:
    F-ZERO X (NTSC-U)
    Super Smash Bros. (NTSC-U)
    Some games known to not work:
    Resident Evil 2 (NTSC-U) (gsuploader fails to send the binary completely)

    Is anyone even still interested in this at all?
     

    Attached Files:

  15. link83

    link83 Enthusiastic Member

    Joined:
    Mar 22, 2008
    Messages:
    526
    Likes Received:
    8
    I'm still very interested :) I actually thought about this thread last month, but didn't want to bump/mither to see if there had been any progress. Will have to give the Action Replay parallel port connection another try sometime soon.

    Is there any possibility of backing up FlashRAM saves as well? Also, did you have any success reversing the compression format the AR/GS uses? (I already have one AR/GS compressed SRAM save file transferred to my PC using an adaptoid, would be great to be able to use it with an emulator)
     
  16. li38d

    li38d Newly Registered

    Joined:
    Mar 14, 2015
    Messages:
    2
    Likes Received:
    0
    Hi there. I understand that this post is quite old, I haven't been able to find any other good sources of information. I was wondering if you could tell me how you set up the GSuploader. I ask because I haven't been able to get it to work on both my Windows 98, and Windows XP, and Linux machines (Over direct parallel port). I was able to get a previous version of GSupload working on Windows 98, but it was only specifically for a different binary file. Is there a special configuration that I am probably unaware about?

    What I'm trying to do is use GSuploader to grab the SRAM on my Zelda ocarina of time game. Right now, the closest I can get is backing up a compressed version of it through the game shark.

    EDIT: I can communicate in linux as send over Neon64 supposedly fine. I can also send over the sram2mpk but nothing happens after it is sent over. Sometimes the game freezes. Other times it stutters and runs fine. And nothing happens to my nintendo controller pak (Ocarina of Time 1.1 with GS 3.20).

    EDIT: I was able to pull and reconstruct a working save file by dumping the RAM on my N64 and recalculating the CRC. I guess this is no longer needed for me.
     
    Last edited: Mar 18, 2015
  17. protivakid

    protivakid Rapidly Rising Member

    Joined:
    Apr 22, 2013
    Messages:
    96
    Likes Received:
    2
    I too am interested in dumping N64 saves to a PC over a GS with a parallel port. It doesn't seem like the DexDrive option will work. The Majora's Mask save seems to be too large that the GameShark does not show it as an option to copy to the controller pack. Did anyone ever get this working?

    @li38d - It looks like you went another option and sort of constructed a new save with hex editing content from the old?
     
  18. li38d

    li38d Newly Registered

    Joined:
    Mar 14, 2015
    Messages:
    2
    Likes Received:
    0
    For the most part, yes. For some of the saves (When they used EEPROM) I used the DexDrive with my game shark. When the cartridge had an SRAM save I used a RAM dump with the game shark while my game was running. In my specific example I used ocarina of time. But it wasn't as easy as grafting the untouched RAM dump onto a new save. I had to recalculate the CRC and figure out which algorithm it was using. Only after correcting the CRC bits in my grafted save file did it work. Without the corrected CRC bits, the game would only load from my bad save file once and then would not properly save.

    I did a write up on the process here. hopefully that should help some. https://www.kyleniewiada.org/blog/2015/04/transferring-n64-saves/

    According to this page here, http://www.micro-64.com/database/gamesave.shtml, it looks like majora's mask uses a 1 Mb flash RAM save. If I were you, I would try a dump of the entire RAM well the game is loaded through the game shark and see what you can find inside. Just take a look and see what the structure is and if the entire save file is located in RAM. You might be able to graft it onto an existing majora's mask game save. ( CRC checks might also be required. I've never tried anything with flash RAM )
     
    Last edited: Jul 19, 2016

Share This Page