23 Oct
2016
23 Oct
'16
2:50 p.m.
Hello,
surely the old transceivers are the most compatible solution, however you
still need to convert the voltages back and forth...
Plus the solution is not the cheaper, and a little uncomfortable too, as
you need to find these old chips, hoping not to buy fake chinese duplicates
(it happened to me more time unfortunately).
So I was searching a solution with modern components, but not using
components too much specific and difficult to be found.
As we need 3.3v logic, but able to work in 5v bus, I'm thinking about 5v
tolerant standard logic as TI LVC or LVT.
The problem is that there aren't open drain bus transceivers, but the
problem could be solved simply using input-only and output-only components,
connecting two in parallel but opposite direction on bidirectional pins.
So identifying one or maybe two codes would be enough for all the
components needed for the board.
The idea of using bare transistors seems to me too much simple.
Not that it couldn't work, but it would be almost impossible to satisfy all
the specifications of the bus in this way... unless you use a more complex
circuit with precise current sources and resistors to grant correct voltage
biases, impedances and slew rates, which in the end is a logic integrated
circuit.
Andrea
23 Oct
23 Oct
2:59 p.m.
On 10/23/16 11:50 AM, shadoooo wrote:
The problem is that there aren't open drain bus
transceivers, but the
problem could be solved simply using input-only and output-only components,
connecting two in parallel but opposite direction on bidirectional pins.
The reason for using the old parts is the logic thresholds are unique to
the Unibus to handle worst-case bus loading and the termination voltage they
used.
24 Oct
24 Oct
1:37 p.m.
On 10/23/16 2:59 PM, Al Kossow wrote:
On 10/23/16 11:50 AM, shadoooo wrote:
The voltages are based on TTL levels. What are the unique voltages?
The key was limited leakage current and input current to not load the
bus by inserting or removing
current from a node (there is a specified maximum in per node and total
nodes). That cover input
to card devices and bus driver leakage.
Logic low voltage is typical of TTL and the driver device has to sink
that current and meet that value.
Logic High was set by the terminator devices at 3.36V but the threshold
is lower based on the bus
receivers.
By late 1970 it was an easy spec to meet, When first used (pdp8e) it
was new and the ICs
were not so great with leakage current and output device saturation current.
Every time this comes up the world is supposed to stop if not met. The
LSI-11 bus (qbus)
was actually harder as it was 120 ohm terminated and HeathKit did it
with common TTL
and the CPU was DEC standard LSI-11 and it worked out to 18 slot backplanes.
Allison
The problem is that there aren't open drain
bus transceivers, but the
problem could be solved simply using input-only and output-only components,
connecting two in parallel but opposite direction on bidirectional pins.
The reason for using the old parts is the logic thresholds are unique to
the Unibus to handle worst-case bus loading and the termination voltage they
used.
2:09 p.m.
New subject: Fwd: Re: DEC bus transceivers
-------- Forwarded Message --------
Subject: Re: DEC bus transceivers
Date: Mon, 24 Oct 2016 13:37:14 -0400
From: allison <ajp166 at verizon.net>
Reply-To: General Discussion: On-Topic Posts <cctech at classiccmp.org>
To: General Discussion: On-Topic Posts <cctech at classiccmp.org>
On 10/23/16 2:59 PM, Al Kossow wrote:
On 10/23/16 11:50 AM, shadoooo wrote:
The voltages are based on TTL levels. What are the unique voltages?
The key was limited leakage current and input current to not load the bus by inserting or
removing
current from a node (there is a specified maximum in per node and total nodes). That
cover input
to card devices and bus driver leakage.
Logic low voltage is typical of TTL and the driver device has to sink that current and
meet that value.
Logic High was set by the terminator devices at 3.36V but the threshold is lower based on
the bus
receivers.
By late 1970 it was an easy spec to meet, When first used (pdp8e) it was new and the ICs
were not so great with leakage current and output device saturation current.
Every time this comes up the world is supposed to stop if not met. The LSI-11 bus (qbus)
was actually harder as it was 120 ohm terminated and HeathKit did it with common TTL
and the CPU was DEC standard LSI-11 and it worked out to 18 slot backplanes.
Allison
The problem is that there aren't open drain
bus transceivers, but the
problem could be solved simply using input-only and output-only components,
connecting two in parallel but opposite direction on bidirectional pins.
The reason for using the old parts is the logic thresholds are unique to
the Unibus to handle worst-case bus loading and the termination voltage they
used.
2:13 p.m.
On Oct 24, 2016, at 10:37 AM, allison <ajp166 at
verizon.net> wrote:
On 10/23/16 2:59 PM, Al Kossow wrote:
The biggest concern is when interfacing to UNIBUS. In the PDP-11 UNIBUS Design
Description
document on Bitsavers, page 4-1 indicates what the Unibus interface chips are and what are
*not*
recommended (8640, 8641 and 8881 are the only ones recommended).
There are a number of rules that must be adhered to when building out a Unibus system.
These
include:
Maximum cable length must be < 50?
Maximum DC loading < 20
Maximum lumped loading < 20
There are rules where cable lengths must be *increased* to avoid reflections.
A single Unibus can be divided into multiple segments. Each segment must adhere to the
above
rules, so you can see that a Unibus can be quite large.
For example, my PDP-11/40 resides in 2 BA11-F boxes (23? tall) and are fully populated
with
Unibus backplanes (5 9 slot backplanes each) with a BA11-15 (15? cable) connecting the
two.
My point here is that the Unibus has a very different electrical environment than Q-bus or
Omnibus
and what may work for them will probably have troubles on a Unibus.
TTFN - Guy
On 10/23/16 11:50 AM, shadoooo wrote:
The voltages are based on TTL levels. What are the unique voltages?
The key was limited leakage current and input current to not load the bus by inserting or
removing
current from a node (there is a specified maximum in per node and total nodes). That
cover input
to card devices and bus driver leakage.
Logic low voltage is typical of TTL and the driver device has to sink that current and
meet that value.
Logic High was set by the terminator devices at 3.36V but the threshold is lower based on
the bus
receivers.
By late 1970 it was an easy spec to meet, When first used (pdp8e) it was new and the
ICs
were not so great with leakage current and output device saturation current.
Every time this comes up the world is supposed to stop if not met. The LSI-11 bus (qbus)
was actually harder as it was 120 ohm terminated and HeathKit did it with common TTL
and the CPU was DEC standard LSI-11 and it worked out to 18 slot backplanes.
The problem is that there aren't open drain
bus transceivers, but the
problem could be solved simply using input-only and output-only components,
connecting two in parallel but opposite direction on bidirectional pins.
The reason for using the old parts is the logic thresholds are unique to
the Unibus to handle worst-case bus loading and the termination voltage they
used.
26 Oct
26 Oct
9:39 a.m.
Guy S.
Thanks saved me the time to say exactly what you said. For all those that
thing designing a driver is a simple thing to do, make your self a
simulated Unibus that is 50 feet long, add around 30 'stubs' load it down
to the max and show me your 'easy to build' drivers signal quality.
On Mon, Oct 24, 2016 at 11:13 AM, Guy Sotomayor Jr <ggs at shiresoft.com>
wrote:
bus by
inserting or removing
The biggest concern is when interfacing to UNIBUS. In the PDP-11 UNIBUS
Design Description
document on Bitsavers, page 4-1 indicates what the Unibus interface chips
are and what are *not*
recommended (8640, 8641 and 8881 are the only ones recommended).
There are a number of rules that must be adhered to when building out a
Unibus system. These
include:
Maximum cable length must be < 50?
Maximum DC loading < 20
Maximum lumped loading < 20
There are rules where cable lengths must be *increased* to avoid
reflections.
A single Unibus can be divided into multiple segments. Each segment must
adhere to the above
rules, so you can see that a Unibus can be quite large.
For example, my PDP-11/40 resides in 2 BA11-F boxes (23? tall) and are
fully populated with
Unibus backplanes (5 9 slot backplanes each) with a BA11-15 (15? cable)
connecting the two.
My point here is that the Unibus has a very different electrical
environment than Q-bus or Omnibus
and what may work for them will probably have troubles on a Unibus.
TTFN - Guy
On Oct 24, 2016, at 10:37 AM, allison <ajp166
at verizon.net> wrote:
On 10/23/16 2:59 PM, Al Kossow wrote:
>
> On 10/23/16 11:50 AM, shadoooo wrote:
>
>> The problem is that there aren't open drain bus transceivers, but the
>> problem could be solved simply using input-only and output-only
components,
>> connecting two in parallel but opposite
direction on bidirectional
pins.
>>
> The reason for using the old parts is the logic thresholds are unique to
> the Unibus to handle worst-case bus loading and the termination voltage
they
used.
The voltages are based on TTL levels. What are the unique voltages?
The key was limited leakage current and input current to not load the current from a node (there is a specified maximum
in per node and total
nodes). That cover input
to card devices and bus driver leakage.
Logic low voltage is typical of TTL and the driver device has to sink
that current
and meet that value.
Logic High was set by the terminator devices at
3.36V but the threshold
is lower based on the bus
receivers.
By late 1970 it was an easy spec to meet, When first used (pdp8e) it
was new and
the ICs
were not so great with leakage current and output
device saturation
current.
Every time this comes up the world is supposed to stop if not met. The
LSI-11 bus
(qbus)
was actually harder as it was 120 ohm terminated
and HeathKit did it
with common TTL
and the CPU was DEC standard LSI-11 and it worked
out to 18 slot
backplanes.
24 Oct
24 Oct
4:18 p.m.
On 10/24/2016 01:37 PM, allison wrote:
The voltages are based on TTL levels. What are the
unique voltages?
The QBUS spec from the 1979 Bus Handbook (the Unibus levels are the same):
Input low voltage (maximum): 1.3 V
Input high voltage (minimum): 1.7 V
And from the TI datasheet for the 74LS74:
Vil - low-level input voltage 0.8 V (maximum)
Vih - high-level input voltage 2 V (minimum)
So no, the DEC bus voltage levels are not TTL levels. Yeah, TTL might
work on a smaller system but you can see that if you push it out to its
limits, TTL could start getting flaky. That's the kind of bug I'm happy
to have DEC's engineers figure out and not have to track down myself.
25 Oct
25 Oct
1:23 a.m.
On 10/24/2016 1:18 PM, David Bridgham wrote:
On 10/24/2016 01:37 PM, allison wrote:
FYI here is an I/O plot I did of the bus input receiver of an 8641 device (the
blue line). A threshold of about 1.5V.
Also included is a plot of a 26S10 transceiver (which has a higher input voltage
threshold) which I think is used
in later designs (SBI? IIRC).
http://www.ak6dn.com/stuff/26S10vs8641.jpg
The voltages are based on TTL levels. What are
the unique voltages?
The QBUS spec from the 1979 Bus Handbook (the Unibus levels
are the same):
Input low voltage (maximum): 1.3 V
Input high voltage (minimum): 1.7 V
And from the TI datasheet for the 74LS74:
Vil - low-level input voltage 0.8 V (maximum)
Vih - high-level input voltage 2 V (minimum)
So no, the DEC bus voltage levels are not TTL levels. Yeah, TTL might
work on a smaller system but you can see that if you push it out to its
limits, TTL could start getting flaky. That's the kind of bug I'm happy
to have DEC's engineers figure out and not have to track down myself. 
2:35 a.m.
On 10/24/2016 2:18 PM, David Bridgham wrote:
On 10/24/2016 01:37 PM, allison wrote:
But who has the big systems now days? The days of 4K core is long gone.
Use TTL and try to keep the systems small.
Ben.
The voltages are based on TTL levels. What are
the unique voltages?
The QBUS spec from the 1979 Bus Handbook (the Unibus levels are the same):
Input low voltage (maximum): 1.3 V
Input high voltage (minimum): 1.7 V
And from the TI datasheet for the 74LS74:
Vil - low-level input voltage 0.8 V (maximum)
Vih - high-level input voltage 2 V (minimum)
So no, the DEC bus voltage levels are not TTL levels. Yeah, TTL might
work on a smaller system but you can see that if you push it out to its
limits, TTL could start getting flaky. That's the kind of bug I'm happy
to have DEC's engineers figure out and not have to track down myself.
5:58 a.m.
On 10/25/2016 02:35 AM, ben wrote:
Some of the recovered and restored system are big.
Allison
On 10/24/2016 2:18 PM, David Bridgham wrote:
> On 10/24/2016 01:37 PM, allison wrote:
>
>> The voltages are based on TTL levels. What are the unique voltages?
>
> The QBUS spec from the 1979 Bus Handbook (the Unibus levels are the
> same):
>
> Input low voltage (maximum): 1.3 V
> Input high voltage (minimum): 1.7 V
>
> And from the TI datasheet for the 74LS74:
>
> Vil - low-level input voltage 0.8 V (maximum)
> Vih - high-level input voltage 2 V (minimum)
>
True, you run the bus at 1.3/1.7 and see how far you go without errors.
Those are limits. Most systems I've played with if you get over 1V/low
and below 2V/high things tend to be a bit flakey.
Also TTL switches at 1.7ish and anyone using a 74ls74 on the bus should
be shot!
Look at 74LS240 or 241 as a better example for an bus to board receiver.
For driving the bus look at 74ls38 those are more typical.
Look at a machine that's running well and tends to stay that way and
you see more like .6-.8/low and over 2.4 high.
So no, the DEC
bus voltage levels are not TTL levels. Yeah, TTL might
work on a smaller system but you can see that if you push it out to its
limits, TTL could start getting flaky. That's the kind of bug I'm happy
to have DEC's engineers figure out and not have to track down myself.
But who has the big systems now days? The days of 4K core is long gone.
Use TTL and try to keep the systems small.
Ben.
10:02 a.m.
On Oct 24, 2016, at 11:35 PM, ben <bfranchuk at
jetnet.ab.ca> wrote:
On 10/24/2016 2:18 PM, David Bridgham wrote:
I just posted what one of my systems is (11/40). It has 128KW of core which
takes 4 9-slot backplanes. I have a fair amount of I/O on that system so I
have 2 BA11F chassis *full* of backplanes (each BA11F holds 5 9 slot backplanes).
My other large system is an 11/70 with a BA11K as an expansion box. The whole
point of Unibus was to allow for large configurations.
And I can guarantee you that TTL will *not* work in those systems.
If you want to build boards that will work in a small subset of systems that?s
find?but don?t advertise it as Unibus compatible. I test the boards I produce
in all of my systems (11/20, 11/34, 11/40 and 11/70) and they all use DEC bus
interface chips.
TTFN - Guy
On 10/24/2016 01:37 PM, allison wrote:
But who has the big systems now days? The days of 4K core is long gone.
Use TTL and try to keep the systems small. The voltages are based on TTL levels. What are
the unique voltages?
The QBUS spec from the 1979 Bus Handbook (the Unibus levels are the same):
Input low voltage (maximum): 1.3 V
Input high voltage (minimum): 1.7 V
And from the TI datasheet for the 74LS74:
Vil - low-level input voltage 0.8 V (maximum)
Vih - high-level input voltage 2 V (minimum)
So no, the DEC bus voltage levels are not TTL levels. Yeah, TTL might
work on a smaller system but you can see that if you push it out to its
limits, TTL could start getting flaky. That's the kind of bug I'm happy
to have DEC's engineers figure out and not have to track down myself.
11:38 a.m.
On 10/25/16 10:02 AM, Guy Sotomayor Jr wrote:
Maybe if care is not taken. Again there are TTL part and those
designed for bus use.
Bad choice, bad results. I've seen a few like that that broke even
with DEC parts.
Then again My 11/73 is BA11S and Ba11N both with 18 slot 4mb ram (two
cards), DELQA,
two RQDX3 (one for RX floppies, second for RD disks), RLV21 (in box2),
CMS scsi,
RXV21V-RX02, DZH11V and Parallel IO (ttl) in box 2 and Gigilo card
(DEC sound
card for Qbus) in Box 1. Likely a few IO I forgot.
By all DEC standards its unsupported config. Bus signals still look good.
I've seen my share of BIG VAXen with many unibus crates too.
Allison
old millrat
On Oct 24,
2016, at 11:35 PM, ben <bfranchuk at jetnet.ab.ca> wrote:
On 10/24/2016 2:18 PM, David Bridgham wrote:
I just posted what one of my systems is
(11/40). It has 128KW of core which
takes 4 9-slot backplanes. I have a fair amount of I/O on that system so I
have 2 BA11F chassis *full* of backplanes (each BA11F holds 5 9 slot backplanes).
My other large system is an 11/70 with a BA11K as an expansion box. The whole
point of Unibus was to allow for large configurations.
And I can guarantee you that TTL will *not* work in those systems. On 10/24/2016 01:37 PM, allison wrote:
But who has the big systems now days? The days of 4K core is long gone.
Use TTL and try to keep the systems small. The voltages are based on TTL levels. What are
the unique voltages?
The QBUS spec from the 1979 Bus Handbook (the Unibus levels
are the same):
Input low voltage (maximum): 1.3 V
Input high voltage (minimum): 1.7 V
And from the TI datasheet for the 74LS74:
Vil - low-level input voltage 0.8 V (maximum)
Vih - high-level input voltage 2 V (minimum)
So no, the DEC bus voltage levels are not TTL levels. Yeah, TTL might
work on a smaller system but you can see that if you push it out to its
limits, TTL could start getting flaky. That's the kind of bug I'm happy
to have DEC's engineers figure out and not have to track down myself.
If you want to build boards that will work in a small subset of systems that?s
find?but don?t advertise it as Unibus compatible. I test the boards I produce
in all of my systems (11/20, 11/34, 11/40 and 11/70) and they all use DEC bus
interface chips.
TTFN - Guy
12:10 p.m.
On Oct 25, 2016, at 8:38 AM, allison <ajp166 at
verizon.net> wrote:
On 10/25/16 10:02 AM, Guy Sotomayor Jr wrote:
Maybe if care is not taken. Again there are TTL part and those designed for bus use.
Bad choice, bad results. I've seen a few like that that broke even with DEC parts.
That?s why there?s the UNIBUS spec that DEC published. In big systems, you must
follow the guidelines even with the proper transceivers. Sometimes it requires that
things be split up and cable length added.
Also, I think in a previous email you mentioned that the UNIBUS is 240ohm. It?s not.
It?s 120ohm.
On Oct
24, 2016, at 11:35 PM, ben <bfranchuk at jetnet.ab.ca> wrote:
On 10/24/2016 2:18 PM, David Bridgham wrote:
I just posted what one of my systems is
(11/40). It has 128KW of core which
takes 4 9-slot backplanes. I have a fair amount of I/O on that system so I
have 2 BA11F chassis *full* of backplanes (each BA11F holds 5 9 slot backplanes).
My other large system is an 11/70 with a BA11K as an expansion box. The whole
point of Unibus was to allow for large configurations.
And I can guarantee you that TTL will *not* work in those systems. On 10/24/2016 01:37 PM, allison wrote:
> The voltages are based on TTL levels. What are the unique voltages?
The QBUS spec from the 1979 Bus Handbook (the Unibus levels are the same):
Input low voltage (maximum): 1.3 V
Input high voltage (minimum): 1.7 V
And from the TI datasheet for the 74LS74:
Vil - low-level input voltage 0.8 V (maximum)
Vih - high-level input voltage 2 V (minimum)
So no, the DEC bus voltage levels are not TTL levels. Yeah, TTL might
work on a smaller system but you can see that if you push it out to its
limits, TTL could start getting flaky. That's the kind of bug I'm happy
to have DEC's engineers figure out and not have to track down myself.
But who has the big systems now days? The days of 4K core is long gone.
Use TTL and try to keep the systems small.
Then again My 11/73 is BA11S and Ba11N both with 18 slot 4mb ram (two cards), DELQA,
two RQDX3 (one for RX floppies, second for RD disks), RLV21 (in box2), CMS scsi,
RXV21V-RX02, DZH11V and Parallel IO (ttl) in box 2 and Gigilo card (DEC sound
card for Qbus) in Box 1. Likely a few IO I forgot.
OK, it?s still a small system by UNIBUS standards. ;-) I can?t check either my 11/40
or 11/70 but (from memory) the configs are:
11/40:
BA11F(1): CPU with all options (including FIS), 2 32KW core memory, additional backplanes
to fill it up
BA11F(2): 2 32KW core memory, 1 RK11D (4 slot backplane), additional backplanes to fill it
up
The ?standard? Unibus devices as I recall are (there are more as most of the backplanes
are full):
4 DL11s
DZ11
RL11
At least one tape drive interface of some sort
bootstrap/terminator
BC11A-15 to connect the two BA11Fs together.
11/70:
BA11F(1): CPU with all options, Hypercache (4MW option that looks like a 4MW cache to the
CPU), 2 SMD controllers that plug into the slots for the massbus controllers (4 slots
each). 2 Massbus controllers (4 slots each), 1 DL11
BA11K: RK11D 4 slot backplane, 2 RL11 controllers, TS11 controller, TU81 controller, 2
DZ11s, 3 DL11s, 1 ethernet controller
There?s more on this system, I just don?t recall it all at the moment. Again, this system
is *full*. I?m at the point where if I want to add more stuff I need to add another
BA11K.
bootstrap/terminator
BC11A-15 to connect the BA11F to the BA11K
By all DEC standards its unsupported config. Bus signals still look good.
I've seen my share of BIG VAXen with many unibus crates too.
Yes, and they all used the proper UNIBUS transceivers and not TTL parts.
TTFN - Guy
3:40 p.m.
On 10/25/16 12:10 PM, Guy Sotomayor Jr wrote:
My book says no. Qbus is for sure 120.
Mine
has many LS24x part and 7438s as there are more than a few IO cards
that are non DEC (mine).
Example IO a PIO IDE interface test dog wire wrapped (usually the worst)
alone with A/D and D/A.
By Qbus standards its a monster and it was rare to see more than two
boxes and usually the cages were
not the 18 AB slot but the 9 slot ABCD configuration. Runs unix well
and usually that breaks machines
that are flakey. Also Qbus uses 120 ohm termination so the drivers have
to sink more current.
Never could fake the DEC interbox cables, those are well done to work right.
The BA123 uVax also has a few odd cards, doesn't seem to care. THose
however were not fast
on the bus as they used PMI for Memory.
Another example is the 11/23 with all heathkit cards for memory, IO and
a few unique homebrews.
I've never seen a bus level issue die to devices used.
mostly.... A few of the systems were
not production and engineering did
play.
Bottom line is someday there will be no DEC parts and what then? I
reserve DEC parts
for repairing defunct boards for new and unique build it would be a
waste of scarce
material. The vector interrupt chip DC-series is one that is hard to
fake without a
larger number of chips.
For preservation reasons its very important, for hacking an old system
not as much.
In my collection I have both.
Allison
On Oct 25,
2016, at 8:38 AM, allison <ajp166 at verizon.net> wrote:
On 10/25/16 10:02 AM, Guy Sotomayor Jr wrote:
Maybe if care
is not taken. Again there are TTL part and those designed for bus use.
Bad choice, bad results. I've seen a few like that that broke even with DEC parts.
That?s why there?s the UNIBUS spec that DEC published. In big systems, you must
follow the guidelines even with the proper transceivers. Sometimes it requires that
things be split up and cable length added.
Also, I think in a previous email you mentioned that the UNIBUS is 240ohm. It?s not.
It?s 120ohm. On Oct
24, 2016, at 11:35 PM, ben <bfranchuk at jetnet.ab.ca> wrote:
On 10/24/2016 2:18 PM, David Bridgham wrote:
> On 10/24/2016 01:37 PM, allison wrote:
>
>> The voltages are based on TTL levels. What are the unique voltages?
> The QBUS spec from the 1979 Bus Handbook (the Unibus levels are the same):
>
> Input low voltage (maximum): 1.3 V
> Input high voltage (minimum): 1.7 V
>
> And from the TI datasheet for the 74LS74:
>
> Vil - low-level input voltage 0.8 V (maximum)
> Vih - high-level input voltage 2 V (minimum)
>
> So no, the DEC bus voltage levels are not TTL levels. Yeah, TTL might
> work on a smaller system but you can see that if you push it out to its
> limits, TTL could start getting flaky. That's the kind of bug I'm happy
> to have DEC's engineers figure out and not have to track down myself.
>
But who has the big systems now days? The days of 4K core is long gone.
Use TTL and try to keep the systems small.
I just posted what one of my systems is
(11/40). It has 128KW of core which
takes 4 9-slot backplanes. I have a fair amount of I/O on that system so I
have 2 BA11F chassis *full* of backplanes (each BA11F holds 5 9 slot backplanes).
My other large system is an 11/70 with a BA11K as an expansion box. The whole
point of Unibus was to allow for large configurations.
And I can guarantee you that TTL will *not* work in those systems. Then again My
11/73 is BA11S and Ba11N both with 18 slot 4mb ram (two cards), DELQA,
two RQDX3 (one for RX floppies, second for RD disks), RLV21 (in box2), CMS scsi,
RXV21V-RX02, DZH11V and Parallel IO (ttl) in box 2 and Gigilo card (DEC sound
card for Qbus) in Box 1. Likely a few IO I forgot.
OK, it?s still a small system
by UNIBUS standards. ;-) I can?t check either my 11/40
or 11/70 but (from memory) the configs are:
11/40:
BA11F(1): CPU with all options (including FIS), 2 32KW core memory, additional backplanes
to fill it up
BA11F(2): 2 32KW core memory, 1 RK11D (4 slot backplane), additional backplanes to fill
it up
The ?standard? Unibus devices as I recall are (there are more as most of the backplanes
are full):
4 DL11s
DZ11
RL11
At least one tape drive interface of some sort
bootstrap/terminator
BC11A-15 to connect the two BA11Fs together.
11/70:
BA11F(1): CPU with all options, Hypercache (4MW option that looks like a 4MW cache to the
CPU), 2 SMD controllers that plug into the slots for the massbus controllers (4 slots
each). 2 Massbus controllers (4 slots each), 1 DL11
BA11K: RK11D 4 slot backplane, 2 RL11 controllers, TS11 controller, TU81 controller, 2
DZ11s, 3 DL11s, 1 ethernet controller
There?s more on this system, I just don?t recall it all at the moment. Again, this
system is *full*. I?m at the point where if I want to add more stuff I need to add
another BA11K.
bootstrap/terminator
BC11A-15 to connect the BA11F to the BA11K
> By all DEC standards its unsupported config. Bus signals still look good. I've seen
my share of BIG VAXen with many unibus crates too.
Yes, and they all used the
proper UNIBUS transceivers and not TTL parts. TTFN - Guy
4:24 p.m.
On Oct 25, 2016, at 12:40 PM, allison <ajp166 at
verizon.net> wrote:
Section 5.2.5 of the PDP-11 UNIBUS spec:
A Unibus segment must always have a Unibus terminator at each end of its
120-ohm transmission path.
So, I don?t know how you get a value of anything other than 120-ohms given that
statement.
TTFN - Guy
Also, I think in a previous email you mentioned that the UNIBUS is 240ohm. It?s not.
It?s 120ohm.
My book says no. Qbus is for sure 120.
26 Oct
26 Oct
6:16 a.m.
On 10/25/2016 04:24 PM, Guy Sotomayor Jr wrote:
Its not. It may be close but.... What your reading is the terminator
value (R1+R2)/R1*R2=120.
thats a terminator and its also limited in the range of values because
the DEC part can only
sink so much and also the terminator has to source current as the driver
can't. Likely
the line impedance can be in the range of 120 ohms, maybe. I"ll have to
drag out a
Qbus back-plane and measure it. I don't have any Unibus.
As far as the chips themselves. They do NOT match the line impedance as
they have
a active low value in the 10 ohm range and when in the high state they
are just an open
or somewhere in the effectively infinite range certainly more than
several thousand ohms.
That's a terrible mismatch for transmission lines, aka bus. The
combination of wacky
source impedances and near open load impedance (input current varies
with source
voltage Vih and Vil) plus parallel capacitance from package and traces
on board means
that as a load its a horrid mismatch as well. With all that reflections
(ringing) are to be
expected and the only thing that can help that is the terminator even
then only to a point.
In short most TTL are no better and those designed to do bus interface
are about the same.
Also CMOS would be far worse as a receiver and some CMOS makes a better
transmitter
but they are incompatible with Unibus/Qbus as they actively source current.
The only common tech that does line matching especially from that era is
ECL, or current
mode logic.
This is why faster buses are so difficult to make right. And if
possible they are to be
avoided or made small as possible. Been there and done that,, mixed
signal design
for the last 40 years.
Allison
On Oct 25,
2016, at 12:40 PM, allison <ajp166 at verizon.net> wrote:
Section 5.2.5 of the PDP-11 UNIBUS spec:
A Unibus segment must always have a Unibus terminator at each end of its
120-ohm transmission path.
So, I don?t know how you get a value of anything other than 120-ohms given that
statement. Also, I think in a previous email you mentioned
that the UNIBUS is 240ohm. It?s not.
It?s 120ohm.
My book says no. Qbus is for sure 120.
TTFN - Guy
25 Oct
25 Oct
4:34 p.m.
On Oct 25, 2016, at 12:40 PM, allison <ajp166 at
verizon.net> wrote:
OK, re-reading the first part of section 5.2.5, it?s pretty clear that the Unibus
is 120-ohm:
A bus terminator is defined as a Unibus element or part of an element containing
a resistive network which connects to the end of a Unibus segment and matches
the 120-ohm characteristic impedance of the Unibus transmission path.
Given that it?s hard to see that the impedance of the Unibus is anything but 120-ohms.
TTFN - Guy
Also, I think in a previous email you mentioned that the UNIBUS is 240ohm. It?s not.
It?s 120ohm.
My book says no. Qbus is for sure 120.
26 Oct
26 Oct
5:49 a.m.
On Tue, 25 Oct 2016, Guy Sotomayor Jr wrote:
OK, re-reading the first part of section 5.2.5, it?s
pretty clear that the Unibus is 120-ohm:
A bus terminator is defined as a Unibus element or part of an element containing
a resistive network which connects to the end of a Unibus segment and matches
the 120-ohm characteristic impedance of the Unibus transmission path.
Or to cite another source: PDP11 Bus Handbook page 76 says
"A bus segment consists of a terminator, a 120-ohm transmission path
(cable) with options having drivers and receivers, and another terminator
(in that order)."
Christian
25 Oct
25 Oct
4:35 p.m.
On 10/25/2016 8:02 AM, Guy Sotomayor Jr wrote:
Where do you get your stock?
On Oct 24, 2016, at 11:35 PM, ben <bfranchuk
at jetnet.ab.ca> wrote:
On 10/24/2016 2:18 PM, David Bridgham wrote:
I just posted what one of my systems is (11/40). It has 128KW of core which
takes 4 9-slot backplanes. I have a fair amount of I/O on that system so I
have 2 BA11F chassis *full* of backplanes (each BA11F holds 5 9 slot backplanes).
My other large system is an 11/70 with a BA11K as an expansion box. The whole
point of Unibus was to allow for large configurations.
And I can guarantee you that TTL will *not* work in those systems.
If you want to build boards that will work in a small subset of systems that?s
find?but don?t advertise it as Unibus compatible. I test the boards I produce
in all of my systems (11/20, 11/34, 11/40 and 11/70) and they all use DEC bus
interface chips. On 10/24/2016 01:37 PM, allison wrote:
But who has the big systems now days? The days of 4K core is long gone.
Use TTL and try to keep the systems small. The voltages are based on TTL levels. What are
the unique voltages?
The QBUS spec from the 1979 Bus Handbook (the Unibus levels are the same):
Input low voltage (maximum): 1.3 V
Input high voltage (minimum): 1.7 V
And from the TI datasheet for the 74LS74:
Vil - low-level input voltage 0.8 V (maximum)
Vih - high-level input voltage 2 V (minimum)
So no, the DEC bus voltage levels are not TTL levels. Yeah, TTL might
work on a smaller system but you can see that if you push it out to its
limits, TTL could start getting flaky. That's the kind of bug I'm happy
to have DEC's engineers figure out and not have to track down myself.
TTFN - Guy
Ben.
4:49 p.m.
On Oct 25, 2016, at 1:35 PM, ben <bfranchuk at
jetnet.ab.ca> wrote:
Secondary chip marked (only reputable vendors). I currently have ~2500 8641
and several 100?s of the other variants. Assuming 100% good parts, I have
enough stock to build at least 100 unibus boards (total) of various types that I
have planned.
And to forestall any questions on the topic, no I will not be selling any of the
chips individually. They are there to allow me to build/sell the various Unibus
boards.
TTFN - Guy
If you want to build boards that will work in a small subset of systems that?s
find?but don?t advertise it as Unibus compatible. I test the boards I produce
in all of my systems (11/20, 11/34, 11/40 and 11/70) and they all use DEC bus
interface chips.
Where do you get your stock?
26 Oct
26 Oct
10:02 a.m.
Hi,
On 10/25/2016 10:49 PM, Guy Sotomayor Jr wrote:
Secondary chip marked (only reputable vendors). I
currently have ~2500 8641
and several 100?s of the other variants. Assuming 100% good parts, I have
enough stock to build at least 100 unibus boards (total) of various types that I
have planned.
And to forestall any questions on the topic, no I will not be selling any of the
chips individually. They are there to allow me to build/sell the various Unibus
boards.
Very enlightening.
You're hoarding interface ICs with commercial second thoughts while
deeming any usable alternative as not working crap. Sounds quite coherent!
BTW Why isn't there a separate list "ccbusinterfacechip" where those
recurring 8881 discussions can be separated from the more interesting stuff?
I just can't imagine that it should be a real problem to build working
Unibus equipment without the old chips.
The Unibus design is from 1 9 7 0 (or around that). Just read that
sentence loud.
Kind regards
Philipp
10:14 a.m.
On Oct 26, 2016, at 7:02 AM, Philipp Hachtmann
<hachti at hachti.de> wrote:
Hi,
On 10/25/2016 10:49 PM, Guy Sotomayor Jr wrote:
I?m saying I won?t use another alternative until that alternative has been proven to work
in large scale systems. I have enough troubles with getting my Unibus systems to work
with BC11A cables (which have always been marginal even ?back in the day?). Too much of
the discussions on Unibus interfacing has been ?hey, I?ll use (fill in the blank) chips I
have, it should work?. I?ll shut up about it when someone does an actual engineered
design.
Secondary chip marked (only reputable vendors).
I currently have ~2500 8641
and several 100?s of the other variants. Assuming 100% good parts, I have
enough stock to build at least 100 unibus boards (total) of various types that I
have planned.
And to forestall any questions on the topic, no I will not be selling any of the
chips individually. They are there to allow me to build/sell the various Unibus
boards.
Very enlightening.
You're hoarding interface ICs with commercial second thoughts while deeming any
usable alternative as not working crap. Sounds quite coherent!
BTW Why isn't there a separate list
"ccbusinterfacechip" where those recurring 8881 discussions can be separated
from the more interesting stuff?
I just can't imagine that it should be a real problem to build working Unibus
equipment without the old chips.
Because AFAIK, no one has done the actual engineering to come up with reliable
replacements. As I said, until that?s done I?ll stick with the old chips.
BTW, with modern designs (i.e. 3.3v I/Os) using the old interface chips is a pain. First
they?re 5v I/Os and 2nd they don?t do tri-state. So you need a 2nd set of interface chips
that are 5v tolerant and convert the I/Os (at least the ones you care about to tri-state.
I spend more board area and parts count on interfacing to the Unibus than actually
implementing what I want. For example, the MEM11A board has 3 active parts that are
actually doing the work, all of the rest of the board and parts (over a dozen) are for
interfacing to the unibus.
TTFN - Guy
10:18 a.m.
On 26 October 2016 at 10:02, Philipp Hachtmann <hachti at hachti.de> wrote:
BTW Why isn't there a separate list
"ccbusinterfacechip" where those
recurring 8881 discussions can be separated from the more interesting stuff?
The discussion is enlightening. It would be nice, however, to
summarize the various conclusions into, say, a Wiki page (isn't there
a classic computers Wiki out there?). That way the discussion needn't
be rehashed ever so often like it always does.
Cheers,
Christian
--
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.
10:28 a.m.
On Oct 26, 2016, at 9:18 AM, Christian Gauger-Cosgrove
<captainkirk359 at gmail.com> wrote:
On 26 October 2016 at 10:02, Philipp Hachtmann <hachti at hachti.de> wrote:
See www.brouhaha.com/~eric/retrocomputing/dec/interfacing/chips.html
<http://www.brouhaha.com/~eric/retrocomputing/dec/interfacing/chips.html> for
starters
Jerry
BTW Why isn't there a separate list
"ccbusinterfacechip" where those
recurring 8881 discussions can be separated from the more interesting stuff?
The discussion is enlightening. It would be nice, however, to
summarize the various conclusions into, say, a Wiki page (isn't there
a classic computers Wiki out there?). That way the discussion needn't
be rehashed ever so often like it always does.
25 Oct
25 Oct
11:23 a.m.
On Tue, Oct 25, 2016 at 2:35 AM, ben <bfranchuk at jetnet.ab.ca> wrote:
But who has the big systems now days?
Me.
The days of 4K core is long gone.
I have Unibus machines that were 8 or more "system units" (DD11CK
equivalents), and a PDP-11/20 that takes up 3 BA-11 boxes. 60% of it
is 4K core stacks, BTW, just like the day it was made in 1972. It
only has a handful of peripherals (console, RK11, LP11...)
Use TTL and try to keep the systems small.
That's great if one is cobbling together a new system, but it doesn't
help when one is trying to breathe life into an existing system by
adding a modern peripheral because ancient disks are no longer
reasonably available.
-ethan
23 Oct
23 Oct
4:57 p.m.
On 2016-10-23 2:50 PM, shadoooo wrote:
Hello,
surely the old transceivers are the most compatible solution, however you
still need to convert the voltages back and forth...
Plus the solution is not the cheaper, and a little uncomfortable too, as
you need to find these old chips, hoping not to buy fake chinese duplicates
(it happened to me more time unfortunately).
So I was searching a solution with modern components, but not using
components too much specific and difficult to be found.
As we need 3.3v logic, but able to work in 5v bus, I'm thinking about 5v
tolerant standard logic as TI LVC or LVT.
The problem is that there aren't open drain bus transceivers, but the
problem could be solved simply using input-only and output-only components,
connecting two in parallel but opposite direction on bidirectional pins.
So identifying one or maybe two codes would be enough for all the
components needed for the board.
The idea of using bare transistors seems to me too much simple.
Not that it couldn't work, but it would be almost impossible to satisfy all
the specifications of the bus in this way... unless you use a more complex
circuit with precise current sources and resistors to grant correct voltage
biases, impedances and slew rates, which in the end is a logic integrated
circuit.
Andrea
As an electronics noob, I'm really waiting for somebody to publish their
findings on this, comprehensively, so I can steal their labour.
Has anyone done so? Is anyone planning to do so? I know that this topic
flares up on the list every 6 months ago in a series of disjointed posts
and observations. The gold is hard to find (especially for aforesaid noobs).
--Toby
5:35 p.m.
On 10/23/2016 04:57 PM, Toby Thain wrote:
On 2016-10-23 2:50 PM, shadoooo wrote:
Toby,
I've watched many flail on this when simple solutions work. They seem
to read into the driver/receiver
specs a lot of imagined should be x when its simple. The specs are
those of Utilogic and TTL of the day.
DEC buses relied on two things; pull-ups to assert the high voltage
level and a strong pull down to ground
at low cost. All of this was developed in the late 60s and early 70s.
To add to that the idea of open
collector was to prevent damage if two drivers asserted the same
line. Also in some cases to allow
wired OR logic. We forget that a transceiver in 1970 was the level of
complex logic and the only thing
more complex was a flipflop as around then the tech was not there for
more than a handful of transistors
on the die. By time the tech could do more the parts were firmly
entrenched and provided the basic
bits often needed.
DEC always suggested their part for the base reason is they work, there
were examples in use to study
and internal engineering was expected to! That and if a customer needed
DEC support it was easier.
I keep my supply of those for board repair. For new boards I make for
myself (QBUS or Omnibus) I use
bog simple 74LS14, 74LS240, 74LS241, 74LS245 and occasionally a open
collector part like 7438.
The 3.3 volt problem is modern logic and not modern in conflict. The
trick in engineering around that
is to keep the interfaces limited to reduce the needed transitions back
and forth.
Allison
Former MilRat
Hello,
surely the old transceivers are the most compatible solution, however
you
still need to convert the voltages back and forth...
Plus the solution is not the cheaper, and a little uncomfortable too, as
you need to find these old chips, hoping not to buy fake chinese
duplicates
(it happened to me more time unfortunately).
So I was searching a solution with modern components, but not using
components too much specific and difficult to be found.
As we need 3.3v logic, but able to work in 5v bus, I'm thinking about 5v
tolerant standard logic as TI LVC or LVT.
The problem is that there aren't open drain bus transceivers, but the
problem could be solved simply using input-only and output-only
components,
connecting two in parallel but opposite direction on bidirectional pins.
So identifying one or maybe two codes would be enough for all the
components needed for the board.
The idea of using bare transistors seems to me too much simple.
Not that it couldn't work, but it would be almost impossible to
satisfy all
the specifications of the bus in this way... unless you use a more
complex
circuit with precise current sources and resistors to grant correct
voltage
biases, impedances and slew rates, which in the end is a logic
integrated
circuit.
Andrea
As an electronics noob, I'm really waiting for somebody to publish
their findings on this, comprehensively, so I can steal their labour.
Has anyone done so? Is anyone planning to do so? I know that this
topic flares up on the list every 6 months ago in a series of
disjointed posts and observations. The gold is hard to find
(especially for aforesaid noobs).
--Toby
24 Oct
24 Oct
12:01 p.m.
On Oct 23, 2016, at 2:50 PM, shadoooo <shadoooo at
gmail.com> wrote:
...
The idea of using bare transistors seems to me too much simple.
Not that it couldn't work, but it would be almost impossible to satisfy all
the specifications of the bus in this way... unless you use a more complex
circuit with precise current sources and resistors to grant correct voltage
biases, impedances and slew rates, which in the end is a logic integrated
circuit.
I don't know about the receiver part, but I'd expect that the drivers could very
easily be done with a simple transistor circuit. After all, that's what an open
collector (or open drain) driver is, in essence. And the spec is quite straightforward,
it demands an adequate current sinking capacity which is easy to meet. As for slew rates,
unless you have antique transistors, that's not going to be an issue given that you
meet the current sink spec; the slew rate of an OC circuit is determined by the system
capacitance and the sink current of the driver.
Some fiddling with SPICE should yield simple answers here.
paul
3:55 p.m.
On 10/24/2016 12:01 PM, Paul Koning wrote:
I don't know about the receiver part, but I'd
expect that the drivers could very easily be done with a simple transistor circuit.
Agreed. However ...
As for slew rates, unless you have antique
transistors, that's not going to be an issue given that you meet the current sink
spec; the slew rate of an OC circuit is determined by the system capacitance and the sink
current of the driver.
I think you read this part backwards. The slew rate requirement is not
a minimum slew rate but a maximum one. That is, any modern transistor
(probably ancient ones too) will be way too fast. You have to do
something to slow it down. Still, I think this one is easily met as
it's just a series resistor on the gate of the driver MOSFET working
against the gate capacitance. Some FPGAs have current limiting on their
output which may obviate the need for the resistor even.
The receiver though, that one takes a little more thought.
4:30 p.m.
On Oct 24, 2016, at 3:55 PM, David Bridgham <dab at
froghouse.org> wrote:
On 10/24/2016 12:01 PM, Paul Koning wrote:
I don't see any max slew rate spec in the driver specs in the peripherals handbook.
paul
I don't know about the receiver part, but
I'd expect that the drivers could very easily be done with a simple transistor
circuit.
Agreed. However ...
As for slew rates, unless you have antique
transistors, that's not going to be an issue given that you meet the current sink
spec; the slew rate of an OC circuit is determined by the system capacitance and the sink
current of the driver.
I think you read this part backwards. The slew rate requirement is not
a minimum slew rate but a maximum one. That is, any modern transistor
(probably ancient ones too) will be way too fast. You have to do
something to slow it down. Still, I think this one is easily met as
it's just a series resistor on the gate of the driver MOSFET working
against the gate capacitance. Some FPGAs have current limiting on their
output which may obviate the need for the resistor even.
4:35 p.m.
On Oct 24, 2016, at 1:30 PM, Paul Koning
<paulkoning at comcast.net> wrote:
OK, I guess my last email didn?t make it. It appears to me that the rise time is set at
25ns.
You need to look at the PDP-11 UNIBUS Design Description document on Bitsavers. Firstly,
in section 4-1, it specifies which chips to use and recommends not using a whole list of
other
chips. The only recommended chips are: 8640, 8641 and 8881.
There are a number of rules that must be adhered to when building out a Unibus system.
These
include:
Maximum cable length must be < 50?
Maximum DC loading < 20
Maximum lumped loading < 20
There are rules where cable lengths must be *increased* to avoid reflections.
A single Unibus can be divided into multiple segments. Each segment must adhere to the
above
rules, so you can see that a Unibus can be quite large.
For example, my PDP-11/40 resides in 2 BA11-F boxes (23? tall) and are fully populated
with
Unibus backplanes (5 9 slot backplanes each) with a BA11-15 (15? cable) connecting the
two.
My point here is that the Unibus has a very different electrical environment than Q-bus or
Omnibus
and what may work for them will probably have troubles on a Unibus.
TTFN - Guy
On Oct 24, 2016, at 3:55 PM, David Bridgham
<dab at froghouse.org> wrote:
On 10/24/2016 12:01 PM, Paul Koning wrote:
I don't see any max slew rate spec in the driver specs in the peripherals handbook.
I don't know about the receiver part, but
I'd expect that the drivers could very easily be done with a simple transistor
circuit.
Agreed. However ...
As for slew rates, unless you have antique
transistors, that's not going to be an issue given that you meet the current sink
spec; the slew rate of an OC circuit is determined by the system capacitance and the sink
current of the driver.
I think you read this part backwards. The slew rate requirement is not
a minimum slew rate but a maximum one. That is, any modern transistor
(probably ancient ones too) will be way too fast. You have to do
something to slow it down. Still, I think this one is easily met as
it's just a series resistor on the gate of the driver MOSFET working
against the gate capacitance. Some FPGAs have current limiting on their
output which may obviate the need for the resistor even.
4:41 p.m.
On Oct 24, 2016, at 4:35 PM, Guy Sotomayor Jr <ggs
at shiresoft.com> wrote:
Sure. But we're trying to understand what is required in order to design
alternatives.
Where do you see the 25 ns spec? I didn't see it (admittedly in a quick scan).
paul
...
OK, I guess my last email didn?t make it. It appears to me that the rise time is set at
25ns.
You need to look at the PDP-11 UNIBUS Design Description document on Bitsavers.
Firstly,
in section 4-1, it specifies which chips to use and recommends not using a whole list of
other
chips. The only recommended chips are: 8640, 8641 and 8881.
4:48 p.m.
On Oct 24, 2016, at 1:41 PM, Paul Koning
<paulkoning at comcast.net> wrote:
5.2.7. It?s discussing the AC loading as a percentage of the risetime (25ns) to allow for
the
reflections.
Yes, all I?m saying is that folks have been looking at OMNIBUS and QBUS and those are
much simpler electrical environments than UNIBUS. You really need to pay attention to
the fact that UNIBUS is really a set of transmission lines so in addition to critical
levels
and currents you need to worry about the transmission line effects (ie the AC
components).
TTFN - Guy
On Oct 24, 2016, at 4:35 PM, Guy Sotomayor Jr
<ggs at shiresoft.com> wrote:
Sure. But we're trying to understand what is required in order to design
alternatives.
Where do you see the 25 ns spec? I didn't see it (admittedly in a quick scan).
...
OK, I guess my last email didn?t make it. It appears to me that the rise time is set at
25ns.
You need to look at the PDP-11 UNIBUS Design Description document on Bitsavers.
Firstly,
in section 4-1, it specifies which chips to use and recommends not using a whole list of
other
chips. The only recommended chips are: 8640, 8641 and 8881.
25 Oct
25 Oct
4:09 p.m.
On Oct 24, 2016, at 4:48 PM, Guy Sotomayor Jr <ggs
at shiresoft.com> wrote:
That seems more like a "for illustration" than an actual specification.
...
Where do you see the 25 ns spec? I didn't see it (admittedly in a quick scan).
5.2.7. It?s discussing the AC loading as a percentage of the risetime (25ns) to allow
for the
reflections. Yes, all I?m saying is that folks have been looking at
OMNIBUS and QBUS and those are
much simpler electrical environments than UNIBUS. You really need to pay attention to
the fact that UNIBUS is really a set of transmission lines so in addition to critical
levels
and currents you need to worry about the transmission line effects (ie the AC
components).
Sure. But whether you look at it as a transmission line or not, in the final analysis
there should be a small set of receiver and driver specs that matter. In theory, they
should be the ones listed in the DEC documents, neither more nor less. In practice, there
might be unspecified ones, such as max slew rate. If so, that's easy enough to handle
by introducing a suitable RC at the driver base (or gate).
As for the receiver, it seems that a TI 75140 (adjustable threshold line receiver) might
do the job.
paul
4:31 p.m.
On Oct 25, 2016, at 1:09 PM, Paul Koning
<paulkoning at comcast.net> wrote:
Maybe, but when you read section 5.2.7 of the PDP-11 Unibus specification:
Nine lumped ac loads reflect 20 precent, and 20 lumped ac loads reflect 40 percent of
a 25 ns risetime step.
On Oct 24, 2016, at 4:48 PM, Guy Sotomayor Jr
<ggs at shiresoft.com> wrote:
That seems more like a "for illustration" than an actual specification.
...
Where do you see the 25 ns spec? I didn't see it (admittedly in a quick scan).
5.2.7. It?s discussing the AC loading as a percentage of the risetime (25ns) to allow
for the
reflections. Yes, all I?m saying is that folks have been
looking at OMNIBUS and QBUS and those are
much simpler electrical environments than UNIBUS. You really need to pay attention to
the fact that UNIBUS is really a set of transmission lines so in addition to critical
levels
and currents you need to worry about the transmission line effects (ie the AC
components).
Sure. But whether you look at it as a transmission line or not, in the final analysis
there should be a small set of receiver and driver specs that matter. In theory, they
should be the ones listed in the DEC documents, neither more nor less. In practice, there
might be unspecified ones, such as max slew rate. If so, that's easy enough to handle
by introducing a suitable RC at the driver base (or gate).
As for the receiver, it seems that a TI 75140 (adjustable threshold line receiver) might
do the job.
4:36 p.m.
On Oct 25, 2016, at 4:31 PM, Guy Sotomayor Jr <ggs
at shiresoft.com> wrote:
That's my point. It says "a 25 ns risetime step". Not "THE 25 ns
risetime step". Nor "at the minimum 25 ns risetime step". So it seems to
be illustrative: if in your particular config the risetime happens to be that, the example
holds.
The obvious question to ask is what the bus capacitance is, between the module
contributions, and the distributed capacitance of the cable. That would explain (in
part) the risetime. The other part would be the inherent risetime of the TTL components
of the era, which are somewhere in that range judging by some of the old datasheets
I've just been looking at.
paul
On Oct 25, 2016, at 1:09 PM, Paul Koning
<paulkoning at comcast.net> wrote:
Maybe, but when you read section 5.2.7 of the PDP-11 Unibus specification:
Nine lumped ac loads reflect 20 precent, and 20 lumped ac loads reflect 40 percent of
a 25 ns risetime step. On Oct 24, 2016, at 4:48 PM, Guy Sotomayor Jr
<ggs at shiresoft.com> wrote:
That seems more like a "for illustration" than an actual specification. ...
Where do you see the 25 ns spec? I didn't see it (admittedly in a quick scan).
5.2.7. It?s discussing the AC loading as a percentage of the risetime (25ns) to allow
for the
reflections. 
4:36 p.m.
On Tue, Oct 25, 2016 at 2:09 PM, Paul Koning <paulkoning at comcast.net> wrote:
As for the receiver, it seems that a TI 75140
(adjustable threshold line
receiver) might do the job.
The high-level input current spec on that is max 100uA, which exceeds the
DEC specification.
One thing everyone seems to be ignoring is that the DEC leakage current
specifications are for Vcc from 0V to 5.25V. In other words, Unibus devices
can't load the bus more when they're not powered. Almost all proposed
alternatives to the DEC-recommended chips do not meet that requirement.
7:37 p.m.
On Oct 25, 2016, at 4:36 PM, Eric Smith <spacewar
at gmail.com> wrote:
On Tue, Oct 25, 2016 at 2:09 PM, Paul Koning <paulkoning at comcast.net> wrote:
True.
I guess a better option might be a voltage comparitor with FET input. The LT1011 would be
an example except that it isn't quite fast enough. Or a voltage follower before the
75140, at the expense of higher part count.
As for the receiver, it seems that a TI 75140
(adjustable threshold line
receiver) might do the job.
The high-level input current spec on that is max 100uA, which exceeds the
DEC specification. One thing everyone seems to be ignoring is that the
DEC leakage current
specifications are for Vcc from 0V to 5.25V. In other words, Unibus devices
can't load the bus more when they're not powered. Almost all proposed
alternatives to the DEC-recommended chips do not meet that requirement.
I don't see any such requirement in the spec. And it would be odd to have one; I
can't think of anyone who would expect a PDP11 to work with part of its devices
powered down. For one thing, if the box with the terminator loses power, you don't
just have unpowered I/O cards, you have no power on the terminator.
paul
9:58 p.m.
On 10/25/2016 03:36 PM, Eric Smith wrote:
On Tue, Oct 25, 2016 at 2:09 PM, Paul Koning
<paulkoning at comcast.net> wrote:
I believe this is a holdover from the PDP-8 days. I do not
know of any PDP-11 system that would actually tolerate a
Unibus peripheral being powered down in the middle of the
bus. I am pretty sure that due to the bus grant logic
present on nearly every peripheral controller, that powering
it down would jam the bus.
So, I suspect that for a PDP-11 or VAX Unibus system, this
requirement does not really make much sense.
Jon
As for the receiver, it seems that a TI 75140
(adjustable threshold line
receiver) might do the job.
The high-level input current spec on that is max 100uA, which exceeds the
DEC specification.
One thing everyone seems to be ignoring is that the DEC leakage current
specifications are for Vcc from 0V to 5.25V. In other words, Unibus devices
can't load the bus more when they're not powered. Almost all proposed
alternatives to the DEC-recommended chips do not meet that requirement.
5:25 a.m.
On Mon, 24 Oct 2016, Paul Koning wrote:
I have the 1979 edition of the PDP11 Bus Handbook in front of me. This
book is very handy as all information on the Unibus and QBUS can be found
there. The driver and receiver characteristics are listed in table 1-3 on
page 60. The only timing parameters for the drivers are the maximum
_propagation_ delays (25ns TPDL and 35ns TPDH), so I interprete this that
the drivers can be faster than that, and no single word about slew rates.
For the QBUS drivers, page 125 specifies the rise/fall times: 10ns<=t<=1?s
There is no such equivalent for the Unibus.
Christian
You need to
look at the PDP-11 UNIBUS Design Description document on
Bitsavers. Firstly, in section 4-1, it specifies which chips to use
and recommends not using a whole list of other chips. The only
recommended chips are: 8640, 8641 and 8881.
Sure. But we're trying to understand what is required in order to
design alternatives. Where do you see the 25 ns spec? I didn't see it
(admittedly in a quick scan).
24 Oct
24 Oct
6:30 p.m.
On Mon, Oct 24, 2016 at 4:35 PM, Guy Sotomayor Jr <ggs at shiresoft.com> wrote:
OK, I guess my last email didn?t make it. It appears
to me that the rise time is set at 25ns.
You need to look at the PDP-11 UNIBUS Design Description document on Bitsavers.
Firstly,
in section 4-1, it specifies which chips to use and recommends not using a whole list of
other
chips. The only recommended chips are: 8640, 8641 and 8881.
We used 8641s on our Unibus COMBOARDs (which weren't built cheaply -
$2500 MSRP in 1984). We also used a pair of DEC DC013s for "Unibus
Interrupt Logic" (and they were somewhat expensive, IIRC, but we used
them to minimize compatibility problems. Customer confidence was
worth a couple hundred bucks in parts and engineering overhead). We
likewise went with DEC chips for our Qbus product - we bought the DEC
Chipkits and used about 75% of them - the DC005s for sure, and I think
the DC010s, but didn't use the DC004s, IIRC. Either way, everything
touching the bus went through a DEC chip.
There are a number of rules that must be adhered to
when building out a Unibus system. These
include:
Maximum cable length must be < 50?
Maximum DC loading < 20
Maximum lumped loading < 20
There are rules where cable lengths must be *increased* to avoid reflections.
For example, my PDP-11/40 resides in 2 BA11-F boxes (23? tall) and are fully populated
with
Unibus backplanes (5 9 slot backplanes each) with a BA11-15 (15? cable) connecting the
two.
We ran machines in the 80s that were not quite as extensive, but one I
recall well was our primary 11/750 with the internal DD11DK full of
cards (UDA50, and a few other things), then a 25' BC11 cable to a
single BA11-K with 3X DD11DK that were full or nearly full - mostly in
that box were the Emulex CS21F 16-port serial cards (at least 5), any
Unibus tape controllers, up to 6 of our COMBOARDs, at least one DMR11,
and a handful of quad SPCs. It all seemed to play nicely, but we
weren't running close to maxed out. Most of our other machines had
1-2 DD11DK outside of the CPU backplane but not nearly as many cards
or bus traffic. We never had any Ethernet hardware, so all of our
sessions were handled via local serial ports. Lots of serial ports.
-ethan
4:56 p.m.
On 10/24/2016 04:30 PM, Paul Koning wrote:
I don't see any max slew rate spec in the driver
specs in the peripherals handbook.
For the QBUS from the PDP11 Bus Handbook 1979, page 125:
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 us
It's faster than the Unibus (that Guy posted) presumably because QBUS
systems tend to be much smaller but a driver that meets the Unibus spec
is good on the QBUS too.
On the receiver, maybe the way to go would be a linear comparator. It
would be easy enough to come up with a 1.5V rail (half way between the
1.3V low and 1.7V high levels) running down the length. And you have to
look but you can find them with a fast enough propagation speed. The
only thing I'm not seeing is meeting the 10pF capacitive load; the spec
sheets just don't say.
Dave
6:54 p.m.
On 10/24/2016 03:55 PM, David Bridgham wrote:
On 10/24/2016 12:01 PM, Paul Koning wrote:
It is set by bus loading card and input to
devices contribute
capacitance and
pull-up current. The rule is what you do does not break the system not
individual boards those they must be compliant.
I don't know about the receiver part, but
I'd expect that the drivers could very easily be done with a simple transistor
circuit.
Agreed. However ...
As for slew rates, unless you have antique
transistors, that's not going to be an issue given that you meet the current sink
spec; the slew rate of an OC circuit is determined by the system capacitance and the sink
current of the driver.
I think you read this part backwards. The slew rate
requirement is not
a minimum slew rate but a maximum one. That is, any modern transistor
(probably ancient ones too) will be way too fast. You have to do
something to slow it down.
NO no no! The old 2n706 and 2n3638 (mid 60s silicon
parts) are ancient
and still too fast if that were the case. Its the product of the bus
loading
the saturation characteristics of the device. In all cases the active low
impedance is less than 20 ohms (much less).
Still, I think this one is easily met as
it's just a series resistor on the gate of the driver MOSFET working
against the gate capacitance. Some FPGAs have current limiting on their
output which may obviate the need for the resistor even.
Actually the Drain of a
fet is already loaded with capcitance, look at
their spec's.
Also MOSFETs (trench, hex, or lateral) also have a diode present as well
as a
finite drain resistance. A series resistor on the gate would seriously
impact
switching time and propagation delay due to Miller capcitance.
The best device is a venerable 2n3904 plus maybe 10 ohms on the collector.
That will easily sink the max 20 loads of the spec with room to spare.
the Qbus is actually harder than Unibus as it can and is extended plus data
and address are multiplex on the same lines which are 120 ohm transmission
lines for speed where the Unibus is 240ohms. The higher the impedance the
grated the sensitivity to capacitive loading. Omnibus is a special case
as some
devices can Wire-OR data onto the bus and an active pull-up device would be
unhappy with that.
The receiver though, that one takes a little more
thought.
Now the input is a device with hysteresis and there are plenty of TTL
devices
that fit in that space and would do well. MOS/CMOS is not god as it high
input
Capacitance and a sensitive to latchup (negative spike from the lines
ringing).
The DEC 8xxx part is like a 7438 for outgoing and 7414 for incoming is the
inversion is wrong there are compliments. That would be one transceiver
in the package.
My sources include the DEC semiconductor data manual and the Omni/Uni/Q/bus
interfacing manuals. Most in several editions over time. That and
prints for
everything I own thanks to Mill Repro. This information is part of the
design
toolkit.
Allison
1:10 p.m.
On 10/23/16 2:50 PM, shadoooo wrote:
Hello,
surely the old transceivers are the most compatible solution, however you
still need to convert the voltages back and forth...
Plus the solution is not the cheaper, and a little uncomfortable too, as
you need to find these old chips, hoping not to buy fake chinese duplicates
(it happened to me more time unfortunately).
So I was searching a solution with modern components, but not using
components too much specific and difficult to be found.
As we need 3.3v logic, but able to work in 5v bus, I'm thinking about 5v
tolerant standard logic as TI LVC or LVT.
The problem is that there aren't open drain bus transceivers, but the
problem could be solved simply using input-only and output-only components,
connecting two in parallel but opposite direction on bidirectional pins.
So identifying one or maybe two codes would be enough for all the
components needed for the board.
The idea of using bare transistors seems to me too much simple.
Not that it couldn't work, but it would be almost impossible to satisfy all
the specifications of the bus in this way... unless you use a more complex
circuit with precise current sources and resistors to grant correct voltage
biases, impedances and slew rates, which in the end is a logic integrated
circuit.
To the last point.... The output of the DEC drivers are simply bare
transistors that
had to meet a minimum spec for saturation current/voltage and minimum speed
for the votlage and power of the device. Modern transistor arrays
would be the
first choice for that. To make it more complex than that is
unrealistic and
misses what those old devices were (hint: dirt simple, and somewhat slow,
best of the norm for the day). Just look at the internal circuits for
the devices
They are not complex and look much like open collector TTL on the bus side.
They did not include current sources, and bias systems. They are not
impedence
controlled nor slew rate controlled save for they were fast for the day
and there
were slower!
Line receivers any of the devices like LS241 or LS241 have hysteris on
the inputs and are
a good match to acceptable bus voltages. I believe there are CMOS
equivilents for that
as well. I've used the bipolar LS TTL parts rather than CMOS as they
have immunity to
latchup and are somewhat more resistant to ESD.
Allison
Andrea
2:08 p.m.
New subject: Fwd: Re: DEC bus transceivers
having half of this conversation not making it from cctech to cctalk is really starting to
piss me off
-------- Forwarded Message --------
Subject: Re: DEC bus transceivers
Date: Mon, 24 Oct 2016 13:10:21 -0400
From: allison <ajp166 at verizon.net>
Reply-To: General Discussion: On-Topic Posts <cctech at classiccmp.org>
To: General Discussion: On-Topic Posts <cctech at classiccmp.org>
On 10/23/16 2:50 PM, shadoooo wrote:
Hello,
surely the old transceivers are the most compatible solution, however you
still need to convert the voltages back and forth...
Plus the solution is not the cheaper, and a little uncomfortable too, as
you need to find these old chips, hoping not to buy fake chinese duplicates
(it happened to me more time unfortunately).
So I was searching a solution with modern components, but not using
components too much specific and difficult to be found.
As we need 3.3v logic, but able to work in 5v bus, I'm thinking about 5v
tolerant standard logic as TI LVC or LVT.
The problem is that there aren't open drain bus transceivers, but the
problem could be solved simply using input-only and output-only components,
connecting two in parallel but opposite direction on bidirectional pins.
So identifying one or maybe two codes would be enough for all the
components needed for the board.
The idea of using bare transistors seems to me too much simple.
Not that it couldn't work, but it would be almost impossible to satisfy all
the specifications of the bus in this way... unless you use a more complex
circuit with precise current sources and resistors to grant correct voltage
biases, impedances and slew rates, which in the end is a logic integrated
circuit.
To the last point.... The output of the DEC drivers are simply bare
transistors that
had to meet a minimum spec for saturation current/voltage and minimum speed
for the votlage and power of the device. Modern transistor arrays would be the
first choice for that. To make it more complex than that is unrealistic and
misses what those old devices were (hint: dirt simple, and somewhat slow,
best of the norm for the day). Just look at the internal circuits for the devices
They are not complex and look much like open collector TTL on the bus side.
They did not include current sources, and bias systems. They are not impedence
controlled nor slew rate controlled save for they were fast for the day and there
were slower!
Line receivers any of the devices like LS241 or LS241 have hysteris on the inputs and are
a good match to acceptable bus voltages. I believe there are CMOS equivilents for that
as well. I've used the bipolar LS TTL parts rather than CMOS as they have immunity
to
latchup and are somewhat more resistant to ESD.
Allison
Andrea
3:26 p.m.
New subject: cctech vs cctalk issues / was Re: DEC bus transceivers
I'm still getting duplicates from cctech: I'm registered to cctalk but for many
messages, a day after it appears via cctalk, the same message shows up from cctech - this
has been going on since the list crash a year or two ago.
It seems to be the messages that were sent to cctech.
It gets annoying when a block of 20 messages comes in and you have to read through them
all to realise you've already seen them.
I thought the outcome of conversation of these issues after the list crash was cctech was
going to be eliminated/amalgamated. Having the two lists may be resulting in more
detriment than benefit.
On 2016-Oct-24, at 11:08 AM, Al Kossow wrote:
having half of this conversation not making it from
cctech to cctalk is really starting to piss me off
2898
days inactive
2901
days old
45 comments
18 participants
participants (18)
-
aek＠bitsavers.org -
ajp166＠verizon.net -
bfranchuk＠jetnet.ab.ca -
captainkirk359＠gmail.com -
cc＠informatik.uni-stuttgart.de -
dab＠froghouse.org -
elson＠pico-systems.com -
ethan.dicks＠gmail.com -
ggs＠shiresoft.com -
hachti＠hachti.de -
hilpert＠cs.ubc.ca -
jsw＠ieee.org -
north＠alum.mit.edu -
paulkoning＠comcast.net -
pete＠petelancashire.com -
shadoooo＠gmail.com -
spacewar＠gmail.com -
toby＠telegraphics.com.au