Return to SAGE, Architecture

Added Table of Contents
Background - training
The AN/FPS-24 Frequency Diversity Radar
- dual-cancellation MTI (moving-target indicator)
AN/FST-2 Radar Transmission Set
- “digitize” the analog radar signals
- Drum operations, video & azimuth
- Height queries
- ClutterMapper
The AN/FSQ-7 Direction Central Computer
- CPU & tricks
- The Direction Central computer program
- Failure Reduction
- "Active" & "Standby" machines
- Transfer Operations
- (Marginal) Voltage Testing
Messages from David Casteel to:
to J.Ray, 1's complement & massive I/O
to J.Ray, AN/FSQ-7 Display Systems, Operators
- Situation Display (SD)
- Light Gun
- Data Display (DD)
to J.Ray, Logic of the CPUs
- Clock, Commands, Instructions
- Illegal Instructions ;-))
- Additional Clock Pulses
to E.Thelen, Anti-Jamming




Recollections of the SAGE System

by David E. Casteel, Captain, USAF (ret)

Background.

First of all, let me give you some idea of my involvement with radar in general and the SAGE system in particular. I entered the USAF in February, 1960 at Mt. Hebo AFS, Oregon as an entry-level 3041 anticipating being assigned to radar maintenance at that site. As a graduate Chemical Engineer, I should have been sent first to Keesler AFB, Mississippi for a 51-week course in Ground Electronics, but for some reason that did not happen. I believe an error caused me to arrive at Mt. Hebo a year early, when I would then have replaced Lt. Barry D. Kushner, who was the existing Radar Maintenance Officer when I did arrive there and would have been eligible for rotation about a year later. My “education” in Ground Electronics and “officership” was pretty spotty, and a lot of it was done by Operations NCOs, as there were precious few radar NCOs at the 689 th at that time.

My boss, the station Ground Electronics Officer, instead put me in charge of the new AN/FST-2 radar digitizing equipment just being made operational and I attended local classes on that gear taught by the Burroughs Tech Reps. When construction began on the new Frequency Diversity AN/FPS-24 radar, I was sent to Eufaula, Alabama in the Fall and Winter of 1960 to learn about that system, principally as anti-jam operator (as that was the class that had an immediate opening).

I returned to Mt. Hebo after that and did become the first RMO on that AN/FPS-24 set—a job I had for about a year and a half. When Lt. Kushner left, I also picked up responsibility for the 2 height-finder radars and all the ancillary equipment, too. I don’t know what brought it about, but I was selected to go to Kingston, New York for IBM training on the AN/FSQ-7 Direction Center Computer and spent 18 weeks there learning all about that most interesting equipment.

Upon return to Mt. Hebo, I was almost immediately transferred to Adair AFS, Oregon (near Corvallis) and arrived there in August, 1962 to begin preparations for the OJT and cross-training of the USAF personnel still in training at IBM Kingston (my class was about a month ahead of theirs). I worked with the IBM Tech Reps to get their training set up and started and soon took charge of one of the 3 rotating crews which did maintenance on that computer system round the clock, a job I had for about 1.5 years. During all those technical courses on the radar and computer systems, I was exposed to a lot of details about their maintenance—indeed, in the case of the AN/FSQ-7, it was essential that the shift OIC and NCOIC be skilled in technical details, because initially the maintenance troops were only taught about their 1/3 of the system: Input/Output Subsystem; Central Computer Subsystem; or Display Subsystem—the OIC/NCOIC acted as interpreters and performed coordination of activities when they crossed the boundaries of those subsystems.

Naturally, cross-training was immediately begun to improve the understanding that those maintenance troops had of the adjacent subsystems, and in time the OIC/NCOIC were not as much needed to provide coordination; nevertheless, the original complement of personnel had been trained with this more active involvement of the OIC/NCOIC of the shift crews in mind. As it happens, I have a rather retentive mind, and I still remember a lot of details about those equipments (for which I do not have any manuals or other documentation available).

I am writing this document to pass on what details I do remember about those equipments, particularly as to design parameters and how they worked. I don’t guarantee that this will be particularly well organized, as I am doing what, in computer terms, would be called a “core dump” (a setting down of what can be retrieved).

The AN/FPS-24 Frequency Diversity Radar.

I have already written a document on this radar, so will not repeat a lot of that information here. Basically, that radar operates in the VHF frequency band, 214-236 MHz, which just barely overlaps the frequencies allocated to VHF TV channel 13. The Frequency Diversity radars were the first, I believe, to include “chirp” (pulse compression) technology as part of their basic design. Using pulse compression required that the transmitted pulses be encoded with a frequency which varied in a controlled manner during the duration of the pulse (so that it could be compressed upon return), and that, in turn, required a transmitter chain which could reproduce accurately the pulse coding passed into it while generating huge amounts of output power.

