28 Jan
2015
28 Jan
'15
6:10 p.m.
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... :-)
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.
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 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.
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.
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...
Noel