MiSTer FPGA Forum

I forgot to open the OSD to save my game again... Yeah, my bad, I know... but then I wondered, why do you have to manually open the OSD to save the ram in a save file in the first place? What's preventing continuous or a periodic autosave?

Thanks.

The problem is that the core has no way to tell if there is new data to be saved. Continuous or periodic autosave would increase the wear on the storage medium. That is why autosave was implemented the way it is, that it only writes the data from RAM to the storage medium when the user opens the OSD.

The autosave topic has been rehashed a few times. It seems like at this point it would need to be a new dev with interest, to implement something themselves, which may or may not makes its way into the core mister framework.

Would it be possible to make autosave available only per-game (not per-core) and with adjustable interval?

Also, how big is the wear problem regarding SD cards?

Wear on the SD is not the only concern - because a user could reset/power off the MiSTer at any time there is always the risk of corruption if writes are happening behind the scenes. With the OSD triggered method that is far less likely to occur (although obviously not impossible)

I understand the problem with SD cards but it's not the only way to save (I use a mounted NAS drive, so it's saving on my NAS, not on the SD card, which is awsome btw).
For the risk of corruption, a solution could be to make a new .bak file evey time a save is completed, so if your main save file is corrupted, you delete it and rename the .bak file. If that's even possible of course.

Don't get me wrong, I would love it to just autosave and work perfectly

One issue with the backup concept is you only find out that a save is corrupted when it reloads, and by the time you find that out it'll probably have autosaved over the good backup!! As with all engineering problems I'm sure there is a way to get a robust system but that would take a lot of development time.

In my little arcade corner of the MiSTer we are only just getting the autosave triggered on OSD open implemented

Oh I see what you mean! I assumed that when a file is corrupted it can't be read again, but if the core can still read it (incorrectly), that's an issue indeed :/

jimmystones wrote: ↑Tue Aug 17, 2021 8:10 pm Don't get me wrong, I would love it to just autosave and work perfectly

One issue with the backup concept is you only find out that a save is corrupted when it reloads, and by the time you find that out it'll probably have autosaved over the good backup!! As with all engineering problems I'm sure there is a way to get a robust system but that would take a lot of development time.

In my little arcade corner of the MiSTer we are only just getting the autosave triggered on OSD open implemented

The NES/SNES Classic from Nintendo pull this off elegantly with no problems.

If you open the save data for any game, you’ll notice that it has two files, cartridge.sram and cartridge.sram.hash, which contains a hash of the sram. This way if there’s ever a mismatch between the contents of the sram and hash file, it knows something is corrupted.

When you power off the device, it doesn’t instantly power off but shows “shutting down…” on screen for a second, allowing the device to finish any ongoing writes to storage. This makes it so the chance of corruption will only ever occur if the power is forcibly cut by pulling the plug or a power outage.

Lastly, for games which use sram as work ram, it has an internal list of those and makes sure to only save when there’s a write to the specific memory address that contains the save data, so as to avoid wear to the storage.

Something is definitely possible if someone is motivated enough to implement it.

Edit: Also, just what are the odds that you'll shut down your MiSTer during the exact milliseconds it takes to write a few KBs file? I'd rather have that risk than yet again losing hours of progress because I forgot to open the OSD before shutting it off. It feels so incredibly backwards and archaic.

Yep, as I said it's not an impossible problem, just that someone would need to spend their time developing it. It would mean changes to the main framework on the Linux side plus changes, rebuilds and testing on every single core that supports autosave... Certainly not an insignificant amount of effort!

The Everdrives have a similar issue. With the 64x5 the save won't be retained if you turn the console off, it's only retained if you reset the console which gives the cartridge the chance to commit the save. The x7 instead holds the data separately and commits it to the SD card the next time the console is powered on (my understanding of this may be overly simplified).

I am in every way completely ignorant so I will defer to others on whether the solution employed with the everdrives has any bearing on this topic, my uninformed assumption is that this method on the MiSTer would require a different set of hardware to accomplish the same functionality in the same way, which sounds prohibitive but may get around the concern of having to take apart and rebuild the Linux stuff from scratch.