"QBone" is a Linux-to-QBUS bridge, implemented with a BeagleBone Black micro Linux system.
QBone can keep old PDP-11s running, by emulating devices and aiding in repair.
It's UNIBUS sister is UniBone. These pages here do not repeat the general introduction or theory of function, so be sure to dig into UniBone documentation too.
Dynamic discussion at the Google group.
QBone,UniBone - Alternative Bus Drivers
QBone with multiple driver options
UNIBUS and QBUS signals lines are terminated with resistor pairs of about 200/400 ohms, resulting in a quite low impedance. Normal TTL gates can neither drive this load, nor have the proper input thresholds.
These low-impedance busses allow routing over far distances ... but it was surely a design before "energy-awareness". Driving the bus alone requires several watts, burned-out bus drivers chips are a common reason for a dead PDP-11s.
DEC specs require special line-driver and -receiver chips, among them the DS8641, which is used on UniBone and QBone.
However, DS8641 chips (or its compatibles, as "DL8641" or the russian "КР559ИП3") are harder and harder to acquire. So time to look for alternatives.
An often mentioned replacement for the DS8641 is the AM26S10: it is designed to drive/receive similar bus lines as UNIBUS/QBUS, and contains also 4 transmitter/receiver pairs. However the pinout is different.
Thats the reason for new QBone version 2023-04 with parallel sockets for DS8641 and also AM26S10:
A pin-compatible variant of AM26S10 is the 75138 driver. As the AM26S10, it's not fully electrically compatible to the DS8641. Their datasheets differ in the switching speed for example: DS8641: 30ns. 75138: 20ns. AM26S10: 10ns.
The usual rule "faster is better" does not apply here: beside different receiver voltage thresholds, faster switching can produce more signal noise, so called "ringing".
In theory the 75138 is the better choice, as its specs are closer to DS8641. The AM26S10 however is still available today (2023, mouser.com) as DIP and SMD case.
These chips can even be mixed freely on the board ... you won't do that.
Whats the problem with those almost-compatible drivers? It's all digital, right?
Clearly AM26S10 and 75138 have different specs than DS8641 ... a bit.
UNIBUS/QBUS Bus signals have switching times of a few 100ns, with sharp switching edges we reach frequencies near or above 100MHz.
So all this weird high-speed electronic black magic starts to apply, as explained in that classic
For instance signal pulses are reflected at cable ends, if the resistors there do not meet the impedance of the drivers.
Reflection results in "Ringing", which is an awful effect: a clean pulse generated by a transmitter can be received as multiple pulses on the receiver side.
("receiver" can also be a scope or logic analyzer probe ... see UniProbe/QProbe discussion).
Imagine multiple pulses on the QBUS ADDR/DATA demux BSYNC line: Address lines on BDAL are latched with BSYNC, a bouncing BSYNC could latch invalid bus noise again, overwriting valid addresses latched before.
DEC addresses ringing in their UNIBUS Troubleshooting user's manual .
Field engineers are advised to measure and suppress ringing by means of different-length backplane connector cables ... hidden in M9202 backplane jumper.
Thats why there are several M9202s with different amount of cable inside.
From these DEC pictures it's also clear why the "input threshold" is important: these signals are not "all digital". The exact properties of UNIBUS/QBUS drivers *matter*. So where can non-DEC drivers be used?
Different use of UNIBUS / QBUS
UNIBUS and QBUS have very similar electrical specs and use the same DS8641 drivers. However both busses are used in different environments.
For a UNIBUS PDP-11 its normal to span multiple backplanes, multiple boxes and often multiple racks ... see here.
Even hobbyists have such setups: For example for tape drives like TU56 DECtape or TU10, the tape controller build into the drive rack, so the white UNIBUS BC11 cable runs between several racks. All the ringing and impedance stuff matters over these long distances and multiple plugs. Thats why UNIBUS is designed asynchronically and with elaborate electrical and timing behaviour.
While QBUS specs allow the same cabling, a typical QBUS system is much more compact, occupying usually only one single backplane.
Personally I've never seen a PDP-11/03/23/73 or uVAX with even two backplanes ... not to mention spanning multiple racks.
So QBUS signal traces are short, impedance failures do not matter much. DEC delivers small QBUS systems not even with the bus-end-terminator build in.
Alternate bus drivers surely can be used on small UNIBUS and certainly on QBUS systems ... as our test have shown.
To be on the save side, use only DS8641 chips for UNIBUS systems with BC11 cables.
QBone - Building
Here are some hints how to build a QBone and test it.
Prepare the BeagleBone's SDcard
Normally you receive a programmed SDcard with the QBone kit. To make a backup of it, G**gle for "clone SDcard" and follow instructions.
The "clone" consists of reading the given SDcard into an image file, then writing that file to a new card.
On Windows 10 I use "win32diskimager" for convenience.
Under Linuxes its a more complicated call to "dd". Example run for writing an SDcard from a zipped image file "qbone_sdcard_2018_11_21.dd.gz":
1. Plug a new sdcard of at least 16GB into your card reader. After recognition the desktop file explorer may pop-up some window.
2. Determine the Linux SDcard device:
joerg@vmubuprog:~$ dmesg | tail
[ 45.200662] usbcore: registered new interface driver usb-storage
[ 45.204700] usbcore: registered new interface driver uas
[ 46.199822] scsi 33:0:0:0: Direct-Access Generic STORAGE DEVICE 0903 PQ: 0 ANSI: 6
[ 46.201107] sd 33:0:0:0: Attached scsi generic sg2 type 0
[ 46.482076] sd 33:0:0:0: [sdb] 62521344 512-byte logical blocks: (32.0 GB/29.8 GiB)
[ 46.488105] sd 33:0:0:0: [sdb] Write Protect is off
[ 46.488108] sd 33:0:0:0: [sdb] Mode Sense: 21 00 00 00
[ 46.494056] sd 33:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 46.524458] sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 >
[ 46.544925] sd 33:0:0:0: [sdb] Attached SCSI removable disk
The output above means that the raw SDcard is "/dev/sdb"
3. To write the zipped image onto the card type something like:
joerg@vmubuprog# sudo -s
[sudo] password for joerg:
root@vmubuprog# gunzip <qbone_sdcard_2018_11_21.dd.gz | time dd of=/dev/sdb bs=1M
13+360271 Datensaetze ein
13+360271 Datensaetze aus
15931539456 Bytes (16 GB) kopiert, 828,463 s, 19,2 MB/s
0.00user 9.66system 13:48.46elapsed 1%CPU (0avgtext+0avgdata 3232maxresident)k
200inputs+31116288outputs (1major+350minor)pagefaults 0swaps
This make take some time.
Hostname on SDcard
Typically the BBB is accessed via Ethernet and will appear in your home network under its "hostname".
The initial network name of the BBB is "qbone". If you use multiple QBones, each must get a different name. The hostname is found on the SDcard filesystem at /etc/hostname. You can edit this only the Ubuntu host: re-plugin the SDcard, navigate to /media/<something>/etc, do a "sudo nano hostname".
Login later with "root/root".
Be aware that you can not boot from the SDcard until BBB is plugged into QBone board!
Populate the board
The populated board looks like this (click to enlarge):
Solder best in that order:
- SMDs are presoldered. CPLDs come preprogrammed.
- flat parts: SIL sockets.
- medium high parts: capacitors, IC sockets, switches and the relay.
- high parts: pin headers. Only a minimal subset of all the pinheaders is necessary for normal operation, the others are debugging.
- LEDs. Anode left toward the "QBone" label.
- Plug ICs and resistor packc into their sockets. Resistor values printed onto the board may not be valid! Make the 0-Ohm restisor pack yourself with help of the special IC-socket pinheader.
- Make BBB adapter, see below
Mount BBB onto PCB
Two special parts are used to fit the BeagleBone vertically into a DEC card space:
- little spacer PCBs
- pinheaders in reduced high
Soldering reduced pinheaders onto spacer PCBs
The pin headers have plastic strips, you get them pushed to one end. The trick is to use the BeagleBone itself as soldering template:
Mounting the spacer PCBs
The little spacer PCBs sit pickyback on the main PCB. The trick here is to align them and solder through both PCBs at once. This is suprisingly easy, at least if you fill the metalized PCB holes with flux. Align the two stacked PCBs with the BBB and temporarily pinheaders.
Just remember to use double length of solder and heat more than the double time.
Cave at: Sometimes your solder may not flow through both PCB layers, resulting in an open contact.
When that happens: do not resolder from the clean side .
Always resolder from the side you worked on already, suck off the old solder if necessary.
If you try to close the bad junction from both sides
- you loose visible control of the junction
- you may get two solder blobs not contacting each other. Or worse: only contacting sometimes !
If you don't feel the need to use a circuit beeper, then you're doing right.
Now continue with tests ...
QBone - Acceptance Test
If you received a QBone hardware or build your own one, you should check wether it functions correctly.
Even if you just like to play with the BBB alone, it must be plugged into QBone to boot from SDcard. Else it will boot another Debian installation from the internal eMMC chip.
For non-QBUS tests QBone can be operated standalone. Power needs are +5V, to connect use pins of the four power capacitors or "+5V UB" pin header. Attention: If you use the BeagleBone +5V jack, parts of the circuit are unpowered, as the relay will not close.
Do perform the non-trivial QBUS/PRU tests, QBone must be placed into in an empty, terminated QBUS backplane (yes, this is a challenge). All types of QBUS "quad" backplanes work.
On some backplanes one QBUS terminator is needed, but it must be passive: No Boot ROM.
The good news: Only +5V are required, no G9047 grant continuity cards are needed.
Plug BBB into QBone PCB, connect +5V to the auxillary QBus power plugs on the QBone PCB.
The power relay must switch after 1 second delay. BBB produces 3.3V supply then and the green LED goes ON.
Program both CPLDs
QBone PCBs come with already programmed CPLDs, so no need to do anything here.
If you build QBone on your own, you need to download CPLD code with Lattice Diamond software and a programming adapter, which is not covered here.
Test boot and network access
Wire BBB via Ethernet to your home network. BBB will talk to your DHCP server. WLAN operation is possible, but not covered here.
Use an ssh client like "PuTTY" to login.
After Power-ON the blue LEDs on the BBB begin to flicker, as the Debian Linux is booting. After 30-90 seconds you can try to login via network.
The default hostname is "qbone", but may change.
joerg@vmubuprog:~$ ssh root@qbone
Have fun with QBone!
Last login: Fri Dec 14 15:28:24 2020
If BBB running, but you get no ssh access to qbone:
- BBB must be plugged into PCB to boot from external SDcard. Else it may boot another OS from its internal eMMC chip.
- "yellow" and "green" network LED active?
- hostname entry on SDcard? (/etc/hostname)
- use RS232 serial login over UART as backup
Also try repowering QBone. There's a known bug in the BBB's Ethernet interface, which seldom prevents network communication sometimes ... never fixed.
QBone exposes two serial RS232 ports. They are configured for regular Linux login sessions or PDP-11 serial port emulation.
Typical UART1 is always for Linux, UART2 maybe configured for the emulation.
To connect to the BBB via RS232, you need to crimp a simple cable:
This pinout is NOT the one you find on PC-mainboard adapters!
See here for a product and docs, only GND, TXD and RXD are connected.
Connect the male DSUB-9 connector to your PC with a null-modem cable and start a terminal emulator with 9600 baud, no hardware hand-shaking.
You should see another Debian shell prompt both on UART1 (and UART2) connector.
Logging in via RS232 may be useful if the Ethernet-bug occurs too often on your BBB.
BeagleBone Debian Linux operation
Here we put a heavy load onto BBB's network, CPU, main memory, and SDcard. This verifies BBB has a full featured Debian installation.
Login via ssh, then update program code and emulation images:
Also play with the "mc" Midnight commander.
Test remote file access to BBB via sftp. Best with a graphical client (example: winscp under Win10, filezilla).
The manual system is working: "man man".
EEPROM, board pin config and I²C
Optionally, there's a small EEPROM, accessed over I²C bus. As the QBone PCB is a "cape" for the BBB, it needs the EEPROM to read out the board name. Then the Linux kernel should activate the correct configuration file to setup port pins of the Sitara CPU correctly. A kernel component named "cape manager" should do this ... it may or may not work in the Debian kernel in use. Doesn't matter. Sigh.
Read the EEPROM:
# hexdump -C /sys/bus/i2c/devices/i2c-2/2-0054/eeprom
Program the EEPROM:
# cat cape.eeprom >/sys/bus/i2c/devices/i2c-2/2-0054/eeprom
Check the EEPROM content:
# hexdump -C /sys/bus/i2c/devices/i2c-2/2-0054/eeprom
Reboot, login again, test wether the correct board configuration is loaded:
root@unibone2:~# cat /sys/devices/platform/bone_capemgr/slots
0: P----- -1 UniBone,00B0,Hoppe,UniBone
1: PF---- -1
2: PF---- -1
3: PF---- -1
4: P-O-L- 0 Override Board Name,00B0,Override Manuf,UniBone
With that test also the I²C interface for add-on panels is tested.
Testing standard GPIOs
The important part of QBone is the PRU controlled interface to the QBUS. But the user LEDs and switches are traditional GPIOs.
Test with the "demo" application, main menu point "TG" for "GPIO", then "LB" for "manual loopback".
In loopback mode, the 4 switches control the four LEDs: toggle them and the LEDs should respond. Pressing the button will enable the DS8641 driver array, resulting in active 2nd green LED.
PRUs and QBUS interface
The real important test is access to the QBUS. Signals are output through the CPLDs and 8641 drivers onto QBUS data lines, then read back through drivers, CPLDs and PRU pins. This tests also terminators and parts of the QBUS backplane.
- Put QBone into an empty QBUS backplane.
Some backplanes have terminators already onboard, else:
Add a terminator to QBUS lines (QProbe or M9400 REV11 with resistors only, no logic!)
- set loopback jumpers onto the IAKI-IAKO and DMGI-DMGO lines (yellow in the image below). Remove these after test!
Use again the "demo" application, main menu "TL" for "test bus latches", then ">>> * r" to test all QBUS signals endlessly with random patterns.
Run this test as long as possible, and terminate with ^C. My most likely reason for errors are QBUS setup errors, then mis-inserted 8641 drivers (not kidding). You also may have open solder joints, or shortcuts between pins. To help in debugging, the test software prints the signal path for failed bits.
To "test the test", you can remove one of the yellow loopback jumpers while the test is running. It should stop with an error.
Its a good idea to bend and knock the board a bit while under test: this may expose bad solder joints.
Pro tip: As the QBUS lines need pullup by terminators, this test can be used to check a big part of your backplane: plug in only a single terminator at either end, QBone to different slots of the backplane and run this test. It will fail, if any of the 44 signals has no connection to the remote terminator. You even can test QBUS cables between separate backplanes this way.
And don't forget to remove the loopback jumpers on IAK* and DMG* after test!
Finally: run it in a PDP-11
If all went well, plug QBone into a PDP-11.or boot operationg systems from emulated RL02.
QBone - Installation
Here some info how to get QBone running after unpacking.
Well, QBUS is less complicated than UNIBUS: QBone can be put into any quad QBUS slot.
Just be sure to close empty QBUS slots between CPU and the last used slot with G9047 GRANT continuity cards. Not all slots are QBUS slots, and slot order is not trivial, see "Backplane geometry" below.
Attention: possible short cuts
As the BeagleBone is a bit too fat, some of its parts may touch the solder side of a module sitting over it.
Either push thin card board between the modules, or mount QBone below an empty slot, filled with a G9047 GRANT then.
Single-backplane QBUS systems (I've never seen other ones!) do not need a terminator pack at bus-end, as DEC CPUs always terminate the bus.
For multi-backplane systems there's some alchemy where to use additional terminators and whether to use 120 or 240 terminators on the other bus end.
Some backplane even have resistor packs soldered on.
QBone has no onboard-terminators: If QBone replaces the CPU in a QBUS system (such as for self test), you need additional terminator packs.
QBUS comes in different variants, and QBone can be plugged into different backplanes. There are some jumpers to verify:
Click to enlarge
Setting up QBUS address width
QBUS systems may use 16, 18 or 22 bit width addresses. The address width of a QBUS system is primarily determined by the CPU in use, QBone has no means to guess it from bus traffic.
So two settings are necessary.
- If using an LSI11/03 system, remove the "DAL<21:18>" jumpers, as these lines carry special CPU-internal signals.
- Call the "demo" application and the prepared *.sh script with command line option "-aw 16", "-aw 18" or "-aw 22"
These settings determine how much memory QBone emulates and for which addresses it activates the "BS7" IO page signal.
Closing C/D GRANT continuity
QBUS IRQ and DMA GRANT signals are daisy-chained from slot to slot. Insert the "CD GRANT" jumpers, if the C/D fingers of QBone are plugged into a socket which carries a standard QBUS.
|CD GRANT jumpers
Check backplane geometries below.
If the CD GRANT jumpers are not closed correctly, controllers plugged behind QBone will not work when doing Interrupts or DMA.
Generating 50Hz clock on EVNT
DEC power supplies generate a 50/60 Hz square wave signal on the EVNT bus line. If you use another power option, and still need the LTC signal, then close jumper "EVNT 50Hz".
The "IRQ/DMA GRANT" jumper block can disconnect the IAKI/IAKO/DMGI/DMGO lines from QBone, or short-cut them for self test.
A selectable "EEPROM ADDR" is required for BeagleBone "Capes" ... their name for plug-on boards. A guy from beaglebord.org once called UniBone "the biggest cape ever".
Leave these jumpers in their factory-position.
You access the BBB software via login to a Linux terminal session as root/root. Best you plug BBB via Ethernet to your home network, your DHCP server will assign the name "qbone" or alike ... that depends on the text in /etc/hostname. Or you login via serial port on UART1, use a null-modem cable to your PC.
After applying +5V to QBUS power, BeagleBoneBlack receives +5V power approx. 1 second delayed by the onboard relay. This delay should be enough to give BBBs reset circuitry a clean "power-on" signal, despite the vintage PDP-11 power supply may come up quite unexpected. +3.3V power is generated on BBB and indicated by the green power-LED.
Then BBB is booting Debian, which takes much too long... in worst case over 1 minute! Some Linux guru should improve this.
You also can power BBB over its front jack, even when plugged into a unpowered PDP-11. The relay will not close then and isolate BBB's +5V from the huge PDP-11. Don't use local BBB power when the PDP-11 is ON, two power sources working against each other may overload the relay contacts.
Login via ssh or UART then, "putty" is a good Win10/Linux host terminal emulator. Additional you may ftp to the BBB, best with a graphical client like WinSCP. You will use file access often when dumping own disk images to the disk emulators.
On power-down you may use a clean "shutdown +0" before. But that's not necessary, Debian has a crash-save journaled file system.
If you want to restart the BBB, don't powercycle the whole PDP-11, use the reset button instead.
When using alternate SDcards, get the best you can. Unlike in smartphones or cameras, the SDcard is in use by Debian all the time, speed and reliability are crucial here.
Ready-to-run shell scripts
In the SDcards main "/root" directory you'll find a couple of executable shell scripts. These usually start the "demo" software with control files to emulate several QBUS devices.
Be sure to always add the "address width" option "-aw" ... see above and below.
QBone can be configured to start one of the emulation-shell-scripts automatically on power-on. Up to 15 script can be prepared, selection is via DIP switch settings and feedback after emulation start via LED codes.
See file "/root/autostart.sh" for details.
Be sure to leave all switches in the upper "OFF" position at first.
You can connect to an already auto-started session after login via ssh.
Background info: QBone on QBUS
First: I owe so much to the QBUS information page! Thank you!
QBUS 16, 18, 22 ?
DEC UNIBUS has a fixed address width of 18 bit, allowing addresses 0..777776 or 256KB. Bigger UNIBUS-CPUs (11/44, 11/70) with 22 bit address width (4MB range) must use separate enhanced memory busses.
In contrast, QBUS was designed to work with 16 bit (64KB), 18 bit (256KB) and 22bit (4MB) address width. Address lines are multiplexed with 16-bit data on the QBUS "DAL" lines. On later MicroVAXes with memory sizes > 4MB, again local memory busses are used.
This flexibility is mostly hidden in CPU logic, IO device get the IOpage (upper 8KB) addressed with a special "IOPage" address line, named "BS7" ("bank 7 select").
QBone acts as bus master (CPU or DMA device) and slave (memory or device register) and has to deal with additional complexity.
The number of address lines in use requires attention on several places. Pluggin together a non-standard system requires major research!
CPU: the CPU has to generate a proper BS7 signal for the upper 8KB page of the address range in use.
The LSI11/03 M7264 and 11/2 are 16bit, 11/23 with F-11 is 18 bit, 11/23+ and J11 based 11/53, 73, 93 are 22 bit.
The LSI11's use backplane address lines DAL<21:18> for other signals. DAL<17,16> are always terminated properly and just not used on 16bit systems.
|Last word address
|Start of IOpage
|11/23 M8186 "A"
11/73 M8192, M8190
Backplane: the backplane must carry the required address lines between CPU and memory or IO device.
As far as I know all backplanes are at least 18 bit capable, meaning DAL<17:0> is always wired correctly.
The LSI11 backplane H9270 can be wired to carry DAL<21:18> too, allowing 4MB machines (23+, J11's) to run in this handsome 4*4 slot cage. Several web pages know how to do it.
Furthermore, backplanes differ in their slot order ("zig-zag"!) and number of special C/D" slots.
Passive IO device (memory or device): must only respond to address lines in use, must ignore unused upper address lines.
Active DMA device: must generate proper BS7 IOpage signals for addresses in IOPage.
Some devices have QBUS18/22 jumper (for example RLV12 RL disk controller). Others work only on 16/18 bit busses, for example DRV11-B M7950 has only 16 address lines.
Backplane geometries: AB, CD, zig-zag
There are several types of QBUS backplanes. The good news: All use the rows A&B for QBUS.
Use of C&D rows differs: sometimes they also contains QBUS, sometimes all C&D slots are connect to a separate bus, sometimes C&D are a separate bus with some kind of "daisy-chain" logic.
There is only one rule: If QBone's C&D slots also go into a QBUS slot (not a special C&D), then set the GRANT continuity jumpers JP7 and JP8.
EVNT and the 50/60Hz Line Time Clock signal
QBUS has a signal EVNT, which causes an unconditional CPU trap (like powerfail). Its mostly used to implement a software clock (LTC= Line Time Clock), DEC power supplies generate a 50 or 60Hz square wave here.
If you have a non-DEC power supply (providing +5/+12V is not SUCH a challenge), you need to generate LTC on yourself. QBone has a 50Hz source, just set jumper JP9 to route it to QBUS EVNT, and that's it.
That's it? Just kidding!
LTC/EVNT can be produced by more than source:
- the power supply,
- peripheral cards like BDV11 M8012, which has a software register to switch LTC EVNT generation by programs.
- QBone via jumper
You may have only ONE LTC source in the system!
LTC use by the CPU is also complex:
- LTC EVNT signal use can be inhibit via a front panel switch "AUX ON/OFF" on some cases (BA-23S, 11/23), which tie EVNT to ground. On other cases, "AUX ON/OFF" is main power.
- LTC EVNT trap can be disabled for some CPUs by setting or opening a wire wrap jumper (LSI11, 11/23)
- LTC EVNT trap can be disabled for some CPUs (11/23+, J11) via a software register. And even the presence of this register can be configured (on KDJ11-E 11/93). AND this can be combined with a hardware jumper.
Do you need 50Hz EVNT? It depends.
- UNIXes need a LTC signal, they will not boot if it's missing.
- Some DEC OSses need lTC too. At least RSX11M and M+ needs it for task scheduling.
- Other OS are less sensible. For example RT11 needs it for the system time-of-day.
- If LTC is enabled (present on EVNT and enabled in CPU), the system needs a trap handler at vector 100, else it will crash.
Bottom line: Good luck!
QBone - Introduction
"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").
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 €180, the ready build and tested is €280. The BeagleBoneBlack is extra. Contact me via
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+ :
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:
- QBone is configurable, allowing to emulate arbitrary devices in parallel up to a full PDP-11 system. See the article on "Frankenstein-PDPs".
- instead of emulating just a disk or floppy drive connected to a DEC controller card, it emulates device & controllers together at the QBUS level.
- media images for simulated storage devices (disk or tape) are SimH compatible Linux files and can be exchange via FTP ... no SDcard plugging.
- simulated devices can have their own physical "lamps & switches" panels.
- simulated memory can be monitored while the PDP-11 is running. Memory can be pre-filled or saved, so its like core.
- having a full Linux behind allows even to run SimH or complex diagnostic software on real hardware, beside all the other benefits.
- Hardware should be simple enough for a "do it yourself" kit: low-cost and low-tech.
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.
- One application is to plug QBOne in an empty backplane together with single DEC cards to test....a QBUS test bench. You can provide own power to feed the backplane.
- You can operate QBone even if the enclosing PDP-11 is switched off: a relay separates it from main PDP-11 +5V power.
- a delayed "power-on" protects QBone, until the old DEC power supply delivers steady voltage.
- the QBUS interface has all signals and power pins routed out. You can design own bus adapters for non-DEC backplanes (examples are Eastern-Europe PDP clones).
QBone is also a platform for hardware & software development. You can can build hardware extensions and control htem over QBUS.
- the BeagleBone is full of interfaces (GPIOs, I²C, SPI, A/D,...), its pinheaders P8 and P9 have solder points and are labeled.
- a powered I²C bus is routed out, for frontpanel replicas or own projects.
- bread board areas to mount own electronics, provded with GND, 3.3V and 5V power points.
- All programming is done in C/C++ .
- QBone can compile its own software, it is its own development tool.
- testpoints on the board can be accesses under program control, to synchronize C++ program flow with logic analyzer pictures.
When using QBone as diagnostic tool, it mates well with the signal adapter "QProbe".
Other use cases include
- monitor or trace QBUS traffic (record the bus traffic). This replaces a 42+ channel logic analyzers when tracing the PDP-11 instruction stream.
- stimulate standalone QBUS devices, for test or to dump disk/tape media.
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
- rebuild own DEC devices you never could acquire. For example the VC11 video controller ... for Moon Lander.
- access physical QBUS devices from within SimH.
- couple PDP-11s by shared memory emulation over internet.
Whats really there now?
All vaporware and marketing speech aside: At the moment we have
- stable hardware
- a memory emulator (4MB on QBUS22)
- RL11 controller with 4 RL01/02 disk drives and console panel
- the RXV11 controller with dual RX01 floppy drive
- the RXV21 controller with dual RX02 floppy drive
- to be verified: RK11/RK05 subsystem (thanks to Josh Dersch)
- to be verified: MSCP disk subsystem (thanks to Josh Dersch)
- to be verified: serial DL11-W interface with KW11 clock
- a front-end processor for the PDP-11
- a QBUS hardware test adapter.
- a "demo" device for QBUS access to the board's LEDs and switches.
- a selftest tool.
- several ready-to-run configurations for XXDP,RT11,RSX11M operating systems.
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".
- 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++.
- Software is public at https://github.com/j-hoppe/QUniBone
- The gcc-compiler for the ARM processor and the "clpru" compiler for the PRUs run on the BBB itself, so QBone is its own development platform!
- 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 QBUS control. There's even a small "hello world" QBUS 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. 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:
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:
- It's a cheap and complete Linux platform with community support.
- In contrast to FPGA developer boards, BBBs should be available for years.
- small enough to fit into DECs Flip-Chip slots.
- the PRU processors are already there for free;
- all the highspeed signal stuff is already solved on the BeagleBone;
- PRU integration into ARM Linux is excellent (shared memory with 200MB/sec bandwidth);
- 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.
- the whole project can be compiled on the BeagleBone itself. Then it needs 4 minutes.
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.