Plug and Play in PC DOS 7: Difference between revisions
No edit summary |
mNo edit summary |
||
Line 1: | Line 1: | ||
{{IBM-Reprint}} | {{IBM-Reprint}} | ||
By [[Mark Gehring]] and [[Kamal C. Patel]] | ''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.'' | |||
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 | 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 | ||
time-consuming, technical process. You might have to configure the system by setting | software files. Mobile systems, in particular, demand greater hardware and software integration in order to dynamically insert and remove devices and docking support. | ||
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 | 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. | ||
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 | |||
the device in, turn on the system, and it works. | |||
== Architecture and Components Overview == | == Architecture and Components Overview == | ||
Figure 1 shows the general structure of the Plug and Play architecture. | Figure 1 shows the general structure of the Plug and Play architecture. | ||
[[Image:patel1.gif|thumb|'''Figure 1. Plug and Play Components''']] | |||
[[Image:patel1.gif | |||
'''Figure 1. Plug and Play Components''' | |||
=== Plug and Play BIOS === | === Plug and Play BIOS === | ||
System BIOS addresses two key areas to furnish plug and play capabilities: Resource | System BIOS addresses two key areas to furnish plug and play capabilities: Resource management and runtime configuration. | ||
management and runtime configuration. | |||
Resource management provides the ability to manage system resources, which include | 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. | ||
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 | 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 | ||
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. | system can allocate resources during runtime. | ||
[[Image:p&pcart.png|frame]] | [[Image:p&pcart.png|frame]] | ||
=== Plug and Play Operating System === | === Plug and Play Operating System === | ||
To provide complete Plug and Play functionality, the operating system requires the | To provide complete Plug and Play functionality, the operating system requires the following components: | ||
following components: | * ''Configuration manager'' -The configuration manager is the software that controls the configuration process and communicates with all components involved in that process. | ||
* ''Configuration manager'' | * ''Hardware tree'' -The hardware tree contains a database of information used to configure the system. | ||
* ''Hardware tree'' | * ''Bus enumerators'' -The bus enumerator identifies all the devices on a particular bus and their resource requirements. | ||
* ''Bus enumerators'' | * ''Resource arbitrators'' -The resource arbitrator allocates resources among all devices. | ||
* ''Resource arbitrators'' | |||
Each of these components is now discussed in turn. | Each of these components is now discussed in turn. | ||
==== Configuration Manager ==== | ==== Configuration Manager ==== | ||
The configuration manager starts the configuration process upon receiving either the | 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. | ||
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 | 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. | ||
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 ==== | ==== Hardware Tree ==== | ||
A record of the current system configuration, known as the ''hardware tree'', is stored in | 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. | ||
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 | 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, | ||
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. | software required to operate these devices, and user-defined settings. | ||
==== Bus Enumerators ==== | ==== Bus Enumerators ==== | ||
The bus enumerator is a type of driver required for each specific bus type and is | The bus enumerator is a type of driver required for each specific bus type and is responsible for building the hardware tree. | ||
responsible for building the hardware tree. | |||
A bus enumerator identifies the devices on that bus by assigning a unique identification | 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. | ||
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 ==== | ==== Resource Arbitrator ==== | ||
The resource arbitrator allocates specific types of resources to devices and resolves | 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. | ||
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 === | === Device Drivers === | ||
Plug and Play device drivers register with the configuration manager when they are | 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. | ||
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 SCSI === | ||
Plug and Play small computer system interface (SCSI) host adapters will configure like | 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. | ||
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, | 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- | ||
which is called SCSI Configuration Auto Magically (SCAM). SCAM requires additional | SCAM-complaint devices still must be configured with software updated to handle SCAM devices. | ||
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 === | === Plug and Play ISA === | ||
The Plug and Play industry standard architecture (ISA) specification, developed jointly | 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. | ||
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 | 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. | ||
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 | 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. | ||
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 | 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. | ||
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 ==== | ==== Backward Compatibility ==== | ||
The Plug and Play architecture must provide compatibility with the installed base of | 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. | ||
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 | 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. | ||
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 == | == Plug and Play Support in PC DOS 7 == | ||
Line 151: | Line 77: | ||
=== Docking Support === | === Docking Support === | ||
''Docking'' is the process of connecting a mobile computer to a docking station and | ''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. | ||
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 | 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. | ||
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 | 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. | ||
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 | During ''warm'' docking a mobile PC is in a suspended state, and many if not all of the associated peripherals are recognized and activated. | ||
associated peripherals are recognized and activated. | |||
In ''hot'' docking, a mobile PC is fully active when docked, and many if not all peripherals | In ''hot'' docking, a mobile PC is fully active when docked, and many if not all peripherals are recognized and activated. | ||
are recognized and activated. | |||
=== DOSDOCK === | === DOSDOCK === | ||
The DOSDOCK utility enables mobile computer users to use either hot or warm docking. | 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. | ||
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 | 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. | ||
notifies you, in a pop-up Windows message, that you must shut down Windows to allow | |||
DOSDOCK to begin. | |||
=== INT 2Fh API === | === INT 2Fh API === | ||
To provide communication between the PC DOS 7 docking support programs, some new | 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. | ||
multiplex interrupt functions are defined. The application programming interfaces (APIs) | |||
in Figure 2 are defined and used for docking support in PC DOS 7. | |||
{| border="1" | {| border="1" | ||
|'''INT 2Fh Function 2000h''' | |||
|'''INT 2Fh Function 2000h''' | Check DOSDOCK Installation | ||
|This function allows the caller to determine whether the DOSDOCK program is resident. | |This function allows the caller to determine whether the DOSDOCK program is resident. | ||
|AX = 2000h | |AX = 2000h | ||
|AL = 00h DOSDOCK program not installed | | | ||
AL = FFh DOSDOCK program resident | :AL = 00h DOSDOCK program not installed | ||
:AL = FFh DOSDOCK program resident | |||
|- | |- | ||
|'''INT 2F Function 2001h''' | |'''INT 2F Function 2001h''' | ||
Get Docking Event | Get Docking Event | ||
|This function allows the caller to determine if a docking event has occurred. An | |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. | ||
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 | |AX = 2001h | ||
|AL = 00h no event | | | ||
:AL = 00h no event | |||
:AL = 01h docking event occurred | |||
:AL = 01h machine is docked | |||
|} | |} | ||
'''Figure 2. PC DOS 7 APIs for Docking Support''' | '''Figure 2. PC DOS 7 APIs for Docking Support''' | ||
=== DYNALOAD === | === DYNALOAD === | ||
The DYNALOAD command allows you to dynamically load a device driver from the | 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. | ||
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 | 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. | ||
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 | DYNALOAD cannot load block device drivers or drivers that require DOS system initialization or execution via the CONFIG.SYS file. | ||
initialization or execution via the CONFIG.SYS file. | |||
=== DDPOPUP === | === DDPOPUP === | ||
The DDPOPUP program provides DOS docking support under Windows. When | 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. | ||
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 | 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. | ||
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 == | == Hardware Requirements == | ||
To provide complete Plug and Play functionality, a system must incorporate all three | 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 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 | 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. | ||
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 | 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. | ||
components is the ability of that system to dynamically respond to configuration events. | |||
== Future of Plug and Play == | == Future of Plug and Play == | ||
The goal of Plug and Play architecture is to easily install and configure new devices. | 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. | ||
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 | 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. | ||
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 | 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. | ||
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. | |||
== References == | == References == |
Revision as of 10:46, 2 November 2019
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.
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.
DOSDOCK
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.
INT 2Fh API
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.
INT 2Fh Function 2000h
Check DOSDOCK Installation |
This function allows the caller to determine whether the DOSDOCK program is resident. | AX = 2000h |
|
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 |
|
Figure 2. PC DOS 7 APIs for Docking Support
DYNALOAD
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.
DDPOPUP
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.
References
- 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.