Burroughs BUIC - AN/GSA-51 SAGE Backup
Home ] Up ]

 

We are actively seeking information  related to any of the topics presented on this page... please email info@smecc.org if you can be of assistance!

Thanks, Ed Sharpe archivist for SMECC

 

 

SAGE BUIC

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.

FROM:
BURROUGHS CORPORATION
Detroit, Michigan 48232
Phone: 875-2260, Ext. 2234
or contact:
Richard J. Brady
Defense, Space and Special Systems Group
Paoli, Pennsylvania
Phone: NIagara 4-6962

_______________________________________________

FACT SHEET

AN/GSA-51 Radar Course Directing Group for the Back Up Interceptor Control System (BUIC)

FUNCTIONAL 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:

  • Air Surveillance

    • Acceptance of radar data from long range radars.
    • Formation of tracks based on radar input presentation of this data for evaluation by operators.
    • Provision of capability for manual track information and automatic maintenance of tracks.

  • Weapon Control
    • Display of available weapons to permit pairing with tracks and manual commitment.
    • Automatic analysis of commitment to assure intercept ability.
    • Automatic transmission of pre-launch and fire command based on operator input.
    • Automatic generation and transmission of guidance commands.

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

BUIC accepts 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.

A computer, 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.

Display data 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 defense sectors.

Peripheral 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 proficiency.

Since the 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 controller-comparator.

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


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.

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


 

The BUIC project development was located at the Burroughs "Great Valley
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 complex
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 equipment was
located in Building 2.  I was an engineering programmer, working on the
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 running
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 renamed the
"8500".  I can remember the large BUIC consoles with the large, round CRT
screen and the light pen control.  Also remember watching non-spec "games"
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 else
that might be of interest relating to the BUIC, BULLSEYE or RADS military efforts.
 
E. MacDonald
K.C., MO

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

 

 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 about it?

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, on Tuesday.

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!

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

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!

 

 

 

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

 

Although it was still a “dual, parallel, fail soft with graceful degradation, and automatic recovery” system, there were software changes from the BUIC mission.

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

 

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

 

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

 

That’s 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 that
all sites had ~100% radar overlap coverage. This was done so that if any
individual radar site went down, the adjacent (about geographically left and
right) sites' beams very nearly met. EC121's provided off-coast "look-down"
radar to overcome clutter & low-level intrusions. Eventually, as parts
became scarce, many, if not all, intermediate sites were scavenged for
parts.



At monkey mountain, Vietnam, shrapnel pierced a sturdy steel cabinet. The
cabinets' doors were designed with copper electrical grounding "fingers",
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 salvaged by
Burroughs, and sold back to the US Gummint for spare parts.



The Msg consoles at the Pentagon (my civilian tour was 1969-1970), in the
Joint Chiefs of Staff's Message Center of course didn't display radar target
data. They displayed military "traffic", meaning transmitted and received
communications messages. They were displayed in "plain text" on the
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 (baited with?)
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 eye
serviceman", and impractical-and hazardous-delay, if we had to feel our way
around the equipment. The foregoing question was in my opinion the result of
(every one at one time or another in) our group hanging around and reading
the screens over the operator's shoulders. Actually, and technically, we had
no "need to know" a single displayed character of any of the "live traffic".
Some of it at the time was interesting and revealing, but I don't remember a
"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.

Charles

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

 
 
 
 
 
We are actively seeking information  related to any of the topics presented on this page... please email info@smecc.org if you can be of assistance!

Thanks, Ed Sharpe archivist for SMECC

 

 

 

 
 

Everyday we rescue items you see on these pages!
What do you have hiding in a closet or garage?
What could you add to the museum displays or the library?

PLEASE CONTACT US!

===================

DONATE! Click the Button Below!


Thank you very much!

===================

Material © SMECC 2007 or by other owners 

Contact Information for
Southwest Museum of Engineering,
Communications and Computation 
&
www.smecc.org

Talk to us!
Let us know what needs preserving!


Telephone 
623-435-1522 

Postal address 
smecc.org - Admin. 
Coury House / SMECC 
5802 W. Palmaire Ave 
Glendale, AZ 85301 

Electronic mail 
General Information: info@smecc.org