Framebuffers [was Re: Panic at boot on 4/330 with cgfour and cgsix]

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> There was some Sun framebuffer I used back in the '80s - I forget
>> which one - that had eight bits per pixel, but, in addition to
>> 900x1152 8pp, it also presented eight 1bpp views of the same video
>> RAM to the host, one per bitplane.
> Maybe it's cgtwo, no overlay bwtwo plane but it can be used like
> bwtwo as "monochrome" mode:

Well, the one I was talking about could be used as *eight* bwtwos, one
per bitplane.  The display hardware was always displaying the video RAM
the same way; the only difference was the CPU's view of the video RAM:
with the eight bits of each pixel either packed into a single byte or
scattered across eight 1bpp views.  (Relatively easy to do in hardware;
just reroute address lines.)

If you want to actually use one of them as a 1bpp display, you have to
load the RAMDAC's colourmap so only the bitplane in question actually
affects the resulting RGB triple.  (This meant that the multi-screen
ddx layer could flip between 1bpp screens very fast; all that was
involved was reloading the hardware's colourmap.)  By suitable
colourmap hackery, it would even have been possible to, for example,
treat those eight bits as four 2bpp PseudoColor screens, though it
wouldn't have been nearly as easy to handle the X server side of it -
you would have to either use the 8bpp view and write only two bits
within each pixel or split the 2bpp screen into two 1bpp framebuffers
under the hood.

But, that said, "cg2" does fit with what forty-year-old memory I have
of doing that.  And it's entirely possible the software you cite just
doesn't use the other seven 1bpp views.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B