Table of Contents
- Starting to Learn
- Time on Guam
- Indiana University
- Servio Logic
- Teaching at the College and High School
- The Job Hunt
I have been working with computers since the summer between my Junior and Senior Year in High School. I applied for and received a summer grant to go to a math and computer camp at Oregon State University. It was a very enjoyable summer, spending most of my time working on the Alwac IIIE in the basement of one of the buildings at OSU. It was fun working with a tube computer and helping take care of the tube farm in the back to burn in the tubes. At the time the tubes that failed usually failed within the first 24 hours of being used. We would burn them in for the 24 to 48 hours before plugging them into the computer.
The media the Alwac IIIE used for feeding programs into the computer were paper tapes. A paper tape is probably one of the most inefficient ways to input programs and data. The one advantage over Hollerith Cards was that if they were dropped, the tape would remain in the same order because it was only one long piece of paper tape with feed holes down the middle. An example of the hassle was when you found a mistake or wanted to add a command, you could either retype all the tape with the correction, or you could duplicate the tape to the point where you would like to add or correct a command or data, type in the corrections/additions, then skip over the mistake on the original tape, finally duplicate the rest of the original tape onto the new tape. Doesn’t that sound like fun!
Starting the Learning Process
The college, Willamette University, I attended did not even have a student accessible computer until my Senior year. Therefore, I took a computer class at the College of San Mateo between my Sophomore and Junior years. It was fun and I learned quite a bit. Of course, we used Hollerith Cards, but we were able to access the computer on our own (this was unlike most colleges through the mid 70s where a user had to turn the card deck into an operator and expect the card deck and results back in about 24 hours).
The system we used was an IBM 1400 series, I am not sure of the exact model number but am including a picture of the 1401 as the first of the series. This is where I started to learn FORTRAN, which would come in handy later in my career.
During my Senior year at Willamette University, we finally got a computer. I believe the model was one of the 1400 series also. I was a mathematics/physics major and so had a few physics projects to do. One of my first was taking the measurements for the height of the moon above the horizon at a varying time (as l=close to midnight as seemed reasonable) each night for a month. This was done with an interesting instrument that was a meter stick with a sliding cardboard piece that was about a foot long. We would slide the cardboard piece on the meter stick until the cardboard piece covered the distance between the horizon and the moon. We would then record the time and the distance of the cardboard piece from our eyes, using the meter stick. What I did was write my own personal program that would take the data and plot the position of the moon with respect to the horizon for midnight each night. The horizon was a straight line going across the page. For a 28-day cycle, the moon would be above the horizon about half the time.
Time on Guam
After one year teaching in Catholic Schools in Sacramento, California, I was offered a teaching position in Guam for two years (I extended that to four years). The first year I taught at Barrigada Junior High School and then switched to George Washington High School for the last three years. I was brought in to teach physics, but when David Gensimore found out that I could program computers I was asked to also teach computer classes. We had a fairly new IBM 1130 to use with a large platter array for storage of information. If you can read German, there is an excellent article about the 1130 at the Stuttgart Museum site.
Spent one year at Indiana to earn my Masters of Science in Computer Science (MSCS degree). I had been accepted to the DBA program, but decided to earn some more money before going back for a higher degree.
Being my first job after earning my Masters, I was put in charge of writing the codes to create a simulator for the Burroughs Scientific Processor (BSP) so that the programmers could write the code that would run on the system without having to have the system completed. The architecture of the system was fascinating. It’s boards were water cooled and the boards were called islands. The various chips on the board had pads instead of legs and were held in place by high tension springs. Unfortunately, one day one spring was not put in correctly and it popped out unexpectedly. Fortunately, the person working on the board only had his face grazed, but the spring stuck into the cinderblock wall behind him. Everyone was much more careful after that. The architecture was fascinating. It was designed to do simultaneous commands on large arrays of data. The system inherits much from the B5500, a high level language computer far ahead of its times. Like the B5500, the BSP was designed using the Algol language. It used Algol, one of the first structured languages instead of assembler. The BSP had 17 parallel memory banks in which large arrays could be placed. The seventeen parallel memory banks were chosen because most arrays do not come in multiples of 17. This allowed fast parallel fetches of the array to be manipulated from regular memory and placed in the parallel memory banks. I was also taking courses at the University of Pennsylvania to earn my PhD in Computer Science, but I did not finish the program and instead moved to Oregon.
I was recruited by one company to come out to Oregon by my Professor at the University of Pennsylvania. I turned them down at first because I wanted to stay in Pennsylvania for my PhD. I was told there was a program I could attend in Oregon, unfortunately the institute unraveled and curtailed offering PhDs once I arrived. On top of that, the company for which I went out to work lost a huge contract with General Electric and thus informed me that they had no needs for my services the day before I was supposed to start. Fortunately, I had five job offers within a week and went to work for Tektronix the following week.
Since I knew something about testing, they asked me to design the internal diagnostics for their 4112, 4113, and 4114 Graphic Terminals. Since this had not been done before at Tektronix, it sounded like a fun challenge. The first week I was there, a well-dressed gentleman came and sat at my desk and talked with me for about 15 minutes. He then introduced himself as Howard Vollum, one of the co-founders of Tektronix. He said that he did this with all of the new hires in a company of 25,000. I am impressed by someone who would do that for new hires, something that seems to be rarely seen in CEOs now.
The first schedule I created said it would take me two years to finish everything I wanted to do. Since they wanted the systems out within one year, I reduced the scope and decided what functionality I would implement for the first release and what would be phased released. I did put in extra hours on this project and the project took about 1.5 years to complete, I was able to implement all the tasks I wanted to have in the firmware. The only defect I had filed against my code for the first year of release was that they wanted to tests to be shortened to quicken the start-up time. The tests I had run were for me minimal and really did not take up that much time, but I was able to reduce the completeness of some tests and put those additional tasks in an optional group of tests that could be run to check out suspected problems. One of the features I built into the code was to check for additional ROMs and, if they checked-summed correctly, jump to a known location in the additional ROMs. The design was, since this was mainly for manufacturing tests, that when the code in the secondary ROMs completed that it would call the instruction at a know location in the master ROMs.
SmallTalk was the preferred language on the system. SmallTalk was developed by Xerox and then licensed to Tektronix. Tektronix did come up with several cool added features like a really great garbage-collector. I was asked to be the lead engineer in the Acquired Language Group and was able to take over the porting of the Emacs editor and help negotiate and oversee the porting of Common Lisp and Prolog to the 4404. SmallTalk was big enough at the time that Tektronix was able to host the first Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA) in Portland, Oregon. After Tektronix’ success with the 4404 and SmallTalk, Xerox organized ParcPlace Software and opened a branch in Portland, OR. They were able to lure away some of the Tektronix SmallTalk engineers. Since then, other languages like Ruby and Ruby-on-Rails have taken many of the ideas of SmallTalk and improved on then, thus causing the death of SmallTalk.
I could not find any articles about ParcPlace, except a 1995 article in the LA Times about it acquiring another company. As you can see in the embedded video, SmallTalk developers were able to produce a product five times faster than developers using C++, the second widely used Object-Oriented program at the time. C++ is still being widely used, but SmallTalk has been replaced by other languages.
The company was trying to develop a database based on SmallTalk, but they had some problems agreeing to a design. I was assigned several different tasks during the year I was there, but I was switched to a different project before I was able to finish the previous one. The one good thing is that they required us to buy a Personal Computer and they pay us back 1/14 of the purchase price per month. The system I bought was an IBM with no hard drive, two floppy drives, and a monochrome monitor. The price in 1984 was $5,500. Can you imagine what you could purchase for that price now? Tektronix needed to come in and write some internal diagnostics for a new Artificial Intelligence workstation that they were developing.
My time at Hewlett-Packard was divided into two sections. The first was working on the SoftBench Software Development Environment and the second was working on the HP-UX installation package Ignite-UX.
Toward the end of SoftBench, I was in charge of the Encapsulator and creating a C++ interface to the library. The library allowed tools to be easier integrated with the SoftBench environment. Stephen A. Williams created a good description of Using SoftBench to Integrate Heterogeneous Software Development Environments.
Ignite-UX is a tool to help install and update HP-UX. It can either be used from a boot disk or remotely. The interfaces are similar, but the boot disk only has minimal display capabilities, so the interface is strictly ASCII characters. The boot disk entry screen looks like: