> From: Eric Smith
> One version of the RH11 added a small FIFO (called a "silo" by DEC,
> IIRC) in the data path. I don't recall which suffix that was, nor
> whether it was the version used in the KS10.
Well, the -AB has the FIFO, according to the Revision J prints (September
1993). It's on the M7294 card (see drawings DBCC/D).
Interestingly, I have prints for an RH11-B! That appears to differ by
having an M7295-YA; that differs from the M7295 by having a hand ECO
(i.e. same etch), part of which can been seen in the lower left corner
of drawing BCTB - the two one-shots.
As to the RH11-C, I looked, and we do have the KS10 prints (MP00540,
mis-labelled "KS10_MaintSch" :-), and it does include RH11 prints. Alas,
those show an M7294, not the claimed M9294-YA. :-( The RH11 sheets are also
out of order (some are at the very back of the pack), and DBCD seems to be
missing entirely. They are revision "L", and the RH11-BA prints are revision
"H", FWLTW.
Noel
> From: J?rg Hoppe
> UniBone can be used in UNIBUS-A SPC slots in 18 bit mode without any
> extra adapters? And can emulate an RH11-C there
As far as I can see, yes.
> even if the RH11 is supposed to run in UNIBUS B?
Well, all RH11's have both UNIBUS A and UNIBUS B; under program control, one
can select either A or B to be the one where the DMA from the RH11 happens.
(Access to the registers in the RH11 is only possible via UNIBUS A, and
interrupts from it can only happen on A.) I'm not sure exactly what your
question is, but I hope that answers it! :-)
> We've seen early SPC slots (PDP-11/40, '45) without NPG wired,
> 'cause SPC was apparently originally meant for "Small" peripherals
> without DMA. Is KS10 UNIBUS-A wired to be DMA capable?
Good question! Well, the RH11 is designed so that it can other devices
'downstream' from it, on both UNIBI. So that says that NPG is sent _through_
the RH11 on both UNIBI - but doesn't speak to the SPC slots. For that, one
needs to look at the backplane wire list - which isn't in the drawings! :-(
However, I happen to have an RH11-AB backplane, and it has the AA1-AB2 jumpers
for NPG on those three slots.
Same thing for interrupts - both UNIBI are wired to for them (although the
grant lines for UNIBUS B don't go into the RH11 cards, they are only on
the RH11 backplane).
Noel
I do not remember these RL02 drives being this heavy.....
https://i.imgur.com/7BwIwas.jpg
On a slightly more interesting note it looks like I only have RL02
drives (3) and do not have any RL01 drives. That could be a problem if I
want to re-load Cobol 81 onto this RSTS/E system. However the RL02's
*should* allow me to reboot RSX11M 4.2 and repair the instance of RSX11M
4.0 that is on my Fujitsu drive (damaged).
Likewise my RT11 images might be on RL01. However I do have the Plessey
disk drive that emulated 4 RK05's on a fixed platter and a removable
platter disk subsystem (which uses disks that look like RL01's but are
*NOT* RL01's) and I *think* I had either RT11 with MUBASIC or a really
weird Gen of RSX11M and RT11. Though I'm not sure if RSX11M would run on
RK05's as boot devices (2.5mb of space)
The dig continues. This weekend I'll see if I can fire a RL02 up.
Hi all --
Picked up a mostly complete Wangco ST-2222 drive recently. This is a
removable pack drive with one fixed platter, nominally Diablo 30 / RK05
compatible in terms of interface, but uses IBM 5540-style packs. It's in
good condition and I'd like to restore it and see if I can interface it to
an RK11.
The part I'm missing is the I/O panel -- on this particular model there was
a breakout board that bolted to the rear of the rack the drive was mounted
in (rather than being mounted to the back of the drive), and it contained
some buffers, level shifters, drive select logic, and the actual interface
connectors. There were two variants of this -- 301062 was the Diablo 30/31
style (with the big Winchester blocks) and 301291 had a more generic
interface with what looks like centronics-style connectors. (You can see
assembly drawings of them in the schematic here:
http://bitsavers.org/pdf/wangco/301462-002_Super_Series_Magnetic_Disk_Opera…,
pages 55 and 69).
I figure it's a long shot, but does anyone have one of these two boards
going spare, or have a similar drive (others in the ST family share the
same panel, it seems) that is in unrestorable/parts-donor condition they
could steal one from?
Thanks,
Josh
>2. When doing 18bit on UNIBUS-A we put all kind of signal levels
>on parity lines PA,PB = DATA<16:17>.
>Won't the KS10 CPU interpret these as real BUS parity errors generated
>by some UNIBUS-A device?
I asked nonsense here: if UNIBUS-A is 18bit too, no parity will be evaluted of course.
Joerg
>
> Date: Thu, 21 Nov 2019 22:13:30 -0500
> From: Chris Zach <cz at alembic.crystel.com>
> Subject: Re: UniBone: Linux-to-DEC-UNIBUS-bridge, year #1
>
> One of my long term questions has been to see if a 2020 could talk to a
> RM80. It should be possible as the Massbus personality module talks to
> the bus at 3600 RPM just like the RM03, and they did manage to get the
> R80 to talk to the 11/730 with a dedicated memory channel connection
> (though maybe the R80 was heavily interleaved)
>
> C
>
ITS could boot from an RM80 on a 2020.
--
Michael Thompson
> maybe the two can be jumpered together (the way the two UNIBI in the
> KD11-A/D can).
Actually, now that I think about it, that might be the reason for the order
of the UNIBUS A out B in/out slots in the backplane:
https://gunkies.org/wiki/RH11_MASSBUS_controller#Backplane_layout
One of those thin M9200 UNIBUS jumpers could be used to connect the A out to
the B in.
> Depends what you mean by "full-length"; no MUD (hex) slots, but yes to
> SPC slots (SPC)
Oooh, typo: 'SPC slots (quad)'
Noel
`
* *Messages sorted by:* [ date ]
<http://www.classiccmp.org/pipermail/cctech/2019-November/date.html#41793>
[ thread ]
<http://www.classiccmp.org/pipermail/cctech/2019-November/thread.html#41793>
[ subject ]
<http://www.classiccmp.org/pipermail/cctech/2019-November/subject.html#41793>
[ author ]
<http://www.classiccmp.org/pipermail/cctech/2019-November/author.html#41793>
------------------------------------------------------------------------
>> Although, with the 3 SPC slots - although they are on UNIBUS A, and only
>> UNIBUS B has the 18-bit capability
>
> It is of course perfectly possible to run UNIBUS _A_ (where the SPC slots are)
> in 18-bit mode too - although the _RH11_ can't use it that way. But you won't
> be using the RH11 anyway, so who cares?
>
>Also, I took another look at the KS10 tech manual, and they do in fact use use
>an M9200 'thin' jumper (although it's mis-labelled "M9300" in the diagram -
>that diagram has a number of errors, including the "M8014" in the UNIBUS 'A'
>In slot - they must mean an M9014 [UNIBUS to 3 flat cables] instead) to link
>the two UNIBI together. Which answers the question of how the KS10 CPU gained
>access to UNIBUS A (where the device registers, interrupts, etc are) when it
>also had to be connected to UNIBUS B (for 18-bit data transfers).
>
>So I think all our questions are answerered (except for the -AB/-C difference
>issue).
So I understand right:
UniBone can be used in UNIBUS-A SPC slots in 18 bit mode without any extra adapters?
And can emulate an RH11-C there, even if the RH11 is supposed to run in UNIBUS B?
Thats good news.
Two more things to check:
1. We've seen early SPC slots (PDP-11/40, '45) without NPG wired,
'cause SPC was apparently originally meant for "Small" peripherals without DMA.
Is KS10 UNIBUS-A wired to be DMA capable?
2. When doing 18bit on UNIBUS-A we put all kind of signal levels
on parity lines PA,PB = DATA<16:17>.
Won't the KS10 CPU interpret these as real BUS parity errors generated
by some UNIBUS-A device?
best regards
Joerg
> From: J?rg Hoppe
> did DEC construct 18bit mutants for a few PDP-11 peripherals to run
> them in KS10?
Yes and no. There were two 18-bit UNIBUS devices, but they were originally
done for the PDP-15 (DEC's last 18-bit machine). They were the RK11-E and the
RH11-AB. When the KS10 appeared, the RH11 was re-purposed for it.
(How the RH11-C in the KS20 differed I'm not sure. I know it used the
M7294-YA instead of the M7294, but I'm not sure how that differed. It's the
MASSBUS data buffer and control, so it's something MASSBUS related. The
RH11-AB already has the 18-bit stuff; see 4.16 "Logic Diagram DBCE", pg. 4-28
(65 of the PDF) in "RH11-AB Option Description" for details; it's poorly
documented.)
> From: Daniel Seagraves
> There's still the problem of the disk Unibus itself to solve - the disk
> UBA doesn't terminate into a normal Unibus. It goes into the disk RH11
> directly, and the bus is terminated on the far end of the RH11. ... The
> ideal scenario would be if the first slot of a RH11 (where the bus
> jumper comes in) can accommodate the (quad card) Unibone without
> issues, the rest of the RH11 boards can simply be pulled without
> breaking bus continuity
The RH11-C seems like it's very similar to the RH11-AB, physically. Both the
'disk' and 'tape' RH11-C's seem like they are separate 9-slot system units,
with the same layout (in terms of boards->slots). Both have 3 Small
Peripheral Controller slots, like the -AB.
The first slot is purpose-wired to hold the M7296 and M7297:
https://gunkies.org/wiki/RH11_MASSBUS_controller#Backplane_layout
so 'no' to that idea. Although, with the 3 SPC slots - although they are on
UNIBUS A, and only UNIBUS B has the 18-bit capability - although maybe the
two can be jumpered together (the way the two UNIBI in the KD11-A/D can).
(IIRC, the "RH11 Peripheral Controller Course" may talk about that.)
I don't think things will work with the RH11 boards pulled, unless you
manually jumper whatever pins are used to feed NPG and BG? through the
device. Probably the easiest thing is to change the bus address of the
RH11.
> From: Chris Zach
> I seem to recall that the RH11C included a full length unibus slot
> after the boards
Depends what you mean by "full-length"; no MUD (hex) slots, but yes to SPC
slots (SPC) - as above.
Noel
>> Well, I was expecting to have to do all of the work myself. There?s
still the problem of the disk Unibus itself to solve
> -the disk UBA doesn?t terminate into a normal Unibus.
> It goes into the disk RH11 directly, and the bus is terminated on the
far end of the RH11. I?d either have to buy another Unibus backplane to
plug the Unibone into, or find a way to plug the cables from the UBA
directly into the Unibone.
>This still leaves the issue of terminating the bus.
> The ideal scenario would be if the first slot of a RH11 (where the
bus jumper comes in) can accommodate the (quad card)
> Unibone without issues, the rest of the RH11 boards can simply be
pulled without breaking bus continuity,
> and the normal terminator in the far slot can be used. I haven?t
looked at any prints or anything yet.
I gave UniBone a set of pinheaders for all UNIBUS signals in parallel to
the gold fingers.
So an adapter board can be designed, which plugs onto the pinheaders,
contains some provision for the UBA connection and contains the
terminator array.
The UBA-UniBone adapter may consist of two parts coupled via flat cable,
with flipchip plugs on one end if necessary.
All this is only mildly annoying, did similar before, for example
http://www.retrocmp.com/tools/uniprobe
> Right, there were two unibus ports on a 2020: The first one went to the
> RH11-C and was very odd in that "Hog Mode DMA" was enabled to allow the
> device to just stream data as much as it wanted to the controller. This
> would mean that other devices on the bus would time out and not have
> their interrupts serviced, but since the RH11 was the only thing it
> didn't matter (and I think this is why you could use RM03's instead of
> RM02's: The whole track could be read and buffered to the 2020's UBA
> controller in one shot.
> That would have to be programmed into the BBB software to ignore the
16 word
> DMA limits and go as fast as the drive can go).
As the disk drives are also emulated, they are not putting any
constraints on the DMA logic: give them the speed and DMA length you prefer.
Joerg