Reference of first flux transition

[AlWe]

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.

My assumption was, that the first flux is relative to the index and the last flux would be simply the last flux transition reported by the drive.

And by subtracting all flux time values from the index2index time I can determine the flux-free time between the last flux and the index again. (And adding that time to the value of the first flux transition again would then lead me to the flux2flux gab between the last and the first flux of one revolution.)

For multi-revolution images this would have been allowed to pinpoint the exact time we got the index signal. With the real format we only know that the index pulse must have been between two recorded flux times but can only pin down the exact time for the last revolution. (Since we still get the time between the last flux of rev 1 and the first flux of rev 2 there is no real downside I see on that. Just not what I assumed...)

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.

I'm still pretty new to flux images... but the sample XDF disk I found in the forum here https://www.cbmstuff.com/forum/showthrea...08#pid3908 seems to have data written over the index, see the attached picture. (It looks at least possible that the crc errors of the sectors in this image are caused by the unusual fact that we have date written over the index pulse and either the supercard or HxC is not handling that correctly. Once I get simpler images working I'll plan to look into that more.)