I've currently been putting together a simple FDC driver and although its quite simple there are a few things that annoy me.

Seek/Recalibration - When do you seek/recalibrate? It seems to work without them (the read command bytes specify which cylinder, head and sector and an implied seek or something is done), why is there a seek then if it works anyway? Is it like calibration in that whenever you get an error you calibrate the read/write head to make sure read/write head is where the controller thinks it is, they might drift apart a bit? e.g. first error you re-seek and on second re-calibrate and seek? will not doing a seek everything now and then screw it up? This a hard one for me to test using bochs and a virtual floppy drive :/.

Non-DMA mode - i haven't actually seen any code examples for this but i imagine you just keep checking the DIO status bit and read it in byte for byte. An obvious absolute no no in a multitasking due to redundant status byte checks and even if you guess how long to wait and give up your time slice you will most likely wait too long, but in single-tasked os i've heard its faster (10-20%)...apparently some floppy drives don't even support non-dma mode? Whats the score with this?

Sleeping - A floppy drive being mechanical with moving parts there seems to be a lot of code with sleeps after seeks and the like. Even though the fdc reports its ready in its msr the read/write head has just spun around like 2 milliseconds ago and making it do something else while its still practically moving can screw up its position.....i see 10ms sleeps after seeks and sleeps after reads and writes so it can settle. I really can't stand this, its not an exact science so this kind of stuff annoys me. There must be some *officialish* guidelines on what delays are required after what operations to prevent things going to poo?

Resetting - Is it safe to assume that if you boot from a floppy drive that the bios has calibrated the drive, is currently seeked at logical sector 0, set the correct transfer speed and has DMA/IRQ mode on with the motor spinning on drive 0? Atm i just set the motor and DMA mode to on even if they are already on. Resetting the controller completely looks like a pain in the ass though.

I absolutely hate working with controllers, most illogical pieces of crap that work in the funkiest of ways :/. Any information welcome.

Do people still use floppy disks? I haven't seen one for many years.

Yes they do.. For instance during OS development on real computers.
Floppies are still easiest way to make a bootable disk.



@calpol2004: From my experience I can say that FDC controller is not very easy piece of hardware to program with.

regards,
Mac2004

I would have thought and easier setup would be the boot-CD or boot-USB. Both are easy to make and can run on all contemporary PCs. I never liked the unreliability of the floppies or, as you have mentioned, the quirky programming needed to make then work.

calpol2004,

Legacy hardware seems strange now, but back in those days…

Newer FDCs and LPC I/O controllers have implied seek feature, the question is "how much backward-compatible your driver wants to be?"

Recalibration is useful when retrying after sector-not-found (electromechanically seek is relative to current position and tolerances always sum up most unfortunate way ) to establish reference point for heads' position.

In 3.5" FDD heads are loaded always (when FD present), it's more important to turn off motor as soon as possible (wear-leveling vs. performance). But nobody stops you from implementing command queuing/seek optimizing in multitasking environment.

Floppy drive doesn't support DMA transfers, only serial MFM. FDC does.
PIO transfer is acceptable if FDC has internal FIFO enabled (several bytes per interrupt, much simpler set-up, no 64 KiB DMA boundaries). Polled I/O may have it's merits also, e.g. in single-thread OS or synchronous serialized I/O — it's simplest (but µPD765/i8272 didn't support it internally, as i82078 does). The speed is irrelevant with fixed data rate (as far as modern computers concerned; 4.77 MHz XT probably may have trouble with PIO).

Specifications are pretty clear in handshaking protocol for FDC. Are you encountering strange errors without delays (assuming handshaking is correct)?

I'd rather make as little as possible assumptions about BIOS' behavior. Correct density (AKA data rate) is probably safe bet.

revolution,

FDC programming is funny and educative: concepts like DMA and hardware interrupts look completely different in theory and practice…

VGA/PIC/PIT/keyboard/FDC is my favorite roadmap to begin with hardware programming.

Minor point, I think you mean "wearing". "wear-levelling" means you would be moving the head back and forth to ensure all parts of the disk get equal wear! The original XT BIOS used PIO for the floppy (and the HDD). Speed was not an issue. Even my old Amstrad (4MHz Z80) could cope with PIO. O RLY? I always found the theory and practice were rather similar.

revolution,

I thought about usual scenario: copy files to FD, take it to another computer, copy files from FD. It's unlikely that heads in FDD1 will be at the same cylinder as in FDD2 (but possible: system data on 3.5" FD resides completely on cyl. 0 ) I'd imagined marginal case: 2.88 MiB 3.5" FD on XT Barely 40 clocks/byte…

Theory and practice differs as in "I know how to do it" and "I've done it"