The following fact sheet is
from a memo in the Burroughs Corporation Collection (CBI 90), Product
Literature (Box37) at the Charles
Babbage Institute for Computer History, Minneapolis, MN.
Detroit, Michigan 48232
Phone: 875-2260, Ext. 2234
Richard J. Brady
Defense, Space and Special Systems Group
Phone: NIagara 4-6962
Radar Course Directing Group for the Back Up Interceptor Control
DESCRIPTION: BUIC is a semi-automatic backup to SAGE which
provides for conduct of the air battle in the event that portions
of SAGE become inoperative. Burroughs Corporation is providing the
AN/GSA-51 Radar Course Directing Group which functions as the
central control for Air Surveillance and Weapons Control for the
BUIC system and includes the following general capabilities:
of radar data from long range radars.
of tracks based on radar input presentation of this data
for evaluation by operators.
of capability for manual track information and automatic
maintenance of tracks.
of available weapons to permit pairing with tracks and
analysis of commitment to assure intercept ability.
transmission of pre-launch and fire command based on
generation and transmission of guidance commands.
AN/GSA-51 consists of a Burroughs D825 modular data processing
system. It is in the modular data processor that the operational
program is stored and executed. For the BUIC application, two
computer modules, six memory modules and three input/output
modules are utilized. Data exchange occurs simultaneously between
any memory and any computer or input/output module. The modular
nature of the equipment not only permits operation of the system
when some modules are inoperative, but also permits convenient
expansion to increase capability. The data processor can be
readily expanded to up to four computers, 16 memories and 20
input/output modules with no obsolescence of hardware or software.
Input/output modules for the BUIC system consist of message
processors and controller-comparators.
radar information from long range radar sites via the message
processors. The data is temporarily stored, formatted into
computer words, and transferred to core memory via a
controller-comparator. Controller-comparators handle data
transfers between core memory and all devices except computers.
operating on the data stored in core memory, performs all the
computations necessary for generating appropriately formatted
display data. The display data, stored in core memory, is
transferred via a controller-comparator to the display fields of a
drum, which in turn automatically presents this data to each
display console 30 times each second. To accomplish all of this,
the computer executes a succession of program segments called up
from the drums.
available at each display console, which includes up to 12,288
symbols or vector segments, is selected by an operator by means of
15 category selectors. Radar data displayed includes current data
together with up to seven history points to permit track
initiation. Once the operator initiates a tracking action by means
of a light pen on the display, the computing system automatically
maintains the track by prediction and examination of incoming data
for correlation. Height requests are automatically generated and
transmitted based on track priority, or may be operator initiated.
When it is
established that defensive action is to be taken, the operator can
call up weapons status information, which is being continually
updated via card reader inputs. He can then call upon the computer
for solutions to possible intercepts, the solutions being made to
appear at the requesting display console. Once a weapon is
assigned, the computer generates the necessary launch and guidance
commands, and the track on the weapon is initiated automatically.
The launch and guidance commands, stored momentarily in core
memory, are accepted by the message processor, formatted, and
transmitted over the appropriate communication lines. All the
while, messages are being exchanged as required with adjacent air
equipment performs support functions. Magnetic tape units are used
for simulation inputs and recording for training, and backup
storage for programs. A typewriter is a backup input for the card
reader and is also used in system maintenance. A status display
console presents indications of which units are
"on-line," or "in test," or in a failed state.
It also houses the central power control to assure orderly system
shutdown without loss of stored data in the event of a power
failure. A line printer provides high-speed printout to permit
rapid program evaluation and change, and evaluation of test
missions. Simulator message composers are training aids for
weapons director, for both initial training and maintenance
D825 is a functionally modular data processing system, it is
possible to achieve increased availability without full duplexing.
This is accomplished by providing additional modules of the
computer, memory, input/output module and an additional display.
While the operational program is functioning, an error recovery
program is being cycled in one computer, one memory, and one
are continually exchanged between the "backup" and
operational group and other modules are continually checked. The
operational program continually stores "safe data" to
permit recovery from a temporary computation interruption. If an
error is indicated, the operational computation is temporarily
suspended and the system is turned over to the error recovery
diagnostics program, which identifies the faulty module and
notifies the operator via the status console and typewriter
printout. The system is returned automatically to the operational
function with information on what modules are available for use,
and the operational program reconfigures, utilizing the safe data
previously stored. This recovery period will vary from about 15 to
30 seconds. The failed module is then further analyzed, repaired
and returned to the operational system.
Intercept Control (BUIC) Training and Installation Data
31 January 2010
Robert W. Nelson, CMSgt. USAF Ret.
During the period between 7 January
1964 and 14 November 1965, I was a TSgt. Team Chief serving in the 2866
Ground Electronic Engineering Installation Agency (GEEIA) Squadron at
Kelly AFB, TX.
The Air Force decided it would install
the BUIC II. However, the Air
Force had no computer installation people within the GEEIA organizations.
GEEIA was to train the following in
house Air Force Specialties for the installation of the BUIC II Project:
Radar Repair Technicians
304X1 Nav-Aids Repair
304X2 Ground Radio Repair
I do not recall the exact number of
personnel selected to attend training, since it has been 45 years. But
ultimately there would be 5 man teams consisting of personnel provided by
several GEEIA Squadrons trained then each team would spread out across the
nation to do the installations, perform a 72 hour Hot Check and then turn
the BUIC over to the operating site personnel.
The BUIC had well over a half million electronic
component parts. For the Hot Check, the BUIC had to operate 72 consecutive
hours with a very limited number of failed parts and had to achieve strict
operational parameters. Our
team had very good luck on the two installations we completed.
Mike Loewen - BUIC lab in Bryan
Hall - Keesler AFB
These pictures were taken during 305x4 Computer Maintenance training at
Keesler AFB in the latter part of 1982 in the BUIC lab in Bryan Hall. The
yellow-rope A1C is me (Mike Loewen). In the group picture, Sgt. Mike Best
is on the extreme left, and Amn. Dan Setaro is in the middle of the front
row. The three of us finished school in December of 1982 and went to
McChord AFB to work on the AN/FSQ-7 until it was decommissioned in August
The BUIC project development was located at the Burroughs "Great
Labs" facility. The facility was located in a rural area
several miles west of
main Burroughs facility at the intersection of Rts.30 & 252 in
Paoli. The GVL
facility consisted of a secure fenced compound with a main building
consisting of three large Quonset-type structures. At the time
that I worked
at this facility (1964-'69), what I remember seeing of the BUIC
located in Building 2. I was an engineering programmer, working on
development of the "George" system for Trans World Airlines
and we were
across the hall from the BUIC area (the Quonset's had a main hallway
from one end to the other down the middle of the building). We
started out on
the D825 computer but as development continued, our version was
"8500". I can remember the large BUIC consoles with the
large, round CRT
screen and the light pen control. Also remember watching non-spec
being played on the console during late night shift hours :o)
I don't have any
of my old documentation left from those days and can't think of anything
that might be of interest relating to the BUIC, BULLSEYE or
RADS military efforts.
I was in the Air Force from 1972
till Sept. 1976 and sometime in 1973 the BUIC III was put into moth
balls. I was a technician on the system working at Charleston AFS in Maine
on the BUIC III.. Lot's of blue neon lights that I with my punch card
program I turned into a 3 million dollar digital clock in the off hours.
A dual CPU computer but not a true dual CPU as it swapped the
running from one CPU to the other... back and forth only one active
at a time. I wish I had photo's but cameras were not allowed on base. I
remember the wind on top of the mountain. I remember the incredible view.
I was transferred to the SLBM DET6 14 MWS and stayed at CHAFS until I was
discharged in 1976. I went there once not too log ago the radomes
are gone the place is just weeds and old buildings behind a chained gate.
I remember the programming language called Jovial
"Jules Own Version of the International Assemble Language"
As I remember the BUIC III operated at 3 MHZ and
had thin film memory in the CPU and 64k by 48 bits in core octal in the
memory cabinets.. Many blue neon lights there!!
first term airman of the quarter det 6 14 mws
SGT Robert C. McClure when discharged
Automatic Message Processing System at the Pentagon was there at the
turn to the 1970 decade. The log entry read, “End of ‘decade’”,
instead of “shift”.
it was still a “dual, parallel, fail soft with graceful degradation,
and automatic recovery” system, there were software changes from the
was it didn’t swap master and slave functions automatically by time;
It swapped when either any backup system failure was detected, or either
CPU detected a failure of the other CPU to increment a real time clock
count in memory. The current CPU master could, of course, initiate a
“recovery cycle” of diagnostics for any detected error, peripheral,
or system element. If memory (mine) serves, it was a 99.996 % uptime
system. It failed about once every six months. Sometime(s) this was due
to both CPUs claiming fault in the other. Failure to auto-recover
resulted in many 132 column width pages of memory dump printing loudly
(printer solenoid hammers striking ribbon + paper against a rotating
metal mandrel), followed by a pathetically short last line spit print of
“help”, followed by “Pat” the Burroughs programmer eventually
arriving from PA to analyze the dump.
few hardware details are: 3 MHZ oscillator, thin film memory, 48 bit
word length, 64K “memory modules” – not pcbs, but ~6’ high X
~3’ wide cabinets. Bryant Drums, disks, tapes, Uptime (& an MDS)
printers, card readers, all in duplicate, except for the card punch.
push buttons for operators on the message consoles were an alphabet soup
of every “XIA”
agency, and departments, and some individuals near, or at the top of US
government you can imagine, who might need to get a message.
all I have time for right now.
BUIC: Many sites-When
used for North American Continental Defense, the sites
were at the periphery of the continental U.S. And, they were placed so
all sites had ~100% radar overlap coverage. This was done so that if any
individual radar site went down, the adjacent (about geographically left
right) sites' beams very nearly met. EC121's provided off-coast
radar to overcome clutter & low-level intrusions. Eventually, as
became scarce, many, if not all, intermediate sites were scavenged for
At monkey mountain, Vietnam, shrapnel pierced a sturdy steel cabinet.
cabinets' doors were designed with copper electrical grounding
which provided shielding against "tempest", or the
interception of any
radiated signals, even electronic noise detection.
When a D825 was dropped off a ship into "the drink", it was
Burroughs, and sold back to the US Gummint for spare parts.
The Msg consoles at the Pentagon (my civilian tour was 1969-1970), in
Joint Chiefs of Staff's Message Center of course didn't display radar
data. They displayed military "traffic", meaning transmitted
communications messages. They were displayed in "plain text"
consoles, meaning that they had been unencrypted, or decrypted, by a
corresponding KG26 encryption device. (You can try, but Google no longer
returned a valid result after years passed in between searches.)
Anecdotally, I knew them as "Krypto Gear" ##. And one had to
be vetted to
get the Top Secret clearance with "Crypto rider". I was asked
the question, "Can you people still diagnose and repair the
consoles if you
can't see them?" The (my) answer was "No". I didn't
explain further that
fixing bit failures, and erroneously displayed English alpha-numeric
characters while wearing a blindfold, would have required a "seeing
serviceman", and impractical-and hazardous-delay, if we had to feel
around the equipment. The foregoing question was in my opinion the
(every one at one time or another in) our group hanging around and
the screens over the operator's shoulders. Actually, and technically, we
no "need to know" a single displayed character of any of the
Some of it at the time was interesting and revealing, but I don't
"bit" of it now.after 42 years have passed.
(As previously submitted)-The D825 had a 3MHZ clock, or oscillator, for
system timing. The 8500 had a 15MHZ clock. Initially there were hardware
problems with this clock rate, and with the ICs' synchronization.
That's enough for now.
ago and far away (but still on planet earth) computers had evolved from
the original tube types.
SAGE , BUIC-I [-II, -III], Whirlwind computer, IBM 7090
"Stretch"-history and forebears, Ed Thelen, et al.
computer lore from before my time: The earliest North American Continental
defense systems, such as SAGE, sometimes required men with wheeled carts,
which held vacuum tubes, pushing them along the computer's aisles to
replace failed tubes. This happened routinely.
only tubes I was involved with were from commercial electronics products.
an original geek, but not quite the fictional Mr. Spock, my very first,
“darling computer”, which could neither make coffee, nor love (nor
kids, etc., etc.), was the Philco S-2000. I mention it, because
it’s architecture had advanced features at the time, such as a
double-length word of 48 bits. Functionally, this really was two, 24 bit
machines operating sequentially. Since memory was slow [ALL COMPUTER
MEMORY FETCHES NOT FROM LOCAL REGISTERS ARE SLOWER-due to bus access and
transfer times- RELATIVE TO CPU EXECUTION SPEEDS, ERGO A PC’S L1, L2,
etc,(Level/Local REGISTER memory caches for the execution Unit)] this
enabled a two-fold speedup in two ways. Doubling memory speed by accessing
two memory words at once, and doubling processor speed by executing two
instructions (~left and then right) before needing to “reload” the
Program Register. Also, UNLIKE IBM’s 7090, and Burroughs’s D825, it
was an ASYNCHRONOUS processor. The architectural engineer’s theoretical
argument went thus: It works near the speed of light, since the logic just
passes electronic signals, and never waits for the “clock” output
pulse of an oscillator. That sounds great, but real-world factors, such as
variations in the rise-and-fall time of early transistors required
accommodation by a gating pulse. This pulse was timed to arrive at the end
of the greatest time it took for any 2N404 transistor to change states,
from conducting (the “on” or binary 0 state) to non-conducting,
and vice-versa. This was the timing requirement for how a 48 bit (bits in
parallel) register word was transferred, or “built-up” by transistors
changing states in parallel.
where did the gating ~=(approx. equal to) settling time ~= transfer pulses
come from? They came from three, identical, main CPU, specialized type of
circuits, each called a “single shot”. When I later worked on the SDS
940, and Xerox Sigma 2/3/6/7/9 asynchronous CPU/I-O systems, the single
shots were replaced by “delay lines” with the same function.
the Synchronous computer designer (IBM, Burroughs D825,
et al, and all PCs) had some counter points, or counter claims: “The
asynchronous system needs and uses pulse timing, so the logic waits
for a pulse anyway; The clock pulses of a Synchronous system are so fast,
that they are everywhere, and the circuitry never needs to wait for
one.” Burroughs’ system designers, however ran into timing problems
with the later 8500, because the pcb’s different foil leads’ lengths
themselves acted as delay lines (and radiative effects) at higher clock
rates. Some circuit chips may have been more sensitive, also.
other “stuff” possible later, unless it’s too boring]
tie it together now: The D825
and the Philco S-2000 had something in common. They had very expensive
operating Control panels. Virtually every CPU register and all memory bits
each had an on-off light. Although the Philco S-2000’s was the size of a
church organ, it was not a system-wide, multi-element status indicator;
One had to figure out what/why there was a malfunction. The D825
had both a front panel with it’s own tri-lead, green, mini neon bulbs$,
and a separate, church organ sized bank of system-wide, multi-element
status indicators. It had red (failed), yellow (suspect with some
diagnostic requirement), and green (good), DUAL bulb-ed (in case one
burned out) indicators for each, and every system device, and processor!
When, rarely, there were many problems, and at Christmas time, when a
special deck of punch-cards was entered, the console was lit up with red,
yellow, and green lights. Via the cards, they were ALL blinking like a
Christmas tree. It was really just a bulb test program.
D825's original mission was as an air defense computer system, and SAGE
BUIC, like and after SAGE, was for U.S. continental defense. However, it
had a phenomenal (for the time) up-time rating, due to it's proprietary,
and highly specialized, HardWare-S/W
combination. Decades(?) later a company called Tandem specialized in high
up-time systems for commercial markets, banks, etc.
A precursor of the Philco S-2000 was an Octal Philco system,
lent/rented/sold-for-cheap to the Israelis for their air defense, and
six-day war. Though I was not involved in that in any way.
clarify, “Doubling memory speed by accessing two memory
words at once...” is not to be taken literally. The memory speed
wasn’t doubled. Accessing a 48 bit memory once to get two, 24 bit
instruction op codes-&-operands, meant that that
type of fetch for instruction op codes-&-operands took half the time,
by eliminating another, second fetch. AND, two memory words weren’t
fetched. Rather, it just equaled double the bit length. Raw data could
still be 48 bits long, and require two fetches for, say, an ADD for the
two "terms", also called the
1000 computers were used by the Israeli military.
Appendix B, columns 2 and 5 of the attached system description. Why? This
is the “rare” information that defines it (definition of the code
type) as an octal system.
a correction: The prior emailed text should be “...all Memory Address
Register bits...”, not “...all
memory bits...” Every memory bit was NOT displayed on the console!