Reference of first flux transition

[admin]

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 AGC 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?

Yes, that is correct and that information is what you are seeing.  It would be great if we could just add up all of the bitcell times and that would match the index to index times, but that's not how it works in the real world. However, it doesn't even matter because the index to index time is never needed unless you are trying to re-image the disk at a different RPM. That is the ONLY time you are going to want to know the index to index time so you can adjust ALL of the bitcells (up or down) in "speed" so it fits within the track time you are trying to obtain.  The drive itself is what outputs a pulse of a certain duration that occurs when a flux reversal occurs.  The issue is that if a flux reversal does not occur within a preset window, then the results are unpredictable.  The drive can output multiple (extra) pulses or fewer pulses, depending on what the drive circuitry is designed to do when the window is exceeded.

Depending on the drive (which is the only real factor here), it will handle the flux differently.  Also, keep in mind that the start/stop is being done using the index pulse and the very first bitcell of the 1st revolution and the very last bitcell of the last revolution will be affected by the index pulse because the capture start and stop occur with the index pulse.  So, because of this alone there could be an increase or decrease in the number of bitcells due to drive speed variances and where the index pulse triggers. For disks that were creating using the index pulse to start/stop tracks, it doesn't matter if the first few hundred bytes (not even bitcells) are wrong because they are contained in the track gap. It's only disks that were not created using the index pulse to start/stop the writing is where you have to get creative and use 2+ revolutions to be able to extract one full interrupted revolution.

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.

Sure it can!  The drive will output whatever it thinks is valid flux reversals, when in fact it could be invalid flux reversals, and the drive speed is not consistent. You don't see a huge increase, but up to several microseconds is not uncommon by any means.

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.

You seem to be hung up on the fact that you can't simply add the bitcell times together and magically come out to be exactly the index to index time.  You need to get out of that way of thinking, because you have no control of what the disk drive is going to do.  Adding the bitcell times together is *rarely* ever going to be equal, and you can certainly have a value that is longer or shorter than the index to index times.   There is never any reason to even know this unless you are writing some utility like my editor/analyzer. You don't need to know anything other than there is a block of flux data and what your upper level format is (MFM, and then decode that to usable hex data).

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.

Oh... you are working with the really upper format.  You are better off looking at things from a MFM perspective because there are caveats with the FDC interpretation of the MFM data that is going to drive you nuts.

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. 

21us-37us variation is just a couple of bytes of variances at the MFM level.  That's quite acceptable.  37us out of 200,000us (a 300 RPM rotation) is 0.0185% deviation.  Consider that a track gap for the type of disk you are working with is typically 200 MFM bytes (800us-1000us long), having a 37us variation over a 200ms period is not going to be a problem for the PLL.

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?

That's all it is for!  I actually don't use that information myself for reads. I am not aware of ANY program supporting .scp images that does.  For writing or converting you need to know that. What did you expect it to be used for?  You can use it to account for drive speed variations between image files, but seriously, if you are just decoding disk images for an emulation you can be so far off and everything will still work. You can delay the reading of a track from the index pulse by several hundred microseconds and still be able to read/decode the entire track correctly. Keep in mind that the decoding window for a standard FDC is +/- 8% of the bitcell times. So, if you have a typical ISO format (IBM PC, Atari ST, TRS-80, etc. etc.) that uses 4us/6us/8us your bitcells can be off by +/-320ns on the low end (4us) and +/-640ns on the high end (8us). Nothing is critical with disk data until you get into the 2.88MB format and some DAT tape formats where sub-100ns accuracy can be required.

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.

Well, it's worked fine for years.  XDF tracks start and stop on the index pulse, and there is a sizeable gap so there should be zero issues.