At the end of this module, you will be able to:

Plug and Play is both a design philosophy and a set of personal computer architecture specifications. Plug and Play is not proprietary to any one company, it is an independent set of specifications developed by a group of hardware and software development companies. These standards may be followed by any company producing computing devices.

The goal of Plug and Play is to enable changes to a personal computer configuration with no intervention by the user. The installation of any device should be a simple, fail-safe operation.

For Plug and Play compliant devices, the installation is automatic—plug the device in, turn on the system, and it works. With a completely compatible Plug and Play system, the user should be able to change the system components without restarting the system. For example, a user could do the following without restarting the workstation or changing configuration parameters.

The system determines the optimal configuration for any of the changes and programs automatically adjust to take full advantage of the new configuration. The following illustrate the capabilities of a fully Plug and Play compatible system.

• If you take your notebook computer with infrared communications features into a room with a printer that also uses infrared communications, your programs are ready to print on this printer.
• You add a new card to your computer and as soon as you power the machine back on, you use the new card.
• By plugging it in and turning it on, you can add a new monitor and automatically take advantage of its new capabilities.

Plug and Play devices must be able to identify themselves and specify their capabilities and resource requirements. This information enables the operating system to determine and establish a working configuration for all devices on the system and load the appropriate device drivers without any user intervention.

A Plug and Play system allows for devices to be inserted into the system at any time. The user is not required to turn off or restart the system. This means that when a device is inserted, the operating system receives notification about (or recognizes) the new device, its capabilities and requirements. The operating system then loads the necessary device drivers and establishes a working configuration. The user is not asked to intervene in the configuration process unless the required resources are not available to the new device.

The Plug and Play architecture is compatible with the installed base of existing (legacy) systems and peripherals. To accomplish this goal, components in the Plug and Play architecture accommodate for the lack of device-reporting mechanisms for legacy devices. Information about such devices is stored in the system, and devices that cannot be software-configured receive first priority in resource allocation.

When unresolvable conflicts occur between devices, the system guides the user through device-configuration options.

There are three types of docking supported by Windows 95; cold, warm, and hot.

Additionally, there are two varieties of hot docking systems available:

• Auto-eject—A software interface that operates motorized ejection mechanism. This allows Windows 95 to prompt the user for action about any open or in-use resources. The user is able to save files and such before the system ejects the computer. This is sometimes called “VCR style” docking.
• Manual — the user undocks the computer without a hardware interlock. Because the system can not control when docking or undocking occurs, any closing of files or other actions must be performed by the user prior to removing the computer to prevent loss of data. This is called Surprise mode in some documentation.

Devices that change configuration based on docking status include almost anything. Monitors, network access, removable hard drives, any resource not necessary to booting the system may change based on configuration.

Some devices may require preliminary steps completed before they can be docked or undocked. For example, if you have a file open and decide to remove the hard drive, what happens to the file?

When a peripheral wants to notify a program that an event has happened and the software needs to handle it, the peripheral will usually do this by triggering an interrupt request. These are hardware signals built into the personal computer and dealt with by a device called a Programmable Interrupt Controller (PIC). The PIC in the original IBM personal computer was capable of dealing with 8 interrupt lines (IRQs) numbered from 0 to 7. When the PC/AT came out, it included a second PIC which was “cascaded” to the first. This meant that IRQ number 2 on the first PIC was used to trigger the second PIC. This method allowed the system to handle 16 interrupts although IRQ 2 was primarily used to trigger the second PIC.

Personal computers consist of multiple bus and device architectures coexisting in a given system. These systems can be viewed using a “tree” model to describe the relationships between these buses and devices.

In the system tree, buses and devices may appear at different levels of the system hierarchy in multiple “parent-child” relationships. Buses and devices may require system resources and they may provide resources that are understood, or not understood, by their parents. The relationships are complicated by the fact that some of the buses (SCSI, PCMCIA) are actually hidden from their parents until they are initialized.

Each branch in the tree defines an object that must be addressed by the Plug and Play framework. This object is called a “device node.” Configuring a device node requires the following information:

Windows 95 implements Plug and Play system identification of new devices both during startup and dynamically while the system is running.

Each time Windows 95 is started, the hardware is polled for its identification and specification information.

The specification for Plug and Play ISA adapters defines a hardware and software mechanism for incorporation in the next generation of ISA cards, referred to as Plug and Play ISA cards.

ISA stands for Industry Standard Architecture. ISA is the architecture specified in 1984 to produce the 80286 (IBM PC/AT) bus systems.

