The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-10-10 23:29 Noel Chiappa
  2020-10-11  2:30 ` Jay Logue
  2020-10-11 23:24 ` Paul Riley
  0 siblings, 2 replies; 72+ messages in thread
From: Noel Chiappa @ 2020-10-10 23:29 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > I noticed a place where I used R0 as a temp ... and was being bashed.
    > So I fixed it, and now the shell starts OK, but attempting to do any
    > command (e.g. "echo foo"), things hang

Well, I had 'fixed' it; it turned out my 'fix' had a bug. :-( (The code I had
to change for the /03 there was pushing the old PS, and that and the temp I
had to push got intermangled.)

Anyway, with that fixed, the /03 Mini-Unix works now. The old user command
binaries seem to work OK on the /03; not that I've tried the all, but the ones
I have tried (including the C compiler) all worked. They all should all work
(there's nothing in user code that's model-dependent). I have tweaked the
shell (to allow 'cd') and init (to get rid of the annoying long rights
message), but that's all.

The latest, greatest mch.s is uploaded:

  http://ana-3.lcs.mit.edu/~jnc/tech/unix/Mini/mch.s

Although a couple of files (bio.c, clock.c, slp.c, and tty.c) had minor
changes (to remove direct rerferences to the PS; they now call getps() and
putps() for that), and main.c has minor changes to work when there's no KW11
or switch register, really the only file with significant changes for the /03
is mch.s. It's the only one where the object code is model-dependent; all the
other changed ones use the same object code for all CPU models.

I'll put up a Web page with details, links to sources, etc, 'soon'.


A couple of other things.

Mini-Unix has removed 'raw' devices (not sure why, probably seemed un-needed),
so other disk drivers (e.g. the RL11 driver) aren't straight drop-ins. Minimal
tweaks needed, though; just remove the read and write routines, I think.

If there was a real use for 'raw' devices, they could probably be added back,
but physio() would have to be modified (simplified). Not sure if anything else
special would be needed; the process can't be swapped while raw I/O is
ongoing, and so on Mini-Unix no other process could run. Probably OK, but
needs to be checked.

I recommend that everyone trying to run Mini-Unix on a hardware /03 invest in
a KEF11 chip. (There are a few on eBait.) That way, you can leave the EIS
emulator out of the build, which will save some space, and allow more room for
device drivers. I added kernel printf() into the build, to help with
debugging, but it can be removed to save space.

You can change the system to use more room for the kernel (see the Mini-Unix
docs), but that involves re-linking _every single user command_, including the
shell and init. Not recommended.

      Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-10 23:29 [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Noel Chiappa
@ 2020-10-11  2:30 ` Jay Logue
  2020-10-11 23:24 ` Paul Riley
  1 sibling, 0 replies; 72+ messages in thread
From: Jay Logue @ 2020-10-11  2:30 UTC (permalink / raw)
  To: tuhs

On 10/10/2020 4:29 PM, Noel Chiappa wrote:

Great work, Noel!

 > The latest, greatest mch.s is uploaded:

Are your other changes available anywhere?  Also, I was wondering if it 
might be useful to have a github repo with these changes.  I'd be happy 
to help set this up.

--Jay


^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-10 23:29 [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Noel Chiappa
  2020-10-11  2:30 ` Jay Logue
@ 2020-10-11 23:24 ` Paul Riley
  2020-10-12  0:53   ` Dave Horsfall
  1 sibling, 1 reply; 72+ messages in thread
From: Paul Riley @ 2020-10-11 23:24 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 3185 bytes --]

Noel,




*Mini-Unix has removed 'raw' devices (not sure why, probably seemed
un-needed),so other disk drivers (e.g. the RL11 driver) aren't straight
drop-ins. Minimaltweaks needed, though; just remove the read and write
routines, I think.*

Your great work to port Mini-Unix will create some demand for device
drivers on the /03 systems, so may be worthwhile to implement RAW device.

Paul


*Paul Riley*

Mo: +86 186 8227 8332
Email: paul@rileyriot.com



On Sun, 11 Oct 2020 at 07:31, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

>     > I noticed a place where I used R0 as a temp ... and was being bashed.
>     > So I fixed it, and now the shell starts OK, but attempting to do any
>     > command (e.g. "echo foo"), things hang
>
> Well, I had 'fixed' it; it turned out my 'fix' had a bug. :-( (The code I
> had
> to change for the /03 there was pushing the old PS, and that and the temp I
> had to push got intermangled.)
>
> Anyway, with that fixed, the /03 Mini-Unix works now. The old user command
> binaries seem to work OK on the /03; not that I've tried the all, but the
> ones
> I have tried (including the C compiler) all worked. They all should all
> work
> (there's nothing in user code that's model-dependent). I have tweaked the
> shell (to allow 'cd') and init (to get rid of the annoying long rights
> message), but that's all.
>
> The latest, greatest mch.s is uploaded:
>
>   http://ana-3.lcs.mit.edu/~jnc/tech/unix/Mini/mch.s
>
> Although a couple of files (bio.c, clock.c, slp.c, and tty.c) had minor
> changes (to remove direct rerferences to the PS; they now call getps() and
> putps() for that), and main.c has minor changes to work when there's no
> KW11
> or switch register, really the only file with significant changes for the
> /03
> is mch.s. It's the only one where the object code is model-dependent; all
> the
> other changed ones use the same object code for all CPU models.
>
> I'll put up a Web page with details, links to sources, etc, 'soon'.
>
>
> A couple of other things.
>
> Mini-Unix has removed 'raw' devices (not sure why, probably seemed
> un-needed),
> so other disk drivers (e.g. the RL11 driver) aren't straight drop-ins.
> Minimal
> tweaks needed, though; just remove the read and write routines, I think.
>
> If there was a real use for 'raw' devices, they could probably be added
> back,
> but physio() would have to be modified (simplified). Not sure if anything
> else
> special would be needed; the process can't be swapped while raw I/O is
> ongoing, and so on Mini-Unix no other process could run. Probably OK, but
> needs to be checked.
>
> I recommend that everyone trying to run Mini-Unix on a hardware /03 invest
> in
> a KEF11 chip. (There are a few on eBait.) That way, you can leave the EIS
> emulator out of the build, which will save some space, and allow more room
> for
> device drivers. I added kernel printf() into the build, to help with
> debugging, but it can be removed to save space.
>
> You can change the system to use more room for the kernel (see the
> Mini-Unix
> docs), but that involves re-linking _every single user command_, including
> the
> shell and init. Not recommended.
>
>       Noel
>

[-- Attachment #2: Type: text/html, Size: 4357 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-11 23:24 ` Paul Riley
@ 2020-10-12  0:53   ` Dave Horsfall
  2020-10-12  1:56     ` Warner Losh
  2020-10-18 20:42     ` [TUHS] Fwd: " Michael Huff
  0 siblings, 2 replies; 72+ messages in thread
From: Dave Horsfall @ 2020-10-12  0:53 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On Mon, 12 Oct 2020, Paul Riley wrote:

> Mini-Unix has removed 'raw' devices (not sure why, probably seemed 
> un-needed),

If it's relevant FreeBSD hasn't had raw devices for ages (not needed?); I 
don't know about Penguin/OS because my Debian box is off the air right 
now (and my Ubuntu box's video is beyond repair).

-- Dave

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-12  0:53   ` Dave Horsfall
@ 2020-10-12  1:56     ` Warner Losh
  2020-10-12  2:09       ` Andrew Warkentin
  2020-10-12 16:57       ` Arthur Krewat
  2020-10-18 20:42     ` [TUHS] Fwd: " Michael Huff
  1 sibling, 2 replies; 72+ messages in thread
From: Warner Losh @ 2020-10-12  1:56 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 636 bytes --]

On Sun, Oct 11, 2020, 6:55 PM Dave Horsfall <dave@horsfall.org> wrote:

> On Mon, 12 Oct 2020, Paul Riley wrote:
>
> > Mini-Unix has removed 'raw' devices (not sure why, probably seemed
> > un-needed),
>
> If it's relevant FreeBSD hasn't had raw devices for ages (not needed?);


No longer needed. Phk removed the need for different types of devices for
disks as part of the geom work. It required, though, that unaligned I/O on
the block device worked...

I
> don't know about Penguin/OS because my Debian box is off the air right
> now (and my Ubuntu box's video is beyond repair).
>

Last I checked, linux still had both.

Warner

>

[-- Attachment #2: Type: text/html, Size: 1467 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-12  1:56     ` Warner Losh
@ 2020-10-12  2:09       ` Andrew Warkentin
  2020-10-12 16:57       ` Arthur Krewat
  1 sibling, 0 replies; 72+ messages in thread
From: Andrew Warkentin @ 2020-10-12  2:09 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

On 10/11/20, Warner Losh <imp@bsdimp.com> wrote:
>
> Last I checked, linux still had both.
>
I don't think I've ever seen a Linux distribution with separate raw
block device files.

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-12  1:56     ` Warner Losh
  2020-10-12  2:09       ` Andrew Warkentin
@ 2020-10-12 16:57       ` Arthur Krewat
  2020-10-12 17:46         ` [TUHS] FreeBSD disk devices (Re: " Bakul Shah
  1 sibling, 1 reply; 72+ messages in thread
From: Arthur Krewat @ 2020-10-12 16:57 UTC (permalink / raw)
  To: tuhs

On 10/11/2020 9:56 PM, Warner Losh wrote:
> unaligned I/O on the block device
Sorry, I have to laugh... isn't that an oxymoron? ;)

But then, I'm more of a BLKI/BLKO kinda guy (TOPS-10).

ak


^ permalink raw reply	[flat|nested] 72+ messages in thread

* [TUHS] FreeBSD disk devices (Re: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-12 16:57       ` Arthur Krewat
@ 2020-10-12 17:46         ` Bakul Shah
  2020-10-12 17:54           ` Warner Losh
  0 siblings, 1 reply; 72+ messages in thread
From: Bakul Shah @ 2020-10-12 17:46 UTC (permalink / raw)
  To: tuhs

On Oct 12, 2020, at 9:57 AM, Arthur Krewat <krewat@kilonet.net> wrote:
> 
> On 10/11/2020 9:56 PM, Warner Losh wrote:
>> unaligned I/O on the block device
> Sorry, I have to laugh... isn't that an oxymoron? ;)

Actually there are no *block* devices in FreeBSD.
And while raw device files such as /dev/r<blkdev>
no longer exist, it is the block devices (with
their buffering etc.) that are gone. Only raw devices
exist now.

And FreeBSD raw disk device drivers don't allow
unaligned I/O access. Nor should they paper over
what is not allowed by the underlying device. Try

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

unsigned char buf[1024];

int main(int c, char**v) {
        char* a = c > 1? v[1] : "1";
        off_t off = (off_t)strtoull(a, 0, 0);
        ssize_t r = pread(0, buf, sizeof buf, off);
        if (r < 0) { perror("read"); return 1; }
        for (int i = 0; i < 4; i++) printf(" %02x", buf[i]);
        printf("\n");
        return 0;
}


^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] FreeBSD disk devices (Re: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-12 17:46         ` [TUHS] FreeBSD disk devices (Re: " Bakul Shah
@ 2020-10-12 17:54           ` Warner Losh
  0 siblings, 0 replies; 72+ messages in thread
From: Warner Losh @ 2020-10-12 17:54 UTC (permalink / raw)
  To: Bakul Shah; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1592 bytes --]

On Mon, Oct 12, 2020 at 11:47 AM Bakul Shah <bakul@iitbombay.org> wrote:

> On Oct 12, 2020, at 9:57 AM, Arthur Krewat <krewat@kilonet.net> wrote:
> >
> > On 10/11/2020 9:56 PM, Warner Losh wrote:
> >> unaligned I/O on the block device
> > Sorry, I have to laugh... isn't that an oxymoron? ;)
>
> Actually there are no *block* devices in FreeBSD.
> And while raw device files such as /dev/r<blkdev>
> no longer exist, it is the block devices (with
> their buffering etc.) that are gone. Only raw devices
> exist now.
>

There's still the buffer cache that does do buffering on the devices... but
it's a different kind of buffering than traditional kernels.  but you're
right, only the cdevs are plumbed down, not the bdevs.


> And FreeBSD raw disk device drivers don't allow
> unaligned I/O access. Nor should they paper over
> what is not allowed by the underlying device. Try
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
>
> unsigned char buf[1024];
>
> int main(int c, char**v) {
>         char* a = c > 1? v[1] : "1";
>         off_t off = (off_t)strtoull(a, 0, 0);
>         ssize_t r = pread(0, buf, sizeof buf, off);
>         if (r < 0) { perror("read"); return 1; }
>         for (int i = 0; i < 4; i++) printf(" %02x", buf[i]);
>         printf("\n");
>         return 0;
> }
>

I meant something different about 'unaligned' access. I mean that the
buffers you read the data into needn't be page aligned. That causes a fair
amount of hair in the lower layers where I spend much of my time...

You are correct you have to read them on an LBA boundary.

Warner

[-- Attachment #2: Type: text/html, Size: 2440 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-12  0:53   ` Dave Horsfall
  2020-10-12  1:56     ` Warner Losh
@ 2020-10-18 20:42     ` Michael Huff
  1 sibling, 0 replies; 72+ messages in thread
From: Michael Huff @ 2020-10-18 20:42 UTC (permalink / raw)
  To: tuhs


On 10/11/2020 4:53 PM, Dave Horsfall wrote:
> On Mon, 12 Oct 2020, Paul Riley wrote:
>
>> Mini-Unix has removed 'raw' devices (not sure why, probably seemed 
>> un-needed),
>
> If it's relevant FreeBSD hasn't had raw devices for ages (not 
> needed?); I don't know about Penguin/OS because my Debian box is off 
> the air right now (and my Ubuntu box's video is beyond repair).
>
> -- Dave

I suspect it's really irrelevant, but NetBSD (as of version 9) still 
uses raw devices; at least for fsck (I have no idea about anywhere else).

I haven't tried; but it wouldn't surprise me to find that OpenBSD uses 
raw devices too.




^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2021-02-03  1:25 Noel Chiappa
  0 siblings, 0 replies; 72+ messages in thread
From: Noel Chiappa @ 2021-02-03  1:25 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Greg A. Woods

    > There's a "v6net" directory in this repository.
    > ...
    > I wonder if it is from either of the two ports you mention.

No; the NOSC system is an NCP system, not TCP; and this one has mbufs (which
the BBN v6 one did not have), so it's _probably_ a Berkleyism of some sort
(or did the BBN VAX code have mbuf's too; I don't recall - yes, it did:

  https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-Vax-TCP

see bbnnet/mbuf.c). It might also be totally new code which just chose to
re-use that meme. I don't have time to look closely to see if I see any
obvious descent.


    > Too many broken half-baked MUAs seem to still be widely used.

I'm one of the offendors! Hey, this is a vintage computing list, so what's
the problem with vintage mail readers? :-)

    Noel

PS: I'm just about done collecting up the MIT PWB1 TCP system; I only have
the Server FTP left to go. (Alas, it was a joint project between a student
and a staffer, who left just at the end, so half the source in one's personal
area, and the other half's in the other's. So I have to find all the pieces,
and put them in the system's source area.) Once that's done, I'll get it to
WKT to add to the repositoey. (Getting it to _actually run_ will take a
while, and will happen later: I have to write a device driver for it, the
code uses a rare, long-extinct board.)

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-24 11:02 Paul Ruizendaal
@ 2021-02-03  0:12 ` Greg A. Woods
  0 siblings, 0 replies; 72+ messages in thread
From: Greg A. Woods @ 2021-02-03  0:12 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

At Thu, 24 Sep 2020 13:02:53 +0200, Paul Ruizendaal <pnr@planet.nl> wrote:
Subject: Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
> 
> I’ve also done a port of the BBN VAX stack to V6 (running on a TI990 clone), using a serial
> PPP interface to connect. Experimental, but may have the OP's interest:
> https://www.jslite.net/cgi-bin/9995/dir?ci=tip

Ah ha!  Sorry, I should have read further in the thread before posting
about the "v6net" directory I found.

Unfortunately as with many threads on TUHS, this one is completely
broken and not easily put into proper tree form due to missing or
garbled 'in-reply-to' and 'references' headers.  Too many broken
half-baked MUAs seem to still be widely used.

-- 
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-22 15:59 Noel Chiappa
@ 2021-02-03  0:07 ` Greg A. Woods
  0 siblings, 0 replies; 72+ messages in thread
From: Greg A. Woods @ 2021-02-03  0:07 UTC (permalink / raw)
  To: The Unix Heritage Society mailing list

[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]

At Tue, 22 Sep 2020 11:59:43 -0400 (EDT), jnc@mercury.lcs.mit.edu (Noel Chiappa) wrote:
Subject: Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
>
> V6, as distributed, had no networking at all. There are two V6 systems with
> networking in TUHS:
>
>   https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC
>   https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6
>
> The first is an 'NCP' Unix (unless unless you have an ARPANet); the second is
> a fairly early TCP/IP from BBN (ditto, out of the box; although one could write
> an Ethernet driver for it).
>
> There's also a fairly nice Internet-capable V6 (well, PWB1, actually) from MIT
> which I keep meaning to upload; it includes SMTP, FTP, etc, etc. I also have
> visions of porting an ARP I wrote to it, and bringing up an Ethernet driver
> for the DEQNA/DELQA, but I've yet to get to any of that.

There's a "v6net" directory in this repository.

	https://www.sqliteconcepts.org/cgi-bin/9995/doc/tip/doc/index.wiki

I accidentally found it all when searching from something completely
different the other day.

I wonder if it is from either of the two ports you mention.

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2021-01-25  4:58   ` Gregg Levine
@ 2021-01-25  8:21     ` Tom Ivar Helbekkmo via TUHS
  0 siblings, 0 replies; 72+ messages in thread
From: Tom Ivar Helbekkmo via TUHS @ 2021-01-25  8:21 UTC (permalink / raw)
  To: Gregg Levine; +Cc: TUHS

Gregg Levine <gregg.drwho8@gmail.com> writes:

> But, ah, never did figure out how to bring up the user disks in the
> collection. When you have the time, can you provide me with some
> information on how you did all of that?

To mount additional disks, just attach them (in simh) and mount them (in
the OS).  Sort of like this (from memory, hopefully right):

$ pdp11
simh> set cpu 11/23+
simh> set rl0 rl02
simh> attach rl0 unix_v6.rl02
simh> deposit system sr 173030
simh> boot rl0
!unix
# STTY -LCASE
# ^E
simh> set rl1 rl02
simh> attach rl1 user01.rl02
simh> continue
# mount /dev/rl1 /mnt

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2021-01-24 16:07 ` Tom Ivar Helbekkmo via TUHS
@ 2021-01-25  4:58   ` Gregg Levine
  2021-01-25  8:21     ` Tom Ivar Helbekkmo via TUHS
  0 siblings, 1 reply; 72+ messages in thread
From: Gregg Levine @ 2021-01-25  4:58 UTC (permalink / raw)
  To: Tuhs

Hello!
You mention having gotten the Shoppe collection of images up on Simh.
Now I worked out how to bring up the boot disk that way without any
problem. But, ah, never did figure out how to bring up the user disks
in the collection. When you have the time, can you provide me with
some information on how you did all of that?
-----
Gregg C Levine gregg.drwho8@gmail.com
"This signature fought the Time Wars, time and again."

On Sun, Jan 24, 2021 at 11:17 AM Tom Ivar Helbekkmo via TUHS
<tuhs@minnie.tuhs.org> wrote:
>
> Noel Chiappa <jnc@mercury.lcs.mit.edu> writes:
>
> > V6 can be run on an -11/23 (I've done it), but not straight out of the box;
> > it requires a few minor tweaks first:
> >
> >   http://gunkies.org/wiki/Running_UNIX_V6_on_an_-11/23
>
> Noel,
>
> here's a huge THANK YOU! from me - I've had a couple of uPDP-11/23+
> systems stowed away for over twenty years, with an eye to one day
> porting V6 to them, and this comment from you finally made me pull out
> one of them and do it.  I now have V6 running on the physical hardware,
> booting from an RD52 on an RQDX3 MSCP controller, and announcing 488KW
> of available RAM at boot.
>
> Here's the write-up: https://www.hamartun.priv.no/v6unix.html
>
> I am *so* looking forward to continuing work on this system (it's just
> barely running, since a couple of days ago), and your web page about
> improving V6 will certainly be my launch pad for the next rounds.
>
> -tih
> --
> Most people who graduate with CS degrees don't understand the significance
> of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-19 15:28 Noel Chiappa
  2020-09-21 10:26 ` Paul Riley
@ 2021-01-24 16:07 ` Tom Ivar Helbekkmo via TUHS
  2021-01-25  4:58   ` Gregg Levine
  1 sibling, 1 reply; 72+ messages in thread
From: Tom Ivar Helbekkmo via TUHS @ 2021-01-24 16:07 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: TUHS

Noel Chiappa <jnc@mercury.lcs.mit.edu> writes:

> V6 can be run on an -11/23 (I've done it), but not straight out of the box;
> it requires a few minor tweaks first:
>
>   http://gunkies.org/wiki/Running_UNIX_V6_on_an_-11/23

Noel,

here's a huge THANK YOU! from me - I've had a couple of uPDP-11/23+
systems stowed away for over twenty years, with an eye to one day
porting V6 to them, and this comment from you finally made me pull out
one of them and do it.  I now have V6 running on the physical hardware,
booting from an RD52 on an RQDX3 MSCP controller, and announcing 488KW
of available RAM at boot.

Here's the write-up: https://www.hamartun.priv.no/v6unix.html

I am *so* looking forward to continuing work on this system (it's just
barely running, since a couple of days ago), and your web page about
improving V6 will certainly be my launch pad for the next rounds.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-10-18 21:36 Norman Wilson
  0 siblings, 0 replies; 72+ messages in thread
From: Norman Wilson @ 2020-10-18 21:36 UTC (permalink / raw)
  To: tuhs

Just for completeness: I have one OpenBSD 6.7 system at
home and look after several more at work, and yes, OpenBSD
still has raw disk devices.

Norman Wilson
Toronto ON

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-10-12 22:43 Noel Chiappa
  0 siblings, 0 replies; 72+ messages in thread
From: Noel Chiappa @ 2020-10-12 22:43 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Paul Riley

    > port Mini-Unix will create some demand for device drivers on the /03
    > systems, so may be worthwhile to implement RAW device.

I'm not sure I understand this ("worthwhile to implement RAW device"); let me
explain what the removal of 'raw' I/O devices from MINI-UNIX really means, and
then ask what it is that you are after.


Early Unix (no idea about later ones) supports two classes of devices; 'block'
devices, which can be used to hold file-systems, and 'character' devices,
which cannot. (I seem to recall a paper, perhaps from the Unix BSTJ issue,
which talks about them in some detail.)

The former are those where the underlying physical device has restricted
semantics; they are block-addressable mass storage devices. All access to them
is via the system's block buffer pool, so reads/writes by the user of
arbitrary size and location are possible. 'Character' devices are everything
else.

'Raw' devices are an interface to the devices of 'block' devices which does
not go through the system's buffer pool; I/O operations to them perform DMA
directly to the user process' memory. They are 'character' devices, in the
Unix device taxonomy. The only semantics available are those supported by the
hardware - e.g. seeks only to block boundaries.

So when I say that MINI-UNIX doesn't have 'raw' devices, it just means that
e.g. the RK disk controller device _only_ talks to the Unix block buffer
system; if a user program wants to look at the disk contents, it has to go
via that system.


So, with that in hand, what exactly is the need you forsee for raw devices
in MINI-UNIX?

Also, I've started to work on getting the V6 RL driver to work in MINI-UNIX;
it should have been easy (just delete the charater device interface), but
for some reason it didn't work when I tried it. I'll look at it in more
detail 'soon'.

       Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-10-12 19:27 Noel Chiappa
  0 siblings, 0 replies; 72+ messages in thread
From: Noel Chiappa @ 2020-10-12 19:27 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Jay Logue

    > Are your other changes available anywhere?

Yeah, they're all up-loaded, and linked to from my 'Running MINI-UNIX on the
LSI-11' page:

  http://ana-3.lcs.mit.edu/~jnc/tech/unix/Mini/Mini.html

It's mostly done, but I'll probably continue to tweak it a bir.

If anyone notices any errors, or has questions that aren't answered there, etc
please let me know.


    > Also, I was wondering if it might be useful to have a github repo with
    > these changes. I'd be happy to help set this up.

Feel free to go for it, if people think it would be useful. (I'm not sure
there is a 'basic' MINI-UNIX repo to start on.)

      Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-10-08 23:49 Noel Chiappa
  0 siblings, 0 replies; 72+ messages in thread
From: Noel Chiappa @ 2020-10-08 23:49 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Paul Riley

    > Always darkest before the dawn.

Well, we'll see.


I found _that_ one; process 1 managed to exec() init, do a fork(), and then
the child process exec()'d the shell - then that apparently died, and the code
in init falls through into:

	termall();
	execl(init, minus, 0);

when the single-user shell exits, so then init restarted; rinse, repeat.

So a _lot_ of the code in mch.s seemed to be working correctly; system calls
(2 exec()'s, and a fork()) worked, processing switching worked, device
interrupts (for the disk and console tty) seemed to be working.. Not sure
what's left!

So I looked at mch.s again, to see what else _was_ there, and I noticed a
place where I used R0 as a temp - with the MFPS/MTPS thing to get to the PS,
instructions like:

      BIS	#340, PS

need to change to:

     MFPS	R0
     BIS	#340, R0
     MTPS	R0

and R0 was being used to hold an arg (in pword:), and was being bashed.


So I fixed it, and now the shell starts OK, but attempting to do any command
(e.g. "echo foo"), things hang (the shell doesn't fork). If I type the
interrupt character, the shell exits, and init restarts.

Oh well, hopefully this one won't be too painful to work out. The system's
mostly working, which I think will really help.

     Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-10-08 16:06 Noel Chiappa
  0 siblings, 0 replies; 72+ messages in thread
From: Noel Chiappa @ 2020-10-08 16:06 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > Now to see if 'cc' works on an '-11/40'

Yeah, the C compiler works fine on a /40; so the SOB bug (or perhaps some
_other_ one I haven't found yet) must have affected it too.

The thing that's odd about that bug is that SOB works _sometimes_ on an /05;
the 'rkmx' on the distro tape will boot (which if the SOB _never_ worked, it
wouldn't). So there must be a data dependency somehow.  John Wilson says the
SOB is very optimized, so maybe there's a bug.


    > then back to the /03.

Well, I tried /03 version, and it doesn't work; /etc/init continually
restarts.

The thing is that _every_ file except mch.s is identical between the '05'
version (which runs fine on the /40; above), and the /03 version.  So the bug
must be in mch.s - unless there's somehow an /03 dependency somewhere else I
missed. I looked through init.c, didn't see anything.

Here:

  http://ana-3.lcs.mit.edu/~jnc/tech/unix/Mini/mch.s

is the mch.s source, if anyone wants to look through it and see if they see
anything. It's conditionalized for the /03; there's a very simple header file
(here:

  http://ana-3.lcs.mit.edu/~jnc/tech/unix/Mini/03mch.s

for the 03 version) to set the flags (so one doesn't have to edit the main file
to change the flag settings).

I had a careful look at mch.s, before I started, checking all the added
conditionalized code; found one that could have been an issue (I was using a
temporary register, r0, that had needed data in it), but the rest all looked
OK. I have some ideas on how to proceed on working out what's going on, but
I'm done for today, gotta do other stuff.

    Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-06 23:08 Noel Chiappa
@ 2020-10-07  5:24 ` Jay Logue
  0 siblings, 0 replies; 72+ messages in thread
From: Jay Logue @ 2020-10-07  5:24 UTC (permalink / raw)
  To: tuhs

On 10/6/2020 4:08 PM, Noel Chiappa wrote:

 > However, when set to an -11/05, Ersatz-11 treats SOBs as NOPs; they 
fall through without any effect. Without a trap, they can't be emulated 
either.

Well that was an unfortunate bit of luck--a bug in the emulator!

All this appears to be working fine under simh.  I was able to do full 
install of Mini-Unix and rebuild the kernel from source while running an 
emulated 11/05.

--Jay

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-10-06 23:08 Noel Chiappa
  2020-10-07  5:24 ` Jay Logue
  0 siblings, 1 reply; 72+ messages in thread
From: Noel Chiappa @ 2020-10-06 23:08 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > I suspect there must be an issue with the -11/05 emulation in Ersatz-11

There is. The C compiler on MiniUnix emits SOB instructions. The -11/05 doesn't
implement SOB; however, the instruction emulator in MiniUnix (emul.s) is
prepared to emulate it. (So MiniUnix should work fine on real -11/05's.)

However, when set to an -11/05, Ersatz-11 treats SOBs as NOPs; they fall
through without any effect. Without a trap, they can't be emulated either.

This caused the problem with namei() failing (namei() calls bcopy(), which has
a SOB in it), and probably caused the problem I was seeing with the C
compiler, but I'm too burned out to check right now. Tomorrow.

    Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-10-06 20:34 Noel Chiappa
  0 siblings, 0 replies; 72+ messages in thread
From: Noel Chiappa @ 2020-10-06 20:34 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > I just realized that the _first_ entry, #'9', is actually #0 _in the
    > directory_; u_count counts _down_, whereas the code looks through dir
    > entries going _up_.

Fixed that (kept my own index of which entry it was working on, and
caculated the name location in the buffer, and got:

  chk 0 15 2 '..'
  chk 1 14 18 '.'
  chk 2 13 34 'bin'
  chk 3 12 50 'dev'
  chk 4 11 66 'etc'

etc... and it blew right past the 'etc' entry, to the end of the
directory. WTF?

    > Still don't understand why I can't print the dir entries out of the u
    > area, though.

Now that my brain has turned on, I'll bet that's not _my_ bug, I'll bet it's
_the_ bug! If the directory entry in u.u_dent.u_name is all 0's, _of course_
the match is going to fail.


Just for grins, I set the CPU type in Ersatz-11 to "40 EIS NOMMU" and... it
booted up fine! I suspect there must be an issue with the -11/05 emulation in
Ersatz-11, since MiniUnix worked fine on _real_ -11/05's.

Now to see if 'cc' works on an '-11/40' - then back to the /03.

    Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-10-06 19:34 Noel Chiappa
  0 siblings, 0 replies; 72+ messages in thread
From: Noel Chiappa @ 2020-10-06 19:34 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > it looks at the following entries:
    > Anyway, after printing the entry for 5, it goes to 'done'

Uh, I just realized that the _first_ entry, #'9', is actually #0 _in the
directory_; u_count counts _down_, whereas the code looks through dir entries
going _up_.

Still don't understand why I can't print the dir entries out of the u area,
though.

Noel


^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-10-06 19:04 Noel Chiappa
  0 siblings, 0 replies; 72+ messages in thread
From: Noel Chiappa @ 2020-10-06 19:04 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: jay-tuhs9915

    > Are there any notes you can share on how to get to the point you're at?

Well, there are three areas where the /03 version needs work, over the /05:

- No LTC clock register
- No switch register
- PS access only via MFPS/MTPS instructions

For the first two, the needed changes are identical to the ones detailed here:

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

These have all been tested on the /23. Rather than anyone make the exact same
changes independently, I can put up the modified versions of the MiniUnix
files for them (low.s, main.c and param.h).

For the third, I have an mch.s with a conditional assembly flag that _should_
do it all; like I said, there are also really minor edits to bio.c, clock.c,
slp.c, and tty.c. Again, I can upload the mch.s which is already done.

I haven't been able to _confirm_ that these work, but it should be mostly good;
the changes are pretty straight-foward.


    > The code is doing a string comparison between the name in the current
    > directory entry (u_dent) and the current pathname component (in
    > u_dbuf). The expression in brackets is the relative distance between the
    > two name fields within the u struct.

Yeah, I'd worked that out (the immediately preceding comment in the code -
"String compare the directory entry and the current component" - indicates
what it's doing, and as my "the term inside the []'s seems to be an offset
.. into the copy of the current directory entry" indicates, I'd worked out how
it did that. I was still puzzled by some othet aspects of the code, I just
included that to give a flavour of the code.

    > In what way does it fail? Is it simply that namei() doesn't find the
    > file its looking for?

Right. It's looking for 'etc' in the root directory (only one block), and
it looks at the following entries:

  9 146 '05mx'
  8 130 'usr'
  7 114 'tmp'
  6 98 'mnt'
  5 82 'lib'

(I put a printf() in the loop; I've added prf.c to the load so I can do
that. The numbers are the index, u.u_count - although it's already been
descremented at that point, so it will be '0' when doing the last entry - and
location of that entry in the directory, given next to it. For some reason, I
can't get the entry to print from u.u_dent.u_name, so I'm printing it straight
from the block buffer, bp->b_addr[]. I can print the _inode number_,
u.u_dent.u_ino as a string, but not the dir entry. Wierd.)

Anyway, after printing the entry for 5, it goes to 'done', with u_error
containing '2'. I can't see how it could do that.

I'm using printf() because I'm too lazy to figure out how to build a kernel
with a debugger like DDT included. (We never did that when we were working
on V6 at MIT BITD; ISR we mostly just used printf() back then, too.)

   Noel


^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-06 14:46 Noel Chiappa
@ 2020-10-06 16:22 ` jay-tuhs9915
  0 siblings, 0 replies; 72+ messages in thread
From: jay-tuhs9915 @ 2020-10-06 16:22 UTC (permalink / raw)
  To: tuhs

On 10/6/2020 7:46 AM, Noel Chiappa wrote:

 > I'm not a SIMH user, though (I'm an Ersatz-11 person); is there 
anyone who is, who'd like to play with MiniUnix with me?

I've been meaning to jump into this, since I own both an 11/05 and an 
11/03, which I'd very much like to run Unix on.  I've also used simh for 
various things (including bringing up 2.9BSD on my 11/23), but I can 
hardly call myself an expert.

Are there any notes you can share on how to get to the point you're at?

 >    for(cp = &u.u_dbuf[0]; cp < &u.u_dbuf[DIRSIZ]; cp++)
 >        if(*cp != cp[u.u_dent.u_name - u.u_dbuf])

Found this in the v6 sources 
(http://www.retro11.de/ouxr/u6ed/usr/sys/ken/nami.c.html).  The code is 
doing a string comparison between the name in the current directory 
entry (u_dent) and the current pathname component (in u_dbuf).   The 
expression in brackets is the relative distance between the two name 
fields within the u struct.  If the if expression evaluates to true, 
then the names do *not* match, and the code loops back to eloop to check 
the next entry.

Since namei() searches for a particular named entry in a directory, its 
reasonable to assume that this particular comparison would fail a number 
of times before finding the correct entry.

 > It seems to check most of the (wrong) directory entries OK, but then 
inexplicably (to me) fails.

In what way does it fail?  Is it simply that namei() doesn't find the 
file its looking for?

--Jay


^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-10-06 14:46 Noel Chiappa
  2020-10-06 16:22 ` jay-tuhs9915
  0 siblings, 1 reply; 72+ messages in thread
From: Noel Chiappa @ 2020-10-06 14:46 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    >> Then on to trying to find out why MiniUnix crashes whenever I try and do
    >> anything significant.

    > I decided I wasn't up to tackling that, so instead I did all the edits
    > to produce an LSI-11 version of MX. ... I need to go
    > back and put conditional assembly flags in mch.s so there's only one
    > source file for both kinds of system. Doesn't boot, though.

So this has turned into a big swamp.

I went back and did the conditionals, and I can turn off the -11/03 flag and
produce the identical binary to the original mch.o file. -11/05 systems built
with that still won't boot, though!

So I had made some minor changes elsewhere in the system; e.g. a few files
(bio.c, clock.c, slp.c, and tty.c) refer the the PS explicitly (a no-no in the
-11/03) so I changed them all to call getps() and putps(), and added /05
versions of those to mch.s; so I backed them out, and re-built the system
using the original binaries of those; _still_ won't boot.

I then tried the original 'rkmx', and that _does_ boot; so there's no
mysterious damage to the file system. But now I'm deeply puzzled, since the
new system (which won't boot) should be basically identical (OK, not
bit-for-bit identical, but close).


So then I started trying to see why the new /05 system won't boot; the exec()
call in process 1 that starts /etc/init seems to be failing. Digging into
that, the call to namei() (in sys1$exec()) seems to be failing? Huh? The
file-system is OK (see above)?

So I'm trying to work out how that is happening. Which is non-trivial;
namei() is pretty convoluted. I can deal with the fact that there are two
nested loops using goto's (not the best form, but I can grok it), but then I
run into things like this:

     for(cp = &u.u_dbuf[0]; cp < &u.u_dbuf[DIRSIZ]; cp++)
	 if(*cp != cp[u.u_dent.u_name - u.u_dbuf])

Check out that second line! (And Heinz didn't touch it; this copy is from the
V6 source.) I'm not sure I 100% grok it, but I think I get roughly what it's
doing: 'cp' seems to be a (moving) pointer into the filename being matched,
and the term inside the []'s seems to be an offset from there into the copy of
the current directory entry in the 'u' structure. (Which is a constant, it
doesn't need to be recomputed each time around the loop, though.) It seems to
check most of the (wrong) directory entries OK, but then inexplicably (to me)
fails.


At this point I'm getting a bad feeling that there could be a sim issue; that
could also explain the problem I'm seeing with the crashes, when trying to run
'cc' under the as-distributed -11/05 version.`

I'm not a SIMH user, though (I'm an Ersatz-11 person); is there anyone who is,
who'd like to play with MiniUnix with me?

	Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-10-02  0:39 Noel Chiappa
  0 siblings, 0 replies; 72+ messages in thread
From: Noel Chiappa @ 2020-10-02  0:39 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > At some point, I'll produce a 'MiniUnix ld' on vanilla V6, so I can
    > build MiniUnix versions of applications there; the first will be the
    > shell, so I don't have to keep typing 'chdir' instead of 'cd'! :-)

OK, that was pretty smooth. I now have (on the main V6 system) a linker in
V6 binary form that outputs MX binary files, so I can do things like:

  mld sh.o /mnt/lib/lib[ca].a

to produce a new shell (which worked fine). (I think to build 'mld' all I
had to do was 'cc ld.c', in usr/sys/source on the MX disk.)

This whole 'futz with MX by mounting the MX disk under V6' thing works really
well.


    > Then on to trying to find out why MiniUnix crashes whenever I try and do
    > anything significant.

I decided I wasn't up to tackling that, so instead I did all the edits to
produce an LSI-11 version of MX. Doesn't boot, though; tries to do a panic, I
think. I'm too burned out to keep going, I will continue tomorrow morning (US
East Coast time).

Once I get it running, before I make it available for download, I need to go
back and put conditional assembly flags in mch.s so there's only one source
file for both kinds of system; I had originally planned on doing that, but I
was in such a 'code attack' mode I forgot all about it.

    Noel


^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-10-01 12:51 Noel Chiappa
@ 2020-10-02  0:23 ` Paul Riley
  0 siblings, 0 replies; 72+ messages in thread
From: Paul Riley @ 2020-10-02  0:23 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 2399 bytes --]

Seems like you're firmly in the footsteps of the creators now... :-)

*Paul Riley*

Mo: +86 186 8227 8332
Email: paul@rileyriot.com



On Thu, 1 Oct 2020 at 20:52, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

>     > From: Paul Riley
>
>     > So mounting Mini-Unix on a running V6 system I guess allows you to
> run
>     > Mini-Unix user mode binaries stuff
>
> Ah, no. They are all link-loaded to run at TOPSYS (060000), so won't run on
> V6 native.
>
>     > Or do you plan to recompile on a stable system?
>
> Well, I need to find out what the problem is, first.
>
>
> Still, notable progress: using my 'mount the Mini-Unix RK pack on a V6
> system'
> hack (which woked fine; the native V6 'icheck' and 'dcheck' work on that
> pack), I was able to sucessfully compile a few tweaked system modules (to
> get
> my usual line-editing chars, and turn off that irritating lower-case mode),
> and then build an OS load which could sucessfully boot. So good progress
> there. A couple of things I learned:
>
> - MiniUnix tools use the 'new' archive format, so the V6 vanilla 'ar'
> doen't
> grok MiniUnix archives (e.g. lib1/lib2). I have a 'nar', which I found on
> the
> 'Shoppa disks', which can deal with them. (We don't have source for it, but
> I'll bet the MIT PWB1 system has that; I'll get to that eventuallly.
> There's also
> an 'ar.c' on the MiniUnix disk; between the two, we'll be able to
> reconstitute
> source for 'nar'.)
>
> - Also, the vanilla V6 linker, 'ld', _also_ doesn't understand new
> archives;
> so the shell file to build a new system, 'shld':
>
>   ld -a -x low.o conf.o lib1 lib2
>
> blows out because it doesn't grok the libraries. Also, the '-a' flag, which
> says 'link starting at 0, not TOPSYS', doesn't exist in the V6 'ld'.
>
> I got around all that by unpacking lib1 (using 'nar', above) - it only
> contains
> two files - and then listing the files to link directly:
>
>   ld -x low.o conf.o syso emulo dev/kl.o dev/devstart.o dev/rk.o
>
> The vanilla V6 linker of course produces an output linked at 0 without
> the -a flag.
>
>
> At some point, I'll produce a 'MiniUnix ld' on vanilla V6, so I can build
> MiniUnix versions of applications there; the first will be the shell, so I
> don't have to keep typing 'chdir' instead of 'cd'! :-)
>
> Then on to trying to find out why MiniUnix crashes whenever I try and do
> anything significant.
>
>        Noel
>

[-- Attachment #2: Type: text/html, Size: 3476 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-10-01 12:51 Noel Chiappa
  2020-10-02  0:23 ` Paul Riley
  0 siblings, 1 reply; 72+ messages in thread
From: Noel Chiappa @ 2020-10-01 12:51 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Paul Riley

    > So mounting Mini-Unix on a running V6 system I guess allows you to run
    > Mini-Unix user mode binaries stuff

Ah, no. They are all link-loaded to run at TOPSYS (060000), so won't run on
V6 native. 

    > Or do you plan to recompile on a stable system?

Well, I need to find out what the problem is, first.


Still, notable progress: using my 'mount the Mini-Unix RK pack on a V6 system'
hack (which woked fine; the native V6 'icheck' and 'dcheck' work on that
pack), I was able to sucessfully compile a few tweaked system modules (to get
my usual line-editing chars, and turn off that irritating lower-case mode),
and then build an OS load which could sucessfully boot. So good progress
there. A couple of things I learned:

- MiniUnix tools use the 'new' archive format, so the V6 vanilla 'ar' doen't
grok MiniUnix archives (e.g. lib1/lib2). I have a 'nar', which I found on the
'Shoppa disks', which can deal with them. (We don't have source for it, but
I'll bet the MIT PWB1 system has that; I'll get to that eventuallly. There's also
an 'ar.c' on the MiniUnix disk; between the two, we'll be able to reconstitute
source for 'nar'.)

- Also, the vanilla V6 linker, 'ld', _also_ doesn't understand new archives;
so the shell file to build a new system, 'shld':

  ld -a -x low.o conf.o lib1 lib2

blows out because it doesn't grok the libraries. Also, the '-a' flag, which
says 'link starting at 0, not TOPSYS', doesn't exist in the V6 'ld'.

I got around all that by unpacking lib1 (using 'nar', above) - it only contains
two files - and then listing the files to link directly:

  ld -x low.o conf.o syso emulo dev/kl.o dev/devstart.o dev/rk.o

The vanilla V6 linker of course produces an output linked at 0 without
the -a flag.


At some point, I'll produce a 'MiniUnix ld' on vanilla V6, so I can build
MiniUnix versions of applications there; the first will be the shell, so I
don't have to keep typing 'chdir' instead of 'cd'! :-)

Then on to trying to find out why MiniUnix crashes whenever I try and do
anything significant.

       Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-30 23:16 Noel Chiappa
  0 siblings, 0 replies; 72+ messages in thread
From: Noel Chiappa @ 2020-09-30 23:16 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > I think before I try debugging it directly, I'll try one of the other
    > Mini-Unix repositories; the one I've been using (from Bob Eager's site)
    > may have some bit-rot.

Well, foo, the one from TUHS has the same symptom: random re-starts. Looks
like I'm going to have to actually debug this.

I guess the first step is to work out how the re-start is happening; I suspect
it's not a trap (I'll check, but I think Mini-Unix catches them all). My best
guess is a jump to 0 (somehow); if so, that should be easy to catch. Then the
next thing is to try and work out where/how/why that is happening.

Following a suggestion of Warner Losh, I think there's a good idea on how to
make progress, which is to mount the Mini-unix pack under V6 (running on a
simulator); that's rock-solid - and the V6 tool-chain can be used to build
Mini-Unix binaries.

And here I thought it was going to be easy to convert Mini-unix to run on
an -11/03. Well, it still might - if I can get Mini-Unix to run reliably!

   Noel


^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-30 18:51 Noel Chiappa
  0 siblings, 0 replies; 72+ messages in thread
From: Noel Chiappa @ 2020-09-30 18:51 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > It is definite, though, that Q22 memory won't work with an LSI-11/2
    > (M7270) ...  I'll try an LSI-11 (M7264) tomorrow, make sure it's the
    > same; it and the LSI-11/2 are similar enough that it should, but it'd be
    > good to confirm it.

Yes, it too won't work with Q22 memory (tried it, no go - ODT won't even start).


    > Then back to trying to work out why Mini-Unix is so fragile for me.

I tried some changes in the simulator set-up, to see if that would fix my
issue; no luck.

It's quite problematic: if I boot Mini-Unix on a clean copy of the RK pack, cd
to /usr/sys/dev, cp kl.c to nkl.c, and 'cc -c nlk.c', Mini-Unix reliably
restarts (trashing the disk in the process). (If I omit the 'cp', I can 'cc -c
kl.c' 3 times, and Mini-Unix restarts on the third.) Something's seriously
wrong.

I think before I try debugging it directly, I'll try one of the other
Mini-Unix repositories; the one I've been using (from Bob Eager's site) may
have some bit-rot.


    > From: Paul Riley <paul@rileyriot.com>

    > I'm checking with Peter Schranz about whether or not his RLV12/RL02
    > boards can run on the '03.

Dave Bridgham and I discussed whether the QSIC would work with an -11/03, and
that analysis should apply equally to the RLV12. Our conclusion was that it
should; here's our reasoning:

The device registers on the board should work fine on either Q18 or
Q22. That's because when going to the I/O page, the CPU asserts a special bus
line, BBS7 (that says 'this cycle is to the I/O page'). The device doesn't
look at the higher address lines when that's on, just BDAL00-12; so if the
LSI-11 is messing with some of BDAL181-21, it shouldn't matter.

For DMA cycles from the device to memory, since the CPU requires Q18 memory
to work, the device too should be able to read/write to Q18 memory. At least,
that's our theory.


I guess all this PDP-11 hardware detail isn't really on-topic for this list; I
should move it to Classic Computers, or something. Sorry all; it's
intermingled with early Unix stuff, and it was easier to keep it all in one
place.

	Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-30 17:58 Noel Chiappa
  0 siblings, 0 replies; 72+ messages in thread
From: Noel Chiappa @ 2020-09-30 17:58 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Paul Riley

    > Can you clarify something for me regarding memory? I understand the
    > bottom area of memory in a Unix system is for the Kernel and it's stuff,
    > and that the top 8kB is set aside for device I/O

Well, technically, the top 8KB of _address space_, not of memory - it's mostly
used for device registers, etc. Here:

  http://gunkies.org/wiki/Unix_V6_kernel_memory_layout

is a bit more detail on how the memory is laid out.

    > The LSI-11 board has 4kW of RAM on it, and I have already a 16KW
    > board. If I want to further expand the RAM, and say I buy another 16kW
    > board, that makes an arithmetic sum of 32kW for the boards, making 36kW
    > total. Can the 4kW of on-board RAM be disabled, and only the 32kW on
    > the boards be used?

Yeah, if you look at LSI-11 documentation, there are jumpers that allow
configuration of the on-board memory. Depending on the etch revision; for my F
revision, jumper W11 (at the top, towards the handle edge, in the middle of
that edge; just below the W1/W2 jumper pair) should be out to disable the
on-board memory.

Or you could configure the two 32KB boards to be at 020000 and 0120000; there
will be 72KB of memory total on the QBUS, but the LSI-11 CPU (no memory
management) will only be able to 'see' the bottom 56KB.


    > Is it ok for the installed RA mto overlap the 8kW at the high memory
    > area?

Yeah, what the CPU sees as the I/O page (at 0160000-0177776 in its address
space) is actually at 0760000-0777776 on the QBUS (on a Q18 QBUS); the CPU
automagically translates the 0160000-0177776 addresses up. On a PDP-11
with memory management, the MMU has to be set up to do that. E.g. in V6,
in:

  https://minnie.tuhs.org//cgi-bin/utree.pl?file=V6/usr/sys/conf/m40.s

there is the following code:

  / initialize io segment

  mov $IO,(r0)+
  mov $77406,(r1)+		/ rw 4k

to set the I/O page in kernel address space to point to the I/O page on the
bus.

	Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-28 23:21 Noel Chiappa
@ 2020-09-30  1:50 ` Paul Riley
  0 siblings, 0 replies; 72+ messages in thread
From: Paul Riley @ 2020-09-30  1:50 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]

Noel,

Some more info on my machines...










*The
DLV11-J:  http://gunkies.org/wiki/DLV11-J_asynchronous_serial_line_interface
<http://gunkies.org/wiki/DLV11-J_asynchronous_serial_line_interface>is
basically 4 DLV11's rolled into a single dual-width card; that's
definitelyan option for Mini-Unix (which apparently supports up to 4
simultaneoususers). They are program compatible with the DHV11, so the
driver should 'justwork'. The boards are readily available on eBait;
'glitchworks' (of thisparish) sells replacement cables (quite good, I have
several).*
I bought a DLV-11J on eBay so that's a starter for my /03 machine. I've
also bought an MSV11-DE 32kW memory board. Peter Schranz has confirmed a
modification to his RLV12/RL02 emulator to allow it to run on the /03. I'm
all set for Mini-Unix on the /03 then!

Regarding the KDF11-B:



*If yours doesn't have the MMU chip, you're probably SOL; those are very
rare.KEF11-A FPU chips are avilable on eBay for modest amounts.  *

Looks like I'm in luck! My /23+ CPU board does have the MMU installed. I
also bought a KEF11-A separately. Glad my wife doesn't know about all these
purchases. ;)

Paul
*Paul Riley*

Mo: +86 186 8227 8332
Email: paul@rileyriot.com



On Tue, 29 Sep 2020 at 07:23, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

>     > From: Pete Turnbull
>
>     > The SRUNL signal that was mentioned isn't likely to cause a problem
>
> That was just a guess on my part as to the exact cause. It is definite,
> though, that Q22 memory won't work with an LSI-11/2 (M7270); I just tried
> it.
> I didn't touch any of the other boards; just swapped the LSI-11/2 for a
> KDF11-A (M8186), everything worked fine; put the LSI-11/2 back, dead again.
>
> I'll try an LSI-11 (M7264) tomorrow, make sure it's the same; it and the
> LSI-11/2 are similar enough that it should, but it'd be good to confirm it.
>
>
> Then back to trying to work out why Mini-Unix is so fragile for me. Has
> anyone else ever worked with Mini-Unix, and if so, any tips?
>
>        Noel
>

[-- Attachment #2: Type: text/html, Size: 5514 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-27 20:50 Noel Chiappa
@ 2020-09-29 13:20 ` Paul Riley
  0 siblings, 0 replies; 72+ messages in thread
From: Paul Riley @ 2020-09-29 13:20 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 2877 bytes --]

Noel,

Regarding the boards, the non-DEC one is the 16kW board I bought installed
in the '03, so I guess that works fine.

I managed to follow instructions for SimH and install and configure a V6
system. Was quite satisfying, and was quite an education. So many lessons
in one session, a really good exercise.

I'm checking with Peter Schranz about whether or not his RLV12/RL02 boards
can run on the '03. May be a similar issue with knobbling some of the pins,
if I'm lucky.

*Paul Riley*

Mo: +86 186 8227 8332
Email: paul@rileyriot.com



On Mon, 28 Sep 2020 at 04:51, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

>     > From: Paul Riley
>
>     > I also have a DEC 256KB board, but I doubt I could use it on the
>     > '03.
>
> Yes, DEC 256KB boards are what's called Q22, and those don't seem to work
> with
> LSI-11's; not even CPU ODT works. I just tried a 256KB MSV11-L with an
> LSI-11,
> and it definitely doesn't work; the MSV11-P is definitely a Q22 board, and
> so
> probably also won't work.
>
> What the Q22 means is that early in the lifetime of the QBUS, it only had
> 18
> address line - so-called Q18. (Technially the LII-11 used only 16 address
> lines,
> so it's actually Q16.) DEC latter snarfed some of the 'unused' pins, and
> made them QDAL18-21. So boards that use those pins for QDAL18-21 are 'Q22'
> boards.
>
> My theory on what the problem is is that the LSI-11 uses some of those pins
> for other things - I think the 'run' light, IIRC. So that confuses Q22
> memory.
> If one tries to use one with an LSI-11, the machine is totally dead - not
> even
> ODT. It doesn't do any harm, though; unplug the Q22 memory, and plug in a
> Q18
> card like an MSV11-D, and it'll be fine.
>
> If you need memory for the LSI-11, MSV11-D boards are pretty common on
> eBait,
> for not much. They tend to be flaky, though; sometimes they come back to
> life
> if you leave them sit for a bit after you plug them in.
>
>   > I believe the [memory] board is non-DEC.
>
> Well, if it's Q22 it won't work either. Both that and the DEC board should
> work in the /23, though. (If you have the part number on the memory chips,
> a
> little arithmetic should give you the board size. 256K and up are
> generallly
> Q22; if you have a manual for that card it might say.)
>
>
> I'm still working with Mini-Unix; it's very fragile. When I got it running,
> the first thing I tried to do was changle the line editing characters
> (since
> my normal ones are burned into ROM). Alas, in stock V6, DEL is hard-wired
> to
> be 'interrupt process', so I can't just 'stty [mumble]', I have to rebuild
> the
> kernel to change that. Not a problem, necessarily - but I edited tty.h and
> said 'cc -c tty.c', and it crashed and re-started - and roached the disk.
> So
> I'm still trying to make progress. I might have mis-configured the
> simulator,
> I'll see.
>
>      Noel
>

[-- Attachment #2: Type: text/html, Size: 3898 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-28 23:21 Noel Chiappa
  2020-09-30  1:50 ` Paul Riley
  0 siblings, 1 reply; 72+ messages in thread
From: Noel Chiappa @ 2020-09-28 23:21 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Pete Turnbull

    > The SRUNL signal that was mentioned isn't likely to cause a problem

That was just a guess on my part as to the exact cause. It is definite,
though, that Q22 memory won't work with an LSI-11/2 (M7270); I just tried it.
I didn't touch any of the other boards; just swapped the LSI-11/2 for a
KDF11-A (M8186), everything worked fine; put the LSI-11/2 back, dead again.

I'll try an LSI-11 (M7264) tomorrow, make sure it's the same; it and the
LSI-11/2 are similar enough that it should, but it'd be good to confirm it.


Then back to trying to work out why Mini-Unix is so fragile for me. Has
anyone else ever worked with Mini-Unix, and if so, any tips?

       Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-27 21:12 ` Warner Losh
@ 2020-09-28  0:22   ` Pete Turnbull
  0 siblings, 0 replies; 72+ messages in thread
From: Pete Turnbull @ 2020-09-28  0:22 UTC (permalink / raw)
  To: tuhs

On 27/09/2020 22:12, Warner Losh wrote:

> Maybe a bit of electrical tape over the fingers on the 256KB board would 
> keep them isolated from these signals? That would help determine if it 
> is just floating pins, or that the LSI-11 used these pins for other reasons?

No need for tape or any other test.  The pin assignments for both the 
original LSI11 bus, as used in the 11/03, and the Q22 bus used in later 
machines, are well documented.  The 16-bit pinouts are listed in the 
1976 edition of the Microcomputer Handbook, the 18-bit in the 1980 
edition, and there's a comparison table with Q22 in the 1982 
Microcomuters and Memories handbook.  There are more differences than 
the BDAL18-21 lines and there are even differences between the KD11-F 
and KD11-HA.

The SRUNL signal that was mentioned isn't likely to cause a problem; 
it's on both AF1 and AH1 in an 11/23 and a KD11-HA, but only on AF1 on a 
KD11-F, and I'm not sure it's bussed anyway in most backplanes.

BDAL18L is on BC1, and that's an internal clock signal on a KD11-HA. 
BDAL19-21 are on BD1-BF1 and they're connected to MICROM signals in the 
KD11-HA.  None of them are connected to anything on a KD11-F.

-- 
Pete
Pete Turnbull

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-28  0:03 ` Paul Riley
@ 2020-09-28  0:06   ` Paul Riley
  0 siblings, 0 replies; 72+ messages in thread
From: Paul Riley @ 2020-09-28  0:06 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 2615 bytes --]

Sorry, That should be 8kB (4kW) of high memory...


On Mon, 28 Sep 2020 at 08:03, Paul Riley <paul@rileyriot.com> wrote:

>
>> don't know how that board uses the SD card, in terms of where it keeps the
>> RL02 image, but if you can find that out, SD<->USB3 adaptors are cheap and
>> plentiful, and it shouldn't be too hard to load the disk image into it
>> using
>> one of them. (For the QSIC, I found a 'dd' for Winsdoze and used that to
>> write
>> the disk image onto the SD card.)
>>
>> Here's how the formatting of the SD card is done. First you partition the
> disk into n 'FAT 12" partitions, one for each drive you wish to connect.
> Then you pop the card in the emulator board, and run a utility which
> formats the partitions as "Linux" and you then have n 10.5MB Linux
> partitions. Putting the card back into your host machine, you then copy
> your RL02 disk images to the newly formatted Linux partitions.
>
> Here's the full explanation:
>
> https://www.5volts.ch/pages/rlv12/rlv12-createdisk/
>
>
>>     > I don't have any PROMs other than what would be on the '03 or '23+
>>     > boards now.
>>
>> Not a problem: if you hook up the -11's console to another computer, you
>> can download a bootstrap into it over the serial line, using the -11's
>> ODT.
>>
>
> Thanks for the tip.
>
>
>> Speaking of booting, I have Mini-Uix booting under an -11/05 simulator
>> (Ersatz-11); I used the RK image from here:
>>
>> Thanks again.
>
>
>> Oh, I recently realized how to make a  bit more room on an -11/03: most
>> DEC small QBUS memory cards allow you to use half the 'I/O page' for
>> memory,
>>
>
> Sounds beyond me, and not necessary at this stage.
>
>
>> What kind of memory card(s) do you have for the -11/03?
>>
>>
> The 256kB card is:
> M8067-KA MSV11-PK 256-kbyte MOS memory with parity CSR
>  I'll keep that for the '23+.
>
> Can you clarify something for me regarding memory? I understand the bottom
> area of memory in a Unix system is for the Kernel and it's stuff, and that
> the top 8kB is set aside for device I/O (with the exceptions you mentioned
> in a previous email about using some of that space). The LSI-11 board has
> 4kW of RAM on it, and I have already a 16KW board. If I want to further
> expand the RAM, and say I buy another 16kW board, that makes an arithmetic
> sum of 32kW for the boards, making 36kW total. Can the 4kW of on-board RAM
> be disabled, and only the 32kW on the boards be used? Is it ok for the
> installed RA mto overlap the 8kW at the high memory area? Do the devices
> spoof these addresses or do they read/write in the high installed RAM area?
>
> Paul
>

[-- Attachment #2: Type: text/html, Size: 4812 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-25 22:08 Noel Chiappa
  2020-09-26 14:52 ` John Foust
@ 2020-09-28  0:03 ` Paul Riley
  2020-09-28  0:06   ` Paul Riley
  1 sibling, 1 reply; 72+ messages in thread
From: Paul Riley @ 2020-09-28  0:03 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 2404 bytes --]

>
>
> don't know how that board uses the SD card, in terms of where it keeps the
> RL02 image, but if you can find that out, SD<->USB3 adaptors are cheap and
> plentiful, and it shouldn't be too hard to load the disk image into it
> using
> one of them. (For the QSIC, I found a 'dd' for Winsdoze and used that to
> write
> the disk image onto the SD card.)
>
> Here's how the formatting of the SD card is done. First you partition the
disk into n 'FAT 12" partitions, one for each drive you wish to connect.
Then you pop the card in the emulator board, and run a utility which
formats the partitions as "Linux" and you then have n 10.5MB Linux
partitions. Putting the card back into your host machine, you then copy
your RL02 disk images to the newly formatted Linux partitions.

Here's the full explanation:

https://www.5volts.ch/pages/rlv12/rlv12-createdisk/


>     > I don't have any PROMs other than what would be on the '03 or '23+
>     > boards now.
>
> Not a problem: if you hook up the -11's console to another computer, you
> can download a bootstrap into it over the serial line, using the -11's ODT.
>

Thanks for the tip.


> Speaking of booting, I have Mini-Uix booting under an -11/05 simulator
> (Ersatz-11); I used the RK image from here:
>
> Thanks again.


> Oh, I recently realized how to make a  bit more room on an -11/03: most
> DEC small QBUS memory cards allow you to use half the 'I/O page' for
> memory,
>

Sounds beyond me, and not necessary at this stage.


> What kind of memory card(s) do you have for the -11/03?
>
>
The 256kB card is:
M8067-KA MSV11-PK 256-kbyte MOS memory with parity CSR
 I'll keep that for the '23+.

Can you clarify something for me regarding memory? I understand the bottom
area of memory in a Unix system is for the Kernel and it's stuff, and that
the top 8kB is set aside for device I/O (with the exceptions you mentioned
in a previous email about using some of that space). The LSI-11 board has
4kW of RAM on it, and I have already a 16KW board. If I want to further
expand the RAM, and say I buy another 16kW board, that makes an arithmetic
sum of 32kW for the boards, making 36kW total. Can the 4kW of on-board RAM
be disabled, and only the 32kW on the boards be used? Is it ok for the
installed RA mto overlap the 8kW at the high memory area? Do the devices
spoof these addresses or do they read/write in the high installed RAM area?

Paul

[-- Attachment #2: Type: text/html, Size: 4120 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-27 21:07 Noel Chiappa
@ 2020-09-27 21:12 ` Warner Losh
  2020-09-28  0:22   ` Pete Turnbull
  0 siblings, 1 reply; 72+ messages in thread
From: Warner Losh @ 2020-09-27 21:12 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

On Sun, Sep 27, 2020, 3:08 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

>     > So that confuses Q22 memory. If one tries to use one with an LSI-11,
>     > the machine is totally dead - not even ODT.
>
> Oh, that's another LSI-11 'feature' (only discovered after someone sent in
> a
> help request on CCalk for a dead LSI-11): if there's no working memory at
> 0,
> ODT won't start/run. So if the Q22 memory is confused, the whole machine
> is dead.
>

Maybe a bit of electrical tape over the fingers on the 256KB board would
keep them isolated from these signals? That would help determine if it is
just floating pins, or that the LSI-11 used these pins for other reasons?

Warner

[-- Attachment #2: Type: text/html, Size: 1299 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-27 21:07 Noel Chiappa
  2020-09-27 21:12 ` Warner Losh
  0 siblings, 1 reply; 72+ messages in thread
From: Noel Chiappa @ 2020-09-27 21:07 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > So that confuses Q22 memory. If one tries to use one with an LSI-11,
    > the machine is totally dead - not even ODT.

Oh, that's another LSI-11 'feature' (only discovered after someone sent in a
help request on CCalk for a dead LSI-11): if there's no working memory at 0,
ODT won't start/run. So if the Q22 memory is confused, the whole machine is dead.

    Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-27 20:50 Noel Chiappa
  2020-09-29 13:20 ` Paul Riley
  0 siblings, 1 reply; 72+ messages in thread
From: Noel Chiappa @ 2020-09-27 20:50 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Paul Riley

    > I also have a DEC 256KB board, but I doubt I could use it on the
    > '03.

Yes, DEC 256KB boards are what's called Q22, and those don't seem to work with
LSI-11's; not even CPU ODT works. I just tried a 256KB MSV11-L with an LSI-11,
and it definitely doesn't work; the MSV11-P is definitely a Q22 board, and so
probably also won't work.

What the Q22 means is that early in the lifetime of the QBUS, it only had 18
address line - so-called Q18. (Technially the LII-11 used only 16 address lines,
so it's actually Q16.) DEC latter snarfed some of the 'unused' pins, and
made them QDAL18-21. So boards that use those pins for QDAL18-21 are 'Q22'
boards.

My theory on what the problem is is that the LSI-11 uses some of those pins
for other things - I think the 'run' light, IIRC. So that confuses Q22 memory.
If one tries to use one with an LSI-11, the machine is totally dead - not even
ODT. It doesn't do any harm, though; unplug the Q22 memory, and plug in a Q18
card like an MSV11-D, and it'll be fine.

If you need memory for the LSI-11, MSV11-D boards are pretty common on eBait,
for not much. They tend to be flaky, though; sometimes they come back to life
if you leave them sit for a bit after you plug them in.

  > I believe the [memory] board is non-DEC.

Well, if it's Q22 it won't work either. Both that and the DEC board should
work in the /23, though. (If you have the part number on the memory chips, a
little arithmetic should give you the board size. 256K and up are generallly
Q22; if you have a manual for that card it might say.)


I'm still working with Mini-Unix; it's very fragile. When I got it running,
the first thing I tried to do was changle the line editing characters (since
my normal ones are burned into ROM). Alas, in stock V6, DEL is hard-wired to
be 'interrupt process', so I can't just 'stty [mumble]', I have to rebuild the
kernel to change that. Not a problem, necessarily - but I edited tty.h and
said 'cc -c tty.c', and it crashed and re-started - and roached the disk. So
I'm still trying to make progress. I might have mis-configured the simulator,
I'll see.

     Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-25 22:08 Noel Chiappa
@ 2020-09-26 14:52 ` John Foust
  2020-09-28  0:03 ` Paul Riley
  1 sibling, 0 replies; 72+ messages in thread
From: John Foust @ 2020-09-26 14:52 UTC (permalink / raw)
  To: tuhs


Have you searched the archives?  Here's some previous conversation.

https://web.archive.org/web/20030215152905/https://minnie.tuhs.org/pipermail/pups/2001-March/000273.html

- John


^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-25 22:08 Noel Chiappa
  2020-09-26 14:52 ` John Foust
  2020-09-28  0:03 ` Paul Riley
  0 siblings, 2 replies; 72+ messages in thread
From: Noel Chiappa @ 2020-09-25 22:08 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Paul Riley

    > I have two RLV-12/RL02 emulator boards I had made from Peter Schranz's
    > design (5volts.ch). They take an SD card

Ah, you're all set, then - doubly so, in fact. Not only do you have reliable
mass storage, but you should be able to put the Unix filesystem on an SD card,
to get the bits into the machine.

I'm not familiar with that board, but it sounds pretty good; QBUS<->SD. I
don't know how that board uses the SD card, in terms of where it keeps the
RL02 image, but if you can find that out, SD<->USB3 adaptors are cheap and
plentiful, and it shouldn't be too hard to load the disk image into it using
one of them. (For the QSIC, I found a 'dd' for Winsdoze and used that to write
the disk image onto the SD card.)


    > I don't have any PROMs other than what would be on the '03 or '23+
    > boards now.

Not a problem: if you hook up the -11's console to another computer, you
can download a bootstrap into it over the serial line, using the -11's ODT.
(There's a page here:

  http://gunkies.org/wiki/Running_an_LSI-11_from_Unix_V6

which talks briefly about how to do that. Things like PDP11GUI can do it too,
I think.) I don't use an RK bootstrap in ROM to boot from the emulated RK11 on
the QSIC; I just load in a short RK bootstrap. I don't know of one lying
around for the RL11, but one would be trivial to whip up.


Speaking of booting, I have Mini-Uix booting under an -11/05 simulator
(Ersatz-11); I used the RK image from here:

  http://www.tavi.co.uk/unixhistory/mini-unix/munixrks.zip

and it just started right up. So that's the big hurdle; been busy with other
stuff, but I'll work on getting it to boot on an '03 'soon'.

You probably want to do the same; having it running under a simulator will
make it easy to build new OS images, e.g. for a system with RL02's. Build the
new system, name it 'rlmx', copy the simulator disk image into the SD card,
and away you go.


Oh, I recently realized how to make a  bit more room on an -11/03: most
DEC small QBUS memory cards allow you to use half the 'I/O page' for memory,
if you need it. I.e. instead of having 56KB of memory, and 8 KB of
address space for device registers (a lot more than is really needed), the
memory can be configured to be 60KB of memory.

It can be a bit of a hassle to use it; to have more room for the OS (for more
drivers, or disk buffers, or whatever), some pieces of Mini-Unix need to be
recompiled, to move up the address where user processes are loaded. Larger
user processes are the same thing; they aren't automatically enabled when
there's more memory, you have to change a config file, recompile some things,
and build a new system.

What kind of memory card(s) do you have for the -11/03?

     Noel



^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-24 18:56 Noel Chiappa
  0 siblings, 0 replies; 72+ messages in thread
From: Noel Chiappa @ 2020-09-24 18:56 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: John Cowan

    > if you are not messing with the kernel or drivers, I find apout to be
    > delightful.

Pretty much all of what little I do with V6 anymore is kernel hacking! :-)

       Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-24 13:04 Noel Chiappa
@ 2020-09-24 18:24 ` John Cowan
  0 siblings, 0 replies; 72+ messages in thread
From: John Cowan @ 2020-09-24 18:24 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 2485 bytes --]

I suppose this is teaching your grandmother(s) to suck eggs, but if you are
not messing with the kernel or drivers, I find apout to be delightful.

On Thu, Sep 24, 2020 at 9:04 AM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

>     > From: Paul Riley
>
>     > On my physical '03 I have twin Sykes floppy drives. I note that in
> the
>     > LSX archives there is a Sykes driver, so I can adapt that I guess.
>
> Yes, here:
>
>  https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/sykfd.c
>
> It looks like it should be a straight drop-in, to run it on Mini-Unix. Not
> sure if your controller is the exact same model, though? Is there any
> documentation on yours? (I haven't done any searching.)
>
> If you want to boot from it, you'll need to write a bootstrap for it; I
> poked
> around, but didn't see one. (Not sure how they booted machines with one,
> back
> in the day; maybe it wasn't the only drive, and they booted off something
> else.)  You can probably modify the RX one:
>
>   https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/src/rxboot.s
>   https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/src/rxboot2.s
>
> Note that this is a 2-stage bootstrap, apparently as a result of the small
> hardware block size on the RX.
>
> And of course there's still the issue of 'how to get bits onto it'. Can
> floppies for it be written on some other kind of machine? If so, someone on
> the Classic Computers list:
>
>   http://www.classiccmp.org/mailman/listinfo/cctalk
>
> may be able to help you write those, or an RL02 pack.
>
>
> You should start by getting some experience building V6 OS loads (Mini-Unix
> will be _very_ similar); use a simulator. I have a lengthy tutorial here:
>
>   http://www.chiappa.net/~jnc/tech/V6Unix.html
>
> It's in terms of Ersatz-11, which I prefer because it has that nice DOS
> device,
> which makes it easy to get files into the Unix (so I can use my normal
> editor on
> the host machine). However, I gather most people prefer SIMH; there is a
> tutorial
> here:
>
>   https://gunkies.org/wiki/Running_Unix_v6_in_SIMH
>
> (I didn't write it; I know nothing of SIMH) for that option.
>
> How do people using SIMH get files into a Unix running on one? Larry Allen
> just wrote a PDP-11 simulator in Rust, and he's thinking about adding a
> paper-tape reader (connectable to a file), so that if he installs the stock
> V6 PTR driver, he can just do 'cat /dev/ptr > myfile'; sort of like how
> VM/370 used the virtual card reader.
>
>        Noel
>
>

[-- Attachment #2: Type: text/html, Size: 3625 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-24 13:04 Noel Chiappa
  2020-09-24 18:24 ` John Cowan
  0 siblings, 1 reply; 72+ messages in thread
From: Noel Chiappa @ 2020-09-24 13:04 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Paul Riley

    > On my physical '03 I have twin Sykes floppy drives. I note that in the
    > LSX archives there is a Sykes driver, so I can adapt that I guess.

Yes, here:

 https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/sys/sykfd.c

It looks like it should be a straight drop-in, to run it on Mini-Unix. Not
sure if your controller is the exact same model, though? Is there any
documentation on yours? (I haven't done any searching.)

If you want to boot from it, you'll need to write a bootstrap for it; I poked
around, but didn't see one. (Not sure how they booted machines with one, back
in the day; maybe it wasn't the only drive, and they booted off something
else.)  You can probably modify the RX one:

  https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/src/rxboot.s
  https://www.tuhs.org/cgi-bin/utree.pl?file=LSX/src/rxboot2.s

Note that this is a 2-stage bootstrap, apparently as a result of the small
hardware block size on the RX.

And of course there's still the issue of 'how to get bits onto it'. Can
floppies for it be written on some other kind of machine? If so, someone on
the Classic Computers list:

  http://www.classiccmp.org/mailman/listinfo/cctalk

may be able to help you write those, or an RL02 pack.


You should start by getting some experience building V6 OS loads (Mini-Unix
will be _very_ similar); use a simulator. I have a lengthy tutorial here:

  http://www.chiappa.net/~jnc/tech/V6Unix.html

It's in terms of Ersatz-11, which I prefer because it has that nice DOS device,
which makes it easy to get files into the Unix (so I can use my normal editor on
the host machine). However, I gather most people prefer SIMH; there is a tutorial
here:

  https://gunkies.org/wiki/Running_Unix_v6_in_SIMH

(I didn't write it; I know nothing of SIMH) for that option.

How do people using SIMH get files into a Unix running on one? Larry Allen
just wrote a PDP-11 simulator in Rust, and he's thinking about adding a
paper-tape reader (connectable to a file), so that if he installs the stock
V6 PTR driver, he can just do 'cat /dev/ptr > myfile'; sort of like how
VM/370 used the virtual card reader.

       Noel


^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-24 11:02 Paul Ruizendaal
  2021-02-03  0:12 ` Greg A. Woods
  0 siblings, 1 reply; 72+ messages in thread
From: Paul Ruizendaal @ 2020-09-24 11:02 UTC (permalink / raw)
  To: TUHS main list; +Cc: Noel Chiappa

[-- Attachment #1: Type: text/plain, Size: 1564 bytes --]

> V6, as distributed, had no networking at all. There are two V6 systems with
> networking in TUHS:
> 
>  https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC <https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC>
>  https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6 <https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6>
> 
> The first is an 'NCP' Unix (unless unless you have an ARPANet); the second is
> a fairly early TCP/IP from BBN (ditto, out of the box; although one could write
> an Ethernet driver for it).

I’ve also done a port of the BBN VAX stack to V6 (running on a TI990 clone), using a serial
PPP interface to connect. Experimental, but may have the OP's interest:
https://www.jslite.net/cgi-bin/9995/dir?ci=tip

> There's also a fairly nice Internet-capable V6 (well, PWB1, actually) from MIT
> which I keep meaning to upload; it includes SMTP, FTP, etc, etc. I also have
> visions of porting an ARP I wrote to it, and bringing up an Ethernet driver
> for the DEQNA/DELQA, but I've yet to get to any of that.

I’d love to have a look at that and compare and contrast the approaches.

I’m finding that BBN’s original design, with a separate kernel thread for the network stack,
is elegant but difficult to tune: too much priority and it crowds out user processes, too little
and the slow PPP line is not kept busy.

I think I’m beginning to understand why CSRG (and later also BBN) moved to
the interrupt driven structure of 4.2BSD: perhaps it was also difficult to tune for a
VAX with ethernet.


[-- Attachment #2: Type: text/html, Size: 2404 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-24  1:28 Noel Chiappa
  0 siblings, 0 replies; 72+ messages in thread
From: Noel Chiappa @ 2020-09-24  1:28 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > Would also be great if supported RL02 drives. ;)

_Support_ for RL02's will not be a problem (but there are probably some issues
- see below). I have an RL11 driver for V6, which will be easy to include in a
system build. There is also a RL V6 boostrap (which lives in block 0 - it
loads the OS from a V6 filesystem); how to load it off the RL pack on actual
hardware, I'm not sure; do you have some PROM device that has an RL bootstrap
in it?

Or do you have some other drive which is going to be your boot device? If not,
how are you going to get the bits onto an RL pack? This was a bit of an issue
for Fritz Muelller with his -11/45 (with an RK05 drive); he finally wound up
having to load it over a serial line, which took several hours. He used
something called PDP11GUI, and you're in luck, that does support RL02's.

Also, I'm not sure if you've had any experience with an old removable-pack
drive. If not, you have to be very careful with them; if you have a head
crash, the heads are now unobtainium, so a head crash will turn the drive into
junk. (Which is a big part of why Dave Bridgham and I are doing to QSIC RK11
emulator...) The packs need to be absolutely clean; a number of people have
experience with them, you should probably qget some lessons from them before trying
to use it.


    > I'd imagine the V6 TTY driver would support boards with multiple serial
    > ports. Guess that's what's needed for multi user access.

The TTY code in V6 consists of two levels of driver. The bottom layer is a
driver which is specific to the particular type of card one's using; DL-11,
DZ-11, etc. If the card supports multiple lines, that driver will too. Then
there's a layer above that, tty.c, which the low-level driver uses to interace
to the OS; the user talks to that. That layer is multi-line.

   Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-23 23:14 Noel Chiappa
@ 2020-09-24  1:09 ` John Foust
  0 siblings, 0 replies; 72+ messages in thread
From: John Foust @ 2020-09-24  1:09 UTC (permalink / raw)
  To: tuhs

At 06:14 PM 9/23/2020, Noel Chiappa wrote:
>I've sent him an email (at the
>address given on that site), we'll see if I get a reply. He might not have a
>way to read those floppies...

He's in Madison, WI and I'm not far from him.  None of my Teraks 
are working (although I have a dozen or so.)  I've tinkered with 
finding another way to read the 8" floppies, as I'd like to 
archive my collection.

- John
  


^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-23 23:14 Noel Chiappa
  2020-09-24  1:09 ` John Foust
  0 siblings, 1 reply; 72+ messages in thread
From: Noel Chiappa @ 2020-09-23 23:14 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: John Foust

    > Mark Riordan has a copy and some docs...
    > http://www.60bits.net/msu/mycomp/terak/termedia.htm

Alas, the only thing online there is a list of which floppies he had, not any
actual content (other than one document). I've sent him an email (at the
address given on that site), we'll see if I get a reply. He might not have a
way to read those floppies...

If not, no biggie; in asking I more wanted to make sure I wasn't wasting my
time, I don't really need him to come through. Having done the /40->/23 move,
I'm sure the /05->/03 move won't present any major problems.

BTW, looking around for a copy of a document he mentioned, I found this:

  http://www.tavi.co.uk/unixhistory/mini-unix.html

so between them and the stuff at TUHS, I think we have everything we'd need.

   Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-22 21:51 John Foust
  0 siblings, 0 replies; 72+ messages in thread
From: John Foust @ 2020-09-22 21:51 UTC (permalink / raw)
  To: tuhs

I wrote:
>There was one for the Terak (an 11/03) in May 1979 but I've never found a copy.

I take it back...  Mark Riordan has a copy and some docs...

http://www.60bits.net/msu/mycomp/terak/termedia.htm

- John


^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-22 21:36 Noel Chiappa
  2020-09-22 21:46 ` Warner Losh
@ 2020-09-22 21:49 ` John Foust
  1 sibling, 0 replies; 72+ messages in thread
From: John Foust @ 2020-09-22 21:49 UTC (permalink / raw)
  To: tuhs

At 04:36 PM 9/22/2020, Noel Chiappa wrote:
>On thinking about it, I might do the -11/03 port of Mini-Unix for the hack
>value; it looks like it should be a quick project (a couple of hours, much of
>which would be getting Mini-Unix set up; I'd use a simulator, my QBUS RK11
>emulator is broken at the moment).

There was one for the Terak (an 11/03) in May 1979 but I've never found a copy.

See page 14...  

https://conservancy.umn.edu/bitstream/handle/11299/159028/UCC_Special%20_Issue_May_1979.pdf?sequence=1&isAllowed=y

- John


^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-22 21:36 Noel Chiappa
@ 2020-09-22 21:46 ` Warner Losh
  2020-09-22 21:49 ` John Foust
  1 sibling, 0 replies; 72+ messages in thread
From: Warner Losh @ 2020-09-22 21:46 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1773 bytes --]

On Tue, Sep 22, 2020 at 3:37 PM Noel Chiappa <jnc@mercury.lcs.mit.edu>
wrote:

>     > If you want multiple users on an -11/03, Mini-Unix would be an
> option;
>     > zit doesn't support the -11/03 'out of the box', but looking at it,
> it
>     > shouldn't be too hard. (Heinz mentioned that it had been done
> before.)
>
> On thinking about it, I might do the -11/03 port of Mini-Unix for the hack
> value; it looks like it should be a quick project (a couple of hours, much
> of
> which would be getting Mini-Unix set up; I'd use a simulator, my QBUS RK11
> emulator is broken at the moment).
>
> I think it should mostly just be some fairly straight-forward changes to
> mch.s; I think all the C code would be fine. (Unless there's an
> 'PS->integ' or
> something hiding somewhere.) Also a few odds and ends, like a software
> console
> switch register (been there, done that).
>
> That would make the full power of Mini-Unix available to people with
> -11/03's;
> those are still fairly common, and reasonably cheap. (Unlike -11/05's.)
> It's a
> considerably more capable system than LSX: e.g. the tty driver is the full
> V6
> one, and supports an arbitrary number of devices.
>
>
> So my question is: had anyone else already done this (I don't want to waste
> time replicating already-done work)? Also, would anyone have a use for it
> if I
> did it? If so, I'll put it up on a Web page when I'm done. (No, I _don't_
> use
> Guthub, and have zero interest in learning how. I'd rather spend my
> remaining
> un-comitted neurons improving my ability to read feudal Japanese.)
>

There's several references to different miniunix patches in the AUSAM
newletters... Any chance those are still around? They don't seem to be in
the TUHS AUSAM archives, though...

Warner

[-- Attachment #2: Type: text/html, Size: 2275 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-22 21:36 Noel Chiappa
  2020-09-22 21:46 ` Warner Losh
  2020-09-22 21:49 ` John Foust
  0 siblings, 2 replies; 72+ messages in thread
From: Noel Chiappa @ 2020-09-22 21:36 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > If you want multiple users on an -11/03, Mini-Unix would be an option;
    > zit doesn't support the -11/03 'out of the box', but looking at it, it
    > shouldn't be too hard. (Heinz mentioned that it had been done before.)

On thinking about it, I might do the -11/03 port of Mini-Unix for the hack
value; it looks like it should be a quick project (a couple of hours, much of
which would be getting Mini-Unix set up; I'd use a simulator, my QBUS RK11
emulator is broken at the moment).

I think it should mostly just be some fairly straight-forward changes to
mch.s; I think all the C code would be fine. (Unless there's an 'PS->integ' or
something hiding somewhere.) Also a few odds and ends, like a software console
switch register (been there, done that).

That would make the full power of Mini-Unix available to people with -11/03's;
those are still fairly common, and reasonably cheap. (Unlike -11/05's.) It's a
considerably more capable system than LSX: e.g. the tty driver is the full V6
one, and supports an arbitrary number of devices.


So my question is: had anyone else already done this (I don't want to waste
time replicating already-done work)? Also, would anyone have a use for it if I
did it? If so, I'll put it up on a Web page when I'm done. (No, I _don't_ use
Guthub, and have zero interest in learning how. I'd rather spend my remaining
un-comitted neurons improving my ability to read feudal Japanese.)

	Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-22 15:59 Noel Chiappa
  2021-02-03  0:07 ` Greg A. Woods
  0 siblings, 1 reply; 72+ messages in thread
From: Noel Chiappa @ 2020-09-22 15:59 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Paul Riley

    > In the bootable images archive, there's the "Unknown V6" RL02
    > image. I've tried that on SimH configured as an 11/23+ with 256kB of RAM
    > and it seems to work fine.

Sorry, where's this archive? Somewhere in:

  https://www.tuhs.org/Archive/Distributions/Research/

I assume? From the description, that might be from the 'Shoppa disks'; didn't
realize that was a /23 on those.


    > I would assume that Ethernet boards are available, but not supported on
    > V6.

V6, as distributed, had no networking at all. There are two V6 systems with
networking in TUHS:

  https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC
  https://minnie.tuhs.org//cgi-bin/utree.pl?file=BBN-V6

The first is an 'NCP' Unix (unless unless you have an ARPANet); the second is
a fairly early TCP/IP from BBN (ditto, out of the box; although one could write
an Ethernet driver for it).

There's also a fairly nice Internet-capable V6 (well, PWB1, actually) from MIT
which I keep meaning to upload; it includes SMTP, FTP, etc, etc. I also have
visions of porting an ARP I wrote to it, and bringing up an Ethernet driver
for the DEQNA/DELQA, but I've yet to get to any of that.


    > it's hard to glean that wisdom from reading the manual.

Yeah, DEC manuals went through a phase-change around about the time of the
/23.  Old DEC manuals are wonderful; stuffed to the gills with deep technical
details. Suitable for engineers...

Later, they turned into manuals for 'ordinary people' - 'plug cable C1 into
plug P1'. Semi-useless; although one can often glean a few useful morsels if
you trawl through the entire thing.

That's why I've been doing PDP-11 pages on the CHWiki which attempt to cover a
lot of technical detail, in a high technical content/size way.

If you need something that's not there, let me know, and I'll get to adding it.

   Noel


^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-22  0:47 Noel Chiappa
  0 siblings, 0 replies; 72+ messages in thread
From: Noel Chiappa @ 2020-09-22  0:47 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Paul Riley <pdr0663@icloud.com>

    >> the tty driver:
    >>
    >>  https://minnie.tuhs.org//cgi-bin/utree.pl?file=LSX/sys/tv.c
    >>
    >> only supports a single line. 

    > The second serial port would not be to support another user, but to
    > communicate with peripherals.

Ah. Well, AIX will still have an issue (above).

    Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
       [not found]     ` <4C35E6D2-8ABD-4DC2-BB2F-F15FA5BF30DD@icloud.com>
@ 2020-09-22  0:22       ` Henry Bent
  0 siblings, 0 replies; 72+ messages in thread
From: Henry Bent @ 2020-09-22  0:22 UTC (permalink / raw)
  To: Paul Riley; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 1911 bytes --]

You're welcome.  Other theoretical alternatives are one of the later 2.9BSD
patches, though I have had no success getting those to run on anything, and
maybe BRL UNIX from the CSRG DVD?  I would appreciate hearing from anyone
who has tried to get BRL UNIX running.

-Henry

On Mon, 21 Sep 2020 at 19:36, Paul Riley <pdr0663@icloud.com> wrote:

> Thanks Henry, that’s an interesting alternative.
>
> I’m trying to get a photo of the drive label.
>
> Paul
>
> Sent from my iPhone
>
> On 22 Sep 2020, at 7:28 am, Henry Bent <henry.r.bent@gmail.com> wrote:
>
> 
> On Fri, 18 Sep 2020 at 23:24, Paul Riley <paul@rileyriot.com> wrote:
>
>>
>> Team,
>>
>> I’ve read thru the FAQ and other sources regarding compatibility of
>> Research and other flavours on the PDP-11. I have two physical machines, an
>> 11/03 and an 11/23+. I’m choosing which version to use on each machine.
>>
>> Is LSX the only option on the 11/03, or could I run V6 or Mini-Unix with
>> more RAM?
>>
>> From the FAQ, it says V7 would support 11/23 with kernel recompilation, I
>> assume includes 11/23+. I see 2.11BSD would also run on a ‘23 (and + I
>> guess) with 1MB or more of RAM, so that would be preferred. I suppose 2.11
>> would be preferable.
>>
>> I also have found another 11/23+ system from a seller here in China.
>> There’s the system, and a VT100, and a hard drive I can’t identify. Here’s
>> a photo, does anyone know what it is? I may bid for it...
>>
>> Paul
>>
>> *Paul Riley*
>>
>
> Ultrix 3.1 should support the 11/23+, which would give you memory support
> up to 4MB as well as support for TCP/IP if you have a DEQNA.  I don't think
> 2.11BSD will run on anything without split I/D which the 23 does not have.
>
> Without a closer view of the label I doubt that anyone could give you a
> definite identification of that hard drive.
>
> -Henry
>
>

[-- Attachment #2: Type: text/html, Size: 3512 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-19  3:22 ` Paul Riley
  2020-09-19 14:20   ` Heinz Lycklama
@ 2020-09-21 23:27   ` Henry Bent
       [not found]     ` <4C35E6D2-8ABD-4DC2-BB2F-F15FA5BF30DD@icloud.com>
  1 sibling, 1 reply; 72+ messages in thread
From: Henry Bent @ 2020-09-21 23:27 UTC (permalink / raw)
  To: Paul Riley; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]

On Fri, 18 Sep 2020 at 23:24, Paul Riley <paul@rileyriot.com> wrote:

>
> Team,
>
> I’ve read thru the FAQ and other sources regarding compatibility of
> Research and other flavours on the PDP-11. I have two physical machines, an
> 11/03 and an 11/23+. I’m choosing which version to use on each machine.
>
> Is LSX the only option on the 11/03, or could I run V6 or Mini-Unix with
> more RAM?
>
> From the FAQ, it says V7 would support 11/23 with kernel recompilation, I
> assume includes 11/23+. I see 2.11BSD would also run on a ‘23 (and + I
> guess) with 1MB or more of RAM, so that would be preferred. I suppose 2.11
> would be preferable.
>
> I also have found another 11/23+ system from a seller here in China.
> There’s the system, and a VT100, and a hard drive I can’t identify. Here’s
> a photo, does anyone know what it is? I may bid for it...
>
> Paul
>
> *Paul Riley*
>

Ultrix 3.1 should support the 11/23+, which would give you memory support
up to 4MB as well as support for TCP/IP if you have a DEQNA.  I don't think
2.11BSD will run on anything without split I/D which the 23 does not have.

Without a closer view of the label I doubt that anyone could give you a
definite identification of that hard drive.

-Henry

[-- Attachment #2: Type: text/html, Size: 2335 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-21 19:37 Noel Chiappa
@ 2020-09-21 23:16 ` devin davison
  0 siblings, 0 replies; 72+ messages in thread
From: devin davison @ 2020-09-21 23:16 UTC (permalink / raw)
  Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 1985 bytes --]

Nice find. What does the label on the big hard drive read? I have found a
similar drive with a worn label and i am trying to see if i can find a
system to connect it to.

On Mon, Sep 21, 2020, 3:38 PM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

>     > From: Paul Riley
>
>     > Using LSX on the 11/03... Will LSX handle cards with multiple serial
>     > ports?
>
> Ah, I just read this carefully; LSX only supports a single user at a time,
> so
> there's no use to multiple serial lines? (But see below.) (I thought Heinz'
> reply message to this referred to Mini-Unix, which does suppport multiple
> users, but on reading it again I see it does not.)
>
>
> If you want multiple users on an -11/03, Mini-Unix would be an option; it
> doesn't support the -11/03 'out of the box', but looking at it, it
> shouldn't
> be too hard. (Heinz mentioned that it had been done before.) Change all
> cases
> of 'mov xx, PS' in mch.s:
>
>
> https://minnie.tuhs.org//cgi-bin/utree.pl?file=Mini-Unix/usr/sys/mxsys/mch.s
>
> to 'MTPS xx' (PS access needs a special instructtion in the /03); that
> might
> be all you need to do. (Installing a KEV11-A, so you can avoid using the
> instruction emulation package for EIS instructions would be nice, but
> apparently isn't required.)
>
>
> If Mini-Unix supports multiple users, it ought to be possible to do the
> same
> with LSX. (I'm not sure what the rationale was for making LSX single-user:
> perhaps the RX was too slow; perhaps there was no need in their use case;
> etc.)
>
> But it would probably be more work than going the Mini-Unix route; e.g.
> to start with, init only supports a single user:
>
>   https://minnie.tuhs.org//cgi-bin/utree.pl?file=LSX/src/init.c
>
> and the tty driver:
>
>   https://minnie.tuhs.org//cgi-bin/utree.pl?file=LSX/sys/tv.c
>
> only supports a single line. One could cross-port the needed 'stuff' from
> Mini-Unix, but it'd probably be easier to do the Mini-Unix -11/03
> conversion.
>
>            Noel
>

[-- Attachment #2: Type: text/html, Size: 2899 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-21 19:37 Noel Chiappa
  2020-09-21 23:16 ` devin davison
  0 siblings, 1 reply; 72+ messages in thread
From: Noel Chiappa @ 2020-09-21 19:37 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Paul Riley

    > Using LSX on the 11/03... Will LSX handle cards with multiple serial
    > ports?

Ah, I just read this carefully; LSX only supports a single user at a time, so
there's no use to multiple serial lines? (But see below.) (I thought Heinz'
reply message to this referred to Mini-Unix, which does suppport multiple
users, but on reading it again I see it does not.)


If you want multiple users on an -11/03, Mini-Unix would be an option; it
doesn't support the -11/03 'out of the box', but looking at it, it shouldn't
be too hard. (Heinz mentioned that it had been done before.) Change all cases
of 'mov xx, PS' in mch.s:

  https://minnie.tuhs.org//cgi-bin/utree.pl?file=Mini-Unix/usr/sys/mxsys/mch.s

to 'MTPS xx' (PS access needs a special instructtion in the /03); that might
be all you need to do. (Installing a KEV11-A, so you can avoid using the
instruction emulation package for EIS instructions would be nice, but
apparently isn't required.)


If Mini-Unix supports multiple users, it ought to be possible to do the same
with LSX. (I'm not sure what the rationale was for making LSX single-user:
perhaps the RX was too slow; perhaps there was no need in their use case;
etc.)

But it would probably be more work than going the Mini-Unix route; e.g.
to start with, init only supports a single user:

  https://minnie.tuhs.org//cgi-bin/utree.pl?file=LSX/src/init.c

and the tty driver:

  https://minnie.tuhs.org//cgi-bin/utree.pl?file=LSX/sys/tv.c

only supports a single line. One could cross-port the needed 'stuff' from
Mini-Unix, but it'd probably be easier to do the Mini-Unix -11/03 conversion.

	   Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-21 17:59 Noel Chiappa
@ 2020-09-21 18:18 ` Arthur Krewat
  0 siblings, 0 replies; 72+ messages in thread
From: Arthur Krewat @ 2020-09-21 18:18 UTC (permalink / raw)
  To: tuhs


On 9/21/2020 1:59 PM, Noel Chiappa wrote:
> The DZ11 is interrupt-per-character on output
I can vouch for that. I ran one at 19,200 on a KS10 to an Adds terminal 
I think... (after I modified the TOPS-10 6.03A monitor to add the option 
to SET TERM), and if I did an HT$$ in TECO of a large file, it would 
bring the system to it's knees.

On the other hand, echo was a lot faster than the DCA ;)

art k.



^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-21 18:13 Noel Chiappa
  0 siblings, 0 replies; 72+ messages in thread
From: Noel Chiappa @ 2020-09-21 18:13 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > They are program compatible with the DHV11

Argh; typo. 'DLV11'.

      Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-21 17:59 Noel Chiappa
  2020-09-21 18:18 ` Arthur Krewat
  0 siblings, 1 reply; 72+ messages in thread
From: Noel Chiappa @ 2020-09-21 17:59 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Heinz Lycklama

    > The DLV-11 supported only one serial port in 1975. Other DEC interface
    > devices may have been added to the Qbus after the mid 1970's.

The DLV11-J:

  http://gunkies.org/wiki/DLV11-J_asynchronous_serial_line_interface

is basically 4 DLV11's rolled into a single dual-width card; that's definitely
an option for Mini-Unix (which apparently supports up to 4 simultaneous
users). They are program compatible with the DHV11, so the driver should 'just
work'. The boards are readily available on eBait; 'glitchworks' (of this
parish) sells replacement cables (quite good, I have several).

Another option for serial lines on QBUS machines are DZ11 and DH11 versions
for QBUS. (The DZ11 is interrupt-per-character on output; the DH11 is DMA on
output.) There are two generations of each: the DZV11 (quad-width) and DZQ11
(dual-width), and DHV11 (quad) and DHQ11 (dual). I think they are pretty much
program compatible with their UNIBUS brethren, and should be easy to get
running. The boards are easy to find on eBait, the breakout panels are
somewhat rarer (although there sre some DH ohes up at the moment).

	 Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-21 13:54     ` Paul Riley
@ 2020-09-21 15:30       ` Heinz Lycklama
  0 siblings, 0 replies; 72+ messages in thread
From: Heinz Lycklama @ 2020-09-21 15:30 UTC (permalink / raw)
  To: Paul Riley; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 2141 bytes --]

Interaction with the outside world on the first LSX system
used standard DEC interfaces of the day - DLV-11 (serial)
and DRV-11 (parallel), plus a specially designed interface
card for a local device. The DLV-11 supported only one
serial port in 1975. Other DEC interface devices may have
been added to the Qbus after the mid 1970's.

Heinz


On 9/21/2020 6:54 AM, Paul Riley wrote:
> Heinz,
>
> Using LSX on the 11/03, what did you use for interaction with the 
> outside world? The SLU of the time had only one port I believe, and 
> that would be tied up with the console terminal. Will LSX handle cards 
> with multiple serial ports? Was there a favoured digital or analog I/O 
> board with some form of kernel support?
>
> Paul
>
> *Paul Riley*
>
>
>
>
> On Sat, 19 Sep 2020 at 22:22, Heinz Lycklama <heinz@osta.com 
> <mailto:heinz@osta.com>> wrote:
>
>     I do believe that it would be easier to use LSX source code,
>     but I also know that some folks at universities were able
>     to modify the source for Mini-UNIX to run on 11/03 in
>     the mid-70's because of the two, only Mini-UNIX source
>     code was available to universities.
>
>     Heinz
>
>     On 9/18/2020 8:22 PM, Paul Riley wrote:
>>
>>     Team,
>>
>>     I’ve read thru the FAQ and other sources regarding compatibility
>>     of Research and other flavours on the PDP-11. I have two physical
>>     machines, an 11/03 and an 11/23+. I’m choosing which version to
>>     use on each machine.
>>
>>     Is LSX the only option on the 11/03, or could I run V6 or
>>     Mini-Unix with more RAM?
>>
>>     From the FAQ, it says V7 would support 11/23 with kernel
>>     recompilation, I assume includes 11/23+. I see 2.11BSD would also
>>     run on a ‘23 (and + I guess) with 1MB or more of RAM, so that
>>     would be preferred. I suppose 2.11 would be preferable.
>>
>>     I also have found another 11/23+ system from a seller here in
>>     China. There’s the system, and a VT100, and a hard drive I can’t
>>     identify. Here’s a photo, does anyone know what it is? I may bid
>>     for it...
>>
>>     Paul
>>
>>     *Paul Riley*
>>
>>
>


[-- Attachment #2: Type: text/html, Size: 7876 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-19 14:20   ` Heinz Lycklama
@ 2020-09-21 13:54     ` Paul Riley
  2020-09-21 15:30       ` Heinz Lycklama
  0 siblings, 1 reply; 72+ messages in thread
From: Paul Riley @ 2020-09-21 13:54 UTC (permalink / raw)
  To: heinz; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]

Heinz,

Using LSX on the 11/03, what did you use for interaction with the outside
world? The SLU of the time had only one port I believe, and that would be
tied up with the console terminal. Will LSX handle cards with multiple
serial ports? Was there a favoured digital or analog I/O board with some
form of kernel support?

Paul

*Paul Riley*




On Sat, 19 Sep 2020 at 22:22, Heinz Lycklama <heinz@osta.com> wrote:

> I do believe that it would be easier to use LSX source code,
> but I also know that some folks at universities were able
> to modify the source for Mini-UNIX to run on 11/03 in
> the mid-70's because of the two, only Mini-UNIX source
> code was available to universities.
>
> Heinz
>
> On 9/18/2020 8:22 PM, Paul Riley wrote:
>
>
> Team,
>
> I’ve read thru the FAQ and other sources regarding compatibility of
> Research and other flavours on the PDP-11. I have two physical machines, an
> 11/03 and an 11/23+. I’m choosing which version to use on each machine.
>
> Is LSX the only option on the 11/03, or could I run V6 or Mini-Unix with
> more RAM?
>
> From the FAQ, it says V7 would support 11/23 with kernel recompilation, I
> assume includes 11/23+. I see 2.11BSD would also run on a ‘23 (and + I
> guess) with 1MB or more of RAM, so that would be preferred. I suppose 2.11
> would be preferable.
>
> I also have found another 11/23+ system from a seller here in China.
> There’s the system, and a VT100, and a hard drive I can’t identify. Here’s
> a photo, does anyone know what it is? I may bid for it...
>
> Paul
>
> *Paul Riley*
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 5185 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-19 15:28 Noel Chiappa
@ 2020-09-21 10:26 ` Paul Riley
  2021-01-24 16:07 ` Tom Ivar Helbekkmo via TUHS
  1 sibling, 0 replies; 72+ messages in thread
From: Paul Riley @ 2020-09-21 10:26 UTC (permalink / raw)
  To: Noel Chiappa; +Cc: tuhs

[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]

Noel,

In the bootable images archive, there's the "Unknown V6" RL02 image. I've
tried that on SimH configured as an 11/23+ with 256kB of RAM and it seems
to work fine. It seems to be somewhat tweaked, as the shell accepts "cd"
instead of "chdir" and I know the C compiler is happy with either "+=" or
"=+". It seems to be reasonably complete (at least binaries I mean). I
can't recall if the source files are there or not.

I guess at least if I use LSX and V6 then they both are V6 based, which
might minimize pain. I'd imagine stuff I write for the '23 would also then
compile on the '03.

I'll have some fun eventually on these machines with my home automation
system. I've picked-up an RS-232 -> WiFi module on TaoBao (China's answer
to eBay) and I'll implement a super-lightweight MQTT system to drive some
stuff at home. (Think custom Christmas lights.) I would assume that
Ethernet boards are available, but not supported on V6.

Anyone else have an LSI machine at home? I'd be interested to know some fun
stuff to do with it.

Paul

*Paul Riley*




On Sat, 19 Sep 2020 at 23:28, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

>     > From: Paul Riley
>
>     > Is LSX the only option on the 11/03, or could I run V6 or Mini-Unix
> with
>     > more RAM?
>
> All PDP-11 Unix versions from V4 on require the MMU, so the -11/03 is out
> for
> them. We don't have the code for V2-V4, though. So V1 (mostly all
> assembler,
> no C :-), LSW and Mini-Unix are the only options for it.
>
> V6 can be run on an -11/23 (I've done it), but not straight out of the box;
> it requires a few minor tweaks first:
>
>   http://gunkies.org/wiki/Running_UNIX_V6_on_an_-11/23
>
>         Noel
>

[-- Attachment #2: Type: text/html, Size: 2644 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-20 13:12 Noel Chiappa
  0 siblings, 0 replies; 72+ messages in thread
From: Noel Chiappa @ 2020-09-20 13:12 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > Thanks so much for your reply.

That's what we're here for... :-)


    > I have an 11/23+ does that make a difference?

No. The KDF11-B of the 23+:

  http://gunkies.org/wiki/KDF11-B_CPU

is the same CPU as all the other KDF11 CPUs; it just has a couple of extra
peripherals on the board (2 asyn serial lines, and some PROMs, IIRC).

    > From the manual it seems to have an MMU

Like all KDF11 CPUs, it has a socket for an MMU chip, but the chip may or may
not be there (I don't know if it was standard on the 23+; and in any event, it
may have been pulled - the CPU will work without it). The main CPU is a DIP
carrier which holds two chips; the optional KTF11-A MMU has one (see the
image, above); the optional KEF11-A FPU is also a carrier with two chips. (The
KDF11-B can also hold the large 6-chip carrier of the optional KEF11-B CIS
chip - a rara avid indeed, if you'relucky enough to have it.)

If yours doesn't have the MMU chip, you're probably SOL; those are very rare.
KEF11-A FPU chips are avilable on eBay for modest amounts.

    > I'm not sure if it's split I/D.

None of the KDF11 CPUs support splite I/D.

     Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
@ 2020-09-19 15:28 Noel Chiappa
  2020-09-21 10:26 ` Paul Riley
  2021-01-24 16:07 ` Tom Ivar Helbekkmo via TUHS
  0 siblings, 2 replies; 72+ messages in thread
From: Noel Chiappa @ 2020-09-19 15:28 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Paul Riley

    > Is LSX the only option on the 11/03, or could I run V6 or Mini-Unix with
    > more RAM?

All PDP-11 Unix versions from V4 on require the MMU, so the -11/03 is out for
them. We don't have the code for V2-V4, though. So V1 (mostly all assembler,
no C :-), LSW and Mini-Unix are the only options for it.

V6 can be run on an -11/23 (I've done it), but not straight out of the box;
it requires a few minor tweaks first:

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

	Noel

^ permalink raw reply	[flat|nested] 72+ messages in thread

* Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
  2020-09-19  3:22 ` Paul Riley
@ 2020-09-19 14:20   ` Heinz Lycklama
  2020-09-21 13:54     ` Paul Riley
  2020-09-21 23:27   ` Henry Bent
  1 sibling, 1 reply; 72+ messages in thread
From: Heinz Lycklama @ 2020-09-19 14:20 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

I do believe that it would be easier to use LSX source code,
but I also know that some folks at universities were able
to modify the source for Mini-UNIX to run on 11/03 in
the mid-70's because of the two, only Mini-UNIX source
code was available to universities.

Heinz

On 9/18/2020 8:22 PM, Paul Riley wrote:
>
> Team,
>
> I’ve read thru the FAQ and other sources regarding compatibility of 
> Research and other flavours on the PDP-11. I have two physical 
> machines, an 11/03 and an 11/23+. I’m choosing which version to use on 
> each machine.
>
> Is LSX the only option on the 11/03, or could I run V6 or Mini-Unix 
> with more RAM?
>
> From the FAQ, it says V7 would support 11/23 with kernel 
> recompilation, I assume includes 11/23+. I see 2.11BSD would also run 
> on a ‘23 (and + I guess) with 1MB or more of RAM, so that would be 
> preferred. I suppose 2.11 would be preferable.
>
> I also have found another 11/23+ system from a seller here in China. 
> There’s the system, and a VT100, and a hard drive I can’t identify. 
> Here’s a photo, does anyone know what it is? I may bid for it...
>
> Paul
>
> *Paul Riley*
>
>


[-- Attachment #2: Type: text/html, Size: 4351 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

* [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems
       [not found] <CAD05_j1bc6DDRtfPkd4QVeWXjwSp73bty46D=2ATozUbHThBWw@mail.gmail.com>
@ 2020-09-19  3:22 ` Paul Riley
  2020-09-19 14:20   ` Heinz Lycklama
  2020-09-21 23:27   ` Henry Bent
  0 siblings, 2 replies; 72+ messages in thread
From: Paul Riley @ 2020-09-19  3:22 UTC (permalink / raw)
  To: tuhs


[-- Attachment #1.1: Type: text/plain, Size: 805 bytes --]

Team,

I’ve read thru the FAQ and other sources regarding compatibility of
Research and other flavours on the PDP-11. I have two physical machines, an
11/03 and an 11/23+. I’m choosing which version to use on each machine.

Is LSX the only option on the 11/03, or could I run V6 or Mini-Unix with
more RAM?

From the FAQ, it says V7 would support 11/23 with kernel recompilation, I
assume includes 11/23+. I see 2.11BSD would also run on a ‘23 (and + I
guess) with 1MB or more of RAM, so that would be preferred. I suppose 2.11
would be preferable.

I also have found another 11/23+ system from a seller here in China.
There’s the system, and a VT100, and a hard drive I can’t identify. Here’s
a photo, does anyone know what it is? I may bid for it...

Paul

*Paul Riley*

[-- Attachment #1.2: Type: text/html, Size: 1696 bytes --]

[-- Attachment #2: IMG_5479.jpg --]
[-- Type: image/jpeg, Size: 52050 bytes --]

^ permalink raw reply	[flat|nested] 72+ messages in thread

end of thread, other threads:[~2021-02-03  1:26 UTC | newest]

Thread overview: 72+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-10 23:29 [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems Noel Chiappa
2020-10-11  2:30 ` Jay Logue
2020-10-11 23:24 ` Paul Riley
2020-10-12  0:53   ` Dave Horsfall
2020-10-12  1:56     ` Warner Losh
2020-10-12  2:09       ` Andrew Warkentin
2020-10-12 16:57       ` Arthur Krewat
2020-10-12 17:46         ` [TUHS] FreeBSD disk devices (Re: " Bakul Shah
2020-10-12 17:54           ` Warner Losh
2020-10-18 20:42     ` [TUHS] Fwd: " Michael Huff
  -- strict thread matches above, loose matches on Subject: below --
2021-02-03  1:25 Noel Chiappa
2020-10-18 21:36 Norman Wilson
2020-10-12 22:43 Noel Chiappa
2020-10-12 19:27 Noel Chiappa
2020-10-08 23:49 Noel Chiappa
2020-10-08 16:06 Noel Chiappa
2020-10-06 23:08 Noel Chiappa
2020-10-07  5:24 ` Jay Logue
2020-10-06 20:34 Noel Chiappa
2020-10-06 19:34 Noel Chiappa
2020-10-06 19:04 Noel Chiappa
2020-10-06 14:46 Noel Chiappa
2020-10-06 16:22 ` jay-tuhs9915
2020-10-02  0:39 Noel Chiappa
2020-10-01 12:51 Noel Chiappa
2020-10-02  0:23 ` Paul Riley
2020-09-30 23:16 Noel Chiappa
2020-09-30 18:51 Noel Chiappa
2020-09-30 17:58 Noel Chiappa
2020-09-28 23:21 Noel Chiappa
2020-09-30  1:50 ` Paul Riley
2020-09-27 21:07 Noel Chiappa
2020-09-27 21:12 ` Warner Losh
2020-09-28  0:22   ` Pete Turnbull
2020-09-27 20:50 Noel Chiappa
2020-09-29 13:20 ` Paul Riley
2020-09-25 22:08 Noel Chiappa
2020-09-26 14:52 ` John Foust
2020-09-28  0:03 ` Paul Riley
2020-09-28  0:06   ` Paul Riley
2020-09-24 18:56 Noel Chiappa
2020-09-24 13:04 Noel Chiappa
2020-09-24 18:24 ` John Cowan
2020-09-24 11:02 Paul Ruizendaal
2021-02-03  0:12 ` Greg A. Woods
2020-09-24  1:28 Noel Chiappa
2020-09-23 23:14 Noel Chiappa
2020-09-24  1:09 ` John Foust
2020-09-22 21:51 John Foust
2020-09-22 21:36 Noel Chiappa
2020-09-22 21:46 ` Warner Losh
2020-09-22 21:49 ` John Foust
2020-09-22 15:59 Noel Chiappa
2021-02-03  0:07 ` Greg A. Woods
2020-09-22  0:47 Noel Chiappa
2020-09-21 19:37 Noel Chiappa
2020-09-21 23:16 ` devin davison
2020-09-21 18:13 Noel Chiappa
2020-09-21 17:59 Noel Chiappa
2020-09-21 18:18 ` Arthur Krewat
2020-09-20 13:12 Noel Chiappa
2020-09-19 15:28 Noel Chiappa
2020-09-21 10:26 ` Paul Riley
2021-01-24 16:07 ` Tom Ivar Helbekkmo via TUHS
2021-01-25  4:58   ` Gregg Levine
2021-01-25  8:21     ` Tom Ivar Helbekkmo via TUHS
     [not found] <CAD05_j1bc6DDRtfPkd4QVeWXjwSp73bty46D=2ATozUbHThBWw@mail.gmail.com>
2020-09-19  3:22 ` Paul Riley
2020-09-19 14:20   ` Heinz Lycklama
2020-09-21 13:54     ` Paul Riley
2020-09-21 15:30       ` Heinz Lycklama
2020-09-21 23:27   ` Henry Bent
     [not found]     ` <4C35E6D2-8ABD-4DC2-BB2F-F15FA5BF30DD@icloud.com>
2020-09-22  0:22       ` Henry Bent

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).