IBM 701 Part 2

Nathan had a problem. The “Defense Calculator,” as the IBM 701 was initially known, was funded with a clear mission: build a stored program computer that could do partial differential equations.

As the Korean War began overseas, aircraft producers of the 1950s scrambled to produce new jets. IBM’s marketing team talked to companies all over the aerospace sector, and every one of them struggled with partial differential equations. Today, we’d call IBM’s situation a “killer app” opportunity.

Nathan sat in one of the 23 rooms in the Kenyon House recently purchased by IBM as a research laboratory. He knew his objective, but designing the architecture was going to be an undertaking. Luckily, he was just the fellow to do it.

Nathaniel Rochester earned a B.S. in electrical engineering from MIT. During World War II he worked at the famous “Rad Lab” and later built the arithmetic logic unit for the Whirlwind computer at Sylvania. To say he was well versed in all things digital would be an understatement.

His first project at IBM in 1948 was Test Assembly, an early tube-based stored-program computer. It used the Williams tube for memory, an electrostatic method rather than the popular mercury delay line. It was attached to the frame of an IBM 604, the big tube-based multipler++, a kind of calculator for punched cards. It read a card, multiplied two numbers, and punched the answer. The Test Assembly became a functioning stored-program computer with about 40 instructions.

Nathan also assisted in building the Tape Processing Machine at Endicott, IBM’s most well-known manufacturing facility. As Eckert and Mauchly made the UNIVAC for the Prudential Insurance Company, the talk around the industry was that tape would replace much of card processing. Large insurance companies had massive collections of punch cards to keep track of customers, claims, and premiums. If anyone was going to replace punch cards, IBM knew it had to be them.

IBM’s Tape Processing Machine operated with lighter reels than the UNIVAC by using iron oxide coated plastic instead of nickel chrome. This meant the tape transport could work much more efficiently and companies didn’t have to hire a Mr. Universe winner to change the reel.

Although it’s hard to imagine anything other than a binary machine, the Tape Processing Machine was decimal. By “binary,” I mean that the machine’s numbers operated in the computer as a long string of binary digits, or as Claud Shannon called them, bits. Add, for example, could carry from each binary digit to the next higher digit. 777777777777 plus 1 is 000000000000, for a 36-bit word machine.

These machines used values from 0 to 9 just like punch cards which employed ten horizontal rows. The bottom row was 9s, the next row up was 8s, and so forth. The cards also had two additional rows for alphabetic characters and punctuation. This was done using the “A row” and “B row,” the top two rows on the card, also known as “row 12” and “row 11” respectively. The top row was 12, the next was 11, and the one after that was 0. Confusing? You’re in good company. I have to look it up every time.

This disorganization was because punch cards originally had only numbers. When letters were added, they put the new 11th and 12th rows at the top of the card and defined the encoding in such a way that if you punched the top row, 1 through 9 would become A through I. If you punched the next row, “row B” aka “row 11,” then punches in 1 through 9 became J through R. Notice that I didn’t mention punches in row 0, the third row down. Punches there meant row 1 through 9 would be S through Z.

If your head is spinning now, wait until I explain how punctuation worked! I’ll spare you the tedium except to say it evolved to use more than two punches long before computers came on the scene.

The Tape Processing Machine set the IBM standard for encoding magnetic tape. Six bits was a natural encoding of value using six binary digits. A binary value of octal number 001 was a digit 1 used for both printing, punching, and doing arithmetic. The value of octal 011 was the digit 9.

The Endicott group’s Tape Processing Machine used these decimal digits as addresses for all the math. Adding 100 to 23 was done serially, from right to left, addressing each character individually. Doing math was slow but fast enough for the card image input and output devices. It could tackle limited problems such as employee X worked N number of hours at pay rate R, producing a result and moving on to the next record.

Even the faster iron oxide tape was slow enough that the serial nature of the decimal machine was quick enough.

Occasionally people mistakenly call the decimal machine a “digital machine.” Binary and decimal machines are both digital. They both use binary digits. A better moniker might be “Scientific” and “Commercial” machines.

None of this seemed like a good fit for solving partial differential equations. IBM needed multiplying and summing with a sequence of numbers. In other words, there was a lot of compute for a limited amount of input-output.

