On 2015-01-06 23:56, Clem Cole<clemc(a)ccc.com> wrote:
On Tue, Jan 6, 2015 at 5:45 PM, Noel Chiappa<jnc(a)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(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol