What are principles of vector CRT display? Simplest way to drive CRTs? [closed]

Question

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.

Pixel Graphics

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:

1. GND
2. Horizontal (X) Deflection
3. Vertical (Y) Deflection
4. Red Intensity (optional)
5. Green or Monochrome Intensity
6. Blue Intensity (optional)
7. 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?

1. A - 3
2. B - 10 (in rough polygon approximation)
3. C - 5 (in rough polygon approximation)
4. E - 5
5. F - 4
6. G - 6 (in rough polygon approximation)
7. ...

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?

Answer 1

Vector and raster graphics pose different challenges. Raster displays require the ability to very quickly generate a stream of pixels at a continuous rate. Unless one is willing to place severe limits on the number of objects per horizontal line and use separate circuitry for each such object (something many early video game systems in fact did) this will require having an image stored in a way that allows it to be read out quickly. Nowadays this is done with RAM, but in the 1960s other approaches such as shift registers or fixed-head magnetic storage would have been cheaper. Unfortunately, using anything other than RAM will limit one's ability to perform display updates cleanly. If one doesn't have enough RAM to hold a full display, it may be necessary to render part of the display to RAM, wait for the drum or shifter to reach the right spot, output the RAM to the drum or shifter at the required speed, and then render the next part of the display, etc. Rather expensive. Note that even a 256x256 black and white display with one bit per pixel would have required 8192 octets (modern bytes) of RAM, which would have been rather a lot.

Vector displays eliminate that problem, and make it practical to have displays with much higher resolution than would have been practical with a raster display. For example, the PDP-1 display had a resolution of 1024x1024, which would have required 131,072 octets of RAM to buffer. The problem with raster displays is that they are much more sensitive to the calibration of the beam-deflection control circuitry. A raster display repeatedly traces the same path over and over the exact same way. Any imprecision in the display circuitry may cause parts of the display to be slightly stretched or distorted, but if the point that is supposed to be 66% of the way down the display is actually 67% of the way down, nobody's apt to notice or care. Such imprecision with a vector display, however, could render it almost useless.

What makes drawing with a vector display difficult is that the deflection coil signal doesn't directly control the beam position, but mostly controls its velocity (it's possible to discharge the stored energy in the coil to reset the beam to center to acquire an absolute position reference, but this takes longer than using relative moves). If on a screen that's 10" wide, one tries to e.g. draw 20 spokes on a wheel, and each attempted move ends moving up 0.01" to the right of where it should be relative to the start, then the end of last spoke will end up about 0.4" to the right of where it should be. That level of precision would be considered pretty good for a raster display, but horrible for a vector one.

It's possible to design and calibrate vector display circuitry to yield good positioning accuracy, but it's an expensive process compared with making raster display electronics that can be much cruder. Using 1960s technology, the cost of calibrating a display would be far less than the cost of generating the pixel stream for a reasonable resolution raster display, but nowadays the reverse is true (though if CRTs were still being produced, modern drive electronics could probably be designed at reasonable cost to be largely self-calibrating).

Answer 2

This is really lots of questions, so a very general answer:

If you want to know how retro vector displays worked, have a look e.g. at the Tektronix 4010, the Vector General, or the various vector displays for the PDP models. Bitsavers has manuals.

The interface for all of these is a variation of the following principle:

Store a "current position" as a pair of counters, get a "next position" into the hardware, let the hardware count towards the next position, outputting the counters as an analog value to the CRT. 10 to 12 bits were used for this.

Then add intensity bits, absolute vs. relative addressing, drawing vs. moving, and if you want it really comfortable, some sort of DMA to read a display list. But the simpler ones did it without DMA.

So for a hardware implementation without DMA, TTL ICs for counters, comparators, and D/A converters, together with some glue logic should get you started.

Answer 3

Expanding the existing answer by temlib is that most osciliscopes have some form of X/Y input and better ones support Z (intensity) This allows you to sidestep the complex signal drive problem to the CRT coils and just wrangle the primitives to DAC output part of the problem. And you'll need a decent scope for poking the back of a CRT anyway.

Once you have a system that you know and trust then you'd start trying to produce a custom driver stage for the CRT. It is worth noting that most cathode ray oscilliscopes used electrostatic beam deflection (voltage dependent) while raster displays generally used electromagnetic (current dependent) and use very different driver stages so check the fine print of any designs you copy.

Once you are at the point you want to dive into the world of exciting voltages found in the back of a tube (not all chasiss are ground so even the frame can kill) it is probably worth being aware that tampering with the beam drive voltages 'to make it brighter' can lead to electrons hitting the front face of the tube with enough energy to produce xrays. There are also a number of ways to damage the tube with incorrect drive (such as high beam intensity with no x/y deflection), so when you start looking for a chassis would suggest making sure you have at least three identical candidates available, one to reverse engineer, one to work on and as a working TV to test against.

Displays with a smaller viewing area and with longer distances from the gun to the front face will require lower deflection currents which will be easier to engineer. They are also less likely to contain clever fault detection circuitry (see above Xray warning) that will complicate having a custom driver attached.

Answer 4

