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.
Monday, August 27 2018 at 11:00 AM PDT
This weekend's project was to image all of my AT&T 3B2 hard disks to preserve the bits on them. To do this, I used David Gesswein's MFM Reader and Emulator board, which allows you to either emulate an MFM hard disk, or read MFM data off of a real hard disk.
A nice side effect is that the images you pull off of a hard disk are compatible with my 3B2 Emulator, so once they've been read off, you can just boot the image as if it were running on a real 3B2. Nice!
I've been pretty impressed with the MFM Reader and Emulator board. It's a nice piece of kit to have around, and it's fully open source. If you've got any MFM systems or hard drives lying around, give it a shot. It's sold either in kit form or fully assembled at a very reasonable price.
Friday, August 10 2018 at 5:40 PM PDT
After much hacking on elisp, I'm happy to announce two changes: First, I've finally implemented pagination on my blog, so the entire nine years of archives isn't rendered in one huge page. And second, there's now an RSS feed available at https://loomcom.com/blog/index.xml. Woohoo!
Getting both of these features implemented was a bit of a
challenge. The built-in Org-Mode publishing feature provided by
ox-publish.el is very much geared toward publishing a single
page. Really, it's supposed to be for publishing a site map of your
website layout. Using it to publish a blog is actually kind of a
kludge and an abuse of the feature, to be frank. But here we are,
that's how most Org-Mode bloggers publish their blogs.
If you want to check out the Emacs setup for this site and blog, you
can look here on GitHub. It's a fairly complicated bit of hacking
designed to work around the single-page limitation. I've also altered
the default RSS backend, supplied by
ox-rss.el, to filter out some
unwanted noise from my RSS feed.
The only thing I can't yet figure out is how to force Org Publish to always generate absolute URLs. I actually don't think it's possible, yet.