THE MAGIC CONNECTION - Part 1
|by Wayne M. Krakau - Chicago Computer Guide, July, 2002|
| Viewing the British TV series Connections (and its successors, Connections 2 and Connections 3),
originally broadcast in this country on PBS and currently being rerun on The Discovery Science Channel,
you could learn such arcane information as how the man who figured out how to feed Napoleon's army was
responsible for launching the Space Shuttle (depending upon how you and I and the Bills - Gates and Clinton
- define "responsible"). In a similar vein, I'm going to show you how a simple magic trick I learned as a child
was responsible for solving an ever more common systems integration problem.
As in the TV series, I'll start with the historical background of the issue at hand. In the old days, when dinosaurs (like IBM) ruled the earth, the circuit boards you plugged into the early IBM and compatible PCs were studded with jumpers, those little rectangles that connect two bare pins, completing the circuit between them. The placement of the jumpers determined various characteristics of the board, including what resources the board would use for communications with the motherboard and the CPU (Central Processing Unit). You had to be careful not to bend or, heaven forbid, break a jumper pin.
Early versions of jumpers required the use of hexadecimal (base 16), binary (base 2) or sometimes octal (base 8) arithmetic to figure out the correct settings. The Proteon ProNet 10 card stands out in my memory as having a particularly nasty collection of jumpers. Later, manufacturers broke down and actually documented the settings in comprehensive tabular lists.
Another advance was the replacement of jumpers, at least partially, by DIP (Dual Inline Package) switches. Some of them flip up and down like a light switch and others slide back and forth. Just to make sure that things weren't too easy, for a long time the DIP switches were labeled with a zero or a one or with Open or Closed, assuming they were labeled at all.
Eventually, manufacturers figured out that if they silk-screened the documentation for the jumpers or switches directly onto their boards, they could save a bundle on preventable tech support calls.
All of this jumper and switch nonsense was done under the assumption that mostly hard core computer geeks and computer professionals were the only ones configuring systems and inserting boards into PCs. As computers were being sold to a much wider audience, the incidence of problems rose alarmingly. Boards just won't work properly if the resources that they use conflict with other boards or some resource used by the motherboard.
This could get complicated as, depending upon the board involved, you had to worry about high memory regions (4-digit hexadecimal addresses), low memory region or port allocation (3-digit hexadecimal addresses), DMA (Direct Memory Access) channels and IRQs (hardware Interrupt Requests). Some boards, like sound cards, required multiple, non-conflicting resources.
The IRQs could be particularly troubling. Each IRQ number, from 1 through 16 (only 1-8 before the IBM AT was introduced) corresponds to an actual direct path to one of the legs on the CPU chip. When the CPU receives a signal via one of the IRQ-related legs, it stops what it is doing and immediately gives its full attention to the task associated with that IRQ, as defined by software loaded into the processor. That software defines what port the CPU will look at when it gets an interrupt signal. Under certain circumstances, IRQs could be shared, but that only made things trickier to figure out. Back then, there was only limited support for IRQ sharing, so running out of available IRQs was always a possibility.
Even with all of these different resources to consider, for an experienced technician or a talented amateur, the task of organizing this mess was definitely doable, if some what tedious (assuming the documentation was up to snuff, of course). An inexperienced user, however, would have to depend upon luck or multiple tech support calls. The problem is, as computer sales grew, the ratio of experienced to inexperienced users tipped overwhelmingly in favor of the inexperienced, nontechnical user, giving computer manufacturers support department fits. The daunting job of manually allocating resources was also seen as slowing sales among the non-geeks.
The answer was a neat trick called Plug and Play, which is a standard for automatically allocating system resources so that software could figure out how to talk to hardware. The idea is to make boards smart enough to supply their resource needs when asked. Then some additional brainpower added to the motherboard figures out who gets what.
©2002, Wayne M. Krakau