I only know the Intel 8272 a bit (via the NEC uPD765 floppy controller in the Amstrad CPC), but what's fascinating about those old-school floppy controller chips is how high level their "API" is and how autonomously they operate.
The chip accepts commands like "seek to track xyz", "format track", "read track", or "read or write a range of sectors", and the chip would go ahead and do its thing (with data transfers optionally via DMA - but this isn't supported in the CPC) and a couple of seconds later it would tell you "ok I'm done", or "oops I encountered this error".
One would rather expect this sort of functionality implemented in a high level operating system function or in some sort of software driver instead of baked into hardware. This also explains the chip's complexity I guess (e.g. 22k transistors, 6x more than a 6502 and 2.5x more than a Z80) - because it actually is a fullblown CPU with a microcode ROM and some floppy controller bits tacked on the side ;)
> One would rather expect this sort of functionality implemented in a high level operating system function
Almost counterintuitively, floppy drives were actually very fast compared to the CPUs early on. The DMA transfers were more to bypass the CPU than anything. For the CHS addressing some formats would implement interleave of the sectors (ie: 1,6,2,7,3,8,4,9,5). This would purposefully space sequential data apart so the CPU would have time to process it while passing over out of sequence data before encountering the next section of it. Putting more load on the CPU compounds this and was why dedicated FDC chips never went away.
Also fun fact,the usage of the ISA DMA interface is why you can't have full featured native floppy controllers on modern motherboards, that doesn't exist any more.
On the PC platform, the floppy is hardwired to DMA channel 2. DMA "channels" were orginally provided by an Intel 8237A DMA controller or compatible, and this is an ISA device.
DMA and FDC controller functionality got taken over by chipsets. ISA became the LPC bus, which still exists - and I believe will keep existing, because TPMs use it. But not sure if modern PCHs include the ISA DMA functionality any more. The floppy was really the only thing that used it.
PC floppies don't have to use DMA, they can use PIO.
So ...
- you need to create a PIO floppy driver for your OS
- you need something that takes floppy controller signals and converts them to LPC (signaling is not the same) and something like that doesn't exist (FPGA hobby project to the rescue)
- you need to wiire that into a modern PC's LPC bus, meaning you need to physically connect those LPC pins to an LPC debug header on your motherboard (if it has one-and if it does, you probably have to add header pins)
- then you need to do something to convert SATA power from the PSU to the floppy's four-pin mini-Molex. I think there's big Molex (IDE hard drives) to double-mini-Molex so with a SATA-to-Molex adapter you can "frakenstein" that.
LPC does DMA just fine, there are off the shelf LPC SuperIO chips with FDD support. There is also this project trying to bring ISA back from LPC https://www.vogons.org/viewtopic.php?t=93291
>ISA became the LPC bus, which still exists - and I believe will keep existing, because TPMs
already superseded by almost 10 year old eSPI. eSPI dropped DMA support.
It was a little before my time, but I think the approach came from minicomputers, which were probably the main application for floppies at the time the first controller chips were designed. Minicomputer interface boards (at least the ones I'm familiar with for the pdp-11) offloaded real-time processing from the main CPU, and also provided a consistent interface to software across differing physical hardware. Also presumably the economics in a minicomputer environment tend to favor a more complex interface board vs slowing down the CPU and adding OS complexity. Note that the concept of device drivers that we have today didn't quite exist -- if you were running Unix V7 you'd need to add source to your kernel tree and recompile to add support for a new kind of device. This favored hardware that looked like some older hardware as far as the OS was concerned. That's easier to arrange with a more complex interface board.
In 1979 or so we booted our DG Nova 2 from tape by toggling in the initial bootstrap program from the front panel. This was practical because it only took a handful of instructions to tell the smart drive controller to load the first block from tape into memory at address zero, and then you just added a jump to zero. This saved us the expense of a ROM card. I had the minute or so of motions to toggle in the boot sequence memorized in my fingers like a Bach fugue.
I believe this is one of the insights Steve Wozniak had that allowed them to make Apple // hardware a lot simpler and cheaper than the competition. They implemented this sort of stuff in the operating system.
Commodore had these complicated chips too - for example the 1541 disk drive had the same 6502 CPU as the C64! They were able to compete on the price in the 80s by the virtue of owning their chief chip supplier, MOS Techonology.
I guess it depends on rhe application. Sometimes for speed to market and engineering simplicity the Intel solution is pretty good - though obviously eccentric. Not everyone has a Woz sitting around in their pocket.
That's about the same level of autonomy modern disk controllers provide.
Commodore disk drives on the other hand were more high level. They operated at a level closer to that of a file server, and would field commands such as "list the directory". The DOS ran on the drive itself.
That's really a different layer in the stack. Those PET disk enclosures had floppy controllers inside them, and a CPU. More like a network attached file server in modern terms.
> One would rather expect this sort of functionality implemented in a high level operating system function or in some sort of software driver instead of baked into hardware.
Can only speak for the more common TMS2793 as used in many MSX floppy systems. Operations like "seek" were basically the FDC pulsing a "head step" signal a # of times, and (optionally) attempting to read a sector mark on the disk to verify r/w head arrived at the correct track.
Operations like "read sector" or "format track" etc weren't performed by that FDC stand-alone, but only served as command to start the process. CPU (Z80 here) would poll some FDC status bits, pass contents of track to format to the FDC, all in byte-for-byte tightly programmed loops. Think ~10 us or so per loop iteration (no DMA).
For some portions of the data a CRC was calculated, and that was done by the FDC in hardware iirc.
So all in all the 'smarts' included in that FDC wasn't that much. I'd think that was true for most FDCs of the day, and the 8271 described here is kind of an outlier there. Of course things may be very different for more advanced/later FDCs like those included in Pentium-era & later PC chipsets.
The NEC765 used in the IBM PC is also "high-level", and so are all the later compatibles. There is no command to read or write raw data, you specify the (starting) sector number, and the controller will start reading the disk, but only transfer the data field over DMA once it finds a matching header field.
I think Acorn made a big mistake using those chips for their floppy disk drives, they were expensive and availability was not good.They should have used the WDC1770 instead but that's life.
Acorn was badly mismanaged. BBC Micro Computer Literacy Project was the best marketing any money could buy, and yet Acorn still managed to not be able to keep up with BBC royalties while selling tons of BBC Micro/Master computers.
The chip accepts commands like "seek to track xyz", "format track", "read track", or "read or write a range of sectors", and the chip would go ahead and do its thing (with data transfers optionally via DMA - but this isn't supported in the CPC) and a couple of seconds later it would tell you "ok I'm done", or "oops I encountered this error".
One would rather expect this sort of functionality implemented in a high level operating system function or in some sort of software driver instead of baked into hardware. This also explains the chip's complexity I guess (e.g. 22k transistors, 6x more than a 6502 and 2.5x more than a Z80) - because it actually is a fullblown CPU with a microcode ROM and some floppy controller bits tacked on the side ;)