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