Re: DEC bus transceivers

2016-10-31 Thread Paul Anderson
I have thousands of NOS chips here that i hope to finish going through. I
have no idea how many bus transceivers are in there. These were intended
for projects I don't know if I'll ever get around to.

There are a lot of NOS out there at a variety of prices. The common 74xx
are mostly there and fairly cheap. I have several thousand ECLs I have
little use for, and they are getting harder to find.

As far as the DEC chips go, I figured if I ever ran out I would pull them
off of boards that I have a lots of extras.

It's been years since I've looked at the prints, but I should be able to
find some DEC transceivers on boards like DZ11, MS11, MSV11, M3106, M3107,
various omnibus boards etc.

I know is sounds terrible, but I can cut the fingers off, sell the board
for the chips, and make some room which i desperately need.

Paul


On Mon, Oct 31, 2016 at 10:12 AM, Noel Chiappa 
wrote:

> > From: Philipp Hachtmann
>
> > that one posting sounded a lot like that, sorry.
>
> OK.
>
> > Do you have a source where there are still 30k chips sitting and
> > waiting?
>
> It was ~30K a couple of months ago. I checked about a week ago, and it was
> down to ~26K (IIRC).
>
> Although, like I said, I doubt they have all 26K in stock themselves;
> based on
> comments they made when we bought a large group, I think that's the total
> number available to them across a number of suppliers, in a network which
> shares inventory information.
>
> Noel
>


Re: DEC bus transceivers

2016-10-31 Thread Noel Chiappa
> From: Philipp Hachtmann

> that one posting sounded a lot like that, sorry.

OK.

> Do you have a source where there are still 30k chips sitting and
> waiting?

It was ~30K a couple of months ago. I checked about a week ago, and it was
down to ~26K (IIRC).

Although, like I said, I doubt they have all 26K in stock themselves; based on
comments they made when we bought a large group, I think that's the total
number available to them across a number of suppliers, in a network which
shares inventory information.

Noel


Re: DEC bus transceivers

2016-10-31 Thread Philipp Hachtmann



On 10/26/2016 04:54 PM, Noel Chiappa wrote:

> From: Philipp Hachtmann

> Very enlightening.
> You're hoarding interface ICs with commercial second thoughts

If you think either Guy, or Dave and I, expect to make much money selling the
QBUS/UNIBUS boards we are working on, you are seriously confused. None of us
are in this as a money-making exercise; there are easier ways to make a lot
more money.
It's not really what I expected. But that one posting sounded a lot like 
that, sorry.



And as to the hoarding, if you'd like to buy up a couple of thousand yourself,
from that miniscule stockpile of 30K units that Guy and I have left out there
for you all, please let me know, and I'll expidite over a name, phone number,
and email for you to contact.


What does that mean? Do you have a source where there are still 30k 
chips sitting and waiting? Sounds interesting!


Kind regards

Philipp



--


Re: DEC bus transceivers

2016-10-29 Thread steven
Hi all,
   On my road trip earlier this year one of the docs I snagged was a ring 
binder of Foxboro
Integrated Circuits dated 10/73, Revision A, one of 200 copies. It covers chip 
characteristics
and compatibility cross references.
This was part of the doc set for the Foxboro FOX 2/10 (PDP-11/15) about which 
more is to come.

