The dd-80: A High Speed Display and Recorder

George Michael

by George Michael

The year was 1958, and computational improvements were arriving with satisfying regularity--well, almost satisfying. There were two aspects about this. First, our needs far outstripped the improvements we were receiving from the vendors. (In fairness, often when we took bigger steps of improvement, the results were not as grand as they should have been.)

The second aspect was that needs in output--printers and storage devices were at least as pressing from the standpoint of the users as were needs for more computational speed; it does little good to be able to compute quickly if, then, the results take a long time to become available. The vendors were not doing anything close to what we needed or wanted.

We found a small company, Data Display, Inc. which was producing a very fast display device. With a small amount of special tuning, it seemed it could be turned into a usable microfilm recorder. We redesigned the display word formats to fit into 32 bits, even though it was to be used on some IBM 709s and other 7000 series machines that used 36-bit words.

Format 1 (7 bits for character (CH) selection):
CH Value Operation
123 Move the beam to (x.y)
124 Enter Format #2 mode at (x,y)
125 Draw a line to (x,y)
126 Advance film 1 frame
127 Display a point at (x,y)
2 bits for character size control
1 bit for intensity control (bright or normal)
1 bit for orientation (erect or rotated 90 degrees CCW)
1 bit to select a focus level (sharp or fuzzy)
10 bits for the x coordinate
10 bits for the y coordinate

Format 2 (The Typewriter Mode):
1 bit for intensity control
7 bits to choose a character; CHi = 0 to 122, where i = 1 to 4
Note: Device stays in Format 2 until CH1 is 123 or higher

The reader can be forgiven for being underwhelmed when considering this instruction architecture; there is no earth-shattering development here. So, what about the dd-80 was so unprecedented? Perhaps the following set of speeds will justify our excitement:

Display a point at (x,y) 4 microseconds
Draw a line to (x,y) 6 to 42 microseconds
Draw a character 9 microseconds
Frame advance about 30 milliseconds

Especially in 1961, this performance was unprecedented. No other display and film recorder came even close to these speeds. The reason for this speed lay in an electrostatic deflection system. Most CRTs used a magnetic deflection system because it could produce more accurate deflections, albeit at the expense of speed. The dd-80 engineers, Floyd Hartwig and Robert Mann, used great skill and attention to detail to achieve an accuracy almost as good as most magnetically deflected CRTs, and more than adequate for our purposes.

The camera was a modification of one that had been developed by Mr. Robert Woltz of Flight Research, Inc. for use in photographing spark chambers at the University of California Radiation Laboratory in Berkeley. It was sprocket-driven and registered each frame onto a set of fixed pins, thereby guaranteeing the frame-to-frame accuracy required for motion picture production. It did this at a nominal speed of 30 frames per second. We added 1,000-foot film magazines that had the film supply magazine split from the take up magazine. This obviously facilitated the shortest waiting time between the production and viewing of motion sequences associated with our large design simulations.

There were two other improvements we made to this facility. Working with Chris Zutes, a Kodak representative, we were able to get a line of film that matched the phosphor-light distribution extremely well. This emulsion, the type RAR 2498, was coated on Mylar thus providing both extra toughness and stability. The RAR 2498 film is a monochrome coating.

For the second improvement, we joined with Dave Dixon from the Lab's Technical Photography Group, and Leonard Nelson of the firm EPOI that represented the Nikon in the US, to develop a special 50-mm lens designed to match the light frequency output of the CRT and the sensitivity of the RAR film. The results were spectacular--we gained in photographic sensitivity, and more than doubled the resolution that could be recorded on the film. Time has dulled my memory so I no longer can say how many dd-80s we installed--it was at least three.

Over the course of their approximately 20-year lifetime, we recorded around 1,000 miles of film, producing millions of pages of text and graphs, and thousands of motion pictures that were mostly used directly by those running the various simulation studies. At the end of these lifetimes, for some (not so mysterious) reasons, speed became less important and the dd-80s were replaced by FR-80s (up to six of them) that produced higher-precision pictures on all sizes of film and paper formats, and a whole graphics workshop built around a DICO-MED color movie maker. Notwithstanding, the dd-80s were very good devices; fast, reliable, and when properly maintained, capable of producing easily readable text.

