QBone

Details

Written by: Administrator

Parent Category: Projects

Category: QBone

Here are some hints how to build a QBone and test it.

Prepare the BeagleBone's SDcard

Generation

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
joerg@vmubuprog:~$

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:

1. SMDs are presoldered. CPLDs come preprogrammed.
2. flat parts: SIL sockets.
3. medium high parts: capacitors, IC sockets, switches and the relay.
4. high parts: pin headers. Only a minimal subset of all the pinheaders is necessary for normal operation, the others are debugging.
5. LEDs. Anode left toward the "QBone" label.
6. 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.
7. 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 ...

Details

Written by: Administrator

Parent Category: Projects

Category: QBone

If you received a QBone hardware or build your own one, you should check wether it functions correctly.

Prerequisites

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.

 

Power-ON

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 

Password: root

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.

 

RS232 ports

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:

./update-codes.sh
./update-files.sh

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.

Preparation:

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

Details

Written by: Administrator

Parent Category: Projects

Category: QBone

Here some info how to get QBone running after unpacking.

Which slot?

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.

Terminators

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.

On-board jumpers

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.

Some values:

Backplane	QBone position	CD GRANT jumpers
H9270	any slot	closed
H9275	any slot	closed
H9276	any slot	open
H9278	slots 1-3	open
H9278	slots 4-8	closed

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

Test/factory jumpers

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.

BeagleBone operation

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.

Autostart

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.

Addr width	Last word address	Start of IOpage	CPUs
16	177776	160000	LSI11/03 M7264 LSI11/2 M7270
18	777776	760000	11/23 M8186 "A" 11/23+ M8189
22	17777776	17760000	11/53 M7554 11/73 M8192, M8190 11/93 M8981

 

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.

H9270	H9275
H9276	H9278

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!

 

Details

Written by: Administrator

Parent Category: Projects

Category: QBone

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

 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 €300. The BeagleBoneBlack is extra, day to day prices are about €70. 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+ :

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
• RK11/RK05 subsystem (thanks to Josh Dersch) *
• MSCP disk subsystem (thanks to Josh Dersch) *
• 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.

(* means: does not pass all DEC diagnostics, but verified by user experience)

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:

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:

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