IDE Channels and Resource Usage

The data pathway over which information flows in the IDE/ATA interface is called a channel. Each IDE channel is capable of controlling up to two IDE/ATA devices (including ATAPI devices if they are supported by the BIOS). Despite Western Digital going so far as to define dual IDE channels as part of its enhanced IDE "standard", there has never really been anything barring the use of more than one IDE channel in a PC. It just wasn't regularly done. Before the popularity of ATAPI CD-ROMs, and plentiful and cheap hard disk storage, the vast majority of PCs used one or two hard disks on a single IDE channel, and that was more than enough for most people.

In fact, it is theoretically possible to configure and use as many as four different IDE/ATA interface channels on a modern PC. There is nothing inherently different in concept between these channels, although there can be a difference in terms of how they are implemented. In theory, they are independent system devices, each using their own set of system resources. If configured correctly (so they don't try to use the same resources and therefore conflict), each IDE channel can behave basically independently.

This table shows the names of the four standard IDE channels, and the resources used by each:

Channel

IRQ Used

I/O Addresses Used

Popularity and Support

Primary

14

1F0-1F7h and 3F6-3F7h

Used by all PCs using IDE/ATA

Secondary

15 (10)

170-177h and 376-377h

Common, built-in on most newer PCs

Tertiary

11 (12)

1E8-1EFh and 3EE-3EFh

Used uncommonly, can have software support problems

Quaternary

10 or 11

168-16Fh and 36E-36Fh

Very rarely used, can have software support problems

As you can see, each IDE channel requires both an interrupt request (IRQ) line and two ranges of I/O addresses. The first two IDE channels are pretty much standard among all newer PCs, as are the resources that they use. IRQs 14 and 15 are generally reserved on most systems for use by the primary and secondary IDE channels, and most newer PCI motherboards have support for both of these channels built into the chipset and BIOS, so there are two IDE connectors on the motherboard, one for the primary channel and one for the secondary. Most operating systems and other software "know" about these two channels, and software problems or resource conflicts with them are rare. With the exception of SCSI host adapters, it is hard to even find an expansion card that will use IRQ 14. (SCSI host adapters can replace IDE entirely in a PC so having them be able to use IRQ 14 can make some sense.)

The tertiary and quaternary channels are far less frequently used, and software issues with them are far more frequent. There are also resource issues to be addressed; the IRQs used by the third and fourth channels can also be "claimed" by other peripherals such as sound cards, network cards and even PS/2 style mice. The I/O addresses they use can conflict with network cards, COM ports, and other devices.

While most newer systems have the primary and secondary IDE controllers built into the motherboard, they don't all implement both channels identically. The better systems include full transfer mode support and bus mastering for both the primary and secondary channels, but some systems--especially older ones--wimped out and in order to save a few bucks, included support for the faster PIO modes (3 and 4) only on the primary channel, meaning that the secondary channel will only run at the lower PIO modes (0, 1 and 2). The idea was that the primary channel would be used by the main hard disks (fast) and the secondary channel by extra, older hard disks and ATAPI devices (slow). Really, having full support on both channels is a much smarter idea, and that is the current trend.

Using the tertiary and quaternary channels requires that additional controllers be added to the two built into the motherboard (or provided by the existing controller or controllers). The most common way that a tertiary channel is introduced into a PC is through the use of a sound card. Most SoundBlaster and compatible sound cards include an IDE controller that can be configured to implement an IDE channel. There are two reasons for this: first, sound cards are commonly sold in "multimedia kits" that include ATAPI CD-ROMs, and so this provides a place for them to be attached. Second, the first CD-ROMs were attached to proprietary (non-IDE) ports on early sound cards, so the trend has continued for historical reasons.

The use of a sound-card-based IDE channel can be a perfectly acceptable way to connect an IDE/ATA or ATAPI device to the system, but there are some cautions here. If the sound card is attached to the ISA bus (which most are), then the IDE controller is also on the ISA bus. This means that the use of faster PIO modes or IDE bus mastering is out, because of the low bandwidth of the ISA bus.

You can also buy expansion IDE cards (often called EIDE cards). These can also usually be set to act as tertiary or quaternary IDE controllers, allowing the use of more than four IDE/ATA devices.

Software support for the tertiary and quaternary IDE channels is not nearly as consistent as it is for the primary and secondary channels. For example, Windows NT 4.0 will not recognize an IDE device attached to the tertiary IDE channel. Most BIOSes also only have space to set up four IDE/ATA/ATAPI devices. This means that using a tertiary IDE requires some sort of driver or add-in BIOS support.

For most people, using the primary and secondary IDE channels is enough. If you have five devices and one is a CD-ROM drive, putting the CD-ROM on the tertiary channel and running it with a CD-ROM driver will work fine for most uses. If you have enough devices that you really need a quaternary channel, you should probably consider "consolidating" your hard disks into one larger one (for performance reasons if nothing else), or moving to SCSI.

Note: The I/O address range for the slave device on the primary IDE channel actually overlaps with the standard address range for the floppy disk controller. This is in fact not a conflict since this overlap is well known and accounted for.

Next: The IDE Cable