Path: utzoo!attcan!uunet!cs.utexas.edu!usc!ginosko!xanth!mcnc!decvax!savax!thompson
From: thompson@savax.UUCP (thompson mark)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Denise/Paula/Agnus/Gary/Portia
Message-ID: <1060@savax.UUCP>
Date: 14 Aug 89 23:19:21 GMT
References: <1388@bnr-fos.UUCP> <1671@cs-spool.calgary.UUCP>
Reply-To: thompson@savax.UUCP (thompson mark)
Organization: Disturbing Products Inc.
Lines: 45

In article <1671@cs-spool.calgary.UUCP> deraadt@enme3.UUCP (Theo Deraadt) writes:
>On the 340x0, it's a little different. If you have one bit/pixel it works
>the same. If you have two bits/pixel, then two consecutive bits in memory
>generate a pixel. If you have 16 colors, you have 4 consecutive bits
>to a pixel. Because the shifting gets icky, you don't get non power-of-two
>bits/pixel. Shifting 3 bits at a time out of a 16bit word gets messy
>when you get to the end of the word :-) It is easier to build video
>shifting circuitry for pixel packing.
>
>There is a National graphics chip set [not sure about availability] that
>has a super blitter/display chip for each bitplane, the entire architecture
>is 32bit, and has a full graphics processor. I looked at a 10 or so page
>pamphlet on it, and it certainly was impressive. THIS THING HAD EVERYTHING,
>but it probably takes up a ton of board space.. the main processor had
>50ns cycles for some stuff...

The processor you refer to is the National DP8500 RGP and its associated
BITBLT processors (DP8511's). It is in fact only a 16 bit processor and
requires one DP8511 per bitplane. This means two things, many colors chew
up lots of board space (not to mention $$) and the number of bits per pixel
is essentialy fixed. The planar approach in RGP is a bit different than the
Amiga. In the RGP, all planes are accessed simultaneously in 16 pixel blocks.
In a 256 color design (8 bitplanes) this comes to a 128 bit data bus, which is
where it attains its BITBLT performance. It also means MANY MANY ram chips.
As far as BITBLT engines go though, it is the fastest one I know of.

>I certainly would much rather stay with a bitplaned approach. Everytime
>I think of displaying text on a nonbitplaned multi bit/pixel screen it
>scares the heck out of me. Of course these systems do text for you,
>but I still think bitplaning is better.

If all you ever want to do is move raster data around in memory quickly,
BITBLT architectures like the RGP and the Amiga are fine. But for doing
real graphics scene generation (ie. color shading), these systems fall flat
on their face. Shading requires pixel by pixel interpolation and unless the
architecture is optimized for fast single pixel access, rendering speed
will be horrible. Some sort of pixel cache can help, but when you include
Z-buffering, that becomes a mess. Most High-End systems organize the image
memory in a planar fashion, but it is accessed like a packed pixel (one pixel
at a time with all the planes at once).
--------------------------------------------------------------------------
|      Mark Thompson                                                     |
|      decvax!savax!thompson       Designing high performance graphics   |
|      (603)885-9583               silicon today for a better tomorrow.  |
--------------------------------------------------------------------------