12-21-2021, 04:09 AM
In my multi revolutions images something is off with the track length or my understanding of the format.
I'm just reading in the flux data, add them all up and then compare the result with the corresponding duration field from the TRK header.
Here what I e.g. get for one of my 1.44 MB IBM disks:
index2index and flux transitions are the duration and the bitcells from the TRK header, while acc ticks is the sum over all flux transitions in the revolutions.
For rev 0 there are 48 "free" ticks which should be the ticks from the last flux transition to the index signal,
But in rev 1 there are 5 ticks *more* than the revolution is long...
Noteworthy is also the discrepancy: while the index2index time varies 1276 ticks (31.9ms) the accumulated ticks have a discrepancy of 1329 ticks (33,225ms)
So the second revolution as roughly 2ms longer, and has 6 flux transitions more. Which seems to be too much to be explained away by some rounding errors.
As background why I'm looking at that:
There is at least one floppy formal - XDF - which is writing sectors over the index pulse and therefore I have to stitch revolutions together correctly, too.
My first assumption was, that the scp format is simply using the time from the first index pulse as reference for the first recorded flux transition.
The question therefore was, if I have to account for the time between the last flux in a track when I want to decode the first flux transition when reading over the index mark.
Now since the first flux transitions in my mult-rev images are always identical it looks like the reference may already be the last flux prior to the index signal. (Which would prevent us to figure out how far away the first flux transition is from the index pulse...)
That could explain why the sum of all flux transactions is longer than the track.
But I simply can't match the what I see into either assumption... So any tips what I'm doing wrong here?
I'm just reading in the flux data, add them all up and then compare the result with the corresponding duration field from the TRK header.
Here what I e.g. get for one of my 1.44 MB IBM disks:
Quote:rev: 0, index2index=7987142, flux transitions=76847
rev: 1, index2index=7988418, flux transitions=76853
rev 0: acc ticks=7987094
rev 1: acc ticks=7988423
index2index and flux transitions are the duration and the bitcells from the TRK header, while acc ticks is the sum over all flux transitions in the revolutions.
For rev 0 there are 48 "free" ticks which should be the ticks from the last flux transition to the index signal,
But in rev 1 there are 5 ticks *more* than the revolution is long...
Noteworthy is also the discrepancy: while the index2index time varies 1276 ticks (31.9ms) the accumulated ticks have a discrepancy of 1329 ticks (33,225ms)
So the second revolution as roughly 2ms longer, and has 6 flux transitions more. Which seems to be too much to be explained away by some rounding errors.
As background why I'm looking at that:
There is at least one floppy formal - XDF - which is writing sectors over the index pulse and therefore I have to stitch revolutions together correctly, too.
My first assumption was, that the scp format is simply using the time from the first index pulse as reference for the first recorded flux transition.
The question therefore was, if I have to account for the time between the last flux in a track when I want to decode the first flux transition when reading over the index mark.
Now since the first flux transitions in my mult-rev images are always identical it looks like the reference may already be the last flux prior to the index signal. (Which would prevent us to figure out how far away the first flux transition is from the index pulse...)
That could explain why the sum of all flux transactions is longer than the track.
But I simply can't match the what I see into either assumption... So any tips what I'm doing wrong here?