> First question: can I safely ignore all that color map stuff?  [...]
> I'm perfectly happy treating the board as 24 bit only, and I believe
> that color maps only come into play in 8 bpp mode, but I certainly
> could be wrong about that.

It depends on - to use the X terms - whether the 24bpp mode is
TrueColor or DirectColor.  If the former, you have no colormap; if the
latter, you probably have 768 bytes of colormap (256 bytes of map for
each primary).

> Second question: How/where do I mmap the board?

I'm not sure, but some of the following questions I can have a stab at.

> What process is mmap'ing me in the first place?  Xsun24?

Right.  (If you're using X; if not, whatever process it is....)

> I actually thought the kernel would do it at probe time, but some
> simple printf's show otherwise.

Maybe the kernel will if you (a) use it as console and (b) have
RASTERCONSOLE turned on, though even then I'm not sure - it's been too
long since I was near the rasterconsole code.

> Basically, is there some predefined place in memory that a linear 24
> bit framebuffer should occupy, or does it vary by hardware?

Certainly no fixed place in virtual memory.  In physical memory, I have
no idea, since I don't know enough about the memory layout of such
machines.  I would guess that each SBus slot has a piece of space and
that the board appears at a fixed offset relative to that, but that
*is* just a guess.

> And if it does vary, how would I figure it out?

I'd have to play around with it (doing peeks and pokes in the
driver[%], and watching the screen) and/or look at other SBus
framebuffer drivers for examples.

[%] Most likely by providing an ioctl that bashes an arbitrary location
    to an arbitrary value, with nofault turned on.  (Not for production
    use, obviously; it would come back out before the driver goes near
    a non-scratch development system.)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B