From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: Zorro III Stuff (Was: Guesses, et al.)
Date: 9 Apr 92 17:26:16 GMT
Reply-To: daveh@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA

In article <1992Apr7.153522.24539@uwm.edu> gblock@csd4.csd.uwm.edu (Gregory R Block) writes:
>daveh@cbmvax.commodore.com (Dave Haynie) writes:
>[comparisons of expansion architecture deleted]
>: Zorro III doesn't use a bus clock, it uses asynchronous strobes to govern 
>: the relationships between master and slave signals.  This has the advantage of
>: making it clock speed independent.  

>Where are the strobes picked up from?  I take it they're produced in
>whatever the 3000 uses as a Gary (I can't remember the name, sorry.
>;) based on the speed of the processor's clock?

The Buster chip is the bus controller/protocol translator.  It has state 
machines based on the motherboard clock, since that's the most efficient way
to get the '030 protocols out in Zorro III form.  The main point here is that 
other Zorro III implementations (future Amigas or other Zorro III bus masters)
can go as fast as their implementations allow, as can bus slaves; they always
meet on equal terms during a bus transaction.

>: The A3000 implementation, at a reachable 20MB/s without burst, represents 
>: the low end in Zorro III -- it's very realistic to expect better in future 
>: machines.  

>So the 3000 is "hardwired", to use a word, to its current "strobe
>patterns"? (trying incredibly hard to NOT use buzzwords...)

I'm not sure what you're after here; maybe you need to try harder next time :).
Like any other design, whether its a memory controller, a CPU, or whatever,
the A3000's Zorro III implementation is based on a fixed set of interconnected
chips, defined by the architecture I designed for this machine.  That design
was, as are most things, a decision based on the available technology we had
available at the time.  It shouldn't surprise anyone that in the 3 years 
since then, new technologies have become available that would let one build a
much more efficient Zorro III bus master.  

>: don't expect one bus to necessarily solve both I/O and multiprocessor 
>: interconnect questions, for example.  

>It seems they're slowly changing their mind, however.  ;)  

I don't think so.  Sure, the I/O bus people add stuff that makes 
multiprocessing possible, and the processor interconnect folks add I/O
capabilities.  In some cases, you're going to wind up with a multilevel effect
anyway; for example, multiple processor cluster boards right now sit on VME
buses.  Making VME handle the multiprocessor traffic better is a good idea,
but it doesn't ever make VME the bus of choice for the cluster interconnect.
Same things could be said about Sun's MBus vs. SBus, or other tradeoffs.  Also,
it's not 100% clear that any one given thing can cleanly be sorted into either
the processor or I/O bin.  Video displays, for example, act like both.

>Was ZorroIII a completely made-up design, or was it based around some
>other bus?

Well, it had to support Zorro II as a subset.  Other than that restriction,
I made it up from scratch.

>Under the 3000, would it matter if the 2410 is banging on chip ram?
>Could the A2410 get locked out from chip on that design?  I know it
>can happen on the 2000, but I'm not up enough on the 3000...  I
>wasn't sure if the custom chips could still lock out cpu access to chip.

It can still happen on an A3000.  The 3000's Buster design can greatly reduce
bus acquisition lag relative to an A2000 if there's nothing jamming the Chip
bus, but you still have determinism problems if the Chips are running 
saturated.  Bus acquisition isn't really the 2410's problem, though; its
problem is run-time determinism.  Since the 34010 is directly involved in the
display generation, it can't stand to be wait stated for very long.

>: On the other hand, a GUI that can effectively manage a deep display without
>: incuring the overhead itself would be a wonder

>But a GUI managing a deep display and itself using 24-bits are two
>different things, aren't they?  

The problem is, how do you run the GUI on a display that only incurs the 
penalty for 24-bit data if there's 24-bit data to deal with?  This is really a
hardware problem.  With a bitplane-oriented machine, it would be pretty simple
to manage this with an alpha channel.  Your hardware would use only 8-planes 
(or whatever) if the alpha plane were clear (with CLUT lookup into 24-bit
color), 24-planes if it were set (obviously bypassing the CLUT).  Of course,
since you have to have 24-bits worth of memory available (but your display
device need not always fetch it as long as it can grab the alpha plane first),
this only saves CPU time.  One could argue that eventually, a cheap-enough
graphics processor will eliminate this problem with raw MGOPS rather than 
cleverness.

>BLAZEmacs will be out 3rd quarter of 2000, about the expected time of
>the next chipset from C=.  ;)  (Sorry, had to do that MB thing just
>once.  :)

Actually, I heard that running BLAZEmacs on your system would spontaneously
generate a new, highly advanced Amiga chip architecture for you.  Or was that
just marketing hype....

>Soon, the world will become a caste-based warrior society, when working at 
>home is more than just a job, it's a life-threatening experience.

Better keep up that martial arts practice...


-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      BIX: hazy
   "We can't be silent, because they might be giants" - The Might Be Giants
 
Newsgroups: comp.sys.amiga.advocacy