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.

boardnice feets

UniBone is very similar to its QBUS successor "QBone".

Yet another device emulator?

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


Unibus controller cards that interface to any modern standard are very rare and expensive.  A Unibus SCSI card or ethernet card will often cost $1000 if you can find one. With UniBone, in time a variety of devices could be emulated.

UniBone can be plugged into every PDP-11 with quad SPC slot, see here a PDP-11/05:

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:

When using UniBone as diagnostic tool, it mates well with the signal adapter "UniProbe".


Some more exotic ideas include


Whats really there now?

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


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".


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: outputs jitter, sampled inputs can loose signal edges. The PRUs run independent of Linux timing and are fully deterministic. They are 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:


Linux and real time

QBone has to react on UNIBUS signals very fast (well in sub-micro-second range). Thats not the domain of Linuxes at first, but as you see it's possible.

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.

"Linux with RT patch" means: This Linux kernel has support for fast real-time applications. Linux started as desktop operation system, where the only interface to an "outside-world" is an user slowly clicking the mouse. If the Linux is embedded into circuitry, it has to react on events much faster and predictable. Making Linux real-time capable was a decade-long struggle.

For some reason, "PRUs" are not called "microcontrollers", but "programmable realtime units" (wait, wasn't a series of famous minicomputers called "Programmable Data Processors"?)These are two independent 200MHz 32 bit RISC processors, sharing memory and all resources with the main ARM CPU. 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.