The major steps of the auto-configuration process are as follows:

1. Put all Plug and Play ISA cards in configuration mode.

The Plug and Play software identifies and configures devices using a set of commands that are carried out using three 8-bit I/O ports. A sequence of data writes to one of the ports (the initiation key) is used to enable the Plug and Play logic on the card.

1. Isolate one Plug and Play ISA card at a time and assign a “handle” to the card.

Because all the cards respond to the same I/O port addresses, the Plug and Play software needs an isolation mechanism to address one particular card at a time. The isolation protocol uses a unique number on each card (the device ID and a serial number) to isolate one Plug and Play card at a time.

After isolation, the Plug and Play software assigns each card a handle, which is used to select that specific Plug and Play card. The handle eliminates the need for the more elaborate and time-consuming isolation protocol to select a specific card.

2. Read the card’s resource data structure to determine the card’s resource requirements and capabilities.

Each Plug and Play ISA card supports a read-only resource data structure that describes the resources supported and those requested by the functions on that card. The structure supports the concept of multiple functions per ISA card. For example, some audio cards may provide sound generation, MIDI, joystick, and CD-ROM functions on a single card. Each function is defined as a logical device.

Plug and Play resource information is provided for each logical device and each logical device is independently configured through the Plug and Play standard registers. Following isolation, the Plug and Play software reads the resource data structure on each card.

3. Allocate conflict-free resources to each card.

When all resource capabilities and demands are known, a process of resource arbitration is invoked to determine resource allocation to each ISA card. The configuration of ISA cards is performed using the command registers specified for each resource type. Some ISA functions may not be reconfigurable. If this is the case, the resources requested will be equivalent to the resources assigned. However, the resource data structure informs the configuration software that it cannot assign these resources to other Plug and Play cards in the system.

After the assignment of resources, an I/O conflict-detection mechanism may be invoked. This mechanism provides a means to ensure that I/O resources assigned are not in conflict with standard ISA cards. The command set also supports activating or deactivating the functions on the card.

4. Activate all Plug and Play ISA cards and remove them from configuration mode.

In a system that uses only Plug and Play ISA cards, it is possible to achieve fully automatic configuration. However, during a transition period the current generation (legacy) of standard ISA cards will coexist with Plug and Play ISA cards in the same system. In such systems, the ISA configuration solution needs to be supplemented with additions to the BIOS and operating system to manage and arbitrate ISA bus resources. User intervention may still be necessary in some cases.

Somehow, the system needs to know what type of hardware exists and how that hardware is configured. Windows 95 determines this by using a safe detection methods, an invasive polling routine (as described in the “Installation and Configuration” module) or by prompting the user to provide this information. Once this information is determined, it is recorded in the registry. This information is not dynamic, but it is used to arbitrate resource assignments with devices that are Plug and Play compatible.

In order to implement a fully Plug and Play compatible system, changes are required to all components of the personal computer system, including the following.

Bus enumerators are responsible for building (enumerating) the hardware tree on a Plug and Play system. The bus enumerators are a new type of driver required for each specific bus type.

The critical function of the bus enumerator is to assign a unique identification code to each device on its bus. The only requirement for the identification code is that it be unique and consistent. Each time the system boots the ID for a particular device should be the same. The Plug and Play framework uses existing identification codes for most buses. For example, Plug and Play EISA devices are identified using the EISA device ID scheme, while PCMCIA cards are identified by means of the Manufacturer ID tuple (a database entry) on the card.

To provide complete Plug and Play functionality, the BIOS notifies the operating system of dynamic configuration events, such as the insertion of a notebook system into a docking station. A Plug and Play BIOS provides a mechanism for a Plug and Play operating system to reconfigure system board devices in response to a dynamic event. This enables the operating system to reconfigure the system without requiring the user to turn the system off. The operating system can also notify programs and drivers of the new system configuration. In addition, for software-controlled devices (such as VCR-style docking and undocking systems), the BIOS can provide early warning to the operating system and prevent errors and data loss due to removal of the device.

The hardware tree is a record in RAM of the current system configuration. The tree information is drawn from the registry of configuration information for all devices, whether they are currently installed or not. (In Windows 95 this information is maintained in the SYSTEM.DAT file.) The hardware tree is created every time the system boots and is updated when a run-time change occurs to the system configuration.