Anyway from this I've just scanned and pdf'd the pages for the DEC 8881, which 
Foxboro called
the C3313AB. The first page is the relevant cross-reference to other 
manufacturers. I'm sure this
is already on bitsavers somewhere (what isn't :) but hey what the heck, the 
more the merrier. The
only other DEC-specific IC that is covered is the 380A.

It's at 
http://web.aanet.com.au/~malikoff/pdp11/DEC_8881_transceiver_IC_Foxboro_pn_C3313AB.pdf

Steve.



Re: DEC bus transceivers

2016-10-26 Thread allison
On 10/26/2016 12:40 PM, Noel Chiappa wrote:
> Re: DEC bus transceivers
> > From: allison
>
> > Actually since about 1987 I've used about 1200 pieces of the 8641 alone
> > repairing boards at the commercial level.
>
> Well, that's over almost 30 years - and your total from that period is about
> 4% of the remaining stock (and in a commercial operation, to boot, not
> hobbyist)...
Its also a lot of boards fixed and sold.  It was a good second income.
that has consumed about 40% of what i have and that doesn't include
the rare like DC03/4/5/10 and others some more common like DLART,
T11, DCK-11-series, and w95xx boards.

I had the gift of being a central engineering milrat at DEC.  So many
of the design protocols for many of the DEC buses are hardwired in
my brain.  They were building systems not just boards.

> > If you going to build a board or three maybe even 20 its not a big deal
> > but its not a reliable source of predictable quality.
>
> Sure, but try looking at it from our perspective: we either use an
> out-of-production part, or have to design something (almost certainly from
> discretes) that meets those specs; and we actually looked at the latter (viz.
> Dave B's design). However, after some pondering, and taking everything
> (including all the below) into account, we decided to go with the original
> chips, since they were still sorta available.

If you use the DEC part you don't have to design, its plug and go. 
Design means
you evaluated something and its application and went with it as it met the
defined need.

I've done the latter and have many tubes of parts that work quite well.
All the designs I did that were unique ground up used those as the packages
work as expected.  The key is thresholds and current sink.

Having measured parts both dynamic and static I have a good feel for
what will
work in all but the pathological cases.   For the pathological cases the
biggest
issue is current sink. But like I said there are systems I run and do
not to try
and make meet DEC supportable configuration standards which means
things like third party cards and one-offs  and those that are museum
level stock to the bone.

> Which is why both we and Guy have stocked up on them, at the start of the
> process: we don't want to crank out boards designed for a certain part, and
> then not be able to get the out-of-production parts the boards were designed
> to use.
>
> If we were designing something for serious production, that wouldn't be an
> option, but for limited-volume hobbyist use, it is. The choice of an
> out-of-production part does have a down-side, but it's minor (and mostly
> alleviated by the pre-buying), and the other options were (in overall sum)
> worse.
>
> > If you get to the bridge your talking redesign in reality or an
> > expensive buy from unreliable source then testing them in bulk.
>
> But, but... I'm _already_ buying them from unreliable sources, then testing
> them! :-)

Therein lies the problem.  My purchase was back when the largest network
was still owned by DEC.  and it was the year they were just EOL'ed
(every one
was doing last time buys with lead times of twenty plus weeks.  I've
dealt in
the grey market and  for other things I can say often the profit taking is
extreme and they know the barrel your over.

>
> But to be serious - if the demand for QSIC's, etc, runs the well of DS8641's
> dry, yes, we'll probably have to re-design. In other words, we'd be right
> where we'd be today if we decided not to use out-out-production parts.
Likely the redesign would be more along the line of different package
(maybe smaller) and the odd inversion or not.


Allison





Re: DEC bus transceivers

2016-10-26 Thread allison

On 10/26/16 10:54 AM, Noel Chiappa wrote:

 > From: Philipp Hachtmann

 > Very enlightening.
 > You're hoarding interface ICs with commercial second thoughts

If you think either Guy, or Dave and I, expect to make much money selling the
QBUS/UNIBUS boards we are working on, you are seriously confused. None of us
are in this as a money-making exercise; there are easier ways to make a lot
more money.

I was making money,  not on part but refubished and tested boards.

Allison



And as to the hoarding, if you'd like to buy up a couple of thousand yourself,
from that miniscule stockpile of 30K units that Guy and I have left out there
for you all, please let me know, and I'll expidite over a name, phone number,
and email for you to contact.

Noel





Re: DEC bus transceivers

2016-10-26 Thread Noel Chiappa
Re: DEC bus transceivers
> From: allison

> Actually since about 1987 I've used about 1200 pieces of the 8641 alone
> repairing boards at the commercial level.

Well, that's over almost 30 years - and your total from that period is about
4% of the remaining stock (and in a commercial operation, to boot, not
hobbyist)...

> If you going to build a board or three maybe even 20 its not a big deal
> but its not a reliable source of predictable quality.

Sure, but try looking at it from our perspective: we either use an
out-of-production part, or have to design something (almost certainly from
discretes) that meets those specs; and we actually looked at the latter (viz.
Dave B's design). However, after some pondering, and taking everything
(including all the below) into account, we decided to go with the original
chips, since they were still sorta available.

Which is why both we and Guy have stocked up on them, at the start of the
process: we don't want to crank out boards designed for a certain part, and
then not be able to get the out-of-production parts the boards were designed
to use.

If we were designing something for serious production, that wouldn't be an
option, but for limited-volume hobbyist use, it is. The choice of an
out-of-production part does have a down-side, but it's minor (and mostly
alleviated by the pre-buying), and the other options were (in overall sum)
worse.

> If you get to the bridge your talking redesign in reality or an
> expensive buy from unreliable source then testing them in bulk.

But, but... I'm _already_ buying them from unreliable sources, then testing
them! :-)

