Path: utzoo!attcan!uunet!mcvax!enea!diab!pf
From: pf@diab.se (Per Fogelstr|m)
Newsgroups: comp.arch
Subject: Re: Blitters and design philosophy
Message-ID: <411@ma.diab.se>
Date: 9 Aug 88 07:13:49 GMT
References: <5254@june.cs.washington.edu> <76700032@p.cs.uiuc.edu> <480@m3. <7984@cup.portal.com>
Reply-To: pf@ma.UUCP (Per Fogelstr|m)
Organization: Diab Data AB, Taby, Sweden
Lines: 24

In article <7984@cup.portal.com> bcase@cup.portal.com writes:
>|At last something important. The specialized processor (NS8500 RGP) i am
>|using costs less than $100. ....................
>
>................ WRT the NS8500 stuff, what if I don't want to use a
>planar frame buffer because I *must* be backward compatible with some other
>organization?  Of course, if the special-puropse something fits like a glove,
>then great!

Well in that case i would use the TI 320?0 Graphics processor :-). But i don't
think you are completly right. We are planning to replace a HITACHI 63483
design with the RGP. And the Hitachi are by no means "planar". However we are
not using the "Replace if less than" etc. operations, and it helps ;-).
The reason for using planar architecture is SPEED and FLEXIBILITY. You will
have the same speed in a monochrome as in a 64+ deep frame buffer. And now
to the really nice things; It doesn't cost anything before i'm really
expanding!  Expansion is achived by adding a bitplane alu (BPU), the frame
buffer memory chips, and a shift register. And i don't have to rewrite my
software. The same software goes for both monochrome AND color!. (I don't
need to care for the X-window mfb/cfb nightmare).
By the way, For raster op's planar or pixel organization doesn't matter much
unless i have to do op's involving more than one plane. (Such as replace if
less or equal etc.) And if i have to do it the DP8500 can handle that to.
However it's not as fast as one could wish.  (About 5us to process a pixel).