Interrupts made easy. (computer hardware interrupts) (Column)
by Mark Minasi
I've noticed that the subject of interrupts has come up a lot in the PC literature lately. If you're messing with Windows, networks, or printing (or any combination of the three), you've perhaps heard people talk about interrupt conflicts, IRQs, and the like. This month, I'll explain in plain English what interrupts are and what kinds of trouble they can cause.
There are actually two very different kinds of interrupts, software and hardware. In this article, I'll deal with hardware interrupts.
Interrupts solve a basic problem faced by any computer peripheral: how to get the CPU's attention. Let's take the example of a basic peripheral--the keyboard. The keyboard connects to the PC via a chip on the PC's motherboard, a keyboard controller. Whenever you press a key, the keyboard sends the keyboard controller a scan code, which the keyboard controller then offers to the CPU.
When I say, "offers," that's just what I mean. The keyboard controller has only enough storage space to hold a single keystroke. Therefore, the keyboard controller must get rid of each received keystroke quickly before the next one arrives. It gets rid of each keystroke by giving it to the CPU, which puts it in the system's keyboard buffer.
That's where the trouble appears. You see, the CPU is normally busy doing things; it's not simply at the beck and call of the keyboard controller. How, then, does the keyboard controller (a) get the CPU's attention and (b) do it quickly?
Interrupts Versus Polling
Peripherals have needed to get the attention of the C since the first computer. There are two approaches to making sure that the CPU gives that attention--interrupts and polling. in a polled system, the CPU periodically drops whatever it's doing and asks the keyboard controller, "Do you have a keystroke for me?" (Remember that drops-whatever-it's-doing part; it'll be important later.) The keyboard controller either says yes and hands over the keystroke or says no. in either case, the CPU then returns to what it was doing. After some time has passed, it again checks the keyboard controller.
Think of a CPU polling a keyboard as being somewhat similar to the situation you'd have if you had a phone without a bell. With such a phone, you'd have to periodically put the receiver to your ear and ask, "Is anyone trying to call me?" it would be a pain, but it would simplify the requirements of the telephone hardware; the phone company wouldn't have to design a ringer into the system.
With an interrupt-based system, on the other hand, the CPU must be designed to accept interrupts. That means that one or more of the wires extending from the CPU chip itself will accept an input signal from another circuit on the motherboard, a signal that says, "Come pay attention to me." The keyboard controller then is connected to one of those interrupt wires, and it places a signal on that wire when it has a keystroke the CPU must handle. The CPU senses the interrupt and puts its current work aside, signaling the keyboard controller that it's ready to accept that chip's keystroke. Let me continue my telephone analogy at this point. As you've no doubt surmised, the interrupt signal is like the telephone's bell in my phone analogy. You can work continuously at your desk without having to worry about whether anyone's trying to reach you or not.
Let's summarize what we know so far. A CPU communicates with a peripheral either through polling or interrupts. Polling requires less support hardware, but it requires that the CPU spend a lot of time checking with the polled peripherals to see if they have need of the CPU's attention.
Which Is Better?
It seems obvious. interrupt-based input/output handling is more than polling, in terms of the CPU's time. And aren't we always looking for faster performance from our PCs?
That's true, but polling has a place in the microcomputer world. For example, the Apple II polled its keyboard. And despite the fact that the parallel port has an interrupt line assigned to it, your PC polls the parallel port, in all probability.
Why? The story starts in 1981, with the first PCs. They were sold with optional serial and parallel ports, and the first parallel ports were made, of course, by IBM. The PC architecture that IBM settled on made heavy use of interrupts, and the parallel port was assigned its own interrupt line, interrupt line number 7 (IRQ7). Unfortunately, some of the parallel ports in the first batch had nonfunctional interrupts, the legend goes, and so IBM rewrote the original PC BIOS so that the PC sent data to the parallel port via polling, not interrupts. Once the initial PCs shipped with a BIOS that supported polling of the parallel ports, all software that followed it--until OS/2 and Windows, as you'll learn in a bit--polled the parallel port, ignoring the IRQ7 that was assigned to the parallel port.
Under a polled system, the PC sends a character to the printer and then says to the printer, "Did you print that character yet? How about now? How about now?" and so on until the printer finally says, "Yes, I printed that character." The PC then sends the printer the next character, starts polling to find out if the parallel port is finished with that character, and so on.
Under an interrupt-driven system, the PC would just send the printer a character and then go back to work on whatever it was doing. When the printer is ready for the next character, it taps the PC on the shoulder and says, "I'm ready for the next character."
The interrupt-driven system sounds more efficient--but is it really? Think about how DOS works--it's a single-tasking operating system. If the PC is in the process of printing, then that's all it's doing. In the last paragraph when I referred to its going back to work on whatever it was doing, I omitted the fact that there's nothing else to do, as most DOS programs are unable to multitask and DOS offers very little in the way of background printing support. So in the final analysis, it really doesn't matter much whether your printer port uses polling or interrupts.
I also neglected to mention a benefit of polling. A PC-to-printer cable doesn't need to have as many wires in it if the interface uses polling rather than interrupts. Some of the 25 wires that go into the standard PC-to-printer cable are only there to support interrupts, so they're unnecessary for most Dos-based systems. That's how some vendors have managed to cut prices on printer cables; they just leave out the superfluous wires.
The fact that the printer interrupt IRQ7 is largely unused is useful for another reason. Interrupts are scarce commodities, and if the parallel port won't use IRQ7, there are plenty of boards that can use it! Many companies have installed local area networks in the past four years, and many LAN interface boards require an interrupt. IRQ7 has served well in this function.
Windows and OS/2 Printing
So you've seen that many printer cable manufacturers save money by leaving a few unnecessary wires out and that stealing the parallel port's IRQ is the most forgivable of sins, as the computer isn't using it anyway, and it makes adding some nifty board like a LAN or a Sound Blaster possible. That was fine under single-tasking DOS. But what about OS/2 and Windows, which are multitasking operating systems? Well, um, there's a problem there.
It should be obvious that an interrupt-driven printer interface would be a real asset to any multitasking system. If one program was printing and another was doing calculations, then the operating system could dump a few bytes to the printer from the first program and then do a few calculations for the second program. When the printer signaled that it was ready, the CPU could give the printer a few more bytes, return to its calculations, and so on. It's like getting the benefits of a mainframe from your desktop PC.
You can probably see the problem by now. There are many PCs out there whose owners have given their IRQ7s away, so when Windows tries to print, nothing happens. Worse yet, when Windows tries to print, the network locks up (if the LAN board was on IRQ7), or the Sound Blaster starts emitting static. In the worst case, the system crashes.
Most PCs have two basic kinds of bus slots--8-bit bus slots and 16-bit bus slots. Let's consider the 8-bit slots, as they're the ones that have the tightest crunch for interrupts. The 8-bit slots support six interrupts numbered 2 through 7. Interrupts 0 and 1 aren't available in bus slots because they're already taken up by the system's timer, which gets interrupt 0, and the keyboard controller, which gets interrupt 1. Interrupt 2 is free on XT-type systems, but it's required on 286 and higher systems to serve as a gateway to the extra interrupts provided by a 16-bit slot. Interrupt 3 is the interrupt for either COM2 or COM4. Since both serial ports are assigned to the same interrupt, they'll only work reliably it you have one or the other. Interrupt 4 is for either COM1 or COM3. Interrupt 5 is usually free on 286 and higher systems, as it's reserved for LPT2 and most of us don't have a second parallel port. Interrupt 6 is used by the floppy drive, and interrupt 7 by LPT1, the first parallel port, as I've mentioned earlier. Use those assignments as a guideline when assigning interrupts to new circuit boards.
What if you have one of those printer cables that don't contain the wires for interrupt support? You'll see trouble there, as well. That inexpensive printer cable that has served you for years may be the root cause of any Windows printing problems that you may be experiencing.
So if your printer prints under DOS but not under Windows, then one thing you should investigate is whether or not your parallel port has a free and clear title to IRQ7. Another thing to try is another printer cable; borrow one from a Windows workstation that's printing OK and put it on your system. If you can print with this cable, then you're OK on the interrupts, and you just need a better cable.