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?
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.
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.