22 Oct
2016
22 Oct
'16
3:18 p.m.
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
22 Oct
22 Oct
4:08 p.m.
On 10/22/2016 03:18 PM, shadoooo 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
5:39 p.m.
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 ;-)
24 Oct
24 Oct
6:41 p.m.
On Sat, Oct 22, 2016 at 5:39 PM, emanuel stiebler <emu at e-bbes.com> 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
22 Oct
22 Oct
6:05 p.m.
New subject: MSCP - was Re: Unibus / Qbus
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
23 Oct
23 Oct
2:16 p.m.
New subject: MSCP - was Re: Unibus / Qbus
On Oct 22, 2016, at 6:05 PM, Toby Thain <toby at
telegraphics.com.au> wrote:
On 2016-10-22 4:08 PM, allison wrote:
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
...
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.
24 Oct
24 Oct
7:39 a.m.
New subject: MSCP - was Re: Unibus / Qbus
On 10/22/16 6:05 PM, Toby Thain wrote:
On 2016-10-22 4:08 PM, allison wrote:
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
...
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
8:51 a.m.
New subject: MSCP - was Re: Unibus / Qbus
On Oct 24, 2016, at 7:39 AM, allison <ajp166 at
verizon.net> wrote:
On 10/22/16 6:05 PM, Toby Thain wrote:
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
On 2016-10-22 4:08 PM, allison wrote:
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. ...
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.
...
12:34 p.m.
New subject: MSCP - was Re: Unibus / Qbus
On 10/24/16 8:51 AM, Paul Koning 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.
I'll have to scratch at the code and see.
Allison
On Oct 24,
2016, at 7:39 AM, allison <ajp166 at verizon.net> wrote:
On 10/22/16 6:05 PM, Toby Thain wrote:
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 On 2016-10-22 4:08 PM, allison wrote:
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. ...
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.
...
12:46 p.m.
New subject: MSCP - was Re: Unibus / Qbus
On Oct 24, 2016, at 12:34 PM, allison <ajp166 at
verizon.net> wrote:
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
...
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.
2834
days inactive
2836
days old
9 comments
6 participants
participants (6)
-
ajp166＠verizon.net -
emu＠e-bbes.com -
ethan.dicks＠gmail.com -
paulkoning＠comcast.net -
shadoooo＠gmail.com -
toby＠telegraphics.com.au