The TI (Lisp) Explorer Project

This is actually the long and repolished version of an employment history entry I prepared for LinkedIn, so the opening is a bit fuzzy. (I might link it back at the end, but for now I just need to save it to get the anchor…)

The dates are a guess, and TI wasn’t even limited to semiconductors in those days. Also, the contract was actually through another temporary company, but I haven’t found any of the pay records. Pretty sure it was a Sony subsidiary that was sold later. Or maybe it merged with Adia? Became part of Adecco?

So now this “employment experience” is more like part of the history of computers. I was hired to help the TI Explorer Project, which may have been the last of the native Lisp machines. No OS. It ran Lisp directly out of the microcode. (I remember Lambda and Symbolics as the competitors, but later I think TI made (or tried to make) a plug-in card version of the TI Explorer for Macs.)

I was hired to join CMINT, Configuration Management, INtegration, and Test. Though I was hired for database work in Pascal (on a DEC), when they found out I could program in Lisp they decided to give me one of the Explorers and I spent almost all of my time working on the new machine. There were not many of the machines available at that time, but I got priority because Lisp programmers were also rare. I joined some months into the project and was there until the release of the new (or first?) version.

This machine had one of the largest CPUs ever made until that time, something like half a million transistors. However it was quickly obvious to me that it would never make money, and sure enough the entire computer division was sold off to HP soon after I left. (Pretty sure the sale included a sweet little Unix box, but that only had a few kernel developers and it had probably been crippled when Mark Brown moved to IBM around the same time as I left. (He did well there, though I don’t think he ever made it to DE.))

I have quite a lot of memories of those days, even after 30+ years. The largest piece of code I had to handle was the incoming side of the main email system. Hairy piece of code that had been ported from Pascal to Zeta Lisp (by Roger?) and I had to port it to Common Lisp. Mostly smooth and easy, but there were a couple of residual bugs that I had to struggle with. I remember wrapping an unwind-protect around one of them to force a reboot when it got hung, but I think there was one last bug I was chasing at the end. I turned that one over to Nobi Nagase (the first Japanese person I remember meeting) and later on he told me that he handled the last bug by changing a delay time.

Maybe the most interesting bug was a weird one that I think I spent an entire morning trying to pin down. I couldn’t even figure out if it was really broken, but after studying it and fighting with it for some hours I took it to Patrick Dussud, one of the Lisp gurus. (He was a Frenchman who went to Microsoft later on.) He looked at it for about 20 seconds and said “Yes, it is borken.” [sic] Then he poked at it for about a minute and told me it was in the compiler and sent me to the compiler guru, who later on told me he’d fixed it. (Can’t remember his name, but quite a reclusive DE sort of fellow.)

Several memories involve memory management problems. For example, there was one time when the hashing wasn’t working properly, and someone knew I was doing prime number stuff, so they asked me about the modulus, which turned out to be composite and that was causing the excess collisions. There was another time they sort of borrowed my machine to figure out what was wrong with the garbage collection. I was especially good at keeping the machine running as the garbage accumulated, so they analyzed my garbage to figure out where the collection was failing. I think it was a mark and sweep algorithm and the marking was failing somehow.

There was also a massive crash one day when an excavator dug up a power line near the plant. All of the Lisp machines crashed when the power went out, but even after power was restored, no one could boot, so about 70 programmers were sitting around on their thumbs. The problem was that booting a TI Explorer required checking with the patch server for the latest patches, but there were no patch servers to check with. The patch servers couldn’t boot because they needed to check with the email server for some reason I can’t recall. So I wound up nursing one of the servers to get it to boot, manually conning it to ignore most of the error messages. Someone must have been giving me a lot of instructions over the phone? I think I had the primary mail server, which was in the office of a high executive. Maybe she was in Dallas that day? Other people were working with the patch server. I think that eventually I got my server sufficiently awoke that the patch servers were alive and everything else could start booting, though it’s possible my part didn’t matter much. Pretty sure the last step required rebooting the mail server to get it into a normal state, but many hours of programming time had been wasted that afternoon.

One hardware-related memory. The machine used a LOT of memory, but we didn’t have much physical memory in those days. Therefore there was a lot of paging to disk that made the machine run quite slow. But there was one giant RAM card floating around the place, and it made a huge difference when I had it in my machine for a few days. I think that “giant RAM” was something like a few MBs in those days. All I can remember fairly clearly is that it was a full-size card with RAM chips all over it. In the normal case it took something like a half hour to boot the machine, but with that RAM card it could finish booting in a few minutes, and everything was much faster.

And a network memory. Most of the development team was in Austin, but the key leaders were up in Dallas. That meant a lot of work was dependent on a bridge from the Austin network to the Dallas headquarters. Fuzzy recollection was that it was a brute force solution that ran at several MB/sec, which was again considered impressive in those days. But it reminds of another weird hardware thing, the fiber optic cable to the display. Which reminds me of the weird keyboard with 4 (or was it 8) bucky bits?

My last recollection involved an interesting microcode bug. Memorable because it came up after the end-of-development code freeze when we were focused on final testing before shipping the code. One of my programs broke after a vector-push-extend call. Turned out that a last-minute microcode optimization was preventing initialization of the new part of the vector with zeros, and my code made the bad assumption that the new values should be zero. (At least that’s how I recollect or confabulate it now.) (I think it was fixed by Susan who worked for Dave? I sat next to the microcoders, and sometimes had lunch with them, but I didn’t actually know them that well.)