Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

State save #71

Open
wants to merge 11 commits into
base: master
Choose a base branch
from
Open

State save #71

wants to merge 11 commits into from

Conversation

leiradel
Copy link
Contributor

@leiradel leiradel commented Dec 8, 2022

This PR implements state saving, both compressed and uncompressed, and implements loading of uncompressed states.

@floooh
Copy link
Owner

floooh commented Dec 19, 2022

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').

@leiradel
Copy link
Contributor Author

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 :)

@floooh
Copy link
Owner

floooh commented Dec 21, 2022

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)

@leiradel
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants