SuperCard Pro Flux Image format (.scp)

[admin]

1) version/revision = currently 0.8?

The version/revision byte is the version/revision of SuperCard Pro software that created the disk image.

Disk Type = only informative: on the sample I received I read 14???

If you look at the latest image file structure info, you will see the Disk Type has changed. 0x14 is manufacturer of man_Atari (0x10) and disk type of disk_AtariSTSS (0x04). So, OR'd together that is 0x14. Actually, it should be 0x15 since both sides are being dumped, so I will change that.

3) Width in BITS of bit cell time? Why define in bits? If not 8 / 16 / 24 /32 … would require the data to be bit packed witch is a pain. (but it is not important at this stage as not really used)

Yes, it is a pain, but I left this option open for future use.

4) Checksum: If I understand correctly we just need to add the bytes with a 32 bits integer ignoring overflow and the sum = the checksum provided? Question the specified range is 0x010-EOF: is this correct? With the described format it is possible to have “unused sections of bytes” in the file as all parts are given by pointers. In that case are the unused part also added in the checksum or is the checksum only for the used bytes (i.e. the bytes you read or write during decoding/encoding)?

The entire file, starting from 0x10 through the very last byte of the file are added together, byte by byte. If the overflow occurs (past 16777216), then the checksum value wraps around to 0 and continues.

Here is the VB code used to calculate the checksum:

Code:

ChecksumTest()
    Z = 0                                           ' start with checksum = 0
    For X = IFF_THOFFSET To FileLength - 1
    Z = Z + FluxImageBuffer(X)                      ' get byte from flux image buffer
    Next X

    X = FluxImageBuffer(IFF_CHECKSUM + 3) * 65536 * 256&
    X = X + FluxImageBuffer(IFF_CHECKSUM + 2) * 65536
    X = X + FluxImageBuffer(IFF_CHECKSUM + 1) * 256&
    X = X + FluxImageBuffer(IFF_CHECKSUM + 0)
    
' compare checksum and quit with error message if they don't match!

    If Z <> X Then
        X = MsgBox("Flux image file checksum failure! Continue with viewing?", vbYesNo + vbDefaultButton2, "Checksum Failure!")
        If X = vbNo Then Exit Sub
    End If

5) track header pointer section: always 1have 62 pointers.

There are 165 pointers, not 162. 0x0010-0x2A4.

6) Track number:??? Different format if single or double sided FD??? How do you know which one to use? Also I suppose this track number should be equal to the number of the track we are pointing at for verification purpose. So if in the File header you are pointing to the track 10 header you should find 10 in this field? In the experiment I have done it seems that this field is always 0 but I may be wrong?

Track number should be the same as the pointer.

7) Length of track: If I understand correctly this is the number of flux transitions recorded for a specific revolutions (data bytes = 2 * length)

Correct! The length is the number of flux transitions * bit cell size. Default is 16 bits. So, if the track length was 0x1000 transitions and the bit cell size was 16 bits, the total length of data would be 0x1000 * 2 = 0x2000 bytes long.

8) Not mentioned in the doc but probably you should have a line that says:
BYTES 0x0C-0x0F contains the offset to get to the first flux transition data. The offset is from the Track Header?

Yes, that is correct. Please look at the latest specification (first post in this thread). I think it is more clear in the revised information.

9) If I understand correctly we ALWAYS have 5 times “index time”, “length”, “offset” (revolution information). Therefore even if number of revolution in FILE HEADER is one we still have 5 entries. Here again this is a waste of space but more important is that you will never be able to do more than 5 revolutions (probably not that important). Like what I said for the track header pointers the number could have been variable based on the number of revolutions?

Yes, there 5 sets of entries in the table. There is no waste of space because you could fill these in at a later date if the image is modified by writing new track data. The image format was designed for emulations, where you could change the data at any given time. That is why everything is offset based. We don't technically need any more than 2 revolutions in order to duplicate any type of disk. The extra space available is for the people that want "preservation" quality dumps.

10) flux data: I think you should FORCE (instead of recommend) that the data for the different revolutions must be adjacent. This is a MUST to be able to decode correctly DATA/ID segment bytes of a sector that span over the index pulse.

It doesn't matter where the data is placed in the file. The offsets are there to join everything. With this file structure, I can add new revolutions to the end of the file and just poke in the new track length, index-index time, and offset. Right now, the imager places all revolutions consecutively and the pointers point to the start of each revolution. But the data could be located anywhere so you need to be using the offsets when fetching the data from the image file.

11) time stamp: little strange to place it here. It is hard to access because floating in middle of nowhere
Currently I read the file as follow:

You are making it too difficult! The last 20 bytes of the file are always the timestamp. Just do a Seek(LOF-20).. that is always the location of the timestamp! If you are loading the entire file into memory, just use: ImageStart+ImageLength-20. If the image file changes, the timestamp will be erased, and the new data will started where the time stamp was located, and a new time stamp will be added to the end of the new data. This way, the last 20 bytes will always be the timestamp.