Yesterday's Hardware

Copyright 2007 Attila Tarpai (tarpai76 at gmail com)

 Trio64V+ video chip in a Dell Optiplex GsTrio64V+ in 1280 screen width! (1MB RAM)


Because I believe that even yesterday's hardware can perform more than enough with proper software! I will try to prove that with native hardware programming of the video subsystem.

Material and method

I digged out a Pentium-I machine from the garbage. It has an S3 Trio64V+ PCI graphics SVGA chip on-board with 1MB (!) of video RAM. I also have a 15" multisync color monitor from Dell (M570).

The Trio64V+ supports a maximum of 4MB Fast-page or EDO DRAM as video RAM. This is enough to store an eg. 1600x1200x65K (2 bytes per pixel/ 2BPP) or 1024x768x16M (4BPP) screen. The Trio64V+ supports color formats of 8-, 16(15)- and 32 bits per pixel (bpp). The 2D Graphics Engine (GE) supports screen pithes of 640, 800, 1024, 1152, 1280, 1600 pixels with 1-, 2- or 4BPPs. Excellent!

Thanks to the Streams Processor component it has the ability to control the display parameters (Width, Height, Hz) independently from the picture shown. This gives opportunity to f.ex. drive the CRT in 1600x1200 mode, and place a 640x480 screen image anywhere on the surface. Wow! Really?

This picture shows 2 640x480 screens (as S3 supports 2 streams) placed anywhere on a 1600x1200 display on a 15" M570 multisync monitor! Of course with 1MB we don't go far, so the 2 screens outputs the same area from frame buffer memory but with different color formats.. Having more memory installed allows us to use totally separate screens.

Programming the Trio64V+ CRTC

I will not go into details on the CRTC registers here (can be found at plenty of places), just highlight some important aspects.

What important for a CRT is travelling on 2 pins: the horizontal and vertical syncron signals. A multisync CRT needs hsync and vsync signal freqs to be happen within its operational range as it has a lowest and a highest speed it can drive the electron beam through the monitor's surface. My M570 can drive one scanline within the freq range of 30-70kHz, and sweep the whole screen within 50-160Hz.

A CRT also needs some time to position the beam between scanlines (in the horizontal blank period) and between frames (vertical blank). This adds a few microsec or some %-time per scanline and between frames. These are the parameters that vary from monitor to monitor!! Maybe worth experimenting, but VESA has a 'standard' for that today called the GTF: timing formulas that calculates these values for us, with which monitor manufacturers conform.

What I did was to open VESA's excel sheet of the GTF, and put in values of:

The resulting values for hfreq and vfreq *should* be within the range of my display's hsync-vsync parameters. That's it! If this is true, the picture will appear on the display. Even resolutions beyond the display's: I've managed to sync to a 1920x1200 on my 15" monitor! This is just an experiment of course pushing a given hardware configuration to the limits.

(One could write a formula to find the highest possible frame rate for a given resolution, which is within the monitor's hsync/vsync range..)

Concerning limitations from the video chip's point of view: even the Trio64V+ CRTC's dot clock is a beast: for the 1600x1200@56Hz resolution it ticks at only 149MHz. It has a maximum freq of 270MHz... (NB. This clock is not the pixel-clock.. or.. why is this working if V+'s max RAMDAC speed is 135MHz??? TODO)

OK. Lets connect this video chip to my 24" Dell 2407WFP flat panel, which has a native resolution of 1920x1200 pixels. LCDs favour 60Hz, so according to GTF this requires a 193MHz pixel clock from the controller. Hm, far from maximum, and who thought that these panels *could* be driven by 10 yr old video chips?? (Not to mention that LCD-s require much less time between scanlines and frames - there is no electron beam to be positioned.. so instead of GTF the formulas for Reduced Blanking are used, which gives a considerably lower pixel clock frequency! In this case 154MHz instead of 193MHz...) Our limitations here though is the amount of video RAM installed for the video chip and not speed: an 1920x1200 screen even on 8-bit (1BPP) needs more than 2MB of video RAM.

Another parameter to add is the speed that frame data can come out of the frame buffer memory chips. If a screen needs to be refreshed 60 times per second, and has parameters of eg. 1600x1200 with 16M colors (3BPP); that is 1600 x 1200 x 3byte x 60/sec = 330 MB/sec throughput! With a 64 bit bus size is's 43.2 million read cycle / sec. A very rough estimation is the following eq:

MCLK' /2 > PCLK', ie. lets give at least half of the memory bandwidth for screen refresh compare to pixel clock needs.