29 Jan
2015
29 Jan
'15
5:46 a.m.
On 2015-01-29 03:10, Noel Chiappa wrote:
I did find two brochures on bitsavers about Enable/34, and one of them
also mentions Megabox.
"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.
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.
That would imply you could not address more than 256K from the CPU. Not
likely...
An 11/34 do not have any EUB slots.
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.
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...)
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.) 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. 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. 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. 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. 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). 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. 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