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@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
