|We are actively seeking
information related to any of the topics presented on this page...
please email email@example.com if you can
be of assistance!
Thanks, Ed Sharpe archivist for SMECC
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.
In the BUIC pictured here: From Left to right: 1. Burroughs Civilian
Tech Rep, name unk 2. CMSgt Hecker 3. SSgt Scoullar 4. A1C Palmoren 5. unk
6. TSgt Nelson 7. Unk It has been 49 years, can not remember the other
names. Our team installed the BUIC II at L.G. Hanscom Field Mass. in June
1965 and the one at Finland, MN in Aug 1965.
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
George Paschetto says:
First, thanks for collecting this information and making it available. I
finally show my daughters what kind of computer I used to repair.
I served as an Airman between 1973 and 1975. I was in the guaranteed job
program which meant I could choose my MOS. I chose computer systems
repairman but in 74-75 the Borroughs BUIC system I was trained to work on
was phased out and replaced. As a result I was offered an honorable
discharge, since I lost the job I was guaranteed through no fault of my
Anyway that explains the fact I only served two years.
I was stationed at Tyndall AFB. I remember not only did the CPU modules
LEDs that lit for each bit in the command register, they also wired the
(or was it it LSB?) on the command register to a speaker, so that the
frequency with which that bit changed would create a sound. We got used to
the sounds created by the various tests that were run at night, and some
the more experienced repairmen could tell not only what test was running
the time (memory test, I/O test, CPU test, etc.) but they could also tell
when something went wrong.
Someone had written a program with the sole purpose of making music using
that speaker. As I recall we had Christmas carols played in two-part
(each CPU played a different part) complete with light show (since the
blinked in interesting patterns in time with the music). I only regret no
pictures were taken.
Another memory is of a joke played on some of the operators. The operators
were officers, and the new guys were told that, if they made a mistake,
could call us in the repair shop and we could "freeze the bit"
taking their erroneous command off the line and intercepting it before it
to the computer. I don't recall if they were ever told it was a gag, or if
they were simply told "we missed it - call faster next time".
As you can read in the book "The System Builders, the story of SDC"
by Claude Baum, I was one of the thousands of eager trainees in the
8-weeks' crash course in computer programming beginning June 23, 1959. I
was 7th in the class of 20 according to reports and was relieved to know
that "I was not that stupid, after all!" since I was indeed
worried about finishing the course.
Joe Slotnic tells us "We
finally found the picture I had wanted to send to you,
regarding the story of my interview with SDC and obtaining
employment with them. The date was probably April, 1966,
as the article speaks about me being MC at a luncheon at
the A. G.Bell Convention in Kansas City in 1966. I was a
young 31 years old at that time!"
There was an ad in the Boston Sunday Globe newspaper
that my first wife noticed (!) and asked me what I thought
It was by System Development Corporation and the ad was
looking for computer programmer trainees who could satisfy 5
criteria for employment... I do not remember all 5 criteria
but one of them was "US Citizenship required," and
another was "a suitable mathematical background."
I knew I could satisfy all of them so I took the ad with me
to work the next day, Monday. The ad said that interviews
would be lined up just for two days, Monday and Tuesday. Use
of the telephone (via TTYs and later use of relay services)
was not available for deaf people at that time, that was why
I took the ad with me to work on Monday. (I was working for
Raytheon Manufacturing Corp, and had been working for them
three years. I had started out as a layout draftsman,
pledging with them that I wished to go to night school and
take courses in mechanical engineering. The guy who
recruited me apparently had other ideas for me and hoped I
would become part of an "operations research"
group he was planning to start at Raytheon. To make a long
story short, things did not work out and I ended up being
just a clerical person doing essentially payroll type work.
I had my degree in Physical Sciences that I got from Harvard
in June 1955 and had graduated with nary an idea of what the
heck I wanted to do with my life!) I had our secretary (she
certainly was a great gal and a very cute one too) call the
recruiter for me. She worked hard on him, telling him that I
was a very personable and capable person and that he should
at least give me a chance to come in person and talk with
him. He finally consented to see me at 8am the next morning,
I was living in Methuen, MA, some 35 miles north of Boston,
where the recruiter was holding interviews in the (now
defunct) Statler Hotel. I got there, parked my car and was at
the recruiter's door at just before 8am. He answered the door,
looked at me puzzled and (I think) gasped when I told him I
had an appointment with him. Yes I did come, and here I am! He
said apologetically that he would like to step out for a cup
of coffee and a donut, and while he was doing that would I be
kind enough to work on 4 very short tests for him? I said
sure, and I did all 4 of them easily enough - they were
performance and aptitude type tests. When he came back, he
took the tests from me, gave me an employment application form
to fill out and we sat down to do them. I was about half-way
through with filling out the application form when he seized
it from me, exclaiming to me "you did all of the aptitude
tests and passed them easily! Apparently you have the basics
of what we are looking for! Can you tell me why you are
looking for this job?"
I smiled at him and said, well to tell the truth I thoroughly
hated the "work" that I was doing at Raytheon, and
proceeded to tell him a bit about it. Now I thought nothing of
it all at that time, but I did marvel later and especially now
about the fact that he and I were speaking to one another with
very little difficulty, communications wise. I am deaf in both
ears, and yes I do read lips to understand other people.
Different people move their lips differently and truth be told,
lip reading can be quite useless at times. My speech is fairly
understandable (many folks who are deaf in both ears do not
speak very well) but I do have problems with some hearing people
who are not used to my "deaf" voice. He did ask
questions about my hearing impairment and decided that it was
not a factor for me in pursuing a computer programmer training
career with SDC...
Remembering the pointers I had read about job interviews etc., I
tried to stand up and take my leave once or twice, but each time
he brushed me aside and continued with our conversations on the
job with SDC. The last time, when I sat down, he started outlining
the (very generous) benefits package that would come with a job
with SDC! I knew then that they really and truly wanted someone
like me! What I had hoped for, some 15 minutes or so of his time,
turned out to be a more than 2-hour interview! He had a list of
"books on computer programming" on a piece of paper that
he thought I should read for a primer of what the whole thing
entailed. There being no Xerox machines available I simply wrote
them down on a piece of paper for myself and feel very lucky that
at that time there were precious few books on the subject.
(Imagine the situation nowadays, with millions of books on the
subject available and a college computer background required too,
for someone aspiring to be a computer programmer or analyst!)
Before we parted he advised me to "discuss the move with your
wife, as it is a big move," (going from MA to California!) and
to read up on the subject some more. If and when I had made up my
mind, I could call... (he was going to say call collect, but
remembered that I could not use the telephone!) no, write a letter
to him and check with him. We parted very amiably and I drove home
to have lunch with my wife. I remember telling her: "I would be
a fool to turn down any offer from them, as it seems to be an
interesting field and a thing for the future!"
I went to work that afternoon, but spent most of the time then and the
next day or so at the library at Raytheon reading those computer books
and coming to the realization that writing computer programs would be
akin to "programming" the Friden calculator (noisy and all)
that I had on my desk at Raytheon, but the machine would be vastly
bigger and more capable! After one week I wrote the letter to SDC and
mailed it. The next Sunday there appeared again in the Boston Sunday
Globe another advertisement from SDC, same thing except that a
different recruiter's name was there. I had the secretary at work call
this guy, and he asked me who I had had my interview with (I no longer
remember his name) and said he was going to talk with him that
evening. I thanked him, worked the rest of the day and went home.
Waiting for me at home was a Western Union telegram telling me that
SDC wished to make me an offer for employment, and to call them
collect at my convenience to discuss the matter!
Next day I collared a fellow employee and asked him to make the call for
me? He did this and we had a 45-minute talk with the personnel
department at SDC, which culminated in their offering me a job!
My admiration for the SDC people and working with them was very high
indeed. I remember one quiz where I had the wrong answer for a
question, so I took it up with the instructor. He showed me why I was
wrong, but I asked him to wait, fetched the notebook from the guy I
was taking notes from and pointed out where I got my information. It
turned out that this guy doing the notes was in error himself, but he
had the right answer on his test paper! This gave the instructor a
glimpse into some of my problems - getting the wrong information by
accident and through no fault of my own! They did me a great favor in
assigning me to the Research & Development Dept with programming
work on the "new" IBM 709 computer! Most of the others in
the class were assigned to further work in SAGE. The reason for this,
they said, was that if I had been assigned to advanced SAGE
development with all its needs for instant communications etc I might
not have liked it very much, but doing work either by myself or with a
few others in the 709 environment would be more beneficial for me.
I left SDC 21 years later with quite different feelings. The company
had changed and so had the people within it. It was time for me to
leave, any way. But I had a great 21 years experience with the
Joe Slotnick, SDC Employee #4081.
Added note - And yes I was first deaf programmer at SDC but not first
deaf employee. A deaf girl in Personnel Dept contacted me when she saw
my picture etc in that SDC publication and had been there up to one year
before I joined the company. She was contemplating taking the
programming course and become a programmer. Don't know if she did that
nor do I remember her name!
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!
|We are actively seeking
information related to any of the topics presented on this page...
please email firstname.lastname@example.org if you can
be of assistance!
Thanks, Ed Sharpe archivist for SMECC