Interrupts made easy. (hardware interrupts; installation of local area network cards)(part 3) (Column)
by Mark Minasi

For the past two months, we've looked into interrupts on the PC, a topic that may not be the most fascinating thing in the world but is surely an important topic.

Recently, I got a chance to actually use this information in a real-world setting. Despite the fact that I've been teaching PC installation and repair seminars for seven years, I found the simple installation of nine Ethernet cards into a variety of computers to be a real education.

Before I provide you with the details, let me give you a little background on why I was installing the boards. As you may know from my other columns, I run a small seminar company that employs four administrative and marketing people, as well as seven full-time instructors. We have three locations--two commercial townhouses and my office, which is in my home. (Hey, when you're the boss, you get to say where your office is, right? Besides, they get more done when I'm not around, and vice versa.)

I'm telling you this so you'll understand that for us, a LAN has been an item of marginal value. We've had LANs running in our test-bed area for a while, so we've become familiar with the seamy underside of NetWare 3.11 and the intricacies of making Windows work with LAN Manager.

For a long time, LANs didn't make sense for us, but recently, they've come to make a lot more sense. Part of that is due to Windows for Workgroups, our latest LAN platform. It's annoying in some ways and great in other ways--but then, isn't that always the case with LANs? We had a bunch of Ethernet cards around the office, some of which actually had documentation. So I sallied forth to set up a network. What made the whole process even more interesting was that no two LAN boards were the same. We have something of a mongrel network that we affectionately call MuttNet.

The first LAN card I installed on our network was an Ethernet board that used everything we've discussed in the two previous columns: an I/O address range, a DMA channel, an IRQ level, and some shared RAM. I left the I/O address at 300 hex so it wouldn't conflict with the computer I was installing the board into. The IRQ I chose was IRQ5, avoiding the more commonly used IRQ2. The reason why is worth exploring.

IRQ2 gets handled in one of three ways by PC systems. On some systems, you can use IRQ2 with no trouble. On others, IRQ2 is connected to IRQ9 as a kind of doorway to IRQ8 through IRQ15. In that event, you may have to utilize IRQ2 but tell your software that you're using IRQ9. (I know it sounds odd, but try it.) On some systems, IRQ2 just plain won't work no matter what you do.

I avoid IRQ2 because even though it can be used in some systems, the fact that it cascades to IRQ8 through IRQ15 makes me a bit nervous; in the past, using IRQ2 has caused conflicts with Windows. I set the DMA to channel 1 and put the shared RAM between CC000 and CFFFF, as I knew that it wouldn't conflict with the hard disk controller ROM between C8000 and CBFFF.

When I plugged the board in, however, it didn't work. The next board I tried didn't work either. It was the same for the next board and the next. A little fiddling around made me realize that the DOS memory manager I was using was placing its memory at the same addresses as the shared memory on my LAN board, which in turn was clobbering the LAN board. (Actually, that's not completely true; the DOS memory manager placed an upper memory block up there because I told it to. You may recall, if you're one of the people who read this column regularly, that I insist on setting up my memory manager so that my includes and excludes are mutually exclusive and collectively exhaustive--that's professor talk for "Map the memory from stem to stern, from 640K through 1024K." As I'd done that, my memory manager took it on faith that it could plaster memory across the RAM buffer on the LAN board.)

To remedy the situation, I told the memory manager to exclude the range of addresses from CC000 to CFFFF (check the earlier columns on memory management for details on excluding and including), and all was well after that. One board down, a bunch more to go.

I went to the second PC and began installing another LAN board. I set the second board in the same way, but it refused to work. A quick check of my notes reminded me that a sound board was using IRQ5, causing a conflict. In case you've never read one of my sermons about keeping notes, here's the short version--you need to write down what you do, and you need to write it down immediately.

Suppose, for instance, you install one of these multimedia upgrade kits, a set containing a sound board, speakers, and a CD-ROM drive. In the process of setting this up, you'll have to choose several DMA channels, IRQ levels, I/O addresses, and, perhaps, ROM addresses.

