UNIBUS PDP-11 memory expander card

[Johnny Billquist]

On 2015-01-29 03:10, Noel Chiappa wrote:
>      > From: Johnny Billquist
>
>      > However, the was one board that went into the CPU box, and then there
>      > was a cable or two out from that to a separate memory box that held the
>      > memory. So the memory cards themself was not in the CPU box
>
> Right, that's a product called the Megabox; details I can find online about
> it are thin, but it seems to include the Extended UNIBUS backplane the memory
> sits on, and the memory cards. (Google 'ABLE Enable Megabox' and it'll pop up
> a short Computerworld blurb about it.)

I did find two brochures on bitsavers about Enable/34, and one of them 
also mentions Megabox.

>      > The machines that had more than 256K of memory, and were Unibus based,
>      > and had the memory on the "unibus" actually had a special backplane for
>      > the memory cards, where otherwise unused signals were used to do the
>      > extra addressing bits.
>
> Standard Extended UNIBUS (a la 11/24 and 11/44), I think.

"Standard" is a strong word here. :-)
Yes, it is called "Extended Unibus", and it's specially wired slots in 
the CPU backplane. Ie. you can only install the memories in slots 9-12 
on an 11/44 or slots 3-6 on an 11/24.

In the 11/44 those slots should be left empty if memory is not installed 
there, while on the 11/24 they are normal SPC slots otherwise.

>      > Which also means that all the memory cards had to sit in the same
>      > backplane as the CPU. They could not be put in any other Unibus
>      > backplane.
>
> Anyway, no, the memory did not have to be in the same backplane as the CPU;
> see the Megabox, where the memory was in that box.

Now you are mixing two different topics.

The above was about Unibus memory on machines able to address more than 
256K.(Ie. the 11/24 and 11/44.)
And for those machines the memory *have* to be on the CPU backplane. 
Think about it for a second. The Unibus only have 18 address lines. How 
do you ever expect anything addressing beyond 256K to work? The extra 
address lines just magically hop from one backplane to the next?

The Megabox, which is a different solution, actually have its own 
backplane (it's its own box...), and its own connection to the main 
system, and only holds memory. As far as I know, it is not a Unibus at 
all. And it still could not be a Unibus, for the same reason I mentioned 
above.

It is *physically impossible* to address more than 256K on a Unibus.

And the 11/70 is another example of a machine that did not have the 
memory in the same backplane as the CPU. It has a memory bux instead. 
The 11/24 and 11/44 are actually conceptually similar, even though there 
the memory sits in the same backplane. They do have a (partly) separate 
bus to address the memory.
And the same is true of the Able product.

> However, a caveat: there is some possibility there was more than one version
> of the ENABLE, in which case two seemingly contradictory statements about
> 'the' ENABLE might in fact both be correct. But until that's shown, let's
> assume there's only one kind... :-)

There are two products (see my other reply), but it would appear that 
they share some parts.

> The thing that I think did have to be on (in, actually - see below) the main
> UNIBUS was the ENABLE card. I think the logical configuration was like this
> (diagram semi-ripped off from Mike Muuss' email):
>
>      Processor ---------- ENABLE ------------------------ Term.
>                  UNIBUS    |                 |  UNIBUS
>                            | EUB             |
>                            |                 |
>                            |_ 11/44 style    |
>                                 memory       |_ Devices (both DMA and
>                                                          non-DMA)
>
> I think all the devices - well, you could have put non-DMA devices on the
> section between the CPU and the ENABLE - all DMA devices at least, had to be
> on the second UNIBUS, because the ENABLE included a UNIBUS map, which was
> separate from the PARs used for CPU accesses, so I think that's pretty
> conclusive that the CPU and DMA devices did not share a UNIBUS.

The DMA is still the easy and obvious part. The interesting question is 
how CPU memory addressing worked.

>      > and you'll get a new MMU which implements all the bits in the PAR
>      > registers. ..
>      > So, it also implies that the original MMU have to be removed.
>
> No. (And I can show you the code... :-) The original MMU was retained; the
> ENABLE included only a second set of PARS (full 16-bit wide), which were the
> ones normally used while the system was running; the PDRs in the CPU
> continued to be used as the _only_ PDRs in the system.

That would imply you could not address more than 256K from the CPU. Not 
likely...

> The style of usage was to, using the CPU's PARs, statically map Kernel D
> space to one quadrant of UNIBUS address space, Kernel I to a second, User D
> to a third, and User I to the fourth. (You wanted to use Supervisor mode too?
> Thhhppptttt!) Those mappings would be on the segment between the CPU and
> ENABLE; once initially set up, those mappings (i.e. CPU PAR contents) were
> never changed.

The 11/34 do not have D-space...

> The PARs on the ENABLE card (which controlled which part of real memory
> various addresses on the first UNIBUS got mapped to) were the ones the
> operating system adjusted as the system was running.

Sorry, this is simply not how it worked.
Like I said, I actually used an 11/34 with the ENable/34 and the 
separate memory box for a few years.
It really looked and behaved identically to an 11/24.
Ie, full 16-bit PARs, still no split I/D space.

>      > And that is where you put the new card in.
>
> I don't think so.
>
> I'm kind of hazy on exactly how this was all wired up: there are the fingers
> on the card (which I think _might_ be the EUB used for the memory bus), the
> UNIBUS edge connector on the ENABLE card, and that over-the-back connector on
> the ENABLE card. Then there were 4 things that had to be connected up: the
> CPU UNIBUS, the memory EUB, the device UNIBUS, and an optional cache memory
> card ... but we have only three connectors. So whether the cache somehow hung
> off the EUB, or directly from the ENABLE via a custom backplane, or what, I'm
> not sure.

An 11/34 do not have any EUB slots.

>      > I don't know anything about the 11/45 extension this way. Like I said,
>      > I only played with an 11/34 that had this.
>
> Anything you could do on the /34 could of course also be done on the /45
> (since the ENABLE did not involve any mods to the CPU, it just interfaced to
> the UNIBUS).

Right. And after my hunting this morning, it turned out that the 
Enable/34 was usable both on the 11/34, 11/45 and 11/60.

> Although I have this bit set that perhaps it - or, one variant of the ENABLE
> (see comment above about more than one) - somehow used the fast memory slots
> in the 11/45 backplane (originally designed for special high-speed solid
> state memory) and that's how you got full advantage of the cache. (I have
> this distinct memory of running 'mips' on our /45 after it was upgraded and
> the result was '3'...) But probably something in my memory is flaky - it was
> a long time ago.

Able also had a memory product for the 11/45 Fastbus. That, however, did 
not extend the addressing in any way.

>      > I probably should try to find the documentation for exact details here
>      > then. I might be able to track down the machine, but I haven't seen it
>      > in almost 20 years.
>
> If you could track down the documentation, that would be really good.

I'm starting to feel I really should.

Having thought a few more minutes, am *know* we had the documentation. 
Now it's just a question of if we still have it, and where it is.
(You should see Updates storage rooms...)

> The programming of the thing we can work out (in addition to my code for V6
> Unix, there is code online for other versions of Unix which support it, e.g.
> BSD2.9). It's the physical installation details which are murky...

I was running RSX-11M and RSX-11M-PLUS on our 11/34, and no 
modifications to the kernel was needed. But you did have to lie to 
SYSGEN, and say that you had an 11/24, or else it would not use the full 
16 bits of the PARs.

	Johnny