Return to univac-ntds.html#Other-information

the following series of articles appeared in
Volunteer Information Exchange
issues 2-13, 2-14, 2-15, 3-01
published by Jim Strickland < JLStrick @ aol . com >
a volunteer at the Computer History Museum

NTDS Computer Notes

by Robert Clinton < rhclinton @ tranquility . net >

Table of contents

The NTDS Computer – Part 1 Vol 2 Num 13, Sept 15, 2013
Robert Clinton
Conversation with Robert Clinton
Lowell Klaisner

In my first conversation with Robert Clinton in R|EVOLUTION, he told me that we had missed a significant computer in computer history, the C­642. I was not familiar with the designation so heard him out. As he talked I realized he was talking about the computer in the NTDS or one like it, so I took him there.

What ensued was a fun conversation about the computer and his experiences on the USS King. In the end, I asked him if he would be willing to write a few paragraphs about his experiences for our Volunteer Information Exchange. The result was the three articles that appear here and subsequent issues.

The Museum’s Revolution exhibition celebrates “2,000 years of computing.” My own part in that history is much more brief but my recent visit did coincide with the 50th anniversary of my first contact with digital computers. I had been aware (from consulting your online catalog) that your collection contained an example of my first computer and in anticipation of my visit I sent an email enquiring if it was on display. I was disappointed to receive a reply telling me it was in “deep storage” and unavailable to view. So it was a great thrill for me to learn on arrival that it was indeed on display. I believe that the confusion arose from a variety of nomenclature associated with the machine.

The computer in question is labelled in your display as the NTDS Computer. This is quite accurate but the machine on display needs to be put in context.

NTDS stands for Naval Tactical Data System. This was the first shipboard system utilizing general purpose (as well as a lot of special purpose) digital technology. The Navy had used analog computers for years, primarily in gunfire control systems, but NTDS was the first system to use “1 and 0” technology. Although it was capable of performing a variety of functions, its primary use was controlling fighter aircraft in air combat. The first three ships to receive NTDS were the missile frigates USS King (DLG10) and USS Mahan (DLG11) and the aircraft carrier USS Oriskany (CVA34). Collectively they were known as the Service Test Ships. Some have observed that the hull numbers of King and Mahan could be interpreted as binary numbers. I suspect that this was merely coincidence and not the reason that these ships were selected to be the first recipients of NTDS.

The term NTDS was properly used to describe the entire shipboard installation, which was composed of three major subsystems. These subsystems, and their components, were each given designations within the Army/Navy (AN/) nomenclature structure. The subsystems were:

These three subsystems were further broken down into component items of equipment, each with a subsidiary nomenclature in the AN structure. Although it is not inaccurate to call the computer in your display “the NTDS computer”, it is more properly a CP642/USQ20. Each of the other components of the USQ20 subsystem had its own designation, e.g., the magnetic tape unit was the RD243/USQ20. The CP642 was sometimes known as “the NTDS Unit Computer”.

The software which ran on the CP642 was known as “the operational program” and it was primarily the tactical data system. There was no operating system as we understand the term today, though there was an embedded package of rudimentary functions that permitted inspecting memory and making changes. The original elements of the operational program were written in assembly language but for later versions Univac provided a higher level language known as CS1.

Programming was performed at two Fleet Computer Programming Centers, the first, located at the Naval Electronics Laboratory at Point Loma, San Diego and the second on the east coast, somewhere in Virginia , as I recall. Shipboard technicians were not expected to do any programming, but of course we did. Since we were not provided with an assembler nor with any reasonable means of input, we did all our programming in absolute machine code, punched into the maintenance panel one octal character at a time.

The operational program was available in two levels of capability which were designated in accordance with the Navy’s specification of levels of shipboard readiness. Condition 1 indicated maximum readiness (i.e., “battle stations”) and Condition 4 was routine peacetime sailing. Thus the Condition 1 level of the operational program was designed for operation with both (or all three, in the case of Oriskany) CPUs interconnected while the Condition 4 level provided a reduced set of capabilities running on only one machine. Running Condition 4 provided the ship with continued NTDS functions in the event of failure of one CPU or if routine maintenance was to be performed.

