Development Things

home .:. projects

>> Escape from the bit bucket.

xmachine log

2026-02-09: Arbitration

The CPU is now properly designated as the bus arbitrator.

Probably in the future I should read the doc on the bus last and the doc on the processor first.

Also, my design for the bus can probably be simplified to a process that runs and accepts connections from devices. As the devices connect they could probably be entered into a queue and that would become the bus order.

The only thing sort of special is the connection to the CPU as the arbitrator.

2026-02-07: Weekend Update (Current State Revisited)

I wouldn't go so far as to say "everything is fixed", but libunibus is at least. Since everything kind of relies on that working, that would be why everything was broken previously.

My current criteria for things being fixed is by running:


$ ~/opt/pdp11-cross/bin/pdp11-aout-as asm/as/add.s -o local/add.as.aout
$ make all
$ bin/bus &
$ bin/mem -f local/add.as.aout &
$ bin/cpu

In English, assemble the add assembly example to aout. Run make all, which builds bus, mem, and cpu (plus associated libraries). Then start bus, mem, and cpu in the order specified. cpu runs until its IR is zero, then halts.

So... yeah, killed a whole Saturday working on it, but I now kind of have a renewed enthusiasm for the project.

2026-02-04: Current State

The project has been dormant for a few months now. Mostly due to lack of time and the whims of the wheel of hobbies.

Also, everything is currently broken.

2025-11-21: Current State

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:

diagram of bus communication

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.