3

I'm building a FDD controller out of a $10 microcontroller. It's mostly working pretty well, and I can read both 720kB and 1440kB PC MFM disks (the only ones I have to test with).

However... if I read a 720kB disk, then change disks to a 1440kB disk and try to read that, I get weird sporadic data dropouts in the pulse stream from the drive --- I mean, long sequences where I get no pulses at all. (And, very occasionally, sometimes no data shows up at all; READ DATA remains at 5V for the duration of the track.) I can detect these and retry and mostly they go away:

Track 68 side 0: 179 ms in 75904 bytes, 1 dropouts Track 68 side 1: 179 ms in 75904 bytes, 1 dropouts Track 69 side 0: 180 ms in 75904 bytes, 1 dropouts Track 69 side 1: 84 data dropouts, retrying Track 69 side 1: 179 ms in 75840 bytes, 0 dropouts Track 70 side 0: 179 ms in 75904 bytes, 1 dropouts Track 70 side 1: 179 ms in 75904 bytes, 0 dropouts Track 71 side 0: 200 data dropouts, retrying Track 71 side 0: 90 data dropouts, retrying Track 71 side 0: 179 ms in 75904 bytes, 0 dropouts Track 71 side 1: 180 ms in 75904 bytes, 0 dropouts

This only happens the first couple of reads after changing disks. If I leave a 1.44MB disk in the drive for a while, the drive seems quite happy and I get reliable data.

The fact that these go away on retry indicates that it's not anything to do with the disk at all, and I'm nervous that there's some sort of calibration after media change which I should be doing but aren't. Some of my data sheets (e.g. https://hxc2001.com/download/datasheet/floppy/thirdparty/Teac/TEAC%20FD-05HF-8830.pdf) mention autocalibration but don't actually explain what this is...

What I'm doing on disk change is a standard homing sequence, where I seek back to track 0, then I seek one more step (as one of my data sheets suggested that seeking to track -1 was necessary to reset the DISK CHANGE line), and then I seek to the track I want to read. I don't seek between retries. I always read a complete track at a time, from one index pulse to the next. I have generous delays at each stage.

I've played with the DENSITY SELECT line and it seems to make no difference --- I think my drive ignores it and figures it out automatically from the hole in the disk.

Is there anything obvious I'm missing here?

5

Solved:

Turns out that my microcontroller board, an otherwise excellent Cypress CY8CKIT-059 PSOC5LP, had a 1uF capacitor between DENSITY SELECT and ground. So, whenever that pin changed state, the value the drive saw would change quite slowly over time.

Crudely ripping it off the board made it all work. Frankly, I'm amazed it did anything useful at all without that fix.

The key insight here was observing that if I changed floppies, reads would fail for a certain wall clock time and then everything would be fine. At which point I remembered the capacitors. This is the third time I've been bitten by this for only two PSoC based projects...

2

HD floppies (both 1.44MB 3.5" HD and 1.2MB 5.25" HD floppies) have a different coating with a different coercivity (for details see e.g. here. At least for writing (and maybe also for reading, I am not sure) you need change the characteristics of the analog circuitry, and possibly also timing.

So there is a fundamental difference. Your drive may indeed take care of this detecting the hole in the floppy, but it additionally may also need a correct density select line, because IIRC one could format HD disks for DD.

The dropouts could very well be related to the different coercitivity - if the signal is weaker because the analog circuits are set up for the wrong coercitivity, and especially weak in some parts of the disk, then the PLL (or whatever the drive uses) may not synchronize correctly, and you won't get a signal. OTOH, on a second attempt, it may just work fine depending on what state the PLL is in when it hits the weak part.

So much at least for the background, I don't have a concrete suggestion how to fix this - in your place, I'd use a scope and see how the signals in various places look.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.