Port-sparc archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Panic at boot on 4/330 with cgfour and cgsix
> Maybe you mean this:
> typedef struct {
> u_char mpixel[CG4_MELEN]; /* bit-per-pixel memory */
> u_char epixel[CG4_MELEN]; /* enable plane */
> u_char cpixel[CG4_HEIGHT][CG4_WIDTH]; /* byte-per-pixel memory */
> } *CG4Ptr, CG4Rec;
That looks roughly right, assuming mapping is set up correctly. Based
on a .h file I found, it looks to me as though the 1bpp overlay is at
offset 0x100000, enable at 0x300000, and 8bpp at 0x500000; if that's
correct, that struct would require each of the three pieces to be
mapped separately.
> CG4Switch(ScreenPtr pScreen, int select)
...
> (void) memset ((char *)fb->epixel, select ? ~0 : 0, CG4_MELEN);
Well...that looks rudimentary, but sufficient if just flipping between
1bpp and 8bpp is enough for the use case in question.
There was some Sun framebuffer I used back in the '80s - I forget which
one - that had eight bits per ppixel, but, in addition to 900x1152 8pp,
it also presented eight 1bpp views of the same video RAM to the host,
one per bitplane. I recall building a ddx layer which presented it as
nine screens, an 8bpp screen and eight 1bpp screens, though as I recall
I didn't actually use it for much. It did lead me to discover how few
clients handled 1bpp PseudoColor well!
/~\ 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
Home |
Main Index |
Thread Index |
Old Index