29 Jan
2015
29 Jan
'15
7:57 a.m.
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_u…
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