Autosave

[Alkadian]

Guys,
Do you know by chance how to enable the Autosave option? I can see that the option is there in the Snes core menu but it is off and greyed out so I cannot change it at all.
Thanks a lot!

[Sigismond0]

You need to make sure you're doing it from a game that actually has saves. The setting appears to be disabled for anything that doesn't have save data.

[Alkadian]

Hi,
Thanks for your feedback.
I tend to believe that the autosave works only for some specific games and not for all the them. I have tried for instance Chrone Trigger and it worked absolutely fine. However, for certain games like my beloved R-Type 3 it doesn’t work. The line Autosave is greyed out.

[Sigismond0]

R-Type 3 doesn't appear to have saved games at all. There's no load/resume option on the main menu, and it doesn't look like it has a high score list either. If there's nothing that gets saved, there's nothing to autosave.

[lupin3rd]

Seems there might be some confusion about what Autosave actually is. From the sounds of it, it is not a full-blown save state option -- that is, an entire dump of RAM as we are accustomed to seeing on emulators. I believe this has been covered in other places, as there are technical hurdles that make save states very hard to do on an FPGA implementation. I mean, yes, where there's a will, there's probably a way -- but it could be a very bad way riddled with problems that create more issues than they fix.

But that does beg the question, how does the core know which games support SRAM saves, and more importantly, how does it know which game variables belong in that SRAM? Or is it a really "dumb" feature, that basically just flushes the SRAM save files to disk every time a write to that location in memory occurs? Or put another way, it will write the SRAM in memory to disk every time the game actually performs a save, guaranteeing that the SRAM save is caught and available on the next load of the core/game.

[retrorepair]

But that does beg the question, how does the core know which games support SRAM saves, and more importantly, how does it know which game variables belong in that SRAM? Or is it a really "dumb" feature, that basically just flushes the SRAM save files to disk every time a write to that location in memory occurs? Or put another way, it will write the SRAM in memory to disk every time the game actually performs a save, guaranteeing that the SRAM save is caught and available on the next load of the core/game.

I can't be 100% sure but I would assume the core reads the header as this will specify if it uses SRAM or not. This will be why some games have this option greyed out as their header doesn't say it supports SRAM (or another form of data backup).

If the game then writes save data to a specific space in memory then the core will see this and prompt you to press the menu to save the SRAM data by lighting the green LED (if autosave is enabled, if you you must manually save SRAM data in the menu).

I still don't understand why SRAM isn't just saved when it happens, I suppose maybe to avoid massive amounts of data being written to SD or to avoid writes being interrupted by a power off? It's not much of a hardship to press the menu button but it's also not clear that this is needed IMHO.

[lupin3rd]

I can't be 100% sure but I would assume the core reads the header as this will specify if it uses SRAM or not. This will be why some games have this option greyed out as their header doesn't say it supports SRAM (or another form of data backup).

I don't know why, but I always forget that most console ROM files still have the metadata headers in place. That would definitely be the easiest route to determine whether or not it saves to SRAM. I probably keep forgetting because I gravitate to arcade cores on the platform, which are composed of the raw ROM data.

It looks like SRAM is usually accessible at one of a couple places, depending on which mapper is in use. I guess the header is probably required for a couple different reasons:

• On the real console, the system is blissfully unaware of what mapper chip is being used as it exists in the cart itself
• For MiSTer to know where SRAM is located, the mapper type needs to be known (and without a cart, the header is the only sure-fire way to be certain). See previous bullet.

I would think a change in wording would make it clearer for users. Maybe just having a catch-all setting with a different name like "Commit game saves to disk" or some other slightly less ambiguous wording would make it easier to turn the feature on and leave it on, despite whether or not the current game uses SRAM. It could always just default the SRAM filename to

Code: Select all

<romname>.srm

or something similar.

[retrorepair]

