<msg> @196 ->Email
marku@magnet.at
Password: jonathan
NMI Claim and Release Procedure

Something interesting to document...

The BAUG and the NAUG both state that on receipt of service call &0C - NMI
Claim, the NMI owner should return with it's ROM number in the Y register;
and when the claimant releases it with service call &0B it should put that
ROM number in the Y register and all the ROMs should check it against it's
own before reasserting control of the NMI.  This implies code like this:

.Service0B: CPY &F4 :\ Is it coming back to me?
            BNE Serv0B_NotMe
            \ Copy my routines back to NMI area
            ..etc

.Service0C: \ Disable my NMIs, etc.
            LDY &F4 :\ Return my ROM number in Y
            LDA #0  :\ Claim the call
            RTS

In the other code:

.I_Use_NMI: LDA #143   :\ Service call
            LDX #&0C   :\ Claim NMI space
            LDY #&FF   :\ As instructed
            JSR OSBYTE
            STY LastNMI_ROM  :\ Save last NMI user's ROM number
            \ do my NMI stuff
            LDA #143   :\ Service call
            LDX #&0B   :\ Release NMI space
            LDY LastNMI_ROM  :\ Last NMI user's ROM number
            JSR OSBYTE

And I've seen addendums and corrections saying 'yes, it is ROM number, not
filing system number'.

However, in real life, by examining real code what actually happens is
this: 

The only system that owns the NMIs full time is the Econet system.

In NFS:
On receipt of Service0C_NMI_Claim, NFS disables it's NMIs and returns '5'
- ie, the NetFS filing system number!

On receipt of Service0B_NMI_Release, NFS doesn't check anything, just goes
ahead and reclaims the NMI.

In ANFS:
On receipt of Service0C_NMI_Claim, ANFS disables it's NMIs and returns '5'

On receipt of Service0B_NMI_Release, ANFS checks if it it #&05, and if so,
reclaims the NMI.

The BAUG, NAUG, Dabhand Master OS and Advanced Sideways RAM and ROM
Programmer's Guide all say 'ROMnumber'

The Electron AUG says 'filing system number'

Hmmm... interesting...

As the Network hardware is the only item that needs to hold the NMIs in
the background continously, this is not much of a problem.  Other systems
just claim the NMIs for the few milliseconds that they actually need them. 

Also, thinking about it, with the specific example of DNFS, two NMI owners
live in one ROM, so if the call did use ROM number, there would be scope
for ambiguity.  Using filing-system number removes this ambiguity.

But, if a non-filing system wanted to own the NMI, what value would it
use?  Not likely, but possible.

Hmmm... I wonder how the Arc works it when both the Ethernet card and the
Econet card want to be able to respond to NMIs (called FIQs) in the
background continously...?  I think... the Arc FIQs have a hardware
register that says where the FIQ came from, so the first thing the FIQ
routine can do is check that register.  Makes the Fast Interrupt reQuest
slighly less Fast!

-- 
J.G.Harston (JGH BBC PD Library) 70 Camm Street, Walkley, SHEFFIELD S6 3TR
BBC+Master / Z80+6502 / CoPro+Tubes / Econet+SJ / Devolution / Transport /
Planning / Highways    http://homepages.nildram.co.uk/~amilton/walkley.htm
jgh@arcade.demon.co.uk   (( Anti-UCE address added by Arcade, not by me ))