The format for the hardware tree defines a standard scheme for identifying each device, its resource requirements and resource constraints, if any. There may also be interdependencies between specific resources, such as COM ports and IRQs, for example. The registry is accessible to programs and drivers to provide them with information about alternative configurations, software required to operate these devices, and user-defined settings. The existence of this database eliminates the need for many of the device and program-specific *.INI files.

The operating system requires several new components to provide complete Plug and Play functionality, including:

The Plug and Play architecture builds on existing device driver models to provide additional APIs required for Plug and Play device configuration. Device drivers must become dynamically loadable and unloadable to allow for system reconfiguration and to make most efficient use of system memory. Device drivers must communicate with other components of the system in a variety of ways. The device drivers must be able to:

The Resource Arbitrator is the part of the operating system that allocates specific types of resources to devices and resolves conflicts between devices that request identical resources.

In the event that different devices require the same resources, the devices must be able to provide information to the operating system about alternative resource requirements. The operating system will use this information to identify a working system configuration. Once the resource conflict has been resolved, the operating system must store the new configuration information in the registry and notify the device drivers of the new resource assignments.

To accomplish this function the Resource Arbitrator contains all the information about how a resource is structured and algorithms for determining a feasible resource configuration for a given a set of device requirements and constraints.

The Resource Arbitrator interacts extensively with the Configuration Manager to perform the iterative process of assigning resources:

In the case of a dynamic reconfiguration of the system, the Configuration Manager may require the resource arbitrator to release resources and reassign them to satisfy the needs of a new device.

This functional separation of the Resource Arbitrator and the Configuration Manager provides for future extensibility of the operating system to address new types of resources.

The four resources that are arbitrated are:

The Configuration Manager coordinates the entire flow of operations performed by all the components involved in the configuration.

The Configuration Manager takes control of the configuration process during two situations:

The Configuration Manager then coordinates communication between the bus enumerators, hardware tree, registry, device drivers, and resource arbitrators to establish a working configuration for the system. In addition, the Configuration Manager notifies device drivers and programs of any pending or present changes in the system layout (such as new or removed devices).

To perform this role the Configuration Manager calls on the bus enumerators to identify all the devices on their specific buses and their respective resource requirements, then stores this information in the hardware tree as a hierarchical arrangement of device nodes.

Under normal circumstances the system performs all configuration operations. However, certain circumstances may require intervention by the end user. For example, if the user is installing a legacy device and the system fails to detect that device, the user can force a software installation through the New Device icon in Control Panel.

Because the Plug and Play system provides a way to change the system configuration, the system needs to provide a specialized tool to access and edit this information, primarily for use by the advanced user.

MicroChannel is IBM’s proprietary bus introduced with the PS/2 series.

EISA stands for Enhanced Industry Standard Architecture. This is a response by an industry consortium to IBM’s MicroChannel. EISA devices use cards that are upwardly compatible from ISA.

MicroChannel and EISA devices already provide a standard identification mechanism and a mechanism for configuring their resources through software.

To integrate with the Plug and Play architecture, a bus enumerator for each bus standard is required to make configuration information about MicroChannel and EISA devices accessible to the operating system. The bus enumerators need to incorporate the functions previously provided by the configuration tools for those buses. In addition, it is desirable to integrate the currently required configuration tools with the operating system.

SCSI stands for Small Computer Standard Interface. This is a multidevice chained interface used in many devices such as hard drives and CD-ROM drives.

A SCSI Plug and Play specification has been completed. It supports dynamic changes and other Plug and Play features.

SCSI devices require both design changes and general ease-of-use enhancements to deliver Plug and Play functionality. The configuration of a SCSI system can be separated into two distinct processes:

Configuring the SCSI bus is difficult for most users. The concepts are mystifying to anyone who is unfamiliar with SCSI. With a completely Plug and Play compatible SCSI bus, the user would be able to just plug in the new device and the bus would adjust. But with a current SCSI bus the list of issues the user must confront to configure a SCSI bus is long, including:

The SCSI-2 specification does not define an automated ID assignment mechanism, so the end user is responsible for making sure that no two SCSI devices on the same SCSI bus share the same SCSI ID.

It is not easy for the non-technical user to tell whether or not a SCSI device is terminated, because termination can be done by jumpers, switches, or by adding or removing resistor packs.

Currently, users can replace a SCSI host adapter with one from a different company and find it does not work due to differences in disk geometry’s or the way devices are mapped to INT 13h parameters. Each of these issues needs to be addressed to provide Plug and Play functionality for SCSI buses.

