Re: Panic at boot on 4/330 with cgfour and cgsix

Mouse <[email protected]>
Newsgroups gmane.os.netbsd.ports.sparc
Message-ID <[email protected]>
> 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		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.