Monday, August 1 2022 at 11:25 AM PDT
I struggled with whether or not I should make this post because I worry that the topic of burnout is taboo. Admitting that I was burned out and that I had to take time to recover from it feels like admitting a kind of failure or a weakness, but the longer I dwelled on it the more I knew that I had to say something, if for no other reason than because I want to help anyone else who's suffering from burnout and wondering what to do about it. You're not alone. During the last few months I have discovered that so many friends and colleagues have gone through something similar, and I want to normalize burnout awareness, especially becuase my message is positive.
Anyway, hi, I was really burned out. I want to talk about it.
Saturday, November 21 2020 at 8:47 AM PST
Was my last blog entry really in March? Apparently, yes, it was.
Forgive me. 2020 has been a strange year. I'm sure you'll agree.
I have been lucky enough to retain a job during the global pandemic, and moreover, the job has been busy as hell. In truth, I haven't been able to work on personal projects nearly as often as I wish I had been able to. What's worse, while some people found themselves with lots of extra time after losing a harsh commute, I was already used to working from home. I've been full-time remote since the end of 2014, so working from home is nothing new to me. I already didn't have a commute! I did not suddenly get any new hours in my day.
I do still have some software projects on the back burner right now. Among them:
- The 3B2/1000 emulation, which is perhaps 80% complete.
- A Tektronix 4404 emulator, which is perhaps 20% complete.
- Various personal information management projects that are scattered here and there.
- Forever tinkering with Emacs configurations.
And, unrelated to computers, I recently bought a violin with the intention of learning to play old-time fiddle. It's fun, but practicing is quite a chore, especially when the sounds you're making are so very terrible.
Monday, March 30 2020 at 9:51 AM PDT
It's now been more than three months since my last post, and I think I owe everyone an update on what I've been doing with my life.
I've been working on the 3B2/1000 simulator for a while now, and at the outset, I decided to try to build a single simulator executable that could be configured as either a 3B2/400 or a 3B2/1000. In hindsight, this was a mistake, but sometimes you can't know that until you get deep down into the guts and have to do some unwinding.
So, I've thrown out what I had, and started anew with the right
strategy. Instead of a single
3b2 binary, instead, there will be
3B2-1000.EXE, respectively, on Windows). This follows the VAX
simulator model, and makes a lot of sense given the levels of
similarity and difference between the 3B2/400 and 3B2/1000.
Friday, December 27 2019 at 10:51 AM PST
In the long, dark months since September, I have not really done any work at all on my 3B2 emulator. Since it's Christmas break for me right now, though, I've taken up the mantle once again and started hacking away on it with the aim of implementing Revision 3 system board support that will allow the simulator to run as a 3B2/1000 system.
Monday, September 30 2019 at 12:56 PM PDT
It's been a minute, hasn't it! I'd like to talk about the state of the 3B2 Simulator and get everyone up to speed with where we are, and where we're going.
Monday, August 5 2019 at 8:11 AM PDT
Do you like obscure artificial intelligence workstations from the 1980s? Of course you do! So do I. That's why, when I found out about the Tektronix 4400 series of workstations, I was immediately smitten.
The 4400 series (including the 4404, 4405, and 4406) were Motorola 68010 and 68020 based workstations built to run Smalltalk-80 and Lisp, and were marketed toward the artificial intelligence industry of the first half of the 1980s. Those were the heady glory days of companies like Symbolics and Lisp Machines, Inc., and stiff competition from Texas Instruments' "Explorer" workstations, so they were pushing into pretty frothy territory.
For about a year now, I've wanted to emulate one, but I just didn't have all the documentation necessary to make it a reality. This past weekend, though, my friend Josh managed to scrounge up a copy of the Tektronix 4404 Component Level Service Manual, which Al Kossow of the Computer History Museum and Bitsavers scanned and archived. Published in 1987, this juicy little manual details every aspect and detail of the 4404 workstation from the top down and the bottom up. It's absolutely glorious. Combined with the Tektronix 4404 firmware already preserved on Bitsavers, I have everything I need to build an emulator. Now, I just need to actually do it.
Yes, in other words, it's just a small matter of programming.
Saturday, June 29 2019 at 3:15 PM PDT
After what feels like an inexcusably long time, the WE32106 Math Acceleration Unit (MAU) has been merged into the main SIMH tree, and the 3B2/400 simulator has support for it.
This project was one of the most tedious, boring, and yet educational projects I have worked on. Join me now as I recount the harrowing details.
Sunday, February 3 2019 at 9:09 AM PST
Ever since I got the AT&T 3B2/400 emulator working well enough to share publicly, I've received a lot of requests for it to support the (in-)famous 3B2 Ethernet Network Interface option card, commonly referred to by its EDT name, "NI".
The NI card is based on the Common I/O Hardware (CIO) intelligent peripheral architecture, the same architecture used for the PORTS card and the CTC tape controller card. I've implemented support for both PORTS and CTC cards, so how hard could the NI card be, right?
But, I think at long last, I've finally cracked it.
Monday, January 7 2019 at 5:05 PM PST
I'm writing this entry more for myself than for anyone else, because I always forget what a pain this is to get set up properly. The backstory starts with a kernel fault.
# TRAP proc = 4022EBEC psw = 1472B pc = 400287BD PANIC: KERNEL MMU FAULT (F_ACCESS) SYSTEM FAILURE: CONSULT YOUR SYSTEM ADMINISTRATION UTILITIES GUIDE
This is what happens if you install software out of order on the 3B2/310, and 3B2/400. I've encountered it a few times, both using my 3B2/400 emulator and using a real 3B2/310. Here's what's happening.
There are two windowing packages for the 3B2:
- "AT&T Windowing Utilities", a single floppy disk containing a driver
for the DMD terminal (the
XTdriver), a minimal support environment, and not much else. It installs under
- "DMD Core Utilities", a three flopy disk set containing a different
version of the
XTdriver, a full support environment, a bunch of demos, and more. It installs under
You might think the more complete package should be installed, ignoring the other one. But, surprisingly, you'd be wrong. If you install only the "DMD Core Utilities" package, or if you install the "AT&T Windowing Utilities" first followed by "DMD Core Utilities", you'll be left with a driver that simply doesn't work. I haven't dived in and really debugged why it's broken, but clearly it is.
So, instead, always install the "DMD Core Utilities" first to get the
/usr/dmd environment and all the nice demos, but then install
the "AT&T Windowing Utilities" to get a working driver.
You can all thank me later.
Monday, January 7 2019 at 11:29 AM PST
The short version is that my use of ElectronJS to build a fully cross-platform front end did not go quite as smoothly as I'd hoped. It went fairly well on macOS and Windows 10, albeit with performance that wasn't quite what I wanted. But when it came time to build it on Linux, I hit a brick wall: No matter what I tried, I could not get the native Rust NodeJS module and the native Electron NodeJS modules to rebuild cleanly.
See, there's a problem when you use native NodeJS modules in ElectronJS: You have to make sure that both ElectronJS and the native modules have been built with exactly the same version of NodeJS. ElectronJS has some tools to help with this, but they were extremely flakey for me. There is a morass of complexity involving NPM, native compilers, and NodeJS. I spent a few days on it, but eventually I gave up in frustration.
I was upset about not having a functeional emulator on Linux, so I dove in and decided to learn some GTK+. If I couldn't have an Electron app, I'd damn well build native front-ends myself, thank you very much.
The result turned out very well. It's a fully native GTK+ app that
takes a few arguments on the command line, has good performance, and uses
the common dmd_core back end library. It's written in C, and uses a
pre-built static library build from
After this success, I wanted to see if I could do the same thing on macOS. I could have just used the same GTK+ code on Mac, but the performance of the Cocoa GTK+ bindings is somewhat poor compared to native frameworks like Metal and CoreAnimation that offload work to the GPU, so I built a native Cocoa app written in Swift instead. It went so well, in fact, that I've distributed it in the Mac App Store.
[A brief aside rant: Apple, you need help. Your developer documentation is terrible. It took far longer for me to build the Cocoa app than it should have. All the way, I had to fight documentation that is embarrassingly sparse at best. Very few documents mention how to use an API or framework. Those that do are in the "Documentation Archive" and haven't been updated in years. Some of those come with a deprecation warning. Most of the currently maintained docs offer nothing more than a function signature with no further discussion. I relied almost entirely on third-party tutorials and examples to help me understand how to use the Apple frameworks. Shameful. Please, do better!]
My next task is going to be a native Windows front end. I'm sure it'll be an adventure, just like the Mac version, but at least I'm learning some useful skills here.
Thursday, December 13 2018 at 1:39 PM PST
Back in the early 1980s, before GUIs were commonplace, Rob Pike and Bart Locanthi Jr. at AT&T Bell Labs created a bitmapped windowing system for use with UNIX. Originally, they called the system "jerq", a play on the name of the Three Rivers PERQ computer. When the technology started to get showed around outside of the lab, however, they changed its name to "Blit", from the name of the "bit blit" operation.
Here's a small demo of the system in action, circa 1982.
Monday, September 10 2018 at 9:50 AM PDT
I recently started on a quest to finish up a loose end on the AT&T 3B2 emulator by finally implementing a simulation of the WE32106 Math Acceleration Unit (MAU). The MAU is an IC that accelerates floating point operations, and it could be fitted onto the 3B2 motherboard as an optional part. I've seen quite a few 3B2 systems that didn't have one; if it's not present, the 3B2 uses software floating point emulation, and gets on just fine without it. This means the 3B2 emulator is totally usable without the MAU. But still, wouldn't it be nice to simulate it?
Lucky for me, one of the critical pieces of documentation I've managed to find over the last few years is the WE32106 Math Acceleration Unit Information Manual. This little book describes the implementation details of the WE32106, and without it it would be hopeless to even try to simulate it. (Speaking of which: The book hasn't been scanned yet, which is a high priority. I have the only copy I've ever seen.)
But even with the book, this is no simple task. So let's dive in a little deeper and look under the hood of the WE32106.