Differences between the PDP-11/15 and PDP-11/20

Noel Chiappa jnc at mercury.lcs.mit.edu
Sun Aug 21 12:53:56 CDT 2016

    > I'm not sure how the KT11-B works, but my _suspicion_ ... is that it's
    > not part of the CPU, but a UNIBUS device

So, I wuz wrong.

The Option Description (part User Manual, with a little bit of Technical
Manual thrown in) is now online:


Having looked through it, the KT11-B is a far more impressive beast than I
thought: there are -11/20 KA11 CPU processor mods to provide User and Exec
mode (i.e. real hardware time-sharing) - there is in fact another cable
between the CPU and KT11-B, it did not show up in the pictures, I guess - and
the memory mapping is paging, with page tables kept in core. (Just like a
junior KI10...)

Using the OD, I have prepared a page in the Computer History for it:


which gives (I modestly claim :-) a clear and concise overview of how the
whole thing works. (The details are all there in the DEC document, but
scattered throughout, in dribs and drabs.) The DEC thing will be a much
easier-to-grok read if you've read this first, I reckon.

The OD does contains some minor details that aren't in the Wiki page (e.g.
you apparently can't modify the CPU's priority in User mode), so if you're
really interested in the thing, read the OD too.

A couple of observations:

First, it does not contain anything like SSR1 in the standard PDP-11 memory
management, which records which registers have changed, and by how much, on
an instruction which gets a fault. It does record a couple of internal KA11
major state bits:


which do allow one, after examinging the instruction which faulted (the
address of which is provided in a KT11-B register), to work that out (unlike
the -11/40, in which some instructions cannot be restarted because the CPU
just doesn't keep enough data around). Still, the code to handle faults is
going to involve parsing the instruction (like m40.s in V6 UNIX, if anyone
cares), to make use of those recorded CPU state bits.

Second, for some reason a TRAP instruction in user mode traps to user mode,
not kernel! This would be a massive PITA for Unix, which uses the TRAP
instruction, for details I won't bore you all with (unless someone cares).


More information about the cctalk mailing list