From: gblock@csd4.csd.uwm.edu (Gregory R Block)
Subject: Re: Zorro III Stuff (Was: Guesses, et al.)
Organization: University of Wisconsin - Milwaukee
Date: Fri, 10 Apr 1992 09:22:03 GMT

daveh@cbmvax.commodore.com (Dave Haynie) writes:
: 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

So it doesn't use the PCLK at all?  I thought it used the 50mhz clock
for something.

And what happens on a 16MHz A3000?

: 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.
: 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 interconnecte
: 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.  

Well, you're right, I should have tried harder.  ;)  I wanted to know,
basically, how Buster created the strobes, and you told me.  Does the
bus, then, slow down to "16MHz" on a 16MHz A3000?

: 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 effec
: 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.  Als
: it's not 100% clear that any one given thing can cleanly be sorted into eithe
: the processor or I/O bin.  Video displays, for example, act like both.

True.  But newer buses (not alterations of old ones) are going to
blend the two together, kind of how yesterdays RISC architectural
paradigms became part of CISC... pipelining, architectures,
parallelism, all crossing over into a big mess.  That's what I was
referring to happening to buses.  I can see that happening, anyways
(in the future).

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

So, given your view that it's either Multiprocessor with I/O on the
side or I/O with Multiprocessor on the side, do you see ZorroIII
fitting into the latter? (that's my guess...)

: 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.

So what mechanism could be included to control that?  Is it possible
to give it "priority"?  Or doesn't the current design make that feasible?

: 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 
: hardware problem.  With a bitplane-oriented machine, it would be pretty simpl
: 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.

That's always true.  It's the same with multiprocessing, people
attacking with pure MIPS on a single-chip mega-risc arch instead of
taking some other route which could yield similar results.  It's more
of a "leapfrog" kind of thing.  (looking back, though, that isn't the
best of analogies...)

: 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....

No, it's true.  However, any attempt to make use of the architecture
with any program other than BLAZEmacs causes the computer to incur a
1000-megaton explosion centered in the Denise.  Suffice to say that
for a billionth of a second, you'll see lots of colors.

Besides, BLAZEmacs has everything you'd ever need...  Architecture
doesn't matter.  It's a Quantum Physics thing.

: Better keep up that martial arts practice...

:)

Greg
-- 
 __________________________________________________________________________
|				     The Chesterfield Electronic Towel (TM)|
|gblock@csd4.csd.uwm.edu                    Don't leave Krikkit without it!|
|__________________________________________________________________________|
Newsgroups: comp.sys.amiga.advocacy