MiSTer FPGA Forum

lupin3rd wrote: ↑Thu Jul 02, 2020 2:00 pm 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 wrote: ↑Thu Jul 02, 2020 2:29 pm 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).

• 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.

<romname>.srm

lupin3rd wrote: ↑Thu Jul 02, 2020 6:11 pm

retrorepair wrote: ↑Thu Jul 02, 2020 2:29 pm 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 wrote: ↑Thu Jul 02, 2020 2:29 pmI 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.

antibolo wrote: ↑Sun Jul 05, 2020 5:34 am

retrorepair wrote: ↑Thu Jul 02, 2020 2:29 pmI 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 wrote: ↑Sun Jul 05, 2020 9:34 amI know what your saying

antibolo wrote: ↑Sun Jul 05, 2020 1:51 pm

retrorepair wrote: ↑Sun Jul 05, 2020 9:34 amI know what your saying

No, I don’t think you do.

antibolo wrote: ↑Sun Jul 05, 2020 4:52 pm 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.

retrorepair wrote: ↑Sun Jul 05, 2020 5:09 pm

antibolo wrote: ↑Sun Jul 05, 2020 4:52 pm 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 wrote: ↑Sun Jul 05, 2020 5:29 pm

retrorepair wrote: ↑Sun Jul 05, 2020 5:09 pm

antibolo wrote: ↑Sun Jul 05, 2020 4:52 pm 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.

antibolo wrote: ↑Sun Jul 05, 2020 7:14 pm 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.

MottZilla wrote: ↑Mon Jul 20, 2020 8:00 pm 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.