This is the third of a series of posts on the formative events in my life. Search for “formative events” to see all of them.
If you could somehow peer back at my interests and activities in the 1960s and early 1970s, you’d quickly conclude that I was headed for some kind of a career in electronics, and in particular, radio electronics. While I still dabble in electronics, I haven’t done anything with radio electronics for over 30 years. My career is all about programming, with a distinctly minor element (especially for the past 25 years) of digital electronics. What the heck happened?
In 1971, I had an advanced amateur radio license and an FCC first class license. I was building radio transmitters and receivers of my own design; primitive but they worked. I knew quite a bit about analog and radio electronics, especially with vacuum tubes as the active element. I had read a bit about digital logic — AND gates, inverters, flip-flops, and so forth — and had even puzzled out how they worked, though I never connected the dots about how you could do something useful with them. But I never seen an electronic calculator, much less a computer. I had zero interest in computers as a hobby, as the notion that I could ever own one myself had never entered my head (this was long before the days of personal computers!).
Then I joined the U.S. Navy, in a special six-year enlistment program they had. This program guaranteed that I’d get two years of training in electronics before I spent four more years serving; the only condition was that I had to pass the classes. The recruiter, true to form (he lied), told me that I’d be able to choose the field I’d be assigned to — and the Navy had some very interesting radio communications programs. I was very attracted to a rate called CTM, which was basically an electronics technician for the spook’s (spies) gear — and everyone knew that the spooks had the latest, hottest gear.
I went to boot camp for 18 long and shocking weeks in Orlando, Florida. Boot camp was not nice, but there was one (and only one, trust me) element of boot camp at which I excelled: taking aptitude and achievement tests. At that time, everyone in boot camp took a battery of standard tests. Guys who did well on certain tests were given more tests, at a higher level. There was even a third round possible, depending on the results of the second. I did well on basically all the tests (all that reading and studying was paying off), even on tests for areas that I thought I had negative aptitude, such as foreign languages. But the tests that got me the most excited were the tests involving electronics, math, and physics: I got 99th percentile scores on all of them, and I’d been told that this meant I would be able to choose whatever rate I wanted. I wanted CTM, and I was certain I would get it.
Wrong again, burrito-breath.
The way we found out what rate we were assigned to is by the orders we got upon leaving boot camp. Because my enlistment program guaranteed two years of school, I knew my orders would be to a school — but I didn’t know which one. When they handed out the orders, and I read mine, I could scarce believe my eyes: I was being sent first to “BEEP” school (basic electronics) in San Diego, then to “DS” school. I had never even heard of the DS rate, so my very disappointed imagination went into overdrive trying to figure out what the hell it was. My company commander was not a help: he was certain it was some kind of dental technician, though he couldn’t figure out why they’d send me to BEEP school first for that. I didn’t find out the truth for a couple of agonizing days, but finally I knew: DS was “Data Systems Technician", an electronics technician specializing in repairing digital equipment, including computers.
Oh, I was so bitterly disappointed! I was even moved to do something very unusual for me at that time in my life (I was still extremely introverted): I complained. Loudly. Eventually I got an appointment to see an actual officer; I’ve forgotten his exact role, but it had something to do with “detailing” — the Navy’s name for the process of assigning sailors to roles. He let me vent my whole story: my high test scores, my recruiter’s promises, my choice of CTM, my unhappiness with the DS assignment. Then he said, basically: “Tough toenails, sailor. Buck up and get with the program; you’re going to be a DS.” Of course he used a slightly cruder set of verbal constructs involving creative arrangements of both common and exotic four-letter words, but that was the general notion. He also added something that gave me pause: that the washout rate from DS school was very high, amongst the highest of all Navy schools — and that I really ought to consider what a prestigous and plum assignment DS school was. He allowed as how he was very surprised at my negative reaction, because a DS assignment as about as good as it gets for an enlisted guy in the Navy.
After my post-bootcamp leave, I was off to San Diego for BEEP school. This was a “self paced” course, which means you could stay there for quite a few weeks until you passed all the module tests. Shore duty in San Diego is just about as good as it gets in the Navy. So did I do the obvious thing, and stretch out that time as much as possible? Hell, no! This idiot went and “challenged” all the modules' tests on the first day I was there. This took the system a bit by surprise (apparently nobody else had ever been so stupid as to pass all the tests on day 1), and I ended up stationed there for a couple of weeks while they figured out where to send me next. I spent that two weeks just goofing off — and kicking myself for having been so stupid as to pass all those tests immediately!
Finally the system caught up to me, and the Navy packed me off to Mare Island, just outside of Vallejo, California. This is on the east side of the San Francisco Bay, and it was to be my home for the next couple of years. I like that area a lot, and I have very fond memories of the many trips I took to the surrounding sights.
I attended a series of classes at Mare Island, starting with basic digital logic and eventually working up to repair of computers and various peripherals (some of which were fairly exotic things, such as interfaces to sonar systems and radar systems). The courses were very much focused on the hardware, as back in those days the interval between failures was quite short — you really needed technicians to keep the equipment running.
While the training was focused on repair work, it included quite a bit of theory — you can’t repair something unless you understand how it works. These classes were, for the most part, almost trivially easy for me. This was because of a combination of several things: my relatively heavy electronics background (especially compared with my classmates), the relatively slow pace of the coursework (the lowest common denominator problem), and at least to some extent my own aptitude for it. But because the coursework was so easy for me, I had lots of time on my hands during school time — and my instructors were generally quite supportive of my doing “extra” things, so long as there was some conceivable connection to my Navy work.
I’ll pause here to mention another significant factor for my work at school — something that was a powerful motivator for me. On the first day in school, our new class was gathered and a chief (a relatively high-ranking enlisted guy) tried to scare the hell out of us. He succeeded admirably with me, but to my surprise he failed with most of my classmates. His message was real simple: half of us would likely flunk out of class, and those who flunked out would be sent to another school at Mare Island: the “swift boat” school. Swift boats, if you’re not familiar with them, are small, light, shallow-draft, and fast craft designed for patrol work on the rivers and coastal waterways. They are made of plywood; there is no armor. They are lightly armed; this varied, but generally was a .50 caliber machine gun and little else. They had small crews. And they had the highest casualty rate of any Navy unit — the Vietnam War was still going hot and heavy. There was a reason so many people were going to swift boat school — replacement crew member were always needed.
Yikes! I thought about the swift boats at least 100 times a day. Whenever my focus wavered or my energy level lagged, those thoughts would take care of the motivation problem. Amazingly (to me, anyway) this was demonstrably not true for most of my classmates. Even when their grades were putting them in danger, the typical response would be to go out for pizza and beer. And many washouts did go to swift boat school. Oh, man…
So I put in a lot of hours — to some extent, motivated by the threat of swift boats, to an increasing extent as time went by, motivated by my own interest. My first “extra” projects were hardware. It was just starting to be easy at that time for ordinary people to buy digital logic IC chips. I built all sorts of things, first from schematics, later from designs of my own. My most ambitious digital project was a “camera controller” — a gadget designed to let me take pictures of wildlife by setting up my camera on a tripod, and having the shutter triggered by the animal breaking light beams, making sound, or stepping on a trigger. I built a fancy little control box, full of lights and switches, that let me use any combination of these things I wanted to set off the camera. It could also take pictures at regular intervals, or take very long exposures (with a fancy integrating light meter to control it). I was very proud of that box, even if I was the only person who had any idea what it did. And it was my first really challenging digital electronic design.
But at some point, about a year into my school at Mare Island, we were taught the rudiments of programming. And I mean rudiments! Remember, their goal was not to make programmers out of us — it was to teach us how to repair digital equipment (in this case, a computer). But to repair a computer, we had to know just the tiniest smidgen of programming, at the machine code (lowest) level. This was the first class I found challenging — and I remember a period of a few weeks when I was wandering around with a bruised brain. I just wasn’t “getting” it. I knew that programming was the “secret sauce” that made computers actually useful, but I was having a lot of trouble understanding how that could be so. There was a very crisp event — in my brain — in the middle of one of these class sessions; this event was the proverbial light bulb going off, the big “AH HA!” moment. To any technical types reading this, the nature of that event might be quite amusing: it was when it dawned on me that computers executed machine code instructions one after the other, in sequential order unless there was a branch instruction. This is one of the key constructs of the “Von Neumann architecture” that all computers were (and still are) based on — but we weren’t taught that (it wasn’t necessary for repair work!).
That event, in context, was a key formative event in my life. From that one simple realization all sorts of derived notions spring quite naturally, and I was springing them like mad. And I wanted to program; I desperately wanted to program — this looked like a lot of fun to me (it was, and still is). But where could I get a computer to practice on? There were no Apples or IBMs back then; normal citizens couldn’t just walk out and buy a computer. The facility at Mare Island, however, was chock full of computers — and they were only being used during working hours on weekdays. With expectations of being shot down, I asked permission to have access during off hours — and the Navy floored me, because they granted me free access.
I went completely crazy on programming for the next year. There’s no other way to say it. I spent every possible waking hour (and I was young, so long evening hours were still possible!). The only programming language I knew was machine code (that’s all they bothered to teach us about, as that’s all you really need to know as a technician), so everything I did was in that language. I quickly grew tired of manually translating instructions into machine code, so I wrote a program to do it — I didn’t know it at the time, but I had re-invented something called an “assembler”. I called it a “translator", and it worked by reading files (on magnetic tape or paper tape) containing something that almost looks like English, and figuring out what machine code would represent that. I came up with the same basic idea of using “symbols” to represent variables or labels that modern assemblers use, but I worked it out on my own. That experience was invaluable, and formed a pattern for a lot of the programming I did over the next few years — I was simply unaware of the fact that other people had already explored this territory, so I just kept reinventing the concepts that they’d already invented. One way to look at that is that I wasted an awful lot of time “reinventing the wheel”. I choose to look at it another way: by reinventing the wheel, I learned an awful lot about how wheels work.
By the time I graduated from Mare Island’s schools, I was a reasonably competent programmer — albeit using strange, unconventional techniques and a self-invented assembler. The most ambitious program I wrote was a chess program that used all the computers in the lab, in a network (although we didn’t call it a network back then!). It wasn’t a very good chess player, but then neither was I and that wasn’t really the point — the point was that I had been able use the “secret sauce” to do something fairly abstract and complex. And I had a lot of fun doing it!
After school, I was stationed on the USS Long Beach (CGN-9), a nuclear-powered guided missile cruiser. It had three mainframes and one minicomputer in the NTDS system that I was assigned to, two more mainframes in the SPS-33 radar system, and a UYK-20 mainframe in the radio room (part of a secure satellite communications system). I did quite a bit of programming while station on the Long Beach. Some was job-related — for example, I successfully found and fixed some (very bad) bugs in the software that interfaced the SPS-33 radar with the NTDS system. These were hand-patched at the machine code level, if you can imagine that, as we had no compilers or linkers on the ship (not that I even knew, then, what those were!). Other things I did were recreational, and what I was quite well known for on the ship was a game I wrote. This game allowed multiple players on multiple “display consoles” (basically simple vector graphics displays) to fly simulated aircraft in a shoot 'em up contest. The simulated planes could fire cannons and missiles, and were as realistic as I could make them in terms of flight capabilities. Most of the people who worked on NTDS — officers and enlisted — spent many, many hours playing my game (called “BOINK"). And I learned a lot about programming while doing it.
Partway through my four years, I made friends with a fellow named Mike Blier — a chief electronics warfar technician. I’ve actually forgotten how we met, but I’ll never forget the next couple of years when we spent nearly every free moment working together on hobby computers. Mike bought one of the earliest kits (an IMSAI), and built it — but he had no idea how to make it do anything. Enter me — and of course I got hooked on this really quickly, and soon began building my own computers. I was astonished at the power of this little hobby computers — they were far more powerful than the “mainframe” computers I was repairing for the Navy! And I could buy one! Yee ha!
Mike and I spent countless hours with our computers, building, learning, experimenting. A long “WestPac” cruise with many weeks in the Indian Ocean helped provide many hours for us. So far from any source of parts, we had to make do with what we had — and all that improvisation was a real learning experience, too. Mike never really got into programming — that was my gig — but we both gained a lot of expertise about modern hardware.
Toward the end of my Navy career, I owned several computers of my own, and was spending a lot of time working on them. I had no idea what I was going to do when I got out of the Navy, but I knew for sure I wanted to work with microcomputers. But there weren’t any obvious job for someone with my skills — there really wasn’t much call for microcomputer technicians, and what need there was was being filled mainly by college students working for next-to-nothing. And I didn’t have the credentials (a degree) to be an engineer. Things were looking a bit shaky, career-wise, when Mike Blier showed me an ad in one of the magazines he was always reading. The ad was from Tarbell Electronics, a well-known name in the fledgling hobby computer industry. Don Tarbell, the owner, was looking for someone to write some software for him, on a contact basis — for something called a “Basic interpreter", intended to out-perform and compete with a product already on the market: Microsoft Basic.
Technical types will find this next bit quite amusing. I had absolutely no clue what a Basic interpreter was. I had no idea what any high level language was, or an interpreter, or a compiler. This is what happens when you don’t have any formal training — concepts that are well-understood by a first-year computer science student were completely missing from my brain. All I knew was that Don Tarbell was willing to pay someone to write some software, and he was asking for proposals. So, figuring I had nothing to lose, I wrote to him with my proposal.
Try to imagine what this must have looked like to Don Tarbell. He gets a letter in the mail — a hand-written letter, full of corrections, with a US Navy “from” address. In this poorly written letter is something that looks like a child’s idea of a proposal — but it does firmly say the following: that this nutcase would write him a Basic interpreter, to his specs (which I had not yet seen), in three months, for a fixed price of $2,000. To deliver a Basic interpreter, written from scratch by one guy, in just three months sounds completely absurd — six months or a year, maybe. But three months? No way! And to offer to pull off such a miracle for a mere $2,000? Crazy!
But to me, $2,000 for three months work was great pay — my Navy salary was just $333 a month. And since I had no idea what I was going to build, I just figured that I could build anything in three months. Don Tarbell wrote back and asked for a phone call; I called him and we talked for about an hour, and then he agreed to engage me. Years later he told me that he figured this was a no-lose proposition for him — the next lowest proposal he received was for (if I’m remembering correctly) $60,000 and 9 months, so if he blew $2,000 and 3 months on me, he hadn’t really put much at risk. I think most businessmen would have passed on my proposal, figuring the risk was just too high. Don Tarbell, for whatever reason, gave me a chance to do something that ended up starting my career in programming. I suspect he liked my spirit and confidence, and further liked the idea that his contract meant a lot to me.
This contract provoked an effort that when I look back on it myself has some elements of the grand epic…and not a little bit of Keystone Cops. When I got the signed contract in my hands, along with the specs for the Basic Interpreter I was to build, I didn’t even own a computer capable of being used for development: I needed a computer with 64K of RAM (the most you could get on a microcomputer back then), some kind of storage (I was still using cassette tapes and paper tape), and a printer. Nor did I own any of the development tools one would consider essential today: I had no editor, no assembler, no linker, and no debugger. And I had just three months to deliver.
To save time, I bought an economical computer kit from a fellow named Dr. Suding, who had a company in Colorado named Digital Group. I built the kit in a couple of days and got it all running. Nice stuff. I bought eight 8KB static memory boards and put them on an extension motherboard — and then had to build an enormous 5VDC power supply to power those things, and also jury-rig a whole bunch of ground to cure some ground noise problems I had. I bought a dot matrix printer from them as well — but it came without software, so I had to write a driver for it. I bought a floppy disk controller board (from Don Tarbell!), and a Persci dual voice-coil positioning 8” double-sided, double-density floppy drive — the Cadillac of floppy drives! It took me a total of about two weeks to get all that stuff in my hands, build it, write the drivers, and make it all work. That was two weeks of very, very long hours, but I didn’t mind at all, as I was having a ball!
When I finished with that, I had a 4MHz Z80 development system, with 64K of RAM, a monitor, a keyboard, and a printer. The operating system was CP/M. Now I needed development tools, and I needed them badly. There was a “tiny” development system running around in source code form; this included a simple monitor with a line-oriented editor, an assembler/linker (all code had to be in a single module), and a debugger. The latter was a brand new concept to me; that’s one idea I never came up with on my own. Anyway, I can’t remember the name of this stuff, but I got my hands on the source code and studied it for a day or so to see how all this stuff worked. Then I had a bunch of ideas for how to make it better. For starters, I wanted to edit directly on the screen (the way we do today, but back then such a thing was a new concept). I absolutely had to have multiple modules, as this program was going to be large. And I had all kinds of ideas for the debugger, especially for “smart” breakpoints and register dumping.
So I spent the next three weeks building development tools. The first thing I wrote was an assembler whose input was Zilog Z80 mnemonics and whose output was a linkable, relocatable code format that I invented (once again, because I didn’t known that others had already done this). Then I wrote a linker to take multiple modules of assembler output and create an object code image from them. Then I wrote an on-screen editor; primitive by today’s standards but compared with the line-oriented editors normally used it was wonderful! The most challenging feature of that editor was that it could handle files larger than would fit in memory; that was essential for the kinds of source code files I’d be working with. Then I wrote a debugger — a very nice debugger, with features I’d never heard of anywhere else, such as conditional breakpoints. I had a lot of fun using the debugger to debug itself!
About 5 weeks into my 13 week contract, I was finally ready to actually start developing the Basic Interpreter. My starting point was to learn Basic, as I’d never seen a high level language before. Compared with assembly language, the syntax of Basic is almost trivially easy — but very powerful. Once I figured out what an “interpreter” was, the majority of the Basic language was really straightforward. I could easily imagine how to build my interpreter for those parts. But two parts of the language looked considerably more challenging: evaluating arithmetic expressions, and the whole notion of floating point math (and all the associated operators and functions).
Eager to make some progress, I decided to leave the hard stuff to the end, and I started writing code. Note that I completely left out the usual design phase of the project: — I just sat down and started coding. This is as though you hired someone to build you a house, and they just picked up their tools and started sawing and hammering, not bothering with anything so irksome as a plan!
For a project this large, and especially for something I’d never built before (an interpreter), this was borderline crazy. But that’s what I did…
In about a month (working, I think, 18 or so hours a day on average) I had everything running except the hard stuff. A real, live Basic interpreter — buggy, some parts were very slow, some parts of the spec I was ignoring, but it was working. This was already a very satisfying achievement for me. But now to the hard stuff…
I had worked in the Navy on something called a CORDIC MATHPAK — basically a collection of subroutines that implemented floating point math, with all the usual operators and functions. I understood that stuff fairly well, and it served as a model for me on my interpreter. But…the Navy work was predicated on a mainframe computer that had add, subtract, multiply, and divide as basic instructions that the computer could do by itself — and a Z80 (the target processor for the interpreter) was missing the last two. I wrote multiply and divide functions and optimized the heck out of them (I remember that my divide function was a couple of clock cycles faster than any I’d seen published), mainly by unrolling loops. But still the CORDIC algorithms would be very slow using these multiply and divide functions. So I looked for something that would be faster, and somehow happened on a little book called “Hastings Approximations”. This volume contained a whole bunch of polynomials that allowed very fast evaluation of approximately correct transcendental functions (logs, sines, etc.), to know accuracies — and there were approximations listed for all the functions I needed, with more accuracy than I needed. These approximations were my salvation: I used them to build all the transcendental functions in my interpreter, and the result was substantially faster than the spec.
The last remaining hurdle was expression evaluation, along with a new one that popped up and turned out to be very challenging: formatted numeric printing. Expression evaluation is one of those things that any computer science student is exposed to very early, and it’s one of those things that’s been well-studied. There is a lot of literature on this subject. Naturally, I was blissfully ignorant of this, so I just invented my own way. The approach I took wasn’t a bad one, either: I converted a conventional expression into reverse-Polish form, and then evaluated it using a stack. I got this idea from seeing how HP calculators worked; it made sense to me. Printing a formatted number really is a challenging problem, but more because it’s a big, messy sort of job than any real algorthmic challenge. I remember this piece of code was a terrific challenge to debug, because there were so many tests that had to be made in order to exercise every branch of the code.
I completed the last functional piece of the interpreter about a week before I was due to deliver it. I thought that was a luxurious schedule, for now I had an entire week to polish the thing up. And I did — I spent the whole week testing and benchmarking, fixing bugs and optimizing. By the delivery day, it was looking pretty darned good.
A couple of days before delivery day, I called Don Tarbell to arrange my trip up to see him (I was in San Diego; he was in Carson, about 120 miles away). I remember being very surprised by his reaction when I told him I was ready to deliver — he was absolutely astonished! He asked me over and over again if I was sure I was ready; he said he’d rather I be a little late than to deliver something that wasn’t really ready. I assured him I was ready, and we set a date and time.
It was a very exciting drive for me up to his place. The whole time I was anticipating the fun of showing him the product — but there was also a little fear, that Don Tarbell might not be happy with what he got, for some reason. I was also looking forward to collecting that check — I was in real need of the money! When I arrived, bearing floppies with the source and object code, Don was ready with a system to test it on. We spent the next couple of hours with him just sitting at the keyboard, trying one thing after another, and every last thing he tried worked perfectly. After the first couple of tests, he had a smile; after about five he had a big grin. In a half hour or so, he was very excited and loudly happy. That was so much fun! And it’s still the part I like the best about being an engineer — having a happy customer when you deliver.
Don wrote me a check on the spot, gave me a tour of his shop (including the TTL logic computer he’d built from scratch), and sent me home with a couple of boards as a gift. Over the next few months we worked together a lot, with him contracting for both bug fixes and enhancements — and insisting on paying me going rates for that work. I made a lot more money on the followup work than I did on the original contract.
And that was my introduction to a career in software engineering…
