Re: [hatari-devel] memory snapshot format/issues

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 09/05/2015 00:50, Steven Noonan a écrit :
> > AFAIK it's primarily meant for snapshots that are used by
> > the same binary, e.g. when you're actively debugging things.
> > It's not meant as something portable.
>
> I understand. It's a fair first pass at snapshotting, but it is fragile.

Hi

I'm not satisfied too with current snapshot, it's not flexible enough.

IIRC I posted about this some months ago, with the idea of splitting 
every component in it's own structure, doing a kind of linked list :

 - component 1 id
 - component 1 size
 - component 1 data
....
 - component n id
 - component n size
 - component n data

This way, an Hatari version would load eveything but would ignore 
components with an unknown id or a different size that what is expected.

So, if a newer hatari version add a new component, the snapshot could 
still be loaded by an older version.

Also if we add more data in an existing component, we should add them at 
the end of the existing data, so an older version would still be able to 
read its data and would then skip to the next component (using "size"), 
ignoring the new data.

This implies that saving/restoring structure as a whole, which is very 
convenient, would not be used anymore, we would save every member one by 
one.

When saving every variable, we can also ensure that 16 bit and 32 bit 
ints are always saved by writing 2 bytes or 4 bytes in a OS/CPU 
independant way (little endian for example), so the same snapshot would 
be usable on big/little endian cpu.

But I'm not sure we have time to do this before next release as it would 
imply lots of rewrite and test to do, better for the next one.

Nicolas