But to be serious - if the demand for QSIC's, etc, runs the well of DS8641's
dry, yes, we'll probably have to re-design. In other words, we'd be right
where we'd be today if we decided not to use out-out-production parts.

Noel



Re: DEC bus transceivers

2016-10-26 Thread Mouse
> The trouble with chip resellers is that it's hard to know which ones are leg$

And then there are the periodic mentions of supposed chip vendors who
ask you what package and what pin count when you ask them for a part
that has never existed except in one version.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Re: DEC bus transceivers

2016-10-26 Thread allison

On 10/26/16 7:38 AM, Noel Chiappa wrote:
  


But DS8641's are available in the 10's of thousands, there's no earthly way
we could use them all on repairs. Yes, when they run out, we'll have a
problem - but I plan to cross than bridge _if_ and when we get to it.

Noel

Actually since about 1987 I've used about 1200 pieces of the 8641 alone 
repairing boards
at the commercial level.  Up till recently I had a side business keeping 
commercial in use
pdp-8 and pdp11 system in NC machines.  Subs are not possible in that 
case as its all
about pin out and form factor.  Same for unique no-DEC boards in that 
service.
There is no choice for them, it has to fit the same hole.  And most of 
the 11s were Qbus

as the Unibus machines even minimal sized ones were generally large.

No they are scarce, any parts are NOS(new but old stock) of an out of 
manufacture part.
If you going to build a board or three maybe even 20 its not a big deal 
but its not
a reliable source of predictable quality.If you get to the bridge 
your talking redesign
in reality or an expensive buy from unreliable source then testing them 
in bulk.


Allison


Re: DEC bus transceivers

2016-10-26 Thread Pete Lancashire
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 
wrote:

>
> > On Oct 24, 2016, at 10:37 AM, allison  wrote:
> >
> > On 10/23/16 2:59 PM, Al Kossow wrote:
> >>
> >> On 10/23/16 11:50 AM, shad 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
> 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 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
>
>
>


Re: DEC bus transceivers

2016-10-26 Thread Noel Chiappa
> From: Philipp Hachtmann

> Very enlightening.
> You're hoarding interface ICs with commercial second thoughts

If you think either Guy, or Dave and I, expect to make much money selling the
QBUS/UNIBUS boards we are working on, you are seriously confused. None of us
are in this as a money-making exercise; there are easier ways to make a lot
more money.

And as to the hoarding, if you'd like to buy up a couple of thousand yourself,
from that miniscule stockpile of 30K units that Guy and I have left out there
for you all, please let me know, and I'll expidite over a name, phone number,
and email for you to contact.

Noel


Re: DEC bus transceivers

2016-10-26 Thread Jerry Weiss

> On Oct 26, 2016, at 9:18 AM, Christian Gauger-Cosgrove 
>  wrote:
> 
> On 26 October 2016 at 10:02, Philipp Hachtmann  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.
> 


