Device Addresses

[#ioportad]: Input/Output (“I/O”) port/address

The port addresses are commonly called an I/O port, or an I/O address, or perhaps even an “I/O port address”. (Well, “commonly” when they are being referred to, which may be less common now that such settings are often automatically assigned so end users typically don't need to mess with these sort of settings).

The standard is that these are displayed in hexadecimal. So the addresses may often be prefaced with 0x or suffixed by a lowercase h. This may look very similar to how memory addresses are referenced by an assembler. However, an answer to v123's SuperUser.com question about port addresses and RAM indicate that I/O addresses use a separate address space than RAM. In other words, the similarity can be thought of as coincidental. The old 8088 CPU accessed I/O memory addresses different than RAM.

Each device should use its own I/O address port. To see the I/O memory addresses or I/O memory address ranges, try one or more of the following approaches.

Wayback Machine @ Archive.org Cache of PC 99 Design Guide Appendix D: “Legacy Support” mentions some common locations.

Determining what is using an I/O port address

(This may be similar in nature to the topic about detecting hardware.)

Determining I/O port address usage in Microsoft Windows
Using Device Manager to identify what uses a specific I/O address (range)
In Windows Vista...
Choose the View menu within Device Manager. Then choose “Resources by type”. Expand the “Input/output (IO)” category. This will show the address ranges, which may be a small number of addresses (e.g. 0x70-0x73 for “System CMOS/real time clock”) or a larger number (e.g. 0-0xCF7 for “PCI bus”, which is 3,320 addresses). On Windows Vista 64-bit, each of these addresses may be shown as 16 hexademical digits (with leading zeros), although perhaps only the last four hexadecimal digits are ever possibly non-zero.
Win9x

(These directions are written from memory, and might be a bit off...)

From Device Manager, find the “Computer” object. (This object/category, called “Computer”, may be the first object underneath the top-most object that is named after the computer's name.) Access the context/shortcut menu of that object (user interface basics: context menu describes easy methods), and choose Properties. Perhaps then use a View menu?

From the System Information Tool

Directions for how to run the System Information Tool vary between operating systems. An option may be to run “ %SystemRoot%\system32\msinfo.exe ” or perhaps “ MSinfo32.exe ”.

Within the “System Summary”, in the “Hardware Resources” category, see a (sub-)category called “I/O”. This interface may show address ranges with eight hexadecimal digits, possibly resulting in all addresses starting with at least four leading zeros.

[#irq]: Interrupt Request (“IRQ”)
IRQs with ISA
No sharing

Sharing IRQs on an ISA bus can lead to problems communicating with a device, including system lockups (especially when the device is being used, or detected). OpenBSD FAQ 12: Section about IRQ sharing says, “ISA devices can not share IRQs. If you find ISA devices sharing IRQs, you must correct this problem.” The problem is not if a device is using multiple IRQs (especially if a single device seems to be using IRQ 2 and IRQ 9), but rather if multiple devices are trying to use one IRQ.

[#irqshar]: Sharing interrupts

Note: IRQ sharing may be very commonplace using new PCI/PnP systems.

(Note that even though the “PCI Express” standard may not be compatible with PCI cards on a hardware level, the “PCI Express” standard does use at least some of the same hardware communication protocols as the older “PCI” standard. That was a key reason why the “PCI Express” standard used the term “PCI” as part of its name. The things that the following text says about PCI are not necessarily limited to just the older PCI standard.)

In fact, OpenBSD FAQ 12.1.1: PCI Devices states, “Interrupts can be shared on the PCI bus. Not only can they be, the system will often perform better when the IRQs are shared, especially on i386 systems.” OpenBSD FAQ 12.8.3: multiple devices sharing an IRQ states that sharing IRQs on PCI devices “is entirely acceptable, and in fact, even desirable”. That page goes on to state, “This is a design feature of the PCI bus. Some people will say that sharing interrupt requests (IRQs) is bad, however they are either confusing the situation with the ISA bus (where IRQ sharing is not permitted), or past experience with broken hardware or software.”

Some further information has been provided for those who want lots of technical details. Sharing IRQs on PCI devices is described further on page 3 of “Running and tuning OpenBSD network servers in a production environment” (PostScript file), by by Philipp Bühler and Henning Brauer, which has been released as a PostScript file. (People can use a PostScript reader, such as a PDF reader, to view this file most nicely.)

However, The Linux Documentation Project (“TLDP”): Plug and Play HOWTO: Chapter 7 “PCI Interrupts”: “Sharing PCI Interrupts” section states, “PCI interrupts may be shared, meaning that two or more PCI devices will generate the same IRQ. If feasible, it's usually better not to share.” Reading that article further, the provided reason seems to be to increase compatability with some old poorly designed hardware. The recommendations by The Linux Documentation Project (“TLDP”) may have been more focused on getting things functional, even with some old, picky hardware. In contrast, that same troublesome hardware may be what the OpenBSD team was referring to in the statement about “past experience with broken hardware or software.” By “broken”, the OpenBSD team probably didn't necessarily mean that the hardware couldn't work, but simply that it used a poor design. So, OpenBSD's comment (about sharing IRQs being desirable) is probably accurate for obtaining maximum (speed) performance when that approach worked.

However, some of that analysis may have reached conclusions by using a bit of speculation. Different operating systems may behave differently, and so the best advice for experiences with one operating system is not necessarily the best approach (or even a decent approach) for another operating system. The different comments by The Linux Documentation Project (“TLDP”) and the OpenBSD team might be due to differences in the attitudes and preferences of the documentation authors, or might be due to different ways that the operating systems handle things. The author of this text cannot, at this time, rightly say which is true.

It is for this reason that the author of this text recommends trying to have hardware and software use automatic resource assignment as much as possible. Instead of trying to manually control every minor detail, simply let the designers of the hardware and software sort out what's best.

It is mainly when using ISA that IRQ uniqueness ended up being so important. Actually, the “Running and tuning OpenBSD network servers in a production environment” (PostScript file), by by Philipp Bühler and Henning Brauer indicates that IRQ sharing may even be possible on an EISA bus. IRQ sharing became far more common on PCI buses.

Painful example

With the OS/2 operating system, some hardware might need an IRQ for OS/2 native mode, and also an IRQ with DOS mode. This was particularly troublesome for a Pro Audio Spectrum 16, as the Sound Blaster compatibility was often more useful (because it was more widely supported) than the native PAS16 command set. To enable the Pro Audio Spectrum 16's Sound Blaster compatibility for DOS programs in OS/2, four IRQs could be required for full functionality. Yeouch! An IRQ was needed for the PAS16 command set in OS/2, and an IRQ was needed for the PAS16 command set for DOS compatibility, and an IRQ was needed for the OS/2 driver to support the Sound Blaster circuitry, and a different IRQ would be needed for DOS compatibility. As can be seen in this documentation, there aren't necessarily very many IRQs available so requiring four IRQs was a very hefty requirement. Using Sound Blaster compatability, in a game designed to run in DOS, was a fairly common scenario back in the day. Although using up so many IRQs for a single card could typically be done, the usage of so many IRQs could prevent the system from having enough resources to be able to support some other hardware.

Cascading

At least on an ISA system, if IRQ9 exists, IRQ2 is used to “cascade” to provide access to IRQ 9 through IRQ 15, and so it may be somewhat common to see IRQ 2 and IRQ 9 looking like they are somehow using the same device. This is generally NOT a problem. Some software may prefer to use a reference to IRQ9 while other software may prefer to be configured to use IRQ2, but one of those two IRQs will likely work flawlessly. (If IRQ9 is supported, choosing to use IRQ9 would be more likely to be preferable, even if the hardware is set to use IRQ 2. Any software that supports using IRQ9 will generally work properly with the hardware by using IRQ 9.)

Standard usage

Certain IRQs are always assigned certain values. Here's a chart of certain and common settings.

IRQ 0 (IRQ zero)
System timer. This IRQ is unconfigurable.
IRQ 1
Keyboard. This IRQ is unconfigurable.
IRQ 2

On systems that have 15 IRQs, this is used for Cascading. It is often harmlessly confused by software with IRQ 9. On systems with only 8 IRQs, this is simply a usable IRQ. For details on what may commonly use that IRQ, see the documentation about IRQ 9.

IRQ 3
Often used with I/O address 0x2F8 (or 0x2F8 through 0x2FF) for COM2. Sometimes is used with I/O address 0x2E8 (or 0x2E8 through 0x2EF) for COM4. Note, though, that COM4 should generally be set to use IRQ10 if possible (if that doesn't conflict with the hard drive controller, which should generally be using IRQ15 if possible). Note that many ISA modems were shipped to use COM2 by default.
IRQ 4
Often used with I/O address 0x3F8 (or 0x3F8 through 0x3FF) for COM1. Sometimes is used with I/O address 0x3E8 (or 0x3E8 through 0x3EF) for COM3.
IRQ 5
Often used with port 0x278 to provide an LTP port. If only one LPT port was detected, then this would be LPT2 (and 0x278 is often documented as being the default address for LPT2). If LPT2 was configured already, then 0x278 is typically LPT3. Newer Sound Blaster cards often used this (most commonly with port 0x220 or 0x240, although other I/O addresses were commonly configurable).
IRQ 6
Floppy Disk Controller. The idea of assigning an IRQ to this slow device is that the device might be even slower if it can't use an IRQ. Generally not configurable. The floppy disk controller may also be responsible for using up DMA channel 2.
IRQ 7

Typically set to be used with a parallel port. This is often documented as being related to LPT1. (However, see the section about LPT ports for the full story.)

Also the default IRQ used by the original Creative Labs Sound Blaster card (which used I/O port 220h by default) was IRQ 7. However, newer sound cards compatible with the Sound Blaster often used IRQ5. If the sound card may be re-configured to use IRQ5 instead, that is generally preferable.

IRQ 8
Real-time clock. Not generally configurable.
IRQ 9

This is generally a usable IRQ, although don't try to overlap it with IRQ2. (Any one device that can use the IRQ may use either IRQ 9 or IRQ 2. There should not be any second device should using either IRQ 9 nor IRQ 2. The limit is a maximum of just one device.)

LPT1 is generally set to use a parallel port at 0x3BC if there is one. Wikipedia's article on “Parallel port”: section on Port addresses on IBM personal computers indicates this would use IRQ 2 by default. So, that would be the same as IRQ 9 on systems that support more than 8 IRQ channels.)

This may be a default IRQ for NE2000 cards at 0x240 or 0x280 (noted by: OpenBSD Manual Page for NE2000, OpenBSD FAQ 12: Hardware, section on ISA NICs)

IRQ 10

COM4

This may be a default IRQ for NE2000 cards at 0x300 (noted by: OpenBSD Manual Page for NE2000, OpenBSD FAQ 12: Hardware, section on ISA NICs)

IRQ 11
Possibly COM3, or possibly a tertiary IDE channel
IRQ 12

This is used by the “PS/2”-style mouse port. Once that standard port became available, it became the generally method of getting rodent input. It remained the generally preferred method of rodent input until USB mice started to become widely supported by both hardware and popular operating systems.

The basic difference between a PS/2 mouse port and a PS/2 keyboard port is just that the PS/2 mouse port uses IRQ 12. Keyboards do not need to use the IRQ, but rodents do. (Therefore, the half-green and half-purple PS/2 ports, colored in a way to indicate that it may be used is a mouse port or a keyboard port, does not operate any different than a PS/2 mouse port.)

IRQ 13
Used by a “math coprocessor” or, more commonly, the circuitry within a CPU that provided the same functionality as the old “math coprocessor” add-ons. Even on an old system that isn't using a math co-processor, devices generally never supported using this.
IRQ 14
Primary IDE Hard Drive Controller. Not all HDD controllers would use this, but many newer ones did, making the IRQ unavailable for other devices.
IRQ 15
Secondary IDE Hard Drive Controller. Not all HDD controllers would use this, but many newer ones did, making the IRQ unavailable for other devices.

As can be seen, IRQs 0, 1, 2 (if 9 is available), 6, 8, and 13 are not usable except for very specific, non-configurable purposes. IRQs 12, 14, and 15 may often be used for very specific purposes. If a sound or video or network card, or a modem, needed an IRQ, some fairly common choices could include 3, 4, 5, 7, 9, 10, or 11. Of those, all are often used by a COM port or an LPT port. Yeeps. Looks like if a network card is going to be used, then choices may need to be made. (The most common choice would likely be to not use LPT3, perhaps followed by LPT2 and then COM3 and COM4.)

IRQs on newer systems

OpenBSD FAQ 12: Section about PCI (FAQ 12.1.1) says, “Interrupts can be shared on the PCI bus. Not only can they be, the system will often perform better when the IRQs are shared, especially on i386 systems.” OpenBSD FAQ 12: Section about IRQ sharing says, “This is entirely acceptable, and in fact, even desirable for PCI devices. This is a design feature of the PCI bus. Some people will say that sharing interrupt requests (IRQs) is bad, however they are either confusing the situation with the ISA bus (where IRQ sharing is not permitted), or past experience with broken hardware or software.” The feature of being able to share IRQs may be known as IRQ Steering (as noted by Microsoft KB Q238096: Problems Shutting Down Windows 98 Second Edition). Some early motherboards that had PCI connectors were “broken” in this fashion: PCI and/or Plug-n-Play support may not have been very good. Upgrading the motherboard's flash might help in such a case. (Moving the card to another slot has been rarely, but sometimes, known to help cards work with such older motherboards. Perhaps the reason was IRQ-related or I/O port address related?)

Although ISA was rather strictly limited to 16 IRQs, numbered 0 through 15, and even that was only possible after cascading raised the limit from 8 IRQs (labeled 0 through 7), PCI may have many more IRQs. Three digit IRQ numbers are not uncommon to see. Sometimes a negative signed IRQ may be reported. If such an IRQ number is shown as an unsigned value, a very large number may be seen. For instance, IRQ -2 (signed) would be equivilent to IRQ 4,294,967,294 (unsigned). Similarly, IRQ -3 (signed) would be equivilent to IRQ 4,294,967,293 (unsigned).

Seeing IRQ values
Linux
View /proc/interrupts as if it were a file. (e.g., use “ cat /proc/interrupts ”), or try a program called procinfo. (This is based on information from Wikipedia's page on Interrupt request: section about x86 IRQs.)
Microsoft Windows

To see the values, use some of the software that reports I/O port addresses but look for an option to deal with IRQs. “ WMIC IRQ GET ” may show the IRQs (but not provide much further interesting details).

DOS
See if MSD came with MS-DOS or Microsoft Windows.
[#dirmemac]: Direct Memory Access (“DMA”)

On an ISA system, there may be a limited number of DMA channels. Devices should not share DMAs.

DMA 0
Wayback Machine @ Archive.org Cache of PC 99 Design Guide Appendix D: “Legacy Support” identifies DMA 0 as being used for “ISA expansion”. Wikipedia's article about Direct Memory Access (“DMA”): section about ISA indicates DMA 0 may be assigned to “DRAM Refresh”. Experience has shown that many devices do not support DMA 0. Therefore, this would seem to be a great choice, as it would be less likely to conflict with other devices that may not have support for this. However, trying to actually use DMA 0 may or may not work very well in various computers.
DMA 1

Sound cards compatible with Creative Lab's Sound Blaster would traditionally use DMA 1 with I/O port 220. (However, this was generally configurable so other options, at least involving DMA 3 and port 220, could also be used.)

DMA 2
Like IRQ6, this may commonly be reserved for use by the floppy drive(s) (or perhaps the “floppy drive controller”, which is the circuitry that communicates with floppy drive(s) and is on the motherborad or on a card in an expansion slot on the motherboard).
DMA 3

Wikipedia's page on IEEE 1284 (LPT parallel printer ports): “Specifications section” says “usually ISA DMA on channel 3” was used for Extended Capacity Port printer/parallel LPT ports.

Sound Blaster sound cards typically used DMA 1 with I/O port 220, while secondary sound card settings typically used DMA 3 with I/O port 240.

DMA 4
Wikipedia's page on Direct Memory Access: section about ISA says “channel 4 is unusable”. This may be used for cascading with an older style of DMA controller that only supported DMA 0 through 3.
DMA 5
Widely available to many systems other than IBM PS/2 systems that used this for a hard drive controller
DMA 6
Available
DMA 7
Available
[#comport]: COM ports

There have been some reserved filenames that are related to the COM ports. From a software perspective, a COM port is really nothing more than a combination of an I/O address and an IRQ. The most common settings are:

COM1: IRQ 4, Address 3F8, or 3F8 through 3FF.
COM2: IRQ 3, Address 2F8, or 2F8 through 2FF.
COM3: IRQ 4, Address 3E8, or 3E8 through 3EF.
COM4: IRQ 3, Address 2E8, or 2E8 through 2EF.

RTTY Ver 3, Pt III: Serial Port Expansions (archived by the Wayback Machine @ Archive.org) says, “There are no standards for IRQ or Address for COM5-COM8 yet. The Flexport 42 provides the standard addresses plus 4 more (340, 290, 180, 100).” Actually, according to an earlier chart, it looked like those were listed in reverse order, so COM5 was 100 (IRQ 11), COM6 was 180 (IRQ 12), COM7 (IRQ 15) was 290, and COM8 was 340 (IRQ 10), with COM4 using IRQ5 and COM3 being unused (in a chart showing a system actually using these COM ports).

Despite there being no standard up through COM8, MSDN Guidelines for naming Files, Paths, and Namespaces (in Microsoft Windows) lists reserved (DOS) filenames for COM ports up through COM9.

A variety of devices could use a COM port (which being an I/O address and an IRQ, can be thought of as a “software” interface rather than a physical connection, but the most common hardware things that used COM ports were probably hardware serial ports (either DE-9 ports or the earlier DB ports), or internal dial-up modems.

[#lptport]: Line Printer Terminal (“LPT”) Parallel Ports

These were basically the standard connector on computers for connecting to printers, and some other devices (most especially scanners), prior to USB. The parallel communication happened at speeds that were low enough that crosstalk wasn't so big of an issue. The ports eventually stopped appearing on most new computers, mainly because newer equipment chose to instead support USB. The primary motivation for going from parallel port to USB was probably the speed benefits of USB communications.

Color

Typically the port was black, perhaps followed by shite, until the PC99 color coding (Wayback Machine @ Archive.org's cache of PC 99 System Design Guide: Chapter 3 (“PC 99 Basic Requirements”) section 3.18: “"Connections use icons, plus keyed or shrouded connectors, with color coding”, and specifically the table in sub-section 3.18.3) specified Burgundy (purple, pantone 235C, as noted by Wikipedia's article on “PC System Design Guide”: “PC 99” documentation). Nicely that color change happened due to the same standardization effort that introduced the newer computing modes of ECP and EPP, so the Burgundy connectors are often a pretty good indication that a port supports the newer modes.

Modes

There are multiple standard “modes” of communication. Wikipedia's article on IEEE 1284 (Printer Ports): “Specifications” section says, “IEEE-1284 requires that bi-directional device communication is always initiated in Nibble Mode. If the host receives no reply in this mode, it will assume that the device is a legacy printer, and enter Compatibility Mode. Otherwise, the best mode that is supported on both sides of the connection is negotiated between the host and client devices by exchanging standardized Nibble Mode messages.” A parallel port configured to be an Extended Capability Port (“ECP”) may be the fastest of these options, using up a DMA port in order to help achieve more speed and/or less overhead than a parallel port acting in “Enhanced Parallel Port” mode. The only real reason not to use ECP instead of EPP is if there isn't a free supported DMA channel number. Otherwise, using EPP is the next best option and does not generally cause any problems.

Port addresses

LPT1 is generally set to use a parallel port at 0x3BC if there is one. Wikipedia's article on “Parallel port”: section on Port addresses on IBM personal computers indicates this would use IRQ 2 by default. (That would be the same as IRQ 9 on many systems.)

However, generally there is not a parallel port set up at 0x3BC. Then, port 0x378 is checked. If LPT1 has not been assigned yet, which is typically the case, then LPT1 gets assigned to 0x378. This is so common that 0x378 is generally documented as the I/O address for LPT1. However, if LPT1 is already assigned to 0x3BC, then LPT2 gets assigned to 0x378, despite the fact that LPT2 is generally documented to be at IRQ5 and 0x278.

Then, a check is made for a parallel port responding to I/O address 0x278. If there is one, then it may commonly be assigned the name LPT1 if that name hasn't been assigned. Otherwise, that I/O address may often be assigned the name LPT2 if that hasn't been assigned. Since there is usually not a parallel port at 0x3BC by default, but there usually is one at 0x378 by default, LPT2 is often documented as being assigned to 0x278 (and IRQ 5). However, if both LPT1 and LPT2 were already assigned, then 0x278 may be assigned the name LPT3.

(This is largely based on information read from Beyond Logic: Introduction to Parallel Ports and Luberth mirror of Beyond Logic's page (both of which seem to have the same typo, referencing 378h as LPT1 instead of LPT3). However, this doesn't seem to conflict with known standard experiences. Wikipedia's article on “Parallel Port” (referencing version from Sept 28, 2011): 5th Citation Reference seems to indicate this behavior as well.)

Port documents LPT4 through LPT7 as having default addresses of 368, 268, 358, 258.

[#dvnamspc]: Device Namespace

For information about what hardware is detected, see the section about hardware. The names assigned to hardware is entirely a decision made by software, although often the names that software assigns may have references to hardware details. For instance, the name of a file system in a partition on the hard drive may be influenced by the type of connector that the hard drive is using to communicate to the hard drive controller it is using.

Unix

Devices may often be shown on /dev/ which is often using a file system type called devfs.

Names of drives

See: creating a filesystem: destination name for a discussion about the names of data storage device objects.

Microsoft Windows

Devices may show up under the \Device heirarchy. (Though this syntax looks like a subdirectory, the fact is that this sort of name is not part of any hard drive's file system.)

Hard drives and partitions

Information on this topic has become substantially lengthy, enough to justify having this information moved to its own sub-section. See: Windows \Device : hard drives and partitions.

[#dosdevnm]: Device names in DOS

A path in DOS can start with a drive letter, such as “C:”. These drive letters work like a “mount point”. Every drive letter has an associated “current” directory (or, to use a term that may be more familiar with people who have used Unix, a “present working directory”). The drive letters are relative, so “C:” is the same thing as “C:.”, and the parent directory of “C:.” can be referenced by “C:..” (with the possible exception of a root directory for the drive, as it may not have a parent directory). DOS uses backslashes to separate folders, so the root directory of each drive has a name such as “C:\”.

DOS also has devices that act similar to files. The names of the devices exist in every single “current” directory. MSDN Guidelines for naming Files, Paths, and Namespaces (in Microsoft Windows) lists the following reserved names (without descriptions): CON (which refers to the “console” used for standard input and standard output), PRN (which is for a printer, and typically maps to LPT1), AUX, COM1 and COM2 and COM3 and COM4 and COM5 and COM6 and COM7 and COM8 and COM9 (which refer to communications ports which are called COM ports), and device names decicated to “Line Printer Terminal” (“LPT”) ports, which are the names LPT1 and LPT2 and LPT3 and LPT4 and LPT5 and LPT6 and LPT7 and LPT8 and LPT9.

In addition to all these names, MSDN Guidelines for naming Files, Paths, and Namespaces (in Microsoft Windows) notes, “Also avoid these names followed immediately by an extension; for example, NUL.txt is not recommended.” (The handling of these filenames have historically been known to have some bugs, which have led to security vulnerabilities.)

(after device namespace)