Article 185932 of comp.sys.apple2: Path: news1.icaen!news.physics.uiowa.edu!hammer.uoregon.edu!elk.ncren.net!logbridge.uoregon.edu!sfo2-feed1.news.digex.net!intermedia!news-out.spamkiller.net!propagator-la!news-in-la.newsfeeds.com!news-in.superfeed.net!newsfeed01.tsnz.net!news02.tsnz.net!news.actrix.gen.nz!dempson Newsgroups: comp.sys.apple2 Subject: Re: What is NMI under Emulator? From: dempson@actrix.gen.nz (David Empson) Message-ID: <1f8jpxu.iediewc7zcgkN%dempson@actrix.gen.nz> References: Organization: Empsoft User-Agent: MacSOUP/2.4.2 X-Original-NNTP-Posting-Host: 202.154.130.23 Lines: 119 Date: Tue, 5 Mar 2002 00:58:04 +1300 NNTP-Posting-Host: 203.96.16.33 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1015243032 203.96.16.33 (Tue, 05 Mar 2002 00:57:12 NZDT) NNTP-Posting-Date: Tue, 05 Mar 2002 00:57:12 NZDT Xref: news1.icaen comp.sys.apple2:185932 Bryan Parkoff 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