State save
This PR implements state saving, both compressed and uncompressed, and implements loading of uncompressed states.
I'm going to try a slightly simpler approach today (on the kc85 emulator), basically just copying out the nested state struct. Any pointers to external data would be patched in after loading back such a snapshot.
Basically:
void kc85_save_snapshot(kc85_t* sys, kc85_t* dst);
bool kc85_load_snapshot(kc85_t* sys, kc85_t* src);
Of course this has a couple of downsides, the snapshots will be fairly useless for 'distribution', because they're very 'volatile' (depending on the exact struct memory layout and endianess), but I'm seeing them mainly as a debug aid (to capture a state and later rewind to it).
As for compression and attaching additional meta data (like a screenshot), I'm planning to do this outside the system emulation in the wrapper application, and using a small zip library (like https://github.com/richgel999/miniz) to compress/decompress (because some snapshots, like the KC85 with its expansion system) can get pretty big, but when not used, will mostly be zeroed).
I'm currently also doing a little API overhaul, and I have added a new way how emulators write their video output (instead of RGBA8 pixels, they provide a fixed RGBA8 palette with up to 256 entries, and the video output is one byte per pixel as index into the palette, this reduces memory accesses, memory bandwidth, and allows to move the 'palette resolution' to a pixel shader (while still being trivial to resolve on the CPU). The only current emulator that can't use this solution is Bombjack, because that uses a variable palette of RGB4 colors - but Bombjack will simply continue to use the current approach of writing out RGBA8 pixels.
This stuff is all in a branch currently ('code-cleanup-1').
the snapshots will be fairly useless for 'distribution', because they're very 'volatile'
You could add a simple version number to the snapshot, but that makes deserialization a bit more complicated ofc.
I thought about just reading and writing the structures contents as I don't really need .z80 support, but I figured it would be nice to have compatibility with a widely used snapshot format for the ZX Spectrum. Maybe add it but only enable it with CHIPS_SAVE_Z80?
If you decide not to merge this PR in the end it's ok, I'll just use your implementation :)
Ah right, I missed the part that this is a standard snapshot format. Yep that definitely makes sense (in addition to the 'non-standard' snapshot format I'm currently implementing which will only be useful for debugging, but has the advantage that it captures the entire chips-emulator specific state down to the last bit)
it captures the entire chips-emulator specific state down to the last bit
Now that you put it that way, I believe I'll be using your snapshot instead of .z80 since reliability is more important than being able to save in a format that other emulators can understand.
I still believe .z80 is an interesting addition though.