Date   : Tue, 24 Mar 1992 17:00:52 GMT
From   : dog.ee.lbl.gov!network.ucsd.edu!sdd.hp.com!think.com!mips!news.cs.indiana.edu!news.nd.edu!mentor.cc.purdue.edu!noose.ecn.purdue.edu!ea.ecn.purdue.edu!wieland@ucbvax.Berkeley.EDU (Jeffrey J Wieland)
Subject: Re: interrupts, arunz, problems

In article <9203231428.AA27601@LL.MIT.EDU> sage@LL.MIT.EDU (Jay Sage) writes:
>
>   I would not expect ARUNZ to be doing anything with interrupts, but I have
>not looked at the source code yet to check.  Are you perchance now using the
>type-4 version of the program?  All type-4 programs have DI and EI
>instructions as part of the address relocation code in the type-4 loader,
>which occupies the second record of the COM file (bytes 80H to FFH).  I
>believe that this code cannot work with interrupts enabled because of the way
>it uses the stack pointer.
>
>   I should point out that versions 3.3 and later of ZCPR also have parts of
>the code that turn off interrupts and then reenable them.  This occurs in the
>
>-- Jay Sage (author of ARUNZ and ZCPR33 and later)

Shouldn't this code be examining the current interrupt state before it
goes changing them?  I mean, if interrupts aren't enabled, it should
detect this and not enable them when it gets through the critical
section of the code.

Bridger Mitchell had some examples for doing this in The Computer
Journal, Vols. 36 & 37.  Be sure to see both articles, because the
second has a work-around for a Z80 that the code in the first article.
Specifically, if an interrupt occurs while your code is checking the
interrupt status, the Z80 will wrongly report that interrupts are 
disabled.

On the other hand, the code to do this might not fit, either in the
Type 4 header or in the command processor.
--
                           Jeff Wieland
                       wieland@ecn.purdue.edu