Dragon FDC implementation notes.
The Dragon FDC design differs a bit from the Tandy one. Some of the differences are simple, others are quite fundamental and may mean low level changes to the CoCo design are needed...
The first thing is that the address decoding between the two interfaces is different.
On the Tandy CoCo controllers, an 8 bit latch is used to implement a drive control register at FF40, and the WD floppy controller IC has a base address of FF48. On the Dragon controller, this scheme is reversed, with the floppy controller IC based at FF40 and the latch at FF48.
The latch register bits are also rather different. In particular, note that drive select differs and that side select is internal to the WDC2797, but comes from the latch on the CoCo scheme because the WD1773 doesn't have an ouput pin. The read / write synchronisation / interrupt handling also differ greatly. Both implementations have an interrupt enable bit, but in the CoCo this turns on DRQ based HALT assertion to synchronise sector byte reads and writes. This is auto-disabled by INTRQ, which generates an NMI signal.
On the Dragon, INTRQ is just gated via an enable bit in the latch to NMI, and DRQ is routed directly to the FIRQ/CART line in to the PIA. The sector data read and write loops mask and disable IRQs at source, and mask FIRQ. They can then SYNC on incoming FIRQs to know when to read or write each byte.
This means that the WD2797 implementation must toggle DRQ per byte during sector reads and writes in order to generate the required edge triggers, and it must do this with reasonably realistic timing, because a read of the PIA is needed to reset the FIRQ generation for each byte read. In other words, DRQ must be reset, by reading / writing the data byte and then the PIA FIRQ generation must also be reset by a read before the DRQ triggers again.
Without these DRQ edges being generated with sane timing, there won't be any FIRQs for the Dragon DOS read and write loops to SYNC on, and sector reads/writes will fail. In contrast, a Tandy controller implementation could well ignore DRQ entirely and just let the DOS code spool the entire sector in / out without the HALT mechanism ever being used. I suspect this may be the cause of the problem getting the Dragon controller implementation going.
Hope this helps - it's guesswork of course, but once all the addressing and control bit function changes are done, DRQ behaviour is the likely culprit if things don't start working immediately...
Kind regards,
MikeM