• Please review our updated Terms and Rules here

Qbus Interface Design Collaboration

K

kenwickvs

Experienced Member
Joined
May 1, 2017
Messages
109
Location
Raleigh, North Carolina, USA
Hello again DECheads,

I've noticed what seems to be an increasing interest in prototyping hardware for the Qbus. I, for one, am tinkering on a Qbus processor board as is Peter (cbscpe on VCFED). There's also a recent VCFED post by w3llschmidt indicating a need for Qbus design templates. I'm sure there are others as well if we had an open, low cost and proven way to interface with the Qbus through a standard circuit design. So, I propose that it would be good to set up a design collaborative on Github with the following initial guidelines:

  • Make the project Open Source and Open Hardware compliant under a non-restrictive license (suggestions welcome)
  • Standardize on KiCad for schematic and layout as the tool suite is totally open, free, very capable and community supported
  • Write an initial design specification, evolving as the project issues are resolved and ultimately finalized
  • Create layout templates for Dual and Quad Qbus form factors
  • Address the issue of obsolete bus interface logic with a workable compromise using long-term available devices
  • If needed, programmable logic (CPLD or FPGA) designs must be generic and independent of a particular vendor architecture
  • Also, any PLD tools used must be available under a free license for individuals, hobbyists, etc.
  • Take advantage of group buys for circuit boards and components (like we did with the RL Emulator last year)


Those are my initial thoughts. I'll go ahead a set up a Github project and welcome anyone's contribution.

-Ken
 
kenwickvs said:
[*]Address the issue of obsolete bus interface logic with a workable compromise using long-term available devices
Click to expand...

Has anyone ever measured signal integrity on the critical signals on a normal 8-slot backplane with integral termination
using conventional tri-state logic?

This comes up over and over. Is this even an issue on a system with no bus extension cables?
 
Hi Ken,

that sounds really good!

Im new on QBUS and i want to understand how it works. So my first goal is to access the bus an see whats going up there with my Dsview.

This is where the idea come from:

unibus_signal_adapter-01.jpg


http://retrocmp.com/images/stories/joerg/unibus_signal_adapter/unibus_signal_adapter-01.jpg

WksQJ5Vl.png


http://svn.so-much-stuff.com/svn/trunk/Eagle/lbr/dec-con.lbr
 
w3llschmidt said:
Im new on QBUS and i want to understand how it works. So my first goal is to access the bus an see whats going up there with my Dsview.
Click to expand...

I think you mean Unibus.

QBus is similar but uses multiplexed address and data. The interrupt mechanism is quite a bit different too.

Bus termination values are also different between the two busses.
 
Just for reference purpose.
Enclosed files from my Q-BUS <-> CTI-Bus ( from Pro 350 ) converter
If you are interested, I would like to provide the Macro-11 driver software for rt11,
a test program and a formatting program. Or at http://www.pdp11gy.com/5E.html#5.
QBUS-CTIBUS-CHIPS.jpg
Drawing.jpg
 
Hi,

