Re: [hatari-devel] Hatari state save/restore for Falcon emulation

[ Thread Index | Date Index | More Archives ]

Le 23/09/2014 22:44, Eero Tamminen a écrit :

Then you can easily walk through the savestate, parse only the component
where the ID is recognized and adapt the parsing depending on the
version ID of the saved component.

Sounds fine, but requires rewrite about all of the current
state save/restore code.

Yes, that would imply some work to change each part of Hatari that does a save/restore, but not that's not a difficult work, just a little tedious.

Also WinUAE and oldUAE CPU states are different.

If you skip CPU state, there's not much point in trying
to restore state for rest of HW components.  Only thing safe
to do at that point is to revert everything restored so far
(or reboot) and inform user that state file was incompatible.

CPU state is not necessarily the best example ; if there's too much change, then state loading could be rejected (also, hopefully we will get rid of the old cpu core one day, so this won't be a problem anymore)

If restoring even one of the components fails, should restoring
proceed?  How we know that it doesn't do something bad for
the program restored within emulation (program could read e.g.
YM registers and do something based on their values).

We could ask the user "do you want to proceed with some default values for this components ?"

This whole thing is completely new file structure / ABI from state file
used by Hatari v1.8.0, so version numbers should be >1.8.0.

Yes, that would be a complete change, with some new API. A for 1.8.0, it was just an example too.

I'm not sure Hatari itself needs to be able to load different
state versions.

If different parts of the memory state are clearly marked in the format
and somewhat documented, conversion between different state file versions
would be possible to do also with an external tool.

External tool for converting previous Hatari state file to new version
could be provided also after Hatari release, provided by 3rd parties
and be done in another language.  Older state files could be updated to
latest version by using such a tool for each intermediate Hatari version.

That's true, external tools could be an option if we don't want to change Hatari itself.

In the end, this looks a lot like a config file, where we have sections
between [], then values for each section are stored with key=value.
Difference with a config file is that this would not necessarily be
stored as plain text (but plain text could be an option, this way a
memory file could even be loaded in a text editor)

Sounds fine to me too.  I don't need cross-version state file
compatibility, so I'm not going to look into this.  It's a lot
of work for whoever is going to implement it, so I think that
person has quite a lot of freedom in implementing it in way
he likes...

I personally just need robustness for current state file handling. :-)

cross-version compatibility (or best effort at least) would be I think really useful.

We could even go for cross-OS compatibility ; this would require much more work (save int, long, ... in an OS neutral way (big endian for example)).

But in the end it would be great if people could be able to swap memory states : you could share some progress in a game, or keep all your memory states if you go from an OS to another (for example, start a game on your PC, save it and reload it later on your android device).

Even for debugging, users could send us savestate when they find a case where emulation is not correct.

Well, I don't have time myself to work on this at the moment, but maybe later. At least, we can already throw some thoughts about what could be the best solution with modularity in mind. Or have a look at some others emulators and see how they handle this (or not :) )


Mail converted by MHonArc 2.6.19+