Understanding Hardware Device Resources Part One - IRQ's Anyone who has ever tried to install a legacy (non plug-and-play) device has learned that device configuration can be a world of confusion for the novice. Fortunately, the entire concept of device configuration can be simplified through the understanding of a few basic terms and concepts. When discussing device configuration, we typically hear about three basic types of hardware resources: Interrupt Request (IRQ) Line Assignments, Direct Memory Access (DMA) Assignments, and memory locations known as Input/Output (I/O) Addresses. In this series of three articles, I will discuss each of these terms with the intent of clarifying device configuration and resource conflict resolution. This discussion is based upon and applies primarily to current-design IBM-compatible systems operating under Microsoft Windows 98, although the other 32-bit versions of Windows are similar. Device resource conflicts occur whenever two or more hardware devices attempt to utilize the same resource. Normally, a conflict will simply stop one or more of the involved devices from operating properly. Often, this will be nothing more than an inconvenient nuisance. Sometimes however, the result is far more serious, to the point of not allowing Windows to load properly. A solid understanding of device resources and their assignments can assist the user in avoiding resource conflicts. Interrupt Request (IRQ) Line Assignments The Interrupt Request Lines, also known as hardware interrupts, are dedicated signal lines or circuits between the system CPU and hardware devices. These signal lines are used for the purpose of notifying the CPU that the assigned device needs processor attention and vice-versa. The simplest way to understand IRQ's is to consider the IRQ as a doorbellą when a device requires CPU attention, it places a signal on its assigned IRQ line. The CPU senses this signal and responds by stopping it's current operation and shifting its attention to the "interrupting" device. In this modern era of high-speed computers, we like to think that our PC's are whizzes at doing multiple jobs simultaneously. Hold on to your hats for the reality of it, folks - for all practical purposes, even the fastest CPU in a PC today is only capable of doing one thing at a time! It only seems like the CPU is doing multiple jobs, due to the fact that the CPU is capable of switching between tasks tens of thousands of times every second. To mere mortals, the apparent effect is that of a CPU doing all kinds of things at the same time. OK, so what does any of this have to do with IRQ's? As a kind of answer, ask yourself a question - "What happens when I try to talk to someone who is too busy to listen?" The IRQ's are the chosen method of making the (too busy) CPU listen to the other devices in the PC. When the CPU receives an IRQ signal, it must stop what it is doing and devote its attention to the interrupting device. These hardware interrupts are known as maskable interrupts, meaning that the processor can temporarily mask or ignore the interrupt request long enough to complete its current task. There is also a Non-Maskable Interrupt or NMI - an interrupt that cannot be ignored even temporarily - but we're not going to worry about that for this discussion, as it is in no way user-configurable. Let's look at a basic rundown of what is behind the whole hardware interrupt scheme. Consider the system keyboard. The keyboard controller on a typical system is a fairly limited device, with no real storage capability (memory) to speak of, and the CPU is responsible for moving the keystroke to the keyboard buffer. Each time the user presses a key, the generated keystroke signal must be passed off to the CPU immediately, because the next incoming keystroke will replace or overwrite the previous one if that one hasn't been stored yet. So what would happen to the incoming keystrokes if the CPU is busy doing something else and so is unable to handle them? The obvious answer is that they would be lost. To prevent this from occurring, the engineers have given the keyboard system the ability to demand processor attention. The keyboard controller, immediately upon receipt of an incoming keystroke, activates its assigned hardware interrupt line (IRQ1). The Intel 8259A IRQ controller chip accepts this interrupt request and passes it on to the processor's interrupt line. The processor in turn shifts its focus to the incoming keystrokes and handles them in the prescribed manner. There is a pre-determined routine to be followed by the system for each of the PC's interrupt lines. Two things of note should be remembered when reading this. One is that there is really a lot more involved than just the few simple steps that I've described here; the process was simplified for this discussion by stripping it down to just its pertinent factors. The other is that this all occurs at incredibly high rates of speed - thousands of times per second. Consider the concept of a 200 MHz CPU that can process 20 million instructions between each keystroke of 120 word-per-minute typist, based on an average of five characters per word. OK, so now that we have seen the basics of interrupt operation, we should look at some more detail about their deployment in the system. The original PC and XT systems used 8-bit ISA expansion slots, and had eight hardware interrupt lines. Figure 1 below shows the default IRQ assignments for the XT-class machines. IRQ Function or Assignment On Bus? 0 System Timer No 1 Keyboard Controller No 2 (Available) Yes 3 Serial Port 1 (COM2:) Yes 4 Serial Port 0 (COM1:) Yes 5 Hard Disk Drive Controller Yes 6 Floppy Disk Drive Controller Yes 7 Parallel Port 0 (LPT1:) Yes Figure 1 - XT Default IRQ Assignments Note that not all of the interrupt lines were made available to the expansion bus. Only those IRQ's that are available to the bus can be used by expansion devices installed to the bus. In other words, no user- installed expansion card could be assigned either IRQ0 or IRQ1, as there were no connections for those IRQ's assigned in the ISA 8-bit expansion slot. In earlier (pre-AT) systems, IRQ2 was reserved for certain video adapter types. With the introduction of the 16-bit ISA bus and the VGA standard, that reservation was pretty much no longer needed, but there was a need for additional IRQ lines. In keeping with the desire for backward compatibility, the engineers devised a scheme that would allow the additional IRQ lines to have processor access without changing the basic structure already in place. The result was the cascaded IRQ's numbered 8 through 15. These newly created IRQ's are connected to the CPU through the basically-unused IRQ2 connection. IRQ Function or Assignment On Bus? Bits? 0 System Timer No -- 1 Keyboard Controller No -- 2 Second IRQ Controller No -- 8 Real-Time Clock No -- 9 Available (shows as IRQ2 on 8-bit cards) Yes 8 10 (Available) Yes 16 11 (Available) Yes 16 12 Motherboard (PS/2) Mouse Port Yes 16 13 Math Coprocessor No -- 14 Hard Disk Drive Controller Yes 16 15 (Available) Yes 16 3 Serial Port 1 (COM2:) Yes 8 4 Serial Port 0 (COM1:) Yes 8 5 Parallel Port 1 (LPT2:) Yes 8 6 Floppy Disk Drive Controller Yes 8 7 Parallel Port 0 (LPT1:) Yes 8 Figure 2 - AT Default IRQ Assignments The existing IRQ2 line was removed from the 8-bit ISA slot and made available as a motherboard connection. A second Intel 8259A chip was added as a controller for the new IRQ's. Its output line connects to the IRQ2 line on the primary 8259A controller as an input. The line designated as IRQ9 on the new controller was then connected to the former IRQ2 connector on the 8-bit ISA slot. Most of the remaining IRQ lines of the secondary 8259A were then brought out to connections on the new 16-bit extension portion of the ISA expansion slot. Thus, we now have fifteen unique interrupt lines communicating to the CPU via the path that previously supported 8 interrupt lines. Figure 2 shows the default IRQ assignments for the AT-class machines. There is a certain amount of prioritization that occurs due to IRQ lines, but the effect of this prioritization is not really noticeable on today's high-speed computers. In a nutshell, the CPU responds to IRQ signals in their numerical order. In other words, if two devices apply an IRQ signal simultaneously, the device with the lower IRQ number gets the CPU's attention first. However, there is a catch to this scheme, which is hinted at in Figure 2. All of the interrupts handled by the second IRQ controller are prioritized after IRQ1 (the keyboard), but before IRQ3 (COM2:). This is due to the fact that they are connected to the first IRQ controller in place of the original IRQ2, and the entire second controller has therefore inherited the old IRQ2 priority position. Your PC has a limited number of IRQ's available - effectively fifteen on a modern system. Of these fifteen existing IRQ's, several are permanently assigned to specific mainboard devices and cannot be used for other purposes. The following chart (Figure 3) shows the typical IRQ assignments in use today. Note that some of the assignments are flexible (indicated by *), while others cannot be changed. IRQ Typical Device Comments and Probable User Assignments 0 System Timer Hard-configured; unavailable for user assignment 1 Keyboard Contr. Hard-configured; unavailable for user assignment 2 Cascade from IRQ9 (see IRQ9) 3 COM2* 4 COM1* 5 (available)* Modem, sound card, second parallel port 6 Floppy Controller Normally not available for user assignment 7 LPT1* 8 Real Time Clock Hard-configured; unavailable for user assignment 9 (available)* Modem, network adapter, sound card 10 (available)* SCSI adapter, sound card, USB controller 11 (available)* network adapter, SCSI adapter, video adapter 12 PS/2 Mouse* Available only if using non-PS/2 pointing device 13 NPU Normally not available for user assignment 14 Primary IDE Normally not available for user assignment 15 Secondary IDE Normally not available for user assignment Figure 3 - Typical Modern IRQ Assignments As can be seen in the chart, there are basically four IRQ's to choose from when installing additional devices into a standard PC. That's not a whole lot to work with! Now consider all of the devices that are found in most new PC's today. What happens when you try to add a modem, a sound card, a network adapter, a SCSI card, and a second printer port? A long-standing problem has been that two devices cannot share a single IRQ and have both devices work properly at the same time. We simply have more devices requiring IRQ's than we have available IRQ lines to assign! The engineers solved this dilemma with the introduction of the PCI (Peripheral Component Interconnect) bus. For the first time, the PCI bus allowed for managed sharing of hardware interrupts. We can now have multiple PCI devices assigned to the same physical IRQ line, because the PCI chipset manages communication between the PCI devices and the processor. For this reason, it is perfectly normal today to see two or three devices assigned to the same IRQ. In this case, you will also see entries such as IRQ Holder for PCI Steering. Configuration Woes Great! Now we know what IRQ's are. Sow how does all of that help us when configuring devices or trying to solve conflicts? Well, the answer to that is best found by looking at the three basic methods of device configuration: - Hardware (legacy) configuration - Software (legacy PNP) configuration - BIOS (PCI) configuration Hardware Configuration As its name implies, this type of device configuration is accomplished through physical changes to the device (card). Typically, these changes involve setting jumpers or DIP switches. Figures 4 and 5 below illustrate typical jumper blocks and DIP switches. Typically, the device manufacturer will provide configuration instructions that will indicate the correct jumper or switch positions for various available device configurations. As an example, a modem may have a Berg header consisting of two rows of eleven pins. The configuration diagram shows that the pairs are labeled JP1 through JP11, and that the default (factory shipping) configuration has a jumper placed on one pin of JP1and JP2, and on both pins of JP3 (see Figure 4), and that this jumper configuration (JP1 and JP2 open with JP3 closed) sets the modem to the standard COM4: resources of 2E8h and IRQ3. Logical Port Hex (h) Address JP1 JP2 COM1: 03F8h to 03FFh ON ON COM2: 02F8h to 02FFh ON OFF COM3: 03E8h to 03EFh OFF ON COM4:* 02E8h to 02EFh OFF OFF JP # 3* 4 5 6 8 10 11 IRQ 3 4 5 7 10 12 15 Figure 8 - Jumper Positions vs. Resources - Asterisks denote factory default settings Figures 6 through 8 illustrate this concept for a typical jumper-configured ISA modem. As stated earlier, this modem ships configured as a standard COM4: device. This means that the modem, once properly installed in the PC, will be hard-assigned the resources normally assigned to COM4:, and will therefore carry the COM4: designation. Here is where ISA device configuration gets tricky. Suppose that you wish to use this modem in your PC, but that you are already using serial port devices attached to COM1: (a digitizing tablet) and COM2: (a plotter). Will this modem work using its factory settings? Yes and No! Sound confusing? Let's see if we can make some sense out of this all. The Yes Part Remember earlier when I said that two devices couldn't share a single IRQ and have both devices work properly at the same time? The operative phrase here is the "work properly at the same time" part. Sure, we could install the modem with its factory configuration, and Windows will even allow it to be assigned the same IRQ as COM2:, and yeah, it will work that wayą until you need to use the plotter and the modem at the same time. Then, whichever device had the interrupt first would work, and the other one would not. Inconvenient? You bet! Then, to complicate the matter even more, if you should choose to use a background application such as a FAX manager, and have it launched when Windows starts, you would lose functionality of the plotter altogether, as the modem will then claim IRQ3 immediately when the FAX application is launched. The No Part As the preceding paragraph indicates, we probably don't want to have unusable peripheral equipment, meaning in this case that we probably don't want to have both COM2: and COM4: assigned to IRQ3. That means that you will have to select a different configuration for the modem - one where there will be no resource sharing or conflicts. Fortunately, this particular modem gives us several configuration options besides the standard COM port definitions from which we can choose. Note that in Figure 8, the modem ships with jumpers in place on positions JP1, JP2, and JP3. Jumpers JP1 and JP2 are used to select the Input/Output (I/O) Address, while jumpers JP3 through JP11 are used to make the IRQ assignment. We will discuss I/O Addresses in another article, so for now I will simply point out that COM ports are not bound to any particular IRQ lines. Although we customarily associate IRQ4 with COM1: and COM3:, and IRQ3 with COM2: and COM4:, we are really free to assign any available IRQ to these ports that is supported by the design of the hardware. What does this doubletalk mean? Simply that if the maker of a hardware device such as a modem or a printer port provides for it in the design of the card, we can assign non-standard IRQ's to these devices. Let's look at what I mean with respect to the modem in Figures 6 through 8. If we want the modem to carry the COM3 designation while using IRQ5, Figure 8 tells us that jumper JP1 should be open, JP2 should be closed, and JP5 should be closed. To accomplish this, take the JP2 jumper that is currently only on one pin of that pair and place it on both pins, closing JP2. Now take the jumper that is on JP3 and move it to JP5. Voila! The modem is now set to COM3 and IRQ5. The DIP Switch Part Earlier, I said that DIP switches are also used for device configuration. It makes absolutely no difference which method is used, as they are essentially the same. A jumper can be either off (open) or on (closed), making it a simple switch. Whatever method is used, the manufacturer should provide the same basic information. The purpose of all user-configurable jumpers or switches should be clearly discernable, and the documentation should include a picture or diagram of the card, showing the relative locations of the jumpers or switches. In addition, many cards will also have the configuration information etched or screen-printed on the card itself; this information may be on either surface of the card. Some cards which use DIP switches will have the bank of switches located near the rear edge of the card, with an access hole stamped in the card bracket to allow reconfiguration of the card without removing it from the PC. On some of these devices, the switch functions will be marked on the card bracket as well. One very important caution is needed hereą never change any jumper or DIP switch setting while the PC is powered up! Don't be afraid to return any hardware device that does not include adequate configuration and installation documentation. Also be sure to store any documentation that you do receive in a safe and accessible location, as you will probably need it if you decide to reconfigure your PC. The Most Important Part Earlier, I referred to this type of hardware resource configuration using the term legacy. This term basically refers to the fact that this type of hardware has inherited the basic physical characteristics of the original IBM AT design, and is therefore designed to be configured and installed without any intervention by the system BIOS, the installed operating system (OS), or any other software. In other words, these devices are completely hardware-configured, and are therefore locked in at whatever resources are assigned through the physical settings on the card. This is a very important consideration when selecting additional or replacement devices. For example, if choosing a replacement modem for use in a Linux system, you would want a legacy device rather than one that requires Windows for its configuration or control process. A critical feature of any legacy device is the expansion slot that it is designed to fit. Consider for example a modem that is meant to fit an 8-bit ISA slot. A quick glance at Figure 2 will show that this modem cannot possibly be configured to use IRQ's 10, 11, 12, 14, or 15. This is so because of the fact that those IRQ lines only connect to the 16-bit extension of the ISA slot. On the other hand, a modem that requires the use of a 16-bit ISA slot may be able to use any or all of those IRQ's, but only if the manufacturer specifically provided for their use in the allowed configuration options. So why did I select COM3: and IRQ5 for our sample device? In this particular instance, it was because I first determined that COM3: was not in use in the PC in question, and that the device currently using IRQ5 could be moved to IRQ11, which is currently available. Sounds simple, right? Actually, it is! Here's how to go about it: - Determine configuration options for the new device. This can only be done by referring to the device manufacturer's documentation for the device. If, as an example, you are installing a parallel port card and the only IRQ options provided for on the card are IRQ5 and IRQ7, one of these IRQ's must be freed if you wish to assign an IRQ for the card. - Determine currently available resources. In Windows98, this can be done in the System Device Manager applet of the Windows Control Panel (see Figures 9 & 10). Click the Properties button with Computer (at the top of the device tree) highlighted. Now make sure that the Interrupt Request option on the View Resources tab is selected. You should now see the current IRQ assignments listed in numerical order. Any IRQ line that is not listed here is currently unused (unassigned) and is therefore available for use. If there is an unlisted IRQ that is also one that your new device can use, great! If not, you will now have to see about making one available by reassigning one currently in use by another device. Note that these steps apply equally to the other configurable hardware resources (DMA Channel and I/O Address) that we will discuss in future articles. - Determine resources that can be made available. Initially, this system had its sound card assigned to IRQ5, which is the interrupt that we wish to use for the modem. This decision was made based upon the current IRQ usage by other devices and the IRQ assignments available on our new modem. The modem allows the use of IRQ's 3, 4, 5, 7, 10, 12, and15. Let's look at each of them in turn, referring to Figure 10 as we go. -- IRQ3 - in use by COM2:, which is currently used for a serial plotter. This resource is non-assignable on this particular motherboard due to the system BIOS; it is locked to the port if the port is enabled. -- IRQ4 - in use by COM1:, which is currently used for a digitizing tablet. This resource is non-assignable on this particular motherboard due to the system BIOS; it is locked to the port if the port is enabled. -- IRQ5 - in use by the Creative Ensoniq PCI Audio Device (sound card). This device, as a PCI device, can use any interrupt assigned to it by the system. At the time that the sound card was installed and configured, IRQ5 was free, and it was thus assigned dynamically by the system. -- IRQ7 - in use by LPT1:, which is currently used for a laser printer and a software security key (dongle). Although parallel ports do not actually require an interrupt, and will generally function properly without having an IRQ assigned, that cannot be done in this case, as the Interrupt is non- assignable on this particular motherboard due to the system BIOS; it is locked to the port if the port is enabled. -- IRQ10 - in use by the USB Host Controller, dynamically configured by the system. -- IRQ12 - in use by the PS/2-compatible pointing device (mouse). This resource is non-assignable on this particular motherboard due to the system BIOS; it is locked to the port if the port is enabled. -- IRQ15 - in use by the Secondary IDE controller, dynamically configured by the system. What becomes apparent from all of this is that the most likely IRQ candidate for the new modem is IRQ5. So how can it be freed from its current assignment? In this particular case, what we must do is deny the PCI bus the use of that interrupt for its pool of IRQ's. This is normally done through a system BIOS option wherein the PCI/Plug and Play preferences are set. Most motherboard BIOS'es allow us to reserve certain resources for legacy devices. Typically, the choice will be between Legacy and PCI/PnP. By setting IRQ5 to the Legacy option, it will no longer be available to the PCI controller upon reboot. Once this is done, the system must now reconfigure the PCI device that was using that IRQ, which in this case is the Creative Ensoniq PCI Audio Device. As is shown in Figure 10, that device was re-assigned to IRQ9, which is now being shared with the Adaptec AHA-2940UW PCI SCSI Controller. The PCI chipset manages this interrupt sharing perfectly, allowing multiple PCI devices to be addressed via the same hardware interrupt. We will look at PCI device installation and configuration some more later on. - Decide upon desired configuration. Now that we have decided that we can free up IRQ5 for the new modem to use, we need to select the other required resources for the device. Our modem is fairly simple and straightforward, only requiring one other hardware resource (the I/O Address) to be configured, and giving us four addresses from which to choose. Although we will go into I/O Addresses in another article, I will take a minute to touch on some basic points here. I chose COM3: for this installation for the simple reason of support expediency. It is much easier not to have to explain to a client why there doesn't have to be a COM3: in order to have a COM4:! It makes no real difference whether we choose COM3: or COM4: for the new modem; it will work just fine either way. What does make a difference is the software that will be used with the modem. Virtually all newer Win9x- designed applications will work with the modem regardless of the I/O Address and IRQ in use. However, there are some 16-bit applications still in use that expect only standard AT IRQ assignments for COM ports, and will not work with non-standard resources. The best thing to do in that case is to update the software if at all possible. A couple of paragraphs ago, I mentioned the "other required resources". You should be aware that some devices may require multiple IRQ's, multiple I/O Addresses, a BIOS address, and one or more DMA Channel. Consider the sound card with an MPU-401 device, an IDE interface, and an SB-16 emulator. This type of card can easily use three IRQ's, two DMA Channels, and four or more I/O addresses. Any one of these required resources can cause a conflict and thereby cause the devices involved to cease to function. As stated earlier, this can cause fatal errors in Windows upon attempted use of the device, or it even cause Windows to fail to load at all. - Configure and install device. As we saw a little while ago, this modem is fairly easy to configure, as the manufacturer has provided good documentation regarding jumper positions and settings. A maximum of three jumpers are used to set any possible configuration for this modem, and the jumpers are all located in one header, which is clearly labeled. This is not always the case, though. I have seen cards that had completely different markings on them from those shown in the manual for the card. I have seen cards with switches when the documentation said there should be jumpers. I have seen cards where the diagrams in the documentation in no way matched the card. I have seen cards with jumper wires on the card instead of Berg headers, requiring the technician to cut the wire to "open" the jumper, and to solder a jumper wire in place if a "closed" option was required. Now I'm not telling you this to scare you! Rather, it is intended to show you that we have come a long way towards user-friendliness where card configuration is concerned. So, again I'll repeat what I said beforeą If the card you purchase has poor or confusing documentation, either return itą or get some professional help with the configuration. Fortunately, most retail-packaged cards today include comparatively good documentation. The same cannot be said for many OEM-type devices, wherein the manufacturers apparently expect that these cards will only be installed by experienced technicians having extensive reference libraries at hand! Installation of the card will vary depending upon the type of device involved. Here too it is best to follow the specific instructions shipped with your card or device. I should point out that Windows can not always do good job of detecting installed devices, either. For example, configure our sample modem as COM3: and IRQ5, and then install it into an ISA slot. Now start the PC and let Windows load up. Now, assuming no hardware resource conflicts exist, have Windows detect new hardware. Will it find a modem? Nope! Windows will find a COM portąperiod! You will now have to use the driver disk that shipped with the modem to configure the modem. On the other hand, once Windows has detected the COM port (or once you have manually installed it and assigned it the correct resources in Device Manager), Windows will detect a modem on the new COM port if you use the Control Panel Modems applet and allow it to look for your modem. The key here is to have the COM port properly configured first. Software (legacy PNP) Configuration There is another class of ISA expansion cards or devices known collectively as Legacy PNP devices. These cards are basically jumperless, and are therefore configured through a software routine. The most common of these is the Intel ICU (ISA Configuration Utility). This utility was shipped with many early plug-and-play devices, and is required for configuration of these devices in a non-PNP environment. In most cases, these devices are a configuration problem only for systems without a plug-and-play BIOS or operating system. It is possible, though, for these devices to cause configuration headaches even with a PNP BIOS and OS. This happens when the BIOS is configured for manual resource assignment and a non-PNP operating system. Although I have encountered this situation several times, it really is the exception rather than the rule. If the PC uses a non-PNP BIOS and is running a non-PNP operating system, for example Windows3.1x over any version of MS-DOS or PC-DOS, the use of the ICU becomes mandatory for proper configuration of Legacy PNP cards. Now let's take a look at some of what is involved in PNP device configuration. As a general rule, most users don't change system hardware very often. That being the case, it really makes no sense for the system to have to reassign device resources on every system start. So, as a means of preventing the need for such repetitive activity, the concept of storing Extended System Configuration Data (ESCD) was developed. You have probably seen the on-screen notation "ESCD Updated". This is an indication that your system, on startup, found one or more devices to be utilizing resources other than those that had been previously assigned. In a modern system with PNP BIOS, there is a small amount (less than 32 KB, and usually 4KB) of RAM set aside to be used as non-volatile random access memory (NVRAM). It is in this area that the ESCD - the resource assignment information for all PNP devices - is stored. Having this information stored means that the system does not have to go through a device detection and resource assignment routine on each startup; rather, the system will simply use the information already stored unless hardware changes are found. This decreases the overall startup time for the PC. Without getting sidetracked too far, I must say a few words about NVRAM. The term volatility as applied to memory refers to a given type of memory's ability to retain stored information when incoming power is removed from the system. All magnetic and optical storage methods are considered to be non-volatile, as the stored information survives power loss in the system. RAM, on the other hand, is considered to be volatile, as any data stored there is lost when the system is powered down. OK, so how can RAM be set aside for use as NVRAM as I said above? The answer to that question depends upon the particular mainboard design, which basically fall into two general categories. In the first, the ESCD is copied from the set-aside NVRAM area to an EEPROM as part of a normal system shutdown. The second category uses a slightly different approach. On these mainboards, the ESCD is copied to a segment of CMOS RAM, which is then kept "alive" by use of a battery. In either type of system, the ESCD is then copied back to the set-aside RAM area on system startup. With the first of these methods, a system that was not properly and successfully shut down may have to detect and configure installed devices when it is restarted. This would be a result of the ESCD not being written to the EEPROM, but should only happen if the current configuration (on restart) differs from that which is currently stored in the EEPROM. The second type of system is prone to another problem. In these systems, the validity of the stored ESCD is dependent upon the health of a battery. Therefore, if the battery is too weak to maintain the CMOS RAM, the ESCD will be lost. In most systems using this approach, that problem becomes immediately apparent, as the same battery is used for both the ESCD and the system BIOS settings. In this case, the PC may not boot at all, as hard disk drive parameters may be lost as well. So what happens with those older PC's, where there is no provision made for storing the ESCD? Here again we have a couple of basic designs to deal with. Some later-model 486 mainboards used an early PNP BIOS, but without any ESCD storage method. These systems would run a PNP device detection and configuration routine as a part of their normal startup sequence. Earlier systems had no PNP capabilities at all, and it is with these systems that we get involved with the ICU. The Intel ICU was commonly shipped with early PNP cards. It performed the same basic functions that are now performed by the PNP BIOS, but was an on- demand disk-stored utility rather than a part of the mainboard firmware. It was invoked on system startup via a line in the CONFIG.SYS file, which loaded the DWCFGMG.SYS configuration manager driver. In addition, a file called ESCD.RF is written to the root directory of the boot drive, and is used for storing the current ESCD as determined through the ICU. The ICU had both DOS and Windows components, allowing the user to launch the device configuration utility in either environment, and was completely incompatible with Windows95. Through the use of the ICU, the user could set the desired resources for the ISA PNP cards in the system. There was limited configuration capability for PCI devices, and the user could "lock" the resource assignments when complete. The utility provided a comparatively small number of device definitions upon installation, but the user could add additional devices to the database. All things considered, the ICU provided a workable solution to an otherwise impossible problem. BIOS Device Configuration Now that we have had a little look at the older systems, it is time to move on to something more current. Mainboards being produced for today's PC market utilize a configuration scheme that is much closer to the Microsoft/Intel/Compaq design ideal of 1993. The original concept was that of a self-configuring system, wherein each new device installed would communicate with the system BIOS so as to make its configuration needs known. The BIOS would then allocate resources to each device present based upon the particular needs of each device and the pool of available resources. This information would then be passed upon request to the operating system, which would in turn load the correct drivers, thereby making all installed devices available to the user. We fall short of that ideal however, in that we often end up with a mixed bag of legacy ISA and plug-and-play PCI devices. We also have a vast number of "generic" devices on the market, and these devices will often not identify themselves correctly to either the system BIOS or the operating system. Then we get into the whole scenario of devices that are newer than the BIOS and the OS, and which require crazy contortions to get them configured. As a good example of this, take a look at the USB devices that are integrated on most of the newer mainboards. When Windows95 was first released, USB was not yet supported. Later versions of Win95 had some basic USB support, but it was poor at best. Along came Windows98 with better support, soon to be followed by Win98SE. At the same time though, there were many mainboards being sold with dual USB ports of which only one was activeą and to make that one work, the user would have to install OS patches and vendor-specific drivers. As anyone who uses the VIA chipset- based mainboards knows well, some issue is constantly cropping up which requires installation of an updated driver set as a fix. The long and short of it is that our constantly changing technology almost eliminates the possibility of true plug-and-play on a wide scale. So where does all of that leave us? Hereą with varying levels of PNP compliance to varying PNP standards, which varying operating systems handle in varying waysą get the picture? The Theory In reality, there is a way to make some sense out of it all. Listed below are some things that will help us to understand the current plug-and-play scheme. - When a device is designed, its manufacturer must decide what resource types the device needs for its operation. Different device types will require different resource types, potentially including ROM addresses, RAM addresses, I/O addresses, Interrupt Request lines (IRQ's), and Direct Memory Access lines (DMA's) - The manufacturer must include specific circuitry on the card for handling its PNP response and configuration. - The card PNP circuitry includes a ROM in which is stored varying information about the card, including but not limited to a device indicator, a manufacturer code, a device type code, and a serial identifier. The ROM can also include OS-specific configuration information. This information is for use by PNP OS'es in determining which specific resources are allocated to the card. - The configuration information on the device ROM may include specifics as to the IRQ's, DMA's, and RAM, ROM, and I/O addresses usable by the device. Successful device configuration requires matching a device-usable resource with a system-available value, and then allocating that matching value to the device. This can be done by either the system BIOS or the operating system. - Many generic or inexpensive cards carry little or no configuration information, relying upon the user to identify the card and install the proper OEMSETUP.INF file for the card. Once the .INF file is loaded, the OS can then configure the card based upon information provided in that file. - Many generic or inexpensive cards offer extremely limited options regarding usable resources. This can lead to conflicts if the only device- usable resources are already in use by some other equally limited device. In some cases, the only option is to install a different card - one with differing device-usable resource specifications. - Only one PNP card is able to communicate with the system BIOS at a time. On startup, the BIOS polls all installed cards, looking and reading for the information stored on the cards' ROM chips. This information is used to determine whether the BIOS can configure the card or if the configuration must be accomplished through the OS. - In modern PC's, we have the option of allowing the BIOS to configure the PNP devices - that is, those that can be BIOS-configured - or else we can allow the PNP operating system to do all of the device configuration. Device configuration should normally be done by one or the other, but not by both! Very often, allowing both the BIOS and the OS to get involved will cause conflicts and/or inoperative devices. - Most BIOS'es today will allow the user to reserve resources for use by non-PNP devices. This becomes important when there is a mix of PNP capabilities among the installed devices. Any hardware resources that are not reserved will be considered as being available for use by PNP-compliant devices. - Current PNP operating systems also allow the reservation of specific system hardware resources for legacy devices. This is normally accomplished through use of the System Device Manager (SDM) or its equivalent. OK - that's all well and goodą but how does all of that help when we can't get a new NIC to set up right? Or, what do we do when Device Manager shows several devices listed as Unknown Device, and we have absolutely no clue as to what they are? And what is that PCI Communication Device and that PCI Multimedia Audio Device that just showed up? Unfortunately, these types of SDM entries are not uncommon when dealing with generic devices, as many of these devices carry very little identifying information in their ROM's. That is when our detective skills come into play, as now we must try to identify the installed devices on our own. One method is to look for hints in the way the device is listed in the SDM. If we have just installed a new modem, the PCI Communication Device that now shows in the SDM is most likely that new modem, right? So how about the PCI Multimedia Audio Device? Well, if the modem has voice (VOX) capability, then it is a safe bet that the PCI Multimedia Audio Device is the modem's WAVE Audio device. The real challenge comes when you have just assembled a new systemą or when you are doing a clean install of your OS. Now you may have numerous devices listed as Unknown Device in the SDM, and these may in fact include most of the installed devices. In this situation, it is probably a good idea to take a couple of steps backward and remove as many cards as is possible from the system. Take it slow - if you are not sure what devices are which in the SDM, and if you force-install the wrong drivers, you will only make a manageable situation unmanageable and will end up frustrated. That's when PC's end up "falling" out through the third-floor window! Try this insteadą Strip the system down to the basics and now look at the SDM list. Anything still on the list is (obviously) something that is still installed in the system. Depending upon the level of mainboard integration, what you might see will include SCSI devices, USB devices, communication devices, audio devices, network adapters and display adapters. In addition, you will see COM and LPT ports, IDE devices, and various devices related specifically to the control of the PCI bus and interface. At this point, start installing the drivers found on the disk(s) provided by the mainboard manufacturer. Many mainboard devices will be easily configured through setup routines provided by the mainboard manufacturer. Once that has been done, look at the SDM again, and compare the listed devices to the devices that you are expecting to see. For example, suppose that your mainboard includes an integrated network adapter. After running the manufacturer's setup routine, you look at the SDM and still see an Unknown Device listed, but there is no network adapter listed. Starting to get the idea? Now look and see if there is a driver set for the network adapter on the installation disk. I used this example for the simple reason that it will often happen just that wayą the setup routine will often configure are devices that are standard equipment for the mainboard family, but will very often not configure those devices that are optional within that mainboard family. These can include display adapters, modems, network adapters, and audio devices, and secondary USB devices. Great! You now have all of the mainboard devices installed and configured, so now it's time to start adding other devices to the system. If you are comfortable with multiple simultaneous installations, go for it! Back up the registry, and then put them all in and start installing the drivers. My own preference is to install them one at a timeą and then to check the system operation after each addition. If the system seems stable, and if each new device has installed and configured properly, I will then back up the registry before beginning the next installation. Many years of experience has taught me the value of this method. If any given installation causes a system crash, I don't have to start all over again - I will simply restore the last successful registry backup. I guess that I just opened up a can of wormsą when I said that a device installation could cause a system crash. Yep - it happens! You install a certain card that needs a given resource that is already in use, and then the system wont start. Or, you install a device whose driver causes a memory conflict, and you start getting the dreaded BSOD. How can these problems be solved? Read oną The advised methodology of installing and configuring a single card at a time basically pinpoints the culprit for you. If all was well before that video capture card was installed but was not afterwards, it is a good guess that something about that installation is causing the problem. It may be that the driver supplied with the device is not compatible with other drivers installed to your system. In that case, the first step is to see if there is an updated driver available for the device in question. Lacking that, some research into your other installed devices is in order. There may be a known and documented compatibility issue. In most situations where a new system is being planned, the research should be done prior to purchasing the individual components. There is no sense in buying a particular combination of cards that is known to be configuration problem. Some manufacturers will go so far as to provide information regarding other devices with which their product will not peacefully coexist. Sometimes, though, you won't have that option, as is often the case when doing an operating system upgrade, or when replacing a mainboard in an existing system. In those cases, about all that you can do is figure out which device is the problem one look for an alternative to that device. The Practical Aspect So far, this has all been an over-the-top discussion of PNP configuration. Now, let's get down to the nuts and bolts of it all from a user's point of view. I often hear questions regarding PCI devices and IRQ assignments, and especially about the listing of multiple devices being assigned to a single IRQ. Many users, after years of being told that devices cannot share IRQ's, get upset when they see multiple devices listed as using the same IRQ. Even worse, they see such cryptic listings as IRQ Holder for PCI Steering (see Figure 10)ą and they often see multiple instances of that entry. Don't worry - it's perfectly normal and absolutely workable, and here's what it's all about. Remember that earlier I said that there were only sixteen total IRQ's available in a modern system, and that of that number, only four are available for additional devices in many systems? Four IRQ's don't allow for much expansion if each device must have a unique IRQ. As a result, the engineering gurus came up with a method of effectively sharing IRQ's between devices that are specifically designed for such sharing. That is an important point - the devices that will share a system IRQ must have been designed with the ability to share IRQ's. If they are not so designed, one or more of the sharing devices may not operate properly even though the SDM is not reporting a resource conflict! In a nutshell, each of the involved devices is technically properly configured when considered individually, and therefore no resource conflict is reported by the system. The PCI bus was an innovation that met three specific goals. One was that of an expansion bus that could and would operate at a higher speed than those that came before it. Another was that of an expansion bus that was not processor dependent, negating the need for continual redesign of the bus as new and/or different processor types became available. There were several earlier attempts at high-speed bus designs, but all of them were either manufacturer-specific (proprietary) or processor-specific (able to function only with a certain processor). The third goal was for the new bus to be capable of supporting the (then) new concept of being almost self- configuring. As is indicated by its wide acceptance, the PCI bus has become a huge success, meeting all of these goals and adding other enhancements as well. Simply put, the PCI design effectively separates the I/O subsystem from the CPU/RAM/cache subsystem. If a PC uses the PCI bus, all installed PCI devices communicate with the PCI controller, which in turn communicates with the processor's local bus through a PCI-to-host bridge device. The PCI subsystem is afforded four individual interrupt lines for its own internal use. To identify these as PCI internal interrupts rather than system hardware interrupt lines (IRQ's), they are labeled as INTA, INTB, INTC, and INTD. Each of these lines is made available to each PCI expansion slot in the system, and the total number of PCI slots that a given system can support depends upon the number of PCI devices that are integrated on the mainboard. Now here's where I lose most newbiesą each of these interrupts, if needed by a device installed in an expansion slot, is then mapped to (or linked with) one of the available system IRQ lines. The PCI controller chip keeps track of which PCI interrupt is mapped to which system IRQ. Clear so far? Great! All is well if there are exactly four PCI slots on the mainboard and four available system IRQ's from which to choose. As you might have guessed by now, it can't be that easy! For example, many earlier BIOS'es will "lock" a given IRQ to a particular PCI slot, effectively preventing the use of any other IRQ for the device in that slot. In that case, the user is forced to shuffle cards between slots in order to find an IRQ combination that will work. For example, if a particular device was designed only to use IRQ's 5,7,9, and 10, but is installed into a slot that is locked to IRQ11, the device may not operate until it is moved to another slot. Some BIOS models would allow the user to specify the associations of IRQ's to PCI internal interrupts, though, as well as specifying the association of PCI internal interrupts to physical slots. The most important thing to remember from all of this is that there are no hard and fast rules when it comes to PCI slots versus PCI interrupts versus IRQ's! This is because there is no one standard governing these relationships. The application of the basic PCI design to a given mainboard is left up to the maker of that mainboard. There are however some "rules of thumb" that help in assembling and configuring PCI-based systems. Newer systems have much more flexibility for automatic configuration. If the system is using a PNP operating system, all that the user needs to do is enable the BIOS option for the PNP OS and let the OS do the configuration. Current versions of Windows98 will update the ESCD after device configuration, saving the information for the next startup. Because of the flexibility of newer BIOS'es and PCI chipsets, it is now common for the PCI controller to assign multiple devices to a single hardware IRQ. When this does happen, you will see SDM entries for IRQ Holder for PCI Steering. There will usually be one of these entries for each device assigned to a given IRQ, and the SDM will also show the actual devices that are linked to the PCI Steering entries. For an illustration of this, take a closer look at the devices listed for IRQ9, IRQ10, and IRQ11 in Figures 10B and 10C. These entries are for devices in the PCI expansion slots. OK - now take a look at the information shown in Figure 12. This figure contains two screen shots taken while using Micro 2000's Micro-Scope 8 to read the PCI information on another PC. This one is fairly straightforward, having (in addition to the mainboard integrated devices) only a sound card, a modem, a network adapter card, and a video adapter card installed. The sound card is an ISA-PNP card and the video adapter is an AGP type. The network adapter (NIC) is in the first PCI slot (immediately adjacent to the AGP slot), and the modem is in the fourth and last PCI slot. Figure 13 shows the SDM listing for the same PC. Let's take a few minutes to analyze some of the information that Micro-Scope 8 (MS8) has extracted. For each PCI device found, MS8 shows specific data about that device and its relationships within the PC. Figure 11 below provides a key to the information shown. Heading Data Represented Bus# Device number assigned by PCI controller upon device detection Vend Vendor ID as stored on device ROM Device Device ID as stored on device ROM Class/Sub Classification and/or subsystem class of device as stored on device ROM Class Nomen Description of device classification as stored on device ROM Sub Nomen Description of device subsystem class as stored on device ROM IRQ System hardware IRQ assigned to device Addr0 First memory address used by device Addr1 Second memory address used by device Addr2 Third memory address used by device Figure 11 - Key to PCI Information Screen Shots It is important to note that the only information that the manufacturer must store on the device ROM is the Vendor ID and the Device ID. Any and all other information stored there is of an optional nature. As might be guessed, many generic or inexpensive devices have no optional data on their ROM's. This is the cause of those poorly identified or Unknown Device entries in the SDM. Looking more closely at Figure 12, you will see that there are five entries listed with 00 in the IRQ field. This may seem confusing, as Figure 13A shows that IRQ0 (IRQ00) is used by the System Timer. All five of these devices are mainboard integrated components of the PCI control subsystem. Now look at the fifth entry in Figure 12A. This entry is for the USB device, and although this is also a mainboard integrated component, it is controlled by the PCI subsystem rather than being a part of that subsystem. It is for this reason that the USB is not grouped with the other integrated components. To further support this concept, consider the other integrated components that also receive discrete IRQ's - the COM ports, the first LPT port, the floppy controller, and the two IDE interfaces. What, you ask, about the last entry in Figure 12b - the one that shows and IRQ assignment of 255? That entry is for the AGP video adapter in this system. AGP (Accelerated Graphics Port) is an offshoot of the PCI specification, and is a topic for it's own article. Briefly, though, the 255 value is displayed because there is no IRQ assigned to the VGA in this system. The system BIOS in use here offers the optional use of an IRQ for the video subsystem, and in this case the option was set to the "No" choice. Each of the other entries in the PCI Information shown in Figure 12 matches precisely with the SDM information shown in Figure 13. Note that the SDM shows the IRQ Holders for each of the PCI devices listed. Note also that IRQ9, one of the standard IRQ's used by the PCI bus, is not used at all by the PCI bus in this system. That is due to the fact that IRQ9 is in use by the sound card, and as I stated earlier, the sound card is an ISA-PNP type. Here comes another one of those pesky PCI rules - No interrupt can be shared between a PCI device and an ISA device. This means that any and all IRQ's assigned to, used by, or reserved for ISA devices will be completely unavailable to the PCI bus. This is exactly why IRQ5 is not shown at all in Figure 13A. That IRQ has been reserved (together with an I/O range) for an industrial interface board that is installed in one of the ISA slots. This board is completely invisible to Windows98, is configured by jumpers, and is initialized by the application software used to output jobs to the connected machine. Before leaving these figures, compare the data shown in Figure 13 to that shown in Figure 10, noting the similarities for many of the IRQ's. Now compare both of these figures to Figure 3. As should now be evident, most of these assignments are fairly consistent from one system to another, with the main difference being in the user-optional devices. Devices that have been deemed to be standard or basic system devices will always be found at the same IRQ. A complete explanation of the process that allows PCI IRQ sharing is beyond the scope of this article, and is really irrelevant anyway. All that matters to the user is that it worksą as long as all of the requirements for IRQ sharing are met by both the mainboard (BIOS) and the expansion device. Another issue with PCI configuration has to do with those resources that are customarily used for legacy devices. Consider the IRQ's typically assigned for COM1: and COM2:. If your system has COM1: enabled in the BIOS but has COM2: disabled there, it would stand to reason that the IRQ normally used for COM2: should now be available for use in the PCI PNP resource pool, right? Unfortunately, it is not always recognized as being free, and therefore may not be used by the PCI bus. Typically, this problem is mainboard and/or BIOS specific, and is usually a problem only if the PNP configuration is done by the BIOS rather than by the operating system. Wrapping It Up The purpose of this article was to make basic hardware configuration less of a mystery to the PC user, especially as related to IRQ's. It has been my experience that IRQ's cause more configuration headaches than any other aspect of hardware configuration. I think that this is due to the scarcity of IRQ's in comparison to I/O address ranges. While there are fewer DMA's than IRQ's, few devices really require a DMA assignment, but virtually every device wants an IRQ. The Plug-and-Play concept has gone a long way towards simplifying most hardware configuration jobs, but it is still nowhere near the hands-off task that we would like it to be. I sincerely hope that the information provided here will help to further your understanding of the concepts discussed. I hope that you will be able to apply some of this to your everyday configuration and troubleshooting chores, and I will gladly welcome comments on the usefulness of the information provided. In future articles, we will look at the other hardware resource aspects that were not covered here. Specifically, we will cover I/O Addresses and DMA assignments. In addition, this article will be updated from time to time as needed, based upon emerging technology and reader comments. Stay tuned...