Reference of first flux transition

[admin]

Let's stick to single-revolution images for now.
The main issue I have is, that when I add all flux times of one revolution together I can get a bigger value then what the header has for index2index. Not always but still quite often... At least 1/3rd of all tracks, based on my very small sample size of three images so far. (I also see that in an amiga scp image but there I only checked track 0.)

Sure - that's quite possible and perfectly normal.  If you use the editor/analyzer and click on the DISPLAY FLUX button you can see the information about the read including the total number of bitcells and total index time.

With your confirmation that the first flux bitcell is relative to the index that would then probably mean that it's not stopping exactly at the next index pulse but can add some flux transitions after the index at the end to a track. But that would then be up to maybe 3ms and definitely > 100 25ns ticks...

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.

In that case I can simply drop the bitcells which would be located behind the 2nd index pulse and directly jump back to the first flux of the track and figure out what the real flux2flux interval would have been without the Index.

Maybe a simple ASCII of how that could look like:

Code:

INDEX
1st flux (ticks since INDEX)
2nd flux (ticks since last flux)
...
last real flux of track
INDEX                   
flux (probably ticks since last flux instead of INDEX)
last flux recorded for TRK

To get the time between the last real flux and the index I would have to add flux times together until it gets bigger than the index2index time, remove the last addition again and then subtract the accumulated time from the index2index time to get the time between the last real flux on the track and the 2nd INDEX.
Would be a bit unexpected but trivial to handle...

Of course none of this necessary. I don't think you understand how invalid flux works.  The bitcell times will be basically wrong for anything that is invalid.  The capture is right, but what the drive itself outputs depends on what type of drive it is and how THAT actually handles flux reversals that are not within it's normal clocking window. You can never just add up the bitcell times and have them the same for every revolution, or matching the index pulse. You can get close IF they are very few invalid bitcells. OLD disks that use sector writing (as opposed to entire track writing) will have a LOT of invalid flux. Every time you write to a track and turn off the writing, the head's magnetic energy collapses creating a "smear", which almost always results in invalid flux.

I'm using a Panasonic Matsushita JU-257A604P 1,44MB Floppy Disk Drive, powered via the supercard.
My test disks images for that are the disk 1 from Novel Dos 7 and a Copy of MS Dos 6.2. (Both images can be decoded without any error.)

You might want to try a different disk drive, you are likely going to find different results.  Also, make sure that your USB port can handle the 300mA of current that the drive is going to need. However, what you are seeing is pretty typical for flux data. Some drives work better than others.

Are you working on a project using SuperCard Pro? If so, there is a LOT of code already written in C for handling every aspect of SuperCard Pro. You might be trying to re-invent the wheel.