Re: [openMSX-devel] save state proposal

[Maarten t. H. <mt...@st...>]

Hi,

This is a combined reply.

David Heremans wrote:

> I'm not
> going to describe them all, but if you meet me IRL we can discuss pro's and
> cons of the other ideas.

There is an MSX fair in Oss next weekend (January 19th). Is this a 
possibility for the openMSX developers to meet IRL?

> One centrall object is the singleton of SaveStateManager.
> All other devices (MSXDevices or others like soundproducers, disk/tape
> patch handlers, pseudo devices,...) need to register with this manager if
> they support savestates.

I don't think it's possible to make save state support optional. For example, 
if MSX-AUDIO would not have save state implemented, it's state will be lost 
when the emulated MSX is loaded from save state. If it were playing 
MoonBlaster music, the sample kit is lost, so all drums are gone. This would 
ruin the almost-perfect MSX experience we are trying to create. But there 
could also be scenarios where the emulated MSX would hang because it is 
waiting for an interrupt or for a status register to flip.

So I think that we should make save states mandatory. When we do that, we 
might as well add it to the MSXDevice interface. Actually, it is at the 
moment, although unused. If any non-MSXDevice object have to be saved, they 
can be triggered from the MSXDevice they belong to. This wouldn't work if 
there are non-MSXDevices that are not part of any MSXDevice either, but I 
don't think classes like that (RealTime for example) should be considered 
part of the state of the emulated MSX anyway.

> Now something practical.
> The call to the virtual-to-be-implemented method will also pas a parameter
> to let the device know if he needs to write a simple or a full blown
> savestate. The difference? For instance a gamecartridge simple savestate
> contains only the current slotmapping, while a full blown savestate will
> also save the ROM data itself. This way a full blown savestate can be used
> to restore the entire game without the need of having the .ROM file around.

This is a nice features. But I think it should be implemented separately from 
save states. For example an NMS8250 package containing the config XML and the 
ROMs would be useful, either as part of a save state, or as an empty machine. 
The useful part of saving the ROM contents is distribution: you can send a 
single file to someone else and it works. Easy distribution is useful for 
both save states and empty machines.

> Another practical thing.
> Since for the moment there is no way to save the xml configuration the
> savestae is till linked to the used xml file. Later on the savestate wil
> contain the needed xml file to recreate the entire msx hardware config.

The config of the MSX machine must be part of the save state, otherwise the 
result is unreliable. Note that this includes information that can change 
after the emulator is started. For example, which disk is in a drive is part 
of the state.

Not everything in the config should be saved though. There are some 
parameters that configure the emulator, not the emulated MSX. For example, 
the Renderer used, the settings of the RealTime sync, the sampling frequency 
of the sound synthesizers etc.

> Files will be a simple bytestream.

What about integers, floats etc? We need a platform independant way to save 
them, so that for example openMSX on PowerPC can read save states created on 
x86. It must be decided whether integers are stored little endian or big 
endian, preferably using convenient write methods that hide these details 
from the MSXDevice programmer. For floating point numbers there may be even 
more ways of storing them in bytes.

> Devices can not assume anything about theire state when a savestate is
> made/restored, so they will need to store everything needed incl emutime
> counters if used, positions in files (for tapes), current soundbuffers etc
> etc etc

I agree with the others, but sound buffers should not be stored. They are not 
part of the MSX state, only of the emulator state. A sound device should 
store its state and EmuTime and can resume sound generation from there.


On Friday 11 January 2002 11:16, Wouter Vermaelen wrote:

> I like the idea of a save-state-directory (vs file) better. Each device
> has its own file in the directory. There is no need for pointers or even
> subheaders. Later the config file (.xml) can also be saved in this
> directory.

I agree.

We could use an archive format (like zip or tar.gz) instead of a real 
directory, so that the user only sees a single file, while developers can 
take those files apart for debugging etc. Also compression is nice, since RAM 
and VRAM contents probably compress well.

Bye,
		Maarten