One significant thing happened during my high school education. I took a typing class! This put me in a room with 30 girls, no doubt preparing themselves to be secretaries. Some boys would have considered such an arrangement to be a grand opportunity, but it was neither here nor there for me. But I learned to touch type, and this has been a valuable skill through my computing career.
There were two computers at that time on the University of Arizona campus. One was a Univac in the math department that nobody I know ever had access to. The other was a CDC Cyber 6400 that served the entire campus. These were days of keypunches and batch processing. You would prepare your deck at a keypunch, then submit it over a counter to a "priesthood" of people who served the computer. A notice was taped to the wall next to the counter estimating the "turnaround time". You would come back and check the return shelves after about that amount of time and find your card deck on top of a print out generated by your job. Typical turnaround times were at least 30 minutes.
Unique skills were used on keypunch machines. The most advanced users would set up a "drum card" which configured the machine, but most users never did. Cards could be duplicated on the machine, then held with your thumb while you added content to the new card. Dropping a card deck was a significant catastrophe.
After my first FORTRAN class (SIE-78), I talked my way into a senior level class (SIE-272) that taught assembly language programming (COMPASS) for the CDC 6400. After than I took one other class (SIE-170) which was a class in numerical methods (mathematical algorithms) and that comprised the 7 units of computer related education I acquired during my undergraduate journey.
The only language besides FORTRAN and COMPASS assembley that I ever heard about on the CDC 6400 was COBOL. I took one look at COBOL and avoided it like the plague.
I was still primarily using FORTRAN, specifically FORTRAN-IV which was the new thing at the time. The main aspect of FORTRAN-IV was that it allowed the use of logical operators like .LT. for "less than", whereas earlier fortran only provided the 3 branch arithmetic if. At some point I ran some timing tests that seemed to indicate that code written with the old 3 branch if ran faster, so I sacrificed readability and wrote some big pieces of code using the old construct. This required more statement numbers and made the miserable task of trying to keep statement numbers in order even more miserable.
The timesharing machines allowed you to save files on disk! This was almost unheard of on the CDC 6400! It also involved you with some kind of text editor. I used an editor called "SOS". The competitor at the time was an editor called "TECO", which I never learned or used. Both of these were line editors. Screen editors were still yet to come. It was said that TECO commands resemble line noise.
The only was to save programs was to use a tape drive. The CDC had big tape drives that I never used. The DEC offered little "DEC-tape" which would have been affordable to a starving student.
One of my favorite jobs was to read magnetic tapes provided by clients. They would bring us their data on big reels of 9 or 7 track tape, written by some other computer. I loved the puzzle of figuring out how to read their data. We had one or two Tektronix 4006 or 4010 graphics terminals. These could draw lines on a storage tube display, but once written the only way to get rid of them was to clear the entire display. We also had a big Calcomp plotter to produce the maps that the mining companies expected. At some point I rewrote the Calcomp software and set up a system with an intermediate graphics file that could be either sent to the plotter or displayed on one of the Tektronix terminals. Being able to "preview" plots on the screen before commiting them to paper saved time and money. The entire package was called PPLOT for "Polygon Plot".
Computing Associates partnered with another company and together they purchased a DEC-20. This was very much like the DEC-10 I had used at the University. For the first time ever, I had unlimited computing resources available to me. With the CDC machines, every job had accounting information and you paid for every second of computing time you used. I remember one time when another of the programmers at computing associates had a job going that had run for several hours (rates were on the order of $1000 per hour, I don't really remember). He and the boss were trying to decide whether all was well and they should just let it continue or whether it was in a loop and should be terminated. This event led to adding the ability to perform big computations in sections, checking each for correctness before submitting a job for the next section. Having the DEC-20 "in house" got away from much of this and led to much faster software development cycles.
This was the first time I heard about the C language. I was told that DEC was using C to write systems software. I was disgusted. My way of thinking at the time was that all systems software ought to be done is assembly. It was only in later years that I realized that speed was not the only metric worth paying attention to. We hired a fellow who incessantly told us about "structured programming". The problem was that he was never able to actually produce anything and he was fired after not too much time. He was right of course, but couldn't produce anything to add weight to his opinions.
After a couple of exciting years, I quit my job at Computing Associates and went back to the University of Arizona to work on an MS degree in Geology. I finished this and went to work at the Lunar and Planetary Lab at the University of Arizona. The department had an Interdata 8/32 which was my first experience with what might be called a minicomputer. It had 2 washing machine sized disk drives, two tape drives (one 7 track and the other 9 track), and had terminals all through the building connected to it. It had 1 megabyte of memory and probably was a 1 MIPS machine. Rumor has it that the instruction set was much like the IBM 370.
It ran a wretched vendor supplied operating system called OS-32. One thing I remember was that the terminal driver did not support "type ahead". If the computer was not ready and you typed anything, it was simply lost! Compiling anything took a long time. I would set up a compile script to "beep" when the compile finished, and then lean back and read a book until the compile finished!
One day, my boss brought me a tape with a label "software tools". It was software from the book "Software Tools" by Kernighan and Plauger. Little did he know the trouble he was starting!
The book introduced structured programming and "ratfor". What "ratfor" was, was a preprocessor that made FORTRAN look as much like C as possible. In particular it did away with statement numbers, replacing them with block structure (via curly braces) and syntax like every modern language. As soon as I had ratfor running, I said goodbye to FORTRAN forever!
The book introduced an idea that was revolutionary for me, namely that speed was not all important. It is more important to write software that is clear, easy to maintain and modify that to be fast. Before this, I was all about using any trick to make things faster, feeling clever for writing assembly language when possible.
Another big idea in the book "Software Tools" was that there is nothing special or mysterious about "system software". Programs are programs. It is amazing what a new mindset and world view can do. I began running a screen editor that was part of "software tools". I proudly showed it to the other programmer I was working with, and he quickly moved to outlaw it, saying that such a thing was an inappropriate use of computer resources.
I was a threat to this fellow, and anything I did to improve the computing environment was met with strong opposition. One day I found a tape in a drawer labeled "Unix edition 7 for the Interdata 8/32". I asked why in the world we were not running this rather than OS-32 and you would have thought I had insulted his mother.
This fellow moved on and the day came when we were able to purchase a bigger pair of SMD disk drives to replace our washing machine drives. The two washing machines (with removable packs) were 80M each and these new rack mount SMD were 300M each. The problem was getting OS-32 to support them was an impasse. I made a suggestion. If we ran unix, we have all the source code and anything is possible. So we began running unix in the morning until noon, then swapping packs and running OS-32 the rest of the day. I was on a crash course learning C, unix, and disk drivers, but my gamble worked out and we were up and running with unix on the new 300M drives.
One thing that was missed was an optimizing fortran compiler that ran on OS-32 (Perkin Elmer provided two compilers -- the vanilla compiler than compiled fast and produced satisfactory code, and an optimizing compiler that ran more slowly but produced significantly faster code. I found that traps used for system calls by unix were entirely different from those used by OS-32. This made it possible to run the old compiler executable under unix and then intercept the traps intended for OS-32 and emulate those calls. Once I wrote the emulator layer, we were able to run the old optimizing compiler under unix without having source code for it.
Initially there was some resentment towards the change to unix. Scientists just want to get their work done and any change is an unwanted interruption. Some years later I was talking to one of those scientists, who told me that he didn't realize it at the time, but switching to unix on the 8/32 set him up perfectly for using Sun workstations which later replaced the interdata -- and he thanked me for it.
The lesson of course is software. Fast or cheap hardware with mediocre software will always be a miserable thing. The old saying is that a computer without software is simply an expensive space heater.
Along with Sun workstations came the network. There may have been UUCP before that and dial up modems and such, but I had little to do with them. Fast ethernet (10 Mbit) made diskless workstations possible, it not wonderful and Sun had the clever slogan "the network is the computer".
Suns were 68000 machines until the SPARC came along. I remember our first SPARC at Steward Observatory, a machine named "hercules". I copied a program to the machine and type the "cc" command to compile it and immediately the prompt came back at me. I was certain something had gone wrong. Nothing had gone wrong. The SPARC machines were that much faster than the 68000. It used to be an overnight process to rebuild a kernel back in those days on a 68000 based Sun.
I also had some kind of DOS/Windows PC in my office. I needed it to support microcontrollers, burn EPROMS and such. The tools and compilers to support hardware and microcontrollers would never be available for linux or sun machines. There was never any love lost between me and the world of microsoft software. It was always a huge pain to set up networking, whereas it "just worked" with linux or BSD. But I didn't spend time using DOS in any way. As long as it booted up and then would run my applications without too much trouble, I was happy.
I began working with some kind of real time operating system. Probably PDOS from Motorola. It had some awful editor that I needed to learn and came with a buggy C compiler. I worked with several such real time operating systems before we settled on VxWorks. The beauty of VxWorks was cross development. The compilers, editors, and linkers were hosted on the Sun machines and were both familiar and first class. Sun workstations had nice disk drives, big displays with window systems, fast network and all of that. I gave thought to porting a decent editor to PDOS, but VxWorks came along and saved me from that chore. The genius of VxWorks is not trying to create a full computing enviroment (and doing a poor job of it), but leveraging the work of others and focusing on a real time kernel.
The VME era marked a turn in my career. I left "number crunching" behind and focused my attention on using computer for control. From this point on my software was controlling motors or some other actuator and reading various sensors. I wrote software used at the University of Arizona mirror lab and at various telescopes.
My office at the observatory was alongside the electronics shop. I would see people every day building things, wiring things, fixing things. It was only natural that I would pay attention and begin learning electronics myself. The book "The Art of Electronics" was invaluable and my copy of the first edition is worn out and falling apart. Once I had learned some electronics, it was only natural to begin building some things and working with microcontrollers.
I used the 8751 for a lot of small projects that needed an embedded processor. You had the choice of using a device with a window and a UV erasble memory or using an 8031 with an outboard ROM. The latter choice allowed you to use a ROM emulator, which is a box with a serial port on one side and a cable to plug into a rom socket on the other. I did plenty of projects using both, and the ROM emulator is the cadillac was to work. Once everything is running and debugged, you burn a EPROM, put the screws in the box, and move on.
What was happening was that computers were becoming more affordable. In addition, my disposable income was growing. Sun workstations began to appear as "surplus" and I spent some time running SunOS (their form of BSD unix) on them at home, and they displaced the miniframe (but were not as much fun - I never did get down to writing bare metal software on them). A lesson I quickly learned was that finding computers on the surplus market indicates that the world has definitely moved on. It became clear that if a person wanted to run some kind of unix at home, running linux on a commodity PC was the best way to do that.
An important lesson for a person who enjoys programming is that you do not have to work with the latest or even fast hardware to enjoy yourself. I find that I have the most fun staying close to the hardware, writing device drivers and operating systems code. There is no question that I could have great fun dragging out one of my old Sun3 boards are bringing up some new operating system on it. Getting unix edition 7 from the Interdata era running on a sun3 could be a fun project.
I considered the exam, but unlike regular students who had taken all the classes within the past year, I had taken them over 5 years or more and a lot of material was no longer fresh in my mind. So I opted for the thesis. Some time later I asked an advisor, "so what happens if a person does not pass the masters exam?" She said, "I don't know, nobody has ever not passed!"
As a thesis project I decided to write a real time operating system. I was inspired by VxWorks, particulary the concept of cross development and using a linux system for development. My thesis was that with threads, semaphores, and a scheduler with a real time policy, I was done. The project was a huge amount of work, both the programming required and writing the thesis itself. I used an otherwise idle and discarded "pentium" based PC and got my Kyu operating system running on the x86 architecture (it was then called "Skidoo"). So I finished a second MS degree and have another feather to wear in my hat.
Around 2010, I retired from the Observatory. I began experimenting with small ARM based boards that were capable of running linux. I selected the Beaglebone Black (BBB) which has an ARM core running at 1 Ghz along with 512M of ram and a decent network. I avoided the wildly popular Raspberry Pi because the BBB has more IO pins and much better documentation (a 4000 page tech manual from Texas Instruments). At some point I began wondering how hard it would be to port my thesis project from the x86 to the ARM. I did some experiments to check some things and then dove in. It was much less work that writing the original code (which is one definition of portability). After work on the BBB, I ported Kyu to several other ARM based boards. At some point I realized that I could spend every waking moment working on a project like this and stopped making it a major focus in order to give attention to other activities of interest.
Tom's Computer Info / tom@mmto.org