Plug and Play in PC DOS 7

From Wiki
Revision as of 22:50, 15 November 2019 by Jugbogdan (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation

By Mark Gehring and Kamal C. Patel

Plug and Play technology lets you install and configure peripheral devices in a computer system. This article first covers Plug and Play components, then details how PC DOS 7 implements Plug and Play support.

Configuring a device in a computer can be a complicated task. Installing a card can be a time-consuming, technical process. You might have to configure the system by setting hardware jumpers to rearrange interrupt request (IRQ) lines, direct memory access (DMA) channels, base I/O, memory address space, and communication ports. In addition to making these manual changes to the hardware, you might also have to edit system software files. Mobile systems, in particular, demand greater hardware and software integration in order to dynamically insert and remove devices and docking support.

To address these problems, the Plug and Play (PnP) architecture has been defined by a group of companies including Compaq, Intel, Microsoft, and Phoenix Technologies. Plug and Play defines a way for peripherals to communicate with a machine's BIOS and operating system and to resolve resource conflicts with little user intervention. You don't need to be concerned about DMAs and IRQs; device installation is automatic - just plug the device in, turn on the system, and it works.

Architecture and Components Overview

Figure 1 shows the general structure of the Plug and Play architecture.

Figure 1. Plug and Play Components

Plug and Play BIOS

System BIOS addresses two key areas to furnish plug and play capabilities: Resource management and runtime configuration.

Resource management provides the ability to manage system resources, which include direct memory access, interrupt request lines, and I/O and memory addresses. After the power-on self-test (POST) process ends, the BIOS, which maintains a list of system board device configuration information, communicates this information to the operating system. Each device is associated with a unique identification code that the operating system recognizes.

The BIOS also provides configuration services, known as runtime services, for system board devices even after the POST process is complete. The BIOS must be able to notify the operating system of dynamic configuration events, such as removing or inserting a PCMCIA card, or docking and undocking a notebook in a docking station. The Plug and Play BIOS specification provides a mechanism whereby a Plug and Play operating system can allocate resources during runtime.


Plug and Play Operating System

To provide complete Plug and Play functionality, the operating system requires the following components:

  • Configuration manager - The configuration manager is the software that controls the configuration process and communicates with all components involved in that process.
  • Hardware tree - The hardware tree contains a database of information used to configure the system.
  • Bus enumerators - The bus enumerator identifies all the devices on a particular bus and their resource requirements.
  • Resource arbitrators - The resource arbitrator allocates resources among all devices.

Each of these components is now discussed in turn.

Configuration Manager

The configuration manager starts the configuration process upon receiving either the system board device configuration list from the BIOS or a notification of a dynamic configuration event from either the BIOS or from one of the bus enumerators.

To establish a working configuration for the system, the configuration manager coordinates the communication between the bus enumerators, hardware tree, device drivers, and resource arbitrators. For each device, the configuration manager loads a driver and instructs it to await assignment of specific resources. In case of a conflict, the configuration manager performs an interactive process of reconfiguration until a working configuration is determined. The configuration manager also informs the device drivers and applications of any pending or present changes in the system layout.

Hardware Tree

A record of the current system configuration, known as the hardware tree, is stored in the random access memory. This record is created every time the system boots or a runtime change occurs to the system configuration.

A central database, from which the tree information is drawn, contains configuration information for all devices, whether or not they are currently installed. From the central database, applications and drivers can get the information about alternate configurations, software required to operate these devices, and user-defined settings.

Bus Enumerators

The bus enumerator is a type of driver required for each specific bus type and is responsible for building the hardware tree.

A bus enumerator identifies the devices on that bus by assigning a unique identification code to each device. It also reads the devices' resource requirements, retrieves the device configuration information either directly from the device or from the central database, and configures the devices as instructed by the configuration manager.

Resource Arbitrator

The resource arbitrator allocates specific types of resources to devices and resolves conflicts between devices that request identical resource assignments. The resource arbitrator interacts with the configuration manager by assigning resources both at system startup and during dynamic configuration events.

Device Drivers

Plug and Play device drivers register with the configuration manager when they are initially loaded. They remain inactive until they are given their resource assignments, then they are able to communicate with applications and respond to dynamic configuration events.

Plug and Play SCSI

Plug and Play small computer system interface (SCSI) host adapters will configure like any other board, but configuring the individual devices on the SCSI chain requires an extension to the basic Plug and Play scheme.

Microsoft and SCSI adapter vendors have collaborated to produce such an extension, which is called SCSI Configuration Auto Magically (SCAM). SCAM requires additional firmware on SCSI adapters and devices. During the boot process, a SCAM-complaint SCSI subsystem allocates SCSI addresses to avoid conflicts. SCAM also handles SCSI termination (indicating which devices are at the ends of the SCSI chain). Older, non- SCAM-complaint devices still must be configured with software updated to handle SCAM devices.

Plug and Play ISA

The Plug and Play industry standard architecture (ISA) specification, developed jointly by Intel and Microsoft, allows software configuration of add-on ISA boards, eliminating the need for hardware jumpers or DIP switches.

Plug and Play ISA boards have unique 72-bit serial IDs that differentiate one PnP ISA board from another. The serial ID contains a manufacturer ID, a product ID, and a serial number.

PnP ISA boards are placed in an isolation state during power-up. The PnP ISA boards arbitrate for the bus, and the board with the largest ID wins. Once a PnP ISA board has won isolation, the other PnP ISA boards drop off.

The system then assigns a card select number (CSN) to the newly isolated board. The CSN is used to single out individual boards later, without performing the isolation sequence again. Once a board has been assigned a CSN, it no longer participates in the isolation sequence, and isolation of PnP ISA boards with lower serial IDs proceeds.

Backward Compatibility

The Plug and Play architecture must provide compatibility with the installed base of existing (non-PnP) systems and peripherals. PnP components must be able to accommodate the lack of device-reporting mechanisms for non-PnP devices. Information about such devices must be stored in the system, and devices that cannot be software-configured must receive first priority in resource allocation. When unresolvable conflicts occur, the system should guide you through device-configuration options.

Plug and Play devices will work on current systems that do not have either a Plug and Play BIOS or a Plug and Play operating system. A configuration utility separate from the operating system must be installed. When the Plug and Play device and its new driver are installed, the system will be able to automatically configure the new device.

Plug and Play Support in PC DOS 7

The rest of this article details Plug and Play support in PC DOS 7.

Docking Support

Docking is the process of connecting a mobile computer to a docking station and subsequently accessing the additional docking station system resources such as CD-ROMs and hard disks. Undocking is the process of disconnecting the mobile computer from the docking station. To perform docking and undocking events, both the docking station and the mobile computer must be Plug and Play-enabled.

PC DOS 7 provides cold, warm, and hot docking support for mobile users who have Plug and Play-enabled hardware. Depending on what is connected to the docking station, PC DOS 7 docking support may eliminate the need to reboot the docking station when the mobile PC is docked.

In cold docking, the system must be rebooted when a mobile PC is docked so that it can recognize its newly associated peripherals. PC DOS 7's cold docking support is enhanced with the multi-configuration support implemented in PC DOS 6.x.

During warm docking a mobile PC is in a suspended state, and many if not all of the associated peripherals are recognized and activated.

In hot docking, a mobile PC is fully active when docked, and many if not all peripherals are recognized and activated.


The DOSDOCK utility enables mobile computer users to use either hot or warm docking. Executed at the DOS command line, the DOSDOCK utility loads and remains resident, waiting for a docking or undocking event. When the event occurs, DOSDOCK examines the environment for the parameters and (depending upon the plug and play interrupt received) tells DOS to dock or undock.

Docking support cannot be activated while running Windows. However, PC DOS 7 notifies you, in a pop-up Windows message, that you must shut down Windows to allow DOSDOCK to begin.


To provide communication between the PC DOS 7 docking support programs, some new multiplex interrupt functions are defined. The application programming interfaces (APIs) in Figure 2 are defined and used for docking support in PC DOS 7.

Figure 2. PC DOS 7 APIs for Docking Support
INT 2Fh Function 2000h

Check DOSDOCK Installation

This function allows the caller to determine whether the DOSDOCK program is resident. AX = 2000h
AL = 00h DOSDOCK program not installed
AL = FFh DOSDOCK program resident
INT 2F Function 2001h

Get Docking Event

This function allows the caller to determine if a docking event has occurred. An application can use this interrupt to determine if a docking event has occurred, rather than polling the PnP BIOS. After making this call, the event flag is reset to 0. AX = 2001h
AL = 00h no event
AL = 01h docking event occurred
AL = 01h machine is docked


The DYNALOAD command allows you to dynamically load a device driver from the DOS command prompt without modifying the CONFIG.SYS file and restarting the computer. The DYNALOAD utility does not run under Windows virtual DOS machine (VDM) mode or while a task swapper is active.

The PC DOS 7 Command Reference lists the drivers shipped with PC DOS 7 that are supported by DYNALOAD. However, DYNALOAD may work with other device drivers. Because there are no standards for loading DOS device drivers after the CONFIG.SYS file is processed, the only way to know if DYNALOAD works with a particular device driver is to try loading that driver. If it is not compatible, you will get an error message.

DYNALOAD cannot load block device drivers or drivers that require DOS system initialization or execution via the CONFIG.SYS file.


The DDPOPUP program provides DOS docking support under Windows. When Windows is running and DOSDOCK is loaded, a pop-up Windows message notifies you that the dock or undock event has occurred, and instructs you to shut down Windows to allow DOSDOCK to function.

DDPOPUP uses the standard Windows user interface to display the pop-up message under Windows. The DDPOPUP program executes as a command-line parameter passed to Windows through the Windows Startup group or by executing it via the RUN option.

Hardware Requirements

To provide complete Plug and Play functionality, a system must incorporate all three Plug and Play system components: BIOS (motherboard), devices (buses), and operating system. However, partial Plug and Play functionality can be provided in systems that include one or two of these components.

Plug and Play expansion cards require a special programmable logic device (PLD) or modifications to an existing application-specific integrated circuit (ASIC) to support basic handshaking functions. The PLD or ASIC lets the device communicate a unique identification number and list the resources it requires and can support.

The major incremental benefit of having a system with complete Plug and Play components is the ability of that system to dynamically respond to configuration events.

Future of Plug and Play

The goal of Plug and Play architecture is to easily install and configure new devices. With a PnP system, inserting and removing certain devices such as PCMCIA cards or connecting and disconnecting from a docking station is simplified without restarting the system.

Plug and Play will eventually provide a mechanism for hardware to communicate configuration changes to device drivers, and then to applications software. Forcing a notebook computer to save a file before it is removed from a docking station is an example of this capability.

Plug and Play shows great potential. It is compatible with existing hardware, and if all the pieces come together in the future, expanding your system may indeed become as simple as plugging in a card and turning on the machine.


  • Microsoft Backgrounder: The Plug and Play Framework, September 1993.
  • Howard Alexander. "Plug and Play: Easy Upgrades At Last." PC Magazine, March 15, 1994.
  • Kay Lee and Nestor Miranda. "What's New in PC DOS 7." Personal Systems,March/April 1995.
  • Albert Saraie. "PnP To Make Users Into Integrators." Computer Technology Review, July 1994.
  • Plug and Play BIOS Specification, version 1.0A, May 5, 1994.
  • PC DOS 7 Technical Reference, January 1995, (GG24-4459-00).
  • PC DOS 7 Command Reference, (S83G-9309).
  • Laura Golla. "Plug and Play ISA Makes PC Hardware Easier to Use." Instrumentation Newsletter, Volume 7, Number 1, Spring 1995.