QBone - Introduction

Parent Category: Projects Category: QBone Written by Administrator

"QBone" is a bridge between DEC QBUS and modern Linux environment. Primary applications is device emulation. It can interface to many PDP-11's, as well as to QBUS-based Micro-VAXes.

It is a "Quad"- Flip-Chip card and requires QBUS on the A/B fingers.

Onboard Linux device is a BeagleBone Black ("BBB").

Proudly presenting:

qbone upward

qbone facing

 Click images to enlarge

"QBone" is very similar to "UniBone", the Linux-to-UNIBUS-bridge.

Much of the UniBone documentation applies to QBone as well and is not duplicated here!

How to get one

Business stuff first! QBone is available for sale, as kit or ready build.

Europeans best get it directly from me, sitting in Germany.
A kit with all SMD parts mounted is €170, the ready build and tested is €260. The BeagleBoneBlack is extra. Contact me via This email address is being protected from spambots. You need JavaScript enabled to view it. or This email address is being protected from spambots. You need JavaScript enabled to view it..

North American and International distribution is done by Joan Touzet from Toronto, check out https://decromancer.ooo/qbone/


QBone in a PDP-11

Thanks to a special mounting solution, QBone fits into one standard DEC Flip-Chip slot (utilizing all tolerances). So it can be plugged into every QBUS card cage, from old LSI11/03 to latest micro VAX. See it here in an open 11/23+ :

qbone cage full

qbone cage detail

As usual, these cards sit quite sloppy in their slots. The wikipedia article on PDP-11 turns it positive: "The PDP-11 was designed for ease of manufacture by semiskilled labor. The dimensions of its pieces were relatively non-critical."

What can it do: Yet another device emulator?

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

So QBone *is* a device emulator. There are already some projects on the web, so QBone has to be different:

QBUS controller cards that interface to any modern standard are rare and expensive, albeit not as rare as UNIBUs cards.  A QBUS SCSI card or ethernet card will often cost several $100s. With QBone, in time a variety of devices could be emulated.

QBone is designed to substitute any part of a PDP-11, this includes backplanes or power supplies.

QBone is also a platform for hardware & software development. You can can build hardware extensions and control  htem over QBUS.

When using QBone as diagnostic tool, it mates well with the signal adapter "QProbe".

Other use cases include

Dynamic discussion at the Google group.


QBone can be seen in action here, it's used to emulate memory and provides 50Hz LTC on EVENT line:


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 LSI11/03, PDP-11/23 and PDP-11/73.


Programmers play ground!

Since the volume of possible device emulations and test applications is too much to develop for one person (at least: for me!), QBone 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. And every generation adds more GHz, cores, and RAM. But all this is of no big value for QBone, 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 advantages over an "ARM + FPGA" solution:

Linux and real time

QBone has to react on QBUS 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 QBUS 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.

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