25 Feb
2021
25 Feb
'21
12:30 p.m.
From: Paul Koning
There's a good reason why the big disks on many
DEC machines were Massbus
devices until MSCP arrived. It's quite clear on Unibus PDP-11s, which
needed Massbus both for speed and for a cleaner answer to more-than-18
bit addressing.
I follow the first sentence, but I'm confused by the second, especially "a
cleaner answer to more-than-18 bit addressing". The UNIBUS MASSBUS
controller/adapter, the RH11, only has 18-bit addressing on the main memory
side. It does have more than 18-bit addressing on the device side, but so does
the RP11 (sort of). Are you thinking of the RH70? That does have access to
more than 2^18 bytes of main memory, but that's because it connects to the
-11/70 memory bus (as well as the UNIBUS, which is only used for control, not
data).
Similar questions about the speed point; passing data through an RH11 doesn't
increase the speed of the UNIBUS? Yes, the RH70 is faster, but that's because
of its connection to the -11/70 memory bus.
Noel
25 Feb
25 Feb
12:38 p.m.
On Feb 25, 2021, at 1:30 PM, Noel Chiappa via cctalk
<cctalk at classiccmp.org> wrote:
Yes, I meant the RH70. The point is that, without Massbus, the only I/O bus you have in
PDP-11 systems is the Unibus (pre-Qbus that is) with all its limitations. The Massbus
enabled the creation of the RH70 with its direct memory connection both for more bandwidth
and more address bits. So, for example, you can use an RM03 rather than being limited to
an RM02 because of the bus performance. And your disks and tapes don't have to fight
all the other I/O devices for unibus map slots.
paul
From: Paul Koning
There's a good reason why the big disks on
many DEC machines were Massbus
devices until MSCP arrived. It's quite clear on Unibus PDP-11s, which
needed Massbus both for speed and for a cleaner answer to more-than-18
bit addressing.
I follow the first sentence, but I'm confused by the second, especially "a
cleaner answer to more-than-18 bit addressing". The UNIBUS MASSBUS
controller/adapter, the RH11, only has 18-bit addressing on the main memory
side. It does have more than 18-bit addressing on the device side, but so does
the RP11 (sort of). Are you thinking of the RH70? That does have access to
more than 2^18 bytes of main memory, but that's because it connects to the
-11/70 memory bus (as well as the UNIBUS, which is only used for control, not
data).
Similar questions about the speed point; passing data through an RH11 doesn't
increase the speed of the UNIBUS? Yes, the RH70 is faster, but that's because
of its connection to the -11/70 memory bus. 
12:43 p.m.
Oh this is fun stuff. Is there a specification write-up anywhere on the
MASSBUS overall?
For example I wonder if the RH70 could do a transfer >128kb at a time.
Another is around the RH11: There were two models, the traditional RH11
(which could only do so many words on a DMA transfer) and the RH11-C
which could do more words per transaction by basically running the
Unibus in "Hog mode". That allowed the 2020 to run RM03's at a full 3600
RPM (and I assume can allow the 2020 to run things like RM80's).
Another item I always wondered about was the RH11's support of two
unibuses. I think the idea was to do the data transfers on the second
bus right to an 11/45's FASTBUS memory without worrying about DMA
timeouts while running the control and status registers on the normal
UNIBUS (which wouldn't block other devices). I wonder, does the MBA on
an 11/70 use similar cards to an RH11?
C
On 2/25/2021 1:30 PM, Noel Chiappa via cctalk wrote:
From: Paul
Koning
There's a good reason why the big disks on
many DEC machines were Massbus
devices until MSCP arrived. It's quite clear on Unibus PDP-11s, which
needed Massbus both for speed and for a cleaner answer to more-than-18
bit addressing.
I follow the first sentence, but I'm confused by the second, especially "a
cleaner answer to more-than-18 bit addressing". The UNIBUS MASSBUS
controller/adapter, the RH11, only has 18-bit addressing on the main memory
side. It does have more than 18-bit addressing on the device side, but so does
the RP11 (sort of). Are you thinking of the RH70? That does have access to
more than 2^18 bytes of main memory, but that's because it connects to the
-11/70 memory bus (as well as the UNIBUS, which is only used for control, not
data).
Similar questions about the speed point; passing data through an RH11 doesn't
increase the speed of the UNIBUS? Yes, the RH70 is faster, but that's because
of its connection to the -11/70 memory bus.
Noel
12:49 p.m.
On Thu, Feb 25, 2021 at 1:43 PM Chris Zach via cctalk <cctalk at classiccmp.org>
wrote:
Oh this is fun stuff. Is there a specification
write-up anywhere on the
MASSBUS overall?
For example I wonder if the RH70 could do a transfer >128kb at a time.
Another is around the RH11: There were two models, the traditional RH11
(which could only do so many words on a DMA transfer) and the RH11-C
which could do more words per transaction by basically running the
Unibus in "Hog mode". That allowed the 2020 to run RM03's at a full 3600
RPM (and I assume can allow the 2020 to run things like RM80's).
Another item I always wondered about was the RH11's support of two
unibuses. I think the idea was to do the data transfers on the second
bus right to an 11/45's FASTBUS memory without worrying about DMA
timeouts while running the control and status registers on the normal
UNIBUS (which wouldn't block other devices). I wonder, does the MBA on
an 11/70 use similar cards to an RH11?
C
I have a UNIBUS array of backplanes from an Industrial 11/40 that has a lot
of MASBUS controllers in it. Or, I think that's what these are. I removed
the backplane chassis from the rack and replaced it with two RL02 drives.
https://www.vintagecomputer.net/digital/PDP11-40_industrial11/DEC_industria…
1:04 p.m.
That is at least one RH11-AB in there, minus the knucklebusters of course.
On 2/25/2021 1:49 PM, Bill Degnan wrote:
On Thu, Feb 25, 2021 at 1:43 PM Chris Zach via cctalk
<cctalk at classiccmp.org <mailto:cctalk at classiccmp.org>> wrote:
Oh this is fun stuff. Is there a specification write-up anywhere on the
MASSBUS overall?
For example I wonder if the RH70 could do a transfer >128kb at a time.
Another is around the RH11: There were two models, the traditional RH11
(which could only do so many words on a DMA transfer) and the RH11-C
which could do more words per transaction by basically running the
Unibus in "Hog mode". That allowed the 2020 to run RM03's at a full
3600
RPM (and I assume can allow the 2020 to run things like RM80's).
Another item I always wondered about was the RH11's support of two
unibuses. I think the idea was to do the data transfers on the second
bus right to an 11/45's FASTBUS memory without worrying about DMA
timeouts while running the control and status registers on the normal
UNIBUS (which wouldn't block other devices). I wonder, does the MBA on
an 11/70 use similar cards to an RH11?
C
I have a UNIBUS array of backplanes from an Industrial 11/40 that has a
lot of MASBUS controllers in it.? Or, I think that's what these are.? I
removed the?backplane chassis from the?rack and replaced it with two
RL02 drives.
https://www.vintagecomputer.net/digital/PDP11-40_industrial11/DEC_industria…
<https://www.vintagecomputer.net/digital/PDP11-40_industrial11/DEC_industrial11_exp_chassis.jpg>
12:56 p.m.
On Feb 25, 2021, at 1:43 PM, Chris Zach via cctalk
<cctalk at classiccmp.org> wrote:
Oh this is fun stuff. Is there a specification write-up anywhere on the MASSBUS overall?
For example I wonder if the RH70 could do a transfer >128kb at a time. ...
I don't know the answer to most of your questions, but this one is easy:
"no". The reason is that the transfer is controlled by a 16 bit word count
register.
paul
1:06 p.m.
In answer to my own question: No it does not based on a bit of review.
Looks like unique cards to the 11/70.
C
On 2/25/2021 1:43 PM, Chris Zach via cctalk wrote:
Oh this is fun stuff. Is there a specification
write-up anywhere on the
MASSBUS overall?
For example I wonder if the RH70 could do a transfer >128kb at a time.
Another is around the RH11: There were two models, the traditional RH11
(which could only do so many words on a DMA transfer) and the RH11-C
which could do more words per transaction by basically running the
Unibus in "Hog mode". That allowed the 2020 to run RM03's at a full 3600
RPM (and I assume can allow the 2020 to run things like RM80's).
Another item I always wondered about was the RH11's support of two
unibuses. I think the idea was to do the data transfers on the second
bus right to an 11/45's FASTBUS memory without worrying about DMA
timeouts while running the control and status registers on the normal
UNIBUS (which wouldn't block other devices). I wonder, does the MBA on
an 11/70 use similar cards to an RH11?
C
On 2/25/2021 1:30 PM, Noel Chiappa via cctalk wrote:
> ???? > From: Paul Koning
>
> ???? > There's a good reason why the big disks on many DEC machines
> were Massbus
> ???? > devices until MSCP arrived.? It's quite clear on Unibus
> PDP-11s, which
> ???? > needed Massbus both for speed and for a cleaner answer to
> more-than-18
> ???? > bit addressing.
>
> I follow the first sentence, but I'm confused by the second,
> especially "a
> cleaner answer to more-than-18 bit addressing". The UNIBUS MASSBUS
> controller/adapter, the RH11, only has 18-bit addressing on the main
> memory
> side. It does have more than 18-bit addressing on the device side, but
> so does
> the RP11 (sort of). Are you thinking of the RH70? That does have
> access to
> more than 2^18 bytes of main memory, but that's because it connects to
> the
> -11/70 memory bus (as well as the UNIBUS, which is only used for
> control, not
> data).
>
> Similar questions about the speed point; passing data through an RH11
> doesn't
> increase the speed of the UNIBUS? Yes, the RH70 is faster, but that's
> because
> of its connection to the -11/70 memory bus.
>
> ??? Noel
>
2:27 p.m.
On 2/25/21 10:43 AM, Chris Zach via cctalk wrote:
Oh this is fun stuff. Is there a specification
write-up anywhere on the MASSBUS overall?
there is some documentation on bitsavers
the register descriptions were intentionally obfuscated to prevent cloning
that was figured out to make SIMH work
the CDC drive interface was also slightly modified for the same purpose
2:37 p.m.
On Thu, Feb 25, 2021 at 12:27 PM Al Kossow via cctalk <cctalk at classiccmp.org>
wrote:
On 2/25/21 10:43 AM, Chris Zach via cctalk wrote:
Interesting... Is this obfuscation documented anywhere (beyond looking at
SIMH code?) I was working on an RH11/RPxx emulation for the Unibone that
was partially working (and that I should really get back to...)
- Josh
Oh this is fun stuff. Is there a specification
write-up anywhere on the
MASSBUS overall?
there is some documentation on bitsavers
the register descriptions were intentionally obfuscated to prevent cloning
that was figured out to make SIMH work
the CDC drive interface was also slightly modified for the same purpose
3:26 p.m.
On Feb 25, 2021, at 4:15 PM, Al Kossow via cctalk
<cctalk at classiccmp.org> wrote:
On 2/25/21 12:37 PM, Josh Dersch wrote:
That rings a bell, for the PDP-11 case. I think there is a mapping from RH11/RH70 CSR
offsets to Massbus control bus register addresses; it isn't the natural 1:1 mapping of
the low order Unibus address bits being used directly as Massbus register addresses.
Interesting... Is this obfuscation documented
anywhere (beyond looking at SIMH code?)
Not that I know of. Thinking about it some
more I think that it was the massbus device addresses
behind the controllers that weren't documented From the software point of view that won't matter,
but if you're trying to build a Massbus device you'd have to know it. I'm
pretty sure I've seen that mapping somewhere (in the past 10 years), at least in part,
but I no longer remember where.
paul
5:43 p.m.
On 2/25/2021 1:37 PM, Josh Dersch via cctalk wrote:
On Thu, Feb 25, 2021 at 12:27 PM Al Kossow via cctalk
<cctalk at classiccmp.org>
wrote:
I did a lot of reverse engineering of the RP06 and RM05 schematics.
The implementation in my KS10 FPGA passes all the DSRPA and DSRMB
diagnostics that matter. I didn't simulate all of the sector header
hardware or ECC hardware since the disk already does that.
The register descriptions are at:
https://github.com/KS10FPGA/KS10FPGA/wiki/RPxx-Disk-Simulator
https://github.com/KS10FPGA/KS10FPGA/wiki/RH11-Massbus-Disk-Controller
https://github.com/KS10FPGA/KS10FPGA/issues/8
Rob Doyle.
On 2/25/21 10:43 AM, Chris Zach via cctalk wrote:
Interesting... Is this obfuscation documented anywhere (beyond looking at
SIMH code?) I was working on an RH11/RPxx emulation for the Unibone that
was partially working (and that I should really get back to...)
- Josh Oh this is fun stuff. Is there a specification
write-up anywhere on the
MASSBUS overall?
there is some documentation on bitsavers
the register descriptions were intentionally obfuscated to prevent cloning
that was figured out to make SIMH work
7:55 p.m.
Date: Thu, 25 Feb 2021 12:37:25 -0800
From: Josh Dersch via cctalk <cctalk at classiccmp.org>
On Thu, Feb 25, 2021 at 12:27 PM Al Kossow via cctalk
<cctalk at classiccmp.org>
wrote:
> On 2/25/21 10:43 AM, Chris Zach via cctalk wrote:
>> Oh this is fun stuff. Is there a specification
write-up anywhere on the
>> MASSBUS overall?
> there is some documentation on bitsavers
> the register descriptions were intentionally
obfuscated to prevent cloning
> that was figured out to make SIMH work
Interesting... Is this obfuscation documented anywhere
(beyond looking at
SIMH code?) I was working on an RH11/RPxx emulation for the Unibone that
was partially working (and that I should really get back to...)
Hey, Josh! You could ask our friends Keith Perez (Massbus Disk Emulator v1)
and Bruce Sherry (MDE v2) about it, or even ask me.
The primary obfuscation was a lie in the PDP-11 documentation which swapped the
names of two signals; this drove Keith nuts until I found the PDP-10 version,
which disagreed with the PDP-11 but agreed with what he saw on th elogic
analyzer. I used to remember which two signals were involved; I'd probably be
able to recall if I could be arsed to go look at the manuals for a moment.
For those who don't know, we decided back in the early days of building Living
Computers: Museum + Labs that spinning rust with 40 year old bearings was going
to be problematical. Add to that the fact that new media was no longer being
produced, and we had to do something. My brilliant friend Keith sat down with
a logic analyzer and an RP06 attached to a KL-10, and proceeded to spend the
next two years (when not called on for other projects) creating a disk
emulator. He used a Rabbit processor for the controller, and about half a
dozen PIC processors for scut work; we could provide up to 4 RP06 or RP07
drives at a time to the KL-10s with his prototype.
Later, Bruce came on board as the museum was ramping up, and redid the design
in a Xilinx chip with VHDL. His was fast enough to support up to 8 RP06 or
RP07 drives (the max on a single channel); he also did a variant which could
emulate up to 8 Massbus attached tape drives, of the TU78 type.
As for operating system support, the only DEC operating system which could put
tapes and disks on the same Massbus was TOPS-20. Tops-10 explicitly tells you
in the SYSGEN process that disks and tapes must reside on different channels; I
believe that ITS follows that same principle. WAITS, although originally a
highly divergent offshoot of Tops-10, took the Massbus code from TOPS-20 v5
when it was ported to a KL-10 at SAIL, so could in theory have disk and tape on
the same channel.
At LCM+L, because the emulators acted as both controllers and peripherals, we
had to devote separate channels to disk and tape, even under TOPS-20, but it
was the hardware, not the OS, which required that. We also had to use two MDEs
on the KL-10 boxes; since dual channel disks were not possible, the front end
11/40 needed its own MDE.
We eventually put Bruce's MDEs on the DECSYSTEM-20 (running Tops-10) and the
other KL-10 (running WAITS), the PDP-11/70 running Unix v7, the KI-10 based
DECsystem-10 running Tops-10 v6.03A, and the MIT-AI KS-10 which was purchased
from CZ way back in the early days. (I rebuilt the
RM03 power supplies and
replaced the HEPA filters on them while Keith was working on
the first MDE.)
We also sent one to Michael Thompson to repay him for lending us some hardware
back in the early days.
Rich
P.S. We're about 10 days from the 1st anniversary of the closing of LCM+L to
the public. Lift a pint in memory of the most fun we ever had standing up.
26 Feb
26 Feb
1:47 a.m.
Rich Alderson wrote:
As for operating system support, the only DEC
operating system which
could put tapes and disks on the same Massbus was TOPS-20. Tops-10
explicitly tells you in the SYSGEN process that disks and tapes must
reside on different channels; I believe that ITS follows that same
principle.
KS10 ITS has MIT hacked microcode for IO instuctions hardwired to use
UBA 1 for disk and UBA 3 for tape.
KA10 and KL10 ITS have TM10 I/O bus tape controllers, optionally using a
DF10 channel.
7:56 a.m.
On 2021-02-25 8:55 p.m., Rich Alderson via cctalk wrote:
...
Hey, Josh! You could ask our friends Keith Perez (Massbus Disk Emulator v1)
and Bruce Sherry (MDE v2) about it, or even ask me.
...
produced, and we had to do something. My brilliant friend Keith sat down with
a logic analyzer and an RP06 attached to a KL-10, and proceeded to spend the
next two years (when not called on for other projects) creating a disk
emulator. ...
Later, Bruce came on board as the museum was ramping up, and redid the design
in a Xilinx chip with VHDL. ...
Are the above projects published?
--Toby
As for operating system support,...
Rich
P.S. We're about 10 days from the 1st anniversary of the closing of LCM+L to
the public. Lift a pint in memory of the most fun we ever had standing up.
8:40 a.m.
Toby Thain wrote:
Rich Alderson wrote:
See here:
https://github.com/livingcomputermuseum?tab=repositories
You could ask our friends Keith Perez (Massbus
Disk Emulator v1) and
Bruce Sherry (MDE v2) about it, or even ask me. ... produced, and
we had to do something. My brilliant friend Keith sat down with a
logic analyzer and an RP06 attached to a KL-10, and proceeded to
spend the next two years (when not called on for other projects)
creating a disk emulator. ...
Later, Bruce came on board as the museum was ramping up, and redid
the design in a Xilinx chip with VHDL. ...
Are the above projects published? 
8:48 a.m.
On 2/26/2021 8:40 AM, Lars Brinkhoff via cctalk wrote:
Toby Thain wrote:
Also here is Rich's
announcement on DEC-10 day of 2017
Rich Alderson wrote:
See here:
https://github.com/livingcomputermuseum?tab=repositories You could ask our friends Keith Perez (Massbus
Disk Emulator v1) and
Bruce Sherry (MDE v2) about it, or even ask me. ... produced, and
we had to do something. My brilliant friend Keith sat down with a
logic analyzer and an RP06 attached to a KL-10, and proceeded to
spend the next two years (when not called on for other projects)
creating a disk emulator. ...
Later, Bruce came on board as the museum was ramping up, and redid
the design in a Xilinx chip with VHDL. ...
Are the above projects published?
Happy DEC-10 Day!
It is my honor to announce that we at Living Computers: Museum + Labs
are releasing to the computing community our Massbus Disk Emulator
and all the associated software. This device connects via Massbus
cables to the RH10 and RH20 interfaces on KI-10 and KL-10 systems, to
the RH11 interface on KS-10 and small PDP-11 systems (including the
front end 11/40 on the KL-10), and to the RH70 on the PDP-11/70. The
MDE provides up to 8 emulated RP06 or RP07 disks (represented by disk
files in the format used by the SimH emulation of these systems).
We expect that it will also work with the RH780 on the VAX-11/780 and
VAX-11/785 although we have not yet tested it in this configuration.
The original MDE was designed by Keith Perez in 2005, and emulated up
to four RP06 drives connected to a KL-10. The current generation was
a redesign by Bruce Sherry in conjunction with the restoration of our
DECsystem-1070 in 2012, and initially provided eight RP06 drives on
the RH10. It has undergone continual development, with associated
software created for us by Bob Armstrong, and is now being opened up
for the use of the relevant communities.
To this end, we have placed the design files for the hardware and the
source files for the software to interface with it, along with our
library of Universal Peripheral Emulator routines, on public access
repositories at Github. The URLs for these repositories are
https://github.com/livingcomputermuseum/MDE2
https://github.com/livingcomputermuseum/MBS
https://github.com/livingcomputermuseum/UPELIB
These are released under a very liberal license which will allow for
free use of the MDE by any interested party.
Happy Dec-10 Day!
Rich
Richard Alderson, Sr. Systems Engineer
Living Computers: Museum + Labs
2245 1st Avenue S
Seattle, WA 98134
Cell: (206) 465-2916
Desk: (206) 342-2239
http://www.livingcomputerss.org/
--
John H. Reinhardt
9:07 a.m.
On 2021-02-26 9:40 a.m., Lars Brinkhoff wrote:
Toby Thain wrote:
Very nice, thanks.
--T
Rich Alderson wrote:
See here:
https://github.com/livingcomputermuseum?tab=repositories
You could ask our friends Keith Perez (Massbus
Disk Emulator v1) and
Bruce Sherry (MDE v2) about it, or even ask me. ... produced, and
we had to do something. My brilliant friend Keith sat down with a
logic analyzer and an RP06 attached to a KL-10, and proceeded to
spend the next two years (when not called on for other projects)
creating a disk emulator. ...
Later, Bruce came on board as the museum was ramping up, and redid
the design in a Xilinx chip with VHDL. ...
Are the above projects published? 
2 Mar
2 Mar
7:27 p.m.
On Thu, 25 Feb 2021 at 21:32, Rich Alderson via cctalk
<cctalk at classiccmp.org> wrote:
As for operating system support, the only DEC
operating system which could put
tapes and disks on the same Massbus was TOPS-20. Tops-10 explicitly tells you
in the SYSGEN process that disks and tapes must reside on different channels; I
believe that ITS follows that same principle. WAITS, although originally a
highly divergent offshoot of Tops-10, took the Massbus code from TOPS-20 v5
when it was ported to a KL-10 at SAIL, so could in theory have disk and tape on
the same channel.
RSX-11/M+ should as well. It is possible during SYSGEN to define a
"mixed MASSBUS".
Best regards,
Christian
--
Christian M. Gauger-Cosgrove
STCKON08DS0
Contact information available upon request.
1740
days inactive
1746
days old
18 comments
12 participants
participants (12)
-
aekï¼ bitsavers.org -
billdegnanï¼ gmail.com -
captainkirk359ï¼ gmail.com -
ccï¼ alderson.users.panix.com -
czï¼ alembic.crystel.com -
derschjoï¼ gmail.com -
jncï¼ mercury.lcs.mit.edu -
johnhreinhardtï¼ thereinhardts.org -
larsï¼ nocrew.org -
paulkoningï¼ comcast.net -
radioengrï¼ gmail.com -
tobyï¼ telegraphics.com.au