OK, I've started looking at this in earnest, with some help from dougg3. Some good news and bad news.
First the bad news: it looks like it won't be possible to emulate an HD20 and a floppy at the same time (assuming HD20 is even possible at all). The CPLD chip that Floppy Emu uses to interface with the Mac has a very limited amount of resources, and it's already almost full with the stuff needed for floppy emulation. Already I had to lobotimize it by removing support for 800K and 1.4MB floppies, just to do any HD20 testing at all. So if you need HD20 emulation and floppy emulation, you'll either need two hardware units, or you'll need to reflash the firmware every time you want to change from one to the other.
Annoying news: it's hard to get the Mac into a state where the HD20 emulation can even be tested. If you boot up with something that looks like an HD20 attached, but that doesn't respond to driver calls correctly, the Mac goes nuts and repeatedly asks you to initialize the disk. If you click Cancel, the dialog just reappears. So it's impossible to even run any diagnostic programs. But if you connect a HD20 Emu after boot up, the Mac just ignores it. It seems to cache information about what drives are present during boot up, and changing it after that has no effect. This means that uniserver's HD20 hot swapping dream probably can't work. So far, the only way I found to run my diagnostic program was to configure the Mac to run my program after boot up, instead of running the Finder.
Good news: I've implemented the disk daisy-chaining mechanism described in the HD20 doc, and it seems to work. With an emulated 400K drive second in the virtual drive chain, the Mac still sees the floppy and will boot from it. Then it sees *something* at the first position in the chain, and freaks out with the endless requests to initialize it.
Pretty good news: I wrote a test program to read random sectors from the HD20. Initially it was failing with error -64, drive not present. After the daisy-chaining changes to the Floppy Emu CPLD, now it fails with error -17, driver can't respond. Looking at the disassembly of the HD20 ROM routines, this is the error I'd expect to see if the drive doesn't respond with the correct handshake after the Mac tells it to reset. So as far as I can tell, the Mac at least thinks there's an HD20 present and is trying to talk to it, so that's good.
First the bad news: it looks like it won't be possible to emulate an HD20 and a floppy at the same time (assuming HD20 is even possible at all). The CPLD chip that Floppy Emu uses to interface with the Mac has a very limited amount of resources, and it's already almost full with the stuff needed for floppy emulation. Already I had to lobotimize it by removing support for 800K and 1.4MB floppies, just to do any HD20 testing at all. So if you need HD20 emulation and floppy emulation, you'll either need two hardware units, or you'll need to reflash the firmware every time you want to change from one to the other.
Annoying news: it's hard to get the Mac into a state where the HD20 emulation can even be tested. If you boot up with something that looks like an HD20 attached, but that doesn't respond to driver calls correctly, the Mac goes nuts and repeatedly asks you to initialize the disk. If you click Cancel, the dialog just reappears. So it's impossible to even run any diagnostic programs. But if you connect a HD20 Emu after boot up, the Mac just ignores it. It seems to cache information about what drives are present during boot up, and changing it after that has no effect. This means that uniserver's HD20 hot swapping dream probably can't work. So far, the only way I found to run my diagnostic program was to configure the Mac to run my program after boot up, instead of running the Finder.
Good news: I've implemented the disk daisy-chaining mechanism described in the HD20 doc, and it seems to work. With an emulated 400K drive second in the virtual drive chain, the Mac still sees the floppy and will boot from it. Then it sees *something* at the first position in the chain, and freaks out with the endless requests to initialize it.
Pretty good news: I wrote a test program to read random sectors from the HD20. Initially it was failing with error -64, drive not present. After the daisy-chaining changes to the Floppy Emu CPLD, now it fails with error -17, driver can't respond. Looking at the disassembly of the HD20 ROM routines, this is the error I'd expect to see if the drive doesn't respond with the correct handshake after the Mac tells it to reset. So as far as I can tell, the Mac at least thinks there's an HD20 present and is trying to talk to it, so that's good.