You can drive a vector display with a few DACs driven by a FPGA for timing and sequencing the patterns.

For a cheap implementation, you can look at the old Vectrex game console which is well documented. It uses only one 8 bits DAC, one analog multiplexer and a few op-amps. Lines are drawn by setting charge current to a R-C circuit, the CPU doesn't calculates pixels along lines.

(Many analog oscilloscopes had a Z-input which could drive spot intensity. That input didn't always have the same bandwidth as the rest of the scope, not suitable to turn it into a TV screen.)

Answer 5

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.

You could try modifying an existing CRT monitor. Intensity is already controlled by the analog RGB signals (a sync signal may still be required to set the black level) but horizontal and vertical deflection waveforms are produced internally and only synchronized to the sync pulses. To have full control from the CPU you would need to drive the coils through current amplifiers.

Vertical deflection already has an amplifier, so you just need to feed your DAC output directly into it.

Horizontal deflection is harder because the coil is driven from the EHT transformer, and both are optimized to work together at the horizontal line frequency. You would need to make a custom amplifier matched to the horizontal deflection coil, or rewind the horizontal coil to match the vertical coil and use a standard vertical amplifier (this could be the better option because it should be more symmetrical). You might also need to put a 'dummy' coil in place of the original horizontal coil to keep the EHT circuit happy.

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.

You won't like the flicker, and getting the horizontal retrace time time low enough will be difficult because a very high flyback voltage is required (that's why the horizontal coil is normally driven from the EHT transformer).

However it could be fine for a vector display, which typically has much less total distance for the beam to travel so it can move slower.

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.

It's more than that. A sprite is a solid object that 'paints' the entire area. Vector graphics is really only suitable for wire-frame display. If you need solid color then a raster scan is more efficient.

Answer 6

Another issue here: The main value of vector displays is they allow for a higher resolution than raster technology--but these days raster has gotten good enough that this is basically a non-issue.

There are two downsides to vector systems that haven't been mentioned so far:

1) Vectors draw lines. The only way to fill an area is to scribble back and forth, drawing a lot of lines.

2) A raster system image is independent of complexity, but a vector system is complexity-limited. The more lines you try to draw the longer it will be before you get back to retracing your image. As your image gets too complex it flickers and eventually blinks.

I have actually programmed a vector system in the 2000s. It required a lot of optimization of the images being drawn to reduce the time the beam was repositioning but not drawing. Drawing a line twice (a shared edge) was also bad--the line came out brighter than the others. The system I was using wasn't a CRT at all, but rather lasers & mirrors--I could project an image on a surface. Even the simplest images I needed to draw (4 rectangles) had some flicker and it was basically blinking by the time I was drawing 20 or more. The objective was to draw a picture on the work table--build this.

(And if you're tempted to look into this--it was a $20k piece of hardware at the time. Then the whole project proved non-viable in a space without adequate climate control--we never did come up with an adequate solution to thermal expansion causing the aim point to drift.)

Answer 7

There was two main ways of doing this, exemplified by a storage display as used in the Tektronix 401x and the VS-11 type displays used by Digital. The 401x was an ASCII driven terminal and contained its own processors. Normal text was written in a dot matrix font at several prefixed scales, not as vectored glyphs by a pseudo rasterizing mechanism. Graphics were drawn using the D to A decoders. Fancier text could be plotted. The image though depended on storage tube technology (memory was expensive then) and Tektronix were already using them in their scopes.

Digital was doing it in another way. They had a minicomputer which shared memory with the a graphic processor which cycled through following display instructions. If we take one, such combination, the GT44, this was a VT-11 graphics processor on a PDP-11/40 minicomputer driving a long persistence X-Y monitor. It would fetch and decode instructions using DMA from shared memory and display the results on the screen, repeating the cycle, hopefully before the display disappeared (otherwise you would get annoying flickering). As the processor could modify the display instructions stream directly, it was quick and so facilitated [simple games][1]. The graphics processor was not simple but remember that this was 74 series chips in those days. Luckily, the [service manual is on bitsavers][2] which gives you info about the whole path. Note that DMA devices communicated with the main processor through Digital's Unibus which handled signalling and in particular memory contention.

Could it be done without a long persistence screen now? Yes, I think I would still stay with a second processor to drive the display and processor speeds are much faster. It is also easier to handle DMA these days which took about half a board back then.

I worked on graphics software for the Tek series and later the VT-11 many, many years ago.

Some references:

[1] https://en.wikipedia.org/wiki/Lunar_Lander_(video_game_genre)#Lunar_Lander_(1973)

[2] https://archive.org/details/bitsavers_decgraphic1GraphicDisplayProcessorSep74_5480001/mode/2up

Answer 8

Character generation can actually be done by partially analog style circuitry- and this has been done, for example to generate the on screen numeric readouts on Tektronix 5000/5400/7000 series oscilloscopes. Basically, some analog constants are "switched in" for whatever glyph is desired, and gradually applied one after another to the coordinate inputs....

A paper "Monolithic analog READ-ONLY memory for character generation" by Barrie Gilbert, 1971, exists describing this technology (manufactured into the late 1980s) in detail.