The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: ron minnich <rminnich@gmail.com>
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] Any oldtimers remember anything about the KS11 on the -11/20?
Date: Mon, 24 Jun 2019 09:21:37 -0700	[thread overview]
Message-ID: <CAP6exYJYDvn9bM18=ExLSTEYg_wT639=U=-RxoKJfDdgKi8EQg@mail.gmail.com> (raw)
In-Reply-To: <20190622181719.E10E918C0B4@mercury.lcs.mit.edu>

just double checking, in case the odd.html had a typo: it was a KS11,
not a KT11-B? Is there any chance there was an error in recollection?

ron

On Sat, Jun 22, 2019 at 11:18 AM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
>
> This is an appeal to the few really-old-timers (i.e. who used the PDP-11/20
> version of Unix) on the list to see if they remember _anything_ of the KS11
> memory mapping unit used on that machine.
>
> Next to nothing is known of the KS11. Dennis' page "Odd Comments and Strange
> Doings in Unix":
>
>   https://www.bell-labs.com/usr/dmr/www/odd.html
>
> has a story involving it (at the end), and that is all I've ever been able
> to find out about it.
>
> I don't expect documentation, but I am hoping someone will remember
> _basically_ what it did. My original guess as to its functionality, from that
> page, was that it's not part of the CPU, but a UNIBUS device, placed between
> the UNIBUS leaving the CPU, and the rest of the the bus, which perhaps mapped
> addresses around (and definitely limited user access to I/O page addresses).
>
> It might also have mapped part of the UNIBUS space which the -11/20 CPU _can_
> see (i.e.  in the 0-56KB range) up to UNIBUS higher addresses, where 'extra'
> memory is configured - but that's just a guess; but it is an example of the
> kind of info I'd like to find out about it - just the briefest of high-level
> descriptions would be an improvement on what little we have now!
>
> On re-reading that page, I see it apparently supported some sort of
> user/kernel mode distinction, which might have require a tie-in to the
> CPU. (But not necessarily; if there was a flop in the KS11 which stored the
> 'CPU mode' bit, it might be automatically cleared on all interrupts. Not sure
> how it would have handled traps, though.)
>
> Even extremely dim memories will be an improvement on the blank canvas we
> have now!
>
>         Noel

  reply	other threads:[~2019-06-24 16:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-22 18:17 Noel Chiappa
2019-06-24 16:21 ` ron minnich [this message]
2019-06-24 16:33   ` ron minnich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAP6exYJYDvn9bM18=ExLSTEYg_wT639=U=-RxoKJfDdgKi8EQg@mail.gmail.com' \
    --to=rminnich@gmail.com \
    --cc=jnc@mercury.lcs.mit.edu \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).