Closed jpxdude closed 6 years ago
The save only happens when you load a different ROM, otherwise it is just in flash on the ESP32. Load up your game and then load a different game, that should save it.
To be honest, this is extremely irritating, and a bit of a quirk. I've just lost hours of progress (about 15+ hours) because the save file isn't generated until you switch ROMS. I think this has to change. I don't switch ROMS that often, so I suspect I'm not the only one that will be losing progress in such a way.
There are plans to remove the internal flash space used for saves. This is a remnant from the pre-psram firmware. A future update should make all emulators save directly to SD card. The challenge is what to do in the event of a SD card error condition at save time.
In the interim, the workaround is to load a different ROM before flashing. This flushes the current save from internal flash to SD card. Another option is to not "erase flash" before updating, but this could cause issues depending on the version being updated from.
Maybe write to flash first then try the SD card. If the SD card fails, display a "retry or cancel" prompt.
I also lost several hours of progress in a game since I wiped out the flash during an upgrade. But I actually expected bugs since this is a new product (not that this is a bug). Now I'm just used to loading some random ROM before upgrades to make sure everything is saved to the SD card.
I agree that there should be a retry option if possible. Maybe another option is to write to flash, then use a 'dummy' ROM to force write to SD.
I understand that there are expected bugs etc, but it is still irritating nonetheless because I can't go back and retrieve my progress. It stings a bit more because I had just caught a SUICINE lol. Lesson learned for now I guess.
Well, the dummy ROM wouldn't be needed. It is just a code change to write directly to SD instead of flash. I think flash is good because I can exit a game and just stuff it in my pocket or yank out the SD card to add another ROM or something. Having it rely only on the SD card for saving game states will likely lead to more occurrences of data loss based on my experience with SD cards.
I think it is still good to have the flash space for saves before flushing to SD, just needs to be done in a more graceful way then having to load another ROM.
Isn't all this writing to the internal flash wearing it out prematurely? I assume it has wear-leveling, but I still don't relish the thought of trying to replace the ESP32 in my ODROID because of worn-out flash memory... Maybe some forward error-correction added to the save-file would make the SD saving more reliable. Is there an open-source Reed-Solomon implementation out there somewhere?
The flash should have 100,000 program/erase cycles per block (64K). The save game storage is wear leveled (SPIFFS filesystem) using 4K sectors across 1MB.
On a somewhat similar topic (please let me know if this should be a separate issue), the GBC emulator doesn't seem to accept save files from other GBC emulators (or saves ripped from a cart) anymore. It worked on the previous firmware that shipped with my ODROID-GO (it was dated early June), but no longer works on the 20180712 firmware I just upgraded to.
Also, I thought I read somewhere that the ".sav" file the odroid-go is dumping to the SD card contains both the Game save as well as the game state (and possibly RTC as well?). Would it be possible to split these out to two files, like many other emulators do? That would make it much easier to load the save into another emulator, back onto a cart, or run through a game save editor. Worst case, a simple script / program to strip the game save out of the ".sav" file would do for my situation (after the issue I mention above is resolved, that is). I'm sure I could create my own script if I knew the start / end hex addrs of only the game save with the .sav file.
the GBC emulator doesn't seem to accept save files from other GBC emulators (or saves ripped from a cart) anymore.
This is likely due to the changes supporting large SRAM in the save state. Using save states from other systems is not a supported feature. This was previously discussed, and the best solution is to write a PC tool to convert save game data. The data format can be found in the source code here: https://github.com/OtherCrashOverride/go-play/blob/master/gnuboy-go/components/gnuboy/save.c
I'm sure I could create my own script if I knew the start / end hex addrs of only the game save with the .sav file.
int irl = hw.cgb ? 8 : 2;
int vrl = hw.cgb ? 4 : 2;
...
sramblock = 1+irl+vrl;
...
fseek(f, sramblock<<12, SEEK_SET);
Save state is directly written to SD card with the latest release: https://github.com/OtherCrashOverride/go-play/releases/tag/20180718-smsplusgx
Closing since current releases directly save/write to SD card.
It appears that data is not being retrieved from or saved to the regular location on the SD card (\Odroid\Data\)
I only noticed this because after flashing to the latest next gen firmware, it lost my latest pokemon crystal save. I experimented by removing the .sav file in the \odroid\data\gbc\ directory, and the save still loaded saved and retrieved directly from the odroid, but it isn't doing this to the SD card.
Is there a way of reinstating the retrieval/storage of data saves from the .sav files on the SD card?