Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!ginosko!usc!apple!oliveb!amiga!cbmvax!daveh
From: daveh@cbmvax.UUCP (Dave Haynie)
Newsgroups: comp.sys.amiga
Subject: Re: Bus Master Boards
Message-ID: <8103@cbmvax.UUCP>
Date: 5 Oct 89 16:28:33 GMT
References: <1956@convex.UUCP>
Organization: Commodore Technology, West Chester, PA
Lines: 93

in article <1956@convex.UUCP>, swarren@eugene.uucp (Steve Warren) says:
> Keywords: bus master A2000 boards

> Which brings up a point, and I would appreciate it if someone really
> knowledgeable about the Amiga bus would answer.  I keep seeing
> articles about IBM's MC bus standard, and as I read them I keep
> trying to find what it is about MC that is so special.  

I think lots of people are trying to figure out the same thing.  Which
basically points to the truth -- there's nothing all that special about
the new IBM Microchannel bus.  It's a basic 32 bit, non-multiplexed bus
with fairly arbitrated multimaster capability and a pseudo-autoconfiguration
mechanism.  

All the hum about it was generated, I suspect, for two reasons.  First of 
all, because it has the IBM name on it, which some folks respect for some 
reason (I guess before my time -- I've only been active in the computer 
business for about 10 years).  And, if nothing else, IBM is BIG, so anything
they do is bound to have an effect, even if it's a negative effect.

Secondly, because of how bad the IBM XT/AT buses are.  For instance, the 
XT/AT buses don't allow interrupts to be shared, so if one card uses a 
particular interrupt line, no other card can.  Soon you run out of interrupts.  
Also, there's no way for an expansion card to master the bus, and the DMA 
controller in these systems (which, in an ideal world, could run transfers 
at 1/2 the rate of a bus master for things like hard disk transfers, etc) is 
so slow, most folks opt for using programmed I/O (eg, the CPU does the 
transfers) anyway.  And of course, XT/AT cards are simply I/O and memory
mapped at fixed locations, so when you add one, you typically have to adjust
jumpers so that your new board doesn't conflict with any of the older boards.

All of these issues were addressed in the Amiga Bus originally, so other than
for speed and arbitration fairness, the Microchannel bus doesn't sound all 
that amazing compared to the Amiga bus.  Or the NuBus in the Mac II.  In
fact, while I haven't actually used a Microchannel system, the stories I've 
heard about it make it's autoconfiguration mechanism (or perhaps just the
OS/2 interface to this mechanism) real bad compared to what you have in the
Amiga system.  For instance, when you plug a memory card in the Amiga bus,
it gets added into the memory pool on the next powerup, automatically.  If
you remove it, it goes away.  If you add a hardware device, like this Bridge
Card I have here, it's device driver gets automatically bound in on startup
(assuming you copied the driver into SYS:Expansion on your boot disk), when
you remove the card, the driver doesn't get started.  Apparently, on the
Microchannel, you have to specifically tell the system to add a card in.  And
when you remove a card, you have to specifically tell the system it's leaving,
or it won't boot.  Like I said, I haven't tried it, but one of the folks
discussing this on BIX said that you've basically "traded hardware jumpers
for software jumpers".  Amigas generally work without any jumpers, and I
gather Mac IIs work about as well.  So it's obvious that IBM doesn't have all
the answers.

> I recently saw an article which promoted an 80 MB/s bus speed on 32-bit MC
> busses, which I didn't credit (it was some kind of marketing announcement,
> and I don't think they had the hardware to demonstrate these speeds).

You have to watch bus speed claims, because a maximum rate rarely tells you
the whole story.  For instance, the Mac NuBus has a top speed around 32
MB/s (as I recall), but the CPU access is closer to 3.5 MB/s.  Top speed is
only in burst mode, which typically can only be achieved between I/O 
devices.

So take the base maximum stated speed of MC bus, which is 20 MB/s (I don't
know what mode; chances are the CPU isn't talking this fast on the bus).
Now double the mimimum bus cycle time; now you're at 40MB/s.  Now, instead
of sending address on 32 wires and data on another 32, send address out
on 32 wires, let whoever's listening latch that address, and then send
data out on 64 wires.  Now you're up to 80MB/s.  That's essentially, if not
exactly, what IBM's doing here.  Depending on how clever they were when they
designed the bus, existing implementations may or may not be able to support 
these new modes.  Certainly existing implementations won't all of a sudden
start sending 64 bit data packets, but they may work OK with bus master and
slave cards that want to talk that way between each other.  Some company's
recently discussed a very similar 64 bit approach on VME bus, and you can
certainly imagine that the same principles can be applied to any bus that's
sophisticated enough to keep the "old-mode" cards at least quiet while any
"new-mode" things are on the bus.

> It looked to me like they were getting excited because it allowed 
> auto-config.

To a large extent, they were -- that's what most of the world sees in the 
new IBM bus.  Then again, to a part of the computer world, IBM is computers,
and if they don't have it, it doesn't exist.  In fact, you can often 
understand a conversation between IBMers if you substitute the phrase
"has finally adpoted" for the word "invented".  As in, "IBM invented the
3.5 inch microfloppy drive", "IBM invented an autoconfiguring expansion bus",
etc.

> --Steve
-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
                    Too much of everything is just enough