There's a copy of ultrix-11, which is v7 based with some 4.1BSD additions, including sockets and a TCP/IP stack. Don't know if it runs on the smaller PDP-11, but it looks like it might. The sources are in the TUHS archives. Seems like the best low-end v7ish kernel with TCP/IP around, but I've not used it extensively. Warner On Fri, May 19, 2017 at 1:04 PM, Ron Natalie <ron(a)ronnatalie.com> wrote:

On Sun, May 21, 2017 at 12:16 PM, Dave Horsfall <dave(a)horsfall.org> wrote: ​It was world wide. The /60 was the fastest machine from release to traditional product in DEC's history.​ ​Indeed. @ Tek we had both the DEC tools and the CMU tools and the 11/40e microcode from CMU (and the compiler that used csav/cret - probably still do somewhere). One problem was the microcode compiler from DEC ran on RSX and CMU's ran on TOPS-10 of which I had neither. ​ The /60 and /40 had similar but different base microengines and it was going to take some work reimplementing the CMU extens for the 60. I've forgotten the details of what changed in the microengine, but something was hugely different and enough that the CMU microcode would have been a model, but would not work even if I could manage to get the tools together. So, it was also on my todo list, but we got an 11/70 shortly after I pulled together the pieces and we never got to it. What I can tell you from the CMU experience is that it bought a small amount of speed up, but the big thing code size reduction for some programs and on 40 class machine -- anything like that helped. But... the problem was it made the binaries not portable. We had to be very careful. The EE production machines (which were 11/34 and later /34As) binaries of course could run on the CS systems, but the CS machines with the /40e microcode, compiler et al, created binaries that core dumped on the 34. Worse yet, was accidently mixing libraries. Ted and I talked about hacking the EE kernel to support a UUI like the FPs did could take the CS binaries and run them. But that project never occurred - which was probably a shame. Instead, Danny Klein and I got really good at purging any tape or disk that passed through a CS system for anything binary on it. Clem

Actually, the 11/60's main claim to fame was it supposed to be a 'commercial' PDP-11 and was built for the small business market. The WCS was a side effect. It was to built to run RSTS and RSX and had a commercial instruction set exten *etc.*. Somebody had written a 'dentist office' package for it and a 'car dealership package' IIRC. And was physically packaged a tad differently than the other 11's as it was trying to be marketing to places that might want to show it off instead of hiding it in a computer room. The main competition at the time was the Burrough 1700 and the IBM System 38 and DEC was trying to find a system to compete in the market. Now, the B1700 is a very cool system and could swap its microcode depending on the language running (it is also bit addressable). As I understand it from talking to the 11/60s product manager many years later at a party, one of the ideas was that the PDP 11/60 WCS an attempt to be able offer features that might be needed to compete with it. The the real truth was that issue in the original 11's had stored the ucode in PROM and if an ECO went out the CPU boards had be swapped, so the chips could be swapped at the factory. Plus a number of places, like MIT and CMU had been banging on DEC to make the ucoding of the system an available option (CMU just built it's own the 11/40e that triple drip made for them). Anyway, as the price of SRAM had fallen dramatically from when the 11 was introduced, and the 11/60 was storing the primary ucode it, not PROM like the other 45 and 40 class systems; WCS became a possible feature to expose. But, as I said, the problem was that the WCS tools were not very portable and the microengine was (as I remember) not well enough documented. Which is why I don't think many people tried. Also the 11/60 also had a unique feature we called the HCU instruction - Halt and Confuse Microcode. Unlike the 11/34 which had an Intel 8008 that ran front (programmers) console, the 11/60's microcode loop read the LED's and keypad. But ... if the ucode took a dive, the only recourse was turn off the system - as it would stop responding to anything (just like PC years later ;-) We never found what sequence caused it; but when I was debugging the original 11/60 port of V6, I would run into a lot ;-) IIRC - we realized on these pages that Dave Horsfall in OZ and I in Oregon must have been doing similar work around the same time. FWIW, my changes made it back to AT&T via Ted and I believe eventually went out in the System III release. That said, I suspect if we were to compare our patches I bet they are pretty similar. Clem On Sun, May 21, 2017 at 4:57 PM, Ron Natalie <ron(a)ronnatalie.com> wrote: