Project Status

• May 2008
  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.
• April 2008
  I finally got back to this project and have RT11 working. Updated PLD files and MACRO-11 sources can be found below.
• October 2004
  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.)
• January 2004
  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 dropped considerably.
  I think the original design is still viable even without the addition of DMA, etc.
• April 2002
  No progress.
  A disk crash set me back, losing my latest driver source.
  Excuses, excuses.....
• March 2002
  Lack of time prevents me from building a prototype based on the new DMA design.
• February 2002
  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 and Accessories.
• 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.

Project Background

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. (View it 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 speed that 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 file.

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 used it. It is probably not the best. The DMA related registers and the reserved address space respond as memory, but does nothing more.

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 cause problems.

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 read-modify-write instructions. 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.

Software

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.

Construction

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. Therefore, 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 and debugging. 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 card. 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 about SCSI. 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 acceptably, 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.

Engineering Package

The following is a crude summary of the design. I don't think it is complete. If anyone is really interested in more information, just ask.

• Block Diagram
• Schematic
• CPLD description file
• 2.11BSD device driver, header file and man page
• RT11 V5.03 handler
• EEPROM boot for the KDJ11-B processor in 2.11BSD assembler
• EEPROM boot for the KDJ11-B processor in MACRO-11

References

• ATA-2 Specification
• ATA-3 Specification Annex C contains of discussion of signal integrity in the drive cable.
• Q22 Specification - part 1, part 2, part 3, and part 4
• DEC chipkit users manual LSI-11 Bus Interface Chips and Accessories (Thanks to Carl Lowenstein and Eric Smith.)

How Fast is it? - I/O Performance

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)
Controller	Xfer Size	Real	System
MSCP	512	53.8	101.7
	1k	100.5	204.1
	2k	179.4	394.1
	4k	284.7	720.7
	8k	457.1	1379.3
WD	512	58.0	110.0
	1k	95.4	177.8
	2k	140.4	349.3
	4k	181.8	672.3
	8k	211.6	1333.3

A real world comparison was made measuring the time to compile the same kernel on each of the devices.

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 in cache, only uses about 30% of the QBus bandwidth. This thing could potentially be a whole lot faster.