Reference of first flux transition

[admin]

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?

Yes, but only for the LAST revolution (when the capture ends).  So, the very first bitcelll will be a value from the index start position, which will be in the middle of that bitcell period.  On a multi-rev capture the data is uninterrupted for each of the revolutions, except the last revolution where the last bitcelll time will be cut short because the index pulse occurred.  SuperCard Pro is an interrupt driven hardware capture device.  The start and stop are triggered by the index pulse sensor.

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.)

No.  You don't do that.  The index to index time is the ACTUAL time it takes for the rotation, down to the 25ns resolution.  It's 100% accurate, as are the bitcell times (reported by the drive - which could be wrong if the bitcell was invalid).  You don't add or subtract anything.  The data presented is an exact representation of what the disk drive sees.

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.

It's possible because of drive speed variations and how invalid flux works.   When invalid flux occurs, the drive will spit out a bitcell duration that is somewhat based on the reversal time, and that is affected by the drive's speed.  I have seen many cases, especially with NFA (no flux area) protection schemes where the drive's PLL circuit takes serveral bitcells before it re-syncs, and I have also seen a lot of cases where flux reversals are actually joined together making a longer than normal bitcell time.  For the most part, it's pretty close in time (1.200us is obviously not much), but these are always 100% due to invalid flux.

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.

There is no rounding at all.  What you see is the information provided BY THE DISK DRIVE.  There is no interpretation here.  It's a very simple interrupt driven 25ns hardware capture.  The disk drive is solely responsible for the data you are seeing. In cases where you add up the bitcells and they exceed the index to index time, that is due to the drive speed variations. These drive speeds are all over the place during a revolution, and that really depends on the drive. Remember that these are using brushless multi-pole motors and every pole firing changes the drive speed slightly. In the grand scheme of things it doesn't matter, but when you are capturing at the 25ns level these are things you can see going on.

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 than what can fit into the index2index time...

Yep, and this is not uncommon - just like it is not uncommon to see fewer bitcells compared to the total time, and if you do repeated reads you are going to find that the actual number of bitcells captured can actually change as well... all depending on how the drive handles the invalid flux is on the track.

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.)

There is no "stitching" going on.  There is 512K of RAM on the SuperCard Pro board and the capture just fills the memory.  The index to index time is handle by a separate asynchronous interrupt.  That is why you get a table of index to index times separate from data stream.

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.

I don't think you realize what disk drives do with flux data.  The flux reversals are converted into a bitcell time.  The drive's clocking circuit is responsible for that.  There is a particular "window" that the drive can use and anything outside of that window is invalid and unpredictable.  This is why many PC disk drives can't handle writing (and sometimes even reading) Macintosh 400K/800K disk format.  Those use a variable speed drive so the reversals are not typically within the normal flux window.

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.

The source code for HxC is available, and that already has the support you are working on done.  Sam Owen has code available as well from SamDisk, there is also a8rawconv, and a slew of emulators with source code available.

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.

This is all perfectly normal.   VALID data will always be correct.  It's the invalid data is what will throw off everything when you start analyzing to this degree of accuracy.