2.11BSD is working now too. I tested it by, among other things,
compiling two kernels simultaneously. It seems pretty solid with
only one active drive.
I finally got back to this project and have RT11 working. Updated PLD files and MACRO-11 sources
can be found below.
There is a lot of discussion on the info-pdp11 mailing
list about a qbus disk controller.
My project seems to come up from time to time.
First, take anything you want.
All the info I have should be here and up to date.
Feel free to contact me if you have any questions.
It is not fully functional.
I believe that there might be a flaw in the interrupt
handling section of the PLD design or a bug in the BSD 2.11 driver.
If RX01 is your thing, I have also worked on an emulator
for use with a QBus or OMNIBUS interface.
It uses a parallel port on a PC running Linux in place a real
RX01 or RX02 drive unit.
Not all there, but a pretty good start.
It will boot RT11 using the RX driver (sometimes, software is just too slow).
It will boot OS/8 using the RX01 handlers,
but does not work with the RXO2 handler,
or the RX01/RX02 universal handler.
(Look at RX02 Emulator.)
Lets say this project is not dead,
just very dormant.
I had the fortune to come upon a
QBus SCSI controller and a QBus DSSI
controller and so the priority
I think the original design is
still viable even without the addition
of DMA, etc.
A disk crash set me back,
losing my latest driver source.
Lack of time prevents me from building a prototype
based on the new DMA design.
A volunteer worked on the NetBSD driver
for the EIDE Adapter.
11 January 2002
Got a copy of the chipkit users manual
which describes the LSI-11 Bus Interface Chips
10 January 2002
Made some updates to the web page.
Since I posted to various lists and newsgroups,
I have received quite a bit of attention.
Thanks to all the comments and suggestions.
1 January 2002
Posted description of project to NetBSD/vax
mailing list. Many interesting responses.
I have been reading discussions about Qbus to
IDE disk adapters for some time.
The only published attempt that I know of
was from the Ukraine and
was based on SSI- and MSI-TTL and some Russian components.
here. The link might be broken.)
Having reviewed what was available,
this is my own attempt...
Design of a Q22-Bus - ATA Disk Adapter
The Q22-Bus is an asynchronous, open-collector system bus,
used for memory and I/O on DEC microPDP-11 processors and
I/O on some VAX processors.
ATA means AT Attachment and the IDE disk interface is
basically an extension of the IBM PC/AT ISA bus,
at least for ATA-2.
Later revisions introduce features to enhance
are generally of no use to the Qbus.
The adapter design is simple and obvious:
a buffer between the two buses with the control
logic necessary to satisfy both sides.
Several National DS8838 Bus Transceivers attach directly to
the Q22-Bus BDAL lines.
Each transceiver section has 3 ports:
a bus port connected to the Q22-Bus,
a gatable input port
connected to adapter Bus B,
and an output port connected to adapter Bus A.
Two 74ALS244 Tri-State Buffers join adapter Bus A to
tri-state adapter Bus B,
effectively gating the Q22-Bus BDAL lines to adapter Bus B.
The transceivers and tri-state buffers taken together
form a interface between the open-collector Q22-Bus
and the tri-state adapter Bus B.
Two signals, QBRL and QBWL, control the direction.
Bus B is connected to the IDE drive data lines and to
an Atmel ATF1508 CPLD which implements the bus protocol logic.
Additional Q22-Bus and IDE drive control signals are
connected to the CPLD through transceivers or directly.
A block diagram is found at the top of this
From the programmers point of view,
the adapter and drive appear as a 32-byte block in
the Qbus I/O page.
I chose address 17771000 because the Ukranian design
It is probably not the best.
The DMA related registers and the reserved address space
respond as memory,
but does nothing more.
Adapter Control Register
DMA Address Register (not implemented)
DMA Count Register (not implemented)
Interrupt Vector Register
Alternate Disk Status Register
Disk Control Register
Disk Data Register
Disk Error Register
Disk Precompensation/Feature Register
Sector Count Register
Low Byte of Cylinder Register
High Byte of Cylinder Register
Disk and Head Select Register
Disk Command Register
Disk Status Register
The base address is fixed in the CPLD at 17771000.
This was for simplicity and a set of base address
select jumpers is planned for.
The interrupt vector is programmable through software.
There has been some discussion that the Unibus and Qbus precede
every write cycle by an implicit read cycle of the same address.
This has relevance for the ATA interface because some
of the registers have different functions when read than when written,
and even more, reading certain status registers will clear status bits.
If there are hidden reads, some information could be lost.
Further, in PIO mode writing the data register 256 times fills the
sector buffer. Interleaving these writes with 256 reads may confuse
the drive controller. So, it is clear that hidden read cycles would
The question is then, "Is every Unibus or Qbus write preceded by a read?"
It seems to be processor dependent. The PDP-11/20 precedes every memory write (DATO)
by a read pause (DATIP). For device registers a DATIP is equivalent to a DATI.
The T-11 microprocessor definitely does do a read before write.
The T-11 manual is very clear about this and suggests techniques for dealing it when
designing with components such as the 8255.
Some processors implement instructions that would seem to be write only as
An example is CLR dst, which will read the destination, discard the
value read and then write a 0.
The solution is to ensure that reading a register does not have any side effects.
If this is not possible, registers that must be written should be mapped to
different addresses for read and write operations.
If anyone could enlighten me further, I would be interested.
My primary goal was to have a disk capable of storing
a reasonable Unix system.
Starting with the 4.3BSD wd disk driver,
a 2.11BSD driver slowly developed.
Not much of the original code survives,
and a better starting point would have been
the 2.11BSD RA driver.
The driver only supports disks capable of LBA addressing.
This was an arbitrary limitation that will likely be
eliminated as development continues.
Only one drive has been tested,
but there is no reason that two drives could not be
made to work.
The Q Bus like most of the older DEC buses is based
on a 0.125 inch spaced card-edge connector.
This spacing is a bit unusual and prototype boards are
long out of stock.
In a PDP8/e project,
I sacrificed some M113 Flip Chip
modules to the cause, but that seemed wasteful.
the adapter was constructed not as a board within a chassis,
but as a separate "chassis".
Two 50-pin IDC headers were wired as if they were an M9405
Q22 mirror image cable connector.
This got the board out in the open and available for probing
This explains all the resistors.
The end of the Qbus must be properly terminated.
Nothing in the design assumes this, so it could easily be
built on a card with the standard DEC connector.
Prototype construction was done using a solder pad
per hole perf board and point to point wiring.
I like to use #30AWG wire with Kynar insulation
stripped and soldered at each end.
This technique has proven to be very reliable and
fairly efficient for construction.
Take a tour of the board.
PIO vs DMA
Traditionally, PDP-11 disk controllers have used direct
memory access (DMA) for disk I/O.
The Qbus places the burden for DMA on the device controller
Once the device has negotiated control of the bus,
it is responsible for all aspects of the bus protocol.
By contrast, IBM PC compatible disk controllers usually
transfered data using programmed I/O (PIO), moving each
byte (or word) through the processor one at a time,
under program control.
I have plans for DMA, but they have not been tested.
Besides, the PIO performance is very good in comparison
with an MSCP SCSI drive.
Some discussion indicates that the MSCP controller
that I tested against is not the fastest.
IDE vs SCSI
I have received several comments questioning my selection
of IDE over SCSI.
The simple answer is the IDE is simple and SCSI is COMPLEX.
This may be a personal bias, I don't know a whole lot
The second answer is that I have several IDE drives of
various sizes, and NO SCSI drives.
Finally, VERY large IDE drives are now unbelievably cheap.
How long before 1GB = $US1? (Now its about 50¢.)
Not very long I think.
One counter argument is that the cable length is quite short
for IDE drives.
The specs indicate a length of 18 inches maximum.
The IDE specs also comment that this restriction is in
part based on a fear that the cable and drive will be
improperly installed and that they should still perform
so it may be possible to extend this if applied properly.
The Qbus is also quite slow in comparison to the faster
modes of the IDE bus.
The IDE bus may be settled by the time the Qbus needs it.
The point is that many of the objections to IDE may be
engineered away when applied to the Qbus.
The following is a crude summary of the design.
I don't think it is complete.
If anyone is really interested in more information,
I compared the performance of the PIO EIDE disk adapter
with a MSCP SCSI controller (CMD CQD-220).
The system was a KDJ11-B processor with 2MW of QBus
memory (no PMI, not sure if the memory is capable
of block mode DMA or not).
The test consisted of reading 8000k using dd
and dumping the results to /dev/null.
This was repeated for block sizes of 512 to 8k,
doubling the size at each test.
For single sector reads and writes,
the EIDE adapter was faster.
I attribute this to MSCP overhead.
For file system block sized reads and writes,
the performance was about equal.
For large transfers the EIDE adapter maxed out at about
250kbytes per sec.
Measured Performance (kBps)
A real world comparison was made measuring the time
to compile the same kernel on each of the devices.
Kernel Compile Time
The WD device compiled the kernel in 70% of the time
required for the MSCP device.
Lots of variables here though.
The SCSI drive is about twice as old as the EIDE drive
and the on disk buffer much smaller.
The important consideration is that the EIDE adapter
is not excessively limited because it operates in
a PIO mode instead of DMA.
Several people have commented on these metrics.
The CQD-220 is probably not the fastest competitor,
some have experienced higher performance with
CQD-440 for example.
The KDJ11-B processor,
even in a 2 instruction loop that is presumably
only uses about 30% of the QBus bandwidth.
This thing could potentially be a whole lot faster.