Path: sparky!uunet!cbmvax!daveh
From: da...@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.advocacy
Subject: Zorro III Stuff (Was: Guesses, et al.)
Message-ID: <30097@cbmvax.commodore.com>
Date: 6 Apr 92 22:49:16 GMT
References: <mykes.1685@amiga0.SF-Bay.ORG> <1992Mar27.223201.16656@uwm.edu> <mykes.1839@amiga0.SF-Bay.ORG>
Reply-To: da...@cbmvax.commodore.com (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 115

In article <mykes.1...@amiga0.SF-Bay.ORG> my...@amiga0.SF-Bay.ORG (Mike Schwartz) writes:

>>That'll change.  The specs for Zorro III make it one of the best buses
>>available out of the competition.  It certainly walks all over NuBus,
>>to say the least.

>Believe it or not, Zorro III might quicly be even too slow.  It clearly
>is better than Mac or PC buses, though.  But imagine it at 100MHz.  

Zorro III can technically keep up with other 32-bit buses out there; it's
faster in practice than many PC and Mac implementations already.  You're going
to run into problems going much faster on any bus, which is why the top 
practical speeds of Zorro III, NuBus, EISA, MCA, etc. all seem to be around
the same point.  Going much faster then the practical limits on these buses
on an expandable backplane rather than a finely tuned motherboard will 
require BTL or GTL drivers, rather than the TTL used on most of today's buses
(MCA already defines a 160MB/s version that uses BTL, though there aren't
any implementations yet).

Now, one thing about Zorro III is that it can always improve with clock
speed, at least within the limits of what we can build in CMOS.  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.  The actual theoretical maximum speeds
on Zorro III are probably faster than you can likely get out of real TTL
levels; some 150MB/s using burst.  But the faster the clock you have to work
with, the closer to theoretical the bus can get, both in the relationship
between strobes and the synchronization delay you'll generally get at the
end of a bus cycle.  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.  Not that Zorro III will solve all problems; you
don't expect one bus to necessarily solve both I/O and multiprocessor 
interconnect questions, for example.  Consider also that we are talking about
personal systems here; bus speed tends to be one of the first things to go
in a PClone when you're taking about price wars, and Apple's never given all
that much consideration to it either.  Based on the success of the A2000's
expansion features, the reality that C='s not going to crank out a new
motherboard with one slightly new feature every three months, and my personal
philosophy which balks at such throw-away systems anyway, we found it important
to give the expansion bus such consideration.

>>The DMI and Rambrandt can run programs on their TI340x0 processor, so
>>there's a lot more possibility.  

The bus is always a bottleneck in some situations, but far less for intelligent
boards.  The "Draw a Circle" command for a dumb frame buffer results in all 
kinds of bus transactions between the host processor and display memory, as the
host processor draws a circle.  The same command ideally results in the 
"Draw a Circle" command being sent to the graphics processor on an intelligent
board.  At best, the bus starts acting more like a high speed network than a
memory interface.  This is firmly coupled multiprocessing, exactly what you
would like to have in an Amiga.

>But Zorro II and even Zorro III is going to be a bottleneck for a long
>time.  If my info is correct, you can only move data from the Amiga
>to the 340x0 boards 512 bytes (maybe it's 512K) at a time - across
>whatever bus you have.  And the 340x0 can't access the Amiga bus
>(how unfortunate).  

Actually, the A2410 can.  But, based on the memory determinism requirements
of the 34010, it's not safe to have it bang on Chip RAM or any other memory
that could lock the 34010 out for some time.  I'm no expert on either of these
processors, but I gather that the 34020 is much easier to deal with.

>I certainly wouldn't want to trade speed of the GUI for more colors in
>the GUI.  But if the colors were free, then the GUI can certainly benefit.

I don't think requiring the GUI to use more colors makes any sense at all.
Allowing it more colors per se is still going to pay a pretty high price for
something that's not useful.  Even if you had a fast 24-bit display, do you
really want to pay any additional processing or memory penalty so can, say,
have 24-bit icons?  Sure, it would look cool, but most folks have better
things to do than design 24-bit icons anyway.  256 color icons are overkill.
On the other hand, a GUI that can effectively manage a deep display without
incuring the overhead itself would be a wonder -- if you need 24-bit color,
supporting it optionally without necessarily having to switch mode all the
time would be fantastic.

>But ask Dan Barret about GUIs sometime :)  He'll advocate BLAZEMONGER as the
>GUI instead of some windowing/menu paradigm :):)  

Well, I'll take BLAZEMONGER over Emacs as my GUI any day of the week.

>Maybe a 3-D shaded video-game-like GUI might be even more productive (as in 
>Xerox Parc ROOMs).

Hey, that's what we all need to get these kids off their video games and onto
real fun.  Rather than clicking on the icon, you have to shoot it.  Rather than
pulling down a menu, you have to wrestle with it.  You can't move a window 
around until you beat it in a sword fight.  I love the idea!

>BTW, I use a SuperHires Interlaced workbench.  This uses 100% of the CHIP 
>bandwidth.  I have zero speed complaints.  None.  Nada.  

I think you'd complain loudly if you didn't have any Fast RAM...

>I've talked to the DMI people and their developers claim the DMI resolver
>can do 2K x 2K on a 1950 mintor.  Seems like 35ns pixels are indeed possible.

That I've got to see.  You can send any size pixel you like horizontally; 
monitors are, after all, analog.  But you can't necessarily read them.  The
1950 does a decent job with 35ns pixels, but I wouldn't place any bets on
being able to actually read 17.5ns pixels.  Vertically, on the other hand,
you're necessarily digital -- the monitor can only handle a range of horizontal
and vertical scan rates, and, well, you all can work out the mathematics: I 
think the 1950 maxxes out at maybe 35-something-kHz horizontal, 75-something-Hz
vertical, interlace of course optional.  I can't think of any obvious magic 
that would do a real 2K x 2K (as I said, REAL, not one of these VGA-with-anti-
aliasing-CLUT "effective resolution" deals).

-- 
Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      BIX: hazy
 "I used to be disgusted, now I try to be amused" - Elvis Costello