Godmode9: Feature Request - Save Management for DS/3DS Cartridges

[JoshuaDoes]

Hello again!

I have a feature request and I'm unsure of where else to place this. I've noticed that GodMode9 has full support for dumping the ROM file in either full or trimmed format for DS cartridges instead of only 3DS cartridges, but one thing I'd like to have implemented is the ability to dump and replace the save data on the cartridge. A good place to look at for reference is TuxSH's TWLSaveTool homebrew, where the feature is fully implemented as its own app in userland and also installable as an app for the system.

Thank you for all of your hard work once again!
If this cannot be done, all I ask is for an explanation as to why. However if it is just something you don't wish to focus on right now, that's also fully understandable and I wish you good luck with all else!

[d0k3]

That feature is, in fact, on my own wishlist:
https://pastebin.com/Sp2GmWda

Problem is, userland code works differently and most likely won't do the trick. I could use help from someone else willing to figure this out, for 3DS game saves, too.

[JoshuaDoes]

I'm glad you're at least looking into it, and having support for 3DS game saves as well would be amazing too!

Userland code definitely is different since a lot of stuff is there to help out but with programming for the actual ARM9 none of that is there, so it's completely understandable. I wish I knew enough myself to figure this out, and if I did I'd probably have submitted a pull request with it by now. Hopefully progress may come to light eventually :)

[WubTheGame]

I bet Godmode9 will soon be the ultimate 3DS tool. besides, it's called Godmode9, the clue's in the name.

[JoshuaDoes]

It already is the ultimate 3DS tool, aside from things currently done within regular homebrew such as CIA installation and DSP firm dumping (which would be neat to have in GM9, but I don't know the specifics and thus am not sure if that's possible despite our level of access).

[WubTheGame]

oh cool.

[ValiantStorm]

@JoshuaDoes I think DSP firm dumping as it stands using DSP1 or DSPDump relies on other titles (HOME Menu?) having a valid DSP firmware in memory. It's definitely present on the NAND as well, though, probably in the files for some system title.

[purringChaos]

I would LOVE to see this implemented.

[SirNapkin1334]

I think DSP dumping is arm11 code, but GM9 is arm9 homebrew. Payloads = arm9, anything else = arm11. You can do a lot of stuff on one that you can't do on the other. Save management would be cool though, since I'm sure we could write to the save flash on arm9.

[cheatfreak47]

I'd love to see this implemented as well, because if it's possible to do this in GM9, you may also be able to add support for games that use NAND flash for saving, such as WarioWare DIY, which don't work with any of the typical 3DS save dumping options.

[Masamune3210]

Pretty sure DSP firmware is present (encrypted?) in the files for the system menu, or one of the early boot services. Possibly possible to grab if found and possibly decrypted, but not really worth it in my opinion since you only need to grab it once and apps already exist to grab it.

Being able to manipulate the save on a NTR/TWL card would be nice, but complicated, as there are quite a few different types of chips used for saves if i remember correctly

[ParzivalWolfram]

It should easily be possible to just request reads from the SRAM on the cart and stream them straight to file, since you can probably reuse some of your ROM-dumping code for that. Only issue is that that'd need either a lot of memory or a lot of time...

[dratini0]

I have been looking at this problem. I have noticed that you made a branch for this back in 2017, but it got into an infinite loop somewhere. However, I have also noticed the file arm9/source/gamecart/card_eeprom.c , which seems not to be referenced anywhere, and which seems to be as old as gamecart support itself . What became of that?

Additionally, from what research I did, it seems to me that DS and 3DS saves are just SPI flash chips, sharing some of the pins with the ROM. The difference with the 3DS is just that it can also use QSPI. Does that mean that 3DS save dumping is essentially the same as DS save dumping?

[dratini0]

Update: I have been making significant strides toward making save management happen, at the moment I am consumed with the intricacies of writing these memories.

I am also hoping that I can figure out how to deal with problematic games like WarioWare DIY (bizarre single package solution), or Art Academy (reportedly a Macronix flash chip, might be similar to 3DS saves).

What I don't expect to figure out anytime soon is the delightful layercake of savegame wear-leveling, encryption, and the DISA container, in which a FAT filesystem resides. It does seem to be well-documented on the 3Dbrew wiki, however I don't really understand how 3DS crypto works.

[profi200]

For SPI flash chips it's pretty much always the same. First you send a write enable cmd and poll until the write enable bit is set in the status reg. Then you can use the flash write cmd. Note: You must write only one flash page at a time and then you must poll the status reg again until it is not busy writing anymore. The new SPI hardware on 3DS luckily has an interface that let's you automatically poll a single bit in the response.

Also there are certain games storing the savegame on the "ROM" itself (on 3DS these are the famous CARD2 games). No one figued out how to write savegames to these but reading is as easy as reading the right "ROM" area.

[dratini0]

The thing that worries me is the 0x0a command. It enables writing a single page, without erasing it first. This is done by reading out the page, modifying it as the user intended and then erasing and writing it back. However, it is not documented anywhere other than GBATEK. It also seems to happily do non-page-aligned writes, which goes even against GBATEK. The page size also seems smaller than the smallest documented erase command, and on some cards (but not others) works several times slower than sector erase and write, which implies to me that it is actually doing sector erases and writes. So now I am writing a tool that can discover these things.

[profi200]

I would not use undocumented write cmds. Stick with the official ones since they are faster and page aligned. Unaligned ones may cause unnecessary wear to the flash.

[dratini0]

Okay, I have been overthinking this. I have been looking at the wrong datasheet. I have looked at datasheets for ST M45PE20 (0x204012), ST M45PE40 (0x204013), and Sanyo LE25FW203A and each of them document page erase (0xDB) and page write (0x0A), without concerns for lowered cycle life.

I have also figured out that page writes crossing page boundaries don't work, I was just doing my testing completely wrong.

It is however worth noting that the Sanyo part, while does support page write, it seems to be dog slow, slower than sector erase and write for anything over a few kilobytes, and about 5x slower for the whole chip. I might try to implement that, since a similar strategy is necessary for the Macronix chips in the 3DS carts anyway, and save management is mostly copying full images back and forth.

[d0k3]

Well, who would have expected this - a feature request from all the way back in 2017, when GM9 was barely one year old can finally be closed.

Made possible by @dratini0's recent commits. Thanks you, @dratini0 - you made that possible! I hope @JoshuaDoes actually still gets notified about the progress.

[JoshuaDoes]

@d0k3 I just got notified, I'm glad to hear! Thank you @dratini0 for the effort :P