Save SRAM

[ne3i]

I tried Write out SRAM when exiting, load it when starting, and settings remains preserved. It seems like there's no need to reset it every start, right?

[Falcosoft]

Actually the best parctice is that you should at least software reset it (by sending GM/GS reset SysEx messages) before playing a new title (be it a game or a Midi file). Otherwise you can experience subtle problems since Midi is a state machine so settings of a previous title can influence the playback of the next one (program, bank, controller, RPN, NRPN etc. settings). So it is questionable how a saved state could be useful in practice, because:

1. If the Midi title does not contain Reset message at the beginning then the above written problems can occur.
2. If the Midi title does contain Reset message at the beginning then the settings of your saved state is overwritten by default values anyway.

[lunathir]

Duplicate of #23

[Karmeck]

Duplicate of #23

I'd say this approach would simulate a working battery while issue 23 would emulate a battery.

The outcome would be the same though.

[Falcosoft]

I think the installed battery emulation and this feature is somewhat unrelated. With battery emulation you should achieve to emulate exactly the behaviour of a properly working HW unit at cold boot. That is it could start with a properly configured default state so you could skip an additional/unnecessary reset to actually get default state. This proposal is rather about the saving of the actual state and reloading it which does not result in a known default state but an arbitrary one defined by the last used Midi track/game.

[ne3i]

My native Language isn't English, so something I expressed may wrong. The Low Battery because MCU_AnalogReadPin, return a bad value while read battery analogValue. To check battery, goto Test Mode, then run T-4 to check battery status. Whatever the battery status, still need to reset parameters at startup. So I try save sram. Try #42 ? This is my screenshot. On Startup, no low battery T-4

[Falcosoft]

I think now I understand better what you want. But I still think that instead of saving always the actual state at exit it would be better (at least make an option for it) to save state right after a proper reset and always load this clear state instead of the arbitrary state saved at every exit. This way at start the emulator would be ready to handle anything properly.

[pachuco]

Idea: Sane default on normal startup. But you can pass CLI parameter with SRAM path/filename. With that parameter, RAM loaded on startup(use sane default and create file if not exist instead), saved on exit.

I imagine this would be useful for storing custom patches? But maybe that's what sysex is for instead.

[NicknineTheEagle]

I think the installed battery emulation and this feature is somewhat unrelated. With battery emulation you should achieve to emulate exactly the behaviour of a properly working HW unit at cold boot. That is it could start with a properly configured default state so you could skip an additional/unnecessary reset to actually get default state. This proposal is rather about the saving of the actual state and reloading it which does not result in a known default state but an arbitrary one defined by the last used Midi track/game.

I'm pretty sure SRAM is where the real module saves settings when it's powered down and it's powered by the battery so they are related. If OP means preserving the full runtime state that would be RAM. This is actually how the emulator currently acts when you press Q, it doesn't clear out RAM and registers so when you press Q again, it's right back to where it was before without the startup animation.

[lunathir]

I think the installed battery emulation and this feature is somewhat unrelated. With battery emulation you should achieve to emulate exactly the behaviour of a properly working HW unit at cold boot. That is it could start with a properly configured default state so you could skip an additional/unnecessary reset to actually get default state. This proposal is rather about the saving of the actual state and reloading it which does not result in a known default state but an arbitrary one defined by the last used Midi track/game.

I'm pretty sure SRAM is where the real module saves settings when it's powered down and it's powered by the battery so they are related. If OP means preserving the full runtime state that would be RAM. This is actually how the emulator currently acts when you press Q, it doesn't clear out RAM and registers so when you press Q again, it's right back to where it was before without the startup animation.

That's exactly what my line of thought was: saving SRAM is basically emulating a working battery attached to the SC-55, though that explanation is rather simplified.

[Falcosoft]

Maybe I was not clear enough. By proper battery emulation I meant a fix that removes the battery error at startup. This commit fixes this problem without doing anything with SRAM: https://github.com/nukeykt/Nuked-SC55/commit/f53aac758621e80ce3aec52c4e4de160c9c0d99e And these options prevents the wrong default state at startup without doing anything with SRAM: https://github.com/nukeykt/Nuked-SC55/pull/47 These reset options also work on units that do not have battery at all (CM-300 and 55st).

So saving and loading SRAM is an independent feature (at least from now on). The SRAM handling related commit should put the call that will do the loading of saved SRAM before the MIDI_Reset() call. This way you get the saved state by default unless you also specify reset in the command line.

[NicknineTheEagle]

The SRAM handling related commit should put the call that will do the loading of saved SRAM before the MIDI_Reset() call. This way you get the saved state by default unless you also specify reset in the command line.

My PR already loads SRAM before MIDI_Reset.