First a correction: I only have the issue with multi-rev images. And since multi-rev images can only be created in splice mode it could be that the splice mode is the issue here... Long story below, but I now suspect that I simply should ignore the index2index time when the image has been created in splice mode.
That's so unexpected I assume I'm simply overanalysing your statement and want to double check on that...
My best understanding still is, that I have to add all flux times of a track together and subtract the time from the index2index time to get the time between the last flux of the track to the index pulse. (At least when the image has been created in index mode.)
But for that the sum of all flux transitions (of one track and revolution) must be less or max equal to the index2index time of that track/revolution.
Do I somehow have to ignore invalid flux times for that? If so I'm really missing something fundamental here:
The drive is simple reporting flux changes and the supercard is making time stamps out of it. I see no way how a invalid long or short flux time reported by the drive could change the fact that the sum of all flux intervals for one track must be less or equal to the index2index time of the revolution. (I see how different revolution/reads can get different results but for each track/revolution. But not how adding up all flux intervals - with 0 interpreted as 0x10000 - can exceed the index2index time reported for the revolution.)
I re-imaged the disk, here a link to it: https://www.awhome.eu/index.php/s/bJ8NHznibT3DNfK
(I created three images in index mode, these are all ok. But from the two images in splice mode the one I linked to has the issue again.)
When I open the image with the SCP software the Flux view informs me, that the "Index" is 399538us and the "Cells" are 399539.200us long for track 0 head 0.
Which make no sense: The Cell time is 1.200us longer than the two revolutions, so these are not all fitting within the disk revolutions.
Now there must be some rounding in the SCP software, which reduces the 1.2us "overrun" to just 0,075us. But I can't reason away those remaining 75ns.
Looking at the TRK header in hex:
Rev 1: 6d ed 79 00 -> 7990637 ticks (199765925ns)
Rev 2: 90 ee 79 00 -> 7990928 ticks (199773200ns)
Total: 15981565 ticks (399539125ns)
So the SCP flux viewer (399538us instead of 399539,125us) is not reporting 1,125us (aka 45 ticks) for the index2index time.
A bit unexpected but no big deal.
The problem here is, that even 399539.125us is still less than the 399539.200us the SCP flux viewer is reporting for the Cell times: We still have 75ns (3 ticks) more in cells then what can fit into the index2index time...
Thus my initial assumption, that the track end may not be exact. (Now it looks more like Splice mode is a bit lax when stitching revolutions together and simply should not be used when there is data written over the index.)
Decoding the same track with my code adds some additional data:
rev 0 has 199766.225us and rev 1 199772.975us worth of flux data.
Adding these together we also get 399539.200us for all flux transitions in total. Therefore the Cell time reported by the SCP Flux viewer must be correct and the discrepancy can't be explained by some rounding error here.
As for my project: I'm working on scp image support for qemu. I copied some core functions from fs-uae and also looked at the Disk Utilities (all code from Keir Fraser) for scp track loading and MFM decoding.
Still much to do but the read support for IBM MFM scp images is mostly done and working fine.
But while testing it I tripped over the fact that sometimes the sum of all flux transactions is not fitting into the corresponding index2index time, breaking the corner case support for reading a sector over the index.
Quote:No, it is stopping at exactly the index pulse. In fact, reading starts and stops in the middle of a bitcell, which is why the first and last bitcell times are typically much shorter than "normal".. there is no extra bits.Are you saying that the last flux in a track is not the time up to the next flux change but to the index pule instead?
That's so unexpected I assume I'm simply overanalysing your statement and want to double check on that...
My best understanding still is, that I have to add all flux times of a track together and subtract the time from the index2index time to get the time between the last flux of the track to the index pulse. (At least when the image has been created in index mode.)
But for that the sum of all flux transitions (of one track and revolution) must be less or max equal to the index2index time of that track/revolution.
Do I somehow have to ignore invalid flux times for that? If so I'm really missing something fundamental here:
The drive is simple reporting flux changes and the supercard is making time stamps out of it. I see no way how a invalid long or short flux time reported by the drive could change the fact that the sum of all flux intervals for one track must be less or equal to the index2index time of the revolution. (I see how different revolution/reads can get different results but for each track/revolution. But not how adding up all flux intervals - with 0 interpreted as 0x10000 - can exceed the index2index time reported for the revolution.)
I re-imaged the disk, here a link to it: https://www.awhome.eu/index.php/s/bJ8NHznibT3DNfK
(I created three images in index mode, these are all ok. But from the two images in splice mode the one I linked to has the issue again.)
When I open the image with the SCP software the Flux view informs me, that the "Index" is 399538us and the "Cells" are 399539.200us long for track 0 head 0.
Which make no sense: The Cell time is 1.200us longer than the two revolutions, so these are not all fitting within the disk revolutions.
Now there must be some rounding in the SCP software, which reduces the 1.2us "overrun" to just 0,075us. But I can't reason away those remaining 75ns.
Looking at the TRK header in hex:
Code:
000002b0 54 52 4b 00 6d ed 79 00 65 32 01 00 1c 00 00 00 |TRK.m.y.e2......|
000002c0 90 ee 79 00 70 32 01 00 e6 64 02 00 00 71 00 4b |..y.p2...d...q.K|Rev 1: 6d ed 79 00 -> 7990637 ticks (199765925ns)
Rev 2: 90 ee 79 00 -> 7990928 ticks (199773200ns)
Total: 15981565 ticks (399539125ns)
So the SCP flux viewer (399538us instead of 399539,125us) is not reporting 1,125us (aka 45 ticks) for the index2index time.
A bit unexpected but no big deal.
The problem here is, that even 399539.125us is still less than the 399539.200us the SCP flux viewer is reporting for the Cell times: We still have 75ns (3 ticks) more in cells then what can fit into the index2index time...
Thus my initial assumption, that the track end may not be exact. (Now it looks more like Splice mode is a bit lax when stitching revolutions together and simply should not be used when there is data written over the index.)
Decoding the same track with my code adds some additional data:
rev 0 has 199766.225us and rev 1 199772.975us worth of flux data.
Adding these together we also get 399539.200us for all flux transitions in total. Therefore the Cell time reported by the SCP Flux viewer must be correct and the discrepancy can't be explained by some rounding error here.
As for my project: I'm working on scp image support for qemu. I copied some core functions from fs-uae and also looked at the Disk Utilities (all code from Keir Fraser) for scp track loading and MFM decoding.
Still much to do but the read support for IBM MFM scp images is mostly done and working fine.
But while testing it I tripped over the fact that sometimes the sum of all flux transactions is not fitting into the corresponding index2index time, breaking the corner case support for reading a sector over the index.