Gba vc support #344
Gba vc support #344
Conversation
|
I'm the "certain someone" that thought this was cursed. At the time I was misremembering something I read on 3dbrew: I had thought that the PXI sysmodule might svcBreak if it received two requests on the same handle. I was wrong; it's Process9 that would do that. However, Process9 is never directly handled in this implementation, with everything instead going through the PXI sysmodule, which makes sure that this never happens. As such, I no longer consider this cursed, and instead ingenius |
|
On another note, I've just submitted a PR to ctrulib that adds a more complete FSPXI interface. If they accept that, I would rather rework the backend of this interface to use that. This code is wonderful proof that this approach works, but using a standard interface rather than a custom one would be better. |
|
Another note while I'm thinking about it: there's more to the save manipulation than is handled here. This works for exporting a noneditable single-system save, but it's not a raw GBA save like would be expected by... well, anything other than Checkpoint. I'm hoping to figure this out (working on it in PKSM) to change that, but this implementation does provide a core backup feature. |
|
This GM9 issue was linked in issue 344, but I'm putting it here for central access, as well. Another note from my research with PKSM: I think that FSPXI_CalcSavegameMAC should handle the CMAC, but I'm not certain to what degree. |
|
Will wait until the rework is pushed to merge this |
FSStreams can now contain either a Handle or a FSPXI_File, using a variant same idea is applied in the io namespace to reuse code instead of the big copy paste used before
|
After the rework is pushed, there are a couple things that need to be changed in this that I just want to document: The GM9 issue linked in my comment above describes how to extract saves from the raw file; that will need to be done by the GBA handling code. Also, in PKSM, I switched to an object-based archive API. I think combining that with an abstraction from actual archive manipulation to a Save class which would handle the actual backup/restore operations would make the actual handling code a whole lot cleaner. |
|
please update this it keep crashing! |
GriffinG1
added
3ds
Based on the theory in Plailect/nimsm you can kill fs to make requests to fspxi which allows you to read decrypted raw savefiles, which the GBA VC saves are (unlike regular games which are filesystems inside the file).
Taken one step further, since the application is rosalina/luma-only, you can use the nifty little things it adds, namely: a session stealing SVC ! No longer need to kill fs, just zippety zap its handle to fspxi and off you go.
That's basically it, with a little interface for reading/writing files (the file path is always the same), and opening/closing PArchives (a separate archive type to avoid passing fs' FS_Archive to it).
It's pretty cursed according to a certain someone, but it works, I tested it. Both dumping and restoring, as well as adding to cache (the accessibleSave cache byte for each entry is now a bit flag, 1 for saves, 2 for GBA vcs).
I dont think it's up to your standards, but I'll leave it here if anyone wants to take a look and maybe reimplement it.