Anyone have any info on the obscure MX11 PDP-11 option?

[Guy Sotomayor Jr]

One place to look and see if there was anything, is to look for any hardware information
about C.MMP at CMU.  Since C. had a mix of modified 11/20s and 11/40s, there *may*
be some information on what they did.

Unfortunately I don’t think it would map directly because C. had (as I recall) 1.2MW of
memory off of the cross point switch.  It was probably capable of more, but I know at
the time I was doing stuff on C., it had 1.2MW.

For those not familiar, C.MMP was a 16-way multiprocessor using PDP-11s that ran
an OS called Hydra.  As far as I remember, the individual 11’s had 8K of local memory
and everything else was accessible through the memory off of the cross-point switch
(basically think of it as 16-port memory).  The cross point switch was pretty spectacular
since there were LEDs at each “intersection” (processor and memory) for a total of
256 LEDs (in a 16 x 16 array).  The LED lit when a processor was accessing a particular
memory region.  It made for some spectacular light shows!

TTFN - Guy

> On Jun 24, 2019, at 1:38 PM, Noel Chiappa via cctalk <cctalk at classiccmp.org> wrote:
> 
> While I asking on the TUHS list about the KS11, someone mentioned the MX11
> Memory Extension Option, described as "enabl[ing] the usage of 128 KW memory
> (18-bit addressing range) ... developed by the Digital CSS (Computer Special
> Systems)".
> 
> I'm not familiar with this, and I couldn't find anything about it. (It's not
> even in the Spare Modules Handbook, but then again, neither is the KS11 -
> although the KT11-B is). Some early UNIBUS device address lists (e.g. the '72
> "peripherals and interfacing handbook") list up to six, from #1 at 777600-06
> to #6 at 777650-56.
> 
> I can _guess_ what it did, from the description above (e.g. maps an 8KB block,
> since there can be up to 6), but I was wondering if anyone had any hard data;
> e.g. memories based on using one BITD, etc, etc.
> 
> Even a high level description (e.g. 'sat on the UNIBUS between the CPU and
> extra memory, and mapped a fixed block of low UNIBUS address space to a block
> controlled by a register') would be an improvement on what we have now, which
> is basically nothing.
> 
>       Noel