Rants & Ramblings

Some Kind Soul(tm) sent me a Sun CG12 a few weeks ago, also known as GS or Matrox SG3. Yes, the board was designed and manufactured by Matrox, contains a bunch of Matrox-designed custom chips which don't show up in any part supplier's inventory list and a handful better known ones.
So, let me describe the board. It's quite huge - if you've ever seen a Leo or an AG-10e, it's like that, just one more slot. It occupies three SBus slots so it only fits in a handful machines like the SS5, SS1(+) and maybe the SS20 where it would hog one CPU slot. I put it in my SS5 where it blocks all SBus slots so there's no room for a fast ethernet board. Bummer.
The board I got turned out to be a CG12+, with 8MB framebuffer, 2MB z-buffer, 128KB RAM for the DSP. The only documentation available is a header file from SMI which contains a rudimentary register and address space layout, existing drivers in OpenBSD and Linux are both based on this file, and by necessity, so is mine.
If you read this header file and then look at documentation for older Matrox chips you will see a lot of familiar terms, apparently the entire Millennium I family and its ancestry ( like Athena ) are more or less distant relatives of the CG12. This should at least give us some ideas how the drawing engine works.
Of course I got the board for the promise to make it work in NetBSD. Unfortunately the firmware lies about the graphics mode set up at boot time so genfb at sbus produces garbage - the address property points at the monochrome overlay plane while the depth property contains 32. Sure, the board has a 32bit framebuffer but that's not what the firmware console uses. Getting it to work as a monochrome wsdisplay was easy enough but when I tried to use a shadow framebuffer to speed things up I found out that NetBSD's machine independent drawing routines for colour depths less than 8 hadn't been adapted to shadow framebuffer usage, so I did that and now the card works fine as a not all that slow but still monochrome console.
Given the similarities between the CG12 and older, more or less well documented Matrox graphics chips it may be possible to get the blitter going. I did some experiments but didn't get very far - all older Matrox graphics chips start commands by ORing 0x100 to the address of a register write. This doesn't match up with the CG12 - the engine registers occupy two successive blocks of 0x100 bytes, so if they use the same method they must use a different value to OR to the address. Also, the engine appears to be in a reset state of some sort, writes to any drawing related registers are ignored, or at least don't show up when reading registers. All other registers appear to contain something sensible and respond to writes, like the DACs ( there are three Brooktree 8 bit DACs, apparently working in lockstep ), various registers that control which view of the framebuffer you see ( be it 8 or 24 bit, overlay or enable planes etc. ) and what appears to be video mode setup.
It may well be that the board requires a firmware image to be uploaded somewhere ( maybe the DSP's private memory ), on the other hand the device properties give a firmware version. It is unclear wether this refers to the ROM content in general or the DSP's firmware. It is also unclear to what extent the drawing engine depends on the DSP, if at all. I don't think we will be able to use the DSP ( there are registers which seem to be for communication with the DSP but no indication whatsoever how they are supposed to work ) but I don't think we have to - the drawing engine will probably work just fine without. Also, the drawing engine seems to be pretty much 2D only, z-buffer operations seem to be the only 3d-support present - maybe the DSP is supposed to do some higher level drawing operations.
What we know about the board is this:

• it's got 8MB dual-ported framebuffer memory, 2MB z-buffer and 128kB DSP memory - quite a lot for a graphics board from 1990
• there's a monochrome overlay plane and an enable plane for the overlay
• there's an 8 bit WID plane and what appears to be a 256 entry WID LUT
• the framebuffer can be used as 8bit, 24 bit single buffer or 2x 12bit with double buffering, the overlay/enable planes seem to be completely independent
• apparently there is no support for a hardware sprite - I guess we're supposed to draw a cursor into the enable/overlay planes, that way at least it wouldn't interfere with the regular framebuffer
• there's a DSP, we don't know what exactly it's supposed to do
• the DACs seem to be regular 256 entry greyscale DACs working in lockstep to provide gamma table / palette support.
• the drawing engine seems to be similar enough to older, documented Matrox designs - there might be a chance to get it going.

Even though the card is quite monstrous its heat output seems to be moderate at worst, it's certainly nowhere near as hot as a Leo or even an AG-10e.