NTDS first went to sea in 1961 aboard the Service Test ships. These three ships engaged in extensive testing of NTDS off the coast of California and made two deployments to the far east. But in March 1965 they were sent to the Gulf of Tonkin as part of Operation Rolling Thunder, the bombing of North Vietnam. I contend that this was the first use of general purpose digital computers in combat operations. Of course, Colossus was used in wartime code breaking, but it was not in an actual combat zone (although some will maintain that all of Britain was a combat zone). The Air Force personnel who operated SAGE might reply that they were in the thick of the Cold War but, fortunately for the fate of mankind, the world never became an actual combat zone. But although the King, Mahan and Oriskany were not subject to hostile attack, there is no doubt that we were in a combat zone: we were given combat pay and were awarded the Vietnam Service Medal

There are two books that provide more details on the development and deployment of NTDS. I believe neither is currently in print but used copies are sometimes available:

David L. Boslaugh, When Computers Went to Sea: The Digitizaion of the United States Navy, IEEE Computer Society, 1999

David E Lundstrom, A Few Good Men from Univac, MIT Press, 1987

Throughout the museum the displays celebrate the accomplishments of the scientists and engineers who conceived and designed the devices of the computer age, and this is at it should be, for without this genius we would have no computers. But I would suggest that some recognition be given to the next lower echelon of expertise that from the start has been responsible for keeping the equipment operating and for assisting users and programmers in making productive use of it. These people have been known by a variety of titles: Field Service Engineer, Systems Engineer, Data Systems Technician, etc.

The initial set of NTDS technicians received their training at the Univac, Hughes and Collins factories but in mid1962 a Navy school was established at Mare Island Naval Shipyard in Vallejo, CA. I was in the first class to convene at this school and received 48 weeks of instruction before graduating to the USS King. After two and a half years on the King I returned to Mare Island as an instructor, primarily teaching the CP642. I taught the inner workings of the computer and its peripherals to aspiring technicians for three years and in Part 2 I will try to recall some of the things I remember about this equipment.

Richard Clinton's article will be continued in future editions of the VIE.

The NTDS Computer – Part 2 Vol 2 Num 14, Sept 30, 20
Robert Clinton

As I mentioned in Part 1, I taught the internals of the CP642 (“NTDS Computer”) for three years, and here is what I remember about it. These memories are at least 43 years old so they may not be entirely accurate – any corrections will be appreciated.

As improvements were introduced into NTDS the modified units were given a suffix to designate the new model. For example, there were CP642A and CP642B versions of the CPU. I believe that the example on display in the Museum is a factory prototype. Although it is in most respects the same as the machine I worked on aboard the USS King, there is a significant of difference: the shipboard model had the lights, buttons and switches of the maintenance panel inside the doors (see photo).

This has triggered a distant memory: in 1964 I spent two weeks at the Naval Electronics Lab at Point Loma and I now recall that a CP642 was controlled from a more conventional control panel, mounted in a desk. The machine may even have been the one in the Museum’s display.

During my visit in August I was asked about the connectors on the front of each chassis. These were not connectors in the usual sense of having mating male connectors; they were actually sets of test points. The CP642 (and indeed all of the USQ20 devices) were lavishly supplied with test points – the output of each logic gate in the machine could be observed by inserting an oscilloscope probe into the associated test point. With a ‘scope and the large book of logic diagrams (known as a “surfboard”) troubleshooting the machine was very straightforward, though its reliability made this a relatively infrequent activity.

The immediate forerunner of the USQ20 was a machine designated USQ17. It was in many respects similar to the “Q20” but had a different I/O protocol and was not suitable for shipboard installation, though it did receive extensive use ashore in the development of NTDS. I believe that CP642 (no suffix) model only saw sea duty on the service test ships. Subsequent installations were of the CP642A. This machine was logically identical to the CP642 but had the maintenance panel mounted above the cabinet, obviating opening the doors to perform tests. The CP642B did have some changes to architecture, including a scratchpad memory.