An oil-cooled TWT was used to perform preamplification of the radar pulse, and a water-cooled triode tube was used as the final power amplifier. When transmitting the “long” pulse (18 usec), the transmitter of each of the 2 channels operated at 5 MW peak power (30 KW average); the compression logic brought the returned pulse back to a 1 usec length at greatly increased amplitude, which did a lot to improve the signal-to-noise ratio of the system. The radar operated at a pulse-repetition-frequency (PRF) of 333 pulses per second, which was quite a bit more “listen time” than the older surveillance radars in use at the time (360 pps) and gave the FD radars a lot more theoretical effective range.

The receiver utilized the very latest dual-cancellation MTI (moving-target indicator) circuitry, which did a lot to improve the presentation from that site (half the view was of the Pacific Ocean, and that caused a lot of “angels” (wave clutter) in the earlier radars). State-of-the-art anti-jam circuits were provided, of course, and electronically, the AN/FPS-24 was able to provide outstanding displays of the air picture under most conditions. The very low frequency at which the radar operated gave it somewhat of an OTH (over-the-horizon) capability, too, and that was part of the design, I am sure.

Much has been written about the physical characteristics of that radar set, and its particular installation at Mt. Hebo. I have previously detailed the problems associated with the mountain itself and the high winds typical there, and the modifications to the radar and its tower (and subsequent attempts to cover it with a radome) so I won’t do so again here. Suffice to say that it probably was ill-conceived to attempt to place such a huge antenna structure atop that mountain, and eventually the AN/FPS-24 was, in fact, removed and replaced by an AN/FPS-27, which operated at a much higher frequency and had a much smaller antenna.

Others have written about the problems with the antenna bearings and other matters; all of those occurred after I had departed the station. I was involved in the event whereby shotguns and bird shot were employed to shatter ice which had formed on the antenna and plugged the openings in the “screen” which made up the reflector. I also made a trip back to the “mountain” in October, 1962 from Adair AFS to view the extreme damage resulting from the destruction of the first “sandwich” radome by high winds.

The AN/FST-2 Radar Transmission Set.

The AN/FST-2 was designed to be the interface between the surveillance radar grid and the AN/FSQ-7 Direction Center computer. It was built by Burroughs Corporation and incorporated several quite interesting innovations to make its basic task much simpler. One must remember that these equipments were designed and built in the late 1950s and early 1960s and computer circuitry was not nearly as developed then as it is now—numeric memory registers were composed of “flip-flops” built from vacuum tubes (2 per unit) and the equipping of a device with a large number of these was not practical.

The main function of the AN/FST-2 was to “digitize” the analog radar signals provided by the surveillance radar equipment, and it was decided to divide its resolution into ¼ mile range units. With a basic range limit of about 250 miles, this means that there are approximately 1000 range blocks in each radar transmit/receive cycle. The comparison circuitry for target detection needed about 7 to 9 radar cycles to be retained in memory to allow for statistical operations on returns in adjacent boxes at the same range to decide when a target leading edge was detected and when the trailing edge occurred.

To do this with vacuum-tube registers would have required about 20,000 tubes and this was not deemed acceptable. Large memory arrays (ferrite core) were not yet available, nor was the computer architecture which would be able to utilize such devices efficiently. A most interesting methodology was devised to handle this problem.

Multiple tracks on a rotating magnetic drum were employed to record and read back the “quantized” (range-blocked) radar data for each radar cycle, and this data would progress from track to track as new data was received. The rotating drum was synchronized with the radar PRF such that the drum rotated at ¼ the PRF rate and multiple rows of read and write heads were positioned to log the data onto the drum in parallel on the several tracks. This allowed for the retrieval of several PRF cycles of data simultaneously for each range block, from which statistical operations could determine the leading and trailing edges of targets.

A gear-driven optical wheel divided each antenna rotation into 4096 divisions, the azimuth pulses being used to drive an Azimuth Counter. To insure that glitches did not cause the count to drift, the counter was reset to zero by a “North pulse” from a mechanical switch on the antenna itself (which gated the azimuth pulse to clear the count). A complex gating circuit synchronized the Azimuth Count pulses with the radar triggers. As it happens, a PRF of 333 means that there is .003 seconds between radar triggers; dividing a 12-second (5 rpm) rotation time into 4096 parts means that the azimuth pulses come about .0029 seconds apart, which means that every so often an azimuth pulse would be skipped. Radars with the more typical 360 PRF would occasionally use the same Azimuth Count for 2 radar cycles.

The drum circuitry also provided a set of target azimuth counters, one for each range block, which would be assigned to targets as they were detected. Each counter began with a value of zero: when a target leading edge was detected, the counter for that range block began counting every other azimuth pulse; when the trailing edge of that target was detected, the assigned counter began counting every azimuth pulse. When the counter was queried for its target, the target counter was simply subtracted from the current azimuth counter and, voila! The center azimuth of the target was obtained. This datum was combined with the range block associated with that target and formatted for transmission to the Direction Center over the land lines.

