The sound card Sound Blaster AWE32 PNP CT3990 had a Plug-and-Play ISA Bus interface chip (large square chip, mid of bottom row).
The term Legacy Plug and Play,[1] also shortened to Legacy PnP,[2] describes a series of specifications and Microsoft Windows features geared towards operating system configuration of devices, and some device IDs are assigned by UEFI Forum.[3] The standards were primarily aimed at the IBM PC standard bus, later dubbed Industry Standard Architecture (ISA). Related specifications are also defined for the common external or specialist buses commonly attached via ISA at the time of development, including RS-232 and parallel port devices.
As a Windows feature, Plug and Play refers to operating system functionality that supports connectivity, configuration and management with native plug and play devices.[4] Originally considered part of the same feature set as the specifications, Plug and Play in this context refers primarily to the responsibilities and interfaces associated with Windows driver development.[5]
Plug and Play allows for detection of devices without user intervention, and occasionally for minor configuration of device resources, such as I/O ports and device memory maps. PnP is a specific set of standards, not be confused with the generic term plug and play, which describes any hardware specification that alleviates the need for user configuration of device resources.[6]
The Plug and Play standard requires configuration of devices to be handled by the PnP BIOS, which then provides details of resources allocations to the operating system. The process is invoked at boot time. When the computer is first turned on, compatible devices are identified and assigned non-conflicting IO addresses, interrupt request numbers and DMA channels.
The term was adopted by Microsoft in reference to their Windows 95 product. Other operating systems, such as AmigaOSAutoconfig and the Mac OSNuBus system, had already supported such features for some time (under various names, or no name).[7] Even Yggdrasil Linux advertised itself as "Plug and Play Linux" at least two years before Windows 95. But the term plug and play gradually became universal due to worldwide acceptance of Windows.
Typically, non-PnP devices need to be identified in the computer's BIOS setup so that the PnP system will not reassign those devices. Problems in the interactions between legacy non-PnP devices and the PnP system can cause it to fail, leading to this technology having historically been referred to as "plug and pray".[2]
Specifications
Legacy Plug and Play Specification was defined by Microsoft and Intel, which proposed changes to legacy hardware, as well as the BIOS to support operating system-bound discovery of devices. These roles were later assumed by the ACPI standard,[1] which also moves support for power management and configuration into the operating system, as opposed to the firmware as previously required by the "Plug and Play BIOS" and APM specifications. The following standards compose what Microsoft describe as Legacy Plug and Play, as opposed to native Plug-and-Play specifications such as PCI and USB.
The device to be installed must be a Plug and Play compliant device.
Hardware identification
Plug-and-play hardware typically also requires some sort of ID code that it can supply, in order for the computer software to correctly identify it.
This ID code system was not integrated into the early Industry Standard Architecture (ISA) hardware common in PCs when Plug and Play was first introduced. ISA Plug and Play caused some of the greatest difficulties that made PnP initially very unreliable. This led to the derisive term "Plug and Pray", since I/O addresses and IRQ lines were often set incorrectly in the early days. Later computer buses like MCA, EISA and PCI (which was becoming the industry standard at that time) integrated this functionality.
Finally, the operating system of the computer needs to be able to handle these changes. Typically, this means looking for interrupts from the bus saying that the configuration has changed, and then reading the information from the bus to locate what happened. Older bus designs often required the entire system to be read in order to locate these changes, which can be time-consuming for many devices. More modern designs use some sort of system to either reduce or eliminate this "hunt"; for example, USB uses a hub system for this purpose.
When the change is located, the OS then examines the information in the device to figure out what it is. It then has to load up the appropriate device drivers in order to make it work. In the past, this was an all-or-nothing affair, but modern operating systems often include the ability to find the proper driver on the Internet and install it automatically.
