I am into playing with TTL to build 1970s style minicomputers. Aside from talking to them via some serial (or parallel) I/O port to a terminal, I am wondering about display output. This here is about vector displays, I have not found much discussion on the internet about them, some arcade game people building vector displays, but I found little about schematics and principles. I remember back in the 1980s I checked out books about "Computer Graphics" from the library, but what I remember having read was very little detail. So now I am thinking this through, and I am beginning with raster dot graphics as a reference.
I understand that a pixel graphics frame buffer module would essentially have a suitable high speed clock, a bunch of counters to generate the number of the present scan line and horizontal pixel position and do the proper sync to the CRT monitor (assuming you use a normal analog VGA / RGB monitor) and then these position numbers are turned into an address to pull the current pixel value from memory. Some contention resolution so that the CPU can write into the display RAM, or tricks with character ROMs, etc. All of that is standard affair.
What goes through the a VGA / RGB monitors cable must conform to a certain protocol. There are only certain resolutions which the monitor supports and they are detected by the right syncing frequency and blanking, etc. Of course this is legacy stuff and falling more and more obsolete in the age of TFT or LED pixel screens and digital display interfaces (DVI, HDMI). So it seems increasingly pointless to try to create that high-speed serialized ray tracing signal adapted to the monitor's expectations.
This is why I wonder whether this all could be done even simpler by driving the CRT tube directly and not interface to a monitor with its own PCB etc. For example, with the VAX 11/780 I once hauled from Madison, WI and kept in my garage for years, there was an entire drawer above the UNIBUS box, which contained a high resolution frame buffer. And with it came a huge and extremely heavy CRT display. I can't remember if it had 4 or 5 BNC cables, but I figure this was not a monitor that I could easily drive with a VGA cable the way I managed to adapt that to the CRT projector I got from university surplus warehouse once.
This gives me the idea of driving a CRT tube raw and naked right from the computer board (set). Perhaps all the high voltage stuff stays inside the monitor housing, but everything else would come from the display module in the computer, i.e., horizontal and vertical deflection and the intensities of the electron rays, monochrome or RGB. This would be delivered at a reasonable voltage level to the CRT where nothing other than amplification to the proper (high) voltages would happen that drive the CRT beam acceleration and deflection.
I am looking for the simplest thing to do with a raw CRT from an old TV. In today's digital world, there is little joy in producing an analog VGA signal only to have it displayed on a TFT flat screen. In that case I prefer to drive the TFT display directly without all that extra effort of serialization and syncing, etc.
So, now let's say I have those 6 or 7 wires coming out of my CRT:
- Horizontal (X) Deflection
- Vertical (Y) Deflection
- Red Intensity (optional)
- Green or Monochrome Intensity
- Blue Intensity (optional)
- Reference Voltage (optional) - which would allow me to drive the display at 3.5V, 5V, 9V, 12V, or whatever levels, so that inside the CRT we would use that to bring it to the level that the internal amplifiers want. If this makes it any harder, just drop this thought.
Now if I have that, my frame buffer card can generate the necessary sawtooth wave forms for the H and V deflection along with the pixels, and if I want to, I could run the display at 25 Hz refresh rate, even if it flickers as hell. I can of course also just plug these wires 1,2,3 into X and Y input of an oscilloscope (hmm, strange that a normal scope does not have an external input for the intensity).
From Direct Driven CRT To Vector
Now with this, my frame buffer discussed above, is just one way to drive the display. What I am really interested in and I always found fascinating, would be a vector display. I have seen some modern vector CRT projects, but I haven't seen schematics and very few discussions I can find on the internet.
So, I am wondering how I would create one myself? But also looking for best practices and perhaps TTL compatible chips that have some of the complexity already taken care of. Since I am starting from scratch, I am thinking all this up from my own intuition and I can see a path from there to how it might be built. But I really would like input of people who know this stuff to tell me which of my ideas have long been scrapped and surpassed by better approaches and which ones have not been taken because they weren't feasible or because the raster image had sucked all the air out of the market such that vector displays just withered away.
For a vector display, for every dot, you have to define Deflection and Intensity signals. Move dot, turn intensity on, then produce a stroke by moving the dot with the intensity on, then turn intensity off. The abstraction is a polygon.
To make it more general even, one can say that every stroke has its own intensity (or intensities of RGB), whatever the current deflection position is will be held in the current deflection register, then a trajectory would be drawn to the next point, with a set intensity ... or even a gradient of intensities.
The trajectory and the intensities gradient is the result of some function generator, in the simplest case X and Y increase linearly from the present position to the next position at a given speed. Both the intensity values as well as the speed should influence the intensity of that stroke. There has to be a minimal speed in order to make the stroke appear as a solid line, and if you draw a polygon, there has to be a maximum amount of time to complete the entire drawing in order to see it all in one frame without the start of the drawing already having vanished.
So the full drawing needs to be constantly repeated. As such it is similar to the raster line drawing: at least 60 Hz refresh rate. The entire drawing needs to be repeated 60 times per second. So now I make a little comparison between vector and pixel, when I have an 80x25 screen full of text. How many strokes per letter in upper case font?
- A - 3
- B - 10 (in rough polygon approximation)
- C - 5 (in rough polygon approximation)
- E - 5
- F - 4
- G - 6 (in rough polygon approximation)
If I average that I get 5.5 strokes per letter, and of course from one letter to the next I also need to move the ray, so, I will just take an estimate of 6 strokes per letter. That is for 80x25 = 2000 letters we have 12,000 strokes. Each stroke requires new X,Y coordinates and the intensity depends on color space, same issue as with raster line graphics. In order to have a 1024 x 768 resolution, I would need 20 bit per each point. So we have 12,000 x 20 bit = 30 kByte per such screen full of text. Of course I can generate the characters from a character ROM also, so for text display I need way less, but I am taking the text display as a comparison to get a feel of the memory and frequency trade-offs. For the same display in raster, I need 768 kByte. So that is about 20 times more. As for frequency at which things need to happen, with raster I need to produce intensities change at 50 MHz while the sawtooth wave forms deflect X and Y for a 60 Hz refresh rate. For vector I would need 12,000 I would need 0.72 MHz to draw all the strokes. So, this means a vector display should be almost 100 times easier on the frequency and 20 times easier on the memory. Rough estimates.
I don't like the polygon approximations, and I think one might do even better if we had analog function generators which could produce more than linear sawtoothy waves. Ideally circular arcs, perhaps ellyptic arcs. This should be doable by using sine waves with just the right phase shift and mixing them in with linear changes. This would add to the data we need to store for each stroke, but it would also drastically reduce strokes as we want to draw more rounded shapes. E.g., the B would suddenly have 3 instead of 10 strokes! The C could be done in a single stroke instead of 5. The G in 2 instead of 6. With the right analog wave form generators this could look better as well as reducing the frequency at which strokes would have to occur.
Of course, one might wish to have a comet-like effect where this fading of the tail as a dot slowly moves over the screen might be intended. But more likely that could be accomplished by having the intensity gradient also generated with an analog waveform.
Then if you think of making a game, you think "sprite". But a sprite is really just a trick to mix in pixel data from the sprite buffer along with the background buffer. So we could do something like that for our vector display, except now we would be dealing with line intersection and clipping. Wow, rapidly this could become very complex. But not if the line clipping could be somehow hardware-accelerated. Could it be hardware accelerated in other ways than just by running algorithms on a fast CPU with multiplication? I guess best would be vector and matrix and all that good stuff.
Seems like overkill to do on the display adapter. Here it becomes clear to me that it's much simpler overlaying sprites over a background (or over each other), even text and graphics overlay, very easy, because you just do it pixel by pixel, and in hardware the same address can just read multiple bytes from memory which would just be OR-ed together (or in other ways simply combined by logic gates.)
But if you could somehow do the line clipping in hardware, then you could create really nice 3D effects with your vector sprites as you could scale them and even fade their intensity out as they move into the depth of the 3D image.
OK, here I stop. What say the experts in old vector display technology?