That sounds a
lot like the Grinnell (I think that's how it was
spelt) framebuffer we had at the lab I worked at in the '80s. It
was a Unibus device, attached to our VAX-11/780, and had some
capabilities I've never seen in a framebuffer since.
Such as?
Such as the selector switches between the pixel data and the lookup
tables, and between the lookup table outputs and the DAC inputs.
In pseudo-C pseudo-code, the per-pixel operation was not
DACinput[chan] = cmap[chan][pixeldata[chan]]
but rather
DACinput[chan] = cmap[sw2[chan]][pixdata[sw1[sw2[chan]]]]
where sw1[] and sw2[] are three-element arrays each element of which
can hold only one of three values.
Of course, it's questionable how necessary this is when you can
rerender a multi-mega-polygon scene afresh during the vertical retrace
interval, but that's a different issue...especially when you the buyer
of the video card essentially can't get the information necessary to
write the software to drive that rerendering.
Today's graphics cards are the fanciest devices
available ever.
...in some respects. Most of their fancies, though, are aimed at high
frame rate when doing 3D rendering, and don't even notice other
possibilities.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B