Thanks, Ed Sharpe archivist for SMECC

Back-up Intercept Control (BUIC) Training and Installation Data

31 January 2010

Robert W. Nelson, CMSgt. USAF Ret. tells us:

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:

303X1  Radar Repair Technicians
304X1  Nav-Aids Repair Technicians
304X2  Ground Radio Repair technicians

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.

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 
of 1983.

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!!

Bob McClure
 Clinton, Ma.  

Former 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 can
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 own.
Anyway that explains the fact I only served two years.

I was stationed at Tyndall AFB. I remember not only did the CPU modules have
LEDs that lit for each bit in the command register, they also wired the MSB
(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 of
the more experienced repairmen could tell not only what test was running at
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 harmony
(each CPU played a different part) complete with light show (since the LEDs
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, they
could call us in the repair shop and we could "freeze the bit" for them,
taking their erroneous command off the line and intercepting it before it go
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".


Thanks,
George Paschetto

Long ago and far away (but still on planet earth) computers had evolved from the original tube types.

See: SAGE , BUIC-I [-II, -III], Whirlwind computer, IBM 7090 "Stretch"-history and forebears, Ed Thelen, et al.

http://www.radomes.org/museum/buic.html

http://www.smecc.org/burroughs_buic_-__an_gsa-51__sage_backup.htm

Defense 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.

The only tubes I was involved with were from commercial electronics products.

As 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.

So, 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.

Thus, 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.

[more other “stuff” possible later, unless it’s too boring]

I’ll 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.

The 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.

More? 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.

 -------------------------------------------------

To 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 "addends".

---------------------

Philco 1000 computers were used by the Israeli military.

See 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.

Also, 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!

Charles

EC-121H out of Otis on Cape Cod, we connected to a BUIC ground
 site on the outer Cape, between Chatham and Province Town

Thanks  for  sharing this  with us  James!   -   Ed#

Hi, I flew on the EC-121H out of Otis on Cape Cod, we connected to a BUIC ground site on the outer Cape, between Chatham and Province Town. I have some pics I collected over the years I flew as First Radar Tech doing repairs to the radar systems, in-flight.

James Hunter

Navigator and Radioman stations

Thanks, Ed Sharpe archivist for SMECC