6 Jan
2015
6 Jan
'15
11:34 p.m.
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:
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
>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. 
6 Jan
6 Jan
11:52 p.m.
New subject: pdp11 UNIX memory allocation.
> ...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 Interdata 8/32, Bell Labs' first 32-bit Unix port target, had writable
microcode. It added a rather modest amount to the cost of the system as I
remember (about $8K). Unfortunately, it was pretty useless. The
instruction format, like many machines at the time, had opcodes and then
some of the instruction bits were use to get the operands -- register,
memory, offsets from registers, etc. The operand handling was implemented
in hardware, and any added instructions could not use get to this operand
hardware. So any new instructions that were added were pretty crippled.
Moreover, the implementation in microcode was flawed. If you tried to
load a word through a pointer that had a -1 in it (a common error in
earlier Unices where -1 was an error return from the OS), you actually got
two faults--a memory bounds error and an alignment check. Unfortunately,
these faults came at slightly different times--the alignment check
executed 2 or 3 micro instructions and then the bounds check arrived,
reset the microcode and lost all the status information. Not only was the
fault unrecoverable but the only way to clear it was to power cycle the
processor!
A bunch of us went to talk to the manufacturer and said, in effect, "We
like your machine but we won't buy any more until this fault recovery
problem is fixed". It was like talking to a bunch of cinder blocks --
they just didn't get it. Shortly afterwards the VAX arrived and the rest
was history...
7 Jan
7 Jan
4:14 p.m.
New subject: pdp11 UNIX memory allocation.
On Tue, Jan 6, 2015 at 6:34 PM, Johnny Billquist <bqt(a)update.uu.se> wrote:
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.
I did not realized it was an option. IIRC we had it on the Teklabs 11/60,
but we could not run the tools easily so we ended up never messing with it.
We had talked about adding the CMU csav/cret instructs from the 11/40e
but we got the 11/70 and that sucked up my time and I never got back to try
it.
It was not a redux of the 11/34 BTW. Jeff Mitchell did the 11/34 and was
off working on the 750 when the 60 was done. I believe Al Pat was somehow
involved with 60, but I've forgotten.
As for the "halt and confuse uCode" stuff. The 60 was notorious for
getting "stuck" when running UNIX. I've now forgotten many of the
details, IIRC it had to with context switch, register save and I think I
remember it was something to do with multiple interrupts. Since Glaser
and I did the original 11/60 port, I think we knew most of the USENIX UNIX
sites that run it on them since we swapped notes if not code. All of us
used to complain about random hangs where the uCode take a jump and the
system would halt. The only solution when that happened was the pull the
circuit breaker power on the back of the machine because the front panel
switched were lost. I personally spend many hours with the DEC guys
trying to figure what is was, we could never repeat it. Years later, when
I got to know some of the uCode engineers that had worked on the 11s and
the Vaxen, I found out it was agreed at DEC engineer there was a uCode bug,
but so few UNIX customer were out there (and the system had gone to
"traditional products") management dropped as not being worth finding and
fixing.
5:27 p.m.
New subject: pdp11 UNIX memory allocation.
On Wed, 7 Jan 2015, Clem Cole wrote:
I did not realized it [WCS] was an option. IIRC we
had it on the
Teklabs 11/60, but we could not run the tools easily so we ended up
never messing with it.
Our 11/60 certainly had it; I remember scouring the manual, trying to make
sense of it, but after five years studying at UNSW and eight years working
there (almost got long service leave!) I got itchy feet. Besides,
although the CSU was a great place to work, I didn't like the plans to
merge it with the Chancellery (the bureaucratic centre), lest I come to
work one morning and find myself working on a COBOL program...
The provenance of the beast was that apparently a deal with some big
publishing house fell through (Limited News, perhaps?) and DEC was stuck
with a warehouse full of them; it seems the WCS was to be used for the
typesetting or something, I dunno; they could always have yanked the WCS?
[...]
The only solution when that happened was the pull the
circuit breaker
power on the back of the machine because the front panel switched were
lost.
Don't all 11s have the same key? I used to carry one on my key-ring.
--
Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server."
http://www.horsfall.org/spam.html (and check the home page whilst you're there)
3409
days inactive
3410
days old
3 comments
4 participants
participants (4)
-
Clem Cole -
Dave Horsfall -
Johnny Billquist -
scj＠yaccman.com