ingoldsby@calgary.UUCP (Terry Ingoldsby) (04/22/86)
I recently attempted to install the `Newdisk' device driver that
was posted to the net by Dave Lewis. I have had some problems and
was wondering if anyone else has experienced similar difficulties.
Assembling Newdisk and installing it using OS9Gen went fine. The
driver works just fine until an error condition occurs. It doesn't seem
to matter what the error is; the easiest error to fake is attempting to
write to a write protected disk. Anyway, when an error occurs the driver
takes up transcendental meditation and I have to reboot the system. My
attempts to debug it have convinced me that when an error occurs, execution
does indeed vector to the error handler contained in the driver. What
happens next is not at all clear but I almost think that another NMI is
occurring a `short' time later.
Debugging this routine is not a trivial task due to its interrupt
driven nature, and I tip my hat to Dave Lewis for writing the beast.
Its really very tight code and I'd like to get it working. I should
mention that I have the old gray Coco and the old disk controller. If
anyone else has had these problems I'd appreciate hearing from them. If
no one else has had these problems then perhaps I've got a bad copy of
the driver and someone would be kind enough to mail me another copy.
One final question: Is it permissable to do system calls within
a device driver?
Terry Ingoldsby
Disclaimer: No one around here even cares what I say.neals@tekigm (04/29/86)
In article <94@vaxb.calgary.UUCP>, ingoldsby@calgary.UUCP (Terry Ingoldsby) writes: . . . > One final question: Is it permissable to do system calls within > a device driver? > I don't know if it's legal or not, but when I was debugging a ramdisk driver, I put in trace print character calls so I could see which sectors were being read/written when it bombed. I kind of wonder if the default stdout path was the console or not, but it worked ok. You couldn't redirect the output though :-( BTW, I noticed that when you do a "CHD", the last sector operation was a WRITE to the first sector of the directory that you changed to. Does anyone know why? Is this related to the re-seeks that occur when you CHD to a directory of a write-protected floppy? I just noticed it when I was playing around with my RS V2 OS9 that I finally got to try a couple days ago. The guy at the Shack told me that the CONFIG utility won't include PIPE, PIPER and PIPEMAN in the bootfile when you select it. After trying CONFIG three times and running into some user-hostile fatal error each time I didn't even check. Be warned though, he is very familiar with the COCO and OS9 and I think he knows what he's talking about. This was not at an RS "What's OS9?" Confuser Center, obviously :-) Neal Sedell *!tektronix!tekigm!neals
dml@loral.UUCP (Dave Lewis) (05/02/86)
In article <94@vaxb.calgary.UUCP> ingoldsby@calgary.UUCP (Terry Ingoldsby) writes: > I recently attempted to install the `Newdisk' device driver that >was posted to the net by Dave Lewis. I have had some problems and >was wondering if anyone else has experienced similar difficulties. > Assembling Newdisk and installing it using OS9Gen went fine. The >driver works just fine until an error condition occurs. It doesn't seem >to matter what the error is; the easiest error to fake is attempting to >write to a write protected disk. Anyway, when an error occurs the driver >takes up transcendental meditation and I have to reboot the system. My > Debugging this routine is not a trivial task due to its interrupt >driven nature, and I tip my hat to Dave Lewis for writing the beast. Thanks. > One final question: Is it permissable to do system calls within >a device driver? > Terry Ingoldsby Yes! In fact, some system calls can only be made by system type modules, which includes device drivers. Watch out for interrupts though. I've never tried to write to a protected disk, but any attempted access to an unformatted disk also causes the system to do a sleep(forever). If there is a second NMI when none is expected it will indeed bomb the NewDisk driver because the NMI is used as sort of an asynchronous RTS. The NMI service routine first dumps all the registers off the stack, then RTS's to the address under them. I'm not sure how to correct this as the disk controller chip is responsible for such things. It says in the data book that if the chip detects an error condition, it will abort the command and issue an NMI. I thought it maybe wasn't NMI-ing at all but doing it twice would cause about the same effect. I have seen it recover from a sector write/verify error. I could hear it going through the three home/reseek cycles and everything, then it reported ERROR #nnn. A look at the allocation map showed that sector marked, and Dcheck said it wasn't in the file structure. (this was during a backup of an 80-track double sided disk) You too have discovered that this thing is a b??ch to debug. Debug does not handle cases where: 1. An NMI occurs while the test program is running 2. The breakpoint is in a subroutine relative to the run address (the stack pointer is moved between `G' and breakpoint) In conclusion, I can only protest that I never said it was perfect, just improved. If these bugs bother you so much that you have to fix them, let me know. I accumulated a lot of info on the disk controller and such which you would find useful in your quest. Post the fix, mail (E or S) it to me or otherwise share it. Don't let it keep you up past 2AM. Did you net.micro.6809'ers know you can't boot from a write protected disk, under Version 2.00 anyway? Seems it won't chd to a directory it can't write to or something. ------------------------------- Dave Lewis Loral Instrumentation San Diego sdcsvax--\ gould9 --\ ihnp4 ---->-->!sdcc3 ---->--->!loral!dml (uucp) sdcrdcf -/ crash ---/ Television -- (n) A set of tireless tubes I've watched the thing twice this year: the day the space shuttle exploded and the day we bombed Libya. -------------------------------
caveh@garfield.UUCP (05/06/86)
In article <1112@loral.UUCP> dml@loral.UUCP (Dave Lewis) writes: > Did you net.micro.6809'ers know you can't boot from a write protected >disk, under Version 2.00 anyway? Seems it won't chd to a directory it can't >write to or something. What is this about write protected disks?! If RS has managed to do this, it is a SEVERE blow to the phylosopy behind os9! Whatever happened to sweet ol' *ROMable* os9?! I don't have os9 2.0.0 yet due to a severe lack of interest on behalf of the local Radio Slack store, however, the problem you describe sounds like a problem that's been with us from the days of os9 1.0.0! The problem, if i recall correctly, was that the shell gave a silly mask to i$chdir. It specified that it wanted write permission to the directory, thus not allowing a chdir to a directory for which you didn't have write permission. To fix this problem, either disassemble the shell, and change the permission the shell wants when it does the i$chdir, or use "debug" to find the i$chdir call in the shell and patch a 'lda #$07' (or whatever the mask is) just preceding the i$chdir to not include the the write bit. If anyone is interested, I could find the location(s) and report back in a few days with a patch. Caveh Jalali caveh@garfield.UUCP