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