PCI floppy controller

[Fred Cisin]

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.