Pasadena City College
This program was written in a programming language called FORTRAN (Formula Translator). Dave loaned me a book on FORTRAN and I began to study it. Soon he told me that there was a night class being taught on the subject at Pasadena City College.
We both joined the class and began using the machine time it entitled us to both to do class exercises (which quickly became too easy to be challenging) and our own projects. Since I had always been interested in music, one of my earliest programs was designed to compare musical pitch between “true” and “tempered” tunings.
Here is a partial listing of that FORTRAN program:
And here is part of the output:
I remember thinking how tedious and detailed programming was. For example, in order to print a character string such as “The True and Tempered Scale”, one had to count the number of characters in the string. I thought I would never want to work a profession where one spent all one’s time counting characters. But, as I began to learn my first programming language, I discovered that I had a real knack for it, and that I really enjoyed it. So my prediction that I would never want to work in the profession turned out to be wrong. (Fortunately, in modern languages you don’t have to count the characters in a character string.)
The teacher for that class was a man named Marvin Rubenstein. Like us, he loved computers and programming and we would often stand in the parking lot of the computer lab until the early hours of the morning talking about computers.
The computer lab for Pasadena City College was not on campus. Rather it was a couple of blocks away in a large garage, probably originally intended to be a space for an auto-repair shop. In August they would open the garage door to unload the year’s supply of punched cards and computer paper. The lab would then overheat from the August weather, a “thermal” light would light up on the computer, and they would have to shut the computer down until they were done unloading supplies.
Our classes were taught in the same room as the computer, whose fans were so noisy that it had to be shut down during class lectures so that the teacher could be heard. Then before we could work on our lab exercises, the computer had to be powered up, which took as much as half an hour, because the memory for that machine had to be heated to a specified temperature in order to function.
Looking back, the 1620 was a strange machine. Virtually all computers use binary or base two, arithmetic. But the 1620 used decimal (base 10) arithmetic. Memory addresses were in decimal, address arithmetic was in decimal, etc. Since decimal arithmetic is rather foreign to digital electronics, all this arithmetic was not directly done by hardware adders. Rather, there were addition and multiplication tables kept at specified locations in memory.
Each memory location contained six bits: four data bits, which was more than enough to encode the 10 decimal digits, plus a check bit to protect against memory errors, and a so-called “flag” bit. Alphabetic data required two memory locations per character. Data, whether numeric or alphabetic, was variable length, so the flag bit marked the end of a data field. Since four data bits can encode 16 values, and there are only 10 digits, two of the other values were used for special markers called “record mark” and “group mark”. There were TF (transmit field) and TR (transmit record) instructions for moving data within memory. These instructions moved a variable amount of data until a flag or record mark respectively was found. It was possible to mis-specify such an instruction such that the source and destination fields overlapped in a way that no delimiter would ever be found. Such an instruction would run forever, clearing all of memory in the process. We actually used this on purpose by typing the following instruction into the console typewriter:
31 00002 00003
31 was the op-code for transmit record. This would clear memory to zeros, as a way of getting rid of any left over garbage from the previous program. Since this instruction would never end, we had to hit the “Reset” button to stop it.
The 1620 at Pasadena City College contained 20K of memory. That seems miniscule by today’s standards, but programs were simpler then.
I did write a message encryption program that required memory three times the size of the message: one for the plain text copy, one for the cipher text, and a workspace. I couldn’t get this to work because there wasn’t enough memory. (I now know more about cryptography and recognize my algorithm for that program as being a “simple substitution cipher”—a type easily broken with primitive cryptanalysis methods.)
After we learned FORTRAN, Mr. Rubenstein began teaching us machine language and assembly language.
Over the following summer, Mr. Rubenstein, invited me to work on a project (without pay, and largely as a learning exercise) for his company, Omnimetrics. My job was to come up with a software package that would do floating-point arithmetic in software. Some 1620s had floating-point hardware, but some didn’t. My job was to write the software that would emulate this floating-point hardware. (Floating point arithmetic deals with fractional numbers as well as very large and very small quantities using a variant of scientific notation, e.g. 6.02 x 1023 .)
The 1620 also came with a disk drive, a washing-machine-sized device that held about 1 megabyte of data. In those days this was such a large number, that the “mega” prefix was never used.
IBM supplied free software to run the 1620. This included a “Monitor” system which was a kind of primitive operating system, plus a FORTRAN compiler and an assembler called SPS.
In one of our midnight conversations with our teacher, I remember him telling us that he had been to a presentation given by IBM where they described their about-to-be-released new set of computers, collectively known as System/360. Prior to the 360, every model of computer had its own unique machine language. This meant that if you wanted to move from a smaller system to a larger, faster one, you had to completely rewrite your software in the new language. One of the prime features of the 360 was that every machine in the series had the same machine language and thus one could move programs from one model to another without change.
More interesting to us was that the new set of computers would have a new kind of software called “Operating System” or OS/360. My teacher explained that only the operating system could do certain “privileged” operations such as allocating memory or accessing input/output devices. This seemed outrageous to me. As a programmer, I was used to having complete control of the computer hardware. Now the operating system was going to block me from having such total control. This was necessary, my teacher explained, because under OS, more than one program could run at a time, and it was part of the OS’s job to keep one program from accidentally or maliciously interfering with the other programs that were running at the same time.