Projects
xmachine
status: alive/in progress
code: GitHub
The goal of this project was to write an emulator for a retrocomputing machine of yore. I settled on the DEC PDP-11.
Why did I choose it?
For mostly lame reasons. I like the front panel (cool 70s color
scheme) and it's word size is 16-bits (fits in a unsigned short,
but it's byte addressable so unsigned char (or
uint8_t)).
It's been through a few iterations so far.
It started life written in C, as a monolithic program not targeting
any specific PDP-11 version/processor.
I rewrote it in C++ with threads (to handle a naive bus
implementation) and ncurses (for console display fun).
I'm currently (as of 2025-11-16) rewriting it in C as a modular
(devices are individual programs) thing, with the eventual goal of
targeting a PDP-11/40 (KD-11A processor with FP11 (floating point processor)
and KT-11D memory management option).
Recent development and Unibus infodump
The last two months have mostly been spent writing libunibus. That's
the Unibus driver and receiver stuff for devices. Bus communication
is written Rube Goldberg-style with each device having a priority bus and data
bus UNIX file socket.
Why? Well, it probably could have been done another way (and better),
but it seemed the easiest way to go for implementing the priority bus
at least to me. Devices, once they request bus master access, can block
(accept) or pass the grant from the bus arbitrator. That's how I ended up with
the implementation I have.
It kind of looks like this:
Each circle is a device (standalone program) and it has a UNIX file socket,
supporting datagrams, named /tmp/xmachine/<name>_pr.socket.
For example, the CPU needs bus master access to fetch a word from memory. To do that, you'd see the following activity on the priority bus:
CPU: Assert BR BA: Receive BR, Assert BG CPU: Receive and block BG, Assert SACK BA: Receive SACK, Negate BG CPU: Receive negated BG, Assert BBSY to the left (BA) and right (MEM) CPU now has control of the data bus.