The label on the Museum’s display accurately describes the computer’s salient characteristics: 9 microsecond add and 32K of 30 bit words. By today’s standards, pathetically underpowered but in 1962 it was “state of the art”, though that phrase was not as overworked in those days as it is now. The machine did have some characteristics that were well ahead of its time:

There was no online mass storage included in the system. The magnetic tape unit was used only for initial loading of the operational program and for writing diagnostic dumps. All code and data therefore had to reside in the core memory of the computers. A wired memory (literally, jumper wires) was available to bootstrap the computer from magnetic tape, paper tape or another computer.

As can be seen in the example on display in the Museum, the chassis were actually large trays of connectors into which logic cards were plugged. The cards were about the size of a credit card and each contained a number of NOR gates (up to four, depending on the number of inputs) or one or two bistable elements. The cards were potted in epoxy and were designed to be thrown away if they failed. There were about 49 different types of cards and they were used in the Univac peripheral devices as well as in the CPU. The basic logic element was the NOR circuit. Since this circuit combined both the NOT and OR function, it could be combined to produce any more complex logic function. Two NOR circuits were combined to produce a bistable (“flipflop”) element.

The adder circuit merits mention. It was variously described as a “1’s complement subtractive adder” or a “2’s complement additive adder”, but whatever you called it, it was a complex bit of logic circuitry which permitted its blistering 9 microsecond add speed. It used the concept of group carries to achieve its performance. Consequently it was the most difficult part of the machine to explain and understand.

Connections to the logic and memory chassis were through racks of connectors on either side of the chassis (not easily seen when observed from the front). When it was necessary to withdraw a chassis from the cabinet a socket wrench was used to disconnect the racks of connectors from the chassis. It was therefore not possible to operate the computer with a chassis withdrawn, which explains the need to have the test points available on the front of the chassis. The five memory chassis were identical and could be freely interchanged (as they sometimes were for diagnostic purposes) but each logic chassis had to be in its specified position.

At the right edge of each chassis there is a toggle switch labelled “Margins.” This allowed running a chassis during maintenance testing with either an increased or decreased DC supply voltage. A test which failed when running margins (usually the low ones) indicated a potential failure which merited further investigation.

The CPUs and the Univac peripherals required a 400 Hz mains supply in order to reduce the size of the DC supplies. This current was provided by either of two motor generators which ran from the ship’s 60 Hz supply. The CPUs and the larger peripherals were cooled by chilled water. Occasionally this supply was interrupted by an air block and within about 15 seconds the internal temperature would skyrocket and the system would crash. Sometimes this caused a failure of one or more logic cards.

Although the computers were installed in air conditioned interior spaces, the Navy did specify that they have “watertight integrity”, which explains the heavy doors with gear teeth. In normal operation these doors were kept closed and “dogged down” but they had to be opened when maintenance was necessary. There were braces to keep them open but opening and closing them when the ship was taking 40 degree rolls required considerable care. More than one Data Systems Technician – myself included – suffered “computer thumb”, but this injury did not earn us a Purple Heart, even when we were in a combat zone.

Programming under Fire Vol 2 Num 15, Oct 15, 2013
Robert Clinton

I wonder how many times I heard that expression during my 30+ years in commercial IT. And each time I had to smile because I had really done it – or nearly so.

