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.

There’s actually quite a bit of work involved in getting this done, and there are a couple of different ways I could go about it. As a bit of background, other simulators in the SIMH platform take a few different approaches, which I’ll summarize here.

The first approach is to build a different simulator binary for each variant you want to emulate. This is how the VAX simulator in SIMH works. The basic vax target simulates a MicroVAX 3900 (KA-655), but there are many other targets, such as vax780, which simulates a VAX-11/780, and vaxstation3100, which simulates (you guessed it) a VAXstation 3100.

The second approach is to build one simulator binary that can be targeted at different models with a configuration setting. This is how the PDP-11 simulator in SIMH works. For example, you can set the PDP-11 model to be a PDP-11/23 with the command

sim> SET CPU 11/23

But if you’d rather simulate a PDP-11/73, you use the command

sim> SET CPU 11/73

Both approaches have advantages and disadvantages. Personally, I think I like the second approach a bit better from a usability standpoint, so that’s the approach I’m taking with the 3B2 emulator. With the next major release, you’ll be able to do

sim> SET CPU 3B2/400
sim> SET CPU 3B2/1000

The first setting above will be the existing simulator behavior, simulating a 3B2/400 with one or two MFM hard drives. The second setting will allow the simulator to behave like a 3B2/1000 with a WE32200 CPU, WE32201 MMU, and one or more SCSI hard drives.

The Master To Do List

I’ve already got a good start on this on a feature branch. Much of the boilerplate to support switching CPU modes is implemented. Because the 3B2/400 and 3B2/1000 have different memory maps, I’ve also added some support for switching the memory map on the fly. But there’s still a lot to do.

• Implement the extra WE32200 instructions and addressing modes.
• Implement the extra WE32201 MMU instructions and modes.
• Implement the new Rev 3 Control and Status Register.
• Verify that the new floppy controller (WD1793) is fully compatible with the existing floppy controller implementation. I think it is 100% backward-compatible, but I don’t know.
• Implement SCSI expansion card support.

Probably of all of these, the SCSI support will be the hardest. I have no access to any SCSI driver source code, so understanding how the 3B2 interacts with the SCSI expansion card will have to be done entirely through reverse engineering the binaries.

Further, I still have no access to any System V UNIX source code that targeted the Rev 3 system board. I only have sources that targeted the 3B2/400, so my only source of knowledge will come from reverse engineering binaries and the 3B2 Technical Reference Manual, which (thankfully) seems pretty complete with regards to exploring the internals of the 3B2/1000.

It’ll be a challenge, but I mean, how bad could it be, right?