Another function of the AN/FST-2 equipment was to receive height queries from the Direction Center and drive the assigned height-finder radar antenna to the appropriate azimuth to “paint” a designated target, from which the human height operator would visually bisect the displayed vertical trace and the height associated with that cursor position was then returned to the Direction Center as the target’s height. This, incidentally, is the origin of the “semi-automated” in the SAGE designation (“Semi-Automated Ground Environment”).

Another piece of the AN/FST-2 was the “Clutter Mapper”, which was just a PPI scope with a photosensor located above it where it could “see” the whole display. The digitized radar information was displayed on the PPI and the pulses observed by the photosensor were what was entered into the drum memory system. To mask out heavy areas of ground clutter, an operator just used an amber-colored marker to write over those places on the PPI face, which effectively hid the returns underneath from the blue-sensitive sensor and prevented them from being considered by the rest of the circuitry. The screen was cleaned off with alcohol when it was necessary to change the areas obscured. When the AN/MPS-11 radar was in place, much of the central area of the data from Mt. Hebo was always mapped out by the Clutter Mapper; when the AN/FPS-24 went on line, the MTI system was so superior that very little mapping-out was required.

The AN/FSQ-7 Direction Central Computer.

The AN/FSQ-7 computer was a very ambitious project, easily being the largest computer built at that time. The CPU was about the same design level as the IBM 709, but the addition of the special Input/Output and Display equipments made it much more complex than that commercial machine. The AN/FSQ-7 was an outgrowth of the Whirlwind I computer originally built at MIT and later transferred to the MITRE Corporation facilities. Its CPU was designed to use 32-bit “words” (the equivalent today of 4 bytes) and IBM had promised to deliver a magnetic core memory system with a 6 sec read/write cycle time.

The original memory was 64x64 (4096) words and the later-supplied “big memory” was a 256x256 unit (65,536 words). In today’s parlance, the “little memory) would be a 16KiB (Kibibytes) unit and the “big memory” would be a 256 KiB unit—not very big, by our standards now. Today’s laptops have more and faster memory than those 1960s behemoths. As it happens, IBM was not quite able to deliver a 6 sec memory cycle—it was actually 6.3 sec, and they had to pay a pretty big penalty for that .3 usec failure.

The central processor (CPU) used a fixed-length instruction cycle based on the basic memory cycle time: branch instructions, which only had to have one memory cycle (to read the next instruction address) were 6.3 usec in length; addition and subtraction instructions had to retrieve a data value (1 memory cycle) and then the next instruction, so they were 12.7 usec long. As it happens, this 2-cycle length was more than adequate to handle the normal add/subtract logic process, so an interesting trick was done to speed up the multiply instruction: the add circuitry (also used for subtract by complementing and adding) incorporated an automatic shift right one position, which meant that no extra time to perform a register shift was needed by the multiply function, with the result that it only took 16 usec; naturally, the add and subtract instructions did need to make a “correctional left shift” at the end, but the 12.7 usec was more than enough to handle that (remember that the cycle time was being driven by the need for 2 memory cycles).

As you might expect, this automatic right shift was detrimental to the divide function, which had to first have a correctional left shift and then another left shift to operate the divide logic—as a result, the divide took 52 usec to complete.

One may think that this technique would be counterproductive, but a major part of the CPU’s time was devoted to making polar-to-rectangular coordinate conversions of the incoming radar data, and each such point conversion required 2 multiplications. With each of up to 16 radars reporting as many as 500 data points each antenna scan (nominal 12 seconds at 5 rpm), that is a need to perform 80,000 multiplications each minute, and the designers were looking to save time any way they could. Division, on the other hand, was typically used to provide the speed value of a track, and would occur much less frequently.

As a matter of fact, another trick was used for the coordinate conversion process: a little instruction called “twin and multiply”. The full precision of the CPU accumulators was not needed for coordinate conversion—about 5 decimal places was easily sufficient, and this precision could be accomplished in only a half-word. The preparation for the process loaded the range value in the Distributor register and the values for the trigonometric sine and cosine of the azimuth angle each into one half of the Accumulator register; the twin-and-multiply instruction multiplied both halves of the Accumulator register (treated as independent halves, each with its own sign bit) by the range value in the Distributor, thus performing both steps of the conversion in one single 16 usec cycle.

This was a good thing, because 1 minute contains only enough time for about 62,500 16-usec cycles and even if the maximum number of input points did not occur, that would in most cases leave little to no time for other operations. Clock pulses were generated at a rate that divided the memory cycle into 12 equal intervals, or at about a 2MHz rate (0.5 usec between clock pulses). The “extra” time required by the multiply and divide instructions (over that provided by the 2 memory cycles needed) was provided by pausing the standard memory operations while additional clock pulses continued to operate the instruction microprogram. Certain other instructions also needed additional time beyond that needed for the number of memory cycles involved (shift and cycle register commands and some tests) and the same paused buffering was used to handle those, too.