Most of the time during the USS King’s 1965 Tonkin Gulf deployment life was pretty routine – “portandstarboard” watches (four hours on, four hours off), tracking outbound and inboard sorties and plenty of boredom. But a few times we went to General Quarters in anticipation of action. On one such occasion the tension was quite high; there had been intelligence warning of a possible MIG attack. The GQ alarm was sounded, condition 1 was set throughout the ship and in the computer room we did a fresh load of the operational program. So everything was in readiness, or so I thought. One feature of the operational program was for it to sequence the display consoles so that the symbol to be updated was at a point just behind the radar sweep. Thus the radarmen were always working with freshlypainted video. What constituted “just behind” was a function of a parameter somewhere in the Op program which defined a sector of about 30 degrees. The radarmen had used this to good effect for several years but at this moment of high tension, the Operations Officer came into the computer room and requested that this sector be narrowed, to around 15 degrees.

Now, at this time in the history of NTDS, the philosophy was that all programming was done at the Fleet Computer Programming Centers (the one on the West Coast was at Point Loma). The only times we saw programmers – officers and civilians – was when the ship was about to call at a desirable liberty port such as Hong Kong. All the rest of the time the Op Program was expected to run without modification and there were no official programmers aboard. We enlisted Data Systems Technicians were trusted to maintain the hardware but the subtleties of programming were thought to be beyond our intellectual grasp. The reality was that aboard ship we did a lot of digging into how it worked, using the listings stowed on board for the itinerant programmers.

I had never looked at the relevant area of the program before but after a few minutes with the listings I managed to locate the parameter. And after a few more minutes of octal arithmetic I had worked out the revised parameter. But how to put it into operation? Stopping the Op Program was out of the question under the battle stations circumstances. However the designers of NTDS had thoughtfully provided a device called the Systems Maintenance Panel or SMP. Among other functions it provided the ability to do an inspectandchange of a running operational program. You could look at and change a halfword at a time. And where was this useful device located? In the Combat Information Center of course, which was darkened and crowded just at the moment. Undeterred by these obstacles I went up to CIC with my modified parameter and a gray Navy flashlight. With great trepidation I started entering the change. It was only one word of data but I was unsure what would happen if I changed the first halfword before the second one. Would the system crash? I held my breath – and it worked!. The hook started hugging the radar sweep more closely and I had my 15 minutes of fame.

The MIGs never came and we soon went back to our normal steaming condition. And I took away one of my life’s most valuable experiences. No matter how tense things got in the civilian pursuits of banking, retail, government, etc. nothing could match the tension of – almost – programming under fire.

NTDS on the USS King Vol 3 Num 1, Jan 5, 2013
Robert Clinton

I was rummaging through my files today and came across this composite set of photos taken on the USS King in September 1965.

One of the two CP­ 642 computers with the doors open, showing the maintenance panels. To the right is the other one with the doors closed.
Both of the CP­ 642s, buttoned up.
At left, the magnetic tape unit. It could read and write tapes at two densities ­"high" density was 256 bpi. Keeping the mag tape units cleaned and aligned was one of the main maintenance efforts. To the right of the MTU is the paper tape reader/punch. Patches to the operational program were received on paper tape and sometimes diagnostic information was punched out on paper tape. The cabinet at the right of the photo is the symbol generator for the AN/SYA­1 display system.
This is the keyset central, which was essentially a multiplexer which interfaced the key entry devices to the computers. Since there were only four keysets, this looks like a considerable overkill and indeed the keyset central could have handled a much larger number of keysets. The lower left bay held analog­digital converters which provided the NTDS system with data on course, speed, pitch and roll. To the extreme right is visible the model 28 teletype which was the only keyboard device included in the shipboard installation.
The desk in the computer room, looking uncharacteristically tidy. One of the grey Navy flashlights hanging above the desk is probably the one I used in my "programming under fire" exercise.
A view of the NTDS workshop. The rack of coffee mugs is an essential feature of any Navy workshop. On the bulkhead in the center you can see an outline of the King. This is a sampler worked by my late wife's fair hand, bearing the inscription "God Bless our Happy Ship". Since she was not religious, there was probably a bit of irony intended. But the King was a relatively happy ship and the NTDS maintenance gang was a great bunch of guys.

Robert Clinton, a recent museum visitor wrote a three part article on his experiences on the USS King where he supported the NTDS system that is now on display at the CHM.