Unlike some operating systems, such as Windows 9x/ME, NT/2000, or OS/2, DOS does not include much built-in support for peripheral devices. Instead, most devices require the addition of device drivers to your DOS configuration in order to access the devices in question.
Virtually every DOS-based computer system needs to work with device drivers at some point, unless it's using an extremely simple hardware configuration. Spending some time familiarizing yourself with this important topic can help you save time when you need to add or manage various device drivers in your system.
DOS contains only rudimentary support for computer hardware. For example, DOS can work with standard VGA video cards, basic IDE hard disks, floppy disk drives, text-mode printers, keyboards, and that's about it. To use other types of hardware usually requires the installation and configuration of a device driver for the device in question. Device drivers enable the following types of devices to work with DOS:
CD-ROM
Mouse or trackball
Tape backup
Video cards
Sound cards
Network cards
Other nonstandard storage devices, such as Zip and Jaz drives
Note
DOS itself can work with printers in only the simplest possible way: It can send text-only information to a printer that can accept that type of information. This means that, just using DOS, you can print only plain text. Other printer features, such as boldface, underline, or even graphics, require an application that uses an application-specific printer driver that cannot be shared with other applications.
Under DOS, you can direct text output to a printer in several ways. You can press the Print Screen key to send a copy of what's on the screen to the printer. You can copy a text file to the printer by using the command COPY filename.ext PRN: and then pressing Enter. You can also use DOS redirection to do the same thing, with the command TYPE filename.ext >PRN:.
For serial printers, see Chapter 13, “Controlling Devices,” on use of the MODE command, which is usually required with serial-port printers.
You might be wondering why you don't see printers and modems in the preceding list. Note that there are two distinct types of device drivers. The first kind—the kind you usually hear about—enables DOS itself to interact with and manage a particular device, such as a CD-ROM drive. When DOS can access and manage a device through the use of a device driver, applications can then make use of the device, too, through DOS.
The second kind of device driver, an application-specific device driver, supports a specific application program that needs to work with a device. For example, WordPerfect for DOS includes its own printer device drivers to allow it to work properly with different printers. The printer device drivers that WordPerfect uses are installed in WordPerfect itself and do not benefit or work with any other application. As another example, most communications programs under DOS either include their own modem device drivers, or they allow fine control of a number of settings that enable them to work with different modems.
To understand device drivers and how they are configured, you first need to understand some basics about standard PC architecture and how DOS works with both application programs and devices to accomplish its work. You also need to understand how the devices themselves interact with the computer because many devices require that you determine and set their hardware interrupt, DMA channel, and memory address manually. The following sections discuss this information.
You have no doubt heard about hardware interrupts, also called IRQs, inside your computer. All PCs are built so that devices that are part of the computer communicate with the processor through the use of these hardware interrupts. A hardware interrupt enables a device, such as your keyboard, to send a signal to the processor indicating that the device requires the processor's attention. When the processor receives a signal on one of these interrupts, it branches to a region of memory that contains the program that handles the device itself. For example, every time you press a key on your keyboard, an interrupt is generated for your processor. The processor then finds the program that corresponds to the interrupt, which in turn handles whatever the device needs. In the case of a key being pressed, the program reads which key was pressed from the keyboard and then sends the information to DOS so that DOS or a running application program can display the key on the screen or do whatever else was intended.
All PCs have 16 hardware interrupts, and unfortunately this number cannot be expanded. The 16 interrupts are arranged in two banks of 8 interrupts, with the second bank being connected to the first bank through interrupts 2 and 9. Because interrupts 2 and 9 link the two banks together, you generally don't want to use these interrupts for any devices in the system (although there are rare exceptions to this rule).
Hardware interrupts in most PCs are edge-sensitive, meaning that the system measures simply whether the interrupt signal is on or off. In some systems, particularly those that use either the EISA or MCA (microchannel) buses, interrupts are level-sensitive, meaning that an individual interrupt signal can be set to one of several different levels. The idea behind level-sensitive interrupts is that, in theory, multiple devices can share an interrupt, with each device using a different level for its communication. However, in practice, this doesn't work very well, and so most buses stick with edge-sensitive interrupts.
IRQ assignments can be shared between devices but never between devices that will be used at the same time. For example, if a computer has an interrupt set for one of its communication ports connected to a modem, it also might be capable of using the same interrupt assignment for a tape backup device, provided that the tape backup device is never used while the modem is being used. Another way this works is for systems that have multiple serial devices installed in them. For example, imagine that a computer has a serial mouse connected to COM1 (IRQ 4) and a modem connected to COM2 (IRQ 3). If another serial device is installed as COM3, it is usually assigned to the same IRQ number as COM1. This also means that the additional device can't be used at the same time as the mouse (which probably means that it can never be used because most mouse devices are active all the time). Instead, in this type of circumstance, you are better off placing the modem on COM1, the mouse on COM2, and the third device on COM3, with the understanding that the third device cannot be used while the modem is in use.
You need to be familiar with some standard IRQ assignments. Note that some of them might be different in a particular PC, depending on the extra equipment provided from the manufacturer and which IRQ is assigned to each device. However, for most systems, the interrupt assignments listed in Table 12.1 are correct for the basic hardware devices.
Table 12.1. Standard Hardware Interrupt (IRQ) Assignments
Virtually every card you install in the computer requires that you set its IRQ. Often, add-on cards come with special software that can do this job for you, and they also help you determine which IRQs might be free for the cards to use. Other cards provide only a bank of switches or jumpers on the cards to set this information, and it's up to you to determine which IRQ is free for the cards and to make sure that the system and new device work properly with the chosen IRQ.
Many devices need to transfer large amounts of data to or from the computer's memory. To free the computer's processor from needing to perform these transfers for devices with large data-transfer needs (such as hard disk controllers, video cards, and network cards), the PC architecture includes a chip called a Direct Memory Access Controller, or DMA Controller. The DMA controller can transfer memory from one place in the computer to another memory address, without using the processor to do the work. The DMA controller is told where the source address of the data to be transferred is, where the destination address is, and how much to transfer. The processor is then relieved from doing the actual work, and the DMA controller takes care of moving the data from one place to another. (It also does so more rapidly than the processor usually can.) The PC has a total of eight DMA channels, and these DMA channels cannot be shared among devices that use them. Moreover, different DMA channels have either 8- or 16-bit transfer capabilities, and devices usually require one or the other. Table 12.2 lists the standard DMA channels in a PC and their usual assignments.
Table 12.2. Standard PC DMA Assignments
| DMA | Size | Assignment |
|---|---|---|
| 0 | 8-bit | Available |
| 1 | 8-bit | Available (can be used for network cards) |
| 2 | 8-bit | Floppy disk controller |
| 3 | 8-bit | Available (can be used for enhanced parallel ports EPP or ECP) |
| 4 | Unavailable (used for memory refresh) | |
| 5 | 16-bit | Available |
| 6 | 16-bit | Available |
| 7 | 16-bit | Available (can be used for hard disk controllers) |
Four common devices make use of the DMA controller and require that a particular DMA channel be assigned to them. These devices are the floppy disk drive (assigned to DMA channel 2), the hard disk controller, the video card, and any installed network cards. In the last three cases, the devices might or might not use DMAs; it's up to the designers of the cards. In newer PCs, these devices do not use DMAs, whereas older computers (80486-based and earlier) often use versions of these devices that do use DMAs.
Most add-on cards that use a DMA channel offer a default setting that works most often. However, if the device isn't functioning correctly, you might have to try one of the other possible DMA channels available on that particular card.
Programs cannot send data to or receive data from devices connected to the computer directly. Instead, small portions of memory are set aside into which programs (and DOS) place information destined for a device, and vice versa. These areas of memory are called I/O port addresses (I/O being short for Input/Output). These memory spaces cannot be shared, nor can they overlap each other.
Most devices you install into the computer require an I/O port address be assigned to them. Often, the default setting from the manufacturer works, although usually alternative addresses also are provided in case of conflict. Most device drivers also need this information to properly interact with the device itself.
As mentioned at the beginning of the chapter, device drivers are memory-resident programs that enable DOS and application programs to interact with certain devices in the computer. Device drivers are generally set up in DOS through a statement in the system's CONFIG.SYS file. In rare cases, a device driver might be loaded in the AUTOEXEC.BAT file instead. Most device drivers use the .SYS extension.
Device drivers in the CONFIG.SYS file are loaded through either the DEVICE= or DEVICEHIGH= statements. The former loads the device driver into conventional memory, whereas the latter attempts to load the device driver into extended memory. Most device drivers function well either way, although in rare cases, a device driver might work properly only in conventional memory. Aside from this, though, whether they are located in conventional or extended memory is determined by the overall memory tuning for the system, which is discussed in Chapter 19, “Configuring Your Computer.”
Note
Device drivers loaded in AUTOEXEC.BAT are placed into conventional memory unless you use the LOADHIGH command to start them.
Two device drivers that most DOS systems load, regardless of what peripherals they have loaded, are HIMEM and EMM386. They are both loaded in the CONFIG.SYS file, and they provide additional memory management services for DOS (in this case, you might think of the system's RAM as a device). Following is an example of how these two lines usually appear in the CONFIG.SYS file:
DEVICE=C:DOSHIMEM.SYS DEVICE=C:DOSEMM386.EXE RAM
As you can see, the actual device driver files can be located anywhere on the computer system, and the DEVICE command accepts drive letters and directories so that they can be located and loaded.
Tip
Sometimes you need to set up boot disks for different configurations on a system. For instance, some computer games require that only the minimum possible device drivers be loaded to provide the game with enough conventional memory and reduce potential conflicts in the system. If you use boot disks to boot DOS with different configurations, you can dramatically improve your boot time by making sure that any needed device drivers are located on the system's hard disk and that the CONFIG.SYS and AUTOEXEC.BAT files properly reference the device drivers. This way, the system can boot much more quickly than if it had to load the device drivers from the disk itself.
Many device drivers require that the chosen IRQ, DMA, and I/O port addresses be set as part of the device driver load command. A good example is the device driver for supporting a Sound Blaster audio card. The following command is used, for example, for a Sound Blaster 16:
DEVICE=C:SB16DRVCTSB16.SYS /UNIT=0 /BLASTER=A:220 I:5 D:1 H:5
The first part of the DEVICE= statement simply locates and loads the device driver. The next portion of the statement is the /UNIT parameter, which in this case indicates that this is the first installed Sound Blaster. Next comes the /BLASTER parameter, which indicates what resources in the system the card can use. Each resource is identified with a letter, followed by a colon and the chosen setting. The A parameter sets the memory address for the card, and the I parameter sets the IRQ used (often, IRQ 5 is used for sound cards because most systems don't have an LPT2 port, so that IRQ is available). The D and H parameters set the two DMA channels that the card is to use—1 and 5, respectively (the Sound Blaster 16 uses both an 8- and 16-bit DMA channel).
Unfortunately, every device driver requires different parameters and uses a different syntax to specify any needed options. For each device driver you use, you need to examine the documentation that came with the device for the proper syntax to use when loading the device driver.
Generally, you might have problems with a device driver when you install it for the first time, although occasional difficulties can emerge over time if it is incompatible with, say, a new program or an additional device.
If you are having trouble getting a device driver to work initially, you should first suspect a conflict in the device's IRQ, DMA, or I/O memory setting. Depending on the device itself, different conflicts might manifest in different ways. For example, skipping sound coming from a sound card often indicates an IRQ conflict.
If the documentation that came with the device offers no clues on how to determine which resource is conflicting, you will likely have to pursue a trial-and-error approach to changing the settings.
Many versions of DOS come with a program called Microsoft Diagnostics (MSD.EXE) that can help you determine which IRQs are free in your computer. Similarly, some utility programs such as Norton Utilities for DOS also can show you this information, as well as information on what I/O port addresses are in use, and sometimes which DMA channels are in use.
Another route you can take when troubleshooting a new device driver is to disable all other device drivers. You do so by editing the CONFIG.SYS and AUTOEXEC.BAT files from which the system boots. You place the keyword REM (followed by a space) in front of any lines in CONFIG.SYS or AUTOEXEC.BAT that load device drivers. The keyword REM stands for remark and indicates to DOS that the rest of that particular line is to be ignored. After “remarking out” the other device drivers, you reboot the computer to make the changes take effect. The idea here is to simply see whether you can get the device to function properly with a minimal system. If so, you can proceed in a stepwise fashion to re-enable the other device drivers until you find the one that conflicts, and then you will probably have enough information to resolve the conflict. (You re-enable a device by removing the REM from the front of its line in CONFIG.SYS or AUTOEXEC.BAT and rebooting). If you cannot get a device to work even in a minimal system, even after trying a number of alternative settings, the device might not be working or it might have some kind of hardware incompatibility. In this case, contact the manufacturer of either the device or the computer system for further assistance.
For example, consider the following case: You have a system that contains two COM ports (COM1 and COM2) with a modem on COM1, a mouse on COM2, a sound card, a printer on a parallel port, and a CD-ROM drive. You have just installed a network card into the system, and the first time you try to initialize it, the mouse on COM2 stops working, and the new network card doesn't work at all. How do you go about resolving this (unfortunately all-too-common) problem?
You probably suspect some kind of conflict because not only does the network card not function but neither does the mouse. If just the new network card doesn't work, but everything else is fine, you probably suspect a configuration problem of some kind or a broken network card, but not necessarily a conflict with another device. Because you're dealing with a conflict (and assuming that no troubleshooting tools are available for either device to tell you what the problem is), you then proceed to find out whether you can make the network card work if you disable the mouse. To do so, you look in both CONFIG.SYS and AUTOEXEC.BAT to find the device driver that controls the mouse (it can be in either place for mouse devices), add REM to the start of its line, and then reboot the computer.
After taking these steps, you discover that the network card starts working. This is good news because you've now proven that the card works, and you've confirmed that you have a conflict with the mouse. If you have any doubt, you can remove the network card or its drivers and see whether the mouse starts working. If so, you've pretty much proven that you have a conflict.
Now the question becomes, what is conflicting? Is it an IRQ, DMA channel, or a memory I/O port? Here, experience really pays off because over time you develop knowledge of the most likely conflict for any given device. However, as a general rule, you should always suspect the IRQ first—that's where most conflicts occur. Looking at the IRQ table (refer to Table 12.1), you see that the COM2 port, which the mouse uses, makes use of IRQ 3. Looking through the documentation for the network card, you find that its default IRQ is also IRQ 3. Eureka!
Tip
Always remember that manufacturer Web sites can be invaluable resources to troubleshoot and resolve device problems. Usually, they have notes, FAQs, and updated drivers that might resolve your problem. Also, don't forget to check the Web site of the company that made the computer because the manufacturer can also have specific fixes for some devices that, for some reason, conflict only on its computers. For example, when I was beta testing Windows NT 4, I never got it to communicate with the serial ports on my main computer. I figured the problem was a bug that would get resolved before NT was released. Well, when I loaded the released version, it had the same problem! Two weeks later, the maker of the computer I was using came up with an update to its BIOS that resolved the problem because Windows NT had changed how it communicated with serial ports in some basic way.
Now that you've guessed that the conflict is on IRQ 3, you can do one of two things:
You can change the network card's IRQ to another IRQ number.
You can't easily change the IRQs for COM ports, so you can't change the mouse's COM2 IRQ to something else. However, you might consider changing from a serial mouse that requires a COM port to something called a bus mouse that uses its own interface card in the computer (and uses different interrupts from serial mouse devices, too).
You use the same process to work through other types of conflicts, but if changing a device's IRQ doesn't work, you might have to try changing the I/O port address or, if the device uses DMA, its DMA channel.
The following are some general tips for different types of devices that you might have trouble with:
Some systems have add-on serial port cards instead of (or in addition to) built-in serial ports. These cards usually enable you to change the IRQs used for those add-on serial ports. However, be reluctant in changing them because many application programs don't work properly with a COM port that isn't on a standard COM port IRQ.
Some video cards use an extra IRQ. The features that require it aren't very important to the functioning of most software, and you can disable a video card's additional IRQ use.
CD-ROM drives rely on at least two device drivers to function. The first, which is usually part of
CONFIG.SYS, initializes the card that connects to the CD-ROM drive. (Often, it is a driver with ASPI in its name, but not always.) Secondarily, a device driver calledMSCDEX.EXE(Microsoft CD Extensions) is required in theAUTOEXEC.BATfile. The driver inCONFIG.SYSprobably requires IRQ, I/O, and DMA assignments, whereasMSCDEXrelies on other settings that tell it the name of the device defined inCONFIG.SYS, the drive letter to use, and some other features that can improve CD-ROM performance. Make sure that the parameters to both the CD-ROM device driver andMSCDEXare correct per the manual that came with the CD-ROM and CD-ROM interface card.Parallel printers don't rely on DOS device drivers. It is up to each application to work with the printer properly. However, serial-based printers can require that you run the DOS
MODEcommand to properly set the system's COM port to work with the printer. You use theMODEcommand to set the COM port's baud rate, number of data bits, parity, and number of stop bits, and these settings must correspond to switch-based settings on the printer itself. See Chapter 13 for details on using theMODEcommand.Modems also do not rely on device drivers, but they are subject to IRQ conflicts with other devices that probably use device drivers. If a modem isn't working properly, suspect an IRQ conflict with the COM port that the modem uses. Also, check the specific settings in the communications program you are using, making sure that it's set to use the right COM port and that the baud rate is supported by the modem.
Solving device conflicts can, at times, be a frustrating task, and working through all the possible issues takes patience. However, keep in mind that you need to perform all changes and tests in a controlled, stepwise fashion, and use the information presented in this chapter to help you understand possible sources of trouble and ways of dealing with various device problems that might crop up. If you do so, and remember to involve any appropriate manufacturers or vendors and take advantage of the help they can give, you can sort out device problems in short order.