One other serendipitous effect was the development of good software, largely written by Ken Bertran. The package was called "Calligraph," and it was a low-level language intended to support all manner of graphics applications. Specifically, Calligraph supported applications in film digitizing (the Eyeball), movie making, and interactive graphics. The language was designed to be hardware-independent, except for the actual construction of display commands. As will be obvious, graphics is heavily dependent in the management of threaded lists; one that is being displayed, and other lists, and the handling of asynchronous interrupts.

There were just 12 routines that comprised Calligraph (these basic CALLIGRAPH routines occupied about 530 words on the IBM 7090, and about 500 words on the CDC 6600):

Function Purpose
IGRAPH (i,j,k) Initialize the display and allocate j words starting at i for display buffer memory. k = minimum buffer size used for a naned picture part.
Later, if i is not zero, then the display is active and j = unused buffer size
NAME (A,N) Designate a picture part named A with light pen value n
CLEAR(A) Clear a picture part A
IN (A) Enter the picture part A into the display list
OUT (A) Remove the picture part A from the display list
RUN (M) Turn the Display on continuously if M = 0, if M < 0 run the display for M cycles
trACK (X,Y, N)` Display the tracking cross at (X,Y). If it sees display light set n=1; update (X,Y)
NtrACK Stop following the Light Pen
LPEN (N, X, Y) The Light Pen value N was seen by the Light Pen at (X,Y)
STOREC(i1,C1,i2,C2,i3,C3,I4,C4) Construct text and add it to the current picture part
STORE (construct a
display word)
Construct one display word and add it in the current picture part. The structure of a display word was given earlier

DD8-0 Photographs
Click on an image to view it at full size.

Figure 1:
The dd-80 direct view CRT in between two dd-50s. Each dd-50 was associated with a CDC 6600 system; the one on the left, and the red leather chair came with serial #1 of the 6600. A manager (naturally) appropriated the chair for his office--rank has its privileges. ./images/dd80-1.jpg
Figure 2:
This is a view of the dd-80, serial #1, with the camera unit in the left background. The dd-80, when first delivered, was first interfaced to an IBM 709, then to an IBM 7090, and finally to the 7094. On the left of the 7094 console is a card reader able to read 150 cards per minute. At the extreme left of the picture is an IBM line printer; rated at 150 lines per minute. In front of the dd-80 camera unit are two I/O engineering consoles because we had two channels. The dd-80 was interfaced through one of the I/O channels to a special unit that provided a 36-bit data item to the dd-80 every 6 microseconds. Also visible in the center background are the two core memory units for the 7094. Each housed 16k of 36-bit words.
Figure 3:
This is an interesting and amusing picture of the dd80's 5" CRT along with the Flight Research 30 fps camera. The spots on the face of the CRT are permanent magnets glued to its face. Instead of expensive and slow electronics ordinarily used to compensate for barreling and pin cushioning in the display raster, these magnets accomplished all that was needed to remove these aberrations, and at no cost. The engineer, Bob Mann merely used the pattern generator pictured on the top of the CRT housing to display the four lines that defined the edges of the displayable area and placed the magnets so that the lines were as straight as possible. Simple, elegant, and effective.

Figure 4:
A view of our second dd-80, this one interfaced to a CDC 6600, showing the camera unit mounted on a solid, 2-inch thick table of aluminum. A rough analysis indicated that no unwanted vibrations would bother the camera. I thought it was a mistake not to mount the CRT on the same table as the camera. However, it never seemed to matter; vibrations were not a problem
Figure 5:
Another view of the dd-800 installation on the CDC6600. Note that the manager, by this time, had appropriated the red leather chair for his office, leaving some decidedly lower quality chairs for those who needed to sit at these consoles. Actually, people hardly ever had the luxury of sitting and working at these stations, but to complete the story, we (in good jest) often escorted certain visitors to the manager's office to see the red leather chair. He never gave any explanation other than that the chair was too good to be left in a computer room.
Figure 5:
The dd-80 was fast. Norman Hardy produced a simple demonstration of a 2-dimensional hydrodynamics program for presentation on the direct-view console. The version shown used an 8 x 8 mesh to show the responses to a variety of forces applied on all four sides. Most of the parameters needed could be adjusted by program. If one wished to make a movie of the calculation, a 15 x 15 zone version of the problem ran at the speed of the camera; 30 frames per second. With suitably adjusted densities and equations of state, the mesh vibrated like a piece of gelatin, and this name stuck to the demonstration. Aside from being amusing, the computation was helpful for new employees in visualizing phenomena like elasticity or computational instabilities.

For information about this page, contact us at: