First thanks for all the support!
You are right, I'm pretty new to flux images and all the nice details these have...
And I'm probably not using the correct terms in all cases, which may cause some confusion.
Here you seem to come back again and again to the amount of flux changes. But I do not understand how the flux ticks of one revolution added together can be bigger than the index2index time of the same revolution:
I thought I got at least the basics right: The disc drive reports any detected flux change via a line. It was news for me that the drive cares about the bitcells at all but I see how this AGG may need a reference to adjust itself within a window.
But the "interface" between the floppy drive and the supercard should be just one line which changes the state whenever the drive thinks it has found a flux transition. The supercard is ticking with 25ns and marks down the ticks between each state change of the floppy data line. And these state changes will later end up as the flux times of the track, with the amount of ticks counted between each state change as it's value.
Thus all timing information of a track revolution and also of the intervals between flux changes should come from the supercard pro, isn't it?
Assuming one revolution of the disk is measured by the supercard to be 7990637 ticks, the accumulated ticks for all logged flux transactions should not be able to exceed 7990637 ticks. While probably impossible I'm ok with zero flux changes during the full time. I'm can follow as long as all the flux data together equals any number between 0 and 7990637. But with one clock and exact start/stop there should be no way to get more than 7990637 ticks summing up all the individual flux times. (And for that we would have to detect a flux change at exactly 0 and 7990637 ticks.)
Of course things change when we have more than one clock: These will next to be sure out of sync and explain the derivations.
Bitcells are not on my radar for the topic here at all. But I understand that when we write e.g. a single sector on real HW it will never be in sync with the pre-existing data. When decoding we'll always have flux transitions outside of the "expected" bit cell. Which is the reason why we are writing the Syny Bytes (zeros) prior to the (I)DAMs, allowing the PLL to find the new bitcell window. In reality the bit cell window and also the clock is shifting around all the time even when we are in sync.
Nevertheless the explanation of the Index mode may be what I was looking for, assuming it also can stop reading after the index mark when creating a image.
After all all the images I recorded with Index seems to be correct, the sum of all the flux ticks is less that the index2index time.
For the three images of the same disk I got those values:
Index2Index sum of all flux times
199783600 199782750 -> 850 free ticks
199773900 199772425 -> 1475 free ticks
199775275 199774425 -> 850 free ticks
Which seems to underline that the Index2index time can't be aligned to individual flux ticks: 21-37us is a serous offset, especially when the last flux id for the index again.
Would it be safe to say that the Index2index time can only be used to determine the rotation speed and and can't be used for anything other?
I also should point out that according to this discussion at least fs-uae is decoding the first flux bit wrong : The code is not handling the last flux transition as mark for the index pulse and this should not be able to read an XDF image from my point of view.
You are right, I'm pretty new to flux images and all the nice details these have...
And I'm probably not using the correct terms in all cases, which may cause some confusion.
Here you seem to come back again and again to the amount of flux changes. But I do not understand how the flux ticks of one revolution added together can be bigger than the index2index time of the same revolution:
I thought I got at least the basics right: The disc drive reports any detected flux change via a line. It was news for me that the drive cares about the bitcells at all but I see how this AGG may need a reference to adjust itself within a window.
But the "interface" between the floppy drive and the supercard should be just one line which changes the state whenever the drive thinks it has found a flux transition. The supercard is ticking with 25ns and marks down the ticks between each state change of the floppy data line. And these state changes will later end up as the flux times of the track, with the amount of ticks counted between each state change as it's value.
Thus all timing information of a track revolution and also of the intervals between flux changes should come from the supercard pro, isn't it?
Assuming one revolution of the disk is measured by the supercard to be 7990637 ticks, the accumulated ticks for all logged flux transactions should not be able to exceed 7990637 ticks. While probably impossible I'm ok with zero flux changes during the full time. I'm can follow as long as all the flux data together equals any number between 0 and 7990637. But with one clock and exact start/stop there should be no way to get more than 7990637 ticks summing up all the individual flux times. (And for that we would have to detect a flux change at exactly 0 and 7990637 ticks.)
Of course things change when we have more than one clock: These will next to be sure out of sync and explain the derivations.
Bitcells are not on my radar for the topic here at all. But I understand that when we write e.g. a single sector on real HW it will never be in sync with the pre-existing data. When decoding we'll always have flux transitions outside of the "expected" bit cell. Which is the reason why we are writing the Syny Bytes (zeros) prior to the (I)DAMs, allowing the PLL to find the new bitcell window. In reality the bit cell window and also the clock is shifting around all the time even when we are in sync.
Nevertheless the explanation of the Index mode may be what I was looking for, assuming it also can stop reading after the index mark when creating a image.
After all all the images I recorded with Index seems to be correct, the sum of all the flux ticks is less that the index2index time.
For the three images of the same disk I got those values:
Index2Index sum of all flux times
199783600 199782750 -> 850 free ticks
199773900 199772425 -> 1475 free ticks
199775275 199774425 -> 850 free ticks
Which seems to underline that the Index2index time can't be aligned to individual flux ticks: 21-37us is a serous offset, especially when the last flux id for the index again.
Would it be safe to say that the Index2index time can only be used to determine the rotation speed and and can't be used for anything other?
I also should point out that according to this discussion at least fs-uae is decoding the first flux bit wrong : The code is not handling the last flux transition as mark for the index pulse and this should not be able to read an XDF image from my point of view.