UNIBUS PDP-11 memory expander card

[Johnny Billquist]

We must obviously be talking about different products.

	Johnny


On 2015-01-29 16:57, Noel Chiappa wrote:
>      > From: Johnny Billquist
>
>      > I searched around a bit more today.
>      > I did find a couple of brochures on bitsavers that mentions it.
>
> Err, you didn't need Google for that - the first post in this thread
> mentioned it... :-)
>
>      >> Standard Extended UNIBUS (a la 11/24 and 11/44), I think.
>
>      > "Standard" is a strong word here. :-)
>
> Well, 'standard' in the sense that more than one DEC machine used it, and one
> could buy third-party memory cards that conformed to it.
>
>      > The Megabox .. 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.
>
> I _suspect_ that internally it has a backplane which supported EUB, and the
> memory plugged into that; whether that was a custom backplane, or what, I
> don't know. (I'd have to check the wire-lists on, say, a DD11-D to see if
> those pins are bussed together - I have this vague memory that they are.)
>
> And yes, _iff_ the cable to it is a standard UNIBUS cable (I don't know what
> kind of cable they used), that would only support the 18-bit address space -
> which would imply that the ENABLE card was in the Megabox.
>
>
>      >> (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...
>
> Dude, I PERSONALLY WROTE THE CODE TO USE THE ENABLE. And I have the source,
> here:
>
>    http://ana-3.lcs.mit.edu/~jnc/tech/unix/mit/conf/m47.s
>
> You are correct, the CPU cannot _directly_ address more than 256KB. However,
> the ENABLE board _can_; mapping registers in the ENABLE (32 of them, each
> handling an 8KB section of incoming UNIBUS address space, from the CPU) allow
> that UNIBUS address space to be mapped, in 8KB blocks, anywhere in the 22-bit
> memory space.
>
> You will find it all laid out most ably in this old post by Mike Muuss
> (peace, Mike):
>
>    http://gopher.quux.org:70/Archives/usenet-a-news/FA.unix-wizards/81.07.12_ucbvax.2254_fa.unix-wizards.txt
>
> It looks like I used a slightly different layout of the address space on the
> UNIBUS from the CPU to the ENABLE from the one he describes (the code in
> m47.s seems to use:
>
> 		KI0-7
> 		KD0-6
> 		UI0-7
> 		UD0-7
> 		KD7		I/O page
>
> with the KI underneath the KD, unlike his; KD7 has to be at the top so that
> the CPU can get to the registers in the ENABLE), but other than that the
> details are identical. (Note that they only differ in how the registers were
> _used_, not in terms of what the hardware's capabilities were.)
>
>
>      >> 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.
>
>      > The 11/34 do not have D-space...
>
> I was talking about on the /45.
>
>      >> 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.
>
> Repeat previous comment about how I personally wrote the code to use it.
>
> Just for you, I have groveled around in the dump I'm working on retrieving,
> and found seg.h, which is the header file which contains the #defines for the
> mapping registers in Unix V6. Here it is:
>
>    http://ana-3.lcs.mit.edu/~jnc/tech/unix/mit/h/seg.h
>
> If you look at it, you will see that UISA[0] has been modified to be
> "0163736". That's how we did the ENABLE - we just changed those definitions,
> and recompiled all the system modules that touched the mapping registers, so
> that that code now talked to the 16-bit PARs on the ENABLE, and not the
> 12-bit ones in the KT (which were set once at system startup time to provide
> the static mapping - see m47.s - and then never changed again).
>
>
>      > 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.
>
> Yes, no split I/D because it was totally external to the CPU, it could only
> take the UNIBUS addresses the CPU generated and map them around.
>
>      >> 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.
>
>      > An 11/34 do not have any EUB slots.
>
> I was assuming that the ENABLE used an EUB to talk to its memory. (See
> diagram further up the original post.)
>
>
>      > (You should see Updates storage rooms...)
>
> Even better would be being allowed to poke around in there... :-)
>
>
>      > I was running RSX-11M and RSX-11M-PLUS on our 11/34, and no
>      > modifications to the kernel was needed.
>
> There must have been some changes somewhere, since as you can see from the
> code above, the ENABLE had PARs in non-standard locations (0163700-0163776).
>
>
> Anyway, if you could find the documentation that would be super-wonderful,
> because I am _really_ curious to know exactly how the thing interfaced to the
> incoming UNIBUS, outgoing UNIBUS, memory, and cache.
>
> 	Noel
>