Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!ac
From: ac@utgpu.UUCP
Newsgroups: comp.sys.m6809
Subject: CHD problem
Message-ID: <1987Apr6.165809.16100@gpu.utcs.toronto.edu>
Date: Mon, 6-Apr-87 15:58:09 EST
Article-I.D.: gpu.1987Apr6.165809.16100
Posted: Mon Apr  6 15:58:09 1987
Date-Received: Mon, 6-Apr-87 23:47:29 EST
Organization: University of Toronto Computing Services
Lines: 20
Checksum: 29441

I believe I understand now why a write to a write-protected disk will crash
the system if the delay code is incorrect.  The delay is required by the
1793 controller whenever a command is stored in its command register.  Failure
to delay will cause strange things (not sure what, they didn't say).  But
why does to long a delay cause problems and only for the write to a write
protected disk.  Well the write to a write protected disk causes an almost
immediate failure return in the form of an interrupt.  The code which
gets control from this NMI assumes it understands the state of the stack.
If the delay code is still executing at the time this interrupt occurs the
stack will still have stuff left on it from the delay code (remember the
lbsr to lbsr to lbsr to rts code).  It seems the whole code would have
been much more robusts if they had used a simple loop instead of the bizarre
lbsr code.


-- 

Name:     Mark Acfield (University of Toronto Computing Services)
Path:     ihnp4!utgpu!ac   
Alias:    ac@utoronto.bitnet