The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
To: tuhs@minnie.tuhs.org
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [TUHS] PDP 11/23 running UNIX version 6 at VCF Midwest!
Date: Tue, 21 Dec 2021 16:42:20 -0500 (EST)	[thread overview]
Message-ID: <20211221214220.4A13118C07A@mercury.lcs.mit.edu> (raw)

    > From: Paul Ruizendaal

    > Does anyone remember, was this a real life bug back in 6th edition 

The 'V6' at MIT (actually, PWB1) never had an issue, but then again,
its TTY driver (here:

  http://ana-3.lcs.mit.edu/~jnc/tech/unix/mit/dmr/tty.c

if anyone wants to see it) was heavily re-written. But from the below,
it's almost certainlynothing to do with the TTY code...


    > From: Dave Plonka

    > one experiment we did was to redirection the bas(1)ic program's output
    > to a file and what we found was that (a) characters would still
    > sometimes be lost

Good test.

If you all want to chase this down (I can lend V6 expertise, if needed), I'd
say the first step is to work out whether it's the application, or the
system, losing the characters. To do that, I'd put a little bit of code in
write() to store a copy of data sent through that in a circular buffer, along
with tagging it with the writing process, etc.

Once you figure out where it's getting lost, then you can move on to
how/why.


    > From: Clem Cole

    > First Sixth Edition does not have support for either the 11/23

Yeah, but it's super-trivial to add /23 support to V6:

  http://gunkies.org/wiki/Running_UNIX_V6_on_an_-11/23

The only places where change is needed (no LKS register, no switch register,
and support for more than 256KB of main memory - and that one one can get by
without), it's hard to see how they could cause this problem.

    > One other thought, I'm pretty sure that Noel's V6+ system from MIT can
    > support a 23

No, we never ran than on a /23 BITD (no need, no mass storage); and I have
yet to bring the V6+ system up (although I have all the bits, and intend to,
at some point, to get its TCP/IP running). I've been using stock (well,
hacked a bit, in a number of ways - e.g. 8-bit serial line output) V6.

	Noel

             reply	other threads:[~2021-12-21 21:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-21 21:42 Noel Chiappa [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-12-19 17:25 Paul Ruizendaal
2021-12-20 15:43 ` Dave Plonka
2021-12-20 16:30   ` Clem Cole
2021-12-19  1:00 Dave Plonka

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=20211221214220.4A13118C07A@mercury.lcs.mit.edu \
    --to=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).