Re: What is NMI under Emulator?

[dempson@actrix.gen.nz (David Empson)]

Bryan Parkoff <BParkoff@satx.rr.com> wrote:

> What is NMI under Emulator?
> 
>     I have noticed that several emulator projects include hardware
> manipulation such as IRQ and NMI.  I know that IRQ is used to interrupt 6502
> CPU such as keyboard and I/O controller cards.  What about NMI?  Please
> advise.

IRQ means "Interrupt Request".  It refers to a hardware input to the
6502, which is activated when a peripheral wants to interrupt the normal
flow of execution in order to be serviced.

As implied by the "request" in the name, the CPU doens't necessarily
have react to the IRQ signal.  Software can control whether or not the
interrupt is handled by manipulating the "interrupt mask" flag in the
status register, e.g. using the SEI and CLI instructions.  For this
reason, IRQ is also known as a "maskable interrupt".

NMI means "Non Maskable Interrupt".  It is an additional interrupt input
to the 6502, but one which the software has no control over - there is
no way to prevent the CPU from reacting to NMI, and it will always cause
an interrupt.

IRQ (if accepted) and NMI cause the CPU to save its current execution
location and the processor flags on the stack, then transfer control to
a predetermined location, which is pointed to by an interrupt vector
(locations $FFFE/$FFFF for IRQ, $FFFA/$FFFB for NMI).  Since there are
separate vectors for the two interrupt types, they can point to
different handers, which allow the handlers to be certain of the type of
interrupt which occurred.

If there are multiple peripherals which are capable of generating IRQ or
NMI, the interrupt handler (or handlers) have to "poll" each interrupt
source to check whether it was the one which generated the interrupt.
(More advanced processors provide an automatic vectoring scheme which
avoids most of this polling overhead by activating the appropriate
interrupt handler directly.)

In the original 8-bit Apple II models through to the IIe, the IRQ and
NMI signal sare provided to all of the slots, and there is nothing on
the motherboard which can generate an IRQ or NMI.

In addition, the original Apple II through to the unenhanced IIe only
has a rudimentary IRQ handler in ROM, which does a minimal amount of
work and then transfers control to a routine pointed to by memory
locations $03FE and $03FF (in RAM).  There is no NMI handler in ROM -
the NMI vector points directly to $03FB, which is supposed to be set up
to contain a JMP instruction to the actual NMI handler.

In the Apple IIc and IIgs, there are several built-in peripherals which
are capable of generating IRQ, but none which generate NMI.  The IIc
also has an external IRQ input via the disk port, and cards in the I/O
slots in the IIgs can generate IRQ and NMI (as with the IIe).  The IIc
and IIgs memory expansion slot doesn't provide access to IRQ or NMI.  If
I remember correctly, the same applies to the auxiliary slot in the IIe.

The IIc's main interrupt sources are the mouse hardware (mouse movement
and button interrupts, plus vertical retrace interrupts), keyboard and
serial ports.

The IIgs has a large number of built-in interrupt sources, including the
Apple Desktop Bus (keyboard, mouse and general ADB operations, including
the Ctrl-Apple-Esc combination which invokes the Classic Desk Accessory
menu), serial ports, some internal timer sources (vertical retrace,
quarter second and one second), Ensoniq sound chip, and scan line
interrupts for the Super Hi-res Graphics screen.  I'm sure there are
more which don't occur to me off the top of my head.

The IIc and IIgs have a more advanced IRQ handler in ROM, which deals
with most of the built-in interrupt sources, and provides support for
external interrupt handlers which manage IRQs from peripheral cards.
They deal with issues like preserving the state of various soft-switches
and setting up a standard environment in which the interrupt handler is
to run, which makes it easier to write interrupt handlers.

The enhanced IIe has a similar IRQ handler, but its only purpose is to
set up the standard environment, as there are no built-in interrupt
sources for it to handle.

The NMI handler in the IIc and enhanced IIe is identical to the original
Apple II.  The IIgs may have a slightly more advanced one, but in all
cases, NMI is difficult to use safely (see below).

Typical application software such as a word processor doesn't care about
interrupts - if they are used at all, they will be dealt with by the
operating system and drivers.  Communications software may need to deal
directly with interrupts from the serial interface.

Maskable interrupts must be disabled during certain time-critical
operations, notably floppy disk I/O in the Apple II, which uses
precisely timed instructions and software loops to transfer data at the
correct rate.  An unplanned interrupt occurring in the middle of a disk
will corrupt the data being written, potentially destroying the contents
of the entire track.  An interrupt in the middle of a disk read will
cause a read error.

Since there is no way to prevent an NMI from being handled, they cannot
be used safely on an Apple II unless they are triggered only at times
when it is known that there are no time-critical operations (such as
disk I/O) taking place.  For this reason, they are almost exclusively
used for devices like "crack" cards or debugging cards, with the NMI
generated by a user-triggered button press (or something like a
recognised memory access).

In the case of a crack card, pressing the button causes an NMI, which is
guaranteed to interrupt the CPU.  The crack card then makes use of the
"inhibit" feature to override the ROM area, replacing the standard NMI
handling code with code supplied by the card itself.  This code takes a
snapshot of the memory contents (storing it in RAM on the card), then a
reboot into the support software allows the memory image to be written
to disk.  Subsequently, the memory image can be loaded into memory,
restoring the cracked softare to its state at the point when the NMI
occurred.  (The crack card is only needed for the capture step, not the
restore step.)

-- 
David Empson
dempson@actrix.gen.nz