Classic Computer Magazine Archive ANTIC VOL. 5, NO. 1 / MAY 1986



The February 1986 issue of ST Resource published ST Crash Clues, a brief introduction to 68000 exceptions. In the next three months, David and Sandy Small will give us a much closer look at the same subject.--ST RESOURCE

The following is the first in a series of articles discussing 68000 (and 6502) interrupts and exceptions--in detail. Along the way, many important concepts underlying the ST's 68000 architecture will be discussed. This series is aimed primarily at the intermediate to expert programmer. But it has information of interest to nearly anyone-- namely, "What are those bombs doing on my screen?"

Because many ST Resource readers--as well as most newcomers to the 68000--are more familiar with the 6502 processor used in 8-bit Ataris, (as well as Apple IIs and Commodore 64s), we'll begin with the 6502 and use it as a base of knowledge to understand the 68000's interrupts and exceptions. In fact, some of the starting concepts of this topic are pretty much the same on both microchips.

Before we roll up our sleeves, I should mention that throughout these articles I've sprinkled something I call: . To some, the term "hacker" has negative connotations. It implies a WarGames sort of destructive mentality. To me, this is totally inaccurate. "Hacker" used to be a very proud term signifying: 1. Freedom of information exchange and 2. Freedom of creativity. We knew what the term really meant long before the national press picked it up as an instant buzzword for the relatively few who abuse computing. (See Hackers Forever in the September, 1985 Antic for more on this. -ST RESOURCE)

I write articles like these because I believe in freedom of information exchange. Much of this information was dearly won, but with it you can create much more easily (the second ethic) and not have to cover the same ground. I always found that when I give information away for free, it has a way of returning manyfold via the informal and incredibly effective hacker's network.

So if the Hacker's Ethic appeals to you, take the Information here and use it to create something! And if you're in the mood, let me know what you created. One good way: my CompuServe ID is 76606,666. And in ANTIC ONLINE, and the SIG * Atari developer and 16-bit sections on CompuServe, there are a great information archanges filled with hackers willing to share information, program code and the like.


What's an interrupt? It's a request for the CPU (central processor unit) to suspend whatever it is doing, and go do something else. When the CPU is finished handling the interrupt, the processor goes back to what it was doing in the first place.

Some fast definitions:

Interrupts are serviced (handled) by an "interrupt service routine." This routine is a specialized piece of code that deals with the interrupt and then exits back to the "main routine"--which is the code that the CPU was executing when it was interrupted.

Why interrupts at all? Because they are quite handy. An analogy will illustrate this: Consider the problem of answering your front door when someone shows up. A good example of an interrupt in real life is a doorbell. When the doorbell rings, you drop whatever you are doing and go answer it.

But if you have no doorbell, your alternative is to look out the front door every 30 seconds or so and see if someone is there. Most of the time someone is not there (at least in my neighborhood) and you end up wasting a lot of time. Computer people call this "polling".

So having a doorbell to interrupt you is much more effrcient. You only spend time answering the door when someone is there.

Computers are the same way. If the computer has a great deal of time to waste, it can poll (look out the door) for things going on, without doing any harm. But if the computer is busy (which the ST and 8-bit machines definitely are) it hasn't got time to waste. Interrupts are the answer here.

What does an Interrupt do, exactly? There are some common aspects to all interrupts:

1. Something happens that causes an interrupt. There is now an "interrupt pending." The CPU is notified that it needs to interrupt. It takes the location where it is currently executing at the program counter (PC) and saves it--usually on the stack. It also generally saves the current flags.

2. The CPU begins executing an interrupt service routine, which it finds in a specifically defined place.

3. The CPU does whatever the interrupt needs it to do. For instance, in a modem program it might receive a character that was just input and store it away for later processing.

4. The CPU clears the source of the interrupt, so there is no more interrupt pending. In other words, the current cause of this interrupt is satisfied and the CPU won't interrupt again because of it. In a modem program, this would prevent us fetching the same character multiple times.

5. The CPU restores its program counter and the flags from the stack, and thus begins executing the main routine where it left off.

All of the above is common to both the 6502 and 68000 processors. However, the low-level details are not the same between the two processors. I want to begin with a generalized overview to keep things in perspective. Since most readers approaching the 68000 for the first time are acquainted with the 6502, let's talk about that processor first.

There has already been a lot of information printed on the 6502 interrupt scheme. Since the main intent of this series is to educate about the 68000, I'll avoid the intricacies of the 6502 not also applicable to the 68000. The remainder of this first article in the series will concentrate on the features in the 6502 which are similar to the 68000.


In the Atari 8-bit machines, there are two types of interrupts. One is "maskable", the other "non-maskable". These terms define whether or not you can shut off that particalar interrupt. For instance, if I'm executing a piece of CPU code that absolutely must not be interrupted, I can "mask off" a maskable interrupt. Think of masking tape--keeping paint from where you don't want it--and you'll have the idea.

A maskable interrupt is often called an IRQ, which stands for "Interrupt Request".

