🚀 go-pugleaf

In article <43140@beno.seismo.CSS.GOV> mo@seismo.CSS.GOV (Mike O'Dell) writes:
>The only problem with bit blitters is that none of the chips available i
>actually do what you want in all the cases.....A vanilla 68K can blit faster 
>than any currently known hardware chip.  Now that Apple has a Cray, maybe 
>they will design some hardware which actually does what the software types 
>need, but for now, it doesn't exist.....
>
>So, who keeps perpetuaing this myth that you gotta have hardware or it ain't 
>chic??
>
>	-Mike O'Dell

um, mike, i disagree.  on several points.

#1.  There are some very good graphics chips available today.  My favorite is
the TI 34010, which is really a graphics CPU, rather than just a graphics 
turbocharger.  It has it's own assembler, etc. and is as programmable as any
well-rounded microprocessor.

It handles ALL graphics - not just bitblts - in color, and is VERY fast.  TI
sells the chip as well as a development board for the PC.  The chip can stand
alone on a display card with oodles of memory, as opposed to a "graphics chip"
such as the i80786, which typically requires external processor support of
some kind.

#2.  A stock 68K - even running at, say, 10Mhz no-wait - is NOT very fast as
a "graphics processor."  I know that "not very fast" is a relative term, but
I have worked with the Bell Labs bitblt code (originally by Rob Pike) and have
written my own, using self-modifying code, etc. such that for a monochrome
device, the inner blt loop was optimally less than 14 words (!).  Believe me,
it is not HALF as fast as the aforementioned 34010.  Sorry.  Admit it - scroll
speed on the Mac is not as fast as say, a character-generator based terminal,
is it?  So there IS room for improvement.

#3.  The point of graphics accelerators is to off-load the main CPU so it can
be doing "more important" things.  The 'ole "two heads are better than one"
syndrome.  This becomes especially important in multi-tasking (read A/UX)
environments. 

Ideally, tasks are distributed among specialized hardware that can expedite 
them, but in a real-world situation, cost trade-offs are usually involved, 
so the CPU is forced to do the dirty work because "slaves" are too expensive.

-- jdm
-- 
in real life:  John D. Miller, Graphic Software Systems, Inc., Beaverton OR
...!{tektronix!verdix}!sequent!gssc!jdm                      (503) 641-2200