Unibus/QBus transceivers and drivers - was Re: PDP-11/20 in Iowa (x3)

[Toby Thain via cctalk]

On 2017-03-27 6:46 PM, Ethan Dicks via cctalk wrote:

On Mon, Mar 27, 2017 at 6:35 PM, Steve Malikoff via cctalk
 wrote:

After seeing this modern memory board project for the PDP-8/e using NVRAMMs
http://www.tronola.com/html/ram_for_pdp-8e.html


I have a couple of those I need to solder up.


I wonder how much effort it would be to refactor the Omnibus logic to Unibus
to build a PDP-11 version, and thus have a quad size card for /15's and /20's?


Conceptually, it's not much different for Unibus.  There's at least
one project out there that's working toward this but not yet available
for purchase.

If I was in a real hurry, I could take a quad prototype board and roll
my own.  I happen to have a handful of DS8641s on hand from making
Unibus COMBOARDs 25 years ago.  The quantity of discussion on this
list about modern Unibus transceiver replacements is rather large and
merely mentioning it is likely to cause a flare-up.


It just begs for a conclusive summary. Perhaps those who are actively 
building stuff will eventually provide one (not necessarily on the list 
per se) :-)


--Toby




-ethan

Re: UNIBUS/QBUS interface chips Was: Re: MEM11 update

[allison]

On 12/6/16 10:05 AM, Toby Thain wrote:

On 2016-12-06 1:34 AM, Eric Smith wrote:

On Mon, Dec 5, 2016 at 6:53 PM, allison  wrote:


A bunch of us old digits (former dec engineers) got together and were
talking
about old systems and the thing that stood out is a general dislike for
having
to use the limited set of bus interface chips when there were newer
parts.  It
was a internal mandate not something that was better than could be had.
The
logic was the parts were known, the vendors vetted for quality and
reliability
and when you use hundreds of thousands to millions of a part like bus
interface
and ram quality is a critical thing.  Were they special, a flat no.



I don't fully agree. The receivers (and transceivers) had a threshold
voltage that is not available with modern parts, and that actually was


I'm an electronics noob, but do you mean a threshold of 1.5V, as with 
DS8641?



I'm not a noob.  I'm an engineer from the the realm of DEC engineering.

I also forget the 74LS14 hex inverter with hysteresis which has a 
threshold about 1.5V

depending on whos datasheet you believe.

Bottom line is the older parts has a low Vih and a high Vil with a 
resulting narrow noise immunity.
Increasing the Vih helps this and the driver/bus combo can support it.  
The yabut is if the drivers
have leakage then attaining Vih on the bus is problematic as the leakage 
was a undesired pull down.
The 8xxx parts used were screened for low leakage with output is in the 
high state (open as they
are open collector).  The bus loads assert the Voltage high state and 
that is above 2.3V so the only
limiting factor then is excessive capacitive loading which smears pulsed 
by RC time constant.  The
other issue with slow edges is where the edge really is and that adds 
uncertainty to timing.   All

of those things were allowed for in the design of the bus.

The voltage your hung up about was  tested to insure it was never lower 
than that or the noise
immunity was terrible.  Its companion was was that the saturated device 
in the package could
also achieve the limit or less or a low voltage at the rated current, at 
that time (late 60s early 70s)

this was a hard parameter to control.

The bottom lime is the better the logic high voltage and logic low 
voltages achieved the greater
noise immunity.  Adding hysteresis insure that a hig is high and a low 
is low and not some random

analog voltage inbetween (or oscillation!).

As to any slew rate testing the issue was that devices that could sink 
the needed current were also
slow as sludge and had to be tested to insure they were fast enough not 
that they would have a
slow propagation time and switching speed as that was also a undesired 
in systems where fast
is important.  Bottom line is the datasheet and purchase spec was to 
insure the part worked to or

better than expected rather than implying magical properties.


Allison


I'm referring to this part of October's thread:
http://www.classiccmp.org/pipermail/cctalk/2016-October/028871.html


--Toby



important for large systems with multiple bus segments.  That was
particularly important for large Unibus systems, but even Qbus with only
two bus segments can get finicky when heavily loaded.