All this weighed on Nathan as he tried to figure the Defense Calculator’s architecture. That wasn’t all that was on his mind. There was also the time pressure.

The product was called the Defense Calculator because it was supposed to help the Korean war effort. It had to be development, prototyped, moved to engineering, and produced to support the dozen or so companies that were creating aircraft for the Defence Department. Every step of the processes had to be telescoped down into a short amount of space. Nathan was handed the task in January of 1951, and IBM needed to deliver the machine by the spring of 1952.

Nathan, in the end, decided against the company’s experience with the Test Assembly and Tape Processing Machine. He declared the machine binary rather than decimal.

All of the other twenty odd machines under development in university and industrial laboratories were all binary machines. The binary form allowed equations to be solved faster because hardware was parallel, not sequential. It would also be easier to debug and keep working.

Deciding on a binary machine removed one problem only to uncover another: the width of binary numbers. Word sizes varied from machine to machine. Today, we think about 32 and 64 bit, but back then many machines used 40-bit words. The EDSAC at Princeton’s Institute of Advanced Studies, for example, used 40-bit words, each holding two 20 bit instructions, or “orders” as they were known at the time.

Nathan knew that the Tape Processing Machine had a way to keep the card images on tape using binary encoding. They were using 7-track tapes, six bits per card column with one bit of parity. Dropping the word size down to 36 bits kept the size of a base ten number to ten digits, the required precision for the problems the customers needed. It was also a perfect fit for the work already done on the tape systems. Six characters fit into a single word.

This moment in history had interesting consequences. The six characters were enough to use symbols for assembly programming, something that Nathan would later invent. When John Backus and his team at IBM worked on one of the very first programming languages, FORTRAN, he inherited that limit. That is why FORTRAN was restricted to six characters.

Another important consequence of Nathan’s 36-bit choice was that only the first 72 columns of punch cards were used in programming languages like FORTRAN and assembly. You could put twenty-four computer words on a single card. The first 36 punch position of the bottom row (row 9) was the first word, the next 36 positions of that row were the second word. The third word was the 36 positions above the first, and so on. In that way, one could fit a lot more on the card in binary than in decimal. As a side effect, you could only read the first 72 columns of the 80 column card.

Once he decided to go with binary, Nathan wrote one of the first computer architecture documents. It was given to everyone on the project, and without it, the system would not have been a success. The programmers, engineers, and technicians, all understood in great detail what the machine was supposed to do.

IBM put Jerrier Haddad in charge of actually building the thing and ensuring that manufacturing could produce it. He took the specifications and divided the work into a half dozen teams. At the top level, the effort was split between the machine’s parts. Besides the central processing unit, there was the cabinet with the electrostatic memory, card punch, card reader, printer, three frames with power controllers, and the all-important tape transport.

The logic of the various machines was worked out using a growing number of circuit models. Each module had room for about eight vacuum tubes and did different functions, various kind of flip-flops, basic AND and OR logic, encoders, decoders, muxes, and demuxes.

The engineers took the specifications of these modules and designed their higher level logic while the actual modules were prototyped. In this way, every aspect of the machine could progress. It was all in motion, all at the same time.

By December, three shifts worked on the machine on a 24-hour schedule. In March 1952, the developers reported to IBM’s board in a room with large windows covered with blinds. After everyone was informed about the machine, the blinds were pulled open.

Ice-cube-tray fluorescent lights illuminated a modern, battleship gray computer room. Head-high boxes filled the room, all thirty inches deep so they could fit through the standard doors of any customer’s offices. It was all stylishly modern for 1952 and the first machine room behind glass with operators scurrying around operating the machine.

The price tag was higher than the initial $8,000 estimate. The machine would cost $12,000 a month--$100,000 today. Of the original 18 customers, 19 put in an official order (what would become the NSA took one as well).

The IBM 704, and later the 709 and 7090, all were built with Nathan’s architecture. He went on to do research and was an early developer of artificial intelligence.

On the 8th of June, 2001, in the quiet little village of Newport, Vermont, Nathaniel Rochester passed away at the age of 82. Many unsung creative talents paved the way to the technology we enjoy today. Nathan was one such talent.