Vector General (VG) was a series of graphics terminals and the name of the Californian company that produced them. They were first introduced in 1969 and were used in computer labs until the early 1980s.
The terminals were based on a common platform that read vectors provided by a host minicomputer and included hardware that could perform basic mathematical transformations in the terminal. This greatly improved the performance of operations like rotating an object or zooming in. The transformed vectors were then displayed on the terminal's built-in vector monitor.
In contrast to similar terminals from other vendors, the Vector General systems included little internal memory. Instead, they stored vectors on the host computer's memory and accessed them via direct memory access (DMA). Fully equipped VG3D terminals ran at about $31,000 including a low-end PDP-11 computer, compared to machines like the IBM 2250 which cost $100,000 for just the terminal.
Among a number of famous uses known within the computer graphics field, it was a VG3D terminal connected to a PDP-11/45 that was used to produce the "attacking the Death Star will not be easy" animations in Star Wars.
A common attempt in the late 1960s to improve performance of graphics display, especially in 3D, was to use special terminals that held a list of vectors in internal memory and then used hardware or software running in the display controller to provide basic transformations like rotation and scaling. As these transformations were relatively simple, they could be implemented in the terminal for relatively low cost, and thereby avoid spending time on the host CPU to perform these operations. Systems performing at least some of these operations included the IDI, Adage, and Imlac PDS-1.
A key innovation in the VG series terminals was the use of direct memory access (DMA) to allow it to access a host computer's memory. This meant that the terminals did not need much storage of their own, and gave them the ability to rapidly access the data without it being copied over a slower link like the serial-based Tektronix 4010 or similar systems. The downside to this approach is that it could only be used on machines that offered DMA, and only through a relatively expensive adaptor.
The basic concept was that the host computer would run calculations to produce a series of points for the 2D or 3D model and express that as 12-bit values, normally stored in 16-bit words with extra stuffed status bits. The terminal would then periodically interrupt the computer, 30 to 60 times a second, and quickly read out and display the data. Each point was read one-by-one into the local memory registers for temporary storage while mathematical functions were applied to them to scale, translate and (optionally) rotate, and when the final values were calculated, those points were sent to the cathode-ray tube (CRT) for display.
There were three different models of the coordinate transformation hardware. The most basic system included the hardware needed to pan and zoom 2D images, in which case the terminal containing it would be known as a Vector General 2D. Another version added the ability to rotate the 2D image around an arbitrary point, known as the 2DR (for Rotate). The most expensive option was the 3D, which provided rotation, pan and zoom on 3D vectors. Another option that could be added to any of these models and was not reflected in the name added a character generator.
The square CRTs were driven directly from the output of the transformation hardware, as opposed to being displayed using a traditional raster scanning method. The company referred to this type of operation as "random scan", although it is universally referred to as a vector monitor in modern references. Two basic CRT models were available, measuring and diagonally. The 21-inch model was also available in a special "high speed" version which improved the drawing rates. The CRTs used electromagnetic deflection, not magnetic as in televisions, to provide high-speed scanning performance.
Several different input devices could be connected to the system. The most common was a 70-key keyboard, while others included a bank of momentary pushbuttons switches with internal register-controlled lights, a graphics tablet, a light pen, a dial box, and a joystick. The system as a whole was quite large, about the size of a small refrigerator.
Vectors were represented logically by two end points in space. Each point was defined by two or three 12-bit values, thereby representing a space from 0 to 4,095 in X, Y and (optionally) Z. The terminal had three 12-bit registers to hold the values while they were being manipulated.
The system allowed vectors to be represented in a number of ways in memory. The most basic mode, "absolute", required two points, one for each end of the vector. "Relative" vectors were expressed as offsets from the last set of values, so only one point was needed to define a vector, the first point being the endpoint of the last one. This could halve the number of points needed to describe a complete drawing, if the data was continuous like a line chart. "Incremental" vectors further reduced memory by using only 6-bits for each point, allowing the data to be packed into less memory in the host. The system could be set to add the values to the high- or low-order 6 bits of the last value, allowing gross or fine movement. Finally, "autoincrementing" vectors further reduced the memory requirements by requiring only one value to be stored, with the others being incremented by a preset amount as each new point was read in. These were similar to relative vectors, with one of the two axes always having the same relative offset. The system also had a separate circuit to generate circular arcs, as opposed to having to send in a series of points.
The display was capable of producing 32 different intensity levels. This could be programmed directly by setting a register in the terminal, but was more commonly used in a programmed mode in 3D. In this mode the intensity was changed automatically as the vector was drawn, with items deeper in the Z dimensions being drawn less intense. This produced a depth cue that made the front of the object look brighter on the display. The rapidity of this change was set through the ISR register.
A separate 12-bit PS register held the scale multiplier. When this value was not used, the coordinate system represented a physical area about twice as large as the screen, allowing it to translate the image to provide scrolling. When a value was placed in this register, the coordinates in the vector registers and the character drawing system were multiplied by this value, producing a zoom effect.
The optional character generator drew characters using a set of five hardware-defined shapes, a circle, a square with a vertical line in the middle, a square with a horizontal line in the middle, and hourglass shapes oriented vertically and a similar one oriented horizontally. By turning the beam on and off as each of these shapes was being drawn by the hardware, the system could draw any required character. For instance, the letter C was drawn using the O shape and turning the beam off while it was on the right. The letter D would be drawn using the O shape and turning it off while it was on the left, and then drawing the vertical-line box with the beam turned on only when the center vertical bar was being drawn. Between one and three such "draws" are needed to produce a complete character. The system included a number of greek letters and mathematical symbols in addition to the normal ASCII characters.
The terminal periodically read the main memory of the host computer using DMA to refresh the display. Further communications were handled through a single bidirectional I/O port after creating an interrupt request with the request details in the PIR register. Settings and instructions were handled by sending data to and from the I/O port to one of the terminal's 85 registers.
For instance, the host could set the value of the PS register, causing the image to zoom. It would do this by calling an interrupt whose 16-bit message contained the number of the register to be set, 17 in this case. The terminal would respond by sending a 16-bit message back over the I/O channel. Writes were handled using a similar process, but the terminal responded to the interrupt by reading a value instead.
The base address for the start of the vector list and the offset within it were in registers 14 and 15. This allowed the display to perform a sort of "page flipping" by writing out separate sets of points within the computer's memory and then changing the display all at once by changing the value of register 14 to point to a different base address. This was limited by the amount of memory available on the host computer.
The display instructions had a variety of formats that allowed the construction of not only vectors, but also various commands. For instance, there were instructions to load data into a given register, consisting of two 16-bit words the first with the register details and the next with the value. Other instructions performed logical OR or AND on register values. The display instructions themselves could be mixed with these operations, so the system could, for instance, begin displaying a selection of items, cause a lamp to light, rotate the image, and then draw more vectors.
The VG3D is historically notable for its use in Star Wars, but is also well known for its early role in the development of computer aided design.
Larry Cuba produced two segments of computer animation for Star Wars on a PDP-11/45 with a VG3D terminal. To film the images frame-by-frame, a wire was connected between one of the lights on the pushbutton panel and the shutter trigger on the camera. This was triggered by the host computer, causing the camera to release the shutter one time and to advance the film a single frame.
The first segment, which shows the exterior of the Death Star, is based entirely on the VG3D's internal display capabilities. The model consisted of a simple series of 3D points representing the outline of the station held in the PDP-11's memory, constructed algorithmically using the associated GRASS programming language's curve generation code. To move and rotate the image as seen in the film, the associated GRASS program would load new rotation and zoom figures into the terminal's registers and then trigger the camera.
The second segment shows the view flying down the trench in the final attack, first from above and then from the pilot's perspective. This was much more difficult to create because the terminal did not support the calculation of perspective, which was required in this sequence. The physical model of the trench used during filming was made up of a series of six features which were duplicated many times and then assembled in different ways to produce a single long model. Cuba digitized each of these six features from photographs and then combined them in different configurations into over 50 U-shaped sections. For each frame, five of these sections were stacked in depth and then the perspective calculations were applied. The addition of new sections as the animation progresses can be seen in the film. This was then sent to the terminal as a static image and the camera was triggered. Each frame took about two minutes to render.
Mike Muuss recounts that the US Army's Ballistic Research Laboratory had purchased a Cyber 173 and three workstations consisting of a VG3D terminal and a PDP-11/34 to drive it. These were intended to be connected together, but no one was able to get this to work, and in the end, the VG workstations were left unused. He was bothered to see all of this hardware being wasted, so in 1979 he hooked up one of the workstations and created a program that produced a rotating 3D cube.
Another programmer had been given a set of 3D points of the XM1 tank design and was writing code to output it to a Calcomp plotter. He asked Muuss if they could get it displayed on the VG terminals instead, so they could rotate it. He first output it as a static image on a Tektronix 4014, but the next night managed to get the display onto the VG3D where it could be easily spun around using the internal vector hardware.
No one in the Army had seen anything like this before. The next day the commanding general of ARRADCOM flew in to see it live. Over the next two weeks Muuss was constantly giving demos of the system to a parade of officers. The demo became so well known that Muuss was able to begin development of BRL-CAD.[1]