From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
To: tuhs@tuhs.org
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6
Date: Mon, 31 Dec 2018 12:20:08 -0500 (EST) [thread overview]
Message-ID: <20181231172008.2499718C073@mercury.lcs.mit.edu> (raw)
> From: Will Senn
> Thanks for not dismissing the thread as frivolity.
Hey, anyone wanting to do things with V6 I take seriously! :-)
> I'm sure y'all have seen Mills's winning Best in Show IOCCC entry:
> https://www.ioccc.org/2018/mills/hint.html
Yes, that was pretty awesome.
> Fantastic, I'm prolly gonna try it.
OK; if you want to know what it's doing (somehow I figured you probably didn't
just want to simply follow the instructions :-) that is different from the /40
(it's quite different, and somewhat complicated), I just wrote this:
http://gunkies.org/wiki/Unix_V6_kernel_memory_layout
to explain it a bit. Currently, one has to read the source to 'sysfix', and
also m45.s, to understand how the /45 version works; that new page is a little
crude still, but it hopefully explains the big picture.
> If the instructions in Setting up are as good for the 45 as they are for
> the 40, I should be able to bring one up relatively painlessly.
I just took a look at "Setting up UNIX - Sixth Edition", and it doesn't really
say much about the /45; it basically just says 'the /45 is wiered inside' and
'look at sys/run'. It is certainly true that that does cover all one needs to
bring V6 up on the /45, but... The coverage of what to do if your '45' has
hardware floating point is pretty complete, though.
> What it sounds like is that Unix was transitioning from non-I/D land to
> I/D land and maintaining a measure of backward compatibility
That's pretty accurate. One main advantage of the /45 is that it could have a
lot more disk buffers, but I'm not sure that makes much difference for
emulation. If you have some application that won't fit well in 64KB, that's
big, but that's a user-land difference, not the OS.
> Is there a bootable tape of the MIT system extant?
Not yet, sorry. I do have a complete dump, but it i) includes all the users'
personal files, and ii) is not well organized. It's on my to-do list.
Noel
next reply other threads:[~2018-12-31 17:20 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-31 17:20 Noel Chiappa [this message]
-- strict thread matches above, loose matches on Subject: below --
2018-12-31 18:38 Noel Chiappa
2018-12-31 20:06 ` Warner Losh
2018-12-31 6:51 Noel Chiappa
2018-12-31 15:06 ` Will Senn
2018-12-31 15:50 ` Clem Cole
2018-12-31 15:53 ` Warner Losh
2018-12-31 15:59 ` Clem Cole
2019-01-01 1:56 ` Eric Allman
2018-12-31 2:25 Will Senn
2018-12-31 2:43 ` Clem cole
2018-12-31 3:31 ` Will Senn
2018-12-31 14:55 ` Clem Cole
2018-12-31 15:05 ` ron
2018-12-31 15:53 ` Clem Cole
2018-12-31 17:30 ` ron
2018-12-31 18:20 ` Paul Winalski
2018-12-31 2:47 ` Clem cole
2018-12-31 3:08 ` Will Senn
2018-12-31 3:15 ` Clem cole
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=20181231172008.2499718C073@mercury.lcs.mit.edu \
--to=jnc@mercury.lcs.mit.edu \
--cc=tuhs@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).