From: email@example.com (Noel Chiappa)
To: firstname.lastname@example.org, email@example.com
Subject: [TUHS] Re: LSX issues and musing
Date: Mon, 11 Jul 2022 17:24:13 -0400 (EDT) [thread overview]
Message-ID: <20220711212413.29B5618C097@mercury.lcs.mit.edu> (raw)
> From: Gavin Tersteeg
> I spent a lot of time getting UNIX V6 working on my PDP-11/23 system.
> It took a lot of tinkering with the kernel and drivers to make it work
> in the way I wanted to
You must have made a lot of changes for it to take "a lot of tinkering".
Bringing V6 up on the /23 has been done several times, and when I did
it, it only took about 2 dozen lines of code in about 2 files. What all
did you wind up changing?
> From my research, it seems like there were two different UNIX variants
> that could run on a system like this. These variants were LSX and
> MINI-UNIX. MINI-UNIX seems to require a decent mass-storage device like
> a RK05 and some porting to work on an 11/03, while LSX is designed to
> work on exactly the hardware specs that I have on hand.
Bringing up MINI-UNIX on the /03 has been done at least twice; once
historically (now lost, AFAIK), and again recently:
I'm not sure what you're basing the "MINI-UNIX seems to require a decent
mass-storage device like a RK05" on - it should run as well on whatever
you're running LSX on as LSX does.
I haven't run LSX myself, but from what I've seen, the only significant
difference between the two is that LSX will run with less main memory than
MINI-UNIX (which really kind of needs 56KB; LSX you can probably get away
with 40KB).That was a significant issue when the LSI-11 was originally
released, but these days one has to really work to have a QBUS PDP-11 with
less than 56KB.
> my EIS-less 11/03
EIS chips can be found on eBait for not much money (I just bought a couple
myself), and it's worth investing in one, so on can dispense with the
emulator, which takes real memory for which a better use can be found.
> The first issue is that the C compiler will randomly spit out a "0:
> Missing temp file" when attempting to compile something. This is
> annoying, but circumventable by just running the same command over and
> over until it works.
Schaeffer's Law (from Larry Niven): anything you don't understand
might be dangerous. I'd track down why this is happening.
next reply other threads:[~2022-07-11 21:24 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-11 21:24 Noel Chiappa [this message]
2022-07-11 21:37 ` Gavin Tersteeg
-- strict thread matches above, loose matches on Subject: below --
2022-08-05 4:35 Paul Ruizendaal via TUHS
2022-08-03 15:17 Noel Chiappa
2022-07-31 19:57 Noel Chiappa
2022-08-01 5:37 ` Heinz Lycklama
2022-08-02 17:56 ` Gavin Tersteeg
2022-08-03 4:32 ` steve jenkin
2022-08-03 4:55 ` Ron Natalie
2022-08-03 5:09 ` G. Branden Robinson
2022-07-11 23:47 Noel Chiappa
2022-07-15 8:07 ` Gavin Tersteeg
2022-07-27 8:02 ` Gavin Tersteeg
2022-07-27 16:24 ` Heinz Lycklama
2022-07-30 4:39 ` Gavin Tersteeg
2022-07-11 21:47 Paul Ruizendaal via TUHS
2022-07-11 21:06 Noel Chiappa
2022-07-11 19:47 [TUHS] " Gavin Tersteeg
2022-07-11 20:01 ` [TUHS] " Warner Losh
2022-07-11 20:26 ` Clem Cole
2022-07-11 20:30 ` Warner Losh
2022-07-11 20:37 ` Phil Budne
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).