I don’t know. It would be hard to replicate because of the custom HW and the custom uCode that ran on the 11/40s. I even think that the 11/20s were modified as well. So trying to figure that out would be “interesting”. ;-) There is documentation on bitsavers that covers the custom uCode HW for the 11/40s. The MMU as I recall was also radically different than what was standard on 11/40s (and non-existant on 11/20s…the 11/20 changes started to get to be so large, I believe later on they just ditched the 11/20s and C. was just all 11/40s) to allow for really large memory spaces…I don’t recall what the maximum possible memory on C. was, it did have 1.2MB while I was there.
And that’s just the HW. Hydra (the OS that ran on C.MMP) was a capability based system (so you needed the proper capability to do anything). I recall at one point the grad student who was doing work on the file system, “lost” the root capability to the file system…so it was no longer possible to create new file systems. Since C.MMP was a “one off” system, don’t expect (even if the SW survives) that there’s an “installation guide”. ;-) It was pretty organic. Last and not least, all of the code was either PDP-11 assembler or BLISS-11. It was all cross built from the (heavily) modified TOP-10 systems that the CS department was running. Hydra did a number of things that eventually lead to Accent and then Mach (which portions are still in use in the guts of OS X). It was what we would call today a microkernel system in that the kernel was the only thing that ran in privileged mode. Everything else were user processes (file system, drivers, terminal system, etc). As I said, it was a capability based system, so to use something you needed to have a capability to it (files didn’t have Unix style permissions…if you had a capability to a file that capability determined what you could do to the file). It had a number of reliability traits: it could detect failures in HW and in SW and restart the appropriate failed item. In the case of CPUs and memory, it could “wall off” the failed component can cause diagnostics to be run to either isolate the problem further or determine that the failure is no longer present. TTFN - Guy > On Sep 16, 2019, at 10:59 AM, Paul Koning <paulkon...@comcast.net> wrote: > > > >> On Sep 16, 2019, at 1:52 PM, Guy Sotomayor Jr via cctalk >> <cctalk@classiccmp.org> wrote: >> >> The only thing that I believe would have used these would have been C.MMP. >> It had 1.2MB of memory on it when I was there. >> >> TTFN - Guy > > It's been a long time since I've heard that reference. Did any of that > software get preserved? I wonder how hard it would be to make SIMH handle it. > > paul >
