Hmmmm! Could we: Take over a small area of memory (the difficult bit) that intercepts calls that want to save/load - switches in a predefined bank of the FlashRAM that would hold all the code we need to do this with . . . Now I know the the answer is going to be no, however, I always say "don't say no" say "I can't think of a way, at the moment" - and then let's ponder on this matter. At some point I'll need to make another batch of MGCs - an ideal opportunity for a redesign (needs to be Master compatible too, this time) - Good for sales too e.g. all the latest features that people will just have to have
Just as a game finishes loading, we could switch to two separate ROMs. The first would contain code to handle loading and saving, perhaps using the ROMFS, though that doesn't support saving (as far as I know) so maybe a different filing system would need to be used. The second would initially be "blank" and could be used for saved games.
If you used ROMFS for this, the first ROM would need to be able to encode ROMFS data and flash it to the second ROM in the correct place. Since ROMFS data ends with a &2B marker, I imagine it might be possible to update it to be &2A and extend the data. Loading would just work because the second ROM would become normal ROMFS storage. Erasing the ROM might be unreliable, however. The code to perform the writing would have to be (temporarily) located in RAM because the first ROM will be paged out so that we can access the second ROM. Maybe it would be possible to just use one ROM if the saving code was small enough.
Using a custom filing system might be better but, as I've never written one of those, I don't know how much work it would be.
This would only work for games that are completely in RAM and don't need to load more parts after the user has loaded or saved their own files.