TEMLIB v3 now includes a video controller suitable for the Sun4m workstation.

SBUS Video cards

S24 (‘tcx’, AFX connector, 501-2337), SunGX (‘cg6’, 501-1672), TurboGX (‘cg6’, 501-2922) and LEO (‘zx’, 3D accelerator, 501-1843)


Resolution is set to 1024x768x256 indexed colours.
Video memory is taken from the DDRAM, using a dedicated port of the Xilinx MIG controller. 2MB is mapped for the framebuffer.

This arrangement is somewhat similar to the “CG14” framebuffer for SparcStation20 which used special DIMM memory modules with dual port DRAM. Using a part of the RAM with no additional wait states, performance is not that bad.

For TCX, “vid.vhd” is used in 256 colours mode and is connected to a 256 x 24bits dual port RAM to emulate a “Brooktree” palette chip. The palette is addressed through a PVC bus.

TCX framebuffer

OpenBIOS declares this framebuffer as a 8bits-only TCX board, a bit like a SparcStation4. The address is a bit different from an actual TCX, to ease memory mapping and save memory (we keep 126MB for programs).
OpenBIOS also initialises the Chrontel CH7301C DVI transmitter present on the SP605 board, bit-banging the I²C bus.

Our implementation is still quite different from an actual S24/TCX : There is no 24bits truecolor and no hardware acceleration.
This is enough for Linux, OpenBSD and NetBSD 5.x.
NetBSD 6.x and Solaris use the hardware acceleration and cannot work with this fake TCX.

A possible alternative could be the “CG3”, wich is a non-accelerated framebuffer, already supported by OpenBIOS. Another solution would be to implement the hardware acceleration features of TCX, which is doable, but very low priority.


The vid.vhd framebuffer controller was already present in previous releases of TEMLIB.
VID can be configured in 1/2/4/8bits per pixels, has a PLOMB “initiator” interface and a few signals for setting the modeline, the colour depth…

The video generator is straightforward. Counters generate horizontal and vertical synchronisation signals. In the visible area, when the horizontal counter Is lower than the image width and the vertical counter is lower than its height, pixels are pumped from a FIFO which is continuously refilled by DMA burst reads. The PLOMB bus can use a different clock from the pixel clock. DMA addresses are incremented independently from the display counters.
In order to align the displayed image with the memory area, the DMA counter is reset and the FIFO is drained at the end of the frame (just after displaying the right down corner).

Because the FIFO is filled asynchronously, and the “end of frame” signal has some resynchronisation delay, a few extra words are fetched by VID, then discarded, beyond the end of the displayed area.
VID uses Xorg “modeline” properties for defining the video resolution and image format :

CONSTANT MODELINE_1024_768_60Hz_65MHz : type_modeline := (--65.00,
  • Dotclock : 65MHz. This is the expected frequency of the pixel clock.
  • HDisp = 1024 : Image width
  • HSyncStart = 1048 : Horizontal Sync. pulse position
  • HSyncEnd = 1184 : Horizontal Sync pulse position
  • HTotal = 1344 : Total width. Horizontal frequency is Dotclock/HTotal
  • VDisp = 768 : Image height
  • VSyncStart = 771 : Vertical Sync. pulse position
  • VSyncEnd= 777 : Vertical Sync. pulse position
  • VTotal = 806 : Total height. Vertical frequency is Dotclock/HTotal/VTotal : 65MHz / 1344 / 806 = 60.0038Hz
  • HSyncPol : 0 : negative, 1=positive
  • VSyncPoll : 0=negative, 1=positive

It is often difficult to get the exact frequency in a FPGA, but modern LCD displays are quite tolerant and can automatically adjust the image to a wide range of input frequencies. For 1024×768, a 66.666MHz clock works just as well as the VESA standard 65MHz clock.

Leave a Reply

Your email address will not be published. Required fields are marked *