See www.brouhaha.com/~eric/retrocomputing/dec/interfacing/chips.html 
 for 
starters


Jerry










Re: DEC bus transceivers

2016-10-26 Thread Christian Gauger-Cosgrove
On 26 October 2016 at 10:02, Philipp Hachtmann  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.


Re: DEC bus transceivers

2016-10-26 Thread Guy Sotomayor Jr

> On Oct 26, 2016, at 7:02 AM, Philipp Hachtmann  wrote:
> 
> 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!
> 

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.

> 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

Re: DEC bus transceivers

2016-10-26 Thread Philipp Hachtmann

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




Re: DEC bus transceivers

2016-10-26 Thread Noel Chiappa
> From: Paul Koning

> The trouble with chip resellers is that it's hard to know which ones are
> legit, and which ones are in the fake chip business.

I suspect that the network of major resellers would tend to keep out the
riff-raff. (They don't need the aggro of dealing with the consequences.)

> a 7400 instead of something more valuable.

Which is why it's good that the DS8641's are going for little more than a
buck; at that price point, there's only minimal benefit from faking them.


Anyway, for any I get, random samples go straight into my tester board!
"Trust, but verify!" :-)

Noel


Re: DEC bus transceivers

2016-10-26 Thread Paul Koning

> On Oct 26, 2016, at 9:07 AM, Noel Chiappa  wrote:
> 
>> ...
> 
> So that figure I was given of 30K in stock is probably not from that one
> vendor, but across all of them. But since nobody is using these chips in a
> product (that I know of), I suspect the number is likely to go down only
> slowly.

The trouble with chip resellers is that it's hard to know which ones are legit, 
and which ones are in the fake chip business.  There have been some articles in 
the trade press about chips being sold with false labels, typically with some 
sort of chip inside but not anything like what the number on the outside 
indicated.  You might get a memory chip instead of a microprocessor, for 
example, or a 7400 instead of something more valuable.

paul




Re: DEC bus transceivers

2016-10-26 Thread Noel Chiappa
> From: allison

> What vendor

I don't recall, would have to look it up; I turned Guy onto them, and he
bought out everything they in stock.

> They have been scarce save though resellers that have NOS parts from
> old stocks and they are not cheap and unpredictable quantities.

Yeah, that vendor said they could get more (apparently from others who still
had stocks), but they'd be slightly more expensive. Apparently these people
all interact, and deal stuff around.

So that figure I was given of 30K in stock is probably not from that one
vendor, but across all of them. But since nobody is using these chips in a
product (that I know of), I suspect the number is likely to go down only
slowly.

> Then I could buy them they are about .86 dollar US, but that was in the
> early 80s.

The ones Guy and I recently bought were about $1 each (I don't recall the
exact amount, would have to check). So not cheap, but not ridiculous.

Noel


Re: DEC bus transceivers

2016-10-26 Thread allison

On 10/26/16 7:38 AM, Noel Chiappa wrote:

 > From: Guy Sotomayor

 > Secondary chip marke[t] (only reputable vendors).

I'm a little more willing than Guy to troll in disreputable waters (I bought
1K DS8641's from a source in Hong Kong), so I have this:

   http://ana-3.lcs.mit.edu/~jnc/tech/QSIC/TestCardF.jpg

which has a bunch of special circuits on it to test chips to make sure they
meet specs; e.g. the large potentiometer is so I can vary the input voltage
to see where it switches from 0 to 1, etc.


 > From: Paul Koning

 > 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

Forget the terminator - as Jon Elson also points out (his email appeared
while I was creating this one), any device which uses interrupts, if
un-powered, won't pass grants.


 > From: allison

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

For actual DEC interface IC's like DC003's, sure. Those are hyper-rare.

I have those too.  You need them to maintain DEC cards.
Then again I have a few of the chipkit proto cards too.