Non Maskable Interrupts (NMI) are a different breed. They happen whether you want them or not. They are reserved for things that absolutely must interrupt you-- regardless of the consequences to your program. In the computer world, they are like being pulled over by a traffic cop. Note the lack of the word "request" in NMI. It's not a request, it's an order!

On the 8-bit Atari, Maskable Interrupts are:

- Serial Bus stuff . .talking with external devices (disk drives, modems, and so on).
- POKEY timers (generally sound generation).
- Keyboard...someone pressed a key.
- [BREAK] key.

As you can see, these are all high priority sorts of things (sound, for instance, just can't wait). But also they are things that a program might want to shut off, such as a program that doesn't want sound.

As I mentioned before, you can choose to shut off these interrupts. One way is with the 6502 SEI instruction, which turns them all off, regardless. (6502 CLI turns them back on). If you need just some of them, then you must write to a hardware register, IRQEN (Interrupt Request Enable), specifying just which of these interrupts you want to work and which you don't.

The 6502 Non-Maskable Interrupts are:

- System Reset key (Wouldn't want to ignore that!)
- Vertical Blank: This is critical to the video display, and the video just can't wait.
- Display List Interrupt: Again, this is critical to the video display.

The first, System Reset, is something you would never want ignored. The second two are made non-maskable because the video must constantly receive information from the Atari to keep its image onscreen. Remember, the video must "refresh" (be told) all its display information each 1/60th of a second. So vertical blank and display list interrupts cannot be delayed.

(Hacker Note: The newer Atari 8-bit models make System Reset a true reset, a special sort of interrupt I'm not going to discuss here. The intent was to fix a bug in the old computers. If the 6502 executes some particular illegal opcodes, it will lock up so completely that even an NMI will be ignored. The only way to get it restarted is with System Reset. It represents a "get Out Of Jail Free" card. I mention this to help avoid confusion.)

(Hacker Note: There is a memory location that allows you to close down Non Maskable Interrupts if you have a Good Reason to do so. It's called NMIEN (Non Maskable Interrupt Enable) and it allows you to shut off the Vertical Blank and Display List Interrupts. (Normally, DLIs are off anyway). However, you'd better have a darn good reason to shut off the Vertical Blank; it is not something ordinarily done. A small bit of trivia is that you can't shut of the System Reset key. But it had better not be pressed when you power up the machine. Atari VCS (2600) game machine owners found that pressing the reset button while powering up had strange effects on many extra players, invulnerability to missiles, etc. Now you know why.)

How does the 6502 handle interrupts at the assembler and machine level? Three ways:

Non-Maskable Interrupt (NMI): Go to whereever $FFFA points to.

System Reset: Go to whereever $FFFC points to. In other words, if the 16-bit address at $FFFC is "$1234", jump to $1234 and start executing. The important thing here is that this is a POINTER, not actual machine code. We'll be seeing lots more of pointers in the 68000, so I am pointing this out early (Sorry about the pun.) Maskable Interrupt (IRQ): Go to whereever $FFFE points to.

At the hardware level, there are two pins to the 6502 which are triggered to cause an interrupt. As you may have guessed, one is IRQ (Maskable Interrupt), and the other - NMI (Non Maskable Interrupt). And, of course, there's always Reset.

Now all these locations, $FFFA-$FFFE, are in system ROM, so you're stuck with whatever the system designers make interrupts do. Fortunately, the Atari designers gave an unprecedented amount of freedom to the user, so the interrupts are "vectored," or directed, to go through a RAM location--which you can alter if you wish--to process the interrupts. So, if you choose, you can redirect the interrupts to your own service routines rather than using Atari's default service routines.

In computerspeak, we are "revectoring the interrupt service routine."

An example? Okay: The serial bus. When the disk drive starts sending data to the Atari, the Atari must be listening in a certain way. This is because the data is coming from the disk drive at a fixed rate. And if the 6502 takes its attention from the drive, it'll lose some of that data. So incoming disk "serial" data generates an interrupt which quickly sends the 6502 off to listen to the serial bus and gather in the data.

(Hacker Note: You can't use the disk drive while the 850 interface is running in its concurrent mode for just this reason. The Atari is listening so hard for incoming characters it can't listen to the drive.)

There have been several disk speed-up programs that make the serial bus run even faster (which is no trivial task). Some examples are Warp DOS from Happy Computing or SynchroMesh from Indus. In these, the data is coming very, very fast from the drive--too fast for the Atari routines. So these programs redirect the Atari interrupts to a specially coded, ultra-high-speed handler that can handle these fast data requests. (Hacker Term: Redirecting an interrupt is called "stealing the interrupt." The term is used so often that I thought I would define it for you.)

This pretty much finishes up our discussion of the 6502. Next month, I'll begin discussing the 68000--the reason most of you began reading this series in the first place. But now that we've laid the groundwork, we're ready to take off. The 68000, after all, is a close cousin of the 6502. It builds on the original--like a good sequel to a hit movie.

David and Sandy Small are professional programmers and longtime contributers to Antic Magazine. David's ST uses IBM Disk Files appeared in our November, 1985 issue. David and Sandy are co-authors of Guidebook for Winning Adventurers, which was reviewed in the September, 1985 Antic.