Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: dewar@cpsc.ucalgary.ca (Alan Dewar)
Newsgroups: comp.sys.sun
Subject: undocumented features of cg4b frame buffer (l
Keywords: Hardware
Message-ID: <8903092016.AA18705@cpsc.UCalgary.CA>
Date: 24 Mar 89 01:32:02 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 107
Approved: Sun-Spots@rice.edu
Original-Date: Thu, 9 Mar 89 15:16:11 EST
X-Sun-Spots-Digest: Volume 7, Issue 210, message 5 of 14

We at the University of Calgary once needed to figure out how the Sun 3/60
sets its colour-table entries.  We needed to know how things worked at a
rather low level, since our application was a real-time kernel which ran
directly on the machine, in place of Unix (i.e., we booted our kernel
instead of booting vmunix).  /usr/include/sundev/cg4reg.h told us that the
colour map resides at physical address FF200000, and we were able to map
it in at some arbitrary virtual address using the boot prom monitor.

>From there, we were able to poke around and see what happened.  The
upshot of all this was that we did figure out how to set colour-map
entries, and our kernel was happy.  More interesting, though, are some
undocumented features of the cg4b that we discovered along the way.

As far as we can tell, all cg4b frame buffers support these features, so
any colour Sun 3/60 should be able to use them.  The features are as
follows:

 1. The monochrome foreground and background colours need not be black and
    white, but can be set to any RGB values.  (Suntools actually uses this
    feature.)

 2. The monochrome (overlay) plane and the colour plane may independently
    be disabled.  If the monochrome plane is disabled (and assuming the
    enable plane is set to all 1s), you see a uniform monochrome-background
    colour.  If the colour plane is disabled (and assuming the enable plane
    is all 0s), you see "nothing."

 3. The colour of the "nothing" you can see in (2) above may be set to any
    RGB value.

 4. The monochrome background can be disabled, while leaving the monochrome
    foreground enabled.  Assuming the enable plane is set to all 1s, this
    allows anything drawn on the monochrome (overlay) plane to be visible,
    while also allowing the colour plane to be seen at the same time.  The
    way I used this was to run suntools with -overlay_only for performance,
    with a pretty Mandelbrot image in low-intensity colours for a background.
    I'm sure you can think of other useful applications for this feature.

 5. The colour of the monochrome overlay, with the monochrome background
    disabled, may be set to any RGB value, and is independent of the normal
    monochrome foreground and background colours.

 6. The colour-map index used to look up each pixel's colour may be masked.
    The normal mask value is FF (i.e., all bits are significant).  A value
    of 7F would mask out the high bit of the colour-map index, resulting in
    colours 0 - 127 being normal, but colours 128 - 255 being displayed as
    colours 0 - 127.  A mask of FE would allow only even-numbered colours,
    and so on.  Masks of F0 and 0F could be used to treat the colour plane
    as two independent 16-colour images, instead of a single 256-colour one.
    Other possibilities abound.  All of this could of course be done via
    manipulation of the colour map, but fiddling a single byte mask is much
    faster.

 7. The colour plane can blink.  It alternates between two states:  the
    normal state in which colours are affected by Undocumented Feature 6,
    and a state in which a further mask is also applied to the colour-map
    index.  The default for this further mask is 00 (nothing gets masked
    out).  Setting it to 01, for instance, would cause blinking between the
    normal colours and even-index colours only.  A mask of FF would blink
    between normal and a display filled with colour 0.

 8. The rate of blinking may be set to any of four possible values.  No
    blinking is NOT one of the options; colour-plane blinking is disabled
    by setting the blink mask to 00.

 9. The overlay plane can also blink, at the same rate as the colour plane.
    Turning on this blinking results in the overlay foreground colour
    blinking to the overlay background colour.

10. The overlay background (described as Undocumented Feature 4) can blink,
    again at the same rate as the other planes.  When it blinks out, the
    overlay foreground remains (assuming it's not also blinking, and the
    enable plane is set to all 1s) and the background allows the colour
    plane to be seen (assuming it's enabled, etc.).

In addition to these features, there is a bit in a control register which
is normally set to 0 and which, if set to 1, causes the display to become
"fuzzy," as with a television whose fine tuning is slightly off.  I would
guess that this is some kind of synchronization which is being disabled,
but I can't see why anyone would want to do that!  Any ideas?

Finally, there is one more control register whose purpose we were not able
to deduce.  We could set it to anything we liked, with no apparent affect
on anything.  Reading it back again would show that some of the bits were
getting cleared sometimes.  I suppose this could be a status register, but
it would be nice to know what status it represents.

Okay, now that everybody is drooling over their keyboards wanting to know
how they can get these features, I've got good news and bad news.  The
good news is that I was able to write a little utility program which
allowed these things to be manipulated from Unix command level.  The bad
news is that it only worked on pre-3.5 systems.  It seems mmap changed
between 3.4 and 3.5.  The colour map for the cg4b resides at a NEGATIVE
offset from the base of the frame buffer.  The offset was accepted by mmap
under 3.4 (but writing to it toasted the machine if /dev/fb was not a
cg4!), but is rejected under 3.5 and 4.0.  One could argue that this is
only reasonable, since negative offsets in general make no sense, but it
does leave us unable to get at the nice features hidden in this device.

Does anybody have any suggestions as to how to get the cg4b's colour map
mapped into a process's address space?  Alternatively, is there some
system call to set these things indirectly?  (Can anybody at Sun help?)
If there is sufficient interest, I would be happy to post the source for
my utility program once I get it working again.

Alan Dewar	Computer Science Dept.	University of Calgary
dewar@cpsc.UCalgary.CA		..!alberta!calgary!dewar