Skip navigation

Seth Morabito ∴ A Weblog

Recovery from Burnout

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.

It's Been A Minute

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.

3B2/1000 Simulator Progress Report

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 two binaries: 3b2-400 and 3b2-1000 (or 3B2-400.EXE and 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.

Here Comes Rev 3

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.

What's Next for the 3B2 Simulator?

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.

Could This Be My Next Emulator?

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.

Stay tuned!

The MAU At Last

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.

Understanding the Network Interface (NI) Card

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.

Using the DMD Terminal with a 3B2

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.

proc = 4022EBEC psw = 1472B
pc = 400287BD


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:

  1. "AT&T Windowing Utilities", a single floppy disk containing a driver for the DMD terminal (the XT driver), a minimal support environment, and not much else. It installs under /usr/bin and /usr/lib.
  2. "DMD Core Utilities", a three flopy disk set containing a different version of the XT driver, a full support environment, a bunch of demos, and more. It installs under /usr/dmd/bin and /usr/dmd/lib.

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 full /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.

Emulating The DMD 5620: Take Two

Monday, January 7 2019 at 11:29 AM PST

Last month, I wrote about my experience building an emulator for the DMD 5620 computer terminal. Well, I'm going to revisit that, because my approach did not turn out the way I wanted it to.

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 dmd_core.

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.

Emulating the DMD 5620 Terminal

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.

3B2 Math Acceleration

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.