|Re: [hatari-devel] Hatari state save/restore for Falcon emulation|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On tiistai 23 syyskuu 2014, Nicolas Pomarède wrote:
> thanks for the patch ; but is it really necessary to add a marker at the
> end of the snapshot ?
It catches cases where saved state was different in a way that
caused state file to be longer. that check would have cought
the FPU state save issue, before I fixed it, and it would have
cought WinUAE -> oldUAE state issue before I added separate check
IMHO it's important to catch this kind of cases because Hatari
apparently can crash when they happen, or go to a state where
it doesn't respond to user and Hatari process needs to be
forcibly killed (I got both kind of issues this evening).
> Overall, I think there're some limitations to our saving format when
> compared to other emulators, namely the fact that we often require to
> lost compatibilty with older snapshot version when a new version is
> released, instead maybe of loading the old version and filling the blank
> with default values.
> For example, if we change something in the sound emulation, we should
> still be able to load the cpu, mfp, video, .... states as their format
> is unchanged.
> So, we could have a snapshot format where each "component" is saved /
> restored as today, but with its own version. This way, we can skip
> unknown component (so maybe a 1.9 snapshot could be loaded with 1.8), or
> we could have some code in each component to be able to load an older
> section and fill the missing part with default values (when it makes
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.)
> 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
> 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.