KryoFlux - Commodore 64 - Index Signal Levels

2009-11-14

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. Even if it is just a bad index signal, it could be real problem with the motor, so we might as well re-read it anyway, there is no point in saving potentially bad data.
  • Change the signal detection method from edge detection to level detection. The hardware is sensitive enough to catch quick changes anyway.
  • Add hardware to filter/stabilize the index signal.
  • Change firmware to ignore bad index signals.

We checked the stream. From the data captured it looks like the index is detected, then another one is detected about 4 ms away. This is the amount of time a drive would hold the index signal, so what possibly happens is the logical level drops but then asserts again for some reason. If the assertion is very short, changing the detection method would only really hide the problem. It happens more on one of our drives than the others, and we have never seen this at all with 3.5” drives and dumps. It might be a level problem because we are sampling 5V TTL (Transistor–Transistor Logic) with a 3.3V board. The board is 5V tolerant, but the operating voltage of only 3.3V of the internal pull-ups seems to be problematic. Due to drain, the voltage of a signal line can drop below the logical 0 (all floppy signals are active low, so a signal being grounded means a logical 1, whereas the pull-up-level is at e.g. 3.3V for the ATMEL development boards), therefore making it impossible to detect if the line is high or low.

We’re addressing this by adding our own pull-ups with 5V (although the ATMEL operates at 3.3V, it does accept 5V TTL for input) to the coming PCB and disabling the internal ones. External level shifters should not be needed, but we will do some testing to see if it works reliably with the external pull-ups, and if not, we’ll add shifters.

We will also detect this problem in software, and that is done by watching for a sudden change of RPM. “Sudden” being a change that is (for example) more than 5% between two revolutions - that would allow using even fairly poor drives, but it would still detect hardware glitches. We have implemented this change in the host software, it will now detect a sudden change in the drive speed and will retry the track. It is better to do this in the host rather than the firmware as the host has a better understanding of what is acceptable based on the current use.