KryoFlux - Out Of Band (OOB) Trace Output

2009-11-07

Rewritten the host transfer, decoder and other related components, making it more production quality than used to be. All possible errors are now detected by the decoder. Real data is now extracted, and information that is supposed to be re-generated by the host is now re-generated, such as index signals, disk revolutions etc.

Now supports more than one instance of the decoder and post-process routines, making it possible to be multi-threaded.

Statistical analysis is performed using the OOB data and data transferred, such as:

Reference clock
Drive speed (RPM)
Transfer speed
Flux reversals per revolution
Data drift

The data drift is time that has not been accounted for: the difference between the total time for all flux reversal samples and the reference clock. In other words, if there is data that the hardware couldn’t measure because it changed too fast or reads differently, it can be detected as drift. Tracks containing data drift are usually well below 1 microsecond for the entire track, but even on unformatted tracks a few dozen microseconds max. Compared to 1/2 microsecond cell sizes, this means that no valid data ever gets lost, but even poorly readable data should be fine.

Here is the current trace output captured by the host PC. It shows control of the drive and this captured OOB information.

01a3ff74: reset=0
01a402b9: descriptor=C2 DiskSystem/version=1.00/date=Nov  7 2009/time=14:46:33
01a402cd: density=0
01a402e1: motor=1
01a405f2: track=0
01a40606: side=0
01a4061a: stream=1
01a40a8b: stream=0
t: 256060, flux rev: 49728, drift: 0.133 us, transfer: 237608 B/s, rpm: 299.901
01a40a9f: side=1
01a40ab3: stream=1
01a40f57: stream=0
t: 267868, flux rev: 49762, drift: 0.533 us, transfer: 238442 B/s, rpm: 299.900
01a40f6b: track=1
01a40f92: side=0
01a40fa6: stream=1
01a4141f: stream=0
t: 257528, flux rev: 49767, drift: 0.732 us, transfer: 237854 B/s, rpm: 299.900
01a41433: side=1
01a41447: stream=1
01a418e4: stream=0
t: 267183, flux rev: 49767, drift: 0.333 us, transfer: 238442 B/s, rpm: 299.903
01a418f8: track=2
01a4191e: side=0
01a41932: stream=1
01a41daa: stream=0
t: 258754, flux rev: 49764, drift: 0.932 us, transfer: 237854 B/s, rpm: 299.912
01a41dbe: side=1
01a41dd2: stream=1
01a42279: stream=0
t: 267630, flux rev: 49577, drift: 0.599 us, transfer: 237577 B/s, rpm: 299.895

...

01a70cc8: track=81
01a70cee: side=0
01a70d02: stream=1
01a7117c: stream=0
t: 68193, flux rev: 8361, drift: 4.328 us, transfer: 62811 B/s, rpm: 299.896
01a71190: side=1
01a711a4: stream=1
01a71648: stream=0
t: 65817, flux rev: 7697, drift: 65.592 us, transfer: 58597 B/s, rpm: 299.893
01a7165c: motor=0

As you may notice, the number of flux transitions have drastically decreased on track 81. This is an indication of unformatted data, and the reason it shows any flux transitions at all is because of the drives AGC (Automatic Gain Control), which increases until transitions are “found”. Of course, in reality, there are no transitions, they are simply forced by the drive. This will be clearly seen in our analyser, CTA.

Check out the drift on those unformatted tracks!

The drive speed is necessarily captured, as it influences how the flux transitions are interpreted. If the target system works at 300 RPM and we read the data at 300 RPM (like on currently preserved Amiga titles) then there is no issue. However, by capturing the drive speed, we can read disks written at 360 RPM, but read on a 300 RPM drive, and have the signals interpreted properly by whatever software wishes to use them.

You may wonder why we have the drive speed captured for each track. This is partly for more reliable representation of the flux transitions at that position on the disk, but it also allows us to support things like Commodore 64 disks with varying width bit cells, and the variable rate drives used in old Apple Macintosh computers.

It doesn’t matter whether you vary the rotation speed or the reference clock for cell generation - it is the same result, different sized cells that we can read perfectly well. The drive itself must be capable of reading the signals of course, and may need to step to tracks if they are not at their standard locations.