leein@uicsrd.csrd.uiuc.edu (06/25/88)
A friend of mine asked me to post the following message to the net.
---------------------------------------------------
Dear PC clone makers;
I have some thought to share with you. Why do you not say no to IBM's
proprietary Micro Channel Bus Architecture? The possible answer I can
expect from such companies as Ta??? and De?? is that they do not have
the technology to develop their own version of OS/2 for an advanced
32-bit bus they might choose instead of MCA. I think this is the
primary reason the other PC clone makers are still stuck to AT
bus which is out of dated for the present 386 age. I think this
is what everyone outside the clone business does not understand
about why they are still stuck to the slow AT bus or just follow IBM's
way blindly.
Another important reason I come up with is that they are not
adventurous any more as they were when they started their business.
(Co???? and De??). Engineers might have had such an idea. However it can't
go through the manager level as it did not in XEROX PARC about
9 years ago.
So listen to me and gather as OSF members did, and choose a
new advanced bus like NuBus (which is in the public domain) or
Multibus II (which is supposedly better (? well...) for the Intel chips) and
make your own version of OS/2 to this new advanced bus standard.
This time just make such revised version of OS/2 compatible
to MS's or IBM's OS/2 as much as possible. Please don't try to
make it incompatible as OSF is now doing for UNIX. Then customers
won't buy your machines with such OS.
To accomplish this job there must be some initiatives. Possible
candiadate companies are HP, UNYSYS, and AT&T which sell PC clones. I think
only these companies have engineers who can do both hardware and
software projects. Who is going to decide on such a project? Sadly,
the managereal personels do. So show this message to them and let them
act.
One caution about the project. Just remember what happened to
ADA and PL/1 (and OSF's UNIX next time), which are the outcomes
of committee, and compare them with C, PASCAL, and Modula-2 which are
the works of one or two veteran designers. Managers usually don't
understand how things are going.
Thanks.
H. SONG
song@uispg.csl.uiuc.edupete@octopus.UUCP (Pete Holzmann) (06/26/88)
In article <42900016@uicsrd.csrd.uiuc.edu> leein@uicsrd.csrd.uiuc.edu writes: >Dear PC clone makers; >...Why do you not say no to IBM's >proprietary Micro Channel Bus Architecture? The possible answer I can >expect from such companies as Ta??? and De?? is that they do not have >the technology to develop their own version of OS/2 for an advanced >32-bit bus they might choose instead of MCA. I think this is the >primary reason the other PC clone makers are still stuck to AT >bus which is out of dated for the present 386 age. >... > So listen to me and gather as OSF members did, and choose a >new advanced bus like NuBus (which is in the public domain) or >Multibus II (which is supposedly better (? well...) for the Intel chips) and >make your own version of OS/2 to this new advanced bus standard. *If* the AT bus were really 'out of date' for '386 machines, then it might make sense to switch to a completely new architecture. If that were true, though, they'd all jump to IBM's lead and use MCA. IBM, unfortunately, *does* set the standards in the eyes of the big corporations, and that's what counts. We may not like it, but its the truth. Fortunately, the big corporations have accepted another standard for PC bus architecture (the AT bus), and everybody is using it. Is it *really* out of date? Too slow? I think not! Sure, it doesn't incorporate all the latest in bus architecture knowledge, but then it didn't do that even when first used! Consider IBM's claims for MCA, and the facts regarding the AT bus, and decide for yourself: 1) MCA is cleaner, newer, nicer, etc etc: All true, all irrelevant. On a bus, what works is what counts! The AT bus was supposedly clean, new and nice when implemented, but all the hardware people in the world surely knew that it wasn't. Didn't make any difference at all. 2) MCA is faster. AT bus is too slow. Various manufacturers have SCSI controllers that can pump 4-5 MB/sec through the 'slow' AT bus. There isn't a MAINFRAME disk drive that can use up that bandwidth, as far as I know. Let alone a wimpy Winchester drive! I've never seen a situation yet where the AT bus was the limiting factor for I/O. Usually it is the rather slow DMA chip on the AT motherboard. When faster throughput is needed, board makers put their own, faster, DMA controller on their board. The AT bus can become a bottleneck for memory access. But board makers seem to be doing a good job of getting around this. A 32 bit extension standard would help a lot in allowing standardized 32 bit RAM cards for 386 machines. 3) MCA handles multiple CPU's. So does the AT bus. A kludge, true, but you can get a 68020, 32032, etc coprocessor board for your AT. Even for a PC for that matter, but then the 8 bit bus really starts to cause trouble! This brings up the real limitation of the 'AT' bus: we need a standardized 32 bit extension! The MCA can handle >2 processors, so someday and in some high end applications, the AT bus may be a liability for this. My conclusion: the clone-makers need to pick a 32-bit AT bus extension standard. There is little engineering reason (right now) to go to the MCA. Pete PS: If you're inclined to believe IBM's marketing hype regarding how wonderful and unique the MCA is, I suggest you think about their OS/2 announcement at COMDEX last fall. They were proclaiming that with OS/2, you could *finally* get multitasking on a PC, while, in another booth, Quarterdeck [Desqview] was merrily DEMONSTRATING multitasking on various flavors of PC's, using lots of existing software, etc etc. It was a sad commentary on the power of marketing. -- OOO __| ___ Peter Holzmann, Octopus Enterprises OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014 OOOOO \___/ UUCP: {hpda,pyramid}!octopus!pete ___| \_____ Phone: 408/996-7746
berger@clio.las.uiuc.edu (06/28/88)
I'm amazed to see somebody try to make a case for AVOIDING standards in
this day and age. The worst problem with the original PC architecture
was that IBM's extraordinarily slow implementation of basic ms-dos
features forced software writers to put hardware-specific code into
their programs. This turned all the superior low-cost competitors to
the PC into orphans and doomed them to a premature death.
Unfortunately, the vast majority of PC type software on the market still
carries large amounts of hardware-specific code, necessitating hardware-
compatible clones. The taiwanese manufacturers are capable these days of
engineering a functional competitor for the PS-2 line, but how will they
convince all the software publishers to make generic versions of the
programs they've been selling with hardware-specific code for 5 or more
years?
Mike Berger
Department of Statistics
Science, Technology, and Society
University of Illinois
berger@clio.las.uiuc.edu
{ihnp4 | convex | pur-ee}!uiucuxc!clio!bergerdan@srs.UUCP (Dan Kegel) (06/28/88)
pete@octopus.UUCP (Pete Holzmann) writes: > leein@uicsrd.csrd.uiuc.edu writes: >>Dear PC clone makers; >> Gather as OSF members did, and choose a new advanced bus like NuBus >> (which is in the public domain) ... > > [ summary: ] > The AT bus is plenty fast; all it needs is a 32-bit address extension. > Most applications don't need multiple CPU's. > Let's extend the AT bus- there is no good engineering reason to switch > to MCA or anything else. The AT-bus is sufficient for here and now; however, some people will eventually need machines with large shared address spaces that the AT bus just can't provide, even with a 32-bit extension. Let's make a clean break, rather than add a kludge atop a kludge atop a poor bus. Choosing a standard bus will have the benefits that boards developed for it will be usable on other computers, and vice versa. The Nu-Bus is a logical choice because it is low-cost compared to busses like VME or Multibus, it is certainly up to the job, and there are already many very nifty boards available for it (e.g. RISC coprocessor boards). It is also more reliable than the AT bus; its sockets are pin-and-plug, rather than edge-card. As a hardware and software engineer who deals with workstations, I am very excited by the prospect of a single bus for the major low-cost 32-bit workstations (the PC 386 and the Mac II); with only one bus to target, hardware designers would have an easier time getting to market, and buyers would have a better variety to choose from. -- Dan Kegel "Take this job..." srs!dan@cs.rochester.edu rochester!srs!dan dan%srs.uucp@harvard.harvard.edu
farren@gethen.UUCP (Michael J. Farren) (06/30/88)
In article <257@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) writes: [Before I start, one question: Mr. Holzmann, have you ever designed a high-speed digital bus? I have. Now, on with the show...] >1) MCA is cleaner, newer, nicer, etc etc: > All true, all irrelevant. On a bus, what works is what counts! This is true. However, what is NOT true is the claim that the AT bus "works". No 32-bit data/address path, insufficient DMA and interrupt support, insufficient attention to loading and timing details essential to truly high-speed operation, and a god-awful electrical emissions characteristic. I don't blame IBM one bit for getting rid of the damned thing. >3) MCA handles multiple CPU's. > So does the AT bus. A kludge, true, Not a kludge. A disaster. True coprocessing is damn near impossible. >My conclusion: the clone-makers need to pick a 32-bit AT bus extension > standard. There is little engineering reason (right now) to go to the > MCA. Unless you count greater reliability, better support for advanced architecture, better support for I/O, greater noise resistance, less emissions problems (therefore easier to get FCC type approval, therefore cheaper), etc.... Not that I think that MCA is the BEST bus around, mind, but anyone who claims that the AT bus is sufficient is talking through his engineering hat. -- Michael J. Farren | "INVESTIGATE your point of view, don't just {ucbvax, uunet, hoptoad}! | dogmatize it! Reflect on it and re-evaluate unisoft!gethen!farren | it. You may want to change your mind someday." gethen!farren@lll-winken.llnl.gov ----- Tom Reingold, from alt.flame
pete@octopus.UUCP (Pete Holzmann) (07/01/88)
In article <978@gethen.UUCP> farren@gethen.UUCP (Michael J. Farren) writes: >[Before I start, one question: Mr. Holzmann, have you ever designed a > high-speed digital bus? I have. Now, on with the show...] Not personally designed. Worked at the gut level on, yes. Been around for FCC hassles, yes. Is a 295 Mbit digital telecommunications architecture fast enough for you? >>My conclusion: the clone-makers need to pick a 32-bit AT bus exBension >> standard. There is little engineering reason (right now) to go to the ^^^^^^^^^^^ a VERY bad choice of word there on my part. Sorry! >> MCA. > >Unless you count greater reliability, better support for advanced architecture, >better support for I/O, greater noise resistance, less emissions problems >(therefore easier to get FCC type approval, therefore cheaper), etc.... > >Not that I think that MCA is the BEST bus around, mind, but anyone who >claims that the AT bus is sufficient is talking through his engineering >hat. Actually, I was talking from under my user's hat. I guess I shouldn't let myself go like that! :-) I shouldn't have said 'little engineering reason to go to MCA' without saying: Users want a compatible bus so they can keep their investment in boards. I guess my attitude is that the AT bus is going to survive a long time, simply because there is so much stuff out there that uses it. I agree, the AT bus is an engineering disaster. But users don't see that, and it looks like there's enough engineering miracles left to keep users happy as long as they don't need 32 bit data paths. On the other hand, I *do* agree that a new bus standard is needed. I really like what the clone-makers are doing. It looks like there is an active push going for the NuBus. Wouldn't it be amazing if Mac and PC boards eventually became compatible with each other!?! That'll be the day. >>1) MCA is cleaner, newer, nicer, etc etc: >> All true, all irrelevant. On a bus, what works is what counts! > >This is true. However, what is NOT true is the claim that the AT bus >"works". No 32-bit data/address path, insufficient DMA and interrupt >support, insufficient attention to loading and timing details essential >to truly high-speed operation, and a god-awful electrical emissions >characteristic. I es?n't blame IBM one bit for getting rid of the damned >thing. From an engineering point of view, you are absolutely right. But from a user's point of view, the AT bus is *great*. Just about everything is compatible. And there are new boards that get around the DMA problems. As an engineer, I appreciate with some amazement the amount of sweat that must have gone into making this stuff work on the AT bus. I'm also amazed at how well the users are insulated from gory details of timing, low level formats, and other stuff. Imagine an end user even adding their own printer port to a computer 10 years ago! It wasn't fun. Pete -- OOO __| ___ Peter Holzmann, Octopus Enterprises OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014 OOOOO \___/ UUCP: {hpda,pyramid}!octopus!pete ___| \_____ Phone: 408/996-7746
johnm@trsvax.UUCP (07/01/88)
> I'm amazed to see somebody try to make a case for AVOIDING standards in > this day and age. If anybody worked to AVOID standards it was IBM. NuBus would have been an equally good choice (and in fact was the one chosen by Apple and will likely be chosen by others) but instead they chose to spend the enormous amounts of money necessary to build a proprietary architecture. Now why do you suppose they did that? Could it be GREED!!!!!!!!!!!!! You don't suppose that they knew that if they didn't come up with a proprietary architecture that it would have meant less revenue for them (no licensing agreements to third party vendors, and reduced sales of OEM plugin cards). You don't suppose that they knew that it would make clones of the machine easier and thus loose them some of their almighty profit do you? You think it was as one of IBM's engineers said, "We didn't set out to make a proprietary bus system, we just wanted to make a better one." Yeah, I'm convinced... John Munsch "Shave and a haircut. No TOON can resist that"
mcdonald@uxe.cso.uiuc.edu (07/02/88)
>Imagine an end user even adding their own printer >port to a computer 10 years ago! It wasn't fun. I don't understand this remark! What do you mean by "fun"? I added ports to my PDP-11's 10 years ago and to my PDP-8 20 years ago. I had two choices: I could buy a card from DEC and stuff it in the 11, or I could build my own from the complete bus description in the "PDP-11 handbook". Plugging in was too trivial to be fun, building my own WAS fun - easy, too, since I like playing with hardware. I honestly don't remember about printer ports for the 8, but I built a multichannel scaler for one. That was lots of little cards, tied together with 2086 wire-wrapped wires. Doug McDonald
madd@bu-cs.BU.EDU (Jim Frost) (07/03/88)
In article <257@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) writes: |3) MCA handles multiple CPU's. | So does the AT bus. A kludge, true, but you can get a 68020, 32032, | etc coprocessor board for your AT. Even for a PC for that matter, | but then the 8 bit bus really starts to cause trouble! This brings | up the real limitation of the 'AT' bus: we need a standardized 32 | bit extension! The MCA can handle >2 processors, so someday and | in some high end applications, the AT bus may be a liability for | this. I have used an AT with 8 coprocessors. And I know for a fact it would work with 31, since the software which coordinates all of this is designed for it. So: you don't need the MCA bus for even that many processors. You just have to break your back to make it work. (Please don't scream at me about how difficult some bus functions are with this setup. It's not the point.) There is a point that you didn't bring up regarding the bus. The MCA bus handles stacked interrupts, which is something that that AT bus sorely needs if you are trying to handle lots of I/O at high rates of speed. You might note that this is exactly the kind of application IBM designed the bus for, since the PS/2 series is supposed to help with mainframe connectivity. And mainframes are IBM's business, not PC's. BTW, the MCA architecture isn't exactly state of the art. IBM has been doing much the same (and even more advanced architectures) for a long time. It's novel for a PC to have that architecture, but it's not state of the art. Cheers, jim frost madd@bu-it.bu.edu
neese@cpe.UUCP (07/05/88)
>>1) MCA is cleaner, newer, nicer, etc etc: >> All true, all irrelevant. On a bus, what works is what counts! > >This is true. However, what is NOT true is the claim that the AT bus >"works". No 32-bit data/address path, insufficient DMA and interrupt >support, insufficient attention to loading and timing details essential >to truly high-speed operation, and a god-awful electrical emissions >characteristic. I don't blame IBM one bit for getting rid of the damned >thing. What kind of adapter are you going to plug into your 32bit bus slot? A memory card? Well that is fine, but every MC Memory card I have seen slows the over all throughput by up to 400% when accesses occur on this card. Show me where the MC Bus actually helps and stop with the vague comparisons. >>3) MCA handles multiple CPU's. >> So does the AT bus. A kludge, true, > >Not a kludge. A disaster. True coprocessing is damn near impossible. The implementation in the MC bus is better, but overhead is high. True coprocessing is NOT damn near impossible. It takes more attention to detail. Do your homework before making brash statements. >>My conclusion: the clone-makers need to pick a 32-bit AT bus extension >> standard. There is little engineering reason (right now) to go to the >> MCA. > >Unless you count greater reliability, better support for advanced architecture, >better support for I/O, greater noise resistance, less emissions problems >(therefore easier to get FCC type approval, therefore cheaper), etc.... > >Not that I think that MCA is the BEST bus around, mind, but anyone who >claims that the AT bus is sufficient is talking through his engineering >hat. Actually each bus has merits of its own, it is the implementation that should decide which bus is better. Peripherals for the MC bus cost more even if you don't use the wizz-bang features of the bus. The form-factor of the MC bus limits the functionality of the adapter card as well. This is important as there are fewer slots in the MC implementations as compared to the AT imple- metations of the day. Roy Neese UUCP @ ihnp4!sys!cpe!neese
neese@cpe.UUCP (07/05/88)
>Dear PC clone makers; > >I have some thought to share with you. Why do you not say no to IBM's >proprietary Micro Channel Bus Architecture? The possible answer I can >expect from such companies as Ta??? and De?? is that they do not have >the technology to develop their own version of OS/2 for an advanced >32-bit bus they might choose instead of MCA. I think this is the >primary reason the other PC clone makers are still stuck to AT >bus which is out of dated for the present 386 age. I think this >is what everyone outside the clone business does not understand >about why they are still stuck to the slow AT bus or just follow IBM's >way blindly. Like it or not, we are stuck with what IBM does. They set the standards because of ignorance in the corporate level of America. Tandy has the technology to develope anything they want. Remember, before IBM jumped into the forray, Tandy developed the software and hardware for its own systems. You say the AT bus is outdated for 386 systems, and I say your wrong. The bus is being pushed, but it is not a limit to the performance of the 386 systems. Tandy has, for instance, a SCSI Adapter that allows BIOS level transfers rates of up to 2.9MBytes/sec with its newest 40/80MB SCSI Hard Drives. A lot of what is wrong with throughput on a 386 system is the peripherals that are being attached to the systems, not the adapters that go into the bus. The MC bus buys you no more throughput for HD's than the AT Bus. The HD throughput is strictly a factor of the HD and controller that is being used. Put the blame for lack of throughput where it belongs. Roy Neese UUCP @ ihnp4!sys1!cpe!neese
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (07/06/88)
There is a bus which allows multiple masters (DMA and CPUs look the
same) with a priority scheme, stacked interrupts, etc. It even allows
diferrent CPUs to reprioritize the interrupt handling. It has been in
continuous production since 1976 and is available with all Intel
processors (I suspect the 432 is no longer sold), 68k and NS32k family,
etc. This is the IEEE696 standard bus.
The last time I looked there were about 80 vendors selling hardware for
it. It's a true backplane system, no motherboard functions, and you can
switch or add processors at will, or run wierd things like a 68010 and
386 on the same system (yes I use custom software). It supports UNIX
and MSDOS implementations on appropriate CPU's.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -measgard@cpro.UUCP (J.R. Stoner) (07/06/88)
From article <11463@steinmetz.ge.com>, by davidsen@steinmetz.ge.com (William E. Davidsen Jr): _ There is a bus which allows multiple masters (DMA and CPUs look the _ same) with a priority scheme, stacked interrupts, etc. It even allows _ diferrent CPUs to reprioritize the interrupt handling. It has been in _ continuous production since 1976 and is available with all Intel _ processors (I suspect the 432 is no longer sold), 68k and NS32k family, _ etc. _This is the IEEE696 standard bus. Somebody call my name? Sorry, it was just rather refreshing to hear about a thing which CompuPro has had a substantial part in developing and not elicit the what-is-that? reaction. I get frustrated sometimes when people say you can't address COM1 in an S100 machine. Some people just can't get IBM out of their collective heads no matter how hard you bang on them. We get tech calls like this almost every day.
nelson@sun.soe.clarkson.edu (Russ Nelson) (07/06/88)
In article <401@cpro.UUCP> asgard@cpro.UUCP (J.R. Stoner) writes:
)From article <11463@steinmetz.ge.com>, by davidsen@steinmetz.ge.com (William E. Davidsen Jr):
)) There is a bus which allows multiple masters (DMA and CPUs look the
)) same) with a priority scheme, stacked interrupts, etc. It even allows
)) diferrent CPUs to reprioritize the interrupt handling. It has been in
)) continuous production since 1976 and is available with all Intel
)) processors (I suspect the 432 is no longer sold), 68k and NS32k family,
)) etc.
)
))This is the IEEE696 standard bus.
)
)Some people just can't get IBM out of their collective heads no
)matter how hard you bang on them.
The Zenith Z-100 has (had--no longer in production) a IEEE696 bus and
runs MS-LOSS and Microsoft Windows.
The third most interesting thing is that you had 768K of uninhibited
access, and another 192K of video ram that you could overlay with
memory. None of this 640K crap. Not only that, but the bus has 24
bits of addressing, so the choice of direct addressing or bank
switching is determined by the CPU board.
The second most interesting thing about the Z-100 was that it had two
processors, a 8085 and 8088, and it was designed back in 1983. At
that time, Zenith had models in the lab that ran as fast as 12 Mhz,
although the parts to do so where prohibitively expensive.
The most interesting thing about the Z-100 was that there was no such
thing as graphics mode--you were *always* in graphics mode.
Therefore, special fonts && double-high characters && italics &&
underlined && boldfaced && greek && boxes && lines && smiley faces if
u really want them are NO problem. Not only that, but the resolution
is 640x225x8. It was possible to reprogram the CRT controller for
640x240x8 as a true bitmap unlike the CGA && Herc and like the EGA.
You could also reprogram it for interlace to give 640x480x8, and there
are aftermarket products to bring it up to 640x480x16. Note that this
is on an *ordinary* monitor. (Disclaimer: interlace mode sucks, but
if you need the resolution, you need it.)
I was going to write an anti-aliased font driver for it, but I never
got around to it (Jerry Pournelle would have eaten it up).
Bobby Inman is quoted in the July 4 issue of PC Week as saying "I'm
not bothered at all by big companies coming in and setting standards,
but they need to do it early, not late. What bothers me when they
come in too late is that they grind up the smaller companies who were
in there in the beginning, and who did the important work in setting
the real standards."
--
Pray that Bush gets re-elected so that the Republicans will be blamed for it.farren@gethen.UUCP (Michael J. Farren) (07/07/88)
In article <12400006@cpe> neese@cpe.UUCP writes: > >The implementation in the MC bus is better, but overhead is high. True >coprocessing is NOT damn near impossible. It takes more attention to detail. >Do your homework before making brash statements. My homework: 18 years of experience, including 8 years designing multi- processor systems, from S-100 bus to proprietary bit-slice systems. 6 years of experience with PC bus issues. And experience with all of the existing coprocessor cards for the PC (all that I know about, anyhow). Damn near impossible is what I said, and damn near impossible is what I meant. If doing true coprocessing on the PC (AT) bus is so trivial, why haven't we seen cards that work, and work well? -- Michael J. Farren | "INVESTIGATE your point of view, don't just {ucbvax, uunet, hoptoad}! | dogmatize it! Reflect on it and re-evaluate unisoft!gethen!farren | it. You may want to change your mind someday." gethen!farren@lll-winken.llnl.gov ----- Tom Reingold, from alt.flame
boyne@hplvly.HP.COM (Art Boyne) (07/11/88)
farren@gethen.UUCP (Michael J. Farren) writes: > If doing true coprocessing on the PC (AT) bus is so trivial, why haven't > we seen cards that work, and work well? Have you looked at the "Viper" card available from Hewlett-Packard? I admit to working for HP, but in the division that makes voltmeters and data acquisition cardcages, and it seems to me that this 68000-based board running HP-BASIC and Pascal seems to work fairly well!
alvitar@madhat.UUCP (Phil Harbison) (07/25/88)
In article <4420008@hplvly.HP.COM>, boyne@hplvly.HP.COM (Art Boyne) writes: > farren@gethen.UUCP (Michael J. Farren) writes: > > > If doing true coprocessing on the PC (AT) bus is so trivial, why haven't > > we seen cards that work, and work well? > > Have you looked at the "Viper" card available from Hewlett-Packard? ... Coprocessor cards for the AT certainly exist, but most communicate with the systems through dual-port RAM or a DMA channel. I have not seen a true bus master for the AT bus, that is, a board that drives the address, data, and control lines after the motherboard tri-states those signals. This is probably because such an interface is difficult for the AT, and impossible for the XT. The original PC/XT bus had no multi-master capabilities whatsoever. This feature was kludged into the AT bus, but is difficult to use. To get control of the bus, you have to request service on a DMA channel, wait for a DMA acknowledge, then assert a signal that causes the motherboard to tri-state the bus. The protocol is very cumbersome compared to most modern busses. ---- Live: Phil Harbison UUCP: madhat!alvitar