A Brief History of PC Plug and Play

Plug and Play, In the Beginning

Early PC expansion cards either came with no user selectable options, like most IBM's cards, or came with banks of jumpers and dipswitches.  Early motherboards also often came only with jumpers to control settings on them.  I love these early devices because, if you have the documentation, you always can change the settings and get them to work.  IBM's PC, XT, Portable, PCjr and all the Tandy 1000s up to and including the Tandy 1000 TX (but excluding the HX) were all configured in this way.  All the major graphics cards and all of Creative Labs sound cards, up to and including the first generation of the Sound Blaster 16, were also configured in this way.

Jumpers or dipswitches typically allow you to select I/O addresses, IRQ and DMA usage, among other things.  If you think you have a conflict, you shut off the computer, check your cards and make changes to fix the conflict.  Turn it back on and if the conflict is solved, it will remain solved so long as the hardware does not change.  Occasionally during this period, there were some cards which could be unofficially modded with a soldering iron to give you extra options.

Conflicts in the early ISA period were often tricky to diagnose.  In the early days, not many people knew what an Interrupt Request was or why their card would not work if another card used the same Interrupt Request.  IRQs were the worst areas of conflict because many devices used an IRQ and there were not many which did not have a specified use.  Some peripheral cards and software programs would only use the lower eight IRQs.  Of those eight, three (System Timer, Keyboard Controller, Floppy Disk Controller) are almost always in use and two more (parallel and serial) are frequently used as well.  ISA IRQs are generally not shareable (except for the parallel IRQ when assigned to a printer).  DMA usage, even with only four or seven DMA channels, was not usually as bad because so few devices used DMA.  I/O port usage was not always given, so if a new card caused your system to crash, it could be due to an I/O conflict.  IBM originally only designated 768 valid I/O addresses in the PC design, but eventually the full number of 8086 I/O addresses (65,536) was being used (including by IBM).  Finally, there are memory addressing conflicts. If a peripheral card uses the Upper Memory Area for ROM or RAM, it may conflict with some other card which also has ROM or RAM.  Some cards, like my ADP-50L use memory addressing to speed up hard disk transfers, even though the card has no RAM, but fail to note which area of memory it is using.

An initialization driver was not common in the early days.  The BIOS, DOS or the program had all the tools it needed to utilize the hardware.  If the BIOS did not have hard drive support, support was added through a ROM extension on a card.  EMS memory boards were an early exception, a driver needed to be loaded so a program could address the memory in a standardized way.  CD-ROM drivers would eventually follow in this way.

Plug and Play, Software Configuration

Knowing that many people were afraid to take a screwdriver and tweezers to their computers, eventually companies began using software configuration.  For systems, this was originally a bootable floppy with a system setup program.  This allowed the user to indicate what he had installed in the system and to change system parameters.  The IBM PC AT was the first system to allow this, and AT clones thereafter took from IBM's lead.  Eventually the IBM PS/2 MCA computers would have peripheral setup disks.  You would load the disk and the disk would tell the system that a new peripheral was installed and configure the card entirely in software.  The only problem with this is that if you lost the setup disk, you were SOOL.  Also, it really stunk if your CMOS battery expired.  The system would store its configuration in the CMOS and when the CMOS died, you would start getting dreaded "161" or "163" errors.  At worst, the system would fail to get past the boot screen at all.  Some other systems, like the later Tandy 1000s store their settings in a small EEPROM.

Eventually, this software configuration concept made its way to ISA cards.  The Gravis Ultrasound was partially software configurable.  While you selected the card's I/O address via jumpers, you set its IRQ and DMA selections by an initialization program (ULTRINIT.EXE) that loaded every time you booted the system.  The second generation Sound Blaster 16s and first generation Sound Blaster AWE32s also used a similar program (SBCONFIG.EXE or DIAGNOSE.EXE).  The Gravis and Creative programs would be loaded in AUTOEXEC.BAT and take the settings from the SET BLASTER or SET ULTRASND lines in AUTOEXEC.BAT.  The Mediavision Pro Audio Spectrum series used a device driver called MVSOUND.SYS, loaded in CONFIG.SYS with parameters, to initialize the card.

Plug and Play : Standardization

Ever desiring to make hardware more friendly to users, especially when PCI cards rarely if ever had jumpers or dipswitches, the ISA Plug-N-Play standard emerged.  This standard mandated that virtually everything be configured by software in a standardized manner.  If you had a Plug and Play OS like Windows 95, you would configure your cards in System Properties.  If you were still using DOS, you had to run a program that gave you the functional equivalent.  Sound Blaster cards had a program called CTCU.EXE which could configure any ISA PNP card, not just a Sound Blaster card.

Popular Sound Cards with PNP support include third generation Sound Blaster 16s, second generation Sound Blaster AWE32s, all Sound Blaster 32s and AWE64s.  The Gravis Ultrasound PNP, the various Yamaha, Crystal and ESS ISA chipsets all seem to be PNP.  They all require drivers to initialize the card and to change settings.  Loading these drivers in DOS can add quite a bit to the boot time.  Even if the card's drivers are properly loaded in Windows, you will still need to load the card's DOS drivers.

ISA Plug and Play would gives you resource configurations.  Some of these configurations would allow you to manually assign resources to the card and sometimes they would not.  Sometimes they would delete resources or assign resources in a very odd way.  Often it was quite a struggle to get some cards working at the resources you wanted as opposed to what the driver assumes everybody wants.

With PCI cards came the end of much of the hassle of assigning resources and managing resource conflicts, whether on the card or in software.  Windows 3.1 had begun the requirement of drivers for various hardware, but Windows 95 took it to a whole new level.  While there would occasionally be a resource conflict, PCI cards were typically well-behaved and focused on configuring options instead of resources.