UniBone - Introduction

Parent Category: Projects Category: UniBone Written by Administrator

"UniBone" is a bridge between DEC UNIBUS and modern Linux environment. Primary applications is device emulation. It can interface to many PDP-11's, as well as to PDP-10 and VAX expansions.

It needs a standard quad "SPC" ("small peripheral connector") slot.

The Linux system is an off-the-shelf BeagleBone Black ("BBB"), running Debian Linux with RT patch. The BBB includes two high speed microcontrollers ("PRU"), these do all the low-level UNIBUS realtime-protocol logic. No FPGA is needed.

The PRU provide an application interface (API) to Linux programs, so these can access the UNIBUS with some high-level functions. This closes the gap between the multi-megahertz realtime signal handling on the bus wires and those indeterministic Linux processes.

"UniBone" could easily be folllowed by a similar "QBone" for QBUS systems: QBUS is just "UNIBUS with fewer wires".

"Project UniBone" consists not just of a hardware board, the most complex part is the software stack.

There are already several device-emulator projects in the web, so UniBone has to be different:

  • instead of emulating just a disk or floppy drive connected to a DEC controller card, it emulates device & controllers together at the UNIBUS level.
  • having a full Linux behind allows even to run SimH or complex diagnostic software on real hardware, beside all the other benefits.
  • All programming is done in C/C++ .
  • Hardware should be simple enough for a "do it yourself" kit: low-cost and low-tech.


boardnice feets


 UniBone has the form factor of a standard DEC "quad-slot" board and can be plugged into every PDP-11:

pdp1105 top Bearbeitet


Even DECs tight limits on vertical board height are met by the BeagleBone ... with some squeezing and a special mounting solution.

board fit


What can it do?

As older PDP-11s tend to break often, UniBone is primarily meant to keep machines running by emulating one or more failed subsystems and aid in repair.

UniBone is designed to fulfill many roles:

  • simulate a memory card for a running PDP-11. Memory can be pre-filled or saved, so its like core.
  • simulate storage devices (disk or tape). Media images are SimH compatible Linux files then.
  • simulate devices that control own physical hardware, as the BBB is full of interfaces (GPIOs, I²C, A/D,...) and patch fields can hold own circuitry. 
  • simulated devices can have their own physical "lamps & switches" panels.
  • monitor or trace UNIBUS traffic (record the bus traffic). This replaces a 56+ channel logic analyzers when tracing the PDP-11 instruction stream.
  • stimulate UNIBUS devices, for test or to dump disk/tape media.

Some more exotic ideas include

  • rebuild own DEC devices you never could acquire. For example the VC11 video controller ... for Moon Lander.
  • access physical UNIBUS devices from within SimH.
  • couple PDP-11s by shared memory emulation over internet.
  • building even a PDP-11 CPU with UniBone (doubt this is ever done. A simple RL disk drive emulation was hard enough).


Whats really there now?

All vaporware and marketing speech aside: At the moment we have

  • stable hardware
  • a memory emulator
  • RL11 controller with 4 RL01/02 disk drives and console panel
  • a front-end processor for the PDP-11
  • a UNIBUS hardware test adapter.
  • a selftest tool.

All these functions are controlled with a big, clumsy, multi-menu application, named "Demo".

The RL02s pass (almost) all ZRL* diagnostics, RT-11 does boot on a PDP-11/34 and PDP-11/05.



Programmers play ground!

Since the volume of possible device emulations and test applications is possibly too much for one person (at least: for me!), UniBone is made "community friendly" and tries to be "as least surprising as possible".

  • The hardware is cheap and robust, parts should be available for years.
  • there's a big community behind the BeagleBone and Debian Linux.
  • Soldering can be done by hand, no fine-pitch parts.
  • Schematics are made with KiCad.
  • No FPGA is used, programming is done in plain C/C++.
  • The gcc-compiler for the ARM processor and the "clpru" compiler for the PRUs run on the BBB itself, so (in theory) UniBone runs its own development tools.
  • Software is split into layers. Programmers of applications and device emulators use a set of core classes, so something like a SDK (system developers kit) exists. Your are completely hidden from the PRUs, all the highspeed stuff and details of UNIBUS control. There's even a small "hello world" UNIBUS test device implemented as example.


Why a BBB?

First question you hear today is: "Why not using a Raspberry Pi"? Comparing RPi with BBB is a bit pointless, as both have different strengths. BBB is weak at CPU power and multimedia, but is a great industrial controller. There's an incredible amount of peripherals built into it. The System Reference Manual is the largest PDF I've ever seen: 5000+ pages.

Sure the latest RPi 3B has 4 cores, is 64 bit, is faster than BBB, has more RAM and better graphics. But all this is of no big value for UniBone, what we need are fast real-time GPIOs.

For real-time applications the Sitara AM335X CPU on the BBB has two separate I/O processors called PRU ("Programmable Realtime Unit"). They execute code at 200MOps, have own GPIOs attached and are especially built for doing bit-banged protocols in software. They can replace FPGAs in medium speed-applications.

A simple benchmark for GPIO perfomance is a loop in C like this:

while(1) {
   my_gpio_pin = 0 ;
   my_gpio_pin = 1 ;

This produces a square wave on an external pin. On UniBone, the loop time is 15ns, the BBB-PRUs reach 66MHz output here. Beat that, RPi!

What's almost important as speed is stability: user programs under Linux will get stopped shortly by the task scheduler on multitasking. Signals produced in software would reflect that, sampled inputs can loose signal edges. The PRUs run independent of Linux timing and are fully deterministic. They are even constructed without pipelines or cache, so one opcode executes always in 5 nanoseconds.


Regarding the design targets above, BeagleBone has many advantages over an "ARM + FPGA" solution:

  • It's a cheap and complete Linux platform with community support.
  • small enough for DEC slots.
  • the PRU processors are already there for free;
  • all the highspeed signal stuff is already solved on the BeagleBone;
  • no 100+ pins CPLD to solder, no fine-pitch ICs! The PCB itself can be distributed as build-yourself-kit to everybody.
  • PRU integration into ARM Linux is excellent (shared memory with 200MB/sec bandwidth);
  • and the PRUs are programmable in (almost) plain C.
  • The C++ based development cycle is fast: Full recompile and download onto the board is about 30 seconds on my x64 host. Compare that with FPGA synthesis.