KryoFlux - Flux Transition to Bit Cell Conversion (1)

2009-11-20

Generally speaking the flux conversion to bit cells works. However, for some data it fails, most notably for data that is written at the highest possible cell density. We dumped quite a few disks containing such data with both an Amiga and KryoFlux so we could compare and find out where the decoding fails. Luckily we could find a pathological case that demonstrates the problem very well, and even better has a very simple pattern that we can identify as flux reversal periods.

  • One protection uses a repeating 0x24a5 pattern as clocking.
  • Translating this to binary: 0010 0100 1010 0101

Remember, the bits are represented by the flux reversals or the lack of them, and their position as bit cells.

The 001 is the first flux transition period (since the last 1) that should last for the duration of 3 cells altogether, where cell is measured by the reference clock in the case of double density MFM - 2us. In other words the 001 pattern is represented by a 6us delay between two flux reversals. Similarly the 01 pattern is 4us.

In practice this means that the above bit pattern is represented as the values “3 3 3 2 3 2”, where each value should be multiplied by the reference clock.

Different FDC solutions try to track the drive speed variation as well as bit jitter through various means, in the case of dedicated MFM controllers, a data separator is responsible, tracking the deviation of the reference clock and adjusting the expected window for a data cell.

Now take a look at the following table, which is actually data sampled from the disk. The first column is the time measured, the second is how the measured time should be translated back to bit cells.

5.2398 3
5.4478 3
5.2398 3
3.9922 2
5.0319 3
4.0754 2

5.1982 3
5.4478 3
5.2398 3
4.0338 2
4.9903 3
4.0754 2

5.1566 3
5.4893 3
5.2398 3
4.0754 2
4.9487 3
4.0754 2

It’s quite easy to see that the simple tracking algorithm that has been used so far will fail as soon as it encounters the values that are very close to one another, yet they represent a different number of bit cells. In our example those two values are: 4.0754 and 4.9487 - just 0.8733 us away.

You may also notice that values are quite a bit off from the reference clock, i.e. multiples of 2us. Any algorithm blindly trying to follow the change of flux periods would fail here.

What real FDCs do is specific to the encoding they try to track, i.e. “cheat a bit”, guessing how to interpret the data - hence the bundling of data separation (clock and data bits) and PLL or other adjustments based tracking of data window in MFM controllers.

If at all possible, we’ll avoid that solution. Nothing specific to data encoding formats have been introduced to the translation in the host software yet, and we don’t intend to start now. It will always be the job of any software to derive such data from the flux periods in DRAFT files. However, we want to make sure all the data we have is reliable, so we need to develop a model solution that is verified, and known to work well. Developers may or may not use it, but at least it would be a verified solution for any application wishing to process DRAFT files.

Now to solve this problem... Thinking... :)