But DS8641's are available in the 10's of thousands, there's no earthly way
we could use them all on repairs. Yes, when they run out, we'll have a
problem - but I plan to cross than bridge _if_ and when we get to it.
What vendor and price???  They have been scarce save though resellers 
that have NOS parts from
old stocks and they are not cheap and unpredictable quantities.  TI the 
only source when they consumed
National Semi is the listed source has it as obsolete out of 
production.  The second source Signetics
went away decades ago before Phillips consumed them.  Then I could buy 
them they are about

.86 dollar US, but that was in the early 80s.

Every time I see something written suggesting the the 86xx parts are 
magical I go back to the
databooks (National and Signetics from the 70s and the current TI) and 
find nothing that

special or unique.

If you have them great, when you run out I'm not giving up the supply I 
have from DEC.



Allison

Noel





Re: DEC bus transceivers

2016-10-26 Thread Noel Chiappa
> From: Guy Sotomayor

> Secondary chip marke[t] (only reputable vendors). 

I'm a little more willing than Guy to troll in disreputable waters (I bought
1K DS8641's from a source in Hong Kong), so I have this:

  http://ana-3.lcs.mit.edu/~jnc/tech/QSIC/TestCardF.jpg

which has a bunch of special circuits on it to test chips to make sure they
meet specs; e.g. the large potentiometer is so I can vary the input voltage
to see where it switches from 0 to 1, etc.


> From: Paul Koning

> 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

Forget the terminator - as Jon Elson also points out (his email appeared
while I was creating this one), any device which uses interrupts, if
un-powered, won't pass grants.


> From: allison

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

For actual DEC interface IC's like DC003's, sure. Those are hyper-rare.

But DS8641's are available in the 10's of thousands, there's no earthly way
we could use them all on repairs. Yes, when they run out, we'll have a
problem - but I plan to cross than bridge _if_ and when we get to it.

Noel


Re: DEC bus transceivers

2016-10-26 Thread allison
On 10/25/2016 04:24 PM, Guy Sotomayor Jr wrote:
>> On Oct 25, 2016, at 12:40 PM, allison  wrote:
>>> 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.
>>
> 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.
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


> TTFN - Guy
>
>




Re: DEC bus transceivers

2016-10-26 Thread Christian Corti

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


Re: DEC bus transceivers

2016-10-25 Thread Guy Sotomayor Jr

> On Oct 25, 2016, at 12:40 PM, allison  wrote:
> 
>> 
>> 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.
> 
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



Re: DEC bus transceivers

2016-10-25 Thread Guy Sotomayor Jr

> On Oct 25, 2016, at 12:40 PM, allison  wrote:
>> 
>> 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.
> 

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



Re: DEC bus transceivers

2016-10-25 Thread allison

On 10/25/16 12:10 PM, Guy Sotomayor Jr wrote:

On Oct 25, 2016, at 8:38 AM, allison  wrote:

On 10/25/16 10:02 AM, Guy Sotomayor Jr wrote:

On Oct 24, 2016, at 11:35 PM, ben  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.

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.

My book says no. Qbus is for sure 120.


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


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.
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 
n

Re: DEC bus transceivers

2016-10-25 Thread Jon Elson

On 10/25/2016 03:36 PM, Eric Smith wrote:

On Tue, Oct 25, 2016 at 2:09 PM, Paul Koning  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.

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


Re: DEC bus transceivers

2016-10-25 Thread Paul Koning

> On Oct 25, 2016, at 4:36 PM, Eric Smith  wrote:
> 
> On Tue, Oct 25, 2016 at 2:09 PM, Paul Koning  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.

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.

> 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



Re: DEC bus transceivers

2016-10-25 Thread Guy Sotomayor Jr

> On Oct 25, 2016, at 1:35 PM, ben  wrote:
> 
>> 
>> 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?
> 
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



Re: DEC bus transceivers

2016-10-25 Thread Paul Koning

> On Oct 25, 2016, at 4:31 PM, Guy Sotomayor Jr  wrote:
> 
> 
>> On Oct 25, 2016, at 1:09 PM, Paul Koning  wrote:
>> 
>> 
>>> On Oct 24, 2016, at 4:48 PM, Guy Sotomayor Jr  wrote:
>>> 
>>> 
 ...
 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.