DEC could easily have made custom interface ICs if they had needed them.

AFAIK, *no* current production interface ICs have the right 
threshold. It's

hard to meet the spec without using either NOS parts or comparators.

It would certainly be possible to build a functionally equivalent bus 
with
modern interface ICs, and it might have significantly better 
performance,

but it wouldn't be compatible with the legacy systems.

Re: UNIBUS/QBUS interface chips Was: Re: MEM11 update

[Toby Thain]

On 2016-12-06 1:34 AM, Eric Smith wrote:

On Mon, Dec 5, 2016 at 6:53 PM, allison  wrote:


A bunch of us old digits (former dec engineers) got together and were
talking
about old systems and the thing that stood out is a general dislike for
having
to use the limited set of bus interface chips when there were newer
parts.  It
was a internal mandate not something that was better than could be had.
The
logic was the parts were known, the vendors vetted for quality and
reliability
and when you use hundreds of thousands to millions of a part like bus
interface
and ram quality is a critical thing.  Were they special, a flat no.



I don't fully agree. The receivers (and transceivers) had a threshold
voltage that is not available with modern parts, and that actually was


I'm an electronics noob, but do you mean a threshold of 1.5V, as with 
DS8641?


I'm referring to this part of October's thread:
http://www.classiccmp.org/pipermail/cctalk/2016-October/028871.html


--Toby



important for large systems with multiple bus segments.  That was
particularly important for large Unibus systems, but even Qbus with only
two bus segments can get finicky when heavily loaded.

DEC could easily have made custom interface ICs if they had needed them.

AFAIK, *no* current production interface ICs have the right threshold. It's
hard to meet the spec without using either NOS parts or comparators.

It would certainly be possible to build a functionally equivalent bus with
modern interface ICs, and it might have significantly better performance,
but it wouldn't be compatible with the legacy systems.

Re: UNIBUS/QBUS interface chips Was: Re: MEM11 update

[Eric Smith]

On Mon, Dec 5, 2016 at 6:53 PM, allison  wrote:

> A bunch of us old digits (former dec engineers) got together and were
> talking
> about old systems and the thing that stood out is a general dislike for
> having
> to use the limited set of bus interface chips when there were newer
> parts.  It
> was a internal mandate not something that was better than could be had.
> The
> logic was the parts were known, the vendors vetted for quality and
> reliability
> and when you use hundreds of thousands to millions of a part like bus
> interface
> and ram quality is a critical thing.  Were they special, a flat no.
>

I don't fully agree. The receivers (and transceivers) had a threshold
voltage that is not available with modern parts, and that actually was
important for large systems with multiple bus segments.  That was
particularly important for large Unibus systems, but even Qbus with only
two bus segments can get finicky when heavily loaded.

DEC could easily have made custom interface ICs if they had needed them.

AFAIK, *no* current production interface ICs have the right threshold. It's
hard to meet the spec without using either NOS parts or comparators.

It would certainly be possible to build a functionally equivalent bus with
modern interface ICs, and it might have significantly better performance,
but it wouldn't be compatible with the legacy systems.

Re: UNIBUS/QBUS interface chips Was: Re: MEM11 update

[allison]

