Any solution yet for MiSTer to autosave without hitting OSD?

[VagrantCS]

So... I know this has been asked over a year ago and I'm aware of Sorg's concern about the risk of corrupting the SD card. I'm coming from RetroArch and find it kinda... strange that the MiSTer can't autosave in-game to the drive without damaging it. Has there been no new ideas/solutions/work arounds that the team/community has come up with yet to solve this issue to protect the SD card from constant rewrites?

Reroute to USB stick? A battery backup add-on similar to the MiSTer real-time clock? A script to "stealth" flash OSD on & off every x secs/mins? Code to "detect" new data that always write so it could save every 20-30 secs when the yellow light glows (using a MiSTer Pi)? Program multiple saves slots that are x secs behind the latest save incase the MiSTer powers off during a write?

FYI I'm not a coder, just a casual gamer. I don't know how any of this stuff works, I have no idea if my dumb ideas are possible (laughable even) and I'm just hoping this feature could be solved (or circumvented) cause IMO it's the only thing holding it back for me to setup the ultimate TapTo experience where guest will never have to deal with the OSD while data writes safely in the background.

I'll be willing to make a donation if this can be figured out, I have faith that it can be solved. BTW Thanks for all the hard work you put in the MiSTer project everyone has put in over the years. You're preserving history!

[birdybro]

Comparing Retroarch to MiSTer is comparing Apples to Oranges, or as the saying goes in Russian "сравнивать тёплое с мягким" (at least according to google).

Retroarch can get away with saving the way it does with low risk of save corruption specifically because it is software emulation. FPGA-based emulation/simulation makes this more difficult. You could probably transmit from the FPGA and then hold the sram data in some kinda cache on the ARM processor side and watch it for changes etc... but the ARM processor has limited resources available with some of the cores that push the system to it's limits in terms of the "time" domain. There are some games on NES and other platforms that use this memory space as extra memory, so the SRAM would be seen as updating multiple times a second. This would cause the bus on the ARM side to probably stutter for other important duties.

Writing to a MicroSD multiple times per second the whole time you are playing some of those NES games is also not a good option at all, so there are good reasons it's not done that way.

The main reason you don't want it writing saves instantly is because you turn the power off and you have a corrupted save on some of these systems that constantly write to SRAM.

If someone comes up with a true solution to this very hard problem they can propose it technically in the Template_MiSTer repo or submit a pull request, but it needs to be tested extremely thoroughly beforehand.

[VagrantCS]

Hmmm...

Okay, not surprised by this response as many have said before the team doesn't want to risk losing performance, risk corruption and due to some cores/games the constant rewrites takes away resources needed for other duties so what you said confirmed it all. I'm sure some unsung hero will swoop in to solve this one day and again I'm willing to make a donation to the MiSTer team as a thank you for those like me that can't code to save their lives. I still find this very odd it can't automatically save safely but hey it is what it is.

Thanks.

[sorgelig]

My recent change removes waiting for "saving..." message. So you can briefly press OSD button 2 times and it's saved.

[birdybro]

Will this impact the PSX core pausing during saving?