Autosave

Just got a MiSTer and need some help? Join the forum and post your questions here!
User avatar
Malan
Posts: 53
Joined: Sun Dec 27, 2020 5:58 pm
Has thanked: 11 times
Been thanked: 8 times

Autosave

Unread post by Malan »

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.
pcfreak324
Posts: 50
Joined: Mon Jun 01, 2020 12:14 pm
Has thanked: 3 times
Been thanked: 12 times

Re: Autosave

Unread post by pcfreak324 »

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.
ash2fpga
Posts: 237
Joined: Tue May 26, 2020 6:20 pm
Has thanked: 62 times
Been thanked: 28 times

Re: Autosave

Unread post by ash2fpga »

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.
akeley
Top Contributor
Posts: 1303
Joined: Mon May 25, 2020 7:54 pm
Has thanked: 416 times
Been thanked: 399 times

Re: Autosave

Unread post by akeley »

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?
User avatar
jimmystones
Core Developer
Posts: 216
Joined: Sun Nov 22, 2020 1:26 pm
Location: Reading, UK
Has thanked: 32 times
Been thanked: 248 times
Contact:

Re: Autosave

Unread post by jimmystones »

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)
User avatar
Malan
Posts: 53
Joined: Sun Dec 27, 2020 5:58 pm
Has thanked: 11 times
Been thanked: 8 times

Re: Autosave

Unread post by Malan »

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.
User avatar
jimmystones
Core Developer
Posts: 216
Joined: Sun Nov 22, 2020 1:26 pm
Location: Reading, UK
Has thanked: 32 times
Been thanked: 248 times
Contact:

Re: Autosave

Unread post by jimmystones »

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

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 :D
User avatar
Malan
Posts: 53
Joined: Sun Dec 27, 2020 5:58 pm
Has thanked: 11 times
Been thanked: 8 times

Re: Autosave

Unread post by Malan »

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 :/
AtomicShroom
Posts: 170
Joined: Sun Mar 07, 2021 12:28 pm
Has thanked: 31 times
Been thanked: 48 times

Re: Autosave

Unread post by AtomicShroom »

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

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 :D
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.
User avatar
jimmystones
Core Developer
Posts: 216
Joined: Sun Nov 22, 2020 1:26 pm
Location: Reading, UK
Has thanked: 32 times
Been thanked: 248 times
Contact:

Re: Autosave

Unread post by jimmystones »

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!
Piplup87
Posts: 11
Joined: Sun Mar 14, 2021 8:27 pm

Re: Autosave

Unread post by Piplup87 »

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.
Post Reply