Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!ittatc!dcdwest!sdcsvax!sdcc6!loral!dml
From: dml@loral.UUCP (Dave Lewis)
Newsgroups: net.micro.6809
Subject: Re: Newdisk bugs?
Message-ID: <1112@loral.UUCP>
Date: Fri, 2-May-86 15:52:57 EDT
Article-I.D.: loral.1112
Posted: Fri May  2 15:52:57 1986
Date-Received: Sun, 4-May-86 23:38:42 EDT
References: <94@vaxb.calgary.UUCP>
Reply-To: dml@loral.UUCP (Dave Lewis)
Distribution: net.micro.6809
Organization: Loral Instrumentation, San Diego
Lines: 67
Keywords: Device Driver
Summary: Probably fixable, but I won't

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.
-------------------------------