On Fri, 22 Apr 2022, Maciej W. Rozycki via cctalk wrote:
You can of course build a PCI FDD interface around the NEC uPD765 or an equivalent controller, but you can't make it compatible with existing PC software, because too much PC specifics has been embedded there around the 8237 DMA controller and DMA page registers at fixed port I/O locations, which is inherently incompatible with the PCI decoding model.
While the lack of DMA would make it impossible to have complete compatability, it could still be partially compatible and have its own version of INT13h that would work for most? floppy utility software.
Consider the PCJr. It did not have DMA, and wasn't compatible with everything for many MORE reasons, but some/most INT13h access to floppies did work. There were, however OTHER problems; IBM made the mistake of thinking that the PCJr could compete on its own as a home computer, failing to realize that everybody who used PCs at work expected to be able to use the PCJr as a PC, and to be able to expand it the same as a PC. As a further example of IBM's error in perception of the PCJr, they supplied it with a chiclets keyboard (just like the Coco), and then later had to give away FREE "real" keyboard replacements for the chiclets (just like the Coco).
Don't expect access BELOW INT13h, talking to the DMA and FDC chips directly. For example, reading side B of a Kaypro disk, where the head number field in the sector headers doesn't match the number of which head it is on, and isn't the expected '1'. Fortunately, most computers with WD FDCs that used invalid head number fields in the sector headers didn't CARE what was there, and would work with disks formatted with correct head number fields.
