Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!apple!netcom!hue
From: hue@netcom.UUCP (Jonathan Hue)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: Bitplanes - good or bad
Keywords: writing a pixel
Message-ID: <10152@netcom.UUCP>
Date: 29 Mar 90 04:49:43 GMT
References: <5917@tekig5.PEN.TEK.COM>
Organization: NetCom- The Bay Area's Public Access Unix System {408 249-0290 guest}
Lines: 28

In article <5917@tekig5.PEN.TEK.COM> wayneck@tekig5.PEN.TEK.COM (Wayne C Knapp) writes:
>
>Clearly this would not compatible with the current system.  If it was done
>on the Amiga it would have to be in addition to the current modes.  However,
>a packed pixel mode would have much better performance for many types of
>graphics applications.

There's a way to be compatible.  We had a similar problem a few years back
when we were designing a frame buffer.  The software people couldn't decide
if they wanted four adjacent bytes to be RGBA for one pixel, or four adjacent
pixels of R, G, B, or A.  There were good reasons for either type of access.
What we finally did was have the frame buffer map to two separate address
ranges, when you accessed through one range of addresses you got RGBARGBARGBA,
when you accessed through the other you got

			  RRRRRRRRRRRRRRRR...
			  BBBBBBBBBBBBBBBB...
			  GGGGGGGGGGGGGGGG...
			  AAAAAAAAAAAAAAAA...

Going to a bitplane oriented system introduces more complexity, but it could
be done.  One problem is that VRAM (if you decide to use it) is usually 4-bits
wide; 1-bit wide VRAM would make things much simpler.  If you support "frame
buffer anywhere in CHIP RAM", like it is today, you would probably run into
a few more problems, and some alignment restrictions.


-Jonathan