I used to believe that good computer programmers are born, not made. There's still a very good chance that's true, but programming in the 1960s often meant keypunching your program on 80 column cards, submitting them to the computer center's batch queue, and getting the results (often a compilation error) hours later. The only people who put up with that hassle really wanted to teach that machine a new trick.
My first exposure to computer programming was on the Bailey Meter 756 process control computer that my father designed. He said it was so easy to program, a 12 year old could do it. I was 12, and he taught me how to program the I/O processor. Later I found in the town's library a new "TutorText™", Basic Computer Programming that used the familiar decimal address and decimal opcodes just like the 756. Not Dartmouth Basic, but machine code for a fictional computer. Not assembler, all numbers.
Later, Bailey got a Packard Bell 250. Where the 756 used a drum for storage, the 250 used a magnetorestrictive delay line. Dad showed me the programming manual for it, and while it had instructions I could recognize, e.g. ADD (add), MUP (multiply), and SQR (square root), it had weird stuff like normalize (NOR) and "move line X to line 7" (MLX). That, and my total confusion about how alphabetic instructions could work on a computer that dealt with numbers ended my early hands on programming experience.
All that changed when I got to CMU. "Computer Programming and Problem Solving I" was Algol, and I quickly learned that compilers did all the work to create the binary numbers that the Univac 1108 actually worked with. Even the old 026 keypunch in my dorm was fascinating - I could punch a card and copy it forever with no loss of data! I couldn't do that with audio tape, photography, or paint brush. Within a couple of weeks the computer had kidnapped me and my Chemistry major was doomed.
The Computer Center was in Scaife Hall. The 3rd floor was where users, clerks, key punches, etc. were. The 4th floor was where the computers were. Sometimes I could get a glimpse of them from the elevator, I must have gotten a tour at some point, but I snuck up there occasionally, and got thrown out a few times. One day I saw Dave Rodgers talking with the operator of the 1108, apparently about some problem. He moved to a panel of blinkenlights and pressed one. They all stopped. Other buttons would change their light, some would change a whole row, and finally another press had them all blinking again.
Dave turned back to the operator and said "That should fix it."
I was amazed, and must have looked uncomprehendingly confused, wondering if I could ever learn a fraction of what I just saw, but I sure wanted to try.
Here are the operator console and Power and Maintenance panel:
At the start of my sophomore year, I applied for a parttime job as a computer operator, either for the 1108 or the bigger IBM 360/67 which I started using in the second semester. Unfortunately, all that was open was a spot on the Computer Science Dept's new DEC PDP-10. It was a lame system - no disks, just five small tape drives that are best compared to floppy disks with really slow access times. One had the operating system and programs people used. A user really needed two DECtapes, one to read a file and one for the output.
It was a timesharing system, which made it more productive than the card based batch systems. It didn't have some of the bells and whistles of TSS/360 on the IBM machine, but those were really distractions from getting real work done. I was surprised I could be productive on it, especially at night when we switched the system tape to the one for the transplants from Stanford. That one included a SAIL compiler, an Algol-like language. For the first time of many I realized I was lucky to wind up on the -10.
No one had experience with the system, so people asked us operators questions we couldn't answer either. I generally dug up the answer, as it would often be helpful to me too. It was also a natural setting to learn more about the operating system, the -10's assembler, the hardware, and basically everything. Along the way I took on more responsibilities, subjects for other days.
Eventually, the system got some drum storage, physically big, low capacity, but fast. People had to delete all their files when they were done for the day, but finally more than two people could use the system at once.
The system crashed from time to time, a reboot would fix things - unless there was damage to the simple file system on the drum. Curiosity led me to writing a program to look at blocks on the drum (or DECtape). I had no clear idea how to code something to interpret a command like "read 5" to read block 5, but the debugger, DDT (the manual said Dynamic Debugging Technique, not Dichlorodiphenyltrichloroethane), could do things like convert assembler instructions into machine code and execute them. The -10 also had a block of instructions called UUOs - Unimplemented User Operations that were meant to be like a system call that was handled by the program itself. Some aspects of executing an instruction would complete before the UUO handler started.
So instead of struggling with some command processor, I created UUOs and could execute instructions like "R buf, block" where buf was in a register field, so I could have 16 different buffers, and block was in the 18 bit effective address field. "W" would write a block, "DUMP buf," would print an octal/ASCII dump on the line printer, "RD" would read and dump, etc. I could write little loops to RD sequential blocks. Basically, it was one of the most useful programs I've ever written.
One evening a couple of people came to report that after the last crash there was a file that caused some sort of error whenever they accessed it. They couldn't even delete it.
"Let me take a look," and ran DSKRD. When it started it immediately entered the debugger. That's a bit odd, normally people ran DDT and told it the program to look at. Most people used DDT to look at data, which they could recognize or set breakpoints in disassembled code. I was doing things like "R 2,100$X" to execute an instruction, one they had never seen before, then rummaging through a buffer at BLK2 looking for things like directory data to find the block that referred to the file in question.
I forget what was wrong with it, but I said "I can delete it here," and patched the buffer to make the file look deleted, and wrote it back out with an equally odd "W" instruction.
I turned around and as I said "That should take care of it," I realized that they must have looked exactly as I did a couple years before when I saw Dave Rogers doing things I could not comprehend.
I was a wizard.
I recently got DSKRD scanned. All in all, it's not very informative, but pretty decent code given it was one of my early projects. It could even be used standalone, I forgot I added that support.
When I wrote it I hadn't figured out that I should name the general purpose registers I used. At the time, DEC had names the used in their code, but those were revamped in a major new release, It appears I converted some of the code to that sensible scheme, but not all. Heck, I hadn't even figured out the most sensible subroutine calling interface was through a stack. I used three of the four subroutine schemes the -10 implemented. I wasn't alone in that confusion!
I also hadn't figured out that comments before a subroutine are important. Byond that, it's pretty decent code.
After I graduated, I worked fulltime for the CompSci department on the -10. My main task was to continue development of our ARPAnet support that origi nally came from Harvard. I worked with Ed Taft there on things like telnet and FTP. My apologies for what Email became.
The steel mills were still running in Pittsburgh and eventually that and other interests led to my first greater than one day bicycle ride 2,700 miles from Palo Alto to Billings Montana, via Canada. I called it a job site hunting trip and got to see ARPAnet sites like Xerox PARC where Ed had gone to. I got wind of an opening at Intel on their PDP-10. While it was pretty low level, the interviewers liked me enough to try to turn it into a better fit. I called them from the road a few times and when I got back to Pittsburgh I called them again only to hear that they had just learned a hiring freeze started three weeks before. That was my introduction to the severe 1974 recession.
A few hours later, Dave Rogers called. He had left CMU a while before to join DEC and told me they had an overloaded inhouse timesharing system that really needed me. A couple weeks later I moved to New England and haven't left since. I didn't spend too much time on that task, but the OS developers appreciated having me there and I was a big help.
I joined Dave on a project on a project to make a small PDP-10, but that was canceled in favor of the new "Virtual Address Extension" project that became DEC's 32 bit VAX system. Some readers have heard of that. I decided that I wasn't ready to be part of an Operating System project from scratch and transferred to the PDP-10 development group. Dave managed the VAX project which wound up changing the company. Had I stayed, things would have worked out okay, but my career would have been very different! Maybe better, maybe not.
I have never learned how to identify someone who is born to be a computer programmer, but an important aspect may be that I can think like a computer. A lot of that goes back to that very early experience with machine code, especially the TutorText which used a very simple computer design that helped visualize how data flows through the system between memory, computation, and logic.
In many ways, programming (when did it get renamed coding?) is much easier today. Immediate feedback make people far more productive, high level languages handle the low level details that occupied much of the time spent writing assembler code, even on the -10, the most wonderful system ever for programming in assembler. On the other hand, people don't know how computers work inside, and that may be important.
I mentioned drum and delay line storage. It will never happen, but if I were to write a book on computer history, it would be titled Tanks for the Memories. While processor speed and features have greatly increased over the decades, those first systems I used at CMU used core memory, a great improvement over all of the predecessors. It was an array of ferrite beads strong on wires that could change and measure magnetic changes. It was hard to automate, and manufacturing often used seamstresses who exchanged making one of a kind clothing for the more lucrative core fabric. At its best, it cost only a dollar a byte. Silicon based electronic memory showed up in 1974 at CMU. My first memory purchase was for 16 KB of TRS-80 memory for a mere $75 in 1980. Today a typical memory for a PC has a million times more memory and costs less.
I'd love to know how much core memory was manufactured, I'm sure it's less than one board of today's memory.
Similarly, the PDP-10 drums used for storage had a 1.6 MB capacity. My first hard disk from Corvus cost $3,000 for 10 MB. Today I can buy a 1 TB NVME solid state disk for $60
We used to be able to compare the advances with automobile technology with computers. There's just no point today. Even years ago the comparison would be to a new car that travels at Mach 15, seats a thousand passengers, gets 30,000 mpg, and folds up to fit in your shirt pocket.
Contact Ric Werme or return to his home page.
Written 2023 Mar 26, last updated 2023 Mar 27.