sga40top
SGA40 with 16-bit Z-buffer (on top)

sga40bot
SGA40 bottom showing 6 PIPRAM chips

sga40mid
SGA40 main board showing graphics chips and DSPs (SIPs are DSP static RAM)


The SGA40 was a 3D graphics board at 1280x1024 pixel resolution with 8 color plans, 2 overlay planes and a 16-bit z-buffer. It interfaced to the system through a DMA SBus controller that had built-in virtual-to-physical address translation so the graphics board could access graphics data structures in user-land applications. That was a pain for the kernel to maintain! It used two AT&T DSP32C DSPs at 25 MFLOPS each for intelligence and the 3D graphics pipeline. The rendering pipeline used a graphics controller that computed polygon data (and 2D operations) and drove a set of parallel datapath chips, one chip for each PIPRAM. The PIPRAMs had 16 bit synchronous data buses and the rendering pipeline ran at 16.67 MHz. The RAMDAC also included a hardware cursor. The architecture could scale to dual-buffered 24-bit frame buffers but that board (destined for K-bus) was never completed.


sga20top
SGA20 top

sga20bot
SGA20 bottom

SGA20 used the graphics control chip, two data path chips and eight PIPRAMs to provide a 1152x900 pixel 8-bit 2D accelerated display. The system architecture was designed around the PIPRAM 1280x1024 array pixel array. Sun's direct frame buffer access model required a linear array of memory so we used two 64Kx8 ROMs to remap the address as it came in when software accessed the frame buffer directly. The board performed pretty well although it was a slave-only device. It had pipelined writes and full 2D acceleration. PIPRAM supported a 32x32 tile fill function so rectangular fills (e.g. screen clears) were incredibly fast. This board went from the first thoughts to running with Sun's Pixrects and our own X11 in 2 weeks, 2 days. We paid out the ear for the proto boards (which were hand delivered to my house on a Saturday afternoon). The only issue was contention in some SBus data buffers that was quickly fixed with a PAL change. This board would have been so much cheaper if we had designed using commercial VRAM.


sbus_mono
SBus monochrome graphics


The monochrome board was software compatible with the K-bus version (just raw pixel data) but used an ASIC designed in Japan to interface with SBus. It used similar ECL circuitry to drive the output to the monitor (100 MHz dot clock). Notice the two PIPRAMs. I think this board could be configured to support a higher resolution with a higher dot clock but that product was never marketed.