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