Finally worked it out. What an almighty pain that was. I'm not sure I've even got it all yet, but I've managed to sidestep several of the booby traps. For all the hardship, at least I made my code easier to troubleshoot in the meantime.
Congrats.
1. The documentation for the DRIVE ENABLE command (page 195 in the 1983 manual) says that the byte at $FCC003 needs to be a mask saying which drive you want to enable, and that bits 0-2,4-6 of that byte are "don't care". LIES. Those bits will be 0 or your code won't work.
Wow! great to know!
3. Don't issue the disk eject command and then just quit to the ROM: the Lisa will crash. You need to wait for and clear the interrupt that the ejection procedure will raise, since (I guess) the ROM won't be ready to handle it.
This makes sense because it will issue an FDIR IRQ. The Boot ROM, much like the uniplus standalone loader is a single process/single user program that tries to avoid handling interrupts as much as possible, however the hardware is designed for a multi-tasking, interrupt driven system. Which means that these programs should set the IRQ mask to 7 and poll I/O until things are settled. Depending on how you choose to structure your Lisa library this may be an issue (or not.).
For a general purpose OS, you won't want to freeze all operations while the floppy drive (or profile) is busy doing stuff and do polling I/O to wait. So specific interrupt service routines have to be written to handle this stuff properly. But to do that, you have to keep track of all things in flight and build a queuing system for requests for various things, like read this block, eject that floppy, write this block, as well as handle incoming stuff. Not easy.
And things can quickly fall out of sync when dealing with the various I/O state machines, such as profile/floppy/cops/etc.
In a single tasking system with mask 7 on for all I/O and polling everything freezes all the time and everything gets sluggish. But it's perfectly fine for a single tasking/polling pre-os loader/boot ROM environment to set the mask to 7 while an operation happens all the way through, but yes, you do have to deal with whatever the other processor expects and the docs don't always tell you exactly. That's why it's useful to see a good example, such as from the Boot ROM source. It may not say in the comments, but likely they ran into the same walls you're hitting now.
Combinations of getting these things wrong can either crash the machine or lead to nothing happening at all. Either way, unless you get it right, the disk will just sit there in the drive. Since your debugging interventions (e.g. putting in ILLEGAL instructions to verify that execution has reached a certain point, or just plain-old bugs in your temporary code) can also crash the machine, it's hard to tell what's going on.
Yup, very true. The Lisa's a Harsh Mistress to paraphrase Heinlein.
I've recently borked the entire profile state machine while trying to get uniplus working, and while I know exactly where the bug is, I haven't yet spotted why it happens - which is a really annoying place to be when trying to fix it. A small error somewhere causes really huge effects down the line.