You may have the best of intentions about writing down all this information soon, but what happens once you have your multimedia system up and running? You play with it, of course! And by the time you've finished trying it out, you're worn out and leave the PC for the day.

By the next day, there isn't a prayer that you can remember all the addresses, channels, and levels. So become methodical; make it a habit to write down those addresses.

The LAN board would only support IRQ2 through IRQ7. I didn't want to use any of them, as I like to avoid 2 if I can, and 3 through 7 were busy, so I needed an alternative approach. A quick look at the sound board showed that it could support any IRQ up to IRQ10, so I reset the sound board to IRQ10, leaving IRQ5 free for the LAN board. Problem solved.

Trouble appeared on the next machine as well. After inserted the LAN board, not only did the LAN board not work, the video screen showed some odd colors upon boot-up.

Clues like this are golden, as most IRQ failures are due to conflicts with other devices and conflicts cause both devices to fail. The video board worked fine before the LAN board was installed, but after the LAN board was installed, neither board worked. Not even a one-pipe problem, Watson!

The video board was a special Windows accelerator board, so I checked its documentation. (Need I deliver my sermon about keeping the documentation around?) The accelerator, as it turned out, employed the I/O address range 300-30F, causing a conflict with the Ethernet card. I reset the I/O address on the Ethernet card, and all was well with that machine.

The next computer booted up OK, but it had strange flickers on the video screen whenever I tried to use the Ethernet card with the test program supplied with the board. The Ethernet card was also failing its tests, so I looked more closely and realized that I'd never opened this particular computer before.

This computer was equipped with a Super VGA board. Almost all Super VGA boards have an autoswitching feature that they'll optionally support, a feature whereby they automatically detect which video mode the currently running software needs and then switch to that mode.

This feature should be disabled for two reasons. First, it causes OS/2 and Windows NT to fail, as well as a number of other programs. Second, the autoswitching mode requires that the video board use a combination of IRQ2 and IRQ9, which is less than desirable because it steals a much-needed interrupt; in some cases, it causes a system to falsely report memory errors. (If this sounds odd, it isn't. The hardware that detects memory errors--also called parity errors--is hooked to IRQ2.)

This Super VGA card, as you can imagine by now, had the interrupt enabled, allowing for Super VGA. I removed the interrupt jumper from the board--its location varies, and you must consult the documentation for your board before trying to remove the interrupt jumper. The Ethernet board ran without a hitch.

By the way, if you're planning to check your Super VGA board's documentation to find out whether or not the interrupt is enabled, be aware that some manuals refer to the interrupt and some refer to autoswitching. If you can't find one, look for the other. On some boards, it isn't a jumper, it's a DIP switch.

By now, as I approached the final machine. I was trying to anticipate problems. Like its comrades, the last LAN board refused to work at first. I struggled with this for a while, idly running diagnostic programs on the entire system.

As I've explained before, I reasoned that if I could figure out what didn't work on this system that had worked before, that would give me a clue about what the board was conflicting with. (Of course, there was the possibility that the board just plain didn't work, but my earlier experiences of the day made that seem unlikely.)

Then I noticed that the diagnostic programs failed to recognize that the PC had a mouse. Eureka! I recalled at that moment that this particular machine didn't have a serial mouse. Unlike most of the machines in my office, it had a bus mouse. A bus mouse requires an interrupt-using circuit board of its own, and I was fairly sure that I'd set the interrupt on the bus mouse interface board to IRQ5.

Not wanting to remove the cover from the PC unless necessary, I tried loading the mouse driver and got the error message interrupt jumper missing. I opened up the PC and checked the mouse board, and sure enough, it was using IRQ5. With its interrupt changed, I replaced the mouse board, and the last of the LAN boards fired up, ready to go.

I don't want to discourage you with this story. I just want to underscore the importance of documenting what's installed in your machines and to share a war story with you that may give you an idea or two the next time you're having trouble making a new board behave.