I can't be 100% sure but I would assume the core reads the header as this will specify if it uses SRAM or not. This will be why some games have this option greyed out as their header doesn't say it supports SRAM (or another form of data backup).

I don't know why, but I always forget that most console ROM files still have the metadata headers in place. That would definitely be the easiest route to determine whether or not it saves to SRAM. I probably keep forgetting because I gravitate to arcade cores on the platform, which are composed of the raw ROM data.

It looks like SRAM is usually accessible at one of a couple places, depending on which mapper is in use. I guess the header is probably required for a couple different reasons:

• On the real console, the system is blissfully unaware of what mapper chip is being used as it exists in the cart itself
• For MiSTer to know where SRAM is located, the mapper type needs to be known (and without a cart, the header is the only sure-fire way to be certain). See previous bullet.

I would think a change in wording would make it clearer for users. Maybe just having a catch-all setting with a different name like "Commit game saves to disk" or some other slightly less ambiguous wording would make it easier to turn the feature on and leave it on, despite whether or not the current game uses SRAM. It could always just default the SRAM filename to

Code: Select all

<romname>.srm

or something similar.

Just to be clear, even with auto save turned on, you still need to press the menu button to commit it to disk. The green LED indicates when save data is present.

[antibolo]

All SNES games were required to have a metadata block for certification purposes that describes various details about the intended cartridge (memory sizes, map mode, enhancement chips, etc.). It is not read by the real hardware but happens to be extremely convenient for emulators and such (unlike systems like the NES where the emulation/copier scene had to make up a header format to describe those details). Among that data, it includes the size of the cartridge SRAM as well as whether it's battery-backed or not.

[antibolo]

I still don't understand why SRAM isn't just saved when it happens, I suppose maybe to avoid massive amounts of data being written to SD or to avoid writes being interrupted by a power off? It's not much of a hardship to press the menu button but it's also not clear that this is needed IMHO.

It's not that simple, SRAM is literally just RAM that's mapped directly to the CPU addressing bus and can be freely read or written to at any time, it's not an atomic operation with a clear beginning and end like writing a file on a computer (open file, write data, close file), but rather just a bunch of "store X at byte Y" with no "open" and "close". Should the core be committing every change to disk immediately like you're suggesting it should, it would have to rewrite the entire file after each individual byte changed in SRAM, one at a time, which would be insanely wasteful. Therefore, flushing SRAM to disk only when entering the menu is a reasonable compromise.

[retrorepair]

I still don't understand why SRAM isn't just saved when it happens, I suppose maybe to avoid massive amounts of data being written to SD or to avoid writes being interrupted by a power off? It's not much of a hardship to press the menu button but it's also not clear that this is needed IMHO.

It's not that simple, SRAM is literally just RAM that's mapped directly to the CPU addressing bus and can be freely read or written to at any time, it's not an atomic operation with a clear beginning and end like writing a file on a computer (open file, write data, close file), but rather just a bunch of "store X at byte Y" with no "open" and "close". Should the core be committing every change to disk immediately like you're suggesting it should, it would have to rewrite the entire file after each individual byte changed in SRAM, one at a time, which would be insanely wasteful. Therefore, flushing SRAM to disk only when entering the menu is a reasonable compromise.

I know what your saying, but as the green LED indicates, this doesn't happen all that often.

If you play super metroid for example, the green led will only illuminate when you save in game so this says to me, the core definitely knows when there's something to save.

The vast majority of games on snes at least require a manual save process so sram doesn't change at any other point. Therefore I'd say the amount of data writes are far from "insane".

[antibolo]

I know what your saying

No, I don’t think you do.

[retrorepair]

I know what your saying

No, I don’t think you do.

Well you may think I don't, but I do.

SRAM is mapped to an address that is used exclusively for save data. If it were used as any other part of memory it would corrupt your save.

The core DOES know when SRAM has changed as indicated by the green LED that ONLY illuminates when sram has changed and that only happens when you hit save in the game or register your name etc.

