12-22-2013, 03:57 AM
Questions / Feedback on scp format.
The feedback is based on experiment with the provided sample.
FILE HEADER
1) version/revision = currently 0.8?
Disk Type = only informative: on the sample I received I read 14???
2) TrackStart – TrackEnd info: are NOT used to read the following Track headers. In other word the region 0x010-0x02A7 is ALWAYS present independent of number of track sampled.
To save space and to allow more that 162 track its would have been possible to just have Track Header entries from TrackStart till TrackEnd?
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)
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)?
5) track header pointer section: always 1have 62 pointers.
TRACK HEADER
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?
7) Length of track: If I understand correctly this is the number of flux transitions recorded for a specific revolutions (data bytes = 2 * length)
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?
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?
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.
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:
Therefore unless I store the maximum upper byte read in all data segments I do not have idea where the time stamp is located!
More flexible and more optimized way for track / revolution would be:
The feedback is based on experiment with the provided sample.
FILE HEADER
1) version/revision = currently 0.8?
Disk Type = only informative: on the sample I received I read 14???
2) TrackStart – TrackEnd info: are NOT used to read the following Track headers. In other word the region 0x010-0x02A7 is ALWAYS present independent of number of track sampled.
To save space and to allow more that 162 track its would have been possible to just have Track Header entries from TrackStart till TrackEnd?
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)
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)?
5) track header pointer section: always 1have 62 pointers.
TRACK HEADER
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?
7) Length of track: If I understand correctly this is the number of flux transitions recorded for a specific revolutions (data bytes = 2 * length)
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?
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?
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.
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:
Code:
Read file header
For 162 times read Track header
If not null
For 5 times read revolution information
If not null
For each revolution read dataMore flexible and more optimized way for track / revolution would be:
Code:
For trackStart till trackEnd read Track Header
For number of revolutions recorded read revolution information
For each revolution read data
Read time stamp (would be located just after the array of track header)