The UPAD is the Unibus version of my QPAD paddle card. It's a paddle card for developing Unibus peripherals using a Burched B3-SPARTAN2+ developer's board. I built it in May 2002. It's a short Unibus SPC card with nine DS3862 octal transceiver chips on it (the DS8641 that I used in the QPAD was discontinued on 01-May-2002 so there was no point in using those), one 180/390 ohm DIP resistor packs for terminating the grant lines, and sockets for three more resistor packs for all the grant lines, and sockets for DIP termination resistor packs for all the other signals. As with the QPAD, I wanted to be able to use the same board for developing peripherals now, and possibly a bus adapter some day, so it needed to be able to terminate the CPU end of the bus if necessary. There are also jumpers which allow the grant lines' receivers to be reused for receiving the interrupt/NPR request signals, since the board only needs to do one or another and I wanted to avoid adding another DS3862 just for that (they cost over $5/ea).
The board is a quad-height, double sided Unibus SPC (small peripheral controller) board. I had it made at PCB Express. Their prices are higher than AP Circuits (the PCB house I usually use) but they can do CNC routing of board edges, so I was able to specify the exact board outline and get the edge connectors notched much more neatly than what I did to my QPAD with a sabre saw (what was I thinking!).
The DS3862 doesn't separate the bus drivers and receivers like the old DS8641 did, it can go in only one direction at a time and that direction applies to all eight bits (so it's just like a 74LS245 but with a different pinout -- it has very high current sink requirements so the VCC/GND pins are in among the I/O pins instead of at the corners of the chip), so unlike the QPAD, I didn't have input and output pins for every single Unibus signal. This complicates the VHDL code a little, but it reduces the number of FPGA I/O pins needed (a good thing since the Unibus is not multiplexed the way the Q-bus is, so there are a lot more signals to contend with), and with the paddle card it means that the UPAD actually requires fewer ribbon cables than the QPAD (two 40-pin cables broken out to four 20-pin connectors at the development board end, vs. five 20-pin cables for the original QPAD). I plan to re-do the QPAD with DS3862s though, since the DS8641 is no longer available, so I'd like to do a full round of testing with paddle boards before committing to an entire self-contained disk controller PC board.
I only just stuffed the board and made up the cables, I haven't yet plugged the board into a machine (I plan to use my secondary "utility" PDP-11/34a for that) or started the VHDL code. I want to do some much more thorough inspection of the board by eye before plugging it in, the QPAD required a number of wiring changes to work but nothing that caused any damage, I don't want to count on getting lucky twice though.
My plan however is to make the Unibus VHDL code's interface be compatible with the Q-bus code, so that when I write the VHDL for the rest of the FPGA's duties (register emulation etc.), it can be built against either so that the same core code will work in both versions of the disk controller.
One important difference, though, is that the Unibus version will support DMA with an 18-bit data path. This is to support the KS10 (DECSYSTEM-2020), which uses the Unibus PA and PB parity lines as additional data lines during (most) disk and magtape I/O. In theory this would work on the Q-bus too (using the BDAL16 and BDAL17 lines as data bits during the data phase of each cycle), but I don't know of any 18-bit Q-bus adapters, so it's probably pointless. For now the Q-bus version of the VHDL code will accept, but ignore, the high two bits of an 18-bit data word.
I had hoped to include a Spartan2 FPGA directly on this board, so that I wouldn't need the Burched development board, but when I tried that it exceeded the limits of the PADS/PCB crippleware demo version I've been using for little projects for years (PADS allows commercial use of this version so this is kosher, it's too crippled to be used for anything serious anyway). So I went with the ribbon cables instead, and plan a daughtercard for the next step, meanwhile I've got a copy of Protel on order. It'll be nice to finally have an autorouter...
So, the rest of this project is vaporware for the time being, but my next steps are: