Work-In-Progress Reports for November 2009

KryoFlux - Band Analyser Results: The results from the band analyser are linked below. A fairly complex pattern based process is being used to determine the correct cell size (otherwise the peak shifts distort the values), but if that fails, the system falls back on an average model without the patterns. (more)

KryoFlux - Band Analyser: The band analyser works now, in fact remarkably well - at least on the dumps we have. It is very good in identifying the correct flux transition periods used, even if a normal average calculation yields a very different result. There is still room for improvement, perhaps a slightly more scientific approach to find the distribution and correct trend analysis, but it works well enough for now. (more)

KryoFlux - More on Flux Decoding: We have tried quite a few iterations of various algorithms now, researching each ones weaknesses and strengths. Ultimately we will probably end up with an improved version of the band analyser, plus a bit of pattern based learning, with cell tracking. As far as we can see (after over a week of analysing data), we have flux transition intervals behaving the same if they have the same neighbourhood. (more)

KryoFlux - More on DRAFT: The glossary:DRAFT format is purposefully being kept very simple. It is structured in such a way that although altering existing data in one file is inconvenient, appending new data or deleting such data by simply truncating the file is very easy. You can then convert it to simpler or more complex formats, the goal of the format is to have all the data in one place without irrecoverable changes, pre or post-processing. (more)

KryoFlux - Flux Transition to Bit Cell Conversion (2): Following on from the previous WIP, we need a reliable method to interpret bit cell data from the measured flux transition timing. One idea (after some sleep) is to derive data within a context. You might be tempted to think the 4us values are spot on, being very close multiples of 2us. In reality however, they are bit shifts from 3.6us. (more)

KryoFlux - Flux Transition to Bit Cell Conversion (1): 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 :glossary:KryoFlux so we could compare and find out where the decoding fails. (more)

KryoFlux - Flux Decoder: The density graphs are not quite right in Turrican 2 when dumping with glossary:KryoFlux, this is mostly due to very different resolution quantized to something glossary:cta can process. glossary:ct would never sample certain differences that show up with KryoFlux. This is not a big problem, and can be fixed another time. The real problem with this game is that it violates recording rules with its sync value. (more)

KryoFlux - Preliminary Decoder (2): Re-organized the host source, abstracted functionality better. Implemented preliminary flux reversal to bitcell decoder. We then implemented code to export data to the RAW format, which is read by glossary:cta, as it's the easiest way to see if the decoded data is fully correct, that is, it produces the exact same data as if it was dumped on the Amiga using glossary:ct. (more)

KryoFlux - Preliminary Decoder (1): We have now created a simple algorithm that looks at the time between flux reversals, and indicates the number of bit cells represented. There are many cases where this is not trivial. Ideally you'd have flux reversals at the exact multiples of the reference clock, for example, 2us for MFM DD, but of course this is never actually the case. The decoder should decide whether seeing a time that is say, 2. (more)

KryoFlux - Incorrect Signal Levels: With regards to the problem of incorrect signal levels, lets look at the facts: - We hardly, if ever, get wrong logical levels from 3.5" drives. - We frequently get them from 5.25" drives. Issues: * Was this never considered a problem by different hardware manufacturers over the course of 30 years? It seems unlikely. (more)

KryoFlux - Commodore 64 - Mastered Tracks: We've been testing the recent new features on some Commodore 64 disks. It's very interesting to see how tracks were commercially mastered by looking at the flux reversal counts. Each written track on the same side will have a similar number, and you can see how half-tracks are unwritten. The correct tracks are: 00.0: track 1 01.0: noise/left over content 02.0: track 2 03.0: noise/left over content 04. (more)

KryoFlux - Commodore 64 - Index Signal Levels: We have started experimenting with some 5.25" Commodore 64 dumps. One disk looks like it is written at 450 RPM on track 49.0. We took a look at the analysed signal and there is an index found there - not nice. The only thing we can do is: * Detect incorrect index signalling, and re-read the track, where one criteria could be a sudden change of RPM. (more)

KryoFlux - Drive Speed: The cell conversion now gets proper cell sizes using the target platform's drive speed and the current drive speed measured per cell. The current drive speed is interpolated for each cell using the available speed data after each revolution. While the drive speed change may actually not be linear, this is still a useful approximation. (more)

KryoFlux - It's All About Cell Size: 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. (more)

5.25" Flippy Disks: Once KryoFlux has been completed, many possibilities open up that were simply impractical before. One investigation we are currently working on is the best method to dump single-sided "flippy" 5.25" disks as used on computers such as the Commodore 64 and Apple II. After some research, we found out is that these disks were written in one pass by the duplicator, Trace, using modified double-sided drives. (more)

KryoFlux - Out Of Band (OOB) Trace Output: 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. (more)

KryoFlux - Work To Do and Compression: The board firmware uses an encoding that ensures that any time value measured between flux reversals are faithfully reproduced and not altered in any way. This means there are no values that would be clipped, clamped or ignored. Compression of the flux transition stream will be done by the host, the board is simply to weak to do anything meaningful. Currently, there is no compression at all. (more)

KryoFlux - DRAFT: We require a storage format for the flux transition stream and the associated data. We are calling this file format "DRAFT" to indicate it is pre-analysed disk data. It is yet to be defined, but it will be an open format for use by community tools. DRAFT is: * An acronym for Data Recording Archival Flux formaT. * "Draft" data, content details should be derived. * Reminiscent of beer, as in free beer. (more)