General Category > LisaList2
Good grief, why is it so hard to eject a disk?
rayarachelian:
--- Quote from: stepleton on March 27, 2021, 12:42:43 pm ---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.
--- End quote ---
Congrats. :)
--- Quote from: stepleton on March 27, 2021, 12:42:43 pm ---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.
--- End quote ---
Wow! great to know!
--- Quote from: stepleton on March 27, 2021, 12:42:43 pm ---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.
--- End quote ---
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.
--- Quote from: stepleton on March 27, 2021, 12:42:43 pm ---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.
--- End quote ---
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.
stepleton:
The Lisa never gives up without a fight. Let's say you want to eject both drives on a Lisa 1, one after the other. If you have disks in both drives, then my code will eject them both. If you have a disk in the top drive only, then my code will eject that one without troubles. If you only have a disk in the bottom drive, then after failing on the top drive saying "no disk there" (expected), it fails on the bottom drive too saying "no disk there" --- and of course the disk stays put.
I'm able to key in the same commands my code uses to the disk controller in Service Mode, and just to make life complicated, that works just fine. That said, Service Mode has different interrupt handling to the no-interrupts polling that my code uses.
I'm not sure that I/O ROM 40 is the most bulletproof software ever made. Oh well, nothing to do but keep plugging away...
rayarachelian:
--- Quote from: stepleton on March 27, 2021, 08:53:11 pm --- If you only have a disk in the bottom drive, then after failing on the top drive saying "no disk there" (expected), it fails on the bottom drive too saying "no disk there" --- and of course the disk stays put.
--- End quote ---
Wait, so in this case were you asking for both to be ejected? It sort of makes sense that it maybe failed if the top one failed, but yeah, ideally it should still eject the bottom one. Or are you asking it to eject only the bottom one and it fails anyway just because the top one is empty? That would be most uncool, and raises questions about how LOS deals with that.
Speaking of I/O 40, the other difference is that it needs to be able to signal to the 68000 side that the user pressed one of the two eject request buttons (in addition to the disk insert signals). How does the "D" ROM or whatever handle that? Does it poll or does it answer the FDIR IRQ?
--- Quote from: stepleton on March 27, 2021, 08:53:11 pm ---I'm able to key in the same commands my code uses to the disk controller in Service Mode, and just to make life complicated, that works just fine. That said, Service Mode has different interrupt handling to the no-interrupts polling that my code uses.
--- End quote ---
Hmmm, that may be a clue perhaps - might help to look at the source code for the Service Mode's ISR - especially in regards to FDIR handling
So about, Service Mode, are you keying in 68000 code for your routine, or are you entering commands directly to the shared floppy RAM block? If the latter, then perhaps timing has something to do with it.
stepleton:
Lol, this one turned out to be a pretty silly mistake on my part: I was checking the same old error value twice. Sorry about that...
I've been trying to avoid copying the ROM in this project, and my great success in doing that means that I get to relearn old lessons all over again. I can't know that the ROM authors have been as hapless as I am, but I tell myself that they must have made at least a few of the same mistakes along the way.
Anyway, my implementation is different to the ROM style --- maybe not better, but different! You'll remember the first post in this thread where I list a step-by-step process for ejecting a disk... Basically, I represent most of these steps (the ones where you change bits of the shared memory and wait for something to happen) in a compact binary language, and then I have an interpreter that interprets this language. On the one hand, it lets you reuse code for a few floppy operations. On the other hand, it doesn't make debugging a walk in the park, at least not when the interpreter had its own bugs.
But I think that's all behind me now, and I'm just now writing docs for the 1.0 release of the Cameo/Aphid Selector program.
rayarachelian:
--- Quote from: stepleton on March 28, 2021, 01:42:35 pm ---I've been trying to avoid copying the ROM in this project, and my great success in doing that means that I get to relearn old lessons all over again. I can't know that the ROM authors have been as hapless as I am, but I tell myself that they must have made at least a few of the same mistakes along the way.
--- End quote ---
Eh, I have a different set of goals, and free time is limited in my case, so I'd rather skip the extra experiments when I can help it. To each their own. :)
--- Quote from: stepleton on March 28, 2021, 01:42:35 pm ---I have an interpreter that interprets this language. On the one hand, it lets you reuse code for a few floppy operations. On the other hand, it doesn't make debugging a walk in the park, at least not when the interpreter had its own bugs.
--- End quote ---
Ooh! That sounds interesting, look forward to that! I was thinking as a way way on the back burner project, perhaps porting micro-python to the Lisa might be a useful way in the future thing - esp if it could interface with the UI/Clascal stuff.
The Aphid/Cameo stuff is really promising too.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version