Archives
 
 
 
  Special
 
 
 
  About Us
 
 
 

Newsletter
Free E-mail Newsletter from BYTE.com

 
    
           
Visit the home page Browse the four-year online archive Download platform-neutral CPU/FPU benchmarks Find information for advertisers, authors, vendors, subscribers Request free information on products written about or advertised in BYTE Submit a press release, or scan recent announcements Talk with BYTE's staff and readers about products and technologies

ArticlesPlug and Play in Hindsight


November 1994 / Letters / Plug and Play in Hindsight

Choice article on Plug and Play (September). However, you omitted one important part: how a trivial hardware botch in the original PC has made this all much worse than it had to be.

Many machines have fewer interrupt levels than the PC but aren't hurt nearly as badly by it. Why? Because on the other machines, I/O boards can share an interrupt line. For instance, there is no reason COM ports need distinct IRQs (interrupt requests), except that I/O cards cannot share the same one and have it work.

There are boards with multiple UARTs (universal asynchronous receiver/transmitter) on a card, all of which internally share one IRQ for the whole card, but the problem is that the original PC bus didn't arrange for IRQ sharing between cards. This only would have cost a pull-up resistor per line (and possibly an inverter), and the IRQ l ine could have been driven low by open-collector TTL drivers, instead of the single totem-pole outputs specified. With this trivial fix, we would have been able to share the IRQs just fine. It would have all been a lot easier.

Michael O'Dell

mo@uunet.uu.net

If I had listed everything wrong with the PC system architecture, my story would have been twice as long! You're right about the PC's limited ability to share interrupts, of course, but keep in mind that those kinds of compromises were not nearly as obvious when IBM was designing the PC in 1980 and 1981. Many of the devices we plug into our computers today didn't even exist then. Also, component costs were much higher in the early 1980s, so what seems like a trivial expense now would have been more significant in those days. In fact, IBM chose the slower 8088 processor with its 8-bit bus instead of the full 16-bit 8086 just to reduce the cost of peripheral parts.--Tom Halfhill

I work on the technical-support staff for the New England Jo urnal of Medicine, supporting PCs, Macs, and Novell servers. I actually understand IRQs (interrupt requests), cascading, memory ports, and even segmented addressing, but that did me little good when I bought a CD-ROM drive. It took me 14 hours with three different brand units before I could get one installed and working properly in my 386. During the same week, my boss bought a CD-ROM for my Mac at the office, and it honestly took me less than five minutes from opening the box to viewing a sample CD.

The PC as we know it will never be PnP (Plug and Play). The ISA bus is not intelligent and cannot be made so; the DOS/Windows combination is even more pathetic. The only hope for PnP on non-Macs is a system that uses Windows NT or OS/2 with a PCMCIA or SCSI primary bus. PnP is just another case of Bill Gates ``inventing a vision'' of something that the Macintosh has been doing for seven years. Your article seemed to lead to the conclusion that PnP is a kludge that doesn't have a snowball's chance in Hades of success, but you never actually said so. I'd be curious to know why.

Don Leamy

New England Journal of Medicine

Waltham, MA

Yes, PnP is a kludge, and yes, it is merely a stepping stone to the real solution--and I made both points in my story. But I disagree that it doesn't have a chance for success or won't make life easier for millions of people. What's the alternative? Are PC users suddenly going to junk all their machines and buy systems based on an entirely new architecture? Or will they migrate in droves to the Macintosh? Not likely. For the vast majority of people, PnP will seem like wondrous technology. Why burst their bubble?--Tom Halfhill


Up to the Letters section contentsGo to previous article: Plug and Play Not Exactly NewGo to next article: Asking for WAN TroubleSearchSend a comment on this articleSubscribe to BYTE or BYTE on CD-ROM  
Flexible C++
Matthew Wilson
My approach to software engineering is far more pragmatic than it is theoretical--and no language better exemplifies this than C++.

more...

BYTE Digest

BYTE Digest editors every month analyze and evaluate the best articles from Information Week, EE Times, Dr. Dobb's Journal, Network Computing, Sys Admin, and dozens of other CMP publications—bringing you critical news and information about wireless communication, computer security, software development, embedded systems, and more!

Find out more

BYTE.com Store

BYTE CD-ROM
NOW, on one CD-ROM, you can instantly access more than 8 years of BYTE.
 
The Best of BYTE Volume 1: Programming Languages
The Best of BYTE
Volume 1: Programming Languages
In this issue of Best of BYTE, we bring together some of the leading programming language designers and implementors...

Copyright © 2005 CMP Media LLC, Privacy Policy, Your California Privacy rights, Terms of Service
Site comments: webmaster@byte.com
SDMG Web Sites: BYTE.com, C/C++ Users Journal, Dr. Dobb's Journal, MSDN Magazine, New Architect, SD Expo, SD Magazine, Sys Admin, The Perl Journal, UnixReview.com, Windows Developer Network