Try it for yourself.

[antibolo]

Of course it knows when writing begins, what it can't automatically know is when it ends, because again, it's not an operation with a "open" and a "close".

With that said, some emulators work around this by waiting for the writes to have stopped for a given period of time as a sign that ok, the game is probably done writing a save file and so the SRAM should be saved. That might be difficult to implement in a MiSTer core though, I don't know.

Furthermore some games might write to SRAM often enough that this workaround would still be a problem regarding writing to the SD card too often. I know at least some NES games use the SRAM not just for saving progress but also as an additional conventional RAM store, since the NES only has a minuscule 2KB of main RAM to work with.

In any case my point is that this isn't as trivial to implement as you think.

[retrorepair]

Of course it knows when writing begins, what it can't automatically know is when it ends, because again, it's not an operation with a "open" and a "close".

With that said, some emulators work around this by waiting for the writes to have ended for a given period of time as a sign that ok, the game is probably done writing a save file and so the SRAM should be saved. That might be difficult to implement in a MiSTer core though, I don't know.

Furthermore some games might write to SRAM often enough that this workaround would still be a problem regarding writing to the SD card too often. I know at least some NES games use the SRAM not just for saving progress but also as an additional conventional RAM store, since the NES only has a minuscule 2KB of main RAM to work with.

In any case my point is that this isn't as trivial to implement as you think.

I never suggested it would be trivial, I don't think you fully read my initial post. I did say pressing the menu button to save isn't a big problem.

I didn't know there were NES games that used the cart ram as extra wram, though this does make sense. Do these games report battery backed ram in their header?

[antibolo]

Of course it knows when writing begins, what it can't automatically know is when it ends, because again, it's not an operation with a "open" and a "close".

With that said, some emulators work around this by waiting for the writes to have ended for a given period of time as a sign that ok, the game is probably done writing a save file and so the SRAM should be saved. That might be difficult to implement in a MiSTer core though, I don't know.

Furthermore some games might write to SRAM often enough that this workaround would still be a problem regarding writing to the SD card too often. I know at least some NES games use the SRAM not just for saving progress but also as an additional conventional RAM store, since the NES only has a minuscule 2KB of main RAM to work with.

In any case my point is that this isn't as trivial to implement as you think.

I never suggested it would be trivial, I don't think you fully read my initial post. I did say pressing the menu button to save isn't a big problem.

I didn't know there were NES games that used the cart ram as extra wram, though this does make sense. Do these games report battery backed ram in their header?

Some NES games do include non-battery-backed SRAM (SMB3 is a notable example) that's purely used as extra RAM (and the iNES header has a "is the SRAM battery-backed" flag so emulators/fpgas know they don't need to save it).

However for games that *do* have the battery-backed flag, whatever SRAM space the game doesn't use for saving progress can also be used for extra RAM. For instance I know that The Legend of Zelda writes to SRAM on every screen change.

[retrorepair]

Of course it knows when writing begins, what it can't automatically know is when it ends, because again, it's not an operation with a "open" and a "close".

With that said, some emulators work around this by waiting for the writes to have ended for a given period of time as a sign that ok, the game is probably done writing a save file and so the SRAM should be saved. That might be difficult to implement in a MiSTer core though, I don't know.

Furthermore some games might write to SRAM often enough that this workaround would still be a problem regarding writing to the SD card too often. I know at least some NES games use the SRAM not just for saving progress but also as an additional conventional RAM store, since the NES only has a minuscule 2KB of main RAM to work with.

In any case my point is that this isn't as trivial to implement as you think.

I never suggested it would be trivial, I don't think you fully read my initial post. I did say pressing the menu button to save isn't a big problem.

I didn't know there were NES games that used the cart ram as extra wram, though this does make sense. Do these games report battery backed ram in their header?

Some NES games do include non-battery-backed SRAM (SMB3 is a notable example) that's purely used as extra RAM (and the iNES header has a "is the SRAM battery-backed" flag so emulators/fpgas know they don't need to save it).

