Mail Archive - Plus/4 World



	Home Search Games Tapes Covers Cheats Maps Software New Stuff Hall Of Fame HVTC Game Endings Solutions Remakes Publications Magazines Effects Top List Members Groups Features Plus/4 Encyclopedia Hardware Tools Options Forum Home Search Games Tapes Covers Cheats Maps Software New Stuff Hall Of Fame HVTC Game Endings Solutions Remakes Publications Magazines Effects Top List Members Groups Features Plus/4 Encyclopedia Hardware Tools Options Forum	Login

Previous | Next

From: Crown (all posts)
Date: 1998-09-16
Subject: Re: Snapshot files for emulators

Hi,

>Ok, why I wrote this letter: I would like introduce a snapshot
>format for the Plus/4 emulators, but I think it is better to dicuss
>about the format because of portability.
>I would like publish this format too, of course. (An other way to
>exchange programs between emulators, and platforms.)
Actually, in VICE snapshot is being implemented right now. The format is quite flexible, and is intended to be a standard format, which other emulators could adapt, so I think first you should have a look at that. I think Ettore could give you a detailed breakdown on the format.
It's a general format, each chip has its own section, so to implement the plus4 support you should just put a TED section into it.

> HIGHRAM - 1 byte, boolean: high memory area is RAM
> if TRUE (means non-zero)
>
You should save the current bank state also.

> ACTRASTLINE - 2 bytes, word: actual drawed raster
> line (real address on screen!) for
> line-based emulations This is not enough! From this you don't know in which drawing state the TED is. Actual screen raster line, and current $ff1d values doesn't tell you if this is a border line or line with graphics.
TED line-cache state is missing also, and of course a lot of things which is needed for a cycle-based emulator.
Of course this isn't a matter if you save snapshot always in the VSYNC section.
Also this actual drawed raster line is relative to what?

>24-65559 RAM dump: 65536 byte of actual RAM. This part contains the
> values of TED registers on their positions. (Eg.
> $FF19 on position of $FF19+24 etc...)
It's better to have the TED register separated from RAM.

>Tagged format would be good, but I think there is no reason for. I
>will implement it, if you think.
Indeed it's needed if you want compatibility with old versions, or other emulators. Just imagine this, if the information you store,
doesn't enough to emulate something, which an other emulator writer wants to implement, and if the format is not extendable, he will simply scrap your format. If you have a tagged format, he just defines a new struct, and saves both in the generated snapshot file.
If this emulator loads a file generated by your emulator, it can run it,
and also yours can run his files, with some differences of course, but the issue here is to be compatible.

>> But what if someone later discovers a way to write to the RAM below
>> $fd00-$ff3f? The RAM addresses 0 and 1 can be written to, and for that
>> reason, you should also store the processor's on-chip I/O register
>> contents separately.
>I am afraid it is not possible. Ok. I think tagged format would be
>the proper way to solve this.
Hmmm, I'm not sure, but I think one of my friend made a 256K expansion,
where you can relocate normal RAM areas, thus every bit of the memory is accessable. Will go after it. :) (The Csory version can do this also,
as you can map the whole memory in 16KB steps.)
So the TED registers definitely should be removed from the RAM.

>be worth having a look. Also, you could have some conversation and
>cooperation with the VICE development team. The same basic format could
>be used for storing the state of all emulators, and also the states of
>attached devices (e.g. drive states).
This is definitely the way to go. :)

Tibor Biczo / Crown of GOTU ICQ : 15989510