On 12/05/2016 06:35 PM, Toby Thain wrote:
> On 2016-05-02 9:48 AM, Noel Chiappa wrote:
>> > From: Pete Lancashire
>>
>> > Do you or someone have a list of all the Unibus bus chips ?
>>
>> I have seen the following bus interface chips used on DEC UNIBUS boards:
>>
>> Drivers:
>>
>> 8881 - Sprague, Signetics - Quad NAND
>>
>> Receivers:
>>
>> 380 - Signetics - Quad NOR
>> 314 - Signetics - 7-input NOR
>> 8815 - Signetics - 4-input NOR
>> 8837 - National Semi - Hex receiver (aka Signetics N8T37)
>> 8640 - National Semi - Quad NOR
>>
>> Transceivers:
>>
>> 8641 - National Semi - Quad transceiver
>>
>> The actal complete part number can vary depending on the
>> manufacturer; e.g.
>> the 8641's are usually DS8641N, from NatSemi, and the 380's are usually
>> SP380A's or SP380N's. Where the basic number is not included (as with
>> the
>> 8T37 for the 8837) I have given it.
>>
>> The following chips have been used by DEC to interface to the QBUS, and
>> I have seen many of the above chips (e.g. 8641's) used there too, so I
>> think chips seen on one bus could be used on the other:
>>
>> Drivers:
>>
>> 7439 - Various - Quad NAND
>>
>> Transceivers:
>>
>> 2908 - AMD - Quad latching transceiver with tri-state output
>>
>> I _believe_ the following chips are also usable as UNIBUS/QBUS interface
>> chips, but I'm not sure if I've seen one used there:
>>
>> Transceivers:
>>
>> 8836 - National Semi - Quad NOR
>> 8838 - National Semi - Quad transceiver (aka Signetics N8T38)
>>
>> Quite a zoo!
>>
>> Noel
>>
>
>

Also 74LS240, 7438, DM8130, dm8838, and Andromeda (the guys that use
the AM29x305) liked the AM2908.

> Has anyone looked at the TI Signal Switch family for QBus? (hat tip
> Ian Finder)
>
> http://www.prnewswire.com/news-releases/three-new-bus-switch-families-from-texas-instruments-enhance-performance-of-datacom-and-networking-equipment-and-optimize-next-generation-portable-computing-and-communications-designs-70812102.html
>
>
Not the best animal as the are CMOS.

A bunch of us old digits (former dec engineers) got together and were
talking
about old systems and the thing that stood out is a general dislike for
having
to use the limited set of bus interface chips when there were newer
parts.  It
was a internal mandate not something that was better than could be had. 
The
logic was the parts were known, the vendors vetted for quality and
reliability
and when you use hundreds of thousands to millions of a part like bus
interface
and ram quality is a critical thing.  Were they special, a flat no.

But next time you look at an LSI-11/2 dual width processor card look at
the line of
caps that are on the bus, they are there to tame the ringing.

Allison

> --Toby
>
>
>

Re: UNIBUS/QBUS interface chips Was: Re: MEM11 update

[Eric Smith]

On Mon, Dec 5, 2016 at 4:35 PM, Toby Thain  wrote:

> Has anyone looked at the TI Signal Switch family for QBus? (hat tip Ian
> Finder)
>

I use those for interfacing 5V TTL-compatible stuff to 3.3V logic.

It doesn't really solve the major Qbus problems.  In particular, it doesn't
help with either the receiver threshold or the drive requirements.

Re: UNIBUS/QBUS interface chips Was: Re: MEM11 update

[Toby Thain]

On 2016-05-02 9:48 AM, Noel Chiappa wrote:

> From: Pete Lancashire

> Do you or someone have a list of all the Unibus bus chips ?

I have seen the following bus interface chips used on DEC UNIBUS boards:

Drivers:

8881 - Sprague, Signetics - Quad NAND

Receivers:

380 - Signetics - Quad NOR
314 - Signetics - 7-input NOR
8815 - Signetics - 4-input NOR
8837 - National Semi - Hex receiver (aka Signetics N8T37)
8640 - National Semi - Quad NOR

Transceivers:

8641 - National Semi - Quad transceiver

The actal complete part number can vary depending on the manufacturer; e.g.
the 8641's are usually DS8641N, from NatSemi, and the 380's are usually
SP380A's or SP380N's. Where the basic number is not included (as with the
8T37 for the 8837) I have given it.

The following chips have been used by DEC to interface to the QBUS, and
I have seen many of the above chips (e.g. 8641's) used there too, so I
think chips seen on one bus could be used on the other:

Drivers:

7439 - Various - Quad NAND

Transceivers:

2908 - AMD - Quad latching transceiver with tri-state output

I _believe_ the following chips are also usable as UNIBUS/QBUS interface
chips, but I'm not sure if I've seen one used there:

Transceivers:

8836 - National Semi - Quad NOR
8838 - National Semi - Quad transceiver (aka Signetics N8T38)

Quite a zoo!

Noel




Has anyone looked at the TI Signal Switch family for QBus? (hat tip Ian 
Finder)


http://www.prnewswire.com/news-releases/three-new-bus-switch-families-from-texas-instruments-enhance-performance-of-datacom-and-networking-equipment-and-optimize-next-generation-portable-computing-and-communications-designs-70812102.html

--Toby

Re: MSCP - was Re: Unibus / Qbus

[Paul Koning]

> On Oct 24, 2016, at 12:34 PM, allison  wrote:
> 
>> ...
> And the RQDX1/2/3 used T11 for the job so its not that intense save for speed.
> The other part of it is much of the code is likely the interface to the MFM 
> disk and thats
> speed intensive and likely more hardware than software.

FWIW, microcontroller based disk controllers existed well before MSCP.  For 
example, the CDC 7054 disk controller (for 844 disks, which are basically 
RP04s, among other things) uses a small 16 bit computer for the top level 
control, with a magic data mover engine to construct the detailed bit-level 
track / sector layout.  If you needed a better disk controller, you could 
modify the firmware (it was downloaded to the disk controller at system boot), 
though not many people were skilled enough to do so.  But I worked with one, 
the famous Don Lee at CERL (PLATO development) at the University of Illinois.

paul

Re: MSCP - was Re: Unibus / Qbus

[allison]

On 10/24/16 8:51 AM, Paul Koning wrote:

On Oct 24, 2016, at 7:39 AM, allison  wrote:

On 10/22/16 6:05 PM, Toby Thain wrote:

On 2016-10-22 4:08 PM, allison wrote:

...
FYI I have never heard of any one recreating the RQDX1/2/3 software
protocol MSCP
as it was nontrivial, proprietary, and copyrighted.

It's been implemented in simh, afaik. Its reputation is a little more imposing 
than the reality.
...

That may be so but putting it on a board to accept a IDE drive is far more 
useful to us that run hardware.
Why IDE, It can use CF and I also have a large supply of drives from 20-512mb.  
 Fortunately I have a
large supply of MFM drives and two SCSI controllers for the larger supply of 
SCSI drives.  However, I
feel I'm the exception and many Qbus users are not so fortunate.

Where is the source code to for that? That is the drive side of that.

There's pdp11_rq.c.  If you were to do a bus interface with microprocessor 
behind it for the protocol work, that code could be adapted for the job.  And 
that would be the obvious way to build an MSCP controller -- that's how MSCP 
was designed to be implemented and how it was done in DEC's controllers.  A 
BeagleBone Black or the like would be more than ample for the job, given that 
early implementations such as the UDA50 were done with 2901 bitslice engines 
(and very odd looking microcode).

paul
And the RQDX1/2/3 used T11 for the job so its not that intense save for 
speed.
The other part of it is much of the code is likely the interface to the 
MFM disk and thats

speed intensive and likely more hardware than software.

I'll have to scratch at the code and see.

Allison

Re: Unibus / Qbus

[Ethan Dicks]

On Sat, Oct 22, 2016 at 5:39 PM, emanuel stiebler  wrote:
> Every time I thought about it, or even started, I gave up, because there
> aren't simply enough people who would buy such a thing. The prices for an
> old working Qbus SCSI controller are low enough, to just wait until you get
> one on ebay for a decent price.

For Qbus SCSI, that number seems to hover around $250.  I can't build
one for cheaper than that, and I doubt anyone can.

> So all of my machines have SCSI in the meantime, and the headache of making
> my own is gone ;-)

I do have more than one Qbus SCSI card, but far more Qbus CPUs than I
could ever afford to so equip.  Also, I have plenty of Unibus and one
VAXBI for which SCSI is far more expensive, so I keep dreaming of a
way to do that, but I never get as far as implementation.

-ethan

Re: MSCP - was Re: Unibus / Qbus

[Paul Koning]

> On Oct 24, 2016, at 7:39 AM, allison  wrote:
> 
> On 10/22/16 6:05 PM, Toby Thain wrote:
>> On 2016-10-22 4:08 PM, allison wrote:
>>> ...
>>> FYI I have never heard of any one recreating the RQDX1/2/3 software
>>> protocol MSCP
>>> as it was nontrivial, proprietary, and copyrighted.
>> 
>> It's been implemented in simh, afaik. Its reputation is a little more 
>> imposing than the reality.
>> ...
> That may be so but putting it on a board to accept a IDE drive is far more 
> useful to us that run hardware.
> Why IDE, It can use CF and I also have a large supply of drives from 
> 20-512mb.   Fortunately I have a
> large supply of MFM drives and two SCSI controllers for the larger supply of 
> SCSI drives.  However, I
> feel I'm the exception and many Qbus users are not so fortunate.
> 
> Where is the source code to for that? That is the drive side of that.

There's pdp11_rq.c.  If you were to do a bus interface with microprocessor 
behind it for the protocol work, that code could be adapted for the job.  And 
that would be the obvious way to build an MSCP controller -- that's how MSCP 
was designed to be implemented and how it was done in DEC's controllers.  A 
BeagleBone Black or the like would be more than ample for the job, given that 
early implementations such as the UDA50 were done with 2901 bitslice engines 
(and very odd looking microcode).

paul

Re: MSCP - was Re: Unibus / Qbus

[allison]

On 10/22/16 6:05 PM, Toby Thain wrote:

On 2016-10-22 4:08 PM, allison wrote:

...
FYI I have never heard of any one recreating the RQDX1/2/3 software
protocol MSCP
as it was nontrivial, proprietary, and copyrighted.


It's been implemented in simh, afaik. Its reputation is a little more 
imposing than the reality.


--Toby


That may be so but putting it on a board to accept a IDE drive is far 
more useful to us that run hardware.
Why IDE, It can use CF and I also have a large supply of drives from 
20-512mb.   Fortunately I have a
large supply of MFM drives and two SCSI controllers for the larger 
supply of SCSI drives.  However, I

feel I'm the exception and many Qbus users are not so fortunate.

Where is the source code to for that? That is the drive side of that.

Allison

MSCP - was Re: Unibus / Qbus

[Toby Thain]

On 2016-10-22 4:08 PM, allison wrote:

...
FYI I have never heard of any one recreating the RQDX1/2/3 software
protocol MSCP
as it was nontrivial, proprietary, and copyrighted.


It's been implemented in simh, afaik. Its reputation is a little more 
imposing than the reality.


--Toby




Allison

Re: MSCP - was Re: Unibus / Qbus

[Paul Koning]

> On Oct 22, 2016, at 6:05 PM, Toby Thain  wrote:
> 
> On 2016-10-22 4:08 PM, allison wrote:
>> ...
>> FYI I have never heard of any one recreating the RQDX1/2/3 software
>> protocol MSCP
>> as it was nontrivial, proprietary, and copyrighted.
> 
> It's been implemented in simh, afaik. Its reputation is a little more 
> imposing than the reality.

Well, it certainly is vastly more complex than the older CSR-based controllers. 
 That's not to say it's undoable; compared to, say, SCSI it's not that painful. 
 (In fact, you might say it's a natural predecessor of SCSI.)  Proprietary, 
yes.  Copyrighted?  perhaps so, but copyright is irrelevant if you want to 
build implementations.  (It only matters if you want to make copies of the 
document.)  I assume MSCP was patented, but any patents have expired long ago 
so those aren't relevant any longer either.  

The main question is whether a sufficiently accurate spec is available.  In the 
case of MSCP (and TMSCP, which is a close relative) the answer is yes (on 
Bitsavers).  And unlike some other standards sources, DEC standards generally 
are written to the level of quality that conformance implies interoperability 
-- in other words, do what the spec says and it will work correctly.

paul

Re: Unibus / Qbus

[emanuel stiebler]

On 2016-10-22 22:08, allison wrote:


So to do that you have two project the hardware is fairly straight
forward (see the
applicable Bus interfacing books put out by DEC) but the software to use
it is a project.
FYI I have never heard of any one recreating the RQDX1/2/3 software
protocol MSCP
as it was nontrivial, proprietary, and copyrighted.


Every time I thought about it, or even started, I gave up, because there 
aren't simply enough people who would buy such a thing. The prices for 
an old working Qbus SCSI controller are low enough, to just wait until 
you get one on ebay for a decent price.


So all of my machines have SCSI in the meantime, and the headache of 
making my own is gone ;-)

Unibus / Qbus

[shadoooo]

Hello,
we are discussing on separate thread about doing an universal interface for
PDP11.
I'm taking all the relevant documentation about Unibus and Qbus busses,
aiming to check the possibility of doing a board compatible, with some
adjustments, with both worlds.
I started to read the 1979 specifications, however it's not all clear to
me, specially about Unibus.

What I understood:
- Qbus is complete on A and B connectors, so a dual card could be done.
Some backplanes have a true serpentine, while some other has C and D with
other signals, but those are of particular usage with dual-board interfaces.
Basically both dual and quad boards can be done, with the latter using A
and B and simply propagating grant on C and D, supposedly connected in
standard serpentine.

Unibus: the specifications are describing A and B, but backplanes are
complicate than that, and can have Unibus, Modified Unibus, Extended
Unibus, SPC...
What for?
If all the signals are in AB, why they are connected again in CDEF?
There's some complete documentation about the different backplane types,
and the standard approach for an Unibus board?

Thanks
Andrea

Re: Unibus / Qbus

[allison]

On 10/22/2016 03:18 PM, shad wrote:
> Hello,
> we are discussing on separate thread about doing an universal interface for
> PDP11.
> I'm taking all the relevant documentation about Unibus and Qbus busses,
> aiming to check the possibility of doing a board compatible, with some
> adjustments, with both worlds.
> I started to read the 1979 specifications, however it's not all clear to
> me, specially about Unibus.
>
> What I understood:
> - Qbus is complete on A and B connectors, so a dual card could be done.
> Some backplanes have a true serpentine, while some other has C and D with
> other signals, but those are of particular usage with dual-board interfaces.
> Basically both dual and quad boards can be done, with the latter using A
> and B and simply propagating grant on C and D, supposedly connected in
> standard serpentine.
>
> Unibus: the specifications are describing A and B, but backplanes are
> complicate than that, and can have Unibus, Modified Unibus, Extended
> Unibus, SPC...
> What for?
> If all the signals are in AB, why they are connected again in CDEF?
> There's some complete documentation about the different backplane types,
> and the standard approach for an Unibus board?
>
> Thanks
> Andrea
>

There are later DEC databooks on the net that give a more complete picture.

The biggest total difference is the QBUS the address (a0-15) and data
d0-15 are multiplexed.
So separate boards make more sense for the buses when you allow for the
Qbus being AB
and Unibus minimally quad or hex size.  

FYI the CD and some cases EF width for Qbus was to allow for quad wide
and hex wide cards
for large peripherals or memories (PDP-11 Qbus CORE is hex wide) and
many board sets for
Qbus like RLV-11 (two boards) need CD interconnect to ty both together
but not for CPU access
where the single board version RLV21 is only a single quad wide.

So a Qbus mass storage could be a dual width and can be very simple for
IDE/CF or maybe SD.

Often the larger problem is not building hardware (there was an IDE
design out there for
QBUS VAX or PDP11 using PIO transfers) but a driver for VMS, Ultrix,
RT11, RSX11, RSTS
was a totally larger project.

So to do that you have two project the hardware is fairly straight
forward (see the
applicable Bus interfacing books put out by DEC) but the software to use
it is a project.
FYI I have never heard of any one recreating the RQDX1/2/3 software
protocol MSCP
as it was nontrivial, proprietary, and copyrighted.


Allison

Re: UNIBUS/QBUS interface chips Was: Re: MEM11 update

[Don North]

On 5/2/2016 7:04 AM, Mattis Lind wrote:

The following chips have been used by DEC to interface to the QBUS, and
I have seen many of the above chips (e.g. 8641's) used there too, so I
think chips seen on one bus could be used on the other:

Drivers:

7439 - Various - Quad NAND

Transceivers:

2908 - AMD - Quad latching transceiver with tri-state output

I _believe_ the following chips are also usable as UNIBUS/QBUS interface
chips, but I'm not sure if I've seen one used there:

Transceivers:

8836 - National Semi - Quad NOR
8838 - National Semi - Quad transceiver (aka Signetics N8T38)

Quite a zoo!


DEC also used the DEC DC005 for the data and address lines on QBUS cards.
The Signetics code is C2324N


DEC also used the DC005 (8 pcs) for address / data interface on the M8739 KLESI 
(Aztec/RC25)

UNIBUS interface card. DC013's were used for the NPR/NPG and BR/BG logic.

Don

Re: UNIBUS/QBUS interface chips Was: Re: MEM11 update

[Brian Walenz]

I did a bit of searching in the fall for an 8881 (to fix a busted HALT
instruction on a PDP8a).  I concluded the 7439 is a pin-for-pin replacement
- I can't claim all credit for this, it's probably known by a few people
here.  My notes say the 8881 will handle 30mA loads.  The 7401 will handle
16mA, while the 7439 will handle 80mA.

Cheers!

b


On Mon, May 2, 2016 at 10:04 AM, Mattis Lind <mattisl...@gmail.com> wrote:

> > The following chips have been used by DEC to interface to the QBUS, and
> > I have seen many of the above chips (e.g. 8641's) used there too, so I
> > think chips seen on one bus could be used on the other:
> >
> > Drivers:
> >
> > 7439 - Various - Quad NAND
> >
> > Transceivers:
> >
> > 2908 - AMD - Quad latching transceiver with tri-state output
> >
> > I _believe_ the following chips are also usable as UNIBUS/QBUS interface
> > chips, but I'm not sure if I've seen one used there:
> >
> > Transceivers:
> >
> > 8836 - National Semi - Quad NOR
> > 8838 - National Semi - Quad transceiver (aka Signetics N8T38)
> >
> > Quite a zoo!
> >
>
> DEC also used the DEC DC005 for the data and address lines on QBUS cards.
> The Signetics code is C2324N
>
> /Mattis
>
>
> >
> > Noel
> >
>

Re: UNIBUS/QBUS interface chips Was: Re: MEM11 update

[Mattis Lind]

> The following chips have been used by DEC to interface to the QBUS, and
> I have seen many of the above chips (e.g. 8641's) used there too, so I
> think chips seen on one bus could be used on the other:
>
> Drivers:
>
> 7439 - Various - Quad NAND
>
> Transceivers:
>
> 2908 - AMD - Quad latching transceiver with tri-state output
>
> I _believe_ the following chips are also usable as UNIBUS/QBUS interface
> chips, but I'm not sure if I've seen one used there:
>
> Transceivers:
>
> 8836 - National Semi - Quad NOR
> 8838 - National Semi - Quad transceiver (aka Signetics N8T38)
>
> Quite a zoo!
>

DEC also used the DEC DC005 for the data and address lines on QBUS cards.
The Signetics code is C2324N

/Mattis


>
> Noel
>

UNIBUS/QBUS interface chips Was: Re: MEM11 update

[Noel Chiappa]

> From: Pete Lancashire

> Do you or someone have a list of all the Unibus bus chips ?

I have seen the following bus interface chips used on DEC UNIBUS boards:

Drivers:

8881 - Sprague, Signetics - Quad NAND

Receivers:

380 - Signetics - Quad NOR
314 - Signetics - 7-input NOR
8815 - Signetics - 4-input NOR
8837 - National Semi - Hex receiver (aka Signetics N8T37)
8640 - National Semi - Quad NOR

Transceivers:

8641 - National Semi - Quad transceiver

The actal complete part number can vary depending on the manufacturer; e.g.
the 8641's are usually DS8641N, from NatSemi, and the 380's are usually
SP380A's or SP380N's. Where the basic number is not included (as with the
8T37 for the 8837) I have given it.

The following chips have been used by DEC to interface to the QBUS, and
I have seen many of the above chips (e.g. 8641's) used there too, so I
think chips seen on one bus could be used on the other:

Drivers:

7439 - Various - Quad NAND

Transceivers:

2908 - AMD - Quad latching transceiver with tri-state output

I _believe_ the following chips are also usable as UNIBUS/QBUS interface
chips, but I'm not sure if I've seen one used there:

Transceivers:

8836 - National Semi - Quad NOR
8838 - National Semi - Quad transceiver (aka Signetics N8T38)

Quite a zoo!

Noel