KryoFlux - It's All About Cell Size

2009-11-12

We are now at the point where we are trying to get real data out of the KryoFlux dumps.

In the process we realized two things:

1) The read rate (directly affected by RPM) is theoretically unimportant as long as data remains physically readable. However getting data faster can introduce precision artefacts.

Let’s explain that.

Imagine you want to read a timing value - that’s what we do in KryoFlux. It’s the measurement of cell-size - how long you can count until you see a change. You get an absolute time by understanding what the reference clock is counting. Say you have a drive running at 300 RPM, you read a value that is, for example, 11. It’s easy to see that if you read the exact same cell at double the RPM rate, at 600 RPM, you would read half the cell size measurement value: 5.5. Now, a timer only ever reads integer values, so instead of 5.5 you’d read 5 and the remainder is basically added to the next cell size. In practice this shouldn’t make any difference apart from very poorly readable disks: 1 timer unit in our case is 41 ns (nano-seconds), and the cells we want to measure are in the range of microseconds (1us = 1000ns).

We have exceedingly good sampling resolution, so this is almost entirely a theoretical problem. It is still worth documenting.

2) It is important to know the target RPM of the drive/system when decoding. It is possible to guess it, based on the number of flux changes found, but that is a bad idea for partially written tracks; you wouldn’t be able to tell difference between a slight variation in speed (by design or simply drive speed wobble) or cell size.

Why do you need to know this?

Imagine you have a drive sampling a disk at 300 RPM, but the target system is using a 600 RPM drive to read the same data. At 300 RPM you’d read, for example, a 2 us cell. However the target system running at 600 RPM would see this as a 1us cell. The 300 vs. 600 RPM examples are obviously off the wall, however a 300RPM vs 360RPM is very realistic, and yields a 20% difference between how data would be seen by one system and another. Again, you could guess which one is the correct RPM, but partially written tracks, or non-standard cell sizes used for mastering, would render such guesses very inaccurate - and so spending effort to implement some sort of guessing is pointless. To summarize, a decoder of the flux transition stream, for any platform, has to have the following understanding of the target system:

1. RPM of the drive used for sampling the disk (already available, mentioned here for completeness)
2. RPM of the drive used for reading the disk
3. The cell rate selected for the FDC
4. The tolerance allowed by the FDC

In accordance with these requirements, the time measurements should not be transformed at all in the DRAFT format. Only a platform-specific decoder would have the knowledge to interpret the data correctly. This is also particularly important when decoding disks that implement some sort of ZCAV (Zone Constant Angular Velocity) recording technique, such as the Commodore 64 and Apple Macintosh, where bit cell sizes differ depending on where on the disk a track is located. Even very weird drive systems (well, if they exist...) can be fully simulated with a decoder that supports all our recommended requirements.

Doing it this way is more complicated, but well worth it.

We could do some simple data correction by varying the target RPM in a decoder implementing the scheme above. This would simulate the effect of a disk mastered on a slightly misaligned drive that doesn’t read well on real hardware (like having a few bits off sometimes), but was verified correctly on the misaligned mastering device.

For example, when we encounter bad data, we get our analyser, CTA to try and change the RPM (within reason) automatically and see if it then sees correct data. This might probably work for many bad disks without real physical damage, which would save a lot of the redumping that is currently done to get a good read.

• We checked the Trace documentation and have seen there were Amiga scripts specified for 600 RPM! That is, make the mastering twice as fast (with half sized cells compared to 300 RPM); this probably required some higher quality/modded drives as well as better disks though.
• The only thing that Trace has as additional data for mastering is the Oersted. There is not much we can do about that though, apart from either using specific media and/or modded drives/heads.

The Amiga HD drives ran at 150 RPM. The target cell rate for Amiga is 2 us or 4 us only, so if you want to read 1 us cell data without a new FDC, the only choice was to halve the drive speed. It would be neat to try and read very old disks (like some old C64 ones) at 150 RPM. It’s probably not something we would want to do normally, as it would mean dumping a disk would take twice as long, i.e. about 7 minutes. Similarly, if we have a large batch of disks to do, and little time, we could have a drive running at 600 RPM for easy to read disks, making dumping a disk about 1.5 minutes! If it fails, we can then resort to 300 RPM.

The question is:

1. Is there any drive out there where we could change the drive RPM programmatically?
2. Is it possible to add some device for some drives that we can control to do this?

It would be super cool, and probably be the most advanced dump/duplication system ever.

(later)

After some research it seems that:

Point (1) seems unlikely. Possibly the only ones available are only physically adjustable, and only for speeds between 290 and 310 RPM. We have one of those, but it is not widely available, and not helpful if we can’t control it in software.

Point (2) is also unlikely. Modern drives probably do speed control via their built-in logic, buried in the silicon. There is not much point doing that, we would have to hack a variety of different drives to make it accessible for people.

We could go crazy and toss the complete drive electronics and directly do motor, index syncing etc. ourselves... but we will leave that until KryoFlux version 2. Actually, we’re serious enough about that to look into it...

Started working on getting transformed cell data out of raw dumps.

Considerably improved the precision of the statistical analysis and some other calculations.

Investigated some weird drift values and fixed a bug related to that. KryoFlux is not limited to detecting and sending index signals only at flux reversals - it can and does store them even if they occur between flux reversals, and stores cycle exact timing information identifying the location. Normally if a track has loads of flux reversals it does not matter much, however on tracks where flux reversals are less frequent, such as on unformatted tracks or partially written tracks it is very possible that thousands of cycles happen between two flux transitions. The firmware correctly calculated the exact position, however this information was not used in the calculations, giving incorrect results. Now drift values are extremely low - how they should be regardless of flux content - this will also improve the conversion between sampled cells and actual data bits.