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.

The New Strategy

The 3B2/400 and 3B2/1000 are similar enough that it was very tempting to make the choice between them simply configurable at runtime. But, the way SIMH builds its system definitions made this a really trecherous path to go down.

Instead, it’s proven to be so much easier to simply split the code, where appropriate, into 3B2/400 and 3B2/1000 versions, in separate files, and to build the header include system such that the makefile can compile and link the appropriate binaries with two seaparate targets.

Some logic, like the CPU, is complex enough but similar enough between revisions that it’s staying in one file. Various blocks are implemented on a per-system basis using the C preprocessor (e.g. #if defined(REV3) ... #else ... #endif blocks).

The other components that need the most individual attention are:

• The MMU, because the WE32201 is significantly different from the WE32101, internally,
• The MAU, again because the WE32206 is significantly different from the WE32106,
• The CSR, which is totally different between system revisions.

Luckily, much of the other stuff, including expansion cards, is completely shared between the revisions, and needs almost no attention.

SCSI

In addition to all of the above, the other big component to worry about was adding SCSI emulation. Unlike the 3B2/400, the 3B2/1000 has no on-board Winchester controller, and must do all of its mass storage through a SCSI expansion card. I’ll have much more to say about this subject later, but three things saved my bacon:

First, the SCSI software distribution includes system header files that helped describe some of the internal structure used by the SCSI card.

Second, the ROM on the SCSI card is much more fully featured than the ROMs on most other cards, and disassembling it using the Ghidra reverse engineering tool was incredibly helpful in understanding how the card behaves.

Third, SIMH includes a SCSI emulation library written Matt Burke. This library takes care of simulating all the low level SCSI interaction and bus state, which left me with only the core 3B2 stuff to implemenmt. Bravo!

The Final Tally

At this point, the MMU and MAU are the only things holding me back from a complete (if possibly buggy) 3B2/1000 simulation. So, that’s what I’ll be focusing on over the next few weekends. Hopefully, we’re looking at a feature complete 3B2/1000-80 simulation some time in May.

Wish me luck!