I think the first thing we need to solve is the level conversion. We need to pay attention to the fact that VIL is 1.1V and VIH is 2.25V. This could be achieved with AC logic (74AC04) running at 3V4. This is close. It will however make the board not power safe, that is if the board has no power it will shorten the bus. For the outputs I suggest N-MOSFET. AO3400 (ZXMN3B14FTA) are fast and high-current and at VGS = 2.5V they have a rdson of only 52mOhm and support up to 4A (we don't need that much of course). Quite a few are then required, but they are cheap (30cents in the quantities we need) So for all signals we have a R(eceive) and a T(ransmit) on the card. This is ok except for BDAL0..15 where it creates issues (aka needs more brainware in the design) when interfacing with bidirectional logic (e.g. Memory). So the FPGA needs to have a decent number of IO (about 100) and must have 3V logic IO. Does that make sense?

Peter
 
The big problem that we have had with making an Omnibus interface was having bus driver chips that were much faster then the original chips and caused lots of crosstalk on the bus.
 
Hi Peter, eeguru, Michael et al,

For reference in this thread following is the original electrical specification for the Qbus from the "PDP11 Bus Handbook" from 1979.

Bus Drivers
Devices driving the 120 ohm LSI-11 bus must have open c·ollector
outputs and meet the following specifications.
DC Specifications
Output low voltage when sinking 70 mA of current: 0.7 V maximum
Output high leakage current when connected to 3.8 Vdc: 25 uA (even if no power is applied to them, except for BOCOK H and BPOK H)
These conditions must be met at worst-case supply voltage, temperature, and input signal levels.
AC Specifications
Bus driver output pin capacitive load: Not to exceed 10 pF
Propagation delay: Not to exceed 35 ns
Skew (difference in propagation time between slowest and fastest gate): Not to exceed 25 ns
Rise/Fall Times: Transition time from 10% to 90% for positive transition, and from 90% to 10% for negative transition, must be no faster than 10 ns and no slower than 1 ps.

Bus Receivers
Devices that receive signals from the 120 ohm LSI-11 bus must
meet the following requirements.
DC Specifications
Input low voltage (maximum): 1.3 V
Input high voltage (minimum): 1.7 V
Maximum input current when connected to 3.8 Vdc: 80uA even if no power is applied to them.
These specifications must be met at worst-case supply voltage, temperature, and output signal conditions.
AC Specifications
Bus receiver input pin capacitance load: Not to exceed 10 pF
Propagation delay: Not to exceed 35 ns
Skew (difference in propagation time between slowest and fastest gate): Not to exceed 25 ns

@eeguru I think that there are a total of 44 signal lines in a Q22 backplane (if I counted correctly).

There are a number of discussions on line regarding the obsolescence of all legacy parts that meet the spec. I agree with Peter that we need to focus on this for our collaborative design. I'm not ready to weigh in with an approach, but I'm working on it. No doubt it will be a compromise.

Thanks for everyone's input.

-Ken
 
Yes there are a total of 44 signals on the Q-Bus, however many are special and will reduce the number of IOs. There are some signals we normally do not drive, but only "consult"

BDCOKH, BPOKH

then there are some which are only input

BDMGI, BIAKI

and there are some which are only output

BDMGO, BIAKO

Also they have to be open collector (drain). Tri-State bus drivers are a very bad idea because it will make the design very complicate and it is electrically not equivalent to the Q-Bus design. You need to be able to de-assert individual signals. Not possible with most Tri-State level converters, but very trivial with open collector. The Q-Bus signals are all preloaded with 3.4V. They represent a Thevenin equivalent of a 3V4 power source with an output resistance of 60 Ohms (each end of the bus is terminated with 120 Ohms). Note that a bus terminated with 120 Ohms and a Thevenin source are dynamically not equivalent. But the Thevenin model gives the reason of the requirement of open collector, its output levels and the minimal current source requirements.

This rules out all modern and currently available off-the-shelf level converters.

Using discrete transistors to drive the bus is just more work when soldering the PCB, it does however not use more PCB space, as I assume we will not go smaller than SOIC for the bus drivers. Traditionally many Q-Bus cards used TTL 7438 open collector drivers for output only signals or the DS8641 for bidirectional signals. Which was 4 signals in a PDIP-14 package and they still had enough space to add the "logic" of the board. Actually using discrete transistors makes routing easier. And of course you do not have to populate all transistors if your design is for example only a device without DMA, or is using just one interrupt etc. etc.

The 7438 are still in production, but those are 5V devices. I don't know if it is a good idea to drive the inputs of a 7438 with FPGA outputs. In theory the output levels of FPGAs with an IO Voltage of 3V3 should be compatible with the inputs of a 7438, perhaps somebody with experience with FPGA interfacing to TTL could shed some light on this subject. The 7438 would have the advantage of meeting the output drive requirements of the Q-Bus.

Peter
 
Thanks for the info. It scratched my brain itch. You still have to level translate or clip the inputs going the other way. So that's even more chips via buffers, quick switches, etc. My $.02, the family of TI chips I linked above have worked well for just about all mid-80's designs I've thrown them at. They only have 35mA sink capacity. However they could be ganged up in pairs. They come in 2, 8, and 16 line versions. So doubling would give 1, 4, and 8 signal bi directional translations. I'm not familiar with QBUS, but as you said if there are a lot of pin-groups or pins requiring individual control, discretes might be better. Though a 6 or 8 gang buffer with individual tri-states (all inputs grounded) and a quick switch would be easier to solder.

I wouldn't think there would be any issues with an FPGA driving a 5V part input other than the rise times needed to meet a higher ViL/H might stretch the spec'd propagation times a little.

Sounds like a cool project. Good luck!
 
It seems that there is no standard parts that meet entirely both driver and receiver specifications as discussed 10-years ago here:
http://www.brouhaha.com/~eric/retrocomputing/dec/interfacing/chips.html

The TI SN7438 is a candidate for the OC drivers if the design has separate drivers and receivers. With input thresholds of 0.8Vil(max) and 2.0 Vih(min) it can be driven with 3.3V FPGAs. The Voh leakage current will not be met. It's available in 14 pin DIP and SO surface mount for about $1.50 US.

We might want to check out the TI AM26S10C quad transceiver which has OC outputs capable of sinking 100ma. It meets the propagation specs, but it is Schottky and has fast rise and fall times (4ns min/10ns typ). The inputs do not quite meet the spec at 1.75Vil, but it's close and the 2.25V Vih is high. Again, the Voh leakage will not be met. It's available in 16 pin DIP and SO surface mount for about $1.50 US.

Another transceiver is the SN75138 with OC 100ma sinking outputs. The propagation is OK, but there is no rise/fall spec, but it's not Schottky so it's probably not too fast. The Vih is 1.8V min and Vih is 2.9V (way high). It's available in 16 pin DIP and SO, compatible with the AM26S10C, but more expensive at about $3.00 US.

So, I think a question to be answered before we can resolve the driver/receiver issues is, for our (hobbyist) requirements, can we relax DEC's Qbus specs? If so, what should they be? I envision the target applications to be single chassis/backplanes rather than clusters of cabinets all cabled together over several meters. Perhaps others have different ideas.

-Ken
 
A quick thought relating to Al Kossow's post early in this thread, it would be very useful to see some captured scope traces (DAL lines would be best) from a heavily loaded PDP. I don't have one, but some folks on this forum do. Any chance of getting this from someone?
-Ken
 
kenwickvs said:
We might want to check out the TI AM26S10C quad transceiver which has OC outputs capable of sinking 100ma. It meets the propagation specs, but it is Schottky and has fast rise and fall times (4ns min/10ns typ). The inputs do not quite meet the spec at 1.75Vil, but it's close and the 2.25V Vih is high. Again, the Voh leakage will not be met. It's available in 16 pin DIP and SO surface mount for about $1.50 US.
-Ken
Click to expand...

I used the AM26S10 to interface an FPGA to the Omnibus.
 
kenwickvs said:
Is the AM26S10 the one you're referring to?
Click to expand...

We had problems with 74FCTxx and 74ABTxx parts. 74LSxx and 74ALSxx parts worked OK.
The AM26S10 worked fine for an Omnibus interface for an FPGA.

kenwickvs said:
PS, Don't you have a running PDP with a loaded Qbus @ RICM?
Click to expand...

All of the Qbus systems at the RICM are little.
 
Last edited:
If you ganged buffers 2x2 the TI SN74LVC16T245, SN74LVC8T245, SN74LVC2T45 parts would meet your specs and save you a FPGA pin for each signal minus a DIR+OE set per signal group. But I'll shut-up now.
 
Bidirectional buffers are in fact only helpful for BDAL0..15. However a level converter with dedicated OE for each side instead of DIR and OE would be easier to use with the Q-Bus. The rest is often better handled using a R(eceive) and a T(ransmit) signal on the board. Especially when you want to have a universal board. As you mention driving a 5V TTL with the output of a 3V3 FPGA only will add to the propagation delay as the VOH of FPGA is really near 3V, sufficient for TTL. And we don't need those extra nanoseconds. So I think I will go for the SN7438 as output buffers. I did not see any datasheet that makes a remark towards the leak current (i.e. when the outputs are high). But I cannot imagine that it is too high. However I have seen that the 74HC4050 would make the ideal input buffer when operated at 3V the input threshold is centered around 1.5V (exactly between the Q-Bus levels 1.3V for Low and 1.7 for High). The good thing is the 74HC4050 have no input clamping diodes towards VCC, so input can go higher than VCC (3V in our case), it can go up to 15V. Now I only need to find a reasonable FPGA. One that has about 100 IO, has 3V IO and comes in a solderable package (no BGA) like TQFP-144. One with on chip configuration storage would be nice.
 
You must log in or register to reply here.
Back
Top