The Direction Central computer program was about 93,000 instructions in total (small by today’s standards), only a small portion of which stayed resident in memory—the rest was written out to magnetic drum storage, from which it could be retrieved as needed. This was the first recorded usage of “swapping” memory out to non-resident status, I believe. There was separate circuitry provided to perform this swapping, so the CPU program counter was not adversely affected by it.

The primary Direction Central program executed in approximately 15-second “frames”, each of which was divided into 3 “subframes” of approximately 5 seconds each. The work of the program was divided among the subframes to insure that each step was performed as often as necessary; coordinate conversion was performed by all the subframes.

An interesting feature of the control consoles in the central room was an audio speaker driven by an amplifier connected to the output of a selected bit in the Accumulator register. When activated, this speaker emitted a sort of rhythmic “rustling” sound which ebbed and flowed in synchrony with the actions of the program subframes. Although these sounds would vary considerably over time, the sequence of sounds produced did demonstrate a remarkable consistency within a short time span, and any sudden departure from this normal sequencing could be instantly detected by the operators and usually indicated a major problem within the CPU.

With each CPU containing thousands of vacuum tubes, each of which could randomly fail at almost any time, such a device could be expected to have frequent failures. Several techniques were used to reduce the incidence of unexpected failures to a level which could be tolerated. First of all, the AN/FSQ-7 facility contained 2 complete CPU elements—the “A” and “B” computers. Each of these CPUs was capable of running the entire show and they alternated daily, providing service for a 24 hour period and then undergoing maintenance and other activities for their “off” day. In periods of higher alert, both CPUs could be operating the Direction Central program simultaneously, and shared information between them.

The “active” machine was actually receiving the radar and other input information, was processing it, and providing the display data to the 100 or so consoles on the Operation floor; the “standby” computer constantly monitored the status of the active machine and periodically obtained backup data from it to provide a minimal level of continuity should severe problems develop with the active CPU.

When a fault was detected, automatically or by operator observation, it was then possible to switch operations to the standby machine (which became “active” in the process) in a matter of seconds. A planned switchover transferred approximately half of core memory, all the display drums information, and substantial parts of the auxiliary drum memories to the standby machine in just a few seconds, at which time the operator could manually initiate a switchover.

Transfers were performed by using drum memories within each CPU dedicated to this function, plus a few special transfer signal lines. Data from one CPU was directly written onto the other machine’s drum inputs, from which it was read by the host CPU at the same rate it was being written. This technique assured that the maximum of data could be obtained, even if the ailing CPU stopped functioning (since the data is on the side of the good CPU).

Another technique which assisted greatly in providing stable operations of the AN/FSQ-7 was a special provision for varying the supply voltages to specific circuits under program control of the CPU. This could simulate aging of circuits and trends in failure points were tested and tracked by special maintenance programs run on each CPU on days it was in standby mode. It is interesting to note that a study performed by MITRE Corporation indicated that, without this special ability to predict circuit failure before it could randomly happen (found during maintenance), circuits would fail faster than they could be isolated and fixed, and the computer would not run.

The electronics were distributed into a number of “frames” containing dozens of “pluggable units”; each contained up to 9 vacuum tubes and could be pulled from the frame and a good unit substituted when that unit was predicted to be approaching a failure point. Such pulled units were taken to a repair facility with sophisticated (for its time) equipment to check out and restore those units to perfect operation, at which time they were returned to the stock of good units.

It is interesting to note that each vacuum tube in the AN/FSQ-7 was individually air-conditioned to keep it from overheating. Cold (50 degrees F) air was forced in at the bottom of each frame, which was essentially a sealed unit when all its pluggable unit positions were occupied (blank plates were available). Each unit mounted its tubes on a sub frame within it and the tubes projected outward through circular openings of various sizes in the exterior plate of the unit. The amount of annular clearance between the rubber ring in the opening and the vacuum tube encircled by it controlled the amount of air rushing by the tube and thus the amount of cooling supplied.

Of course, one cannot ignore the enormous amount of equipment devoted to displaying to and receiving manual input from the many Operations personnel working at the Direction Center. In many ways, this part of the AN/FSQ-7 may well have been the most important part from the viewpoint of history, since it was the first effort at providing a true man/machine interface in real time.

And it was remarkably successful. It incorporated high-speed video presentation, both vector and typographic data, switch activation, and—most importantly—light gun technology, which was the precursor of our computer mouse and other pointing devices. The SAGE system can be truly considered to be the great experimental facility in which many of our capabilities to interface between humans and computers were developed.

