OK, short update. The FDC emulation seems to be working correctly for sector reads and writes, in single and double density, both Percom and RadioShack doublers. Tested wtih TRSDOS 2.3, 2.7, LDOS 5.3.1 (and less aggressively with NewDOS/80).

Testing/debugging incurred a bit more work than expected, since the various DOSes use different techniques for different things; e.g. some use a loop counter to time index hole passings, and others use the interrupt-driven 'heartbeat' counter. (In the latter case I wasted a couple days debugging in the desktop development app only to eventually discover I had not implemented the heartbeat interrupt in that environment. sigh. Most of that time was spent disassembling the OS to figure out why it specifically was unhappy, so at least I got some pleasant disassembly time in....) Another one was detection of the disk density -- LDOS was reporting double density disks as single density because it tries to figure it out by reading the dir track first as single-density, then if it fails, retries as double density. But my virtual floppy implementation was reporting 'success' on reading sectors without considering that a single density FDC cannot read double density magnetics. So I needed to add some logic to make those reads fail; and then LDOS behaved as expected.

I did implement also ReadTrack and WriteTrack. I had been dreading these, but they wound up being fairly easy. I also think they work correctly -- at least in the virtual floppy implementation. However, I can't break out the champagne yet (well, maybe some of the cheap stuff), because I still have some issue whereby FORMAT is not working (which is what uses those commands). In LDOS I get a formatted disk, however, every other track (odd) is single density. LDOS is indeed explicitly requesting to change FDC's, but obviously it should not be, so "why?". I disassembled the double density driver, and that looks sane (or rather my understanding seems sane relative to what the disassembly showed). Anyway, the driver issues controller select changes based upon a bit in a byte in a structure. There are 10 of these, and I think collectively they are called the 'Device Control Table' ('DCT'). All the operations I have seen use the IY register to be the 'this' pointer referencing the target device's structure instance, and in this case +3 is the bitfield I mentioned. It uses bitmask 0x40 to indicate single(0)/double(1) density.

Stepping in the debugger, I can see this value flapping wildly between, say 0x4c, and 0x04. WTF? this should be stable since it represents the characteristics of the drive. I also note that IY is wildly off in the weeds at 0x656f, and I know that normally the DCT is at 0x4700 + nDevice*10. Hmm. Corruption of CPU state? Jeez, I would think I would have seen the effects of a bug of that nature long before I got down to the execution of an entered command for formatting a disk. But maybe -- read/write track do alloc new, special, structures (the track image and state data), and write does alter memory.

Anyway, I did a cursory disassembly of FORMAT/CMD and it seems it makes a copy of the DCT entry for some reason, so the IY value is not completely insane, but I need to understand why it's flapping in the wind.

Also, TRSDOS 2.3 is not formatting, either. This is significant because it is a single-density-only OS, and is blythely unaware of 'selecting disk controllers' -- that's so 1980! -- so it's not a density thing. Also TRSDOS 2.7 hangs at 'analyzing disk' before getting into formatting at all.

All this smells like 'status register infidelity', so I guess there's going to be more disassembly and single stepping in my future. Single-stepping; hmm. If there is a 'Texas two-step', is there a 'Wisconsin one-step'?

Anyway, on the plus side, sector reads and writes to already-formatted floppy images seem to work just fine, which is the 90+% use-case. So it's quite usable. Still, I must have this feature because I prefer that the emulated environment not have 'forbidden' uses.