PC Card is the standard for the credit card sized interface cards found in portables and other small computer systems. This standard was previously called PCMCIA.

To support Plug and Play for PC Card requires at least two drivers: one for the card and one for the socket. The approach to supporting PC Card under the Plug and Play framework calls for a PC Card adapter to be controlled by a PC Card bus enumerator that incorporates the PC Card Card Services functions as well as the enumeration and configuration functions described in the Plug and Play specification. Using this approach the PCMCIA device can be treated like any other Plug and Play device during the configuration process, so resources can be allocated and reclaimed dynamically by the operating system, allowing for easy addition of static devices and support for hot or warm docking.

To support PC Card cards as standard Plug and Play devices, the PC Card card must be able to supply a unique identifier for itself and declare its resource requirements. This information can then be kept in the operating system hardware tree where it can be used to configure the device dynamically.

PC Card device drivers can be implemented in two ways:

In a Plug and Play system the PC Card system software is integrated with the operating system configuration management software, so that the Configuration Manager provides the resource allocation for the card rather than the Card Services module. This can be done by adding a PC Card bus enumerator and driver to Card Services and changing Card Services to accept configurations from the configuration manager instead of tracking the resources itself. This implementation will provide support for existing Card Services clients as well as new Plug and Play drivers.

The VESA (video electronic standards association) Local (VL) bus is a standard for a bus that allows high speed connections to peripherals.

PCI stands for Peripheral Component Interconnect. This is a local-bus being promoted as the successor to VL. This type of device is used in most Pentium computers and in the Apple Power Macintosh.

The current PCI bus architecture meets most of the requirements for providing Plug and Play functionality. PCI devices use a standard identification scheme and a mechanism for declaring their resource requirements. The BIOS on PCI platforms contains the configuration logic required to configure all PCI devices during POST , and to enable only boot devices and devices with option ROMs. In addition, the BIOS already provides a mechanism for device drivers to access PCI configuration data.

The PCI bus enumerator builds the hardware tree in the operating system for both PCI devices and PCI bridges. The BIOS extensions are required to enable the operating system to correctly configure systems that contain both PCI and ISA devices. Since PCI devices can share interrupts but ISA devices may not, the BIOS must be able to prevent the operating system from mapping PCI devices to interrupts being used by non-shareable ISA devices.

PCI is Plug and Play compatible. But PCI cannot automatically transfer this compatibility to another bus in the system. Because PCI tends to be a secondary bus, you need to be aware that its parent bus may not be Plug and Play compatible. If the parent bus is not Plug and Play compatible, the PCI bus cannot use the Plug and Play functions.

VL bus devices are not as compatible with the Plug and Play specifications as PCI buses. The VL bus devices do have identification and configuration routines built in and, because they are an ISA child bus, VL devices can leverage much of the work that has been done with the ISA specification.

The Device Manager is the user interface used to manually change the configuration of devices.

• To access the Device Manager

1. From Control Panel, double-click the System Icon.

The System property sheets displays.

2. Click the Device Manager tab.

The Device Manager allows you to change the configuration of any device located on the workstation. You may view devices by type or by connections.

Viewing by connection is useful as it most closely resembles the registry information. Another use is when you may not know where a device is listed, but you know what type of device it is, you can find it by the connection.

• To change the configuration of a communications port (optional)

1. From the Device Manager, click the + beside Ports.

The tree expands showing the types of ports available on the workstation.

2. Select a Communications Port.
3. Click the Properties button.

The property sheets for Communications Port displays.

1. Click the Resources tab.

The Resources sheet displays, indicating the current settings.

You may want to record these settings for future reference.

These configurations are the various settings that the device supports. Notice that any resource marked with an * conflicts with an existing device.

Did the settings change?

The Device Manager is the primary tool (accessed through the System icon in Control Panel).

1. A customer is interested in installing Windows 95 on a notebook computer but is concerned about all the extra “software overhead” that may be needed to support hot docking.

What extra “software overhead” could the customer be referring to, and what can you do to dispel this myth?

The “software overhead” that the customer is referring to is probably device drivers. The customer is concerned that once a device is undocked from a computer, the various device drivers for the docking station devices remain in memory.

Explain to the customer that Windows 95 comes with device drivers that are loaded and unloaded automatically as the system configuration changes by means of hot docking.

2. A customer has just added some new boards to his Windows 95 system. The customer wants the mouse plugged into COM 1 and has a printer plugged into the only parallel port. The system has the following hardware: