There are a few critical problems with the current savestate system that prevent a release:
-The name of the savestate file is currently broken. It used to be based on the loaded ROM file name, but this is no longer relevant. We now need to generate a filename based on the loaded combination of system modules, so that it can support, for example, lock on cartridges or multi-system configurations. Note that the mapping of controllers will also affect the file name. Savestate files can still be manually loaded for potentially incompatible system configurations, but only devices which can be mapped will be updated by loading the savestate.
-Support for backup memory needs to be added. For this, I suggest some kind of flag in the system file that indicates that a given device has persistent storage. The data for these devices will be saved back into a special system folder for storing persistent data when the system is unloaded. By default, the user will be asked if they want to save the data when the system is unloaded, but they can set a system option to save or discard by default, with a special menu options to manually save or load from the persistent storage on demand.
-We need to support saving and loading debugger state. I would suggest the best way to do this is to save debugger state alongside normal savestate files, with the exact same rules for saving and loading them as for normal savestate files. On the GUI, the user will be able to visually see when a debugger state file exists in a particular slot, since we will overlay some text in blue on the save slot where a debug state exists. When saving or loading a savestate, only the save data will be affected using the normal F5 and F8 keys, while CTRL+F5 and CTRL+F8 will affect debug state. There will be normal menu options provided for working with the debug state separately from the save state data. This will allow debug state to be stored in a possibly empty savestate slot, but loaded and saved on demand, to assist in debugging sessions.