4 ms·

Yeah, those WD 1771, 1773, 1793 FDC chips, and that NEC 765 were all over the place. Iirc they'd handle track seeking for you, and for sector read/write you eit

Yeah, those WD 1771, 1773, 1793 FDC chips, and that NEC 765 were all over the place. Iirc they'd handle track seeking for you, and for sector read/write you either needed a DMA channel or a (fast enough) CPU to move data bytes to/from the FDC, there was no internal buffering. The other thing the FDC would do is format tracks and sectors. There were all these header bytes that you wouldn't see during regular data read/write ops, but presumably allowed the FDC to recognize when to start transferring between the head and the system bus.

rep_lodsb 4y ago
And "smarter" is not always better: the NEC 765 (and later compatibles) used in PCs would always interpret those header bytes instead of allowing the software to read and write arbitrary "raw" data. This made certain formats impossible to duplicate - a benefit for copy protection schemes, but not in the user's interest - and it also limited how much a driver could optimize disk access. There was one command to read the next sector ID that the drive head was passing over, and another to read the contents of all sectors in the order that they appeared on the disk, but no way to do both at the same time. You couldn't read an entire track in whatever order and sort it out in software. Many disk formats had sectors arranged in an interleaved order to give slow computers more time for processing the data, or skewed the starting sector number from track to track to optimize for the seek time during linear reading. So just reading the sector contents without the headers wouldn't work, plus the "read all sectors" command always waited for what it assumed was the start of track. Some other controllers (at least some of the Western Digital ones you mentioned) would instead just detect the sync pattern at the start of a sector, and then send everything including the control bytes to the host. They could also format and write an entire track in one operation, with exact control over the layout. Still there was a lot of clever hacks to make the PC controller do things it wasn't designed to do. Like formatting a track with lots of very small sectors (128 bytes), most of which would then be completely overwritten - header and all - to become part of just a few large ones. That allowed different sector sizes on the same track to give a bit of extra space, but with very little possibilities to control the gap lengths (necessary due to the mechanical nature of floppy drives). So this format wasn't as optimal or reliable as it could have been with a "dumber" controller. It's hard to believe, but IBM would actually use this crazy format to distribute their installation diskettes!

rep_lodsb 4y ago

And "smarter" is not always better: the NEC 765 (and later compatibles) used in PCs would always interpret those header bytes instead of allowing the software to read and write arbitrary "raw" data. This made certain formats impossible to duplicate - a benefit for copy protection schemes, but not in the user's interest - and it also limited how much a driver could optimize disk access. There was one command to read the next sector ID that the drive head was passing over, and another to read the contents of all sectors in the order that they appeared on the disk, but no way to do both at the same time. You couldn't read an entire track in whatever order and sort it out in software. Many disk formats had sectors arranged in an interleaved order to give slow computers more time for processing the data, or skewed the starting sector number from track to track to optimize for the seek time during linear reading. So just reading the sector contents without the headers wouldn't work, plus the "read all sectors" command always waited for what it assumed was the start of track. Some other controllers (at least some of the Western Digital ones you mentioned) would instead just detect the sync pattern at the start of a sector, and then send everything including the control bytes to the host. They could also format and write an entire track in one operation, with exact control over the layout. Still there was a lot of clever hacks to make the PC controller do things it wasn't designed to do. Like formatting a track with lots of very small sectors (128 bytes), most of which would then be completely overwritten - header and all - to become part of just a few large ones. That allowed different sector sizes on the same track to give a bit of extra space, but with very little possibilities to control the gap lengths (necessary due to the mechanical nature of floppy drives). So this format wasn't as optimal or reliable as it could have been with a "dumber" controller. It's hard to believe, but IBM would actually use this crazy format to distribute their installation diskettes!