>> 
>> That seems more like a "for illustration" than an actual specification. 
> 
> 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.

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




Re: DEC bus transceivers

2016-10-25 Thread Eric Smith
On Tue, Oct 25, 2016 at 2:09 PM, Paul Koning  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.


Re: DEC bus transceivers

2016-10-25 Thread ben

On 10/25/2016 8:02 AM, Guy Sotomayor Jr wrote:



On Oct 24, 2016, at 11:35 PM, ben  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.

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?


TTFN - Guy


Ben.




Re: DEC bus transceivers

2016-10-25 Thread Guy Sotomayor Jr

> On Oct 25, 2016, at 1:09 PM, Paul Koning  wrote:
> 
> 
>> On Oct 24, 2016, at 4:48 PM, Guy Sotomayor Jr  wrote:
>> 
>> 
>>> ...
>>> 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.
> 
> That seems more like a "for illustration" than an actual specification. 

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

My concern (and I get that the supply of DEC transceivers is limited) is that 
someone will build some thing and says it works in Unibus machines and they’ve 
only tested it in a relatively small system (one BA11K box for example) and it 
will fail miserably (or worse only fail intermittently) in larger systems.

TTFN - Guy



Re: DEC bus transceivers

2016-10-25 Thread Paul Koning

> On Oct 24, 2016, at 4:48 PM, Guy Sotomayor Jr  wrote:
> 
> 
>> ...
>> 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.

That seems more like a "for illustration" than an actual specification. 

> 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



Re: DEC bus transceivers

2016-10-25 Thread allison

On 10/25/16 10:02 AM, Guy Sotomayor Jr wrote:

On Oct 24, 2016, at 11:35 PM, ben  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.


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


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






Re: DEC bus transceivers

2016-10-25 Thread Guy Sotomayor Jr

> On Oct 25, 2016, at 8:38 AM, allison  wrote:
> 
> On 10/25/16 10:02 AM, Guy Sotomayor Jr wrote:
>>> On Oct 24, 2016, at 11:35 PM, ben  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.
> 
> 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.

> 
> 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



Re: DEC bus transceivers

2016-10-25 Thread Ethan Dicks
On Tue, Oct 25, 2016 at 2:35 AM, ben  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


Re: DEC bus transceivers

2016-10-25 Thread Guy Sotomayor Jr

> On Oct 24, 2016, at 11:35 PM, ben  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.

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



Re: DEC bus transceivers

2016-10-25 Thread ben

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.
Ben.




Re: DEC bus transceivers

2016-10-25 Thread allison
On 10/25/2016 02:35 AM, ben 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)
>>

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.
>
Some of the recovered and restored system are big.


Allison


>
>




Re: DEC bus transceivers

2016-10-25 Thread Christian Corti

On Mon, 24 Oct 2016, Paul Koning wrote:
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).


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


Re: DEC bus transceivers

2016-10-24 Thread Don North

On 10/24/2016 1: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.


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




Re: DEC bus transceivers

2016-10-24 Thread allison
On 10/24/2016 03:55 PM, David Bridgham wrote:
> 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.  
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.
> 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





Re: DEC bus transceivers

2016-10-24 Thread David Bridgham
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.




Re: DEC bus transceivers

2016-10-24 Thread Guy Sotomayor Jr

> On Oct 24, 2016, at 10:37 AM, allison  wrote:
> 
> On 10/23/16 2:59 PM, Al Kossow wrote:
>> 
>> On 10/23/16 11:50 AM, shad 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 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 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



Re: DEC bus transceivers

2016-10-24 Thread allison

On 10/23/16 2:59 PM, Al Kossow wrote:


On 10/23/16 11:50 AM, shad 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 
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


Re: DEC bus transceivers

2016-10-24 Thread allison

On 10/23/16 2:50 PM, shad 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





Re: DEC bus transceivers

2016-10-24 Thread Ethan Dicks
On Mon, Oct 24, 2016 at 4:35 PM, Guy Sotomayor Jr  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


