I was playing Mother 1+2 on a NDS Lite with R4 card and EZ-FLash 3in1. I had loaded the Mother1+2 GBA file into the PSRAM of the cart. After exiting, I noticed that my .sav file, located on the microSD card, was only 16 bytes in size?! I tried a few other games in PSRAM and they leave save files of irregular sizes ranging from 16 bytes to 8.02 KB. I am able to restore my game normally on the NDS+R4+EZ3in1 but the save file does not work on visual boy advance. Does EZ3in1 store save files in some strange way when you are running the game from PSRAM? For a game in the NOR, I can use GBAtool to extract a usable battery .sav file, no problem.
I have noticed that the 16 byte mother 1+2.sav file was overwritten after I loaded a different game to PSRAM. Now it is 32KB in size. But it still doesn't work in VBA. I looked at it in a hex editor and the first four characters are still AKGB. Then theres a little stuff, a long stretch of 0000 and more stuff. Does the 3in1 or R4 Kernel put some kind of header on the sav data? By comparison, the empty SAV file created by VBA was all FFFF. There must be someone else here who has an R4 with Wood UI 1.62 (latest) and an EZ-Flash 3in1... I want to migrate my SAV file to TEMPGBA on a DSTWO Supercard so that I can save state b/c having to find a phone to save game in Mother 1 is damn annoying. Guess I'll have to start all over again.
Sorry, I must have lost this among my sea of tabs. Saves should be some power of 2 bytes (half a kilobyte through to 512 kilobytes), the reason you see 8.02KB in this case is because WOOD/AKAIO adds a header to the save. This is for good reason as GBA saves have no header and if you do not know what game it comes from then it is a nightmare. As this is not part of any other flash cart setup, emulator...... you will need to remove it. Occasionally you will also need to pad out or remove save data for things like pokemon and some older versions of VBA. You should just be able to slice it off with a hex editor and restore it to have it work in an emulator and putting it back for when you need that, I did have a batch file around here somewhere to use with filecutter ( http://crackerscrap.com/index.php and click on projects) but I will have to search for that and I have to run shortly (I think it was 12 bytes though that should be easy enough to confirm). Alternatively I guess you could use Rudolph's expansion cart management stuff ( http://filetrip.net/nds-downloads/applications/download-gba-exploader-0-58b0mx-f10382.html ) but in some ways that defeats the object. The 3 in 1 (and most other lines of GBA EZ gear starting with the original EZ3) will have several sections of memory to do things with. The loader section (not present on the 3 in 1) The SRAM section, this is what the battery is for and what stores you saves. Also occasionally some data but nobody does that any more. The PSRAM section aka RAM section. This is between 16 and 32 megabytes depending upon the model, though it will always be 16 for the 3 in 1 line. The NOR section. This will be between 32 and 64 megabytes but most programs only use 32 here. The EZ4 lite deluxe used 48 but that is a different matter. If the game has a real save (some games have none and some have passwords or some form) then it will end up in the SRAM until it is removed. The 3 in 1 has no onboard management as far as the end user is concerned and everything is down to what you use to launch it. Technically you can have a game on the NOR and its save along with a game on the PSRAM and its save (it is what older flash carts did to allow multiple games and saves) but nothing beyond a couple of beta EZ5 kernels will do that there.
Does this mean a battery for saves is not needed anymore if we have an EZ5 with mentioned EZ5 kernels and a 3in1 because the save is stored in PSRAM and transfered to the microSD using soft reset?
Well, the file is 32768+16 bytes = 32784. So I tried trimming off the first 16 bytes. No luck it still doesn't work in VBA. Here's what I did. The part I cut is highlighted.
Well, I have progressed far enough in Mother 1 that phone access is no longer an issue. Since it would be a spoiler, I won't say anything about the specifics. Playing the game is more fun than hex editing. Still don't know what is the deal with R4's save file format, but I think I understand a few more things about how R4 handles backing up the sRAM: 1. If you select backup save at startup in the GBA settings, it does just that and appends a header. 2. If you don't select it, only a header is written to the SD. Furthermore, it appears that your save file is not copied to SD until you load a different ROM into PSRAM. 3. The backup file is only usable on the 3in1, loaded from R4 Wood. For example: I started playing Mother 1 last week. I noticed mother1+2.gba.sav was only 16 bytes. But it seemed to work ok. As I played and saved more Mother 1 on saturday, I saw (in the info menu) that the 16 byte file was not being updated b/c it still said it was last modified on thursday. I decided to play a little Activision Anthology (Atari 2600) arcade games on sunday and noticed that mother1+2.gba.sav had been written and was now 32.02KB in size. The AA game save was also just 16 bytes. Switching back to mother 1, this file was updated to 32.02KB, I think. I think R4 Wood GUI is trying to do too much for the user: by modifying the game save file the load/save is almost seamless, but good luck to the average user trying to undo whatever R4 Wood did to the file. I set mine to backup sRAM to SD at startup. Otherwise, it could lose a lot if you don't happen to switch games for a long time--something I am prone to do when playing RPGs-- and the battery fails.