However for games that *do* have the battery-backed flag, whatever SRAM space the game doesn't use for saving progress can also be used for extra RAM. For instance I know that The Legend of Zelda writes to SRAM on every screen change.

Ok, well a few bytes on a screen change isn't horrendous in my opinion. I do wonder about those games which use part of the battery backed ram for wram though, if the core (or emulators etc) would then write the whole sram to disk. They must have a way round constantly writing to disk in real time?

[retrorepair]

To be fair, an auto save every 10 seconds (if data has changed) may be a good compromise.

That said, again, how it works now is fine, just have to remember to hit the menu button before powering off.

[antibolo]

I've literally just explained why this isn't a good idea, via the Zelda example.

Anyway we're going in circles now, I'm done here.

[retrorepair]

I've literally just explained why this isn't a good idea, via the Zelda example.

Anyway we're going in circles now, I'm done here.

How is that a good example? It doesn't address my last post.

10 second intervals between (very small) writes isn't exactly a problem for SD cards, even if the data has changed, which in 90% of cases, it won't have (and if it hasn't, don't flush to disk). Sorry but that's a fact.

I'll not point out again, but how it works now is fine. Just posing my thoughts (god forgive me for having ideas).

*EDIT*

Just did some Googling and this is exactly how Retroarch handles saves across multiple platforms:

https://github.com/libretro/RetroArch/i ... -577363873

[KneeTie]

I think the possibility of having this option, at user discretion and with an alert, is a welcome one.

[Poeskas]

I second this.

[MottZilla]

I don't see why the current method is so hard to deal with. Save your game in the game itself, then press the menu button. Simple.

In your suggestion of auto saving every 10 seconds, now when you save the game in the game you need to wait atleast 10 seconds in the worst case scenario for the save data to be backed up. Seems like a worse idea to me. Plus there is the chance introduced with this rolling arbitrary time window that it could decide to write the data to SD card while the SRAM is in the middle of being written resulting in waiting another 10 seconds. So now instead of saving your game and then pressing the menu button you're going to save your game and stare at the LED light hoping it goes out. And as previously mentioned a game can use SRAM as scratch RAM for any purpose they want. Many games are well behaved and solely use SRAM for save file data, others are not.

While options are nice in this case some users might find it causing problems. Antibolo pretty much explained all this before. The current system really is the best option. The user's actions determine when saving to the nonvolatile memory happens rather than some messy automatic attempt to make up for laziness or forgetfulness.

[retrorepair]

I don't see why the current method is so hard to deal with. Save your game in the game itself, then press the menu button. Simple.

In your suggestion of auto saving every 10 seconds, now when you save the game in the game you need to wait atleast 10 seconds in the worst case scenario for the save data to be backed up. Seems like a worse idea to me. Plus there is the chance introduced with this rolling arbitrary time window that it could decide to write the data to SD card while the SRAM is in the middle of being written resulting in waiting another 10 seconds. So now instead of saving your game and then pressing the menu button you're going to save your game and stare at the LED light hoping it goes out. And as previously mentioned a game can use SRAM as scratch RAM for any purpose they want. Many games are well behaved and solely use SRAM for save file data, others are not.

While options are nice in this case some users might find it causing problems. Antibolo pretty much explained all this before. The current system really is the best option. The user's actions determine when saving to the nonvolatile memory happens rather than some messy automatic attempt to make up for laziness or forgetfulness.

You made a lot of assumptions there. Why would you not want to option to save if the save is available? I don't see why the two can't coexist as an option but regardless, you obviously didn't read what I wrote either because I've said repeatedly:

THERE'S NOTHING WRONG WITH THE CURRENT METHOD.

I give up trying to have a resonable conversation on this forum, people who have a rough understanding should not behave like they know it all because invariably, they don't.

[MottZilla]

