Ghost disks (STG)

[Steven Seagal]

Below is the specification of ghost disks in future version of Steem.
This is not to impose it on the world, there's no reason that all emulators use the same way to do this, but this is to clarify the purposes of "STG" and "STW" files.
STG is for ghost disks, STW is for a full disk.


ST Ghost v1.0
===============================================================================

STG is the extension of "ghost disks" for Steem.

Ghost disks are used to save sector changes in read-only disk image
formats such as STX (pasti) and IPF, CTR (caps).

If SSE option 'Ghost disk' is checked, a STG file is automatically
created at first sector write, with the same name as the disk image.
Steem will check the existence of a STG file at reads.

Only those sectors that are changed are saved, and retrieved when
the same sectors are read.

This is useful to save highscores or game progress.

Sectors are identified by an "ID field" as described in the WD1772 doc.
The CRC info isn't used.

To save space, records are sequentially added.
Normally, there will not be a lot of records, so performance
shouldn't be an issue.

In the current specification, only sectors are recorded, not full
tracks.

Tested on:
- Sundog IPF loads to menu
- Great Courts
- Super Cycles
- Platoon

To test:
- Lethal Xcess
- Super Sprint


Header
------

4 bytes: "STG" null-terminated C string
1 word (little-endian): version in hex ($0100 to begin with)
1 word (little-endian): number of records


Record
------

5 bytes: header "SEC" (for sector) and the record number (big-endian)
to help debugging.

6bytes: ID field, being:
BYTE track (0-83) (disk track, not TR register that could be different)
BYTE side (0 or 1) (real, as selected in the PSG)
BYTE num (sector number) (SR register)
BYTE len 0-3 for 128,256,512 or 1024 bytes
BYTE CRC (unused)
BYTE CRC (unused)

X bytes acording to len: data

If the program saves the same sector with different sizes, this will corrupt
the file. Normally there are no such cases.


[edited to current specification]

[npomarede]

Each sector / ID field should have the physical side and physical head position at the time of the write, else you will get problems : some games are using side=0 in the ID field of 2nd side for example, or are putting different value in the track part of the ID field.
Without that, you could have several sectors with similar ID fields in the same file (and conflict), while they were supposed to be on different physical track.

Nicolas

[Steven Seagal]

I think you're right.
For side this is already the case (it's real side) but not for track.
Using the ID field concept may seem strange then, I did that because the struct exists.