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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On tiistai 23 syyskuu 2014, Nicolas Pomarède wrote:
> Le 22/09/2014 23:49, Eero Tamminen a écrit :
> > And if the version is same, but content turns out to be incompatible
> > (e.g. wrong lenght) after loading, should emulation be able to
> > revert the state change?
> > 
> > (Reverting could be done by writing current state to a temporary
> > file before trying to restore user given state file.)
> 
> If you consider that each component is saved with a structure that
> contains :
>   - a component ID
>   - a version ID
>   - size of the structure in bytes
>   - data for this component
> 
> 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.


> This requires that you can't have same version ID for a component if the
> data has a different meaning between 2 Hatari versions, so the risk of
> loading incompatible data is lowered (it could still happen if savestate
> gets corrupted)
> 
> The size of the structure in bytes has 2 meaning :
> 
>   - if you encounter a block with an unknown component ID, then you can
> skip it by reading as many bytes as in "size of the structure", and you
> will point to the next block to parse (so for example some winuae's
> specific component (MMU for example) could be ignored when trying to
> load a snapshot made with Hatari "new winuae core" into Hataro "old uae
> core"

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.


>   - if you encounter a known block, then you can check that the size
> matches the expected size for given version of the component (for
> example, you expect the YM2149 part version 1.8.0 to be 60 bytes,else
> there's an error in the saved component you're tryring to restore).

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


> >> This way, we could also keep previous snapshots and use them with more
> >> recent version of Hatari, which can be useful if you use snapshot to
> >> save some games' progress (this is something that is possible with
> >> WinUAE or Steem since years for example, and I think it's a good
> >> feature).
> >> 
> >> What do you think ?
> > 
> > Sounds good.  It would require either saving all of them to
> > separate files (instead of filename, user could select state save
> > directory), or completely rewriting how state saving is currently
> > done in Hatari.
> 
> I think we could save everything to the same file as we do today, then
> compressing the result.
> 
> The components' version could be similar to the Hatari's version. So we
> would start with "1.8.0" for example.
> Then when Hatari 1.8.1 is released, all component that were not modified
> would keep their 1.8.0 version, only updated component would have a
> version's change to indicate a difference (eg a new fdc.c component
> could have version 1.8.1)

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.


> Now what would be good is that "fdc 1.8.1" be able to load an older
> snapshot made with "fdc 1.8.0", but this can become quite hard to do the
> transition between this old state and the new one, as we're only dealing
> with bytes, sometimes a component is just a whole structure written to
> the savestate, and nothing more, with no indication of what is in the
> structure. This means for example fdc.c 1.8.1 would need to know how to
> parse 1.8.1, but also all previous state versions to be able to add the
> missing default values.

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.


[...]
> 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. :-)


	- Eero