Re: DEC bus transceivers

2016-10-24 Thread David Bridgham
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



Re: DEC bus transceivers

2016-10-24 Thread Guy Sotomayor Jr

> On Oct 24, 2016, at 1:41 PM, Paul Koning  wrote:
> 
> 
>> On Oct 24, 2016, at 4:35 PM, Guy Sotomayor Jr  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.
> 
> 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).

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


Re: DEC bus transceivers

2016-10-24 Thread Paul Koning

> On Oct 24, 2016, at 4:35 PM, Guy Sotomayor Jr  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.

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



Re: DEC bus transceivers

2016-10-24 Thread Guy Sotomayor Jr

> On Oct 24, 2016, at 1:30 PM, Paul Koning  wrote:
> 
> 
>> On Oct 24, 2016, at 3:55 PM, David Bridgham  wrote:
>> 
>> 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.
> 
> I don't see any max slew rate spec in the driver specs in the peripherals 
> handbook.
> 

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

Re: DEC bus transceivers

2016-10-24 Thread Paul Koning

> On Oct 24, 2016, at 3:55 PM, David Bridgham  wrote:
> 
> 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.

I don't see any max slew rate spec in the driver specs in the peripherals 
handbook.

paul




Re: DEC bus transceivers

2016-10-24 Thread David Bridgham
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.



cctech vs cctalk issues / was Re: DEC bus transceivers

2016-10-24 Thread Brent Hilpert
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


Fwd: Re: DEC bus transceivers

2016-10-24 Thread Al Kossow



 Forwarded Message 
Subject: Re: DEC bus transceivers
Date: Mon, 24 Oct 2016 13:37:14 -0400
From: allison 
Reply-To: General Discussion: On-Topic Posts 
To: General Discussion: On-Topic Posts 

On 10/23/16 2:59 PM, Al Kossow wrote:
>
> On 10/23/16 11:50 AM, shad 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 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



Fwd: Re: DEC bus transceivers

2016-10-24 Thread Al Kossow
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 
Reply-To: General Discussion: On-Topic Posts 
To: General Discussion: On-Topic Posts 

On 10/23/16 2:50 PM, shad 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
>




Re: DEC bus transceivers

2016-10-24 Thread Paul Koning

> On Oct 23, 2016, at 2:50 PM, shad  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



Re: DEC bus transceivers (was Re: Unibus disk controller with modern storage)

2016-10-24 Thread Noel Chiappa
> From: David Bridgham

> Just the bus interface takes over half the area of a dual-height board!

In part because the level converters are SMD, and we had to mount them on
(modified) wide DIP carriers to use them in a wire-wrap board.

> I've played around with laying out what might be the production board
> ... and I've got it down to a row of 8641 bus transceivers and a row or
> two of the level-converter chips.

> http://pdp10.froghouse.org/qsic/proto-pcb.jpg

For those looking at that picture, it's not our current plan for 'producton'
QSIC's; the one in the picture uses a daughter-card with an FPGA on it, but
that makes the card to high to fit into a single slot. So the current plan is
to do a card with an FPGA on it directly.

Noel


Re: DEC bus transceivers

2016-10-24 Thread allison
On 10/23/2016 04:57 PM, Toby Thain wrote:
> On 2016-10-23 2:50 PM, shad 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
>
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





Re: DEC bus transceivers (was Re: Unibus disk controller with modern storage)

