[TUHS] pdp11 UNIX memory allocation.

Johnny Billquist bqt at update.uu.se
Wed Jan 7 09:34:06 AEST 2015


On 2015-01-06 23:56, Clem Cole<clemc at ccc.com> wrote:
>
> On Tue, Jan 6, 2015 at 5:45 PM, Noel Chiappa<jnc at mercury.lcs.mit.edu>
> wrote:
>
>> >I have no idea why DEC didn't put it in the 60 - probably helped kill that
>> >otherwise intersting machine, with its UCS, early...
>> >
> ?"Halt and confuse ucode" had a lot to do with it IMO.
>
> FYI: The 60 set the record of going from production to "traditional
> products" faster than? anything else in DEC's history.     As I understand
> it, the 11/60 was expected to a business system and run RSTS.  Why the WCS
> was put in, I never understood, other than I expect the price of static RAM
> had finally dropped and DEC was buying it in huge quantities for the
> Vaxen.  The argument was that they could update the ucode cheaply in the
> field (which to my knowledge the never did).   But I asked that question
> many years ago to one of the HW manager, who explained to me that it was
> felt separate I/D was not needed for the targeted market and would have
> somehow increased cost.   I don't understand why it would have cost any
> more but I guess it was late.

No, field upgrade of microcode can not have been it. The WCS for the 
11/60 was an option. Very few machines actually had it. It was for 
writing your own extra microcode as addition to the architecture.
The basic microcode for the machine was in ROM, just like on all the 
other PDP-11s. And DEC sold a compiler and other programs required to 
develop microcode for the 11/60. Not that I know of anyone who had them. 
I've "owned" four PDP-11/60 systems in my life. I still have a set of 
boards for the 11/60 CPU, but nothing else left around.

The 11/60 was, by the way, not the only PDP-11 with WCS. The 11/03 (if I 
remember right) also had such an option. Obviously the microcode was not 
compatible between the two machines, so you couldn't move it over from 
one to the other.

Also, reportedly, someone at DEC implemented a PDP-8 on the 11/60, 
making it the fastest PDP-8 ever manufactured. I probably have some 
notes about it somewhere, but I'd have to do some serious searching if I 
were to dig that up.

But yes, the 11/60 went from product to "traditional" extremely fast.

Split I/D space was one omission from the machine, but even more serious 
was the decision to only do 18-bit addressing on it. That killed it very 
fast.

Someone else mentioned the MFPI/MFPD instructions as a way of getting 
around the I/D restrictions. As far as I know (can tell), they are 
possible to use to read/write instruction space on a machine. I would 
assume that any OS would set both current and previous mode to user when 
executing in user space.
The documentation certainly claims they will work. I didn't think of 
those previously, but they would allow you to read/write to instruction 
space even when you have split I/D space enabled.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol



More information about the TUHS mailing list