Introduction

When I was designing the PDP‑11/Hack I started with just the CPU board and some SLUs. The SLUs were old style adapters using some simple interface logic and a UART.

This was fine for simple systems but then I wanted to add all those functions that would turn the simple system into a “real” PDP‑11. Already the most basic features like a clock interrupt (BEVNT) or a boot ROM required a lot of glue logic and in the case of the ROM it required programmable storage with a 16‑bit interface. With 16‑bit interface I mean, the PDP‑11 reads the ROM in 16-bit words, so either the ROM had to be 16‑bit wide or I had to read multiple words from the ROM and assemble them to a 16‑bit word, like the boot ROM of a PDP-11/44 which consisted of 512x4bit bipolar PROM.

In addition I was planning to build a “disk controller” which was compatible with an existing disk controller for the PDP-11 and it was clear that I also needed some software in order to be able to translate read and write requests to reads and writes on an external storage.

I needed to save real‑estate on my PCBs as I wanted all those interface cards to be no larger than 100 x 100mm. At the time I was starting with the system larger PCBs were rather expensive and I planned the project to be within certain budget limits.

Traditionally PDP‑11 Q‑Bus interface adapters have been a “grave yard” of zillions of TTL logic, some interfaces even required multiple boards (e.g. RLV11). But later Q‑Bus adapters appeared that were using some sort of microcontroller. Either real microcontrollers like the 8051 or bit-slice processor designs based on the AM2901 family. The result of this was that these controllers fit on a relatively small dual-width Q‑Bus board. DEC was even using a PDP‑11 to build PDP‑11 controllers using the T‑11.

My consideration was that when a fully functional SCSI controller, like the UC07, can be built with just using a 8051 then it should be possible to build any controller by using my preferred microcontrollers, the now Microchip 8-bit AVR controllers, which are much faster and have more features.

Q-Bridge

Therefore I was looking into a solution to interface the Q-Bus with a microcontroller to be able to use the rich features and IO capabilities of microcontrollers to build IO cards for the PDP-11.

I have named the project Q‑Bridge. In the meantime several versions exist and with every interface card I have introduced enhancements, corrections, simplifications or modifications. However the basic concepts have not changed and as it is used in almost all of my projects I decided to give a detailed overview of the design.

For my PDP‑11/Hack the complete logic, including bus interface, actually fits in a single ATF108 CPLD. Later when I transferred the design to the real Q-Bus only minor changes of the interface logic were required as I used the real Q-Bus protocol on the system bus of my PDP‑11/Hack. Only the direct bus interface had to be modified as I had to add Q-Bus receivers and transmitters to interface with the real Q-Bus signal levels.

Note: Q-Bridge is a concept with many variations, in fact each controller I have built so far for the Q‑bus or the PDP‑11/Hack uses a different version but the basic idea is always the same.

Functions

Like a real PDP-11 interface card the Q-Bridge implements the following features

Device Registers

The Q-Bridge decodes access to the IO page of the PDP-11 and when the address matches device register addresses it will inform the microcontroller using an external interrupt of the microcontroller. The PDP-11 has no special IO instructions so this is the same as supporting DATI and DATO/DATOB cycles.

PDP-11 Interrupts

Another function of the Q-Bridge is the ability to rise an interrupt on the Q-Bus and provide a vector during the interrupt acknowledge cycle.

DMA

The last feature is the ability to perform DMA. The Q-Bridge includes several functions to support the microcontroller to perform DMA to and from the PDP-11 memory. The Q-Bridge handles bus arbitration and has a set of handshaking signals for the data transfer phase of the DMA. Ultimately I have made a complete redesign of the interface between the MCU and the CPLD and for the newest Q‑bus card, the RLV12 Emulator V2.0, I have even added a second CPLD. The additional CPLD added the resources for a DMA data register and now DMA is completely handled within the CPLD.