> Date: Thu, 11 Jul 1996 18:31:14 -0400 (EDT)
> From: Brad Spencer <brad@anduin.eldar.org>

> Basically, I redid the mmap function in the driver.  I sorta
> stumbled on the change by mistake.
> 
> Here is the config line I use:
> 
> cgfour0 at obio0 addr 0x0b300000 level 4        # P4 4/100
> 
> I have not had a lot of time lately to fiddle with my 4/110, but the
> last time I thunked on it, the following worked [around the 1.2
> version of cgfour.c].  The information was derrived from staring at
> the cgfour driver in OpenBSD and by some guesses [I don't know if
> there ever was a cgfour on the Sun 4 that wasn't on a P4 bus.  That is
> what the 0x300000 is all about in the return()].

So, you think the mmap function is incorrect?
If that is true, why would it work on the 3/60?

The current one looks to me like it is roughly equivalent to
the one sparc/cg4 given the different hardware layout of each.

The hardware layout information came from the SunOS header file:
	/usr/include/sundev/cg4reg.h
which appears to suggest there are two layouts for the cg4
("type A" and "type B").  My 3/60 has "type B".  Does yours?
If we have to support both types, how do we determine which
one we are looking at?

Here are the relevant definitions from SunOS:

/* A type (AMD DAC) definitions */
#define	CG4A			0

/* frame buffer and color map addresses */
#define CG4A_ADDR_OVERLAY	0xFF000000
#define CG4A_ADDR_ENABLE	0xFE400000
#define CG4A_ADDR_COLOR		0xFE800000
#define CG4A_ADDR_CMAP		0x000E0000

/* B type (Brooktree DAC) definitions */

/* frame buffer and color map addresses */
#define CG4B_ADDR_OVERLAY	0xFF400000
#define CG4B_ADDR_ENABLE	0xFF600000
#define CG4B_ADDR_COLOR		0xFF800000
#define CG4B_ADDR_CMAP		0xFF200000