Well, I’ve about worn my fingers to a frazzle and I’m blurring out at this point, so I’ll stop for now.

Respectfully,
David E. Casteel
Captain, USAF (ret)


Later thoughts sent by e-mail:

Message to Jim Ray on 13 SEP 2004:

The AN/FSQ-7 (and -8) were "1's complement" computers, not the "2's complement" logic that is standard today.  This meant that there were 2 valid bit configurations that equaled zero:  all "0" bits and all "1" bits; the former (all zeroes) was +0 and the latter (all ones) was -0, and numerically they were equal.  Since some arithmetic operations used a divided accumulator (called "left half" and "right half") with each half-word having its own sign bit, this meant that the accumulator could have a valid value of zero with 4 different configurations of its two halves (+0,+0; +0,-0; -0,+0; -0,-0) and this made testing the accumulator for a zero value somewhat complicated.  The test for zero actually performed 4 separate tests for all zero bits, separated by steps that complemented the halves of the accumulator in a pattern that complemented each half twice and put the register in each possible state, at the end leaving the accumulator contents the same as they were prior to the test; if any of the 4 checks revealed an accumulator value of all zero bits, the test was deemed satisfied and the zero check was true.  I don't know that there was any significant advantage to the Q7 by having this arrangement, and no modern machines currently use "1's complement" to my knowledge.

Some of the diagrams of the AN/FSQ-7 I have seen in various web sites show the IC drums (InterCommunications) wired such that they would be written on by their host CPU and read by the other CPU; my recollection is that this is backward--that each CPU wrote to the other machine's IC drum and read its own, so that if the "dying" CPU had to be powered off, the data still on the IC could be read by the machine going "active", thus minimizing data loss.  Possibly you have some independent source for verifying or invalidating this memory, but it is how I remember it.

I stated in my document that the Direction Central Active program was about 93,000 instructions.  This value does not agree with that on other web sites, and I will defer to them in this area, as I was not a programmer.

One of the web sites makes the spurious claim that the AN/FSQ-7 was no better than a less-than-$5 calculator today, and this is simply ludicrous.  The Q-7 was a stored-program machine with an ability to handle a large variety and amount of digital data inbound, outbound, and displayed.  That inexpensive calculator may have memory and some complex programmed computations, but it is NOT the equivalent of a stored-program computer.  It is true that the CPUs of the Q-7 were slower and had less static memory than even a Commodore 64 PC, but even the current PCs today would have to have considerable attachments to handle the input/output/display requirements of SAGE.  The display requirements, alone, would require at least 100 monitors (a Direction Center had about 100 display consoles) just for the situation displays, and others might be needed to handle the text messages.  (Of course, no one would attempt to reconstruct the SAGE system using modern equipment because the job it was designed to do does not exist any longer.  However; if a comparison with modern equipment is to be made, the modern gear should be required to perform the same tasks.)


Message to Jim Ray on 14 SEP 2004:

The Display System of the AN/FSQ-7 (and -8) was where the real man-machine interface activity took place.  The human operators sat before their display consoles and viewed information presented to them there and took actions by means of the Light Gun and console switches.  A Direction Center (Q-7 facility) was equipped with about 100 of these consoles, which were grouped into several functional clusters with different missions: 
- Surveillance,
- Identification,
- Crosstell, and
- Intercept Control. 
(I think I have that correct.) 

The Surveillance operators concentrated on the radar data displays and assigned track numbers to perceived "trails" of blips depicting the route of aircraft.  The radar info included blips from 7 scans presented in order from oldest to most recent so that they produced a crawling trail of dots defining the direction and speed of each plane being reported.  They could assign a track number to one of these trails by firing the Light Gun on the current radar blip (more about the Light Gun later). 

Once a track had been assigned, it became an "unknown" and was passed to the Identification section, which compared the position, direction, and other factors with flight plans that had been filed by the FAA or military organizations, and thereby could determine if the unknown was "friendly" (matched a plan) or "unidentified".  Unidentified planes were subject to having interceptors scrambled to make visual identification.  At some point those unidentified planes might be declared "hostile" and interception would commence in earnest. 

The Crosstell operators just managed tracks being passed to and from that DC and adjacent DCs.  All intercept activity, whether for identification or aggressive action, was performed by the Intercept section Weapons Controllers.

The display consoles themselves consisted of four main components:  the Situation Display (SD), the Data Display (DD), the Manual Inputs panel (switches), and the Light Gun. 