2016-10-24 Thread allison
On 10/22/2016 06:40 PM, David Bridgham wrote:
> On 10/22/2016 12:44 PM, shad wrote:
>
>> What kind of bus transceivers did you used for the QSIC, specially
>> because you have
>> to go from 5V open-drain logic to 3.3V logic?
> To add to Noel's answer, here's a picture of our current prototype board.
>
> http://pdp10.froghouse.org/qsic/qsic-wirewrap.jpg
>
> Coming up from the QBUS, the first two rows of chips are the bus
> transceivers.  The next row and a half are the level-converters.  Then
> the two large ribbon cables run off to the FPGA module we're using for
> development.  The two small ribbon cables go to the indicator panel. 
> Just the bus interface takes over half the area of a dual-height board! 
> I've played around with laying out what might be the production board
> (when I get tired of Verilog and want a mindless break, I doodle with
> kicad) and I've got it down to a row of 8641 bus transceivers and a row
> or two of the level-converter chips.  It's better but still a good
> fraction of the entire board.
>
> http://pdp10.froghouse.org/qsic/proto-pcb.jpg
>
> Now I thought, what if my idea of that two MOSFET bus transceiver would
> work?  What would the board look like then?
>
> http://pdp10.froghouse.org/qsic/qsic-smt.jpg
>
> Obviously that could be squeezed down a lot more.  Even another
> transistor or two per bus line would still be fairly small.  Doing the
> bus transceiver and level-conversion in one step makes a big difference.
>
> For the QSIC, we're going to have sufficient room and we're able to find
> enough old bus transceivers to continue on as we're going.  Still, I'd
> sure love to have an option that used production parts and took up less
> board space.
>
>

For bus to card LS241, LS244 and LS245 were used in the day by heathkit
(H11)
For bus to card with hysteresis LS14 was a common choice along with
LS13 or maybe LS132.  

Other considerations the DEC specs were based on available devices of
the day (late 70s)
and in the last 40 years there are a plethora of better devices that
replace those easily.  
The key being Schmidt input (bus to card level) for noise immunity and
robust drive for the
output devices.  Many of those were also used for S100 (less well
thought out and
often noisier.) with good success.  I've copied and used those for
making boards as
needed for Qbus and Omnibus as those represent the common DEC buses
outside of SCSI
in the hardware I own.

One thing I'm adverse to is bus to CMOS without buffering or the reverse
even if
the CMOS can drive the bus.  Unexpected ringing or spikes on the bus can
play
havoc with those as well as poor ESD practices.

Now the problems of board space and available parts may force SMT and CMOS
for the internal circuits and also power conservation (and thermal
management).


Allison




Re: DEC bus transceivers

2016-10-23 Thread Toby Thain

On 2016-10-23 2:50 PM, shad 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



Re: DEC bus transceivers

2016-10-23 Thread Al Kossow


On 10/23/16 11:50 AM, shad 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.




Re: DEC bus transceivers

2016-10-23 Thread shadoooo
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


DEC bus transceivers (was Re: Unibus disk controller with modern storage)

2016-10-22 Thread David Bridgham
On 10/22/2016 12:44 PM, shad wrote:

> What kind of bus transceivers did you used for the QSIC, specially
> because you have
> to go from 5V open-drain logic to 3.3V logic?

To add to Noel's answer, here's a picture of our current prototype board.

http://pdp10.froghouse.org/qsic/qsic-wirewrap.jpg

Coming up from the QBUS, the first two rows of chips are the bus
transceivers.  The next row and a half are the level-converters.  Then
the two large ribbon cables run off to the FPGA module we're using for
development.  The two small ribbon cables go to the indicator panel. 
Just the bus interface takes over half the area of a dual-height board! 
I've played around with laying out what might be the production board
(when I get tired of Verilog and want a mindless break, I doodle with
kicad) and I've got it down to a row of 8641 bus transceivers and a row
or two of the level-converter chips.  It's better but still a good
fraction of the entire board.

http://pdp10.froghouse.org/qsic/proto-pcb.jpg

Now I thought, what if my idea of that two MOSFET bus transceiver would
work?  What would the board look like then?

http://pdp10.froghouse.org/qsic/qsic-smt.jpg

Obviously that could be squeezed down a lot more.  Even another
transistor or two per bus line would still be fairly small.  Doing the
bus transceiver and level-conversion in one step makes a big difference.

For the QSIC, we're going to have sufficient room and we're able to find
enough old bus transceivers to continue on as we're going.  Still, I'd
sure love to have an option that used production parts and took up less
board space.