Perhaps then you did not read all of my point. I did read your entire post. I said the autosave suggestion might be a nice option to have, but pointed out part of why something like that is not implemented (yet) is most likely because of certain potential problems that exist with the idea compared to the current method of doing things which doesn't have those issues. You assumed my position is that I don't want this feature but I'm only discussing the idea and how it would or wouldn't work.

I think you are taking criticism of an idea personally. You shouldn't. I don't know if you're directing your comment of " people who have a rough understanding should not behave like they know it all because invariably, they don't." toward me but I'm commenting based on my own experience which includes writing several emulators and hacks and patches. My input on the idea of implementing an autosave feature is based on those things. I would never claim to "know it all". No one does.

If you have a solution or counter argument about how auto saving can be implemented without these issues or how the positives outweigh the negatives feel free. I can continue the conversation about auto save.

So if you are going to auto save something like 3 seconds after the last SRAM write that may work well for certain games or certain platforms as I said before. But if a game uses the SRAM also as extra RAM or uses just part of it for any reason on a regular basis for non-data backup you'll get a lot of false positives that you should save SRAM to the SD card. So now a decision must be made on how you deal with that. One option is we could leave the LED indicator on hoping the user realizes they will have to call the menu to backup their save or maybe have an on screen message that can be toggled to warn the user that autosave has been disabled and hope they see it. The key goal is to be sure that users don't end up losing their save data by a hole in the expected save system. The only hole in the current system is the user forgets to press the menu button after saving in the game. You introduce new ones with the auto save if it does not work as hoped. Do you have a better idea than what I suggested as a way of coping with the potential problem of not being able to rely on typical SRAM write behavior?

[retrorepair]

It was more directed toward the general populous and my rapidly declining patience with it, but since you are willing to explore this, let's do it.

RE games which use SRAM as expansion RAM, which games are these? I'd wager it's limited to NES and other systems of this generation and since SRAM backup is handled per core maybe some exceptions can be made as opposed to being the rule? Are there a lot of games which do this?

Do any SNES games do this?

Do Megadrive/Genesis games do this?

I'm certain no AES games will.

MVS backup RAM I don't believe is suitable for autosave unless the vector is narrowed to the data and skips the RTC.

I've actually been doing some testing with SNES games and monitored when they write to SRAM (using the LED as a guide) and I've yet to find a SNES game which would cause an issue. I've compiled a test build of the SNES core that I've modified to save as soon as SRAM has changed and so far, again, no issues.

I understand that writing to the SD during a power cycle lends itself to corruption, but doesn't any write to SD?

[wesclemens]

Isn't this a problem with the SNES directly? If I was to power cycle a real console while it was in the middle of writing to the SRAM wouldn't it be corrupted.

Also, doesn't all the same corner cases exists when the menu is open? (e.g. if I opened the menu while the SRAM was being written.)

Maybe, the last 3 saves can be preserved to the SD card this way if the latest save is corrupted you could recover from one of the older.

[bootsector]

What I do here so I never have issues with lost/corrupted saves:

- Make sure autosave is ON in cores
- Wnen finish playing and saving in-game, open OSD then perform a cold reboot (select reboot option, keeping it pressed)
- Turn MiSTer off

Performing a cold reboot ensures (save) file buffers are flushed to SD card.

[MottZilla]

NES is the primary system where battery backed SRAM also gets used for general expansion RAM. SNES already has a very large amount of RAM so the relatively small amount in a cartridge would be unlikely to be used for anything other than data backup. However it's possible a hack could steal some unused portion for this purpose so I wouldn't rule it out.

Genesis is in the same boat as the SNES, very little is added and the base system has far more so it seems unlikely to be used for other purposes.

MVS/AES is probably well behaved but I am not sure.

Compiling a list is a good idea.

[Optiroc]

SNES hacks commonly use cartridge RAM as scratchpad, especially for custom text rendering in translation hacks.