The Situation Display (SD) was a large (19") round cathode-ray tube that used randomly-positioned beams [now called "vector graphics"] to draw images on the screen.  This was not a raster display (such as TV) but the beam was directed to specific points in the array by an addressing scheme and modified in that position by character-generation logic to trace out the particular characters needed at that spot.  One of the character types was a solid dot, which could be displayed in two intensity settings--normal and high intensity.  Normal intensity was used for all data except the most recent scan radar blips and the track locator dot; those were displayed in high intensity and were enabled for use by the Light Gun.  The order of display processed the radar data first, followed by the track data, but within those parameters the individual tracks were not processed to the screen in any particular order (except the radar data was processed in such a way that all the oldest blips were displayed first, then the next-oldest, through the most recent (current) last, and the blips in each age level were displayed in the same order, producing a smooth trail on the screen).

The Light Gun did not function in the same way that a modern-day mouse does.  The mouse puts a generated image on the screen at a position whose coordinates are known by the operating system, which can then relate that position to the information depicted on the screen in that location to assign an action when a click is made.  The Light Gun, on the other hand, did not involve any information as to where the instrument was, but used time coincidence to convey the position information to the operating program.  First of all, only specific types of information being displayed on the SD were enabled for Light Gun activity (radar current and track locator)--the gun would not "fire" on anything else. 

Each of those high-intensity signals was under the control of an addressed message on one of the Display Drums, part of which was the coordinates of the blip.  When the Light Gun fired on a blip, it opened a gate that permitted transfer of the display message (including the coordinates and type) into the Light Gun control circuits, and only then was there any position information relating to where the gun had been pointed at the time of firing.  The little red circle projected onto the screen face by the Light Gun had no real function other than to allow the operator to get the sensor positioned near (and focused on) the blip he wanted. 

When the trigger of the Light Gun was pressed, the logic waited until the next enabled high-intensity blip appeared in the region where the gun was pointed, and then initiated transfer of the data associated with that blip into the memory area associated with that gun; this also set a flag that the gun had been fired so that the program would take notice of it.  The actual function performed on that blip was assigned by the switches in the Manual Inputs panel, which could also be used to send character information to the program when requested.  Other functions of the Manual Inputs panel were to control the particular types of information being shown on the SD and DD. 

The Data Display (DD) was a Typotron tube , which was quite an unusual display element.  It incorporated a storage mask (a fine wire mesh coated with non-conductive material located near the internal surface of the phosphor-coated display screen) that received character images and stored them as charged areas on the surface of the mask by action of the message generation logic and its associated electron beam.  The characters were formed by deflecting a thick electron beam through a particular stencil opening in a character array metal plate, and then re-deflecting this shaped beam to the appropriate position on the display (actually onto the storage mask).  Once written to the mask, the insulating nature of the mask enabled that configuration of charges to stay in position for a considerable period of time. 

The actual characters seen on the display screen were generated by illuminating that storage mask with a wide fan beam of low-intensity electrons, called the “flood beam”:  where the charge pattern for a character existed on the mask, the electrons were allowed to continue on to energize the phosphor on the screen; where there was no charge on the mask the weak electrons were blocked.  Over time, the weak electron flood beam would degrade the information stored on the mask, so it would have to be refreshed periodically.  The contrast available on the DD was not very great, either, but it was readable in the low light of the Operations area. 

There was a means of completely erasing all data on the mask, too, and this was done between messages to eliminate confusion.  A console that was not in use did not receive much activity for the DD, and sometimes this resulted in a message being left in the system unchanged for a long period of time, and this caused burn spots on the DD screen.  It was necessary to have procedures for standing down a console that would remove any DD messages being sent there to prevent that (costly) deterioration.

Of course, all this state-of-the-art (then) display equipment required a lot of circuitry and programming behind the scenes.  The information being displayed was stored on rotating drums:  there was a drum for the SD, another for the DD (actually, a part of the MIXD drum), and one for the RD (Radar Display).  The SD and RD data was identified by its display coordinates and several characteristics that could be filtered out by individual settings at each display console.  That is to say, all the SD and RD information was sent in parallel to all the display consoles, and each operator decided what portions of the information he wanted to see; the console logic allowed the selected data elements to be shown and ignored all the rest. 

The DD information was specific to each console and was sent there only by request of the operator (well, there were some high-priority messages sent unsolicited).  There was a lot of circuitry involved in translating the data as stored in CPU memory into the forms required by the various display drums and this was separate from the CPU logic; in fact, there were entire frames of these circuits and a large number of Distribution Boxes (that connected the consoles to the frames) constituting the rest of the Display subsystem (along with the consoles and drums).

I briefly outlined the Manual Inputs piece earlier, but there is more yet that I remember.  A part of the MIXD (Manual inputs, Intercommunication, Xtell, and DD) drum was devoted to an array of bits corresponding to each of the switches on each of the consoles--a "1" in that bit constituted a switch that was "on" and a "0" represented a switch that was "off".  When an operator initiated action, by Light Gun or other means, this array was read by the operational program and the switch settings for that console were then used to determine what activity would be associated with that action.  I don't remember the details of how often that array was refreshed, but it had to be quite often.


Message to Jim Ray on 9 JAN 2005: Logic of the CPUs

The logic of the CPUs of the AN/FSQ-7 and AN/FSQ-8 SAGE computers was produced by hard-wired instruction circuitry to cause specific actions to take place at specific time points within the Instruction Cycle.  There is a hierarchy to this plan:  Clock Pulses; Commands; and Instructions.

Clock Pulses.  All activity within the CPU is ultimately based on Clock Pulses.  Each Memory Cycle was divided into 12 clock intervals, each approximately .5usec long.  Both the Memory Cycles and the Instruction Cycles were keyed to these Clock Pulses. 

The actions within the magnetic core memories were controlled by the Memory Clock (derived from the basic Clock Pulses) and the instruction logic had a separate set of Clock Pulses.  The basic Clock Pulses were first run through a cyclic ring of gates that produced specific numbered Clock Pulses numbered from 1 through 12, and each of these 12 individually-timed pulses then was gated by other logic elements to produce the Commands used by the rest of the circuitry.  It was necessary to have two ring counters--one for memory and one for instructions--because the memory ring had to run continuously, but the instruction ring could be temporarily stopped for any of various reasons.  At this point, the CPU has raw Clock Pulses, .5usec apart, and 2 sets of 12 numbered Clock Pulses defining specific points in the Memory and Instruction Cycles.

Commands.  Commands are essentially specific Clock Pulses produced by gating the numbered Clock Pulses by other logic within the instruction plan and designed to perform a specific unique action on an element of the CPU hardware.  An example would be a Command to clear a part of the Accumulator, or to perform an Add within half of the Accumulator.  These Commands had 3-digit numbers assigned to them and these were used to trace the paths of the Commands through the logic diagrams of the CPU.  Every possible action to part of the logic hardware (Accumulator, Distributor, Adder, Shift Registers, Program Counter, etc.) was done by a specific numbered Command, which always occurred at the same clock time (from the same numbered Clock Pulse). 

There was a very large book called the Logic Index that laid out the timing diagrams for every instruction, showing the specific Commands invoked at every clock time within the instruction cycle.  Some instructions only required one Memory Cycle, some required 2 or 3, and others required 2 cycles plus additional "uncounted" Clock Pulses to complete the actions (the Multiply, Divide, Shift, and Cycle instructions).  The Logic Index also referenced the book and page of Logic Diagrams where the Commands involved in the Instruction originated (and from which its path could be traced).

Instructions.  As described above, Instructions are merely controlled sequences of Commands and they occur by interpreting the Instruction Code and enabling or disabling various gates controlling the distribution of Commands to the CPU logic circuitry.  Instructions were identified by 3-digit codes, assigned in Classes by initial digit:  all Add-type instructions (including Subtract) had codes beginning with the same digit; all Multiply/Divide instructions began with a different digit; all Store instructions had yet another initial digit; etc. 

In order to avoid using more gates than necessary (they were expensive back then), the gating of the Commands was done at the highest level of Instruction Code decoding permissible:  if a particular Command was always done for every instruction within a Class (e.g., all Add-class instructions needed the Command to initiate an Add function), then that Command was gated only by the first digit of the Instruction Code; there was a hierarchy of gating that minimized the gating circuitry to that required to perform the Instruction Set--and no more.  As it happened, not all possible Codes within each Class were ever actually defined for use, a condition that created a lot of so-called "illegal" Instructions. 

An "illegal Instruction" is simply one for which its Code does not invoke a full set of Commands, but does invoke all of the ones that are common to all Instructions in a Class or Subclass.  Because of the desire to minimize the control logic within the CPU, the design did not incorporate any gating to prevent those illegal (unused) Instruction Codes from passing Commands--if a program specified one of those illegal codes, the actions controlled by those common Commands would actually be performed, whatever they were, and most of the time the results would be unpredictable and undesirable. 

However, programmers being the inventive people that they are, some of them did find the functions performed by these incompletely-specified Instructions to be useful:  e.g., any illegal Store Class instruction performed the initial clearing of that memory location (because all Store Class instructions needed that function); however, since it was not a recognized Instruction, no other functions (Commands) were gated through.  The result was that invoking an illegal Store Class instruction simply cleared that memory location to zeroes.  The principal method for preventing illegal Instructions from being specified erroneously in programs was a QC check within the Assembler Program that rejected any Instruction Codes that were not part of the recognized list. 

Eventually, those illegal Instructions that had found favor with the Programming Staff (by performing useful activity) were given official Codes and Mnemonics to be used, and the Assembler was modified to accept those specific previously-illegal Codes.  No changes to the CPU wiring were made to implement these "new" Instructions--the only action was to pick a specific one of the numerous illegal Instruction Codes in that Class and make it "legal" (however, any of the other illegal Codes would also work if allowed to pass).

Additional Clock Pulses.  Several of the Instruction Classes could not finish their activity within the 2-cycle normal Instruction period (24 Clock Pulses), principally the Multiply-Class Instructions (Multiply and Divide) and the Shift-Class Instructions (Shift and Cycle).  By an arbitrary feature of the Clock Pulse numbering scheme, the Instruction Cycle always was considered to begin with Clock Pulse 7, proceeding through Clock Pulse 12, then going to Clock Pulse 1, etc., ending at Clock Pulse 6.  Multiply Instructions always took 16usec (32 Clock Pulses) to execute, Divide Instructions took 52usec (104 Clock Pulses), and the Shift/Cycle Instructions could require varying numbers of additional Clock Pulses to accomplish the number of positional shifts requested by the program.  To allow for this activity, the normal Instruction Cycle Ring Counter was halted at the point where the additional repetitive functions were required and raw Clock Pulses were then supplied through an auxiliary set of gates to provide the specialized Commands needed to perform the extra operations.  When the extra time required had passed, the Instruction Cycle Ring Counter was allowed to continue cycling to wrap up the Instruction.

I earlier mentioned that the Multiply Instructions were speeded up by incorporating a wired right shift into the Adder circuitry--every Add logic invocation resulted in shifting the value in the Accumulators to the right one position, ready to handle the value to be added by processing the next digit in the multiplier.  The Add and Subtract (which is really a Complement and Add), of course, did not want the value so shifted (and altered by a factor of 2) so a Correctional Shift Left was required to restore the proper value.  The total of 24 Clock Pulses (2 sets of 12) available to the Add Class of Instructions was more than sufficient to allow gating in a Command to perform this Correctional Shift Left, so this was not a problem.  However, by not requiring a specific Shift Right for each step of the Multiply process, enough time was saved to make the Multiply take only a little longer than a normal 2-cycle Instruction.  Naturally, this automatic Right Shift by the Adder logic was detrimental to the Divide process, which needed left shifting to perform its function.  The Divide, therefore, needed not only the Correctional Shift Left (as with the Add and Subtract) but also an additional Shift Left to process the Divide.  This is why the Divide Instruction requires so much more time than any of the others.  This tradeoff was recognized, of course, but it was also known that the Direction Central program would require enormous usage of the Multiply function (coordinate conversion from Polar to Cartesian), but would only need a few uses of the Divide (mostly to get the speed of a track).


Anti-Jamming Casteel to Thelen March 12, 2012

Ed,
I left the SAGE system fairly early in its development (1964) and so did not have a lot of experience in how it handled jamming. When I was involved, the principal thrust was to counter jamming in the radar equipment so that a cleaner data stream was sent to the AN/FST-2B for digitizing. The Frequency Diversity (FD) radar scheme was installed to insure that radars with widely different frequency ranges covered the same portions of the sky, so that jammers would have to spread their efforts over a much wider frequency spectrum to be effective. Many interesting circuits were also incorporated to counter specific types of jamming. Of course, given enough jammers with enough power, their effects probably could not be completely countered. The AN/FST-2B did not, itself, have any anti-jam capabilities—its primary function was to find the range and azimuth of the center point of any radar blips fed into it, and formulate that information into a data stream sent to the computer at the Direction Center. It handled both radar and IFF/SIF inputs. There were some thresholds that could be set in the input processing section, but they probably wouldn’t have been too useful as anti-jam operators. The design of the target center detection was a pretty good foil against “running rabbits” type jamming (most usually caused by adjacent radars on the same frequency, but possible as a deliberate jamming attempt).

I know that when I left SAGE there were some attempts under way to programmatically process strobe-type jamming that made its way into the computer to determine the intersections between strobes input by different radar sites as probable target locations. I have no idea how effective those efforts were, however. Chief Fitzgerald on AllServicesRadarVets was very involved with the programming in SAGE and he may have more insight into that activity.

There have been arguments pro and con about SAGE and its ability to do its function, with and without jamming, for many years. It is pointless to talk much about it now since it has been gone for a long time, but I do believe that it did serve a purpose. If it did nothing else, it probably served as a deterrent to a massive bomber attack on our country. Since we never experienced such an attack, we’ll probably never know. Many advances in technology were furthered by investment in SAGE and we continue to reap benefits from those even today.

The new FD radar systems (AN/FPS-24, AN/FPS-26, AN/FPS-27, AN/FPS-28, AN/FPS-30, and AN/FPS-35) all incorporated sophisticated receivers (AN/GLA-8) designed to counter jamming. Combined with the “chirp” (pulse compression) feature in the transmitter and receiver, these were quite effective in reducing the effectivity of most jamming. The reason little has been written about these matters is that for a long time such information was highly classified. I suspect that much of it still is. I have read a number of postings by people at the SAGE radar sites sharing data with FAA that most of the anti-jam features of the radar were disallowed by them. I have no direct experience to support this, however.

David