| Re: [hatari-devel] Hatari state save/restore for Falcon emulation |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Le 23/09/2014 22:44, Eero Tamminen a écrit :
Hi,
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 :) )
Nicolas