Paper Tape: A Programmer’s Nightmare


4 July 2006





Probably every computer programmer has a story to tell about his or her worse programming job and although I have had several nasty ones, the one involving paper tape has to have been my worst.


Graduating with a degree in Electrical Engineer (EE), over my career as an engineer, I never practiced EE. Instead from the get go, I designed computer hardware, then computer software and finally both the computer hardware and software involved in complex machine-to-machine interfaces.


My paper tape job was for the Naval Research Laboratory (NRL) as at that time I worked for a company, which hired its employees out to various government defense agencies. Although the details of the job are fuzzy now, I remember this about the job: used a Rolm ruggized Data General Corporation minicomputer with 8 or 16 kilobytes (can’t remember which but think it was 8) of memory, had a teletype user interface hooked to a paper tape punch machine, had a paper tape reader attached to the Rolm computer and also had an industrial strength analog tape recorder, which was to be controlled by the Rolm.


The whole point of the project was to take the Rolm on board an aircraft and to record various sounds onto the magnetic tape reels for later playback and analysis. This of course required that the Rolm, via a Teletype user interface, be able to start, stop, rewind, tag recorded records, erase records, etc.


At the time, hard disks were expensive and bulky and although the Rolm might have come with one and an operating system, the one I had did not. Thus, all code had to be written in assembly language, which is the native code of the machine and involves loading registers and manipulating them via shifting bits for multiple and divide, sending out specific code to the tape machine interface, etc.


Not a hard job really. Just control the tape recorder. Problem was that with limited memory, it was very tough to get all the functions required into the space allowed, even when written in assembly language. And then there was the paper tape. To develop my programming, I would sit at a Teletype machine and enter my lines of code and have the attached punched tape machine punch out a tape I could then read into the Rolm for actual program execution. Of course, as I typed on the Teletype, it would create a fan-fold hard copy of my code. If upon execution in the Rolm, my latest code worked, I would set aside that punched tape and associated fan-fold print out and begin on another section of code. The next time I was ready to test more code, I would read all older code via paper tape into the Rolm and then enter and test new code, again creating a punched tape if that piece of code was correct or after I debugged it.


3 months. 3 months of paper tape punching and reading. Of course, the tape punch and reader, both, broke several times and I ran out of tape more than once.


If there had been more memory in the Rolm, the job would not have taken so long or been so difficult but as I began to build up a library of various tape machine controller or user interface functions, I began to run out of memory consistently. Thus, I had to go back and reexamine all my existing code to determine if I could break it into smaller, reusable or shared pieces of code that did not have to be repeated in memory for some other function to work properly.


Of course subroutines or shared pieces of code carry an overhead with them as you have defined inputs and outputs and so I was always balancing whether a subroutine with its overhead was better or worse than just repeating code in more than one function.


3 months. As I was doing the work at NRL, I rarely returned to my employer’s office and thus my immediate company boss would come to visit when he was on base trying to stir up more business for our company.


I think at about 2 months, my government bosses began to worry about my progress as I had not gone to them to say the project was complete or even shown then any of my progress. Anyway, one day, my boss came by and although a nice, understanding guy began to question were I was with the project. “Pieces, I have lots of pieces complete,” I responded and “believe it or not, it is all going to come together at one time.” Just to show him I had, in fact been working hard, which he did not doubt, I showed him how I could set the tape machine to recording, rewind the tape, advance it to a specific record, search for specific recorded information, etc. He went away happy although I later learned that I was supposed to have been done with the project in 2 months and I was already into my 3rd month and had little to show the government bosses.


Take larger pieces of code and break into smaller modules, parts of which could be reused by other functions. Repeatedly I had to do this to get all required functions to fit into the Room memory available, all the while, piling up miles and miles of paper tape, mostly wasted.


Of course, more than once, the paper tape of some function or set of functions dropped on the floor and I had to carefully gather it up again in its strange fan-fold configuration. Not as bad as dropping a punched card deck, but almost.


Finally, close to the end of the 3rd month, all coding was finished and I informed both my government boss and company boss. Demonstration day. For once, on demonstration day, the system worked without a hitch and the government bosses did not even have any changes to make, desired or required. As I had told my company boss, it would all come together at one time and it did.


I never actually flew with the system when it was taken out in Navy planes to collect data. In fact, I never worked on the system again, but the company I worked for did.


Almost 5 years after I completed the paper tape job, several engineers in my company came to me at a picnic and although I did not know them, they knew of me as they had worked on or were working on my old code, updating it for a newer, larger airborne system and they all were amazed at the coding job done as not only was it efficient in space but also was so well commented that they could actual understand the processing and maintain it. Interesting that one commented that when they started their update, after searching and searching, they could only find where I had wasted one byte in each user interface message or a total of 30 bytes in the whole system.


10 years after I completed the paper tape project, believe it or not, the code I had created was still flying and being used. 10 years on any software is forever and ever and although I lost a lot of hair over that stupid paper tape punch and reader, I am proud of what I accomplished there and I also understand what programmers had to face when building the first space probes with limited on-board memory.


Now, I have a personal computer with 2 Gigabytes of memory in it and programs can be as large as 500 Megabytes. For sure, many more functions than I had to implement but 500 Megabytes for one program? Wonder if the program would be 500 Megabytes if they had had to use paper tape?


For more Ron Stultz writings, click here.