From lehmann at ans-netz.de  Sun Nov  8 05:03:58 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Sat, 07 Nov 2015 20:03:58 +0100
Subject: [TUHS] System III - TCP/IP
Message-ID: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>

Hi,

i have an old Z8001 based SysIII variant and I would love to have
TCP/IP on it (SLIP first, later with a homebrew ethernet device).

I wonder if someone ever saw TCP/IP available on a System III?

I have lets say 90% of the kernel running on it as source
available and I started digging in the available 4.2 BSD sources.

It looks like there would be much to do to hack in TCP/IP on my
own (no IPC, no Net, no PTY, no....).

I got K5JB running (userland TCP/IP implementation) after I fixed
some C code because the C Compiler available on the system is.....
kinda limited.

telnetd is of course not working as there are no pseudo-teletypes
on this SYSIII. At least I got ping, echoping and ftpd up and
running via SLIP

(10.1.1.2 is my SysIII box:)

# ping -c3 10.1.1.2
PING 10.1.1.2 (10.1.1.2): 56 data bytes
64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms
64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms
64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms

--- 10.1.1.2 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms
# ftp 10.1.1.2
Connected to 10.1.1.2.
220  FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991
Name (10.1.1.2:root): test
331 Enter PASS command
Password:
230 Logged in
ftp> get sa.timer
local: sa.timer remote: sa.timer
500 Unknown command
500 Unknown command
200 Port command okay
150 Opening data connection for RETR sa.timer
   2571       0.53 KB/s
226 File sent OK
2571 bytes received in 00:05 (0.48 KB/s)
ftp> get wega
local: wega remote: wega
200 Port command okay
150 Opening data connection for RETR wega
  98723       0.51 KB/s
226 File sent OK
98723 bytes received in 03:05 (0.51 KB/s)
ftp> exit
221 Goodbye!
#

So I wonder if someone got anything SYSIII -> Net/TCP/IP related
which could help me in any way to get a SYSIII kernel capable of
TCP/IP and PTYs to get a telnetd up and running via SLIP is my
first goal.

Regards,
Oliver


From lm at mcvoy.com  Sun Nov  8 05:20:44 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 7 Nov 2015 11:20:44 -0800
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
Message-ID: <20151107192043.GA11895@mcvoy.com>

So this seems pretty tough, 16 bit machine and all.  If you were to get
it to work it would probably be with Lachman's STREAMS based TCP/IP.
No idea if that was open sourced.

On Sat, Nov 07, 2015 at 08:03:58PM +0100, Oliver Lehmann wrote:
> Hi,
> 
> i have an old Z8001 based SysIII variant and I would love to have
> TCP/IP on it (SLIP first, later with a homebrew ethernet device).
> 
> I wonder if someone ever saw TCP/IP available on a System III?
> 
> I have lets say 90% of the kernel running on it as source
> available and I started digging in the available 4.2 BSD sources.
> 
> It looks like there would be much to do to hack in TCP/IP on my
> own (no IPC, no Net, no PTY, no....).
> 
> I got K5JB running (userland TCP/IP implementation) after I fixed
> some C code because the C Compiler available on the system is.....
> kinda limited.
> 
> telnetd is of course not working as there are no pseudo-teletypes
> on this SYSIII. At least I got ping, echoping and ftpd up and
> running via SLIP
> 
> (10.1.1.2 is my SysIII box:)
> 
> # ping -c3 10.1.1.2
> PING 10.1.1.2 (10.1.1.2): 56 data bytes
> 64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms
> 64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms
> 64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms
> 
> --- 10.1.1.2 ping statistics ---
> 3 packets transmitted, 3 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms
> # ftp 10.1.1.2
> Connected to 10.1.1.2.
> 220  FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991
> Name (10.1.1.2:root): test
> 331 Enter PASS command
> Password:
> 230 Logged in
> ftp> get sa.timer
> local: sa.timer remote: sa.timer
> 500 Unknown command
> 500 Unknown command
> 200 Port command okay
> 150 Opening data connection for RETR sa.timer
>   2571       0.53 KB/s
> 226 File sent OK
> 2571 bytes received in 00:05 (0.48 KB/s)
> ftp> get wega
> local: wega remote: wega
> 200 Port command okay
> 150 Opening data connection for RETR wega
>  98723       0.51 KB/s
> 226 File sent OK
> 98723 bytes received in 03:05 (0.51 KB/s)
> ftp> exit
> 221 Goodbye!
> #
> 
> So I wonder if someone got anything SYSIII -> Net/TCP/IP related
> which could help me in any way to get a SYSIII kernel capable of
> TCP/IP and PTYs to get a telnetd up and running via SLIP is my
> first goal.
> 
> Regards,
> Oliver
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From b4 at gewt.net  Sun Nov  8 06:27:27 2015
From: b4 at gewt.net (Cory Smelosky)
Date: Sat, 7 Nov 2015 12:27:27 -0800
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <20151107192043.GA11895@mcvoy.com>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
Message-ID: <1C0DB3B7-988D-435F-A590-6C0AB14249A3@gewt.net>

Any ideas if any of this would work on Sys III for VAX?

(Or the technically opened PDP-11 that includes VAX)

Sent from my iPhone

> On Nov 7, 2015, at 11:20, Larry McVoy <lm at mcvoy.com> wrote:
> 
> So this seems pretty tough, 16 bit machine and all.  If you were to get
> it to work it would probably be with Lachman's STREAMS based TCP/IP.
> No idea if that was open sourced.
> 
>> On Sat, Nov 07, 2015 at 08:03:58PM +0100, Oliver Lehmann wrote:
>> Hi,
>> 
>> i have an old Z8001 based SysIII variant and I would love to have
>> TCP/IP on it (SLIP first, later with a homebrew ethernet device).
>> 
>> I wonder if someone ever saw TCP/IP available on a System III?
>> 
>> I have lets say 90% of the kernel running on it as source
>> available and I started digging in the available 4.2 BSD sources.
>> 
>> It looks like there would be much to do to hack in TCP/IP on my
>> own (no IPC, no Net, no PTY, no....).
>> 
>> I got K5JB running (userland TCP/IP implementation) after I fixed
>> some C code because the C Compiler available on the system is.....
>> kinda limited.
>> 
>> telnetd is of course not working as there are no pseudo-teletypes
>> on this SYSIII. At least I got ping, echoping and ftpd up and
>> running via SLIP
>> 
>> (10.1.1.2 is my SysIII box:)
>> 
>> # ping -c3 10.1.1.2
>> PING 10.1.1.2 (10.1.1.2): 56 data bytes
>> 64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms
>> 64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms
>> 64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms
>> 
>> --- 10.1.1.2 ping statistics ---
>> 3 packets transmitted, 3 packets received, 0.0% packet loss
>> round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms
>> # ftp 10.1.1.2
>> Connected to 10.1.1.2.
>> 220  FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991
>> Name (10.1.1.2:root): test
>> 331 Enter PASS command
>> Password:
>> 230 Logged in
>> ftp> get sa.timer
>> local: sa.timer remote: sa.timer
>> 500 Unknown command
>> 500 Unknown command
>> 200 Port command okay
>> 150 Opening data connection for RETR sa.timer
>>  2571       0.53 KB/s
>> 226 File sent OK
>> 2571 bytes received in 00:05 (0.48 KB/s)
>> ftp> get wega
>> local: wega remote: wega
>> 200 Port command okay
>> 150 Opening data connection for RETR wega
>> 98723       0.51 KB/s
>> 226 File sent OK
>> 98723 bytes received in 03:05 (0.51 KB/s)
>> ftp> exit
>> 221 Goodbye!
>> #
>> 
>> So I wonder if someone got anything SYSIII -> Net/TCP/IP related
>> which could help me in any way to get a SYSIII kernel capable of
>> TCP/IP and PTYs to get a telnetd up and running via SLIP is my
>> first goal.
>> 
>> Regards,
>> Oliver
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
> 
> -- 
> ---
> Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From clemc at ccc.com  Sun Nov  8 07:28:03 2015
From: clemc at ccc.com (Clem Cole)
Date: Sat, 7 Nov 2015 16:28:03 -0500
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <20151107192043.GA11895@mcvoy.com>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
Message-ID: <CAC20D2NnLC2H=+8ZzpXEpgUqa+qW3JuFMLeWjL_Su9OBoHWBZQ@mail.gmail.com>

hmm...

0.) adding pty's is pretty easy.  Just grab the BSD code and start
hacking.  Grab the original version of Steven's book - he will talk to you
through it in detail.   It's a two drivers, the control (ptyX) and the
slave (ttypX) .   Having them in your system is handy anyway for a number
of things besides networking (like the expect(1) program).

1.) Larry's memory might be better than mine but I did not think streams
shows up until System V.3.  I have an old PWB 3.0 (System III) manual and
see no evidence of streams in it.   Given that Dennis did not create them
until the V8 tty driver, and then later, the Summit guys use the streams
interface for networking, I'm not surprised its not in System III.   So I
think using streams is likely to be a dead end.

2.) Perry Flinn, Bob Doolittle, and I spliced BSD sockets and the 4.2 stack
into a System III -ish kernel for the Masscomp's RTU.  So it's definitely
doable - although work.  The biggest issue is that the memory systems
between BSD and System III are different.  So Rob Gurwitiz's old mbuf code
will need to be hacked.  Definitely get a copy of Steven's, maybe the
current BSD book and go for it.

3.) One other thought if all you want to a solid IP/TCP network stack and
can forgo the sockets API, then you might try to find the old BBN
distribution for BSD 4.1 (Vax) -- which is what Joy started with[remember -
Berkeley did not have contract for IP/TCP support for the Vax, BBN did -
joy took the BBN code and redid it).  By definition its is a FOSS - because
the US tax payer paid for it - although I'm not sure where to find the code
these days (google in your friend).    Anyway, the BBN stack splices into
the kernel with one small hook (a hack in nami - similar to the MIT
ChaosNet stack) but otherwise things just look like devices:  i.e.
open("/dev/tcp",...) or instead of socket(...)     There was a later
version/distribution from BBN that included the BSD sockets code as an
update for 4.2, but was the BBN guts (we actually used that version for the
Stellar machine - splicing it into a System V3 based kernel after adding
the BSD APIs).

4.) It strikes me that it would be easiest of all to just take something
like a $20-$30 "Wiznet" 5100 board from Sparkfun and interface it to the
system either via serial or better if you have a parallel port.   Then run
the IP/TCP stack externally.   This is what we do for Arduino's and other
small micro controllers - the board is well documents and easy to talk
too.  They have both RJ45 style and wireless too.   I have a hand full of
them here and am pretty happy with them for what they provide.

The fact is that for the Masscomp system originally, we ran the IP/TCP
stack in a coprocessor (in that case an 186) for realtime reasons (we did
not want networking to interrupt the main processor which was 10MHz 68K).
But when we finally went to the '020 the processor was so much faster, we
put the stack into the kernel and just use the co-processor as a very large
buffer.

Anyway - the idea is that the system hacking for a tcp stack become very
small, just a driver.   You don't get things like UNIX domain sockets, but
if what you want it telnet/ftp and the like - a cheap coprocessor like the
Wiznet should  work fine.

Clem

On Sat, Nov 7, 2015 at 2:20 PM, Larry McVoy <lm at mcvoy.com> wrote:

> So this seems pretty tough, 16 bit machine and all.  If you were to get
> it to work it would probably be with Lachman's STREAMS based TCP/IP.
> No idea if that was open sourced.
>
> On Sat, Nov 07, 2015 at 08:03:58PM +0100, Oliver Lehmann wrote:
> > Hi,
> >
> > i have an old Z8001 based SysIII variant and I would love to have
> > TCP/IP on it (SLIP first, later with a homebrew ethernet device).
> >
> > I wonder if someone ever saw TCP/IP available on a System III?
> >
> > I have lets say 90% of the kernel running on it as source
> > available and I started digging in the available 4.2 BSD sources.
> >
> > It looks like there would be much to do to hack in TCP/IP on my
> > own (no IPC, no Net, no PTY, no....).
> >
> > I got K5JB running (userland TCP/IP implementation) after I fixed
> > some C code because the C Compiler available on the system is.....
> > kinda limited.
> >
> > telnetd is of course not working as there are no pseudo-teletypes
> > on this SYSIII. At least I got ping, echoping and ftpd up and
> > running via SLIP
> >
> > (10.1.1.2 is my SysIII box:)
> >
> > # ping -c3 10.1.1.2
> > PING 10.1.1.2 (10.1.1.2): 56 data bytes
> > 64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms
> > 64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms
> > 64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms
> >
> > --- 10.1.1.2 ping statistics ---
> > 3 packets transmitted, 3 packets received, 0.0% packet loss
> > round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms
> > # ftp 10.1.1.2
> > Connected to 10.1.1.2.
> > 220  FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991
> > Name (10.1.1.2:root): test
> > 331 Enter PASS command
> > Password:
> > 230 Logged in
> > ftp> get sa.timer
> > local: sa.timer remote: sa.timer
> > 500 Unknown command
> > 500 Unknown command
> > 200 Port command okay
> > 150 Opening data connection for RETR sa.timer
> >   2571       0.53 KB/s
> > 226 File sent OK
> > 2571 bytes received in 00:05 (0.48 KB/s)
> > ftp> get wega
> > local: wega remote: wega
> > 200 Port command okay
> > 150 Opening data connection for RETR wega
> >  98723       0.51 KB/s
> > 226 File sent OK
> > 98723 bytes received in 03:05 (0.51 KB/s)
> > ftp> exit
> > 221 Goodbye!
> > #
> >
> > So I wonder if someone got anything SYSIII -> Net/TCP/IP related
> > which could help me in any way to get a SYSIII kernel capable of
> > TCP/IP and PTYs to get a telnetd up and running via SLIP is my
> > first goal.
> >
> > Regards,
> > Oliver
> > _______________________________________________
> > TUHS mailing list
> > TUHS at minnie.tuhs.org
> > https://minnie.tuhs.org/mailman/listinfo/tuhs
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151107/95db42d9/attachment.html>

From b4 at gewt.net  Sun Nov  8 08:07:29 2015
From: b4 at gewt.net (Cory Smelosky)
Date: Sat, 7 Nov 2015 14:07:29 -0800
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <CAC20D2NnLC2H=+8ZzpXEpgUqa+qW3JuFMLeWjL_Su9OBoHWBZQ@mail.gmail.com>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
 <CAC20D2NnLC2H=+8ZzpXEpgUqa+qW3JuFMLeWjL_Su9OBoHWBZQ@mail.gmail.com>
Message-ID: <5C15A998-5D10-47C7-888E-EADF42C1BFBE@gewt.net>



Sent from my iPhone

> On Nov 7, 2015, at 13:28, Clem Cole <clemc at ccc.com> wrote:
> 
> hmm...
> 
> 0.) adding pty's is pretty easy.  Just grab the BSD code and start hacking.  Grab the original version of Steven's book - he will talk to you through it in detail.   It's a two drivers, the control (ptyX) and the slave (ttypX) .   Having them in your system is handy anyway for a number of things besides networking (like the expect(1) program).
> 
> 1.) Larry's memory might be better than mine but I did not think streams shows up until System V.3.  I have an old PWB 3.0 (System III) manual and see no evidence of streams in it.   Given that Dennis did not create them until the V8 tty driver, and then later, the Summit guys use the streams interface for networking, I'm not surprised its not in System III.   So I think using streams is likely to be a dead end.
> 
> 2.) Perry Flinn, Bob Doolittle, and I spliced BSD sockets and the 4.2 stack into a System III -ish kernel for the Masscomp's RTU.  So it's definitely doable - although work.  The biggest issue is that the memory systems between BSD and System III are different.  So Rob Gurwitiz's old mbuf code will need to be hacked.  Definitely get a copy of Steven's, maybe the current BSD book and go for it.
> 
> 3.) One other thought if all you want to a solid IP/TCP network stack and can forgo the sockets API, then you might try to find the old BBN distribution for BSD 4.1 (Vax) -- which is what Joy started with[remember - Berkeley did not have contract for IP/TCP support for the Vax, BBN did - joy took the BBN code and redid it).  By definition its is a FOSS - because the US tax payer paid for it - although I'm not sure where to find the code these days (google in your friend).    Anyway, the BBN stack splices into the kernel with one small hook (a hack in nami - similar to the MIT ChaosNet stack) but otherwise things just look like devices:  i.e. open("/dev/tcp",...) or instead of socket(...)     There was a later version/distribution from BBN that included the BSD sockets code as an update for 4.2, but was the BBN guts (we actually used that version for the Stellar machine - splicing it into a System V3 based kernel after adding the BSD APIs).

I have 4.1a and c source I think.

> 
> 4.) It strikes me that it would be easiest of all to just take something like a $20-$30 "Wiznet" 5100 board from Sparkfun and interface it to the system either via serial or better if you have a parallel port.   Then run the IP/TCP stack externally.   This is what we do for Arduino's and other small micro controllers - the board is well documents and easy to talk too.  They have both RJ45 style and wireless too.   I have a hand full of them here and am pretty happy with them for what they provide.
> 
> The fact is that for the Masscomp system originally, we ran the IP/TCP stack in a coprocessor (in that case an 186) for realtime reasons (we did not want networking to interrupt the main processor which was 10MHz 68K).  But when we finally went to the '020 the processor was so much faster, we put the stack into the kernel and just use the co-processor as a very large buffer.   
> 
> Anyway - the idea is that the system hacking for a tcp stack become very small, just a driver.   You don't get things like UNIX domain sockets, but if what you want it telnet/ftp and the like - a cheap coprocessor like the Wiznet should  work fine.
> 
> Clem
> 
>> On Sat, Nov 7, 2015 at 2:20 PM, Larry McVoy <lm at mcvoy.com> wrote:
>> So this seems pretty tough, 16 bit machine and all.  If you were to get
>> it to work it would probably be with Lachman's STREAMS based TCP/IP.
>> No idea if that was open sourced.
>> 
>> On Sat, Nov 07, 2015 at 08:03:58PM +0100, Oliver Lehmann wrote:
>> > Hi,
>> >
>> > i have an old Z8001 based SysIII variant and I would love to have
>> > TCP/IP on it (SLIP first, later with a homebrew ethernet device).
>> >
>> > I wonder if someone ever saw TCP/IP available on a System III?
>> >
>> > I have lets say 90% of the kernel running on it as source
>> > available and I started digging in the available 4.2 BSD sources.
>> >
>> > It looks like there would be much to do to hack in TCP/IP on my
>> > own (no IPC, no Net, no PTY, no....).
>> >
>> > I got K5JB running (userland TCP/IP implementation) after I fixed
>> > some C code because the C Compiler available on the system is.....
>> > kinda limited.
>> >
>> > telnetd is of course not working as there are no pseudo-teletypes
>> > on this SYSIII. At least I got ping, echoping and ftpd up and
>> > running via SLIP
>> >
>> > (10.1.1.2 is my SysIII box:)
>> >
>> > # ping -c3 10.1.1.2
>> > PING 10.1.1.2 (10.1.1.2): 56 data bytes
>> > 64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms
>> > 64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms
>> > 64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms
>> >
>> > --- 10.1.1.2 ping statistics ---
>> > 3 packets transmitted, 3 packets received, 0.0% packet loss
>> > round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms
>> > # ftp 10.1.1.2
>> > Connected to 10.1.1.2.
>> > 220  FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991
>> > Name (10.1.1.2:root): test
>> > 331 Enter PASS command
>> > Password:
>> > 230 Logged in
>> > ftp> get sa.timer
>> > local: sa.timer remote: sa.timer
>> > 500 Unknown command
>> > 500 Unknown command
>> > 200 Port command okay
>> > 150 Opening data connection for RETR sa.timer
>> >   2571       0.53 KB/s
>> > 226 File sent OK
>> > 2571 bytes received in 00:05 (0.48 KB/s)
>> > ftp> get wega
>> > local: wega remote: wega
>> > 200 Port command okay
>> > 150 Opening data connection for RETR wega
>> >  98723       0.51 KB/s
>> > 226 File sent OK
>> > 98723 bytes received in 03:05 (0.51 KB/s)
>> > ftp> exit
>> > 221 Goodbye!
>> > #
>> >
>> > So I wonder if someone got anything SYSIII -> Net/TCP/IP related
>> > which could help me in any way to get a SYSIII kernel capable of
>> > TCP/IP and PTYs to get a telnetd up and running via SLIP is my
>> > first goal.
>> >
>> > Regards,
>> > Oliver
>> > _______________________________________________
>> > TUHS mailing list
>> > TUHS at minnie.tuhs.org
>> > https://minnie.tuhs.org/mailman/listinfo/tuhs
>> 
>> --
>> ---
>> Larry McVoy                  lm at mcvoy.com             http://www.mcvoy.com/lm
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151107/29e91783/attachment.html>

From lehmann at ans-netz.de  Sun Nov  8 08:13:38 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Sat, 07 Nov 2015 23:13:38 +0100
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <CAC20D2NnLC2H=+8ZzpXEpgUqa+qW3JuFMLeWjL_Su9OBoHWBZQ@mail.gmail.com>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
 <CAC20D2NnLC2H=+8ZzpXEpgUqa+qW3JuFMLeWjL_Su9OBoHWBZQ@mail.gmail.com>
Message-ID: <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net>


Clem Cole <clemc at ccc.com> wrote:

> 0.) adding pty's is pretty easy.  Just grab the BSD code and start
> hacking.  Grab the original version of Steven's book - he will talk to you
> through it in detail.   It's a two drivers, the control (ptyX) and the
> slave (ttypX) .   Having them in your system is handy anyway for a number
> of things besides networking (like the expect(1) program).

Yeah.. having pty would be good anyway but the C compiler is so limited
that it would be just some sort of rewrite instead of "porting"...

It is basically a pcc as of 1981 with whatever Zilog hacked into it
additionally. I once tried to get a current pcc onto the system but...
yeah... I guess I lack skill ;)
- the new PCC would need to create Z8001 ASM code.... something I lack skill.
- an optimizer... haha...  no way I could  even optimize Z8001 ASM code by
   hand ;)
- if a new linker is needed - how to create Zilogs s.out format...
- I guess I would need to recompile the whole kernel with this new compiler
   to have every object work "together" - but I still lack some sources (most
of them I "retranslated" from disassembled object files to C code - but 2 or
3 are just are too hard to retranslate)
I also had a look at the C-Compiler which comes with Plexis SYSIII (which
is available as source somewhere in the WWW) but this is a compiler capable
of non-segmented executables (one 64K segment adressable) only but I need a
Compiler creating segmented executables (128 64k segments accessable = 8MB
address space)

So I'm stuck with this '81ish C compiler - ok - but who said that it would
be an easy task ;)


> 4.) It strikes me that it would be easiest of all to just take something
> like a $20-$30 "Wiznet" 5100 board from Sparkfun and interface it to the
> system either via serial or better if you have a parallel port.   Then run
> the IP/TCP stack externally.   This is what we do for Arduino's and other
> small micro controllers - the board is well documents and easy to talk
> too.  They have both RJ45 style and wireless too.   I have a hand full of
> them here and am pretty happy with them for what they provide.

I was thinking about the same. I have connectors on the board where I have
access to the System complete bus. They where used for things like a RTC,
system memory, Tape controller and so on. So I could build up a board using
Wiznet and thats it. So no need of a PIO or SIO which would things kinda slow
anyway... Wiznet would be of course faster as the Z8001 would do in any way.

But what comes to my mind with that solution... I would need a kernel part
which interacts with the wiznet chip (driver). I can not directly access
the wiznet from userland which would be non privileged code which is not
allowed to execute privileged instructions (raises a trap).
On the userland side...
I probably have to "rewrite" all the stuff which comes with BSD and uses
libnet. Pr is there something like a compatibility layer which provides
a library looking like a libnet API but internally "redirects" everything
to the wiznet (via the to-be-written-kernel-driver) so I wouldn't need to
reinvent all the userland tools as well?

Oliver


From dfawcus+lists-tuhs at employees.org  Sun Nov  8 15:10:28 2015
From: dfawcus+lists-tuhs at employees.org (Derek Fawcus)
Date: Sun, 8 Nov 2015 05:10:28 +0000
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
 <CAC20D2NnLC2H=+8ZzpXEpgUqa+qW3JuFMLeWjL_Su9OBoHWBZQ@mail.gmail.com>
 <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net>
Message-ID: <20151108051028.GA32246@cowbell.employees.org>

On Sat, Nov 07, 2015 at 11:13:38pm +0100, Oliver Lehmann wrote:
> 
> It is basically a pcc as of 1981 with whatever Zilog hacked into it
> additionally. I once tried to get a current pcc onto the system but...
> yeah... I guess I lack skill ;)
> - the new PCC would need to create Z8001 ASM code.... something I lack skill.
> - an optimizer... haha...  no way I could  even optimize Z8001 ASM code by
>    hand ;)
> - if a new linker is needed - how to create Zilogs s.out format...
> - I guess I would need to recompile the whole kernel with this new compiler
>    to have every object work "together" - but I still lack some sources (most
> of them I "retranslated" from disassembled object files to C code - but 2 or
> 3 are just are too hard to retranslate)
> I also had a look at the C-Compiler which comes with Plexis SYSIII (which
> is available as source somewhere in the WWW) but this is a compiler capable
> of non-segmented executables (one 64K segment adressable) only but I need a
> Compiler creating segmented executables (128 64k segments accessable = 8MB
> address space)

Older versions of gcc (around 3.3/3.4) supported the z8000 family,  so you
could try using it to make things easier.  Have a look here:
  http://www.z80ne.com/m20/sections/download/z8kgcc/z8kgcc.html
which seems to be a version supporting segments - the '-mz8001' switch.

DF


From downing.nick at gmail.com  Sun Nov  8 15:39:43 2015
From: downing.nick at gmail.com (Nick Downing)
Date: Sun, 8 Nov 2015 16:39:43 +1100
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <20151108051028.GA32246@cowbell.employees.org>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
 <CAC20D2NnLC2H=+8ZzpXEpgUqa+qW3JuFMLeWjL_Su9OBoHWBZQ@mail.gmail.com>
 <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net>
 <20151108051028.GA32246@cowbell.employees.org>
Message-ID: <CAH1jEzbzpuwzncuEFQMHHD-pHHk_4SHre2PY5BPZNpY_HAgXCw@mail.gmail.com>

I think you might get better mileage by just trying to port 2.11BSD over to
your Z8001 device, since it is a self contained system, no interface
hacking will be needed, just porting. You will have to hack in the device
drivers for your disks, ports etc, and create a bootstrap and do a little
assembly hacking for the memory management, the context switches, exec()
and system calls, BUT you have all this in your Sys3 source anyway. I think
it would be easier and  cleaner to do this than try to transplant a lot of
gory internals.

My own experience in this was I wanted TCP/IP running on a Z180 machine
(1MB RAM but 64k address space with a very basic MMU), so I started with a
primitive unix called UZI see http://www.dougbraun.com/oldstuff and hacked
in sockets from NOS see http://www.qsl.net/ah6rh/am-radio/packet/jnos.html
and honestly it took months, was incredibly tedious and bug-prone, very
detailed interfacing work and restructuring to get things like socket
timeouts to work, expose functionality via system calls and so on... I
reached a point where I was medium satisfied but then my laptop got stolen
and I had to revert to month-old backup and decided to throw it away and
start again. I also did not finish the 2.11BSD port but I got as far as
making 2.11BSD cross compile from a linux system, was going to drop in the
Z180 cross toolchain as the next step, but for whatever reason put it
aside. I am happy to pass on what I have.

Nick
On 08/11/2015 4:17 PM, "Derek Fawcus" <dfawcus+lists-tuhs at employees.org>
wrote:

> On Sat, Nov 07, 2015 at 11:13:38pm +0100, Oliver Lehmann wrote:
> >
> > It is basically a pcc as of 1981 with whatever Zilog hacked into it
> > additionally. I once tried to get a current pcc onto the system but...
> > yeah... I guess I lack skill ;)
> > - the new PCC would need to create Z8001 ASM code.... something I lack
> skill.
> > - an optimizer... haha...  no way I could  even optimize Z8001 ASM code
> by
> >    hand ;)
> > - if a new linker is needed - how to create Zilogs s.out format...
> > - I guess I would need to recompile the whole kernel with this new
> compiler
> >    to have every object work "together" - but I still lack some sources
> (most
> > of them I "retranslated" from disassembled object files to C code - but
> 2 or
> > 3 are just are too hard to retranslate)
> > I also had a look at the C-Compiler which comes with Plexis SYSIII (which
> > is available as source somewhere in the WWW) but this is a compiler
> capable
> > of non-segmented executables (one 64K segment adressable) only but I
> need a
> > Compiler creating segmented executables (128 64k segments accessable =
> 8MB
> > address space)
>
> Older versions of gcc (around 3.3/3.4) supported the z8000 family,  so you
> could try using it to make things easier.  Have a look here:
>   http://www.z80ne.com/m20/sections/download/z8kgcc/z8kgcc.html
> which seems to be a version supporting segments - the '-mz8001' switch.
>
> DF
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151108/c7caac2f/attachment.html>

From lm at mcvoy.com  Sun Nov  8 17:11:02 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Sat, 7 Nov 2015 23:11:02 -0800
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <1C0DB3B7-988D-435F-A590-6C0AB14249A3@gewt.net>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
 <1C0DB3B7-988D-435F-A590-6C0AB14249A3@gewt.net>
Message-ID: <20151108071102.GA7290@mcvoy.com>

Just getting back to email (spent the day taking pictures at a hockey
tournament).  

Others have replied, no STREAMS System III (that's what Sys 5 did,
Dennis did "streams", they are not the same, Dennis' stuff was sane,
STREAMS was not, he and I talked a bit about that - which was classic
Dennis because I was nobody, fresh out of grad school porting a STREAMS
based TCP/IP stack and I felt it was weird so I reached out to dmr and
he of course replied in depth.)

I tend to agree with whoever said 2.11BSD.  If you have to do 16 bit and
you want all the goodies, 2.11BSD is where you want to be.  Back porting
all that stuff to System III really makes me ask the question of "why?".
Why bother?  I get that it could be like a mountain you want to climb,
if that's the case, cool.  But I never saw System III as much of a cool
mountain.  I think there were some cool parts, didn't the PWB and DWB
come form System III?  If so, those where the things I'd want to have
ported forward.  Other than that, what's the System III attraction?

If you actually have a need to have this work and have networking then
once again Clem has the right idea, grab one of those boards.  (And once
again I want to meet Clem in person, lot of love for the Masscomp work
and all his stories).

--lm

On Sat, Nov 07, 2015 at 12:27:27PM -0800, Cory Smelosky wrote:
> Any ideas if any of this would work on Sys III for VAX?
> 
> (Or the technically opened PDP-11 that includes VAX)
> 
> Sent from my iPhone
> 
> > On Nov 7, 2015, at 11:20, Larry McVoy <lm at mcvoy.com> wrote:
> > 
> > So this seems pretty tough, 16 bit machine and all.  If you were to get
> > it to work it would probably be with Lachman's STREAMS based TCP/IP.
> > No idea if that was open sourced.
> > 
> >> On Sat, Nov 07, 2015 at 08:03:58PM +0100, Oliver Lehmann wrote:
> >> Hi,
> >> 
> >> i have an old Z8001 based SysIII variant and I would love to have
> >> TCP/IP on it (SLIP first, later with a homebrew ethernet device).
> >> 
> >> I wonder if someone ever saw TCP/IP available on a System III?
> >> 
> >> I have lets say 90% of the kernel running on it as source
> >> available and I started digging in the available 4.2 BSD sources.
> >> 
> >> It looks like there would be much to do to hack in TCP/IP on my
> >> own (no IPC, no Net, no PTY, no....).
> >> 
> >> I got K5JB running (userland TCP/IP implementation) after I fixed
> >> some C code because the C Compiler available on the system is.....
> >> kinda limited.
> >> 
> >> telnetd is of course not working as there are no pseudo-teletypes
> >> on this SYSIII. At least I got ping, echoping and ftpd up and
> >> running via SLIP
> >> 
> >> (10.1.1.2 is my SysIII box:)
> >> 
> >> # ping -c3 10.1.1.2
> >> PING 10.1.1.2 (10.1.1.2): 56 data bytes
> >> 64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms
> >> 64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms
> >> 64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms
> >> 
> >> --- 10.1.1.2 ping statistics ---
> >> 3 packets transmitted, 3 packets received, 0.0% packet loss
> >> round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms
> >> # ftp 10.1.1.2
> >> Connected to 10.1.1.2.
> >> 220  FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991
> >> Name (10.1.1.2:root): test
> >> 331 Enter PASS command
> >> Password:
> >> 230 Logged in
> >> ftp> get sa.timer
> >> local: sa.timer remote: sa.timer
> >> 500 Unknown command
> >> 500 Unknown command
> >> 200 Port command okay
> >> 150 Opening data connection for RETR sa.timer
> >>  2571       0.53 KB/s
> >> 226 File sent OK
> >> 2571 bytes received in 00:05 (0.48 KB/s)
> >> ftp> get wega
> >> local: wega remote: wega
> >> 200 Port command okay
> >> 150 Opening data connection for RETR wega
> >> 98723       0.51 KB/s
> >> 226 File sent OK
> >> 98723 bytes received in 03:05 (0.51 KB/s)
> >> ftp> exit
> >> 221 Goodbye!
> >> #
> >> 
> >> So I wonder if someone got anything SYSIII -> Net/TCP/IP related
> >> which could help me in any way to get a SYSIII kernel capable of
> >> TCP/IP and PTYs to get a telnetd up and running via SLIP is my
> >> first goal.
> >> 
> >> Regards,
> >> Oliver
> >> _______________________________________________
> >> TUHS mailing list
> >> TUHS at minnie.tuhs.org
> >> https://minnie.tuhs.org/mailman/listinfo/tuhs
> > 
> > -- 
> > ---
> > Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 
> > _______________________________________________
> > TUHS mailing list
> > TUHS at minnie.tuhs.org
> > https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From cowan at mercury.ccil.org  Sun Nov  8 17:22:30 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Sun, 8 Nov 2015 02:22:30 -0500
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <20151108071102.GA7290@mcvoy.com>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
 <1C0DB3B7-988D-435F-A590-6C0AB14249A3@gewt.net>
 <20151108071102.GA7290@mcvoy.com>
Message-ID: <20151108072230.GA8436@mercury.ccil.org>

Larry McVoy scripsit:

> he and I talked a bit about that - which was classic
> Dennis because I was nobody, fresh out of grad school porting a STREAMS
> based TCP/IP stack and I felt it was weird so I reached out to dmr and
> he of course replied in depth.)

Bohr and Feynman at Los Alamos, to put it Star Trek-ly.

> I think there were some cool parts, didn't the PWB and DWB
> come form System III?  

Vice versa.  PWB began between the Sixth and Seventh Edition, but didn't
reach the Unix mainline (as it was then) until System III.  There was a
second PWB release branched from the Seventh Edition.

> Other than that, what's the System III attraction?

I tend to agree: a thoroughly vanilla release.


-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
I could dance with you till the cows come home.  On second thought,
I'd rather dance with the cows when you come home.
        --Rufus T. Firefly


From b4 at gewt.net  Sun Nov  8 18:20:27 2015
From: b4 at gewt.net (Cory Smelosky)
Date: Sun, 8 Nov 2015 00:20:27 -0800 (PST)
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <20151108072230.GA8436@mercury.ccil.org>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
 <1C0DB3B7-988D-435F-A590-6C0AB14249A3@gewt.net>
 <20151108071102.GA7290@mcvoy.com> <20151108072230.GA8436@mercury.ccil.org>
Message-ID: <alpine.BSF.2.20.1511080019560.42120@meaghan.gimme-sympathy.org>

On Sun, 8 Nov 2015, John Cowan wrote:

> Larry McVoy scripsit:
>
>> he and I talked a bit about that - which was classic
>> Dennis because I was nobody, fresh out of grad school porting a STREAMS
>> based TCP/IP stack and I felt it was weird so I reached out to dmr and
>> he of course replied in depth.)
>
> Bohr and Feynman at Los Alamos, to put it Star Trek-ly.
>
>> I think there were some cool parts, didn't the PWB and DWB
>> come form System III?
>
> Vice versa.  PWB began between the Sixth and Seventh Edition, but didn't
> reach the Unix mainline (as it was then) until System III.  There was a
> second PWB release branched from the Seventh Edition.
>
>> Other than that, what's the System III attraction?
>
> I tend to agree: a thoroughly vanilla release.
>

What about SysV for PDP-11? ;D

>
>

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects


From lehmann at ans-netz.de  Sun Nov  8 19:40:16 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Sun, 08 Nov 2015 10:40:16 +0100
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <CAH1jEzbzpuwzncuEFQMHHD-pHHk_4SHre2PY5BPZNpY_HAgXCw@mail.gmail.com>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
 <CAC20D2NnLC2H=+8ZzpXEpgUqa+qW3JuFMLeWjL_Su9OBoHWBZQ@mail.gmail.com>
 <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net>
 <20151108051028.GA32246@cowbell.employees.org>
 <CAH1jEzbzpuwzncuEFQMHHD-pHHk_4SHre2PY5BPZNpY_HAgXCw@mail.gmail.com>
Message-ID: <20151108104016.Horde.RqrbT03f_72g8VsxukB9eQv@avocado.salatschuessel.net>

Yeah,

Nick Downing <downing.nick at gmail.com> wrote:

> I think you might get better mileage by just trying to port 2.11BSD over to
> your Z8001 device, since it is a self contained system, no interface
> hacking will be needed, just porting.

would be of course a way to do, but then it is just another BSD installation.
I could also run on every other hardware. And being able to crosscompile which
would be lets say - mandatory - to not transfer files via 9600baud every
single time  would involve getting a compiler create Assembler code. And of
course the 2.11 BSD need to understand and execute Zilogs s.out format as
I have a bunch of software (involving the Assembler) where I have zero sources
for.
I have once tried to port the old gcc as well as - I forgot the name - some
other sort of C compiler with Z8001 support - but they all lack the s.out
format support and have a sligthly different ASM syntax than the Assembler
I have supports. Missing features like extended math functions and so on.....

But you might be right... porting a "complete" system like 2.11 BSD might be
easier than extracting every little piece just to find out that another piece
needs to be extracted as well... wich probably makes you end up with a BSD
kernel anyway ;)

Regards, Oliver



From lehmann at ans-netz.de  Sun Nov  8 23:38:17 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Sun, 08 Nov 2015 14:38:17 +0100
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <CAH1jEzbzpuwzncuEFQMHHD-pHHk_4SHre2PY5BPZNpY_HAgXCw@mail.gmail.com>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
 <CAC20D2NnLC2H=+8ZzpXEpgUqa+qW3JuFMLeWjL_Su9OBoHWBZQ@mail.gmail.com>
 <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net>
 <20151108051028.GA32246@cowbell.employees.org>
 <CAH1jEzbzpuwzncuEFQMHHD-pHHk_4SHre2PY5BPZNpY_HAgXCw@mail.gmail.com>
Message-ID: <20151108143817.Horde.tlWgdF0OWmzmg-kXXO-AxUO@avocado.salatschuessel.net>


Nick Downing <downing.nick at gmail.com> wrote:

> I think you might get better mileage by just trying to port 2.11BSD over to
> your Z8001 device, since it is a self contained system, no interface
> hacking will be needed, just porting.

By the way - why do you think 2.11 BSD would be better to port instead of the
original 4.3 BSD? The system has no 64KB addressing limitation. It can adress
up to 128 64KB segments (=8MB). I mean, on a first look, it looks like 2.11BSD
contains a lot more Assembler Code I would need to move to Z8001 ASM mnemonics
as 4.3 does?!


From dave at horsfall.org  Mon Nov  9 00:45:18 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 9 Nov 2015 01:45:18 +1100 (EST)
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <20151108071102.GA7290@mcvoy.com>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
 <1C0DB3B7-988D-435F-A590-6C0AB14249A3@gewt.net>
 <20151108071102.GA7290@mcvoy.com>
Message-ID: <alpine.BSF.2.11.1511090115510.57799@aneurin.horsfall.org>

On Sat, 7 Nov 2015, Larry McVoy wrote:

> Just getting back to email (spent the day taking pictures at a hockey 
> tournament).

A typical Canadian :-)  There is only one game, and it's called Cricket; 
where else can you see a sport that can take five days, and ends up in a 
draw?

[...]

> I tend to agree with whoever said 2.11BSD.  If you have to do 16 bit and 
> you want all the goodies, 2.11BSD is where you want to be.  Back porting 
> all that stuff to System III really makes me ask the question of "why?". 
> Why bother?  I get that it could be like a mountain you want to climb, 
> if that's the case, cool.  But I never saw System III as much of a cool 
> mountain.  I think there were some cool parts, didn't the PWB and DWB 
> come form System III?  If so, those where the things I'd want to have 
> ported forward.  Other than that, what's the System III attraction?

I thought PWB (makers of "make") came from Harvard?  Other than that, Sys 
III/V was presented by suits; enough said.  System III was, well, what 
System V was going to be like...  It never had TCP/IP, only BNU (i.e. UUCP 
with a jazzed-up name).

Gahh...  I still have flash-backs to that awful "cu" command,

Perhaps it's my experience with Lionel Singer et al, but I really learned
to hate SysIII/V...

> If you actually have a need to have this work and have networking then 
> once again Clem has the right idea, grab one of those boards.  (And once 
> again I want to meet Clem in person, lot of love for the Masscomp work 
> and all his stories).

Indeed.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From jnc at mercury.lcs.mit.edu  Mon Nov  9 01:52:53 2015
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun,  8 Nov 2015 10:52:53 -0500 (EST)
Subject: [TUHS] System III - TCP/IP
Message-ID: <20151108155253.0205318C0F4@mercury.lcs.mit.edu>

    > From: Dave Horsfall <dave at horsfall.org>

    > I thought PWB (makers of "make") came from Harvard? 

PWB? As in "Programmer's Work Bench"? The OS part of that came straight out
of Bell - see pg. 266 in the first Unix BSTJ issue. Not sure about all the
applications (well, SCCS came from Bell).

	Noel


From usotsuki at buric.co  Mon Nov  9 03:04:14 2015
From: usotsuki at buric.co (Steve Nickolas)
Date: Sun, 8 Nov 2015 18:04:14 +0100 (CET)
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <alpine.BSF.2.11.1511090115510.57799@aneurin.horsfall.org>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
 <1C0DB3B7-988D-435F-A590-6C0AB14249A3@gewt.net>
 <20151108071102.GA7290@mcvoy.com>
 <alpine.BSF.2.11.1511090115510.57799@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.02.1511081804040.42072@frieza.hoshinet.org>

On Mon, 9 Nov 2015, Dave Horsfall wrote:

> On Sat, 7 Nov 2015, Larry McVoy wrote:
>
>> Just getting back to email (spent the day taking pictures at a hockey
>> tournament).
>
> A typical Canadian :-)  There is only one game, and it's called Cricket;
> where else can you see a sport that can take five days, and ends up in a
> draw?

Dragon Ball Z? *shot*

-uso.


From downing.nick at gmail.com  Mon Nov  9 10:21:18 2015
From: downing.nick at gmail.com (Nick Downing)
Date: Mon, 9 Nov 2015 11:21:18 +1100
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <20151108143817.Horde.tlWgdF0OWmzmg-kXXO-AxUO@avocado.salatschuessel.net>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
 <CAC20D2NnLC2H=+8ZzpXEpgUqa+qW3JuFMLeWjL_Su9OBoHWBZQ@mail.gmail.com>
 <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net>
 <20151108051028.GA32246@cowbell.employees.org>
 <CAH1jEzbzpuwzncuEFQMHHD-pHHk_4SHre2PY5BPZNpY_HAgXCw@mail.gmail.com>
 <20151108143817.Horde.tlWgdF0OWmzmg-kXXO-AxUO@avocado.salatschuessel.net>
Message-ID: <CAH1jEzarQAW4ucfP81RRhP0pgkFiHiiMAH9F=a6DsEEiU0Uy=Q@mail.gmail.com>

Although the Z8000 has segments, they will require special code to
access, and so you will have to regard it as a 16 bit CPU from the
viewpoint of running ordinary unix kernel/applications.

You can most likely implement a split I/D architecture by having code
execute out of a different segment than data, although I haven't
checked the datasheet so I don't know for sure if this is possible.
You can also do a few other things -- you could for example make mbufs
and bufs reside in different segments and wrap all kernel accesses to
them in macros, which would free up significant space in the main
kernel data segment. Or you could do what I did for the Z180
implementation, (the first try -- UZI / NOS derivative, not the
proposed 2.11BSD port), which I somewhat borrowed from the IAR's Z180
C compiler -- the calling convention allows for a segment switch on
function call and return, so you can have large multi-segment
executables.

In my implementation I had a 768 kbyte RAM disk which was formatted
unix style (not BSD style unfortunately), but I had an alignment
routine which put executable files into contiguous blocks on 4kbyte
boundaries (normally the filesystem had 1kbyte blocks), and I created
a mapping table, and I revised the IAR compiler's calling stubs to
allow executing multi segment executables direct from RAM disk. This
would work in your system with minor porting, but unfortunately it's
not implemented in 2.11BSD, it's in my earlier code. You're welcome to
it, though.

The kernel and some of the utilities in 2.11BSD are large enough to
require split I/D, I didn't have that, but proposed to get around it
by using multi-segmented executables (my memory map allowed for 4
kbytes of stubs and utility code/data, 56 kbytes of data and 4 kbytes
of the currently visible code segment). So you will have to either
implement split I/D or multi-segmented executables, it doesn't matter
which. Check how your sys3 system handles this, because you will
probably want to take as much of the assembly code from the sys3
system as possible.

So given you're implementing a 16 bit system, you should definitely go
for 2.11BSD, it's simply the most advanced and the only reasonable
unix system out there that executes in 64 kbytes. You can look at
4.3BSD, personally I looked at a later BSD and I discovered that the
network stack is significantly cut down in 2.11BSD, and for good
reasons. For example it does not implement syn cookies (protection
against TCP SYN DOS attacks), presumably because this required some
largeish kernel tables. You don't need the complexity, you want
2.11BSD I think.

Nick

On Mon, Nov 9, 2015 at 12:38 AM, Oliver Lehmann <lehmann at ans-netz.de> wrote:
>
> Nick Downing <downing.nick at gmail.com> wrote:
>
>> I think you might get better mileage by just trying to port 2.11BSD over
>> to
>> your Z8001 device, since it is a self contained system, no interface
>> hacking will be needed, just porting.
>
>
> By the way - why do you think 2.11 BSD would be better to port instead of
> the
> original 4.3 BSD? The system has no 64KB addressing limitation. It can
> adress
> up to 128 64KB segments (=8MB). I mean, on a first look, it looks like
> 2.11BSD
> contains a lot more Assembler Code I would need to move to Z8001 ASM
> mnemonics
> as 4.3 does?!
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From downing.nick at gmail.com  Mon Nov  9 10:31:43 2015
From: downing.nick at gmail.com (Nick Downing)
Date: Mon, 9 Nov 2015 11:31:43 +1100
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <20151108143817.Horde.tlWgdF0OWmzmg-kXXO-AxUO@avocado.salatschuessel.net>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
 <CAC20D2NnLC2H=+8ZzpXEpgUqa+qW3JuFMLeWjL_Su9OBoHWBZQ@mail.gmail.com>
 <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net>
 <20151108051028.GA32246@cowbell.employees.org>
 <CAH1jEzbzpuwzncuEFQMHHD-pHHk_4SHre2PY5BPZNpY_HAgXCw@mail.gmail.com>
 <20151108143817.Horde.tlWgdF0OWmzmg-kXXO-AxUO@avocado.salatschuessel.net>
Message-ID: <CAH1jEza76_XTKXQPjjDuXS9t=bNVZCZzMAWddMcy0gRkQF9DkQ@mail.gmail.com>

By the way, there's no reason you can't use your existing Zilog
toolchain. You can just modify the makefiles that come with 2.11BSD to
run the Zilog tools. Or another option might be to write a compiler
driver that acts like "cc" and invokes the Zilog tools as
subprocesses, you have the source for 2.11BSD "cc" so this shouldn't
be too hard to do. Whatever naming convention the Zilog compiler uses,
you could rename the object files to ".o" and the 2.11BSD build system
would work largely unchanged. The most tricky part will be creating
the a.out executables, which are in the simplest case a header of
maybe 18 bytes (depends slightly on the magic number of the executable
since there were a few different compatible versions) followed by the
code and data segments followed by relocation records. To do this, I
am pretty sure I created my own linker, or modified the unix linker
(cannot remember exactly) in order to read the object files from the
IAR Z180 assembler (and I think these were in S-record format that you
mentioned) and create the a.out executables, I also had an extended
a.out format for the large multi-segment executables (including the
kernel), in which I arranged the code into 4 kbyte segments using a
first-fit algorithm. Again I'm happy to give you whatever I have on
this.
Nick


On Mon, Nov 9, 2015 at 12:38 AM, Oliver Lehmann <lehmann at ans-netz.de> wrote:
>
> Nick Downing <downing.nick at gmail.com> wrote:
>
>> I think you might get better mileage by just trying to port 2.11BSD over
>> to
>> your Z8001 device, since it is a self contained system, no interface
>> hacking will be needed, just porting.
>
>
> By the way - why do you think 2.11 BSD would be better to port instead of
> the
> original 4.3 BSD? The system has no 64KB addressing limitation. It can
> adress
> up to 128 64KB segments (=8MB). I mean, on a first look, it looks like
> 2.11BSD
> contains a lot more Assembler Code I would need to move to Z8001 ASM
> mnemonics
> as 4.3 does?!
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From doug at cs.dartmouth.edu  Mon Nov  9 11:39:12 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sun, 08 Nov 2015 20:39:12 -0500
Subject: [TUHS] PWB contributions
Message-ID: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>

>> I thought PWB (makers of "make") came from Harvard?

> PWB ...  came straight out of Bell. Not sure about all the
> applications (well, SCCS came from Bell).

PWB did not create make; Stu Feldman did it in research.
PWB did make SCCS. I believe it also originated cico,
find and eval. Probably more, too, but I can't reliably
separate PWB's other contributions from USG's.

Doug


From cowan at mercury.ccil.org  Mon Nov  9 11:48:12 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Sun, 8 Nov 2015 20:48:12 -0500
Subject: [TUHS] PWB contributions
In-Reply-To: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
Message-ID: <20151109014812.GB4546@mercury.ccil.org>

Doug McIlroy scripsit:

> PWB did not create make; Stu Feldman did it in research.

Which is why, according to Google folklore, the desktop he
was set up with on the first day did not have a TAB key.

> PWB did make SCCS. I believe it also originated cico,
> find and eval. 

The Mashey shell, obviously, and -mm.  Wikipedia claims that
cpio, expr, xargs, yacc, and lex first appeared outside
the Bell Labs boundary in the PWB release, though at least
the last two were certainly not PWB-specific.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
If you understand, things are just as they are.
if you do not understand, things are just as they are.


From clemc at ccc.com  Mon Nov  9 12:12:13 2015
From: clemc at ccc.com (Clement T. Cole)
Date: Sun, 8 Nov 2015 21:12:13 -0500
Subject: [TUHS] PWB contributions
In-Reply-To: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
Message-ID: <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>

Doug

Eric Shienbrood originally wrote more(1) at UCB when he came as a grad student.    It was based on functionality from ITS that he as used to having at MIT.   Summit wrote a similar program with the same called page(1) and I'm fairly sure it was few years after Eric's program. Btw page(1) which did not have the same functionality (no termcap or in there case terminfo yet).  Less(1) would show up a few years later and replace them both.  

Clem

Sent from my iPad

On Nov 8, 2015, at 8:39 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

>>> I thought PWB (makers of "make") came from Harvard?
> 
>> PWB ...  came straight out of Bell. Not sure about all the
>> applications (well, SCCS came from Bell).
> 
> PWB did not create make; Stu Feldman did it in research.
> PWB did make SCCS. I believe it also originated cico,
> find and eval. Probably more, too, but I can't reliably
> separate PWB's other contributions from USG's.
> 
> Doug
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From doug at cs.dartmouth.edu  Mon Nov  9 12:14:32 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sun, 08 Nov 2015 21:14:32 -0500
Subject: [TUHS] PWB contributions
Message-ID: <201511090214.tA92EW8h006854@coolidge.cs.Dartmouth.EDU>

> cpio, expr, xargs, yacc, and lex first appeared outside
> the Bell Labs boundary in the PWB release

This gently corrects a statement in my posting: the name
of one of the PWB-originated programs is expr, not eval.

Doug


From cowan at mercury.ccil.org  Mon Nov  9 12:32:14 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Sun, 8 Nov 2015 21:32:14 -0500
Subject: [TUHS] PWB contributions
In-Reply-To: <201511090214.tA92EW8h006854@coolidge.cs.Dartmouth.EDU>
References: <201511090214.tA92EW8h006854@coolidge.cs.Dartmouth.EDU>
Message-ID: <20151109023214.GB19195@mercury.ccil.org>

Doug McIlroy scripsit:

> This gently corrects a statement in my posting: the name
> of one of the PWB-originated programs is expr, not eval.

Not intentionally!  I figured that eval was some part of the
RJE system (core to PWB, of course) that I had never heard of.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
It's the old, old story.  Droid meets droid.  Droid becomes chameleon.
Droid loses chameleon, chameleon becomes blob, droid gets blob back
again.  It's a classic tale.  --Kryten, Red Dwarf


From treese at acm.org  Mon Nov  9 12:58:07 2015
From: treese at acm.org (Win Treese)
Date: Sun, 8 Nov 2015 21:58:07 -0500
Subject: [TUHS] PWB contributions
In-Reply-To: <52F63A89-B372-409E-9296-BAA4CBF848AF@acm.org>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
 <52F63A89-B372-409E-9296-BAA4CBF848AF@acm.org>
Message-ID: <D9D5CFE3-F9F1-4A70-844C-210B7BD84575@acm.org>


Of course, as soon as I sent that, I found Dan Halbert’s version of things
at http://www.danhalbert.org/more.html

For what that’s worth.

 - Win

> On Nov 8, 2015, at 9:54 PM, Win Treese <treese at acm.org> wrote:
> 
> 
> Clem, 
> 
> In trying to check on some memories of mine, I came across your answer on
> Quora about "What is the difference between less and cat command?”, in which
> you mention that Wikipedia had it wrong about Dan Halbert writing more(1).
> 
> What Dan did tell me many years ago is that he wrote a program called “less”
> when he was at Berkeley as a near-parody on more(1). Its notable feature was
> that it went backwards through the file, displaying in the opposite direction.
> 
> This, of course, had nothing to do with what we now know as less(1), and that code
> is probably lost to history.
> 
> - Win
> 
>> On Nov 8, 2015, at 9:12 PM, Clement T. Cole <clemc at ccc.com> wrote:
>> 
>> Doug
>> 
>> Eric Shienbrood originally wrote more(1) at UCB when he came as a grad student.    It was based on functionality from ITS that he as used to having at MIT.   Summit wrote a similar program with the same called page(1) and I'm fairly sure it was few years after Eric's program. Btw page(1) which did not have the same functionality (no termcap or in there case terminfo yet).  Less(1) would show up a few years later and replace them both.  
>> 
>> Clem
>> 
>> Sent from my iPad
>> 
>> On Nov 8, 2015, at 8:39 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>> 
>>>>> I thought PWB (makers of "make") came from Harvard?
>>> 
>>>> PWB ...  came straight out of Bell. Not sure about all the
>>>> applications (well, SCCS came from Bell).
>>> 
>>> PWB did not create make; Stu Feldman did it in research.
>>> PWB did make SCCS. I believe it also originated cico,
>>> find and eval. Probably more, too, but I can't reliably
>>> separate PWB's other contributions from USG's.
>>> 
>>> Doug
>>> _______________________________________________
>>> TUHS mailing list
>>> TUHS at minnie.tuhs.org
>>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
> 



From treese at acm.org  Mon Nov  9 12:54:57 2015
From: treese at acm.org (Win Treese)
Date: Sun, 8 Nov 2015 21:54:57 -0500
Subject: [TUHS] PWB contributions
In-Reply-To: <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
Message-ID: <52F63A89-B372-409E-9296-BAA4CBF848AF@acm.org>


Clem, 

In trying to check on some memories of mine, I came across your answer on
Quora about "What is the difference between less and cat command?”, in which
you mention that Wikipedia had it wrong about Dan Halbert writing more(1).

What Dan did tell me many years ago is that he wrote a program called “less”
when he was at Berkeley as a near-parody on more(1). Its notable feature was
that it went backwards through the file, displaying in the opposite direction.

This, of course, had nothing to do with what we now know as less(1), and that code
is probably lost to history.

 - Win

> On Nov 8, 2015, at 9:12 PM, Clement T. Cole <clemc at ccc.com> wrote:
> 
> Doug
> 
> Eric Shienbrood originally wrote more(1) at UCB when he came as a grad student.    It was based on functionality from ITS that he as used to having at MIT.   Summit wrote a similar program with the same called page(1) and I'm fairly sure it was few years after Eric's program. Btw page(1) which did not have the same functionality (no termcap or in there case terminfo yet).  Less(1) would show up a few years later and replace them both.  
> 
> Clem
> 
> Sent from my iPad
> 
> On Nov 8, 2015, at 8:39 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> 
>>>> I thought PWB (makers of "make") came from Harvard?
>> 
>>> PWB ...  came straight out of Bell. Not sure about all the
>>> applications (well, SCCS came from Bell).
>> 
>> PWB did not create make; Stu Feldman did it in research.
>> PWB did make SCCS. I believe it also originated cico,
>> find and eval. Probably more, too, but I can't reliably
>> separate PWB's other contributions from USG's.
>> 
>> Doug
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs



From clemc at ccc.com  Mon Nov  9 13:36:51 2015
From: clemc at ccc.com (Clem cole)
Date: Sun, 8 Nov 2015 22:36:51 -0500
Subject: [TUHS] PWB contributions
In-Reply-To: <D9D5CFE3-F9F1-4A70-844C-210B7BD84575@acm.org>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
 <52F63A89-B372-409E-9296-BAA4CBF848AF@acm.org>
 <D9D5CFE3-F9F1-4A70-844C-210B7BD84575@acm.org>
Message-ID: <65204902-BAB1-4624-8D14-A65BEC60A574@ccc.com>

Interesting. If I run Into Eric any time soon I'll have to ask him.  As I recall I don't remember Dan's version but I do remember Eric's. Nor do I remember Geoff hacking on it. Plus if you look at the CSRG db from Kirk, the DB shows Eric as the creator. What's more Dan's name is not in the man page - Eric's is.  



I wonder if this is a case where Dan wrote something specific for the ADM's and the 11s and Eric did something similar more general around the sametime.  FWIW: Eric had always claimed to me that he wrote it and it is my memory that I got the sources from him for our systems in the CAD group in Cory hall (and have never had a reason to doubt him in that claim). 

I do remember more(1) was was one of the first programs that used Hortons termcap library that he had pulled out of joy's vi and greatly enhanced.  Mike Arnold then took it and created curses (for Rogue actually).

Btw Because of using termcap it forced a lot of us to put the termcap strings in the environment to speed up program start. 

Dans memory of the undergrad PDP 11 had being over loaded does line up with my memory.  A couple of us were teaching CS-40 (the intro undergrad course) around that time and undergrads used the Cory 70s.  I avoided them as much as possible. 



Sent from my iPhone

> On Nov 8, 2015, at 9:58 PM, Win Treese <treese at acm.org> wrote:
> 
> 
> Of course, as soon as I sent that, I found Dan Halbert’s version of things
> at http://www.danhalbert.org/more.html
> 
> For what that’s worth.
> 
> - Win
> 
>> On Nov 8, 2015, at 9:54 PM, Win Treese <treese at acm.org> wrote:
>> 
>> 
>> Clem, 
>> 
>> In trying to check on some memories of mine, I came across your answer on
>> Quora about "What is the difference between less and cat command?”, in which
>> you mention that Wikipedia had it wrong about Dan Halbert writing more(1).
>> 
>> What Dan did tell me many years ago is that he wrote a program called “less”
>> when he was at Berkeley as a near-parody on more(1). Its notable feature was
>> that it went backwards through the file, displaying in the opposite direction.
>> 
>> This, of course, had nothing to do with what we now know as less(1), and that code
>> is probably lost to history.
>> 
>> - Win
>> 
>>> On Nov 8, 2015, at 9:12 PM, Clement T. Cole <clemc at ccc.com> wrote:
>>> 
>>> Doug
>>> 
>>> Eric Shienbrood originally wrote more(1) at UCB when he came as a grad student.    It was based on functionality from ITS that he as used to having at MIT.   Summit wrote a similar program with the same called page(1) and I'm fairly sure it was few years after Eric's program. Btw page(1) which did not have the same functionality (no termcap or in there case terminfo yet).  Less(1) would show up a few years later and replace them both.  
>>> 
>>> Clem
>>> 
>>> Sent from my iPad
>>> 
>>> On Nov 8, 2015, at 8:39 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>>> 
>>>>>> I thought PWB (makers of "make") came from Harvard?
>>>> 
>>>>> PWB ...  came straight out of Bell. Not sure about all the
>>>>> applications (well, SCCS came from Bell).
>>>> 
>>>> PWB did not create make; Stu Feldman did it in research.
>>>> PWB did make SCCS. I believe it also originated cico,
>>>> find and eval. Probably more, too, but I can't reliably
>>>> separate PWB's other contributions from USG's.
>>>> 
>>>> Doug
>>>> _______________________________________________
>>>> TUHS mailing list
>>>> TUHS at minnie.tuhs.org
>>>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>> _______________________________________________
>>> TUHS mailing list
>>> TUHS at minnie.tuhs.org
>>> https://minnie.tuhs.org/mailman/listinfo/tuhs
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From clemc at ccc.com  Mon Nov  9 13:51:46 2015
From: clemc at ccc.com (Clem cole)
Date: Sun, 8 Nov 2015 22:51:46 -0500
Subject: [TUHS] PWB contributions
In-Reply-To: <65204902-BAB1-4624-8D14-A65BEC60A574@ccc.com>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
 <52F63A89-B372-409E-9296-BAA4CBF848AF@acm.org>
 <D9D5CFE3-F9F1-4A70-844C-210B7BD84575@acm.org>
 <65204902-BAB1-4624-8D14-A65BEC60A574@ccc.com>
Message-ID: <3E37024A-F6FC-4F11-82D1-A94700AD2521@ccc.com>

I should add - I certainly remember the ITS behavior from my old accounts there.  I also know Eric came to UCB after MIT.  Dan may have also but I can not verify that and I have no reason to not believe his story other than what Eric had said to me over the years and my own memories of the time. 

Basically the two programs I remember were Eric's more(1) and later Summit's pager which was a poor cousin to Eric's program and having to put Eric's program on AT&T based flavors so my own Finger ROMs could type comfortably.  

Clem

Sent from my iPhone

> On Nov 8, 2015, at 10:36 PM, Clem cole <clemc at ccc.com> wrote:
> 
> Interesting. If I run Into Eric any time soon I'll have to ask him.  As I recall I don't remember Dan's version but I do remember Eric's. Nor do I remember Geoff hacking on it. Plus if you look at the CSRG db from Kirk, the DB shows Eric as the creator. What's more Dan's name is not in the man page - Eric's is.  
> 
> 
> 
> I wonder if this is a case where Dan wrote something specific for the ADM's and the 11s and Eric did something similar more general around the sametime.  FWIW: Eric had always claimed to me that he wrote it and it is my memory that I got the sources from him for our systems in the CAD group in Cory hall (and have never had a reason to doubt him in that claim). 
> 
> I do remember more(1) was was one of the first programs that used Hortons termcap library that he had pulled out of joy's vi and greatly enhanced.  Mike Arnold then took it and created curses (for Rogue actually).
> 
> Btw Because of using termcap it forced a lot of us to put the termcap strings in the environment to speed up program start. 
> 
> Dans memory of the undergrad PDP 11 had being over loaded does line up with my memory.  A couple of us were teaching CS-40 (the intro undergrad course) around that time and undergrads used the Cory 70s.  I avoided them as much as possible. 
> 
> 
> 
> Sent from my iPhone
> 
>> On Nov 8, 2015, at 9:58 PM, Win Treese <treese at acm.org> wrote:
>> 
>> 
>> Of course, as soon as I sent that, I found Dan Halbert’s version of things
>> at http://www.danhalbert.org/more.html
>> 
>> For what that’s worth.
>> 
>> - Win
>> 
>>> On Nov 8, 2015, at 9:54 PM, Win Treese <treese at acm.org> wrote:
>>> 
>>> 
>>> Clem, 
>>> 
>>> In trying to check on some memories of mine, I came across your answer on
>>> Quora about "What is the difference between less and cat command?”, in which
>>> you mention that Wikipedia had it wrong about Dan Halbert writing more(1).
>>> 
>>> What Dan did tell me many years ago is that he wrote a program called “less”
>>> when he was at Berkeley as a near-parody on more(1). Its notable feature was
>>> that it went backwards through the file, displaying in the opposite direction.
>>> 
>>> This, of course, had nothing to do with what we now know as less(1), and that code
>>> is probably lost to history.
>>> 
>>> - Win
>>> 
>>>> On Nov 8, 2015, at 9:12 PM, Clement T. Cole <clemc at ccc.com> wrote:
>>>> 
>>>> Doug
>>>> 
>>>> Eric Shienbrood originally wrote more(1) at UCB when he came as a grad student.    It was based on functionality from ITS that he as used to having at MIT.   Summit wrote a similar program with the same called page(1) and I'm fairly sure it was few years after Eric's program. Btw page(1) which did not have the same functionality (no termcap or in there case terminfo yet).  Less(1) would show up a few years later and replace them both.  
>>>> 
>>>> Clem
>>>> 
>>>> Sent from my iPad
>>>> 
>>>> On Nov 8, 2015, at 8:39 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>>>> 
>>>>>>> I thought PWB (makers of "make") came from Harvard?
>>>>> 
>>>>>> PWB ...  came straight out of Bell. Not sure about all the
>>>>>> applications (well, SCCS came from Bell).
>>>>> 
>>>>> PWB did not create make; Stu Feldman did it in research.
>>>>> PWB did make SCCS. I believe it also originated cico,
>>>>> find and eval. Probably more, too, but I can't reliably
>>>>> separate PWB's other contributions from USG's.
>>>>> 
>>>>> Doug
>>>>> _______________________________________________
>>>>> TUHS mailing list
>>>>> TUHS at minnie.tuhs.org
>>>>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>>> _______________________________________________
>>>> TUHS mailing list
>>>> TUHS at minnie.tuhs.org
>>>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>> 
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs


From random832 at fastmail.com  Mon Nov  9 13:38:46 2015
From: random832 at fastmail.com (Random832)
Date: Sun, 08 Nov 2015 22:38:46 -0500
Subject: [TUHS] PWB contributions
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
 <52F63A89-B372-409E-9296-BAA4CBF848AF@acm.org>
 <D9D5CFE3-F9F1-4A70-844C-210B7BD84575@acm.org>
Message-ID: <m2r3jzsuyh.fsf@fastmail.com>

Win Treese <treese at acm.org> writes:

> Of course, as soon as I sent that, I found Dan Halbert’s version of things
> at http://www.danhalbert.org/more.html

>From that page:
> I named the program more. This was a daring move at the time, since it
> was such a long name for a UNIX command, and was also a real English
> word.

That makes me wonder... where does pg(1) fit into this history? There's
a version of it in the 32V tree in the TUHS archive, but nowhere else,
yet it surfaces in modern Unixes such as Solaris and there's a clone in
the "util-linux" package. It also shows up in SuSv2 (marked LEGACY, and
absent from later versions). Was it part of System III/V?



From lm at mcvoy.com  Mon Nov  9 14:34:13 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 8 Nov 2015 20:34:13 -0800
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <alpine.BSF.2.11.1511090115510.57799@aneurin.horsfall.org>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
 <1C0DB3B7-988D-435F-A590-6C0AB14249A3@gewt.net>
 <20151108071102.GA7290@mcvoy.com>
 <alpine.BSF.2.11.1511090115510.57799@aneurin.horsfall.org>
Message-ID: <20151109043413.GC22320@mcvoy.com>

On Mon, Nov 09, 2015 at 01:45:18AM +1100, Dave Horsfall wrote:
> On Sat, 7 Nov 2015, Larry McVoy wrote:
> 
> > Just getting back to email (spent the day taking pictures at a hockey 
> > tournament).
> 
> A typical Canadian :-)  There is only one game, and it's called Cricket; 
> where else can you see a sport that can take five days, and ends up in a 
> draw?

I'd be proud to be Canadian but I'm American though my background is
I'm 1/2 Dutch and 1/4 Scotch and 1/4 Irish.  I've been told that makes
me a pragmatic cheap drunk, which isn't entirely wrong :)  My Dad was
a Rhodes scholar and met my mom in Europe; growing up I'd go live with
my grandmother in the Netherlands quite a bit, so the Dutch connection
is pretty real.

The hockey connection is just that I grew up in Wisconsin and played
pickup any chance I could.  It wasn't until I started coaching high
school hockey that I realized there was this thing called a team
and you might want to think about passing.  Pickup is all about 
personal skills, there is no team in pickup...

We now return you to the quite fascinating discussion of getting some
Unix working on some 16 bit Zilog chip that can address 8MB in segments.
I'm actually jealous that anyone has the time to do this, it sounds 
like a blast.  The computing world is pretty complex these days, look
at any Android phone.  I used to think that working on the kernel was
hard, and it is, but it is far more contained in some ways.  It would
be pleasant to be doing a bring up of Unix.

--lm


From lm at mcvoy.com  Mon Nov  9 14:44:08 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 8 Nov 2015 20:44:08 -0800
Subject: [TUHS] PWB contributions
In-Reply-To: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
Message-ID: <20151109044407.GD22320@mcvoy.com>

On Sun, Nov 08, 2015 at 08:39:12PM -0500, Doug McIlroy wrote:
> >> I thought PWB (makers of "make") came from Harvard?
> 
> > PWB ...  came straight out of Bell. Not sure about all the
> > applications (well, SCCS came from Bell).
> 
> PWB did not create make; Stu Feldman did it in research.
> PWB did make SCCS. 

Marc Rochkind did SCCS, right?  Wikipedia said he did it at Bell Labs.

Does anyone on the list remember him?  I'd love to hear some stories
about how SCCS was created.

Warning: source management rant coming.

SCCS got a bad rap from Walter Tichy when he created RCS, I can't remember
his dislike but it's completely wrong.  RCS is diff based, you have a file
and a series of patches.  For the tip of the trunk, that's the file, going
backwards in history they are reverse patches.  OK, not so crazy.  But now
think about a branch.  You do reverse patches back to the branch point and
forward patches down to the tip of the branch.  Anyone living on a branch
hated RCS.

SCCS has interleaved deltas.   It's a brilliant design that has far far
better performance than anything else out there.  I'll explain that if
anyone cares but I'd love to know if anyone talked to Marc while he was
building SCCS.  Love to learn how he came up with that.

The reason I know so much about SCCS is that BitKeeper is sort of SCCS 
on steroids, we took the file format, fixed a bunch of stuff, and made
the first distributed version control system with it.  Git, Mercurial,
all the others, are copies of what we did.

I wish Marc was on this list, be fun to chat.

--lm


From clemc at ccc.com  Mon Nov  9 14:50:27 2015
From: clemc at ccc.com (Clem cole)
Date: Sun, 8 Nov 2015 23:50:27 -0500
Subject: [TUHS] PWB contributions
In-Reply-To: <m2r3jzsuyh.fsf@fastmail.com>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
 <52F63A89-B372-409E-9296-BAA4CBF848AF@acm.org>
 <D9D5CFE3-F9F1-4A70-844C-210B7BD84575@acm.org> <m2r3jzsuyh.fsf@fastmail.com>
Message-ID: <35BEAC3A-0112-4750-8D5C-0A370AD6830A@ccc.com>

The Summit folks created pg(1).  It was definitely in System V. But I think Doug's memory of it being there much earlier coincides with my memory.  As I mentioned more(1) was part of the source kit I carried with me to non-BSD systems that I needed so I could type comfortably. 

Sent from my iPhone

> On Nov 8, 2015, at 10:38 PM, Random832 <random832 at fastmail.com> wrote:
> 
> Win Treese <treese at acm.org> writes:
> 
>> Of course, as soon as I sent that, I found Dan Halbert’s version of things
>> at http://www.danhalbert.org/more.html
> 
> From that page:
>> I named the program more. This was a daring move at the time, since it
>> was such a long name for a UNIX command, and was also a real English
>> word.
> 
> That makes me wonder... where does pg(1) fit into this history? There's
> a version of it in the 32V tree in the TUHS archive, but nowhere else,
> yet it surfaces in modern Unixes such as Solaris and there's a clone in
> the "util-linux" package. It also shows up in SuSv2 (marked LEGACY, and
> absent from later versions). Was it part of System III/V?
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From cowan at mercury.ccil.org  Mon Nov  9 14:51:08 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Sun, 8 Nov 2015 23:51:08 -0500
Subject: [TUHS] PWB contributions
In-Reply-To: <20151109044407.GD22320@mcvoy.com>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <20151109044407.GD22320@mcvoy.com>
Message-ID: <20151109045108.GD19694@mercury.ccil.org>

Larry McVoy scripsit:

> I wish Marc was on this list, be fun to chat.

rochkind at basepath.com.  I don't know him, but those who do, or who
have more chutzpah than I, may want to tell him about us.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Dream projects long deferred usually bite the wax tadpole.
        --James Lileks


From lm at mcvoy.com  Mon Nov  9 15:07:50 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 8 Nov 2015 21:07:50 -0800
Subject: [TUHS] PWB contributions
In-Reply-To: <20151109045108.GD19694@mercury.ccil.org>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <20151109044407.GD22320@mcvoy.com>
 <20151109045108.GD19694@mercury.ccil.org>
Message-ID: <20151109050750.GG22320@mcvoy.com>

Doing it now.

On Sun, Nov 08, 2015 at 11:51:08PM -0500, John Cowan wrote:
> Larry McVoy scripsit:
> 
> > I wish Marc was on this list, be fun to chat.
> 
> rochkind at basepath.com.  I don't know him, but those who do, or who
> have more chutzpah than I, may want to tell him about us.
> 
> -- 
> John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
> Dream projects long deferred usually bite the wax tadpole.
>         --James Lileks

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From lm at mcvoy.com  Mon Nov  9 15:09:55 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 8 Nov 2015 21:09:55 -0800
Subject: [TUHS] PWB contributions
In-Reply-To: <20151109050750.GG22320@mcvoy.com>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <20151109044407.GD22320@mcvoy.com>
 <20151109045108.GD19694@mercury.ccil.org>
 <20151109050750.GG22320@mcvoy.com>
Message-ID: <20151109050955.GH22320@mcvoy.com>

Um, can someone tell me how to tell Marc how he signs up if he is interested?

On Sun, Nov 08, 2015 at 09:07:50PM -0800, Larry McVoy wrote:
> Doing it now.
> 
> On Sun, Nov 08, 2015 at 11:51:08PM -0500, John Cowan wrote:
> > Larry McVoy scripsit:
> > 
> > > I wish Marc was on this list, be fun to chat.
> > 
> > rochkind at basepath.com.  I don't know him, but those who do, or who
> > have more chutzpah than I, may want to tell him about us.
> > 
> > -- 
> > John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
> > Dream projects long deferred usually bite the wax tadpole.
> >         --James Lileks
> 
> -- 
> ---
> Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From cowan at mercury.ccil.org  Mon Nov  9 15:16:19 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Mon, 9 Nov 2015 00:16:19 -0500
Subject: [TUHS] PWB contributions
In-Reply-To: <20151109050955.GH22320@mcvoy.com>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <20151109044407.GD22320@mcvoy.com>
 <20151109045108.GD19694@mercury.ccil.org>
 <20151109050750.GG22320@mcvoy.com>
 <20151109050955.GH22320@mcvoy.com>
Message-ID: <20151109051618.GE19694@mercury.ccil.org>

Larry McVoy scripsit:

> Um, can someone tell me how to tell Marc how he signs up if he is interested?

Per the Mailman page: he find Warren Toomey's email at tuhs.org and asks
him.  If he can't figure out how to get that email, he's lost to the
Dark Side of the Force.


-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
If a traveler were informed that such a man [as Lord John Russell] was
leader of the House of Commons, he may well begin to comprehend how the
Egyptians worshiped an insect.  --Benjamin Disraeli


From iamleot at gmail.com  Mon Nov  9 15:16:37 2015
From: iamleot at gmail.com (Leonardo Taccari)
Date: Mon, 09 Nov 2015 06:16:37 +0100
Subject: [TUHS] PWB contributions
In-Reply-To: <20151109050955.GH22320@mcvoy.com>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <20151109044407.GD22320@mcvoy.com> <20151109045108.GD19694@mercury.ccil.org>
 <20151109050750.GG22320@mcvoy.com> <20151109050955.GH22320@mcvoy.com>
Message-ID: <56402c4a.8153c20a.5bc24.ffffe7bc@mx.google.com>

Hello Larry,

Larry McVoy writes:
> Um, can someone tell me how to tell Marc how he signs up if he is interested?
Just send an email to Warren Toomey (wkt at tuhs dot org).

Ciao,
L.


From lm at mcvoy.com  Mon Nov  9 15:28:34 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 8 Nov 2015 21:28:34 -0800
Subject: [TUHS] do you know about TUHS?
Message-ID: <20151109052834.GA30198@mcvoy.com>

Hi Marc,

TUHS == The Unix Historical Society, it's a mailing list as well as a
repository of Unix source code (including yours).  A lot of the Bell
Labs guys are on the list, it has weird topics like the current one of
how to get System III booting on a Zilog something that is 16 bits but
can address 8MB in segments.

There was a side discussion of PWB and SCCS came up and I started talking
about how cool SCCS was and how RCS gave it an undeserved bad rap. In
the process I said "I wish Marc was on this list" and John Cowan said
here is his email, go ask him.

I think you'd have fun on the list, it's old school unix.  Lots of signal,
very little noise.  I personally would love to have you there, SCCS was
brilliant.  It would be fun to pick your brain about how that happened.

And for the record your advanced unix programming book has influenced
how I code.  It error checks when there could be errors and passes when
there shouldn't be errors.  I feel like that book threaded the needle -
error checking matters except when it doesn't.  It taught me a lot and
I pass it on to anyone who will listen.

If you want to get on the list send an email to wkt at tuhs.org.  Be good
to have your voice here.

--lm


From b4 at gewt.net  Mon Nov  9 15:38:19 2015
From: b4 at gewt.net (Cory Smelosky)
Date: Sun, 8 Nov 2015 21:38:19 -0800
Subject: [TUHS] Anyone have any sun4c/hp300?
Message-ID: <3AEEECE6-5A5F-469E-BB81-F526D2194F53@gewt.net>

Anyone have some sun4c or hp300 gear they'd be persuaded to part with? Preferred in the SF Bay Area? It's getting a bit too difficult using broken emulators and broken cross compilers...

Sent from my iPhone

From lbickley at bickleywest.com  Mon Nov  9 16:40:25 2015
From: lbickley at bickleywest.com (Lyle Bickley)
Date: Sun, 8 Nov 2015 22:40:25 -0800
Subject: [TUHS] Anyone have any sun4c/hp300?
In-Reply-To: <3AEEECE6-5A5F-469E-BB81-F526D2194F53@gewt.net>
References: <3AEEECE6-5A5F-469E-BB81-F526D2194F53@gewt.net>
Message-ID: <20151108224025.6e49cbc1@asrock.bcwi.net>

On Sun, 8 Nov 2015 21:38:19 -0800
Cory Smelosky <b4 at gewt.net> wrote:

> Anyone have some sun4c or hp300 gear they'd be persuaded to part with? Preferred in the SF Bay Area? It's getting a bit too difficult using broken emulators and broken cross compilers...

Sun4c for sure and sometimes HP300 systems - try Weirdstuff in Sunnyvale. Talk to Jim...

I have no affiliation with Weirdstuff other than as a client and fellow preservation fan.

Cheers,
Lyle

-- 
73      AF6WS
Bickley Consulting West Inc.
http://bickleywest.com

"Black holes are where God is dividing by zero"


From b4 at gewt.net  Mon Nov  9 17:20:55 2015
From: b4 at gewt.net (Cory Smelosky)
Date: Sun, 8 Nov 2015 23:20:55 -0800
Subject: [TUHS] Anyone have any sun4c/hp300?
In-Reply-To: <20151108224025.6e49cbc1@asrock.bcwi.net>
References: <3AEEECE6-5A5F-469E-BB81-F526D2194F53@gewt.net>
 <20151108224025.6e49cbc1@asrock.bcwi.net>
Message-ID: <4DCC6F06-A048-40D4-B821-009796E9F17D@gewt.net>

They end up with hp300 stuff?! Huh.

Sent from my iPhone

> On Nov 8, 2015, at 22:40, Lyle Bickley <lbickley at bickleywest.com> wrote:
> 
> On Sun, 8 Nov 2015 21:38:19 -0800
> Cory Smelosky <b4 at gewt.net> wrote:
> 
>> Anyone have some sun4c or hp300 gear they'd be persuaded to part with? Preferred in the SF Bay Area? It's getting a bit too difficult using broken emulators and broken cross compilers...
> 
> Sun4c for sure and sometimes HP300 systems - try Weirdstuff in Sunnyvale. Talk to Jim...
> 
> I have no affiliation with Weirdstuff other than as a client and fellow preservation fan.
> 
> Cheers,
> Lyle
> 
> -- 
> 73      AF6WS
> Bickley Consulting West Inc.
> http://bickleywest.com
> 
> "Black holes are where God is dividing by zero"


From lehmann at ans-netz.de  Mon Nov  9 18:15:51 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Mon, 09 Nov 2015 09:15:51 +0100
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <CAH1jEzarQAW4ucfP81RRhP0pgkFiHiiMAH9F=a6DsEEiU0Uy=Q@mail.gmail.com>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
 <CAC20D2NnLC2H=+8ZzpXEpgUqa+qW3JuFMLeWjL_Su9OBoHWBZQ@mail.gmail.com>
 <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net>
 <20151108051028.GA32246@cowbell.employees.org>
 <CAH1jEzbzpuwzncuEFQMHHD-pHHk_4SHre2PY5BPZNpY_HAgXCw@mail.gmail.com>
 <20151108143817.Horde.tlWgdF0OWmzmg-kXXO-AxUO@avocado.salatschuessel.net>
 <CAH1jEzarQAW4ucfP81RRhP0pgkFiHiiMAH9F=a6DsEEiU0Uy=Q@mail.gmail.com>
Message-ID: <20151109091551.Horde.vyfPFb7gspsxIQB3WGNcE_A@avocado.salatschuessel.net>


Nick Downing <downing.nick at gmail.com> wrote:

> You can most likely implement a split I/D architecture by having code
> execute out of a different segment than data, although I haven't
> checked the datasheet so I don't know for sure if this is possible.

I have 3 different MMUs available. Stack, Code and Data it is called in
the Circuit diagram. I probably have to lookup the references but I still
don't get why the kernel can only work with 64k of RAM as it is right now
compiled as a segmented programm and uses more memory already with SysIII.
Only the boot0-loader is compiled unsegmented and also some small
utilities. Every other portion of the system uses the segmentation features
of the Z8001 and is not limited to 64k adressable space.

The system has right now MB of


From lehmann at ans-netz.de  Mon Nov  9 18:16:46 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Mon, 09 Nov 2015 09:16:46 +0100
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <20151109091551.Horde.vyfPFb7gspsxIQB3WGNcE_A@avocado.salatschuessel.net>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
 <CAC20D2NnLC2H=+8ZzpXEpgUqa+qW3JuFMLeWjL_Su9OBoHWBZQ@mail.gmail.com>
 <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net>
 <20151108051028.GA32246@cowbell.employees.org>
 <CAH1jEzbzpuwzncuEFQMHHD-pHHk_4SHre2PY5BPZNpY_HAgXCw@mail.gmail.com>
 <20151108143817.Horde.tlWgdF0OWmzmg-kXXO-AxUO@avocado.salatschuessel.net>
 <CAH1jEzarQAW4ucfP81RRhP0pgkFiHiiMAH9F=a6DsEEiU0Uy=Q@mail.gmail.com>
 <20151109091551.Horde.vyfPFb7gspsxIQB3WGNcE_A@avocado.salatschuessel.net>
Message-ID: <20151109091646.Horde.WJOBgOU20u5J3ItIHNJDwO9@avocado.salatschuessel.net>

I hit the send button to fast :(

Oliver Lehmann <lehmann at ans-netz.de> wrote:

> Nick Downing <downing.nick at gmail.com> wrote:
>
>> You can most likely implement a split I/D architecture by having code
>> execute out of a different segment than data, although I haven't
>> checked the datasheet so I don't know for sure if this is possible.
>
> I have 3 different MMUs available. Stack, Code and Data it is called in
> the Circuit diagram. I probably have to lookup the references but I still
> don't get why the kernel can only work with 64k of RAM as it is right now
> compiled as a segmented programm and uses more memory already with SysIII.
> Only the boot0-loader is compiled unsegmented and also some small
> utilities. Every other portion of the system uses the segmentation features
> of the Z8001 and is not limited to 64k adressable space.
>
> The system has right now MB of

The system has right now around 6 MB of RAM but can be upgraded to 16MB
minus 64KB (Due to a firmware bug) of RAM.


From gregg.drwho8 at gmail.com  Mon Nov  9 18:17:02 2015
From: gregg.drwho8 at gmail.com (Gregg Levine)
Date: Mon, 9 Nov 2015 03:17:02 -0500
Subject: [TUHS] Anyone have any sun4c/hp300?
In-Reply-To: <4DCC6F06-A048-40D4-B821-009796E9F17D@gewt.net>
References: <3AEEECE6-5A5F-469E-BB81-F526D2194F53@gewt.net>
 <20151108224025.6e49cbc1@asrock.bcwi.net>
 <4DCC6F06-A048-40D4-B821-009796E9F17D@gewt.net>
Message-ID: <CAC5iaNEzk8ZZiqncB=1M=7HJnk7pcPFc0e8Y66dCoHhNfkexjA@mail.gmail.com>

Hello!
They do indeed. That , ah, shop is famous all over the country. Yes go
there and talk to the fellow mentioned.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Mon, Nov 9, 2015 at 2:20 AM, Cory Smelosky <b4 at gewt.net> wrote:
> They end up with hp300 stuff?! Huh.
>
> Sent from my iPhone
>
>> On Nov 8, 2015, at 22:40, Lyle Bickley <lbickley at bickleywest.com> wrote:
>>
>> On Sun, 8 Nov 2015 21:38:19 -0800
>> Cory Smelosky <b4 at gewt.net> wrote:
>>
>>> Anyone have some sun4c or hp300 gear they'd be persuaded to part with? Preferred in the SF Bay Area? It's getting a bit too difficult using broken emulators and broken cross compilers...
>>
>> Sun4c for sure and sometimes HP300 systems - try Weirdstuff in Sunnyvale. Talk to Jim...
>>
>> I have no affiliation with Weirdstuff other than as a client and fellow preservation fan.
>>
>> Cheers,
>> Lyle
>>
>> --
>> 73      AF6WS
>> Bickley Consulting West Inc.
>> http://bickleywest.com
>>
>> "Black holes are where God is dividing by zero"
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From lehmann at ans-netz.de  Mon Nov  9 19:40:00 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Mon, 09 Nov 2015 10:40:00 +0100
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <20151109091646.Horde.WJOBgOU20u5J3ItIHNJDwO9@avocado.salatschuessel.net>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
 <CAC20D2NnLC2H=+8ZzpXEpgUqa+qW3JuFMLeWjL_Su9OBoHWBZQ@mail.gmail.com>
 <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net>
 <20151108051028.GA32246@cowbell.employees.org>
 <CAH1jEzbzpuwzncuEFQMHHD-pHHk_4SHre2PY5BPZNpY_HAgXCw@mail.gmail.com>
 <20151108143817.Horde.tlWgdF0OWmzmg-kXXO-AxUO@avocado.salatschuessel.net>
 <CAH1jEzarQAW4ucfP81RRhP0pgkFiHiiMAH9F=a6DsEEiU0Uy=Q@mail.gmail.com>
 <20151109091551.Horde.vyfPFb7gspsxIQB3WGNcE_A@avocado.salatschuessel.net>
 <20151109091646.Horde.WJOBgOU20u5J3ItIHNJDwO9@avocado.salatschuessel.net>
Message-ID: <20151109104000.Horde.mZW7kq6nXQAQyqwKfyBtDlp@avocado.salatschuessel.net>

This is for example the ureg.c which shows the Segmentation Code for the
current SysIII Kernel I redid from original SysIII Sources + Disassembled
object-File analysis of the current SysIII Kernel running on the system:

http://cvs.laladev.org/index.html/P8000/WEGA/src/uts/sys/ureg.c?rev=1.1&content-type=text/x-cvsweb-markup



Oliver Lehmann <lehmann at ans-netz.de> wrote:

> I hit the send button to fast :(
>
> Oliver Lehmann <lehmann at ans-netz.de> wrote:
>
>> Nick Downing <downing.nick at gmail.com> wrote:
>>
>>> You can most likely implement a split I/D architecture by having code
>>> execute out of a different segment than data, although I haven't
>>> checked the datasheet so I don't know for sure if this is possible.
>>
>> I have 3 different MMUs available. Stack, Code and Data it is called in
>> the Circuit diagram. I probably have to lookup the references but I still
>> don't get why the kernel can only work with 64k of RAM as it is right now
>> compiled as a segmented programm and uses more memory already with SysIII.
>> Only the boot0-loader is compiled unsegmented and also some small
>> utilities. Every other portion of the system uses the segmentation features
>> of the Z8001 and is not limited to 64k adressable space.
>>
>> The system has right now MB of
>
> The system has right now around 6 MB of RAM but can be upgraded to 16MB
> minus 64KB (Due to a firmware bug) of RAM.




From lehmann at ans-netz.de  Mon Nov  9 19:40:51 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Mon, 09 Nov 2015 10:40:51 +0100
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <20151109104000.Horde.mZW7kq6nXQAQyqwKfyBtDlp@avocado.salatschuessel.net>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
 <CAC20D2NnLC2H=+8ZzpXEpgUqa+qW3JuFMLeWjL_Su9OBoHWBZQ@mail.gmail.com>
 <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net>
 <20151108051028.GA32246@cowbell.employees.org>
 <CAH1jEzbzpuwzncuEFQMHHD-pHHk_4SHre2PY5BPZNpY_HAgXCw@mail.gmail.com>
 <20151108143817.Horde.tlWgdF0OWmzmg-kXXO-AxUO@avocado.salatschuessel.net>
 <CAH1jEzarQAW4ucfP81RRhP0pgkFiHiiMAH9F=a6DsEEiU0Uy=Q@mail.gmail.com>
 <20151109091551.Horde.vyfPFb7gspsxIQB3WGNcE_A@avocado.salatschuessel.net>
 <20151109091646.Horde.WJOBgOU20u5J3ItIHNJDwO9@avocado.salatschuessel.net>
 <20151109104000.Horde.mZW7kq6nXQAQyqwKfyBtDlp@avocado.salatschuessel.net>
Message-ID: <20151109104051.Horde.YgA2De1sCJ0zishMzOjwnS8@avocado.salatschuessel.net>

http://cvs.laladev.org/index.html/P8000/WEGA/src/uts/sys/ureg.c?rev=1.9&content-type=text/x-cvsweb-markup

1.9 is the current version 1.1 is the plain SysIII file...


Oliver Lehmann <lehmann at ans-netz.de> wrote:

> This is for example the ureg.c which shows the Segmentation Code for the
> current SysIII Kernel I redid from original SysIII Sources + Disassembled
> object-File analysis of the current SysIII Kernel running on the system:
>
> http://cvs.laladev.org/index.html/P8000/WEGA/src/uts/sys/ureg.c?rev=1.1&content-type=text/x-cvsweb-markup
>
>
>
> Oliver Lehmann <lehmann at ans-netz.de> wrote:
>
>> I hit the send button to fast :(
>>
>> Oliver Lehmann <lehmann at ans-netz.de> wrote:
>>
>>> Nick Downing <downing.nick at gmail.com> wrote:
>>>
>>>> You can most likely implement a split I/D architecture by having code
>>>> execute out of a different segment than data, although I haven't
>>>> checked the datasheet so I don't know for sure if this is possible.
>>>
>>> I have 3 different MMUs available. Stack, Code and Data it is called in
>>> the Circuit diagram. I probably have to lookup the references but I still
>>> don't get why the kernel can only work with 64k of RAM as it is right now
>>> compiled as a segmented programm and uses more memory already with SysIII.
>>> Only the boot0-loader is compiled unsegmented and also some small
>>> utilities. Every other portion of the system uses the segmentation features
>>> of the Z8001 and is not limited to 64k adressable space.
>>>
>>> The system has right now MB of
>>
>> The system has right now around 6 MB of RAM but can be upgraded to 16MB
>> minus 64KB (Due to a firmware bug) of RAM.




From doug at cs.dartmouth.edu  Mon Nov  9 23:58:03 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Mon, 09 Nov 2015 08:58:03 -0500
Subject: [TUHS] PWB contributions
In-Reply-To: <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
Message-ID: <201511091358.tA9Dw35f010741@coolidge.cs.Dartmouth.EDU>

> Eric Shienbrood originally wrote more(1) at UCB

Amusing result of ambiguity. I had written

> PWB did make SCCS. I believe it also originated cico,
> find and eval. Probably more, too, but I can't reliably
> separate PWB's other contributions from USG's.

The intended meaning was, "Probably more things, too",
things like "cut" and "paste", whose exact provenance
I can't recall. And I got 2 out of 3 wrong in the list
"cico, find and eval", which should have been "cpio,
find and expr".

> Less(1) would show up a few years later and replace [page and more].

And to set a world benchmark for software bloat. For a good time try
        less --help | wc

Doug


From ron at ronnatalie.com  Tue Nov 10 00:02:37 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Mon, 9 Nov 2015 09:02:37 -0500
Subject: [TUHS] PWB contributions
In-Reply-To: <201511091358.tA9Dw35f010741@coolidge.cs.Dartmouth.EDU>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
 <201511091358.tA9Dw35f010741@coolidge.cs.Dartmouth.EDU>
Message-ID: <9285A78F-8A2D-4EE0-A2E4-894AD98F039B@ronnatalie.com>


> On Nov 9, 2015, at 8:58 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> 
>> Eric Shienbrood originally wrote more(1) at UCB
> 
> Amusing result of ambiguity. I had written

What was provided by PWB?
Who was provided by research?
Where was provided by UCB?

I don’t know…THIRD BASE!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151109/21b96e6a/attachment.bin>

From cowan at mercury.ccil.org  Tue Nov 10 00:44:16 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Mon, 9 Nov 2015 09:44:16 -0500
Subject: [TUHS] PWB contributions
In-Reply-To: <201511091358.tA9Dw35f010741@coolidge.cs.Dartmouth.EDU>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
 <201511091358.tA9Dw35f010741@coolidge.cs.Dartmouth.EDU>
Message-ID: <20151109144416.GA13422@mercury.ccil.org>

Doug McIlroy scripsit:

> And to set a world benchmark for software bloat. For a good time try
>         less --help | wc

I disagree entirely: it's a matter of how you see less.  For me it is
roughly comparable to ed (and indeed the primary documentation is about
the same size).  Both have the function of letting you inspect, in ways
not predictable in advance, the contents of a file.  Ed also allows
you to modify the file, whereas less has a more convenient interface
for dealing with pipeline output, and has single-keystroke convenience
commands, notably space.

(IWBNI ed had a switch to make it read stdin into the buffer and then
read commands from /dev/tty.  Obviously a wrapper script could achieve
this easily.)

Disclaimer:  I actually use ex, not ed: I'm willing to trade off a
litttle less standardosity for a little more convenience.  That also
of a minimal subset of vi commands when dealing with code that contains
highly repetitive strings, notably Lisp parentheses.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
"Repeat this until 'update-mounts -v' shows no updates.
You may well have to log in to particular machines, hunt down
people who still have processes running, and kill them."


From lm at mcvoy.com  Tue Nov 10 01:13:46 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 9 Nov 2015 07:13:46 -0800
Subject: [TUHS] Anyone have any sun4c/hp300?
In-Reply-To: <CAC5iaNEzk8ZZiqncB=1M=7HJnk7pcPFc0e8Y66dCoHhNfkexjA@mail.gmail.com>
References: <3AEEECE6-5A5F-469E-BB81-F526D2194F53@gewt.net>
 <20151108224025.6e49cbc1@asrock.bcwi.net>
 <4DCC6F06-A048-40D4-B821-009796E9F17D@gewt.net>
 <CAC5iaNEzk8ZZiqncB=1M=7HJnk7pcPFc0e8Y66dCoHhNfkexjA@mail.gmail.com>
Message-ID: <20151109151346.GJ22320@mcvoy.com>

And ebay if weirdstuff doesn't come through.

On Mon, Nov 09, 2015 at 03:17:02AM -0500, Gregg Levine wrote:
> Hello!
> They do indeed. That , ah, shop is famous all over the country. Yes go
> there and talk to the fellow mentioned.
> -----
> Gregg C Levine gregg.drwho8 at gmail.com
> "This signature fought the Time Wars, time and again."
> 
> 
> On Mon, Nov 9, 2015 at 2:20 AM, Cory Smelosky <b4 at gewt.net> wrote:
> > They end up with hp300 stuff?! Huh.
> >
> > Sent from my iPhone
> >
> >> On Nov 8, 2015, at 22:40, Lyle Bickley <lbickley at bickleywest.com> wrote:
> >>
> >> On Sun, 8 Nov 2015 21:38:19 -0800
> >> Cory Smelosky <b4 at gewt.net> wrote:
> >>
> >>> Anyone have some sun4c or hp300 gear they'd be persuaded to part with? Preferred in the SF Bay Area? It's getting a bit too difficult using broken emulators and broken cross compilers...
> >>
> >> Sun4c for sure and sometimes HP300 systems - try Weirdstuff in Sunnyvale. Talk to Jim...
> >>
> >> I have no affiliation with Weirdstuff other than as a client and fellow preservation fan.
> >>
> >> Cheers,
> >> Lyle
> >>
> >> --
> >> 73      AF6WS
> >> Bickley Consulting West Inc.
> >> http://bickleywest.com
> >>
> >> "Black holes are where God is dividing by zero"
> > _______________________________________________
> > TUHS mailing list
> > TUHS at minnie.tuhs.org
> > https://minnie.tuhs.org/mailman/listinfo/tuhs
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From dave at horsfall.org  Tue Nov 10 01:40:27 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Tue, 10 Nov 2015 02:40:27 +1100 (EST)
Subject: [TUHS] PWB contributions
In-Reply-To: <65204902-BAB1-4624-8D14-A65BEC60A574@ccc.com>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
 <52F63A89-B372-409E-9296-BAA4CBF848AF@acm.org>
 <D9D5CFE3-F9F1-4A70-844C-210B7BD84575@acm.org>
 <65204902-BAB1-4624-8D14-A65BEC60A574@ccc.com>
Message-ID: <alpine.BSF.2.11.1511100228510.69353@aneurin.horsfall.org>

On Sun, 8 Nov 2015, Clem cole wrote:

> I do remember more(1) was was one of the first programs that used 
> Hortons termcap library that he had pulled out of joy's vi and greatly 
> enhanced.  Mike Arnold then took it and created curses (for Rogue 
> actually).

Wouldn't that be Ken Arnold?  Clearly I remember the message "You are as 
smart as Ken Arnold in dungeon %d" when quaffing a certain potion.

Ah, many days I spent playing Rogue, when I should've been working, and 
coming to grips with all its versions.

Who remembers Rog-o-matic?  I vaguely remember that it actually walked off 
with the Amulet of Yendor.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From clemc at ccc.com  Tue Nov 10 01:54:59 2015
From: clemc at ccc.com (Clem Cole)
Date: Mon, 9 Nov 2015 10:54:59 -0500
Subject: [TUHS] PWB contributions
In-Reply-To: <alpine.BSF.2.11.1511100228510.69353@aneurin.horsfall.org>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
 <52F63A89-B372-409E-9296-BAA4CBF848AF@acm.org>
 <D9D5CFE3-F9F1-4A70-844C-210B7BD84575@acm.org>
 <65204902-BAB1-4624-8D14-A65BEC60A574@ccc.com>
 <alpine.BSF.2.11.1511100228510.69353@aneurin.horsfall.org>
Message-ID: <CAC20D2NDuMzsbeGEPJKUpKdZyh09xp6MC9CqvxnGHz=Fca6-tA@mail.gmail.com>

Sorry - typo/brain f*rt -- Ken Arnold

On Mon, Nov 9, 2015 at 10:40 AM, Dave Horsfall <dave at horsfall.org> wrote:

> On Sun, 8 Nov 2015, Clem cole wrote:
>
> > I do remember more(1) was was one of the first programs that used
> > Hortons termcap library that he had pulled out of joy's vi and greatly
> > enhanced.  Mike Arnold then took it and created curses (for Rogue
> > actually).
>
> Wouldn't that be Ken Arnold?  Clearly I remember the message "You are as
> smart as Ken Arnold in dungeon %d" when quaffing a certain potion.
>
> Ah, many days I spent playing Rogue, when I should've been working, and
> coming to grips with all its versions.
>
> Who remembers Rog-o-matic?  I vaguely remember that it actually walked off
> with the Amulet of Yendor.
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151109/aa98b117/attachment.html>

From mah at mhorton.net  Tue Nov 10 08:12:42 2015
From: mah at mhorton.net (Mary Ann Horton)
Date: Mon, 09 Nov 2015 14:12:42 -0800
Subject: [TUHS] PWB contributions
In-Reply-To: <65204902-BAB1-4624-8D14-A65BEC60A574@ccc.com>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
 <52F63A89-B372-409E-9296-BAA4CBF848AF@acm.org>
 <D9D5CFE3-F9F1-4A70-844C-210B7BD84575@acm.org>
 <65204902-BAB1-4624-8D14-A65BEC60A574@ccc.com>
Message-ID: <20151109141242.156630m1mbtw4ifu@webmail.mhorton.net>

My recollection matches Clem's - I was there and I thought Eric wrote "more".
Dan was definitely there and he might have done the first version, but  
I don't recall that.  I do recall the story about MIT, and I sure that  
ITS was the inspiration.  And I recall Eric noting the space bar was  
the "next page" key (as opposed to Return which other programs  
expected) because it's the biggest key on the keyboard.

I can't take credit for pulling libtermcap (originally libtermlib) out  
of vi, Bill Joy had already done that before I took on vi and termcap.

   Mary Ann

Quoting Clem cole <clemc at ccc.com>:

> Interesting. If I run Into Eric any time soon I'll have to ask him.   
> As I recall I don't remember Dan's version but I do remember Eric's.  
> Nor do I remember Geoff hacking on it. Plus if you look at the CSRG  
> db from Kirk, the DB shows Eric as the creator. What's more Dan's  
> name is not in the man page - Eric's is.
>
>
>
> I wonder if this is a case where Dan wrote something specific for  
> the ADM's and the 11s and Eric did something similar more general  
> around the sametime.  FWIW: Eric had always claimed to me that he  
> wrote it and it is my memory that I got the sources from him for our  
> systems in the CAD group in Cory hall (and have never had a reason  
> to doubt him in that claim).
>
> I do remember more(1) was was one of the first programs that used  
> Hortons termcap library that he had pulled out of joy's vi and  
> greatly enhanced.  (Ken) Arnold then took it and created curses (for  
> Rogue actually).



From downing.nick at gmail.com  Tue Nov 10 08:36:04 2015
From: downing.nick at gmail.com (Nick Downing)
Date: Tue, 10 Nov 2015 09:36:04 +1100
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <20151109104051.Horde.YgA2De1sCJ0zishMzOjwnS8@avocado.salatschuessel.net>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <20151107192043.GA11895@mcvoy.com>
 <CAC20D2NnLC2H=+8ZzpXEpgUqa+qW3JuFMLeWjL_Su9OBoHWBZQ@mail.gmail.com>
 <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net>
 <20151108051028.GA32246@cowbell.employees.org>
 <CAH1jEzbzpuwzncuEFQMHHD-pHHk_4SHre2PY5BPZNpY_HAgXCw@mail.gmail.com>
 <20151108143817.Horde.tlWgdF0OWmzmg-kXXO-AxUO@avocado.salatschuessel.net>
 <CAH1jEzarQAW4ucfP81RRhP0pgkFiHiiMAH9F=a6DsEEiU0Uy=Q@mail.gmail.com>
 <20151109091551.Horde.vyfPFb7gspsxIQB3WGNcE_A@avocado.salatschuessel.net>
 <20151109091646.Horde.WJOBgOU20u5J3ItIHNJDwO9@avocado.salatschuessel.net>
 <20151109104000.Horde.mZW7kq6nXQAQyqwKfyBtDlp@avocado.salatschuessel.net>
 <20151109104051.Horde.YgA2De1sCJ0zishMzOjwnS8@avocado.salatschuessel.net>
Message-ID: <CAH1jEzZ35dbkkGhErsHhWMka67g=9SND4_PB00PQqXNs0a384w@mail.gmail.com>

Well that looks to me like a standard split I/D setup where each process,
and the kernel, can have up to 64 kb of code and 64 kb of data. It will run
2.11bsd with a relatively straightforward porting effort -- direct
translation of each code fragment to do something equivalent on your device.

What I discussed as another option (that I did on Z180 which did not have
split I/D and hence had too small a logical address space to run 2.11bsd or
any other reasonable unix)... was to increase the code limit past 64 kb by
segmentation. Whilst this is difficult to do, it can be achieved without
(much) compiler support. Code pointers become 3 bytes instead of 2, but
luckily, code pointers are hardly used, and this limitation can be got
around by using stubs.

You are right though, in that a natively running system that can freely
utilize your 6 Mb or 8 Mb or whatever, certainly IS possible. The MS DOS C
compilers for PC/XT, PC/AT etc, supported this. The "large" memory model
had segmented code and data, any process could have multiple code and data
segments. Pointers were 4 bytes (equivalent to 3 bytes in your case, a
16-bit offset and a 7-bit segment). However, pointer arithmetic did not
carry into the segment field, so arrays and structs and the biggest
"malloc" were limited to 64 kbytes. It was somewhat slower than the "small"
memory model (2 byte pointers) and everything took more memory. The "huge"
memory model removed the 64 kbyte limitation altogether via a software
emulation of a flat address space (by doing carrying arithmetic whenever
pointers, arrays or structs were derefenced) but was of course MUCH slower.

If your compiler supports these things, go ahead and use them and port
4.3BSD across, it would be great. I thought you were talking about a
smaller system like 1 Mb, with 1 Mb you could support say 3 users and a
kernel @ 256 kbytes each using a 2.11bsd-like split I/D system and a small
memory model. They could run a reasonable toolchain consisting of a shell
spawning cc spawning a compiler or linker (for example) and an editor,
simultaneously, though it would be tight. In that case I would be concerned
about speed and size and would recommend a "small" memory model. But if you
have 6 Mb and your processor is relatively fast (say 8 MHz) and your
compiler efficient, then I guess a "large" model would be reasonable. I
like tiny unices, though :)

Nick
On 09/11/2015 8:40 PM, "Oliver Lehmann" <lehmann at ans-netz.de> wrote:

>
> http://cvs.laladev.org/index.html/P8000/WEGA/src/uts/sys/ureg.c?rev=1.9&content-type=text/x-cvsweb-markup
>
> 1.9 is the current version 1.1 is the plain SysIII file...
>
>
> Oliver Lehmann <lehmann at ans-netz.de> wrote:
>
> This is for example the ureg.c which shows the Segmentation Code for the
>> current SysIII Kernel I redid from original SysIII Sources + Disassembled
>> object-File analysis of the current SysIII Kernel running on the system:
>>
>>
>> http://cvs.laladev.org/index.html/P8000/WEGA/src/uts/sys/ureg.c?rev=1.1&content-type=text/x-cvsweb-markup
>>
>>
>>
>> Oliver Lehmann <lehmann at ans-netz.de> wrote:
>>
>> I hit the send button to fast :(
>>>
>>> Oliver Lehmann <lehmann at ans-netz.de> wrote:
>>>
>>> Nick Downing <downing.nick at gmail.com> wrote:
>>>>
>>>> You can most likely implement a split I/D architecture by having code
>>>>> execute out of a different segment than data, although I haven't
>>>>> checked the datasheet so I don't know for sure if this is possible.
>>>>>
>>>>
>>>> I have 3 different MMUs available. Stack, Code and Data it is called in
>>>> the Circuit diagram. I probably have to lookup the references but I
>>>> still
>>>> don't get why the kernel can only work with 64k of RAM as it is right
>>>> now
>>>> compiled as a segmented programm and uses more memory already with
>>>> SysIII.
>>>> Only the boot0-loader is compiled unsegmented and also some small
>>>> utilities. Every other portion of the system uses the segmentation
>>>> features
>>>> of the Z8001 and is not limited to 64k adressable space.
>>>>
>>>> The system has right now MB of
>>>>
>>>
>>> The system has right now around 6 MB of RAM but can be upgraded to 16MB
>>> minus 64KB (Due to a firmware bug) of RAM.
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151110/9074cfd5/attachment.html>

From reed at reedmedia.net  Tue Nov 10 08:23:05 2015
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Mon, 9 Nov 2015 16:23:05 -0600 (CST)
Subject: [TUHS] PWB contributions
In-Reply-To: <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
Message-ID: <alpine.NEB.2.11.1511091612300.28638@t1.m.reedmedia.net>

On Sun, 8 Nov 2015, Clement T. Cole wrote:

> Doug
> 
> Eric Shienbrood originally wrote more(1) at UCB when he came as a grad 
> student.  It was based on functionality from ITS that he as used to 
> having at MIT.  Summit wrote a similar program with the same called 
> page(1) and I'm fairly sure it was few years after Eric's program. Btw 
> page(1) which did not have the same functionality (no termcap or in 
> there case terminfo yet).  Less(1) would show up a few years later and 
> replace them both.

>From my book in progress ...

-=-=-=-=-=-=

Many students were writing various pieces of software not in the context of
some larger purpose, but for their benefit. They were then included when 
Joy
% and company
collected up the existing software and distributed it.\cite{halbert1}

In the Berkeley terminal rooms, the dumb terminals beeped
incessantly so most of the bell speakers had been disconnected.
Their \emph{cr3} pager tool rang the terminal bell and waited for a carriage
return after every 24 lines.
The terminals also rang the bell when the cursor advanced near the
right margin on output or keyboard input (like a typewriter
bell).\cite{halbert-jchac1-4}

% TODO: mention cr3 stty mode?
% archives/1970s/2bsd/src/cr3.c says 22 lines and no mention of sound

So Dan Halbert\index{Halbert, Dan}.
who arrived in 1978 as a first-year graduate student,
wrote a pager called \emph{more} that printed ``--More--''
instead of ringing the bell and accepted the space
instead of carriage return to continue. Plus it could take multiple
filenames and print a line of colons around the filenames.
This was inspired by his use of the ITS timesharing systems as an
undergraduate at MIT that put a ``--MORE--'' prompt at the bottom
of the screen when displaying files.\cite{halbert-jchac1-4}

His friends and fellow graduate students, Geoff
Peck\index{Peck, Geoff} and Eric Shienbrood\index{Shienbrood, Eric},
greatly expanded it, adding various
options -- and \emph{more} was added into the next distribution.\cite{halbert1}

-=-=-=-=-=-=

Date: 17 Jun 2010
@MISC{halbert1,
  author = {Dan Halbert},
  howpublished = "Personal correspondence", 
  year = 2010,
  month = jun
}   
    
@ARTICLE{halbert-jchac1-4,
 author = "Dan Halbert",
 title = "{THE "MORE" COMMAND IN UNIX}",
 journal = "Journal of the Computer History Association of California",
 year = 1994,
 month = "April-June",
 volume = "1",
 number = "4" }

Prior to that Chuck Haley had a pager called cr3. Then Bill Joy 
simulated that with a filter "stopping output after each page (22 
lines) to wait for a carriage return, sending 22 more lines, or a EOF, 
sending 10 more lines." (That quote is from the source.)

By the way, I don't have experience with the CR3 control register, and
don't really understand what it means from the hardware perspective.




From rochkind at basepath.com  Tue Nov 10 09:02:44 2015
From: rochkind at basepath.com (Marc Rochkind)
Date: Mon, 9 Nov 2015 16:02:44 -0700
Subject: [TUHS] About SCCS (and PWB)
Message-ID: <CAOkr1zWeEvoy_7EdLP7ZbTo=6vOgy_kbr-_S5ANvR35sEF2JEg@mail.gmail.com>

I just got on this list today, and I see that Larry McVoy asks:

"I wish Marc was on this list, be fun to chat."

I'd be happy to chime in on SCCS or early PWB questions, to the extent I
remember anything.

I did see a thread about PWB contributions in which people are trying to
sort out what came from research and what from the PWB group (under Evan
Ivie). As I recall, PWB was always based on research. Dick Haight would
install the latest research system from time-to-time, and then the
so-called "PWB UNIX" was whatever he had taken from research plus stuff we
were developing, such as SCCS. Unlike, say, Columbus UNIX, our kernel
always matched research at the system call level, so there never was such a
thing as a PWB-kernel dependency.

(I think the USG system was run quite differently: They had their own
system, and would merge improvements from research into it. I could be
wrong about this, as I never worked in the USG group.)

--Marc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151109/fdb8db68/attachment.html>

From lm at mcvoy.com  Tue Nov 10 09:05:09 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 9 Nov 2015 15:05:09 -0800
Subject: [TUHS] About SCCS (and PWB)
In-Reply-To: <CAOkr1zWeEvoy_7EdLP7ZbTo=6vOgy_kbr-_S5ANvR35sEF2JEg@mail.gmail.com>
References: <CAOkr1zWeEvoy_7EdLP7ZbTo=6vOgy_kbr-_S5ANvR35sEF2JEg@mail.gmail.com>
Message-ID: <20151109230509.GC24474@mcvoy.com>

On Mon, Nov 09, 2015 at 04:02:44PM -0700, Marc Rochkind wrote:
> I just got on this list today, and I see that Larry McVoy asks:
> 
> "I wish Marc was on this list, be fun to chat."
> 
> I'd be happy to chime in on SCCS or early PWB questions, to the extent I
> remember anything.

Awesome!  How about a start of how you came up with the SCCS design,
in particular the interleaved delta format (we internally call it
"the weave")?


From rochkind at basepath.com  Tue Nov 10 09:49:32 2015
From: rochkind at basepath.com (Marc Rochkind)
Date: Mon, 9 Nov 2015 16:49:32 -0700
Subject: [TUHS] About SCCS (and PWB)
In-Reply-To: <20151109230509.GC24474@mcvoy.com>
References: <CAOkr1zWeEvoy_7EdLP7ZbTo=6vOgy_kbr-_S5ANvR35sEF2JEg@mail.gmail.com>
 <20151109230509.GC24474@mcvoy.com>
Message-ID: <CAOkr1zVwzuHNjarRxSuX9b8uuPwCqecf7rKyd5TOO4sgroEQUA@mail.gmail.com>

Since you asked, here's the true story of how I came up with the delta
encoding, a story never before told.

I was living in a garden apartment in Sayreville, NJ, and at night would
walk my girlfriend's dog along a hillside just outside our front door. It
was usually cold, I didn't like the dog (still don't like dogs), and hated
dodging the piles of dog shit while he tugged on the leash. So, as a coping
mechanism, I used to let my mind wander, and one evening it was wandering
and wondering about a problem I was struggling with, which was how to store
the source and the deltas all in the same file. (It was a "data set," on
the IBM OS/360 system we were using--we weren't on UNIX yet.)

Anyway, no doubt simultaneously with this unpleasant animal taking a shit,
I came up with idea of surrounding pieces of text with markers. (The
algorithm itself is documented in my original 1975 paper, which you can
read about here: http://basepath.com/aup/talks/SCCS-Slideshow.pdf.)

(Wouldn't this be an even better story if I said that the little piles of
dog poop on the hillside looked like markers in the soft glow of a full
moon? It's not true, but perhaps I'll tell it that way if the occasion
arises in the future.)

When I got inside, I started to sketch out how the markers might work, and
came up with interesting observation that insertion start/end markers
obviously nested, but deletion start/end markers did not nest with insert
start/end markers. This is obvious if you think about it the right way:
When you delete, the text you're deleting could have been added at various
times, but when you insert, the inserted text is always added at the same
time.

I didn't have replacement markers; insert and delete were enough, I thought.

I kept fooling around with the idea until I had an algorithm that I thought
would work to retrieve any version with a single pass. (It's in the paper,
referenced above.)

To prove the algorithm to be correct, I enumerated all possible cases of
insertions mixed in with deletions. I don't recall how many cases I had,
but I think it was around 20 or 30. Then I painstakingly went though every
case, making sure the algorithm produced the right answer. This was a rare
example of me doing actual work.

Coding it up, as I remember, was very easy, as the scheme is pretty simple.
I'm sure I had it running in SNOBOL4 in a day or two. Redesigning SCCS in C
for UNIX came maybe a year or so later, but the algorithm remained the same.

Larry very kindly says: "SCCS has interleaved deltas. It's a brilliant
design that has far far better performance than anything else out there."

Maybe it was brilliant, but I can tell you that I was just trying to pass
the time while that stupid dog did his business.

--Marc

On Mon, Nov 9, 2015 at 4:05 PM, Larry McVoy <lm at mcvoy.com> wrote:

> On Mon, Nov 09, 2015 at 04:02:44PM -0700, Marc Rochkind wrote:
> > I just got on this list today, and I see that Larry McVoy asks:
> >
> > "I wish Marc was on this list, be fun to chat."
> >
> > I'd be happy to chime in on SCCS or early PWB questions, to the extent I
> > remember anything.
>
> Awesome!  How about a start of how you came up with the SCCS design,
> in particular the interleaved delta format (we internally call it
> "the weave")?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151109/48873390/attachment.html>

From clemc at ccc.com  Tue Nov 10 11:09:18 2015
From: clemc at ccc.com (Clem Cole)
Date: Mon, 9 Nov 2015 20:09:18 -0500
Subject: [TUHS] About SCCS (and PWB)
In-Reply-To: <CAOkr1zVwzuHNjarRxSuX9b8uuPwCqecf7rKyd5TOO4sgroEQUA@mail.gmail.com>
References: <CAOkr1zWeEvoy_7EdLP7ZbTo=6vOgy_kbr-_S5ANvR35sEF2JEg@mail.gmail.com>
 <20151109230509.GC24474@mcvoy.com>
 <CAOkr1zVwzuHNjarRxSuX9b8uuPwCqecf7rKyd5TOO4sgroEQUA@mail.gmail.com>
Message-ID: <CAC20D2OTqKZ1B89usWf5_cvV4_=31E8EA1N03gFd=2D8i2Gb9g@mail.gmail.com>

Outstanding.   I love it.   You can use emoji's today and have the
scatological references inline.

Clem

On Mon, Nov 9, 2015 at 6:49 PM, Marc Rochkind <rochkind at basepath.com> wrote:

> Since you asked, here's the true story of how I came up with the delta
> encoding, a story never before told.
>
> I was living in a garden apartment in Sayreville, NJ, and at night would
> walk my girlfriend's dog along a hillside just outside our front door. It
> was usually cold, I didn't like the dog (still don't like dogs), and hated
> dodging the piles of dog shit while he tugged on the leash. So, as a coping
> mechanism, I used to let my mind wander, and one evening it was wandering
> and wondering about a problem I was struggling with, which was how to store
> the source and the deltas all in the same file. (It was a "data set," on
> the IBM OS/360 system we were using--we weren't on UNIX yet.)
>
> Anyway, no doubt simultaneously with this unpleasant animal taking a shit,
> I came up with idea of surrounding pieces of text with markers. (The
> algorithm itself is documented in my original 1975 paper, which you can
> read about here: http://basepath.com/aup/talks/SCCS-Slideshow.pdf.)
>
> (Wouldn't this be an even better story if I said that the little piles of
> dog poop on the hillside looked like markers in the soft glow of a full
> moon? It's not true, but perhaps I'll tell it that way if the occasion
> arises in the future.)
>
> When I got inside, I started to sketch out how the markers might work, and
> came up with interesting observation that insertion start/end markers
> obviously nested, but deletion start/end markers did not nest with insert
> start/end markers. This is obvious if you think about it the right way:
> When you delete, the text you're deleting could have been added at various
> times, but when you insert, the inserted text is always added at the same
> time.
>
> I didn't have replacement markers; insert and delete were enough, I
> thought.
>
> I kept fooling around with the idea until I had an algorithm that I
> thought would work to retrieve any version with a single pass. (It's in the
> paper, referenced above.)
>
> To prove the algorithm to be correct, I enumerated all possible cases of
> insertions mixed in with deletions. I don't recall how many cases I had,
> but I think it was around 20 or 30. Then I painstakingly went though every
> case, making sure the algorithm produced the right answer. This was a rare
> example of me doing actual work.
>
> Coding it up, as I remember, was very easy, as the scheme is pretty
> simple. I'm sure I had it running in SNOBOL4 in a day or two. Redesigning
> SCCS in C for UNIX came maybe a year or so later, but the algorithm
> remained the same.
>
> Larry very kindly says: "SCCS has interleaved deltas. It's a brilliant
> design that has far far better performance than anything else out there."
>
> Maybe it was brilliant, but I can tell you that I was just trying to pass
> the time while that stupid dog did his business.
>
> --Marc
>
> On Mon, Nov 9, 2015 at 4:05 PM, Larry McVoy <lm at mcvoy.com> wrote:
>
>> On Mon, Nov 09, 2015 at 04:02:44PM -0700, Marc Rochkind wrote:
>> > I just got on this list today, and I see that Larry McVoy asks:
>> >
>> > "I wish Marc was on this list, be fun to chat."
>> >
>> > I'd be happy to chime in on SCCS or early PWB questions, to the extent I
>> > remember anything.
>>
>> Awesome!  How about a start of how you came up with the SCCS design,
>> in particular the interleaved delta format (we internally call it
>> "the weave")?
>>
>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151109/89afb3f1/attachment.html>

From rochkind at basepath.com  Tue Nov 10 11:27:51 2015
From: rochkind at basepath.com (Marc Rochkind)
Date: Mon, 9 Nov 2015 18:27:51 -0700
Subject: [TUHS] About SCCS (and PWB)
In-Reply-To: <CAC20D2OTqKZ1B89usWf5_cvV4_=31E8EA1N03gFd=2D8i2Gb9g@mail.gmail.com>
References: <CAOkr1zWeEvoy_7EdLP7ZbTo=6vOgy_kbr-_S5ANvR35sEF2JEg@mail.gmail.com>
 <20151109230509.GC24474@mcvoy.com>
 <CAOkr1zVwzuHNjarRxSuX9b8uuPwCqecf7rKyd5TOO4sgroEQUA@mail.gmail.com>
 <CAC20D2OTqKZ1B89usWf5_cvV4_=31E8EA1N03gFd=2D8i2Gb9g@mail.gmail.com>
Message-ID: <CAOkr1zU18Lc0q1K5ZLCwsm2x9a6a0-3C5MDeL-BNNQ6142Q4Sw@mail.gmail.com>

💩
On Nov 9, 2015 6:09 PM, "Clem Cole" <clemc at ccc.com> wrote:

> Outstanding.   I love it.   You can use emoji's today and have the
> scatological references inline.
>
> Clem
>
> On Mon, Nov 9, 2015 at 6:49 PM, Marc Rochkind <rochkind at basepath.com>
> wrote:
>
>> Since you asked, here's the true story of how I came up with the delta
>> encoding, a story never before told.
>>
>> I was living in a garden apartment in Sayreville, NJ, and at night would
>> walk my girlfriend's dog along a hillside just outside our front door. It
>> was usually cold, I didn't like the dog (still don't like dogs), and hated
>> dodging the piles of dog shit while he tugged on the leash. So, as a coping
>> mechanism, I used to let my mind wander, and one evening it was wandering
>> and wondering about a problem I was struggling with, which was how to store
>> the source and the deltas all in the same file. (It was a "data set," on
>> the IBM OS/360 system we were using--we weren't on UNIX yet.)
>>
>> Anyway, no doubt simultaneously with this unpleasant animal taking a
>> shit, I came up with idea of surrounding pieces of text with markers. (The
>> algorithm itself is documented in my original 1975 paper, which you can
>> read about here: http://basepath.com/aup/talks/SCCS-Slideshow.pdf.)
>>
>> (Wouldn't this be an even better story if I said that the little piles of
>> dog poop on the hillside looked like markers in the soft glow of a full
>> moon? It's not true, but perhaps I'll tell it that way if the occasion
>> arises in the future.)
>>
>> When I got inside, I started to sketch out how the markers might work,
>> and came up with interesting observation that insertion start/end markers
>> obviously nested, but deletion start/end markers did not nest with insert
>> start/end markers. This is obvious if you think about it the right way:
>> When you delete, the text you're deleting could have been added at various
>> times, but when you insert, the inserted text is always added at the same
>> time.
>>
>> I didn't have replacement markers; insert and delete were enough, I
>> thought.
>>
>> I kept fooling around with the idea until I had an algorithm that I
>> thought would work to retrieve any version with a single pass. (It's in the
>> paper, referenced above.)
>>
>> To prove the algorithm to be correct, I enumerated all possible cases of
>> insertions mixed in with deletions. I don't recall how many cases I had,
>> but I think it was around 20 or 30. Then I painstakingly went though every
>> case, making sure the algorithm produced the right answer. This was a rare
>> example of me doing actual work.
>>
>> Coding it up, as I remember, was very easy, as the scheme is pretty
>> simple. I'm sure I had it running in SNOBOL4 in a day or two. Redesigning
>> SCCS in C for UNIX came maybe a year or so later, but the algorithm
>> remained the same.
>>
>> Larry very kindly says: "SCCS has interleaved deltas. It's a brilliant
>> design that has far far better performance than anything else out there."
>>
>> Maybe it was brilliant, but I can tell you that I was just trying to pass
>> the time while that stupid dog did his business.
>>
>> --Marc
>>
>> On Mon, Nov 9, 2015 at 4:05 PM, Larry McVoy <lm at mcvoy.com> wrote:
>>
>>> On Mon, Nov 09, 2015 at 04:02:44PM -0700, Marc Rochkind wrote:
>>> > I just got on this list today, and I see that Larry McVoy asks:
>>> >
>>> > "I wish Marc was on this list, be fun to chat."
>>> >
>>> > I'd be happy to chime in on SCCS or early PWB questions, to the extent
>>> I
>>> > remember anything.
>>>
>>> Awesome!  How about a start of how you came up with the SCCS design,
>>> in particular the interleaved delta format (we internally call it
>>> "the weave")?
>>>
>>
>>
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151109/6acd29fd/attachment.html>

From random832 at fastmail.com  Tue Nov 10 14:11:42 2015
From: random832 at fastmail.com (Random832)
Date: Mon, 09 Nov 2015 23:11:42 -0500
Subject: [TUHS] PWB contributions
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
 <alpine.NEB.2.11.1511091612300.28638@t1.m.reedmedia.net>
Message-ID: <87r3jyfq81.fsf@fastmail.com>

"Jeremy C. Reed" <reed at reedmedia.net> writes:
> By the way, I don't have experience with the CR3 control register, and
> don't really understand what it means from the hardware perspective.

If I understand correctly, it's not hardware, it's part of the kernel
tty driver. There's a two bit field in the stty flags, for selecting a
delay mode. The purpose of the delay was to allow the terminal time to
process it (i.e. to physically move the carriage, for a printing
terminal) - the kernel would wait before sending more characters.

As can be seen in tty.c (link below), CR1 caused a delay of 5 units, and
CR2 a delay of 10 units. CR3 had no meaning in the standard kernel, and
so some custom version of the kernel could have interpreted it to have
some other meaning.

http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/dev/tty.c

It's not clear where this was actually done. The 3BSD kernel used
CR3 to indicate that (if I read it correctly) a number of padding
characters depending on the column position should be inserted.

P.S. Somewhat confusingly, searching for "CR3" finds a page about
"control registers" of the _intel 386_, of which CR3 has something to do
with "paging" in the virtual memory sense of the word. This has nothing
to do with the topic under discussion.



From meillo at marmaro.de  Wed Nov 11 06:26:36 2015
From: meillo at marmaro.de (markus schnalke)
Date: Tue, 10 Nov 2015 21:26:36 +0100
Subject: [TUHS] A portrait of cut(1)  (was: PWB contributions)
In-Reply-To: <201511091358.tA9Dw35f010741@coolidge.cs.Dartmouth.EDU>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
 <201511091358.tA9Dw35f010741@coolidge.cs.Dartmouth.EDU>
Message-ID: <1ZwFUy-77P-00@marmaro.de>

[2015-11-09 08:58] Doug McIlroy <doug at cs.dartmouth.edu>
> 
> things like "cut" and "paste", whose exact provenance
> I can't recall.

Thanks for reminding me that I wanted to share my portrait of
cut(1) with you. (I sent some questions to this list, a few
months ago, remember?) Now, here it is:

	http://marmaro.de/docs/freiesmagazin/cut/cut.en.pdf

Hope you like it.


meillo


From clemc at ccc.com  Wed Nov 11 08:10:52 2015
From: clemc at ccc.com (Clem Cole)
Date: Tue, 10 Nov 2015 17:10:52 -0500
Subject: [TUHS] A portrait of cut(1) (was: PWB contributions)
In-Reply-To: <1ZwFUy-77P-00@marmaro.de>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
 <201511091358.tA9Dw35f010741@coolidge.cs.Dartmouth.EDU>
 <1ZwFUy-77P-00@marmaro.de>
Message-ID: <CAC20D2PC1HsHHAmkPD09TygLg4V0iaPwAKk5Ok7aUmfPFEyGmw@mail.gmail.com>

On Tue, Nov 10, 2015 at 3:26 PM, markus schnalke <meillo at marmaro.de> wrote:

> http://marmaro.de/docs/freiesmagazin/cut/cut.en.pdf


​Fascinating ​- thanks for sharing.
Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151110/7a172862/attachment.html>

From akosela at andykosela.com  Wed Nov 11 09:10:10 2015
From: akosela at andykosela.com (Andy Kosela)
Date: Wed, 11 Nov 2015 00:10:10 +0100
Subject: [TUHS] A portrait of cut(1) (was: PWB contributions)
In-Reply-To: <1ZwFUy-77P-00@marmaro.de>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
 <201511091358.tA9Dw35f010741@coolidge.cs.Dartmouth.EDU>
 <1ZwFUy-77P-00@marmaro.de>
Message-ID: <CALMnNGhrvp3n04fiV43CsEEYp44eYLOyQ5d6YbKvV8W_qFaDXg@mail.gmail.com>

On Tue, Nov 10, 2015 at 9:26 PM, markus schnalke <meillo at marmaro.de> wrote:
> [2015-11-09 08:58] Doug McIlroy <doug at cs.dartmouth.edu>
>>
>> things like "cut" and "paste", whose exact provenance
>> I can't recall.
>
> Thanks for reminding me that I wanted to share my portrait of
> cut(1) with you. (I sent some questions to this list, a few
> months ago, remember?) Now, here it is:
>
>         http://marmaro.de/docs/freiesmagazin/cut/cut.en.pdf
>
> Hope you like it.

Great read.  I always liked cut(1).

--Andy


From cowan at mercury.ccil.org  Wed Nov 11 09:12:21 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Tue, 10 Nov 2015 18:12:21 -0500
Subject: [TUHS] A portrait of cut(1) (was: PWB contributions)
In-Reply-To: <CALMnNGhrvp3n04fiV43CsEEYp44eYLOyQ5d6YbKvV8W_qFaDXg@mail.gmail.com>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
 <201511091358.tA9Dw35f010741@coolidge.cs.Dartmouth.EDU>
 <1ZwFUy-77P-00@marmaro.de>
 <CALMnNGhrvp3n04fiV43CsEEYp44eYLOyQ5d6YbKvV8W_qFaDXg@mail.gmail.com>
Message-ID: <20151110231221.GF28365@mercury.ccil.org>

Andy Kosela scripsit:

> Great read.  I always liked cut(1).

The fact that it refuses to reorder fields is kinda annoying, though.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
You annoy me, Rattray!  You disgust me! You irritate me unspeakably!
Thank Heaven, I am a man of equable temper, or I should scarcely be able
to contain myself before your mocking visage.  --Stalky imitating Macrea


From lm at mcvoy.com  Wed Nov 11 09:34:10 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Tue, 10 Nov 2015 15:34:10 -0800
Subject: [TUHS] A portrait of cut(1) (was: PWB contributions)
In-Reply-To: <20151110231221.GF28365@mercury.ccil.org>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
 <201511091358.tA9Dw35f010741@coolidge.cs.Dartmouth.EDU>
 <1ZwFUy-77P-00@marmaro.de>
 <CALMnNGhrvp3n04fiV43CsEEYp44eYLOyQ5d6YbKvV8W_qFaDXg@mail.gmail.com>
 <20151110231221.GF28365@mercury.ccil.org>
Message-ID: <20151110233410.GB11631@mcvoy.com>

On Tue, Nov 10, 2015 at 06:12:21PM -0500, John Cowan wrote:
> Andy Kosela scripsit:
> 
> > Great read.  I always liked cut(1).
> 
> The fact that it refuses to reorder fields is kinda annoying, though.

cut .... | awk '{print $2,$1}'

?


From cowan at mercury.ccil.org  Wed Nov 11 09:39:16 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Tue, 10 Nov 2015 18:39:16 -0500
Subject: [TUHS] A portrait of cut(1) (was: PWB contributions)
In-Reply-To: <20151110233410.GB11631@mcvoy.com>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
 <201511091358.tA9Dw35f010741@coolidge.cs.Dartmouth.EDU>
 <1ZwFUy-77P-00@marmaro.de>
 <CALMnNGhrvp3n04fiV43CsEEYp44eYLOyQ5d6YbKvV8W_qFaDXg@mail.gmail.com>
 <20151110231221.GF28365@mercury.ccil.org>
 <20151110233410.GB11631@mcvoy.com>
Message-ID: <20151110233916.GG28365@mercury.ccil.org>

Larry McVoy scripsit:

> cut .... | awk '{print $2,$1}'

I didn't say there was no workaround.  But obviously "cut -f 3,2,1"
expresses a particular intention which (by design) cut will not satisfy.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Pour moi, les villes du Silmarillion ont plus de realite que Babylone.
                --Christopher Tolkien, as interviewed by Le Monde


From random832 at fastmail.com  Wed Nov 11 10:16:01 2015
From: random832 at fastmail.com (Random832)
Date: Tue, 10 Nov 2015 19:16:01 -0500
Subject: [TUHS] A portrait of cut(1)
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
 <201511091358.tA9Dw35f010741@coolidge.cs.Dartmouth.EDU>
 <1ZwFUy-77P-00@marmaro.de>
Message-ID: <87twotfl1a.fsf@fastmail.com>

markus schnalke <meillo at marmaro.de> writes:
> [2015-11-09 08:58] Doug McIlroy <doug at cs.dartmouth.edu>
>> things like "cut" and "paste", whose exact provenance
>> I can't recall.
>
> Thanks for reminding me that I wanted to share my portrait of
> cut(1) with you. (I sent some questions to this list, a few
> months ago, remember?) Now, here it is:
>
> 	http://marmaro.de/docs/freiesmagazin/cut/cut.en.pdf

Did you happen to find out what GWRL stands for, in the the comments at
the top of early versions of cut.c and paste.c?

/* cut : cut and paste columns of a table (projection of a relation) (GWRL) */
/* Release 1.5; handles single backspaces as produced by nroff    */
/* paste: concatenate corresponding lines of each file in parallel. Release 1.4 (GWRL) */
/*        (-s option: serial concatenation like old (127's) paste command */

For that matter, what's the "old (127's) paste command" it refers to?



From ckeck at texoma.net  Wed Nov 11 11:54:04 2015
From: ckeck at texoma.net (Cornelius Keck)
Date: Tue, 10 Nov 2015 20:54:04 -0500
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
Message-ID: <18ccc50ef61f0eebe11b7f1b925e7b33.squirrel@mail.texoma.net>

Z8001 with SysIII, what hardware is that? Sounds a bit like Commodore's
CBM900, but that ran Coherent 0.7.3 or so, was actually fairly snappy for
its time. Coherent roughly resembled Unix System 7. Didn't have an IP
stack.

On Sat, November 7, 2015 14:03, Oliver Lehmann wrote:
> Hi,
>
>
> i have an old Z8001 based SysIII variant and I would love to have TCP/IP
> on it (SLIP first, later with a homebrew ethernet device).
>
> I wonder if someone ever saw TCP/IP available on a System III?
>
>
> I have lets say 90% of the kernel running on it as source
> available and I started digging in the available 4.2 BSD sources.
>
> It looks like there would be much to do to hack in TCP/IP on my
> own (no IPC, no Net, no PTY, no....).
>
> I got K5JB running (userland TCP/IP implementation) after I fixed
> some C code because the C Compiler available on the system is..... kinda
> limited.
>
> telnetd is of course not working as there are no pseudo-teletypes on this
> SYSIII. At least I got ping, echoping and ftpd up and
> running via SLIP
>
> (10.1.1.2 is my SysIII box:)
>
>
> # ping -c3 10.1.1.2
> PING 10.1.1.2 (10.1.1.2): 56 data bytes
> 64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms
> 64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms
> 64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms
>
>
> --- 10.1.1.2 ping statistics ---
> 3 packets transmitted, 3 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms # ftp
> 10.1.1.2
> Connected to 10.1.1.2.
> 220  FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991
> Name (10.1.1.2:root): test
> 331 Enter PASS command
> Password:
> 230 Logged in
> ftp> get sa.timer local: sa.timer remote: sa.timer
> 500 Unknown command
> 500 Unknown command
> 200 Port command okay
> 150 Opening data connection for RETR sa.timer
> 2571       0.53 KB/s
> 226 File sent OK
> 2571 bytes received in 00:05 (0.48 KB/s)
> ftp> get wega local: wega remote: wega
> 200 Port command okay
> 150 Opening data connection for RETR wega
> 98723       0.51 KB/s
> 226 File sent OK
> 98723 bytes received in 03:05 (0.51 KB/s)
> ftp> exit 221 Goodbye!
> #
>
>
> So I wonder if someone got anything SYSIII -> Net/TCP/IP related
> which could help me in any way to get a SYSIII kernel capable of TCP/IP and
> PTYs to get a telnetd up and running via SLIP is my
> first goal.
>
> Regards,
> Oliver
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>




From lehmann at ans-netz.de  Wed Nov 11 16:46:29 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Wed, 11 Nov 2015 07:46:29 +0100
Subject: [TUHS] System III - TCP/IP
In-Reply-To: <18ccc50ef61f0eebe11b7f1b925e7b33.squirrel@mail.texoma.net>
References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net>
 <18ccc50ef61f0eebe11b7f1b925e7b33.squirrel@mail.texoma.net>
Message-ID: <20151111074629.Horde.tahOW-1_p1N21XPnfd2vPA8@avocado.salatschuessel.net>

Hi Cornelius,

the system is more or less a clone of the Zilog System 8000 which ran ZEUS.
The clone was made in the eastern part of germany behind the iron curtain.
The 16Bit part of the system is more or less a 1:1 clone of the System 8000
and so is the OS also a clone of ZEUS (with modified part of the kernel to
adress the differences in hardware). If you are more interested about the
system itself, feel free to read more on my page (page itself is english,
but most linked documents are in german)

http://www.pofo.de/P8000/

Regards,
Oliver

Cornelius Keck <ckeck at texoma.net> wrote:

> Z8001 with SysIII, what hardware is that? Sounds a bit like Commodore's
> CBM900, but that ran Coherent 0.7.3 or so, was actually fairly snappy for
> its time. Coherent roughly resembled Unix System 7. Didn't have an IP
> stack.
>
> On Sat, November 7, 2015 14:03, Oliver Lehmann wrote:
>> Hi,
>>
>>
>> i have an old Z8001 based SysIII variant and I would love to have TCP/IP
>> on it (SLIP first, later with a homebrew ethernet device).
>>
>> I wonder if someone ever saw TCP/IP available on a System III?
>>
>>
>> I have lets say 90% of the kernel running on it as source
>> available and I started digging in the available 4.2 BSD sources.
>>
>> It looks like there would be much to do to hack in TCP/IP on my
>> own (no IPC, no Net, no PTY, no....).
>>
>> I got K5JB running (userland TCP/IP implementation) after I fixed
>> some C code because the C Compiler available on the system is..... kinda
>> limited.
>>
>> telnetd is of course not working as there are no pseudo-teletypes on this
>> SYSIII. At least I got ping, echoping and ftpd up and
>> running via SLIP
>>
>> (10.1.1.2 is my SysIII box:)
>>
>>
>> # ping -c3 10.1.1.2
>> PING 10.1.1.2 (10.1.1.2): 56 data bytes
>> 64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms
>> 64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms
>> 64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms
>>
>>
>> --- 10.1.1.2 ping statistics ---
>> 3 packets transmitted, 3 packets received, 0.0% packet loss
>> round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms # ftp
>> 10.1.1.2
>> Connected to 10.1.1.2.
>> 220  FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991
>> Name (10.1.1.2:root): test
>> 331 Enter PASS command
>> Password:
>> 230 Logged in
>> ftp> get sa.timer local: sa.timer remote: sa.timer
>> 500 Unknown command
>> 500 Unknown command
>> 200 Port command okay
>> 150 Opening data connection for RETR sa.timer
>> 2571       0.53 KB/s
>> 226 File sent OK
>> 2571 bytes received in 00:05 (0.48 KB/s)
>> ftp> get wega local: wega remote: wega
>> 200 Port command okay
>> 150 Opening data connection for RETR wega
>> 98723       0.51 KB/s
>> 226 File sent OK
>> 98723 bytes received in 03:05 (0.51 KB/s)
>> ftp> exit 221 Goodbye!
>> #
>>
>>
>> So I wonder if someone got anything SYSIII -> Net/TCP/IP related
>> which could help me in any way to get a SYSIII kernel capable of TCP/IP and
>> PTYs to get a telnetd up and running via SLIP is my
>> first goal.
>>
>> Regards,
>> Oliver
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>
>>




From meillo at marmaro.de  Wed Nov 11 22:23:18 2015
From: meillo at marmaro.de (markus schnalke)
Date: Wed, 11 Nov 2015 13:23:18 +0100
Subject: [TUHS] A portrait of cut(1)
In-Reply-To: <87twotfl1a.fsf@fastmail.com>
References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU>
 <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com>
 <201511091358.tA9Dw35f010741@coolidge.cs.Dartmouth.EDU>
 <1ZwFUy-77P-00@marmaro.de> <87twotfl1a.fsf@fastmail.com>
Message-ID: <1ZwUQo-5Yl-00@marmaro.de>

[2015-11-10 19:16] Random832 <random832 at fastmail.com>
> 
> Did you happen to find out what GWRL stands for, in the the comments at
> the top of early versions of cut.c and paste.c?
> 
> /* cut : cut and paste columns of a table (projection of a relation) (GWRL) *
> /
> /* Release 1.5; handles single backspaces as produced by nroff    */
> /* paste: concatenate corresponding lines of each file in parallel. Release 1.4 (GWRL) */
> /*        (-s option: serial concatenation like old (127's) paste command */
> 
> For that matter, what's the "old (127's) paste command" it refers to?

Unfortunately I have no clue, for neither of them.

To resolve ``GWRL'', insider knowledge seems to be needed. (Or a cool
party with creative buddies, of course! (Today's the opening of the
carnival season in Germany ... that could be an opportunity. :-D ))

``127'', whatever system that might be, it surely predates UNIX.
Background knowledge from the time back then will be necessary.

I can provide neither of them ... and searching for such stuff is
difficult because the terms and their context are too generic.
(``cut and paste'' is by no means a valuable context if you try
to search for it. ;-) )

Maybe someone older or more inside has some ideas ...


meillo


From norman at oclsc.org  Wed Nov 11 22:41:13 2015
From: norman at oclsc.org (Norman Wilson)
Date: Wed, 11 Nov 2015 07:41:13 -0500
Subject: [TUHS] A portrait of cut(1)
Message-ID: <1447245676.11216.for-standards-violators@oclsc.org>

  For that matter, what's the "old (127's) paste command" it refers to?

Every organization at AT&T had a number as well as a name.
In the early days of UNIX, the number for Computer Science
Research was 127.  At some point a 1 was prepended, making
it 1127, but old-timers still used the three-digit code.

So it's a good guess that `127's paste command' means
one that came from, or had been modified in, Research.

I don't know when or where, though.  I don't see a paste
command in V7.  paste.c in V8 has exactly the same comment
at the top.

Norman Wilson
Toronto ON


From doug at cs.dartmouth.edu  Thu Nov 12 12:11:53 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 11 Nov 2015 21:11:53 -0500
Subject: [TUHS] Subject:  Re:  A portrait of cut(1)
Message-ID: <201511120211.tAC2Br92003895@coolidge.cs.Dartmouth.EDU>

> /*        (-s option: serial concatenation like old (127's) paste command */
>
> For that matter, what's the "old (127's) paste command" it refers to?

I can't remember 127 ever having a "paste" command. We did have "ov",
which overlaid adjacent pairs of formatted pages to make two-column
text. "Serial concatenation" would seem to be what was done by "pr"
or "cat".

"ov" figured in the flurry of demos on the day of pipes' birth.
        nroff | ov | ov
made four-column output.


From cubexyz at gmail.com  Fri Nov 13 12:38:12 2015
From: cubexyz at gmail.com (Mark Longridge)
Date: Thu, 12 Nov 2015 21:38:12 -0500
Subject: [TUHS] Backport cut to V7
Message-ID: <CADxT5N4ggDbxvbeAfwS76p4KA1vZQM3yOoeZaSQBnnqU=jWSJA@mail.gmail.com>

I'm not sure how old cut is, but a quick look at the code gave me the
idea it could be backported to V7, as I'm fairly sure that cut wasn't
in V7.

It doesn't look like it needs a lot of stuff, just fclose, puts, do
and while loops. Even a  v6 or v5 backport doesn't seem too difficult.

Mark


From ron at ronnatalie.com  Sat Nov 14 03:56:26 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Fri, 13 Nov 2015 12:56:26 -0500
Subject: [TUHS] Backport cut to V7
In-Reply-To: <CADxT5N4ggDbxvbeAfwS76p4KA1vZQM3yOoeZaSQBnnqU=jWSJA@mail.gmail.com>
References: <CADxT5N4ggDbxvbeAfwS76p4KA1vZQM3yOoeZaSQBnnqU=jWSJA@mail.gmail.com>
Message-ID: <51DEFF94-4CE1-40BA-8BCC-5FF04A8B9EFB@ronnatalie.com>

If you’re starting with the PWB application, it’s not even a back port really.   PWB was a sort of V6-ish development environment, sort of a front port.

> 
> I'm not sure how old cut is, but a quick look at the code gave me the
> idea it could be backported to V7, as I'm fairly sure that cut wasn't
> in V7.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151113/49ef0dd9/attachment.bin>

From lehmann at ans-netz.de  Sat Nov 14 04:48:35 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Fri, 13 Nov 2015 19:48:35 +0100
Subject: [TUHS] user struct on SYSIII / V7
Message-ID: <20151113194835.Horde.-ghfy1raSZPIb62MtEVbn0A@avocado.salatschuessel.net>

Hi,

does someone know where "u" is defined on SYSIII or V7?

sys/user.h states:

extern struct user u;

But I wonder where it is defined? On ZEUS I have u.o but I'm
not able to correctly disassemble it. Right now I'm guessing
that it should be something like:

u module
$segmented
$abs %F600

   global

_u array [%572 byte]

end u

But the resulting object (u.o.hd) does not match 100% the existing
u.o on the system (u.o.orig.hd).

--- u.o.orig.hd 2008-05-16 21:52:12.000000000 +0200
+++ u.o.hd      2008-05-16 21:52:16.000000000 +0200
@@ -3,6 +3,6 @@
  00000020  00 00 00 01 00 00 00 00  01 00 00 00 00 00 00 00   
|................|
  00000030  00 00 00 02 00 00 00 00  00 00 00 00 1e 00 75 5f   
|..............u_|
  00000040  70 00 00 00 00 00 01 00  00 00 1e 01 75 5f 64 00   
|p...........u_d.|
-00000050  00 00 00 00 3e 00 f6 00  61 3e 5f 75 00 00 00 00  |....>..a>_u....|
+00000050  00 00 00 00 01 00 f6 00  61 01 5f 75 00 00 00 00  |.......a._u....|
  00000060  00 00                                             |..|
  00000062


From ron at ronnatalie.com  Sat Nov 14 04:51:17 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Fri, 13 Nov 2015 13:51:17 -0500
Subject: [TUHS] user struct on SYSIII / V7
In-Reply-To: <20151113194835.Horde.-ghfy1raSZPIb62MtEVbn0A@avocado.salatschuessel.net>
References: <20151113194835.Horde.-ghfy1raSZPIb62MtEVbn0A@avocado.salatschuessel.net>
Message-ID: <5F23773C-A448-4AC7-AE26-70A3CBF769B8@ronnatalie.com>


> On Nov 13, 2015, at 1:48 PM, Oliver Lehmann <lehmann at ans-netz.de> wrote:
> 
> Hi,
> 
> does someone know where "u" is defined on SYSIII or V7?
> 
> sys/user.h states:
> 
> extern struct user u;
> 
> But I wonder where it is defined? On ZEUS I have u.o but I'm
> not able to correctly disassemble it. Right now I'm guessing
> that it should be something like:
> 

In Version 7 it’s in /usr/sys/h/user.h



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151113/aff2c927/attachment.bin>

From ron at ronnatalie.com  Sat Nov 14 04:53:14 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Fri, 13 Nov 2015 13:53:14 -0500
Subject: [TUHS] user struct on SYSIII / V7
In-Reply-To: <5F23773C-A448-4AC7-AE26-70A3CBF769B8@ronnatalie.com>
References: <20151113194835.Horde.-ghfy1raSZPIb62MtEVbn0A@avocado.salatschuessel.net>
 <5F23773C-A448-4AC7-AE26-70A3CBF769B8@ronnatalie.com>
Message-ID: <C2DAF190-872B-4CBC-9C96-B901A0F96B67@ronnatalie.com>

>> 
> 
> In Version 7 it’s in /usr/sys/h/user.h
> 
> 
And in System III it is in /usr/include/sys/user.h

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151113/2811788b/attachment.bin>

From lehmann at ans-netz.de  Sat Nov 14 05:12:31 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Fri, 13 Nov 2015 20:12:31 +0100
Subject: [TUHS] user struct on SYSIII / V7
In-Reply-To: <5F23773C-A448-4AC7-AE26-70A3CBF769B8@ronnatalie.com>
References: <20151113194835.Horde.-ghfy1raSZPIb62MtEVbn0A@avocado.salatschuessel.net>
 <5F23773C-A448-4AC7-AE26-70A3CBF769B8@ronnatalie.com>
Message-ID: <20151113201231.Horde.a7a9Nc2HERUIJNolisTv8Lz@avocado.salatschuessel.net>


Ronald Natalie <ron at ronnatalie.com> wrote:

>> On Nov 13, 2015, at 1:48 PM, Oliver Lehmann <lehmann at ans-netz.de> wrote:
>>
>> Hi,
>>
>> does someone know where "u" is defined on SYSIII or V7?
>>
>> sys/user.h states:
>>
>> extern struct user u;
>>
>> But I wonder where it is defined? On ZEUS I have u.o but I'm
>> not able to correctly disassemble it. Right now I'm guessing
>> that it should be something like:
>>
>
> In Version 7 it’s in /usr/sys/h/user.h

There is the  definition of the user struct  and the declaration of
"u" as _external_ variable. I'm looking for the place where u is
"implemented". Without a definition of "u" somewhere _u will caus
a symbol undefined error.


From ron at ronnatalie.com  Sat Nov 14 05:15:31 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Fri, 13 Nov 2015 14:15:31 -0500
Subject: [TUHS] user struct on SYSIII / V7
In-Reply-To: <20151113201231.Horde.a7a9Nc2HERUIJNolisTv8Lz@avocado.salatschuessel.net>
References: <20151113194835.Horde.-ghfy1raSZPIb62MtEVbn0A@avocado.salatschuessel.net>
 <5F23773C-A448-4AC7-AE26-70A3CBF769B8@ronnatalie.com>
 <20151113201231.Horde.a7a9Nc2HERUIJNolisTv8Lz@avocado.salatschuessel.net>
Message-ID: <9E1EC0BB-A9E1-41D9-90DD-33D1E275ABD5@ronnatalie.com>

Someone “sanitized” your include directory.

Take a look here in the browsable archives...http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/include/sys/user.h <http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/include/sys/user.h>

> On Nov 13, 2015, at 2:12 PM, Oliver Lehmann <lehmann at ans-netz.de> wrote:
> 
> 
> Ronald Natalie <ron at ronnatalie.com> wrote:
> 
>>> On Nov 13, 2015, at 1:48 PM, Oliver Lehmann <lehmann at ans-netz.de> wrote:
>>> 
>>> Hi,
>>> 
>>> does someone know where "u" is defined on SYSIII or V7?
>>> 
>>> sys/user.h states:
>>> 
>>> extern struct user u;
>>> 
>>> But I wonder where it is defined? On ZEUS I have u.o but I'm
>>> not able to correctly disassemble it. Right now I'm guessing
>>> that it should be something like:
>>> 
>> 
>> In Version 7 it’s in /usr/sys/h/user.h
> 
> There is the  definition of the user struct  and the declaration of
> "u" as _external_ variable. I'm looking for the place where u is
> "implemented". Without a definition of "u" somewhere _u will caus
> a symbol undefined error.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151113/5814de14/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151113/5814de14/attachment.bin>

From lehmann at ans-netz.de  Sat Nov 14 05:27:54 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Fri, 13 Nov 2015 20:27:54 +0100
Subject: [TUHS] user struct on SYSIII / V7
In-Reply-To: <9E1EC0BB-A9E1-41D9-90DD-33D1E275ABD5@ronnatalie.com>
References: <20151113194835.Horde.-ghfy1raSZPIb62MtEVbn0A@avocado.salatschuessel.net>
 <5F23773C-A448-4AC7-AE26-70A3CBF769B8@ronnatalie.com>
 <20151113201231.Horde.a7a9Nc2HERUIJNolisTv8Lz@avocado.salatschuessel.net>
 <9E1EC0BB-A9E1-41D9-90DD-33D1E275ABD5@ronnatalie.com>
Message-ID: <20151113202754.Horde.0UIcoCQhpuBwcwWI3juWh_9@avocado.salatschuessel.net>


Ronald Natalie <ron at ronnatalie.com> wrote:

> Someone “sanitized” your include directory.
>
> Take a look here in the browsable  
> archives...http://minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/include/sys/user.h

Where do you see u defined? I only see it declared as external:

extern struct user u;

You need one single global u definition (memory reservation) so all
sources accessing u accessing the same struct, don't you? At least
this is what I have here and there is also the memory adress in my
param.h:

# define UBASE             0x3E00F600      /* kernel virtual addr of  
user struct */

This is where "u" is located on my system.


From lehmann at ans-netz.de  Sat Nov 14 05:33:20 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Fri, 13 Nov 2015 20:33:20 +0100
Subject: [TUHS] user struct on SYSIII / V7
In-Reply-To: <20151113194835.Horde.-ghfy1raSZPIb62MtEVbn0A@avocado.salatschuessel.net>
Message-ID: <20151113203320.Horde.VokfqdGcy16czyeqhojbDVa@avocado.salatschuessel.net>


Oliver Lehmann <lehmann at ans-netz.de> wrote:

> u module
> $segmented
> $abs %F600
>
>   global
>
> _u array [%572 byte]
>
> end u

By any way - is here someone on the list understanding Z8000 PLZ/ASM? ;)

The problem is, that "u" must be available in the address space on this
location for the kernel to function correctly:

# define UBASE             0x3E00F600      /* kernel virtual addr of  
user struct */

And with the above ASM code, it is placed on 0x0100F600. I also tried
of course $abs 0x3E00F600 but it makes no difference. It is always
placed at 0x0100F600 and I have zero clue why

the original object from the system:

#67 nm /usr/sys/conf/u.o
3e00f600 A _u
01000000 s u_d
     0000 s u_p


my object generated from my u.s:

#68 nm u.o
0100f600 A _u
01000000 s u_d
     0000 s u_p

Somehow I need to get the address right.... This is why I wanted to
look up how the original SYSIII or V7 was doing it (even if the asm
would be of course completely different).


From lehmann at ans-netz.de  Sat Nov 14 06:07:42 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Fri, 13 Nov 2015 21:07:42 +0100
Subject: [TUHS] user struct on SYSIII / V7
In-Reply-To: <20151113203320.Horde.VokfqdGcy16czyeqhojbDVa@avocado.salatschuessel.net>
References: <20151113194835.Horde.-ghfy1raSZPIb62MtEVbn0A@avocado.salatschuessel.net>
 <20151113203320.Horde.VokfqdGcy16czyeqhojbDVa@avocado.salatschuessel.net>
Message-ID: <20151113210742.Horde.QVAGJ_n38SOOv-KfmUDyOxj@avocado.salatschuessel.net>

Hi,

I found out so far, that %3e00.... means, that the data is put on
segment 62 (0x3e). Regarding to the Z8000 ASM handbook, segmented
adresses are notated as <<segment>>offset, so in my case
<<62>>%F600 - but of course it does not work and the assembler
yields and error :(


Oliver Lehmann <lehmann at ans-netz.de> wrote:

> Oliver Lehmann <lehmann at ans-netz.de> wrote:
>
>> u module
>> $segmented
>> $abs %F600
>>
>>  global
>>
>> _u array [%572 byte]
>>
>> end u
>
> By any way - is here someone on the list understanding Z8000 PLZ/ASM? ;)
>
> The problem is, that "u" must be available in the address space on this
> location for the kernel to function correctly:
>
> # define UBASE             0x3E00F600      /* kernel virtual addr of  
> user struct */
>
> And with the above ASM code, it is placed on 0x0100F600. I also tried
> of course $abs 0x3E00F600 but it makes no difference. It is always
> placed at 0x0100F600 and I have zero clue why
>
> the original object from the system:
>
> #67 nm /usr/sys/conf/u.o
> 3e00f600 A _u
> 01000000 s u_d
>     0000 s u_p
>
>
> my object generated from my u.s:
>
> #68 nm u.o
> 0100f600 A _u
> 01000000 s u_d
>     0000 s u_p
>
> Somehow I need to get the address right.... This is why I wanted to
> look up how the original SYSIII or V7 was doing it (even if the asm
> would be of course completely different).
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs




From ron at ronnatalie.com  Sat Nov 14 06:16:34 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Fri, 13 Nov 2015 15:16:34 -0500
Subject: [TUHS] user struct on SYSIII / V7
In-Reply-To: <20151113202754.Horde.0UIcoCQhpuBwcwWI3juWh_9@avocado.salatschuessel.net>
References: <20151113194835.Horde.-ghfy1raSZPIb62MtEVbn0A@avocado.salatschuessel.net>
 <5F23773C-A448-4AC7-AE26-70A3CBF769B8@ronnatalie.com>
 <20151113201231.Horde.a7a9Nc2HERUIJNolisTv8Lz@avocado.salatschuessel.net>
 <9E1EC0BB-A9E1-41D9-90DD-33D1E275ABD5@ronnatalie.com>
 <20151113202754.Horde.0UIcoCQhpuBwcwWI3juWh_9@avocado.salatschuessel.net>
Message-ID: <4D2BAFF1-8A2C-42A4-9C42-102D2E6F109F@ronnatalie.com>

I can’t say how the Z8000 wants to implement it.   On the PDP11, the _u variable is set to the absolute 140000.   This isn’t really an “allocation.”  It’s just the base of one of the kernel address segments.   The kernel maps the per process data area (essentially the user structure and the kernel stack) there.    It’s just allocated as a hunk of usize memory (usize is in 64 byte chunks on the PDP).   The code one is “not expected to understand” handles this context switch.   In fact, the user structure is only ever “initialized” for the first process (init).   After that fork just copies it from the parent to the child and then all the other system calls, etc… change it as required.

Gosh it’s been a long time since I was this deep into a UNIX kernel (especially on a primitive machine).   
Hope this helps.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151113/6b045248/attachment.bin>

From brantleycoile at me.com  Sat Nov 14 05:42:08 2015
From: brantleycoile at me.com (Brantley Coile)
Date: Fri, 13 Nov 2015 14:42:08 -0500
Subject: [TUHS] user struct on SYSIII / V7
In-Reply-To: <CE36BEBC-DA9F-4E95-B238-1D5C303700B9@icloud.com>
References: <20151113203320.Horde.VokfqdGcy16czyeqhojbDVa@avocado.salatschuessel.net>
 <CE36BEBC-DA9F-4E95-B238-1D5C303700B9@icloud.com>
Message-ID: <A271731C-C23A-4C6D-A0BE-A6C1413DCBDE@me.com>



iPhone email

> On Nov 13, 2015, at 2:38 PM, Brantley Coile <brantleycoile at icloud.com> wrote:
> 
> For performance reasons an assembly symbol "u" was defined to be a fixed address. That allowed us to use constructions like u.u_procp to generate a single address.  It was very fast. Does this help?
> 
> iPhone email
> 
>> On Nov 13, 2015, at 2:33 PM, Oliver Lehmann <lehmann at ans-netz.de> wrote:
>> 
>> 
>> Oliver Lehmann <lehmann at ans-netz.de> wrote:
>> 
>>> u module
>>> $segmented
>>> $abs %F600
>>> 
>>> global
>>> 
>>> _u array [%572 byte]
>>> 
>>> end u
>> 
>> By any way - is here someone on the list understanding Z8000 PLZ/ASM? ;)
>> 
>> The problem is, that "u" must be available in the address space on this
>> location for the kernel to function correctly:
>> 
>> # define UBASE             0x3E00F600      /* kernel virtual addr of user struct */
>> 
>> And with the above ASM code, it is placed on 0x0100F600. I also tried
>> of course $abs 0x3E00F600 but it makes no difference. It is always
>> placed at 0x0100F600 and I have zero clue why
>> 
>> the original object from the system:
>> 
>> #67 nm /usr/sys/conf/u.o
>> 3e00f600 A _u
>> 01000000 s u_d
>>   0000 s u_p
>> 
>> 
>> my object generated from my u.s:
>> 
>> #68 nm u.o
>> 0100f600 A _u
>> 01000000 s u_d
>>   0000 s u_p
>> 
>> Somehow I need to get the address right.... This is why I wanted to
>> look up how the original SYSIII or V7 was doing it (even if the asm
>> would be of course completely different).
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs


From lehmann at ans-netz.de  Sat Nov 14 22:34:15 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Sat, 14 Nov 2015 13:34:15 +0100
Subject: [TUHS] link() syscall implementation
Message-ID: <20151114133415.Horde.waGYhqdGBssNHzZf3_TcC5x@avocado.salatschuessel.net>

Hi,

I'm struggling on reimplementing the C code for the link()
syscall.

Usually on SYSIII and V7 you have something like:


link()
{
	register struct inode *ip, *xp;
	register struct a {
		char	*target;
		char	*linkname;
	} *uap;

[...]
	u.u_dirp = (caddr_t)uap->linkname;
[...]
}

The problem now on my system is, u_dirp in the user struct
is saddr_t (*long) and not caddr_t (*char) and I wonder how
I have to assign uap->linkname.
The original ASM code looks like:

_link::
{
	dec	fp,#~L2
	ldm	_stkseg+4(fp),r8,#6
	ldl	rr8,_u+36
[...]
	ldl	rr2,rr8(#4)
	ldl	rr4,rr2
	and	r4,#32512
	ldl	_u+78,rr4
[...]

I had the same problem already 7 years ago but didn't came up
with a solution back then.

http://home.salatschuessel.net/quest/problems.php

What came to my mind in the meantime is the following and maybe
someone can check if this is right:

1. _u+78 (u.u_dirp) contains a pointer - so what is assigned
    here in ASM is a memory address.
2. The memory notation for accessing segmented data on Z8001
    seems to be 0xSS00XXXX where SS is the segment number up
    to 127 and XXXX is the relative address in that segment.
3. This means ANDing 0xSS00 with 0x7F00 means to strip out
    all invalid data from the segment-position of the address,
    to make sure it  can only be between 0 and 127 (0x0000 and
    0x7F00).

I wonder how the assignment of uap->linkname to u.u_dirp has
to be done correctly?!


From lehmann at ans-netz.de  Sat Nov 14 22:56:35 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Sat, 14 Nov 2015 13:56:35 +0100
Subject: [TUHS] link() syscall implementation
In-Reply-To: <20151114133415.Horde.waGYhqdGBssNHzZf3_TcC5x@avocado.salatschuessel.net>
Message-ID: <20151114135635.Horde.6nqJB5AyLmQsx2fCZX4iZtZ@avocado.salatschuessel.net>


Oliver Lehmann <lehmann at ans-netz.de> wrote:

> The problem now on my system is, u_dirp in the user struct
> is saddr_t (*long) and not caddr_t (*char) and I wonder how
      ^^^^^^^^^^^^^^^
must read saddr_t (long)


typedef union
{
     caddr_t             l;
     struct
     {
         unsigned        left;
         unsigned        right;
     }                   half;
}                       saddr_t;        /* segmented address with parts */



From random832 at fastmail.com  Sat Nov 14 23:33:24 2015
From: random832 at fastmail.com (Random832)
Date: Sat, 14 Nov 2015 08:33:24 -0500
Subject: [TUHS] link() syscall implementation
References: <20151114133415.Horde.waGYhqdGBssNHzZf3_TcC5x@avocado.salatschuessel.net>
Message-ID: <m2fv08r9i3.fsf@fastmail.com>

Oliver Lehmann <lehmann at ans-netz.de> writes:
> The problem now on my system is, u_dirp in the user struct
> is saddr_t (*long) and not caddr_t (*char) and I wonder how
> I have to assign uap->linkname.

> I wonder how the assignment of uap->linkname to u.u_dirp has
> to be done correctly?!

Isn't uap->linkname also a pointer? Or does your system have near and
far pointers?



From lehmann at ans-netz.de  Sun Nov 15 01:17:57 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Sat, 14 Nov 2015 16:17:57 +0100
Subject: [TUHS] link() syscall implementation
In-Reply-To: <20151114135635.Horde.6nqJB5AyLmQsx2fCZX4iZtZ@avocado.salatschuessel.net>
References: <20151114133415.Horde.waGYhqdGBssNHzZf3_TcC5x@avocado.salatschuessel.net>
 <20151114135635.Horde.6nqJB5AyLmQsx2fCZX4iZtZ@avocado.salatschuessel.net>
Message-ID: <20151114161757.Horde.RL0PZVub39UDZ9-Qr0wtXdW@avocado.salatschuessel.net>

I've now implemented this:

         u.u_dirp.left = hiword(uap->linkname) & 0x7f00;
         u.u_dirp.right = loword(uap->linkname);

while hiword and loword being defined in my param.h like this:

# define loword(X)      (((unsigned short *)&X)[sizeof(X) - \
                         (sizeof(unsigned short)+1)])
# define hiword(X)      (((unsigned short *)&X)[0])

This results in:

         ld      r2,rr8(#4)
         and     r2,#32512
         ld      _u+78,r2
         ld      r2,rr8(#6)
         ld      _u+80,r2


versus

         ldl        rr2,rr8(#4)
         ldl        rr4,rr2
         and        r4,#32512
         ldl        _u+78,rr4

does the same but  with more instructions and of course not 1:1
binary "the same" ;)
wonder why
   u.u_dirp.l = (caddr_t)(((long)uap->linkname) & 0x7F00FFFF);
didn't worked.

At least link() is now working again (before the fix it was only
working when the file to be linked is in the working directory)

#1 ls -i /z/tmp/
  2487 hugo   2486 walter
#2 rm /z/tmp/walter
#3 ln /z/tmp/hugo /z/tmp/walter
#4 !1
ls -i /z/tmp/
  2487 hugo   2487 walter
#5 ln /z/tmp/hugo /z/walter
#6 ls -i /z/tmp/hugo /z/walter
  2487 /z/tmp/hugo                  2487 /z/walter
#7


From reed at reedmedia.net  Sun Nov 15 03:50:08 2015
From: reed at reedmedia.net (Jeremy C. Reed)
Date: Sat, 14 Nov 2015 11:50:08 -0600 (CST)
Subject: [TUHS] citation for a Bill Joy interview?
Message-ID: <alpine.NEB.2.11.1511141053120.28638@t1.m.reedmedia.net>

I see http://archive.org/details/BillJoyInterview but the source is 
unknown. Does anyone know who conducted this interview or where it came 
from? (I tried to contact the archive years ago but didn't hear back.)

Most of the stories I have alternative sources for but I'd like to cite 
some of this content in a book I am authoring.

Also it doesn't seem to have a starting place. It appears the beginning 
of the interview is missing. (Also it has eight sections marked with 
"[Skipped portion you requested.]" and 27 page breaks.)

It appears it may have been OCR'd (Exacfiy = Exactly, correcfiy = 
correctly, f'mally = finally, f'md = find, f'n'st = first, llliac = 
ILLIAC, Riogin = Rlogin, HTrP: = HTTP: and many other OCR-like typos), 
plus misspelled names where the originally typed wrong (so I assume the 
transcriber wasn't directly related to this story, like deck = DEC, 
Favory = Fabry, Gerwitz = Gurwitz, "E-bid(?) ASCH" = maybe EBCDIC to 
ASCII).

If anyone knows the source for this interview or a proper bibtex entry 
for it, I'd appreciate it.


From earl.baugh at gmail.com  Sun Nov 15 05:12:48 2015
From: earl.baugh at gmail.com (Earl Baugh)
Date: Sat, 14 Nov 2015 14:12:48 -0500
Subject: [TUHS] VCF SE 4.0 - Speakers?
Message-ID: <CANcLFn6_JM_AjBJAX-7mhB099Qw1sFR6_g5u+0HnKhL51zZ7-A@mail.gmail.com>

Howdy,

I'm the secretary of the Atlanta Historical Computing Society, and a lurker
here on the TUHS list.
We're starting our process of looking for speakers at our upcoming VCF SE
4.0.   It'll be April 2nd and 3rd 2016
in the Atlanta area.   Since I've enjoyed reading and hearing about all the
UNIX history on this list,
I was wondering if anybody here might be willing to speak at our event.
It seems there is a good
deal of history that is captured in the minds of the members of this
list... which might make a number
of good presentations.

We're open on ranges of topics.  We've had many different people speak...
the first editor of Byte,
the artist who did the covers of many Byte magazines, Jason Scott from
archive.org, some early SWTPC
engineers, some early Apple engineers including Daniel Kottke.  We also
have members from the
various Vintage Computer groups from around the U.S. speak (and of course
some local members),
and some University Archivists who are starting to have to deal with old
media.  This year we will have
Jerry Manock (the designer from Apple who established their design
group...designed cases for Mac, etc.)
as one speaker.

We love to learn about the history, esp. from the folks who lived it.  I am
just slightly too young to have
been there (was born in '65) but always enjoy the talks.   We can
accommodate from a 30 min talk to
an hour.    We have a professional sound set up and stage.   We have a
co-sponsor, the Computer
Museum of America that is being established in the area as well.  We have
between 5 and 10 slots to fill.

We aren't a large group, but we do have a limited budget to assist with
travel, lodging, etc.  We can handle
"nice" but not the Ritz :-)

If anybody is interested, please contact me and I can provide further
details.   And if you'd be interested
but can't make this year, please still contact me, maybe we can work
something out in the future.

Thanks!

Earl Baugh
Secretary
Atlanta Historical Computing Society.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151114/117e5bf8/attachment.html>

From ron at ronnatalie.com  Sun Nov 15 05:34:24 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sat, 14 Nov 2015 14:34:24 -0500
Subject: [TUHS] citation for a Bill Joy interview?
In-Reply-To: <alpine.NEB.2.11.1511141053120.28638@t1.m.reedmedia.net>
References: <alpine.NEB.2.11.1511141053120.28638@t1.m.reedmedia.net>
Message-ID: <F2CB340C-3D1C-4266-AE8C-98E436F29D28@ronnatalie.com>

It appears to be a transcription of an interview (yes probably subsequently imprecisely OCR’d).   It doesn’t sound like it’s actually the quality of a published article (since it still has inline comments about skipping things as requested), but likely is some piece of correspondence between Bill and whoever.

Given some of the events he is talking about in current situation it seems to date to the mid 90’s.   It is after Mosaic (1982) but refers to Jon as if he is still alive (he died in 1998).   It’s also incredibly off the cuff.   Bill is off by a couple of years on the dates (ARPANET/TCP conversion, VAX 11/750 availability).



I thing E-bid? ASCH is 8-bit ASCII.   EBCDIC doesn’t make any sense in that context.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151114/10fecd01/attachment.bin>

From random832 at fastmail.com  Sun Nov 15 07:18:13 2015
From: random832 at fastmail.com (Random832)
Date: Sat, 14 Nov 2015 16:18:13 -0500
Subject: [TUHS] link() syscall implementation
References: <20151114133415.Horde.waGYhqdGBssNHzZf3_TcC5x@avocado.salatschuessel.net>
 <20151114135635.Horde.6nqJB5AyLmQsx2fCZX4iZtZ@avocado.salatschuessel.net>
 <20151114161757.Horde.RL0PZVub39UDZ9-Qr0wtXdW@avocado.salatschuessel.net>
Message-ID: <m2bnawqnze.fsf@fastmail.com>

Oliver Lehmann <lehmann at ans-netz.de> writes:
>         ldl        rr2,rr8(#4)
>         ldl        rr4,rr2
>         and        r4,#32512
>         ldl        _u+78,rr4

This looks like it could be:
  u.u_dirp.l = uap->linkname;
  u.u_dirp.left &= 0x7f00;

>
> does the same but  with more instructions and of course not 1:1
> binary "the same" ;)
> wonder why
>   u.u_dirp.l = (caddr_t)(((long)uap->linkname) & 0x7F00FFFF);
> didn't worked.

Well, what code did it generate? Are longs in the same byte order as
pointers (could it have needed to be FFFF7F00)?



From lehmann at ans-netz.de  Sun Nov 15 07:42:05 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Sat, 14 Nov 2015 22:42:05 +0100
Subject: [TUHS] link() syscall implementation
In-Reply-To: <m2bnawqnze.fsf@fastmail.com>
References: <20151114133415.Horde.waGYhqdGBssNHzZf3_TcC5x@avocado.salatschuessel.net>
 <20151114135635.Horde.6nqJB5AyLmQsx2fCZX4iZtZ@avocado.salatschuessel.net>
 <20151114161757.Horde.RL0PZVub39UDZ9-Qr0wtXdW@avocado.salatschuessel.net>
 <m2bnawqnze.fsf@fastmail.com>
Message-ID: <20151114224205.Horde.pNedl1JFkdNwTKQKHr6OiXv@avocado.salatschuessel.net>


Random832 <random832 at fastmail.com> wrote:

> Oliver Lehmann <lehmann at ans-netz.de> writes:
>>         ldl        rr2,rr8(#4)
>>         ldl        rr4,rr2
>>         and        r4,#32512
>>         ldl        _u+78,rr4
>
> This looks like it could be:
>   u.u_dirp.l = uap->linkname;
>   u.u_dirp.left &= 0x7f00;

Good guess, but the optimizer didn't optimized this "away" so this
generates literally what is done in C:

         ldl     rr2,rr8(#4)
         ldl     _u+78,rr2
         ld      r2,_u+78
         and     r2,#32512
         ld      _u+78,r2


>
>>
>> does the same but  with more instructions and of course not 1:1
>> binary "the same" ;)
>> wonder why
>>   u.u_dirp.l = (caddr_t)(((long)uap->linkname) & 0x7F00FFFF);
>> didn't worked.
>
> Well, what code did it generate? Are longs in the same byte order as
> pointers (could it have needed to be FFFF7F00)?

Should be the same byte order, yes. It generates:

0530 3582  0004     584         ldl     rr2,rr8(#4)
0536 0702  7f00                 and     r2,#32512
04d2 5d02  8000*    585         ldl     _u+78,rr2
04d6 004e*

OK - it is not temporarily copied to rr4, but directly modfied in
rr2 and then assigned to u.u_dirp. It should be "the same" - But
  - ln(1) does not work with this code. Instead of creating a
hardlink, it creates a new empty file (different inode).

And to be honest - who would write such a code in the first place
    u.u_dirp.l = (caddr_t)(((long)uap->linkname) & 0x7F00FFFF);
Feels to crazy for me as someone would really write such a code.
There are so many "better" way (readability) someone would come
up with than this.... I/We just didn't figured out the better
way yet ;)

Another possibility could be, that the sys2.o was generated with
an earlier version if the assembler and not recompiled with the
"newer"/shipped one and that it might be impossible to generate
this code now. But all sccs tags in the assembler are before the
sccs tag in sys2.o....

Regards, Oliver


From random832 at fastmail.com  Sun Nov 15 09:07:16 2015
From: random832 at fastmail.com (Random832)
Date: Sat, 14 Nov 2015 18:07:16 -0500
Subject: [TUHS] link() syscall implementation
References: <20151114133415.Horde.waGYhqdGBssNHzZf3_TcC5x@avocado.salatschuessel.net>
 <20151114135635.Horde.6nqJB5AyLmQsx2fCZX4iZtZ@avocado.salatschuessel.net>
 <20151114161757.Horde.RL0PZVub39UDZ9-Qr0wtXdW@avocado.salatschuessel.net>
 <m2bnawqnze.fsf@fastmail.com>
 <20151114224205.Horde.pNedl1JFkdNwTKQKHr6OiXv@avocado.salatschuessel.net>
Message-ID: <m2y4e0p4d7.fsf@fastmail.com>

Oliver Lehmann <lehmann at ans-netz.de> writes:
> OK - it is not temporarily copied to rr4, but directly modfied in
> rr2 and then assigned to u.u_dirp. It should be "the same" - But
>  - ln(1) does not work with this code. Instead of creating a
> hardlink, it creates a new empty file (different inode).

Are you sure this is where the problem is?

For the pointer assignment, what about just using u.u_dirp.l =
uap->linkname, and validating there are no invalid bits (return EFAULT
or raise SIGSEGV if so - also should the user code really be allowed to
pass in arbitrary segment IDs?) in a separate step?



From lehmann at ans-netz.de  Mon Nov 16 00:43:49 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Sun, 15 Nov 2015 15:43:49 +0100
Subject: [TUHS] link() syscall implementation
In-Reply-To: <m2y4e0p4d7.fsf@fastmail.com>
References: <20151114133415.Horde.waGYhqdGBssNHzZf3_TcC5x@avocado.salatschuessel.net>
 <20151114135635.Horde.6nqJB5AyLmQsx2fCZX4iZtZ@avocado.salatschuessel.net>
 <20151114161757.Horde.RL0PZVub39UDZ9-Qr0wtXdW@avocado.salatschuessel.net>
 <m2bnawqnze.fsf@fastmail.com>
 <20151114224205.Horde.pNedl1JFkdNwTKQKHr6OiXv@avocado.salatschuessel.net>
 <m2y4e0p4d7.fsf@fastmail.com>
Message-ID: <20151115154349.Horde.6dHXDRnHFazVunVIgPsob3u@avocado.salatschuessel.net>


Random832 <random832 at fastmail.com> wrote:

> Oliver Lehmann <lehmann at ans-netz.de> writes:
>> OK - it is not temporarily copied to rr4, but directly modfied in
>> rr2 and then assigned to u.u_dirp. It should be "the same" - But
>> - ln(1) does not work with this code. Instead of creating a
>> hardlink, it creates a new empty file (different inode).
>
> Are you sure this is where the problem is?

Not any longer - I tried it again with

u.u_dirp.l = (caddr_t)(((long)uap->linkname) & 0x7F00FFFF);

and it seems to work now - no idea what went wrong the last time
I tried it.

#1 rm /z/tmp/*
#2 echo "test" > /z/tmp/hugo
#3 ln /z/tmp/hugo /z/tmp/walter
ls#4  -li /z/tmp
total 2
  2452 -rw-rw-rw- 2 wega     system        5 Nov 15 02:44 hugo
  2452 -rw-rw-rw- 2 wega     system        5 Nov 15 02:44 walter
#5

I still have direct modification of rr2 and not the copy to rr4,
so if I would aim for binary equalness it is still not the same,
but it seems that it can't be done another way.


From random832 at fastmail.com  Wed Nov 18 08:55:17 2015
From: random832 at fastmail.com (Random832)
Date: Tue, 17 Nov 2015 17:55:17 -0500
Subject: [TUHS] Interesting post by Rob Pike in 1985: Shells,
	features and interaction
Message-ID: <877flgw816.fsf@fastmail.com>

https://groups.google.com/d/msg/net.unix/Cya18ywIebk/2SI8HrSciyYJ

Apparently the 8th Edition shell had the ability to export functions via
the environment.

I'm wondering - were there (are there?) any other shells other than bash
that picked up this feature? How was it implemented, considering this
was the cause of the "Shellshock" vulnerability?



From random832 at fastmail.com  Wed Nov 18 08:57:02 2015
From: random832 at fastmail.com (Random832)
Date: Tue, 17 Nov 2015 17:57:02 -0500
Subject: [TUHS] With all the talk about cut(1) recently...
Message-ID: <87wptgutdt.fsf@fastmail.com>

I was amused to see it come up in one of the olduse.net newsgroups I've
been following.

Interestingly, the SysIII version of cut.c does not have the line
mentioned here. That's because it doesn't initialize _any_ of the flag
variables. The line was added some time between then and SysV, and that
is the _only_ significant change between the SysIII and pdp11v versions.

https://groups.google.com/d/msg/net.bugs.usg/iAkgNVBJNSo/PgXAC2vi044J



From random832 at fastmail.com  Wed Nov 18 10:38:41 2015
From: random832 at fastmail.com (Random832)
Date: Tue, 17 Nov 2015 19:38:41 -0500
Subject: [TUHS] Interesting post by Rob Pike in 1985: Shells,
	features and interaction
References: <877flgw816.fsf@fastmail.com>
Message-ID: <m2fv04uooe.fsf@fastmail.com>

Random832 <random832 at fastmail.com> writes:
> I'm wondering - were there (are there?) any other shells other than bash
> that picked up this feature? How was it implemented, considering this
> was the cause of the "Shellshock" vulnerability?

I was able to find the information on how it was implemented in 8th
edition: Environment strings of the form "name(){value}", contrary to
pre-shellshock bash's "name=(){value}" - the latter certainly looks like
it was inspired by the former, though.

http://man.cat-v.org/unix_8th/5/environ



From brantleycoile at me.com  Wed Nov 18 10:50:36 2015
From: brantleycoile at me.com (Brantley Coile)
Date: Tue, 17 Nov 2015 19:50:36 -0500
Subject: [TUHS] Interesting post by Rob Pike in 1985: Shells,
 features and interaction
In-Reply-To: <877flgw816.fsf@fastmail.com>
References: <877flgw816.fsf@fastmail.com>
Message-ID: <8E0284E2-3BEC-4F68-B93F-CFC59C2CBD2F@me.com>

Tom Duff's shell, rc, exports the functions as variables as well. You can find it in the Plan 9 Ports utilities. Byron Rakitzis also write a version of rc.

> On Nov 17, 2015, at 5:55 PM, Random832 <random832 at fastmail.com> wrote:
> 
> https://groups.google.com/d/msg/net.unix/Cya18ywIebk/2SI8HrSciyYJ
> 
> Apparently the 8th Edition shell had the ability to export functions via
> the environment.
> 
> I'm wondering - were there (are there?) any other shells other than bash
> that picked up this feature? How was it implemented, considering this
> was the cause of the "Shellshock" vulnerability?
> 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs



From fair-tuhs at netbsd.org  Wed Nov 18 11:56:28 2015
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Tue, 17 Nov 2015 17:56:28 -0800
Subject: [TUHS] Interesting post by Rob Pike in 1985: Shells,
	features and interaction
In-Reply-To: <877flgw816.fsf@fastmail.com>
Message-ID: <7694.1447811788@cesium.clock.org>

That function export feature of bash was not the cause of the
Shellshock vulnerability.

The cause was idiot programmers who wrote CGI scripts for bash
without proper data sanitization.

See also
https://www.quora.com/Are-there-any-projects-to-replace-bash-the-Unix-shell/answer/Erik-Fair


	Erik <fair at netbsd.org>


From khm at sciops.net  Wed Nov 18 15:15:09 2015
From: khm at sciops.net (Kurt H Maier)
Date: Wed, 18 Nov 2015 00:15:09 -0500
Subject: [TUHS] Interesting post by Rob Pike in 1985: Shells,
 features and interaction
In-Reply-To: <7694.1447811788@cesium.clock.org>
References: <877flgw816.fsf@fastmail.com>
 <7694.1447811788@cesium.clock.org>
Message-ID: <20151118051509.GB27122@wopr.sciops.net>

On Tue, Nov 17, 2015 at 05:56:28PM -0800, Erik E. Fair wrote:
>
> The cause was idiot programmers who wrote CGI scripts for bash
> without proper data sanitization.
>

No, the cause was "idiot programmers" who did not stop processing the
function definition when the function ended.  Bash was not conformant
to its own syntax specification.   Then they had to fix the same bug for
here documents.  While fixing that, someone discovered stack smash among
other bugs in the parser.

Data santitization is important, but that doesn't mean bash doesn't
suck.  The fix wasn't "stop exporting functions into the environemnt,"
the fix was to patch bash.  Several times.

khm


From random832 at fastmail.com  Wed Nov 18 15:36:28 2015
From: random832 at fastmail.com (Random832)
Date: Wed, 18 Nov 2015 00:36:28 -0500
Subject: [TUHS] Interesting post by Rob Pike in 1985: Shells,
	features and interaction
References: <877flgw816.fsf@fastmail.com> <7694.1447811788@cesium.clock.org>
Message-ID: <m2bnarvpgj.fsf@fastmail.com>

"Erik E. Fair" <fair-tuhs at netbsd.org>
writes:
> That function export feature of bash was not the cause of the
> Shellshock vulnerability.
>
> The cause was idiot programmers who wrote CGI scripts for bash
> without proper data sanitization.

The manner in which bash (pre-shellshock) imported functions from the
environment, along with the vulnerability, made "proper data
sanitization" flatly impossible without deep knowledge of what kind of
strings it was looking for. It would import functions from absolutely
any variable, with any name, including variables explicitly designated
in the protocols involved to hold untrusted remote data.

Removing text in a format that triggers a feature of a particular shell
from HTTP_COOKIE is absolutely not the CGI script's responsibility (the
bug triggers before the script gets to execute a single line), and I
would argue it's not the HTTP server's problem either.

And if the bash feature had been implemented correctly, it would have
been mostly harmless (The remote client could still have caused a
function called HTTP_COOKIE to be defined, but the script's almost
certainly not going to execute it)



From chneukirchen at gmail.com  Wed Nov 18 22:47:07 2015
From: chneukirchen at gmail.com (Christian Neukirchen)
Date: Wed, 18 Nov 2015 13:47:07 +0100
Subject: [TUHS] Interesting post by Rob Pike in 1985: Shells,
	features and interaction
In-Reply-To: <8E0284E2-3BEC-4F68-B93F-CFC59C2CBD2F@me.com> (Brantley Coile's
 message of "Tue, 17 Nov 2015 19:50:36 -0500")
References: <877flgw816.fsf@fastmail.com>
 <8E0284E2-3BEC-4F68-B93F-CFC59C2CBD2F@me.com>
Message-ID: <87vb8zeapg.fsf@gmail.com>

Brantley Coile <brantleycoile at me.com> writes:

> Tom Duff's shell, rc, exports the functions as variables as well. You
> can find it in the Plan 9 Ports utilities. Byron Rakitzis also write a
> version of rc.

Note that Plan 9 rc is susceptible to a Shellshock-style attack,
whereas Byron's rc is not.

https://bitbucket.org/rsc/plan9port/issues/187/shellshock-on-rc-1

-- 
Christian Neukirchen  <chneukirchen at gmail.com>  http://chneukirchen.org


From lehmann at ans-netz.de  Sat Nov 21 23:00:22 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Sat, 21 Nov 2015 14:00:22 +0100
Subject: [TUHS] Porting 2.11 BSD
Message-ID: <20151121140022.Horde.ZwPZMYWApn-dXiuNCkiDWDA@avocado.salatschuessel.net>


Hi,

I wanted to at least give it a try porting 2.11 BSD to my Z8001
machine. I din't really wrote any kernel part until now so it
will be a huge learning curve for sure. No idea what my spare
time permits, but... at least I'm planning giving it a try.

I didn't found something like "thing you should do first when
porting 2.11 BSD to another architecture" online so I thought
myself... maybe it would be good to start with the standalone
utilities - more precisely with "disklabel".

Is there a good "HOWTO" for "first things first" as implementing
disklabel seems to require quite some "device work" before the
first "hello world" is there - is there something else which
should be could be done first and does not require so much to
port (the whole disk subsystem on that machine is different
from "usual" disk subsystems as it is handled via a PIO)

Regards, Oliver



From dugo at xs4all.nl  Sat Nov 21 23:36:27 2015
From: dugo at xs4all.nl (Jacob Goense)
Date: Sat, 21 Nov 2015 14:36:27 +0100
Subject: [TUHS] Porting 2.11 BSD
In-Reply-To: <20151121140022.Horde.ZwPZMYWApn-dXiuNCkiDWDA@avocado.salatschuessel.net>
References: <20151121140022.Horde.ZwPZMYWApn-dXiuNCkiDWDA@avocado.salatschuessel.net>
Message-ID: <a7b99f64b51b42bfb928c45d19e69be1@xs4all.nl>

On 2015-11-21 14:00, Oliver Lehmann wrote:
I wanted to at least give it a try porting 2.11 BSD to my Z8001
machine.

Have a look at http://retrobsd.org/ for some recent ports. Also
the good old Porting Unix to the 386 series by Jolitz could be
of help.


From hellwig.geisse at mni.thm.de  Sun Nov 22 00:03:07 2015
From: hellwig.geisse at mni.thm.de (Hellwig Geisse)
Date: Sat, 21 Nov 2015 15:03:07 +0100
Subject: [TUHS] Porting 2.11 BSD
In-Reply-To: <20151121140022.Horde.ZwPZMYWApn-dXiuNCkiDWDA@avocado.salatschuessel.net>
References: <20151121140022.Horde.ZwPZMYWApn-dXiuNCkiDWDA@avocado.salatschuessel.net>
Message-ID: <1448114587.9367.39.camel@papa2>

Hi Oliver,

On Sa, 2015-11-21 at 14:00 +0100, Oliver Lehmann wrote:
> Is there a good "HOWTO" for "first things first" as implementing
> disklabel seems to require quite some "device work" before the
> first "hello world" is there - is there something else which
> should be could be done first and does not require so much to
> port (the whole disk subsystem on that machine is different
> from "usual" disk subsystems as it is handled via a PIO)

I don't have an exact HOWTO for porting BSD, but we gathered
some experience in these things while porting NetBSD to our
processor ECO32.

First and most important is a working tool-chain (which in case
of BSD means GCC). You should really know your tools, because
you will frequently dig deep into them to understand various
aspects of e.g. linker scripts. We totally underestimated the
amount of work to be done here.

Then you must decide if you will do cross-development, or if you
can do it on a running BSD system. Even if so, you will have to
generate a file system for the target BSD system from which you
boot your machine. You can do that with the tools included in BSD,
but they are not running yet. (Btw, byte-order is an especially
nasty thing in this context.)

Memory management was another area which required a fair amount
of work. I have no experience with 2.11 BSD, but in case of NetBSD
the code is divided into at least three layers to obtain a good
degree of re-usability for different architectures. Alas, the
documentation was rather poor, and the relevant book ("The Design
and Implementation of the 4.4 BSD Operating System" by McKusick
et al.) is a bit outdated.

The project of porting BSD to a yet unsupported machine is
certainly feasible, and is indeed a valuable experience. But
don't expect to have it done in only a couple of weeks... :-)

Good luck!
Hellwig



From clemc at ccc.com  Sun Nov 22 00:39:46 2015
From: clemc at ccc.com (Clem Cole)
Date: Sat, 21 Nov 2015 09:39:46 -0500
Subject: [TUHS] Porting 2.11 BSD
In-Reply-To: <1448114587.9367.39.camel@papa2>
References: <20151121140022.Horde.ZwPZMYWApn-dXiuNCkiDWDA@avocado.salatschuessel.net>
 <1448114587.9367.39.camel@papa2>
Message-ID: <CAC20D2OeRdxZqZt1EMa5hy+hx_iK1AqRZr+YCroQRDWh1g0egw@mail.gmail.com>

Hellwig made some great tips.

Two other thoughts..

1.) Make sure you understand the low level interrupt mechanism and how
interrupts are turned into real C proceedure calls and back again.   This
is traditionally handled in the *.s file - which in the case of BSD is spit
out by Sam's config program.   So you'll eventuall need to rewrite the
proper stuff for your system - although as a step 1, you'll create it by
hand.

2.) A thought might be to walk before you try running.  The MIT guys took
V6 and the Lions book and rewrote it for the x86.   They use it for their
undergrad OS course.   They have excellent materials and have updated the
V6 code for a modern compiler.     A year ago, I answered a Quora question
about learning the kernel this was:
https://www.quora.com/Which-Linux-kernel-versions-source-code-is-better-for-newbie-to-read/answer/Clem-Cole?__snids__=1310704238&__nsrc__=1&__filter__=all


The most relevant part I have cut/pasted here:

 "a modern take on a classic" - the course if being offered this fall at
the URL:   6.828 / Fall 2014 <http://pdos.csail.mit.edu/6.828/2014/xv6.html>

The latest xv6 source is available via
        git clone git://pdos.csail.mit.edu/xv6/xv6.git
<http://git//pdos.csail.mit.edu/xv6/xv6.git>

Tools are can be found at:   6.828 / Fall 2014
<http://pdos.csail.mit.edu/6.828/2014/tools.html>

Using the MIT course or the Lion's text will teach how the kernel works and
how a user program interacts with it.   IMO: Lion's commentary is super and
100% of the source is there to read and ponder.  Please remember that
generations of the best kernel hackers started with this document (although
some of us predate it - but when I saw it I made a copy).

​My point is gett​ing the V6 kernel running on your HW.  The take your
learning from that and try a BSD kernel.   The hardest part of the ports
will be common and the V6 kernel is going to be a lot easier to get
working, because it small and simple.


No you went get networking at all the cool BSD features, but if the idea to
learn how to do it, start small scale as the MythBuster's guys always do ;-)

Clem

On Sat, Nov 21, 2015 at 9:03 AM, Hellwig Geisse <hellwig.geisse at mni.thm.de>
wrote:

> Hi Oliver,
>
> On Sa, 2015-11-21 at 14:00 +0100, Oliver Lehmann wrote:
> > Is there a good "HOWTO" for "first things first" as implementing
> > disklabel seems to require quite some "device work" before the
> > first "hello world" is there - is there something else which
> > should be could be done first and does not require so much to
> > port (the whole disk subsystem on that machine is different
> > from "usual" disk subsystems as it is handled via a PIO)
>
> I don't have an exact HOWTO for porting BSD, but we gathered
> some experience in these things while porting NetBSD to our
> processor ECO32.
>
> First and most important is a working tool-chain (which in case
> of BSD means GCC). You should really know your tools, because
> you will frequently dig deep into them to understand various
> aspects of e.g. linker scripts. We totally underestimated the
> amount of work to be done here.
>
> Then you must decide if you will do cross-development, or if you
> can do it on a running BSD system. Even if so, you will have to
> generate a file system for the target BSD system from which you
> boot your machine. You can do that with the tools included in BSD,
> but they are not running yet. (Btw, byte-order is an especially
> nasty thing in this context.)
>
> Memory management was another area which required a fair amount
> of work. I have no experience with 2.11 BSD, but in case of NetBSD
> the code is divided into at least three layers to obtain a good
> degree of re-usability for different architectures. Alas, the
> documentation was rather poor, and the relevant book ("The Design
> and Implementation of the 4.4 BSD Operating System" by McKusick
> et al.) is a bit outdated.
>
> The project of porting BSD to a yet unsupported machine is
> certainly feasible, and is indeed a valuable experience. But
> don't expect to have it done in only a couple of weeks... :-)
>
> Good luck!
> Hellwig
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151121/e290c0ee/attachment.html>

From random832 at fastmail.us  Sun Nov 22 10:13:35 2015
From: random832 at fastmail.us (Random832)
Date: Sat, 21 Nov 2015 19:13:35 -0500
Subject: [TUHS] Porting 2.11 BSD
In-Reply-To: <20151121140022.Horde.ZwPZMYWApn-dXiuNCkiDWDA@avocado.salatschuessel.net>
References: <20151121140022.Horde.ZwPZMYWApn-dXiuNCkiDWDA@avocado.salatschuessel.net>
Message-ID: <1448151215.3670388.446383649.14D3C39D@webmail.messagingengine.com>

On Sat, Nov 21, 2015, at 08:00, Oliver Lehmann wrote:
> I wanted to at least give it a try porting 2.11 BSD to my Z8001
> machine.

Is there an emulator for this system so people without one can follow
along?


From mjkerpan at kerpan.com  Sun Nov 22 10:27:20 2015
From: mjkerpan at kerpan.com (Michael Kerpan)
Date: Sat, 21 Nov 2015 19:27:20 -0500
Subject: [TUHS] Porting 2.11 BSD
In-Reply-To: <1448151215.3670388.446383649.14D3C39D@webmail.messagingengine.com>
References: <20151121140022.Horde.ZwPZMYWApn-dXiuNCkiDWDA@avocado.salatschuessel.net>
 <1448151215.3670388.446383649.14D3C39D@webmail.messagingengine.com>
Message-ID: <CAHfSdrX41eu0BexfW9wLf48ZqS4MijER--YLb8poMbCbwjND+A@mail.gmail.com>

Sadly, I haven't ever seen much in the realm of Z8001-based systems
emulation. There's an emulator for something called the P8000, but
that's about it. Even the Olivetti M20 (probably the most
widely-deployed Z8001 system in real life) lacks an emulator.

Mike

On Sat, Nov 21, 2015 at 7:13 PM, Random832 <random832 at fastmail.us> wrote:
> On Sat, Nov 21, 2015, at 08:00, Oliver Lehmann wrote:
>> I wanted to at least give it a try porting 2.11 BSD to my Z8001
>> machine.
>
> Is there an emulator for this system so people without one can follow
> along?
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From pechter at gmail.com  Sun Nov 22 10:30:16 2015
From: pechter at gmail.com (William Pechter)
Date: Sat, 21 Nov 2015 19:30:16 -0500
Subject: [TUHS] Porting 2.11 BSD
In-Reply-To: <1448151215.3670388.446383649.14D3C39D@webmail.messagingengine.com>
References: <20151121140022.Horde.ZwPZMYWApn-dXiuNCkiDWDA@avocado.salatschuessel.net>
 <1448151215.3670388.446383649.14D3C39D@webmail.messagingengine.com>
Message-ID: <56510C98.2000301@gmail.com>

Random832 wrote:
> Is there an emulator for this system so people without one can follow
> along?
I found this for a Z8000 System III box.  It was an East German dual cpu 
Z80/Z8001 clone box running SysIII -- perhaps this may be of some help 
as a comparison.

Emulator
http://www.knothusa.net/Home.php

More P8000 info
http://www.pofo.de/P8000/
Z8000 docs
http://www.pofo.de/P8000/  (there's some Zilog System 8000 Z8000 Zeus 
info here as well.

-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-gmail.com  http://xkcd.com/705/



From lehmann at ans-netz.de  Sun Nov 22 11:36:30 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Sun, 22 Nov 2015 02:36:30 +0100
Subject: [TUHS] Porting 2.11 BSD
In-Reply-To: <56510C98.2000301@gmail.com>
References: <20151121140022.Horde.ZwPZMYWApn-dXiuNCkiDWDA@avocado.salatschuessel.net>
 <1448151215.3670388.446383649.14D3C39D@webmail.messagingengine.com>
 <56510C98.2000301@gmail.com>
Message-ID: <20151122023630.Horde.YgAxkfni4xS7fRdlcpIUGSp@avocado.salatschuessel.net>


William Pechter <pechter at gmail.com> wrote:


> I found this for a Z8000 System III box.  It was an East German dual  
> cpu Z80/Z8001 clone box running SysIII -- perhaps this may be of  
> some help as a comparison.

And I also redid (disassembled objects, translated it back to C) nearly
all Kernel sources of the SYSIII (only lock.c is missing with file
locking features - I only disassembled it)

https://github.com/OlliL/P8000/tree/master/WEGA/src/uts


> Emulator
> http://www.knothusa.net/Home.php

Yes... he built the Emulator based on MAME back in 2008 with quite
some info from me - he used to work on a P8000 back in the 90s so
he felt for it building the Emulator.... ;)


> More P8000 info
> http://www.pofo.de/P8000/

> Z8000 docs
> http://www.pofo.de/P8000/  (there's some Zilog System 8000 Z8000  
> Zeus info here as well.

Cool... you found my page ;)



From jgevaryahu at hotmail.com  Sun Nov 22 12:04:35 2015
From: jgevaryahu at hotmail.com (Jonathan Gevaryahu)
Date: Sat, 21 Nov 2015 21:04:35 -0500
Subject: [TUHS] Porting 2.11 BSD
In-Reply-To: <CAHfSdrX41eu0BexfW9wLf48ZqS4MijER--YLb8poMbCbwjND+A@mail.gmail.com>
References: <20151121140022.Horde.ZwPZMYWApn-dXiuNCkiDWDA@avocado.salatschuessel.net>
 <1448151215.3670388.446383649.14D3C39D@webmail.messagingengine.com>
 <CAHfSdrX41eu0BexfW9wLf48ZqS4MijER--YLb8poMbCbwjND+A@mail.gmail.com>
Message-ID: <BLU437-SMTP3593916AF0C4B006F72898C7180@phx.gbl>

There is a functional emulator of the Olivetti M20 in the MESS emulator, 
now a subpart of MAME (same executable for both).
http://www.mamedev.org/

On 11/21/2015 7:27 PM, Michael Kerpan wrote:
> Sadly, I haven't ever seen much in the realm of Z8001-based systems
> emulation. There's an emulator for something called the P8000, but
> that's about it. Even the Olivetti M20 (probably the most
> widely-deployed Z8001 system in real life) lacks an emulator.
>
> Mike
>
> On Sat, Nov 21, 2015 at 7:13 PM, Random832 <random832 at fastmail.us> wrote:
>> On Sat, Nov 21, 2015, at 08:00, Oliver Lehmann wrote:
>>> I wanted to at least give it a try porting 2.11 BSD to my Z8001
>>> machine.
>> Is there an emulator for this system so people without one can follow
>> along?
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>


-- 
Jonathan Gevaryahu AKA Lord Nightmare
jgevaryahu at gmail.com
jgevaryahu at hotmail.com



From pechter at gmail.com  Sun Nov 22 12:13:53 2015
From: pechter at gmail.com (William Pechter)
Date: Sat, 21 Nov 2015 21:13:53 -0500
Subject: [TUHS] Porting 2.11 BSD
In-Reply-To: <20151122023630.Horde.YgAxkfni4xS7fRdlcpIUGSp@avocado.salatschuessel.net>
References: <20151121140022.Horde.ZwPZMYWApn-dXiuNCkiDWDA@avocado.salatschuessel.net>
 <1448151215.3670388.446383649.14D3C39D@webmail.messagingengine.com>
 <56510C98.2000301@gmail.com>
 <20151122023630.Horde.YgAxkfni4xS7fRdlcpIUGSp@avocado.salatschuessel.net>
Message-ID: <565124E1.8050001@gmail.com>

Oliver Lehmann wrote:
>
> William Pechter <pechter at gmail.com> wrote:
>
>
>> I found this for a Z8000 System III box. It was an East German dual 
>> cpu Z80/Z8001 clone box running SysIII -- perhaps this may be of some 
>> help as a comparison.
>
> And I also redid (disassembled objects, translated it back to C) nearly
> all Kernel sources of the SYSIII (only lock.c is missing with file
> locking features - I only disassembled it)
>
> https://github.com/OlliL/P8000/tree/master/WEGA/src/uts
>
>
>> Emulator
>> http://www.knothusa.net/Home.php
>
> Yes... he built the Emulator based on MAME back in 2008 with quite
> some info from me - he used to work on a P8000 back in the 90s so
> he felt for it building the Emulator.... ;)
>
>
>> More P8000 info
>> http://www.pofo.de/P8000/
>
>> Z8000 docs
>> http://www.pofo.de/P8000/  (there's some Zilog System 8000 Z8000 Zeus 
>> info here as well.
>
> Cool... you found my page ;)
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

Nice site... I worked for DEC back in the 80's and I ended up installing 
Exxon Office Systems'  Vaxes which
they used for software development for the Zeus systems.  Some employees 
were from the Berkeley area
and New Jersey, even Princeton, seemed to be culture shock.

The computer room was directly under the flight path to the little 
Princeton Airport and the rented building
wasn't really designed for those machines.  The place was small offices 
for insurance sales, accounting,
lawyers and such.   They later moved over to a new building on the RT 1 
corridor which had a real computer room after they had all the 
electricity put in for the 11/780.

They moved from California to Princeton, New Jersey back around '81 or 
so and were gone shortly
when Exxon closed them down in '84.

I think they were the first Ultrix32 box I saw in my lifetime... which 
was much more AT&T focused working
for DEC in New Jersey.  By 92 or so I was doing SunOS 4.1.3 at work and 
FreeBSD/NetBSD at home.

I never could figure out how AT&T kept the miserable self-destructive 
Unix Filesystem alive with it's 13 character filename limit and no 
symbolic links.  SysVR4 finally showed some promise, and I even
thought they had a winner with their object-oriented management tools to 
manage getty's and printers and such.

FACE, the SVR4 character terminal graphic utilities were not too bad. 
You could finally run the whole system without vi-ing configurations -- 
kind of like a pre-SUSE  Yast that used the button labels on function keys.
Perkin-Elmer/Concurrent had a similar thing in Xelos (SVR2) on their 
block-mode capable 1251 and 6312
terminals...  That was the thing in the 80's -- menu or function button 
Unix sysadmin screens.

AT&T killed their future OEM's by allowing the OSF/USL split to happen 
over their Sun investment
and promise that Sun would get the new Unix before everyone else. The 
Unix wars made sure there
wouldn't be one binary/source compatible version of Unix across all 
hardware platforms.

When I started to work with Solaris2 I was amazed as to how different it 
seemed than straight SVR4 and
I helped write Pyramid's training for their OS/x SVR4 MIPS R3000 product.

Had AT&T been more willing to supply the code equally and get out of the 
way you wouldn't have had
the waste of the NCR purchase later after the less than stellar 3b and 
3b2 sales of the late 80's.

To bring this back to the Z8000 ZEUS and Zilog:

Pyramid was an OEM for AT&T and AT&T was to sell Pyramid boxes to the US 
Government to replace
the Z8000 Zilog Zeus machines which were used by the IRS.  I think this 
all fell apart after the
NCR purchase.  My job kind of went with it as Pyramid went through a 
downward sales spiral
as AT&T stopped buying MIServers and the MIPS MIServer-S line (R3000 
SVR4) multicpu boxes.

Bill

-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-gmail.com  http://xkcd.com/705/



From wkt at tuhs.org  Mon Nov 23 05:32:20 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 23 Nov 2015 06:32:20 +1100
Subject: [TUHS] 101 fixes for unix V6?
Message-ID: <20151122193220.GA23614@www.oztivo.net>

Hi all, I just receivd this e-mail from Will Senn who has just joined
the TUHS mailing list:

----- Forwarded message from Will Senn -----
Hi,
I am conducting research on older UNIX operating systems and came
across a letter from Richard Wolf to Ian Johnstone, dated Feb 5, 1979.
On p. 29 of the AUUGN, Volume 1 number 3, Mr. Wolf refers to a set of
101 fixes for research version 6. In my research, I am currently using
v6 and wondered if you knew where I might find the fixes or if the
bits are known to exist?

Kind Regards,
Will
----- End forwarded message -----

Will, there was a "50 bugs" tape for 6th Edition Unix that was "released"
to Unix owners in a very interesting distribution method: see
http://www.groklaw.net/articlebasic.php?story=20060616172103795

You can find it in the Unix Archive. Look in Applications/Spencer_Tapes/unsw3.tar.gz. It is the file usr/sys/v6unix/unix_changes.

Does anybody know of something which could be described as "101 fixes for
research version 6"? The phototypesetter version of Unix was V7.

Cheers all and welcome to the list Will.

	Warren


From ron at ronnatalie.com  Mon Nov 23 05:33:28 2015
From: ron at ronnatalie.com (Ronald Natalie)
Date: Sun, 22 Nov 2015 14:33:28 -0500
Subject: [TUHS] 101 fixes for unix V6?
In-Reply-To: <20151122193220.GA23614@www.oztivo.net>
References: <20151122193220.GA23614@www.oztivo.net>
Message-ID: <0AD9A203-9985-4534-AABA-DED59E6E9488@ronnatalie.com>

I don’t recall 101 fixes, but there was a 50 fixes tape that came out of the labs for version 6.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151122/5bb1bc48/attachment.bin>

From will.senn at gmail.com  Mon Nov 23 06:59:35 2015
From: will.senn at gmail.com (Will Senn)
Date: Sun, 22 Nov 2015 14:59:35 -0600
Subject: [TUHS] 101 fixes for unix V6?
In-Reply-To: <20151122193220.GA23614@www.oztivo.net>
References: <20151122193220.GA23614@www.oztivo.net>
Message-ID: <56522CB7.5030309@gmail.com>



On 11/22/15 1:32 PM, Warren Toomey wrote:
> Hi all, I just receivd this e-mail from Will Senn who has just joined
> the TUHS mailing list:
>
> ----- Forwarded message from Will Senn -----
> Hi,
> I am conducting research on older UNIX operating systems and came
> across a letter from Richard Wolf to Ian Johnstone, dated Feb 5, 1979.
> On p. 29 of the AUUGN, Volume 1 number 3, Mr. Wolf refers to a set of
> 101 fixes for research version 6. In my research, I am currently using
> v6 and wondered if you knew where I might find the fixes or if the
> bits are known to exist?
>
> Kind Regards,
> Will
> ----- End forwarded message -----
>
> Will, there was a "50 bugs" tape for 6th Edition Unix that was "released"
> to Unix owners in a very interesting distribution method: see
> http://www.groklaw.net/articlebasic.php?story=20060616172103795
>
> You can find it in the Unix Archive. Look in Applications/Spencer_Tapes/unsw3.tar.gz. It is the file usr/sys/v6unix/unix_changes.
>
> Does anybody know of something which could be described as "101 fixes for
> research version 6"? The phototypesetter version of Unix was V7.
>
> Cheers all and welcome to the list Will.
>
> 	Warren
> _______________________________________________
>
Warren,

In looking at the Spencer tape, I can see how this might be considered 
the 101 fixes (Wolff's comment that he had only "heard about" the 
changes, might indicate a quantity mismatch). The 52 fixes in 
usr/sys/v6unix/unix_changes represent "the differences between level 6 
unix and bell unix". On top of those changes, there are 31 additional 
fixes called "CORRECTIONS to level 6 code" and a whopping 57 "programs 
written specifically for or heavily modified for, AUSAM" which I suppose 
are what are referred to as "ENHANCEMENTS to level 6 UNIX". The tape 
contains "The Second Australian Sixth Edition" and has #ifdef's to 
determine if the system is an AUSAM system. The 52 v6 fixes are 
straightforward to see because the tape has the original source in one 
directory tree and the changes in another. Whereas the other 
enhancements and fixes are a bit more challenging because they are 
related to AUSAM's mods.

Thanks for the warm welcome, the direction, and for posting my question.

One more question, how did you zero in on 
Applications/Spencer_Tapes/unsw3.tar.gz as containing the fixes, the 
notes in the archive, from Spencer, are pretty bare:

    unsw3.tar is yet another anthology, this one Australian. I can't find a
    README file, but some quick experimental grepping doesn't find any dates
    later than 1977, so this one may be really early.

Regards,

Will


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151122/15157281/attachment.html>

From imp at bsdimp.com  Mon Nov 23 07:59:23 2015
From: imp at bsdimp.com (Warner Losh)
Date: Sun, 22 Nov 2015 14:59:23 -0700
Subject: [TUHS] 101 fixes for unix V6?
In-Reply-To: <56522CB7.5030309@gmail.com>
References: <20151122193220.GA23614@www.oztivo.net>
 <56522CB7.5030309@gmail.com>
Message-ID: <CANCZdfpQ48uGdsrBvn2sAJg1_3GVtcF2QkeaasAD9yTAPxJFiQ@mail.gmail.com>

There's also USENET groups that had bug fixes for different versions
of Unix posted to them. comp.bugs.misc leaps to mind. I recall at least
some v7 bug fixes were posted there. Google's interface is kinda lame,
so I couldn't search it very well for v6 bugs, but there were maybe a
dozen or so v7 patches dating from the late 1980's. While not
as convenient as a fix tape, there may be something there of interest.

Warner

On Sun, Nov 22, 2015 at 1:59 PM, Will Senn <will.senn at gmail.com> wrote:

>
>
> On 11/22/15 1:32 PM, Warren Toomey wrote:
>
> Hi all, I just receivd this e-mail from Will Senn who has just joined
> the TUHS mailing list:
>
> ----- Forwarded message from Will Senn -----
> Hi,
> I am conducting research on older UNIX operating systems and came
> across a letter from Richard Wolf to Ian Johnstone, dated Feb 5, 1979.
> On p. 29 of the AUUGN, Volume 1 number 3, Mr. Wolf refers to a set of
> 101 fixes for research version 6. In my research, I am currently using
> v6 and wondered if you knew where I might find the fixes or if the
> bits are known to exist?
>
> Kind Regards,
> Will
> ----- End forwarded message -----
>
> Will, there was a "50 bugs" tape for 6th Edition Unix that was "released"
> to Unix owners in a very interesting distribution method: seehttp://www.groklaw.net/articlebasic.php?story=20060616172103795
>
> You can find it in the Unix Archive. Look in Applications/Spencer_Tapes/unsw3.tar.gz. It is the file usr/sys/v6unix/unix_changes.
>
> Does anybody know of something which could be described as "101 fixes for
> research version 6"? The phototypesetter version of Unix was V7.
>
> Cheers all and welcome to the list Will.
>
> 	Warren
> _______________________________________________
>
>
> Warren,
>
> In looking at the Spencer tape, I can see how this might be considered the
> 101 fixes (Wolff's comment that he had only "heard about" the changes,
> might indicate a quantity mismatch). The 52 fixes in
> usr/sys/v6unix/unix_changes represent "the differences between level 6 unix
> and bell unix". On top of those changes, there are 31 additional fixes
> called "CORRECTIONS to level 6 code" and a whopping 57 "programs written
> specifically for or heavily modified for, AUSAM" which I suppose are what
> are referred to as "ENHANCEMENTS to level 6 UNIX". The tape contains "The
> Second Australian Sixth Edition" and has #ifdef's to determine if the
> system is an AUSAM system. The 52 v6 fixes are straightforward to see
> because the tape has the original source in one directory tree and the
> changes in another. Whereas the other enhancements and fixes are a bit more
> challenging because they are related to AUSAM's mods.
>
> Thanks for the warm welcome, the direction, and for posting my question.
>
> One more question, how did you zero in on
> Applications/Spencer_Tapes/unsw3.tar.gz as containing the fixes, the notes
> in the archive, from Spencer, are pretty bare:
>
> unsw3.tar is yet another anthology, this one Australian. I can't find a
> README file, but some quick experimental grepping doesn't find any dates
> later than 1977, so this one may be really early.
>
> Regards,
>
> Will
>
>
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151122/07fdf845/attachment.html>

From downing.nick at gmail.com  Mon Nov 23 10:56:42 2015
From: downing.nick at gmail.com (Nick Downing)
Date: Mon, 23 Nov 2015 11:56:42 +1100
Subject: [TUHS] Porting 2.11 BSD
In-Reply-To: <565124E1.8050001@gmail.com>
References: <20151121140022.Horde.ZwPZMYWApn-dXiuNCkiDWDA@avocado.salatschuessel.net>
 <1448151215.3670388.446383649.14D3C39D@webmail.messagingengine.com>
 <56510C98.2000301@gmail.com>
 <20151122023630.Horde.YgAxkfni4xS7fRdlcpIUGSp@avocado.salatschuessel.net>
 <565124E1.8050001@gmail.com>
Message-ID: <CAH1jEzYW9DBrSE0A=NnREq8qyq6vOQ6nWN6d-dwEa3mp1r20Gw@mail.gmail.com>

What I would do personally is:
1. Run in an emulator such as the ones linked above, it will be heaps
easier than the bare hardware. Need not emulate your particular machine.
Preferably would emulate your Z800x CPU but even that isn't 100% essential.
2. Get yourself a 2.11bsd filesystem, best way might be install or download
2.11bsd for PDP-11 and run in simh. Hopefully the simulated disk is in raw
form so it can be moved between simh and your emulator, otherwise you could
modify one of the emulators or convert the file somehow.
3. Figure out a way of copying between your real disk and your simulated
disk. For example run an sshd under simh and "scp" to your disk. Or mount
your file as a tape and "dd" it over to your disk with correct name. Or
whatever, there could be existing utilities that can do this. (Kind of like
msdosutils on linux has a userspace implementation of vfat and can do
simple things to vfat formatted floppies or disk images).
4. Figure out how the bootstrap works and translate it to Z800x assembly.
In essence the boot sector will load the next 16 or so sectors into memory
and jump to it. Those 16 sectors contain a cutdown version of a 2.11bsd
filesystem mounted rdonly, enough to read superblock, locate inode table,
maybe locate /boot/kernel and then load and jump to it. I can send some
examples in Z80 code for my project. Or I can take a look in 2.11bsd and
tell you how this works.
5. You now have a cross assembler and linker and a development system. Get
C working too. Compile the kernel with as many things as possible disabled
-- no disk, network, etc. Find a way for dprintf() or similar to work --
such as polled output to a serial port, or even just defining an unused
Z8001 opcode to putchar() whatever is in R1. No need for any finesse here.
6. In the first line of the kernel startup put a dprintf of "hello world".
Copy resulting kernel to /boot/kernel or whatever it is supposed to be
called. Put similar diagnostics in your bootstrap. Run and debug until your
messages come out. Then gradually step through the kernel initialization
and main loop fixing things as you go. Eventually add more subsystems.

Nick
On 22/11/2015 1:14 PM, "William Pechter" <pechter at gmail.com> wrote:

> Oliver Lehmann wrote:
>
>>
>> William Pechter <pechter at gmail.com> wrote:
>>
>>
>> I found this for a Z8000 System III box. It was an East German dual cpu
>>> Z80/Z8001 clone box running SysIII -- perhaps this may be of some help as a
>>> comparison.
>>>
>>
>> And I also redid (disassembled objects, translated it back to C) nearly
>> all Kernel sources of the SYSIII (only lock.c is missing with file
>> locking features - I only disassembled it)
>>
>> https://github.com/OlliL/P8000/tree/master/WEGA/src/uts
>>
>>
>> Emulator
>>> http://www.knothusa.net/Home.php
>>>
>>
>> Yes... he built the Emulator based on MAME back in 2008 with quite
>> some info from me - he used to work on a P8000 back in the 90s so
>> he felt for it building the Emulator.... ;)
>>
>>
>> More P8000 info
>>> http://www.pofo.de/P8000/
>>>
>>
>> Z8000 docs
>>> http://www.pofo.de/P8000/  (there's some Zilog System 8000 Z8000 Zeus
>>> info here as well.
>>>
>>
>> Cool... you found my page ;)
>>
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>
>
> Nice site... I worked for DEC back in the 80's and I ended up installing
> Exxon Office Systems'  Vaxes which
> they used for software development for the Zeus systems.  Some employees
> were from the Berkeley area
> and New Jersey, even Princeton, seemed to be culture shock.
>
> The computer room was directly under the flight path to the little
> Princeton Airport and the rented building
> wasn't really designed for those machines.  The place was small offices
> for insurance sales, accounting,
> lawyers and such.   They later moved over to a new building on the RT 1
> corridor which had a real computer room after they had all the electricity
> put in for the 11/780.
>
> They moved from California to Princeton, New Jersey back around '81 or so
> and were gone shortly
> when Exxon closed them down in '84.
>
> I think they were the first Ultrix32 box I saw in my lifetime... which was
> much more AT&T focused working
> for DEC in New Jersey.  By 92 or so I was doing SunOS 4.1.3 at work and
> FreeBSD/NetBSD at home.
>
> I never could figure out how AT&T kept the miserable self-destructive Unix
> Filesystem alive with it's 13 character filename limit and no symbolic
> links.  SysVR4 finally showed some promise, and I even
> thought they had a winner with their object-oriented management tools to
> manage getty's and printers and such.
>
> FACE, the SVR4 character terminal graphic utilities were not too bad. You
> could finally run the whole system without vi-ing configurations -- kind of
> like a pre-SUSE  Yast that used the button labels on function keys.
> Perkin-Elmer/Concurrent had a similar thing in Xelos (SVR2) on their
> block-mode capable 1251 and 6312
> terminals...  That was the thing in the 80's -- menu or function button
> Unix sysadmin screens.
>
> AT&T killed their future OEM's by allowing the OSF/USL split to happen
> over their Sun investment
> and promise that Sun would get the new Unix before everyone else. The Unix
> wars made sure there
> wouldn't be one binary/source compatible version of Unix across all
> hardware platforms.
>
> When I started to work with Solaris2 I was amazed as to how different it
> seemed than straight SVR4 and
> I helped write Pyramid's training for their OS/x SVR4 MIPS R3000 product.
>
> Had AT&T been more willing to supply the code equally and get out of the
> way you wouldn't have had
> the waste of the NCR purchase later after the less than stellar 3b and 3b2
> sales of the late 80's.
>
> To bring this back to the Z8000 ZEUS and Zilog:
>
> Pyramid was an OEM for AT&T and AT&T was to sell Pyramid boxes to the US
> Government to replace
> the Z8000 Zilog Zeus machines which were used by the IRS.  I think this
> all fell apart after the
> NCR purchase.  My job kind of went with it as Pyramid went through a
> downward sales spiral
> as AT&T stopped buying MIServers and the MIPS MIServer-S line (R3000 SVR4)
> multicpu boxes.
>
> Bill
>
> --
> Digital had it then.  Don't you wish you could buy it now!
> pechter-at-gmail.com  http://xkcd.com/705/
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151123/7a4fe56c/attachment.html>

From lehmann at ans-netz.de  Mon Nov 23 18:05:08 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Mon, 23 Nov 2015 09:05:08 +0100
Subject: [TUHS] Porting 2.11 BSD
In-Reply-To: <CAH1jEzYW9DBrSE0A=NnREq8qyq6vOQ6nWN6d-dwEa3mp1r20Gw@mail.gmail.com>
References: <20151121140022.Horde.ZwPZMYWApn-dXiuNCkiDWDA@avocado.salatschuessel.net>
 <1448151215.3670388.446383649.14D3C39D@webmail.messagingengine.com>
 <56510C98.2000301@gmail.com>
 <20151122023630.Horde.YgAxkfni4xS7fRdlcpIUGSp@avocado.salatschuessel.net>
 <565124E1.8050001@gmail.com>
 <CAH1jEzYW9DBrSE0A=NnREq8qyq6vOQ6nWN6d-dwEa3mp1r20Gw@mail.gmail.com>
Message-ID: <20151123090509.Horde.anntqPoOVbgXR9r5HlrgBxs@avocado.salatschuessel.net>

Hi Nick,

first - thank you very much the time you spent writing!

Thing is - yes - there is a P8000 emulator but it has some bugs which may
render the assembler not to produce code and so on. I feel better to use
the original hardware and my SYSIII to compile the stuff I need.

Using a harddisk image made by simh is a great idea. Porting disklabel,
mkfs and so on first would be a huge task before it works. But with the
way you proposed I would see much earlier "something" running on the
system.

Getting data from and to the current SYSIII is not an issue as I have kermit
on it and can transfer files via serial without any problem.

Getting a filesystem to the "BSD disk" for the system should also be easy
as I already build a WDC-Controller emulation hardware which uses a SD-Card
or an IDE harddrive as datastorage but behaves 100% compatible to the P8000
like the original Controller.
Using an SDCard makes it kinda easy to just dd the filesystem to/from it.

The current SYSIII Firmware, Boot and Kernel sources are as good as 100%
available which I guess would it make it a lot easier to port it to boot
from a BSD Filesystem.

The current boot process on the SYSIII is "rather simple". The firmware has
some basic functionality to boot from the harddisk. It just loads block 0
of disk 1 with a length of 200 byte into Address %8000 and executes whatever
is on that address after it was loaded

https://github.com/OlliL/P8000/blob/master/firmware/MON16/p.boot.s
(See line 609-636 - sorry for the german comments)

I definitly do not want to change the firmware in any way as I want to make
a "drop in replacement" to the current SYSIII - so no firmware modifications.
I wonder this would mean to not use disklabels for example. I guess disklabels
are stored in block 0 which would make it incompatible with the current
boot0 loading which is expected to be in block 0 - right?


Then there is currently the boot0 loader which is currently on block 0 of
the harddisk which is now executed.

This one is also implemented in ASM and is now able to understand the
filesystem. It is configured by default to open again block 0, reads a
defined inode and searches for the secondary bootloader "boot".

https://github.com/OlliL/P8000/blob/master/WEGA/src/cmd/BOOT0/boot0.md.s
(See line 128 - 277)

The secondary bootloader is implemented in C and is the first program, able
to execute segmented code like the kernel:

https://github.com/OlliL/P8000/blob/master/WEGA/src/uts/conf/boot.c


I guess, I have to port the primary bootloader first to be able to understand
UFS/FFS as it is probably different than the current SYSIII-FS and the primary
bootloader needs to "understand" it to look for the secondary bootloader.
I plan to "reuse" the current primary bootloader and just change the
filesystem code. I guess this should be enough.

The secondary bootloader is hopefully also implemented in C in 2.11  
BSD (didn't
looked it up yet) So I can modify it to understand Zilogs s.out format instead
of BSDs a.out format.
This is vital as the whole toolchain needs to be taken over to BSD as there is
just no other toolchain available compiling, assembling and linking  
Z8001 code.
I also have important binaries with no source code which need to be able to
run in BSD as well as they did in SYSIII (Z80-RIO-Emulator, CP/M-Emulator,
Cross-Assemblers for Z8, Z80). So making BSD able to understand the s.out
format of SYSIII is vital as I'm only able to compile code in s.out format
the first place.

So to summarize it... The first thing would be:

0. get simh up and running
1. get a 2.11-BSD filesystem onto a (new) SD-Card
2. modify the primary bootloader to read the UFS-filesystem
3. write a secondary bootloader which only does "hello world"
4. place the secondary bootloader onto that filesystem
5. boot it
6. fix it until it works
7. create a /unix kernel which does a "hello world"
8. modify the secondary bootloader until it is able to load
    the kernel.

What do you think?

- Is a current FreeBSD still able to read/write 2.11 BSD disks?
- I wonder how much difference the SYSIII-FS and UFS has regarding to the
   primary bootloader (boot0.md.s lines 128-158 searches for "boot").

Regards, Oliver


From fair-tuhs at netbsd.org  Mon Nov 23 18:40:40 2015
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Mon, 23 Nov 2015 00:40:40 -0800
Subject: [TUHS] Porting 2.11 BSD
In-Reply-To: <20151123090509.Horde.anntqPoOVbgXR9r5HlrgBxs@avocado.salatschuessel.net>
References: <CAH1jEzYW9DBrSE0A=NnREq8qyq6vOQ6nWN6d-dwEa3mp1r20Gw@mail.gmail.com>
Message-ID: <26595.1448268040@cesium.clock.org>

With regard to cooperating with extant system firmware, this is a problem that
NetBSD has on almost every platform it runs on (and it runs on many). You can
find many examples of how to cooperate or work-around firmware bootloaders in
our BSD-licensed codebase:

	http://www.netbsd.org/

Further, we've got a standard secondary booter framework, though we retired
a.out quite a few releases ago. See src/sys/arch/*/stand (for "stand-alone")
in our source repository. Or grab the source tarballs as you see fit.

Some of this is deja vu for me: I was a co-founder of the "Undergraduate
Computing Facility" (UCF) at UCB in 1982, and helped set up the Z8002 based
Onyx system in B50 Evans Hall that was our first and for a long time, only,
computer. The undergrads who used that system to learn Unix ported many a BSD
utility to that system (at least the ones that weren't too RAM-hungry),
starting with BerkNet so we could move files around easily & have E-mail.

	good luck,

	Erik <fair at netbsd.org>


From doug at cs.dartmouth.edu  Tue Nov 24 11:55:36 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Mon, 23 Nov 2015 20:55:36 -0500
Subject: [TUHS] "Edition 0" manual
Message-ID: <201511240155.tAO1tap2016965@coolidge.cs.Dartmouth.EDU>

Among the papers of the late Bob Morris I have found a
Unix manual that I don't remember at all--a draft by
Dennis Ritchie, in the style of (but not designated as)
a technical report with numbered sections and subsections.
It does not resemble the familiar layout of the numbered
editions. Besides the usual overview of kernel and shell,
it describes system calls and some commands, in a layout
unrelated to the familiar man-page style. Detailed
reference/tutorial manuals for as, roff, db and ed
are included as appendices.

The famous and well-justified claim that "UNIX contains a numer
of features very seldom offered even by larger systems"
appears on page 1.

A little poking around tuhs.org didn't reveal a copy of
this document. Does anybody know of one somewhere else?

Doug


From doug at cs.dartmouth.edu  Tue Nov 24 12:10:43 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Mon, 23 Nov 2015 21:10:43 -0500
Subject: [TUHS] 101 fixes for unix V6?
Message-ID: <201511240210.tAO2AhxJ017230@coolidge.cs.Dartmouth.EDU>

> The phototypesetter version of Unix was V7.

I'm not sure of what's being said here. Manuals from
the 4th edition on were phototypeaet, first on a
CAT and later a Linotron (if I remember the name right).

Doug


From wkt at tuhs.org  Tue Nov 24 12:19:18 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 24 Nov 2015 13:19:18 +1100
Subject: [TUHS] 101 fixes for unix V6?
In-Reply-To: <201511240210.tAO2AhxJ017230@coolidge.cs.Dartmouth.EDU>
References: <201511240210.tAO2AhxJ017230@coolidge.cs.Dartmouth.EDU>
Message-ID: <20151124021918.GA9640@www.oztivo.net>

On Mon, Nov 23, 2015 at 09:10:43PM -0500, Doug McIlroy wrote:
> > The phototypesetter version of Unix was V7.
> 
> I'm not sure of what's being said here. Manuals from
> the 4th edition on were phototypeaet, first on a
> CAT and later a Linotron (if I remember the name right).

Taken from http://www.darwinsys.com/history/hist.html:

The early evolution of the C language has been described elsewhere ...
It is May, 1975, and the new improved Sixth Edition is about to be released...
There follows a succession of releases of the C compiler. The PWB
1.0 release of UNIX, the first outside the labs of a non-Research
from Bell, goes out in 1977. And a special release tape known only as
``Phototypesetter Version 7'' includes a new release of troff as well
as the C compiler, assembler, loader, archiver and bits of the C library.

Cheers, Warren


From lm at mcvoy.com  Tue Nov 24 12:22:41 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Mon, 23 Nov 2015 18:22:41 -0800
Subject: [TUHS] 101 fixes for unix V6?
In-Reply-To: <20151124021918.GA9640@www.oztivo.net>
References: <201511240210.tAO2AhxJ017230@coolidge.cs.Dartmouth.EDU>
 <20151124021918.GA9640@www.oztivo.net>
Message-ID: <20151124022241.GC3979@mcvoy.com>

On Tue, Nov 24, 2015 at 01:19:18PM +1100, Warren Toomey wrote:
> On Mon, Nov 23, 2015 at 09:10:43PM -0500, Doug McIlroy wrote:
> > > The phototypesetter version of Unix was V7.
> > 
> > I'm not sure of what's being said here. Manuals from
> > the 4th edition on were phototypeaet, first on a
> > CAT and later a Linotron (if I remember the name right).
> 
> Taken from http://www.darwinsys.com/history/hist.html:
> 
> The early evolution of the C language has been described elsewhere ...
> It is May, 1975, and the new improved Sixth Edition is about to be released...
> There follows a succession of releases of the C compiler. The PWB
> 1.0 release of UNIX, the first outside the labs of a non-Research
> from Bell, goes out in 1977. And a special release tape known only as
> ``Phototypesetter Version 7'' includes a new release of troff as well
> as the C compiler, assembler, loader, archiver and bits of the C library.

It's worth noting that Unix was built for troff.  Typesetting patents
if I recall correctly.


From wkt at tuhs.org  Tue Nov 24 12:57:54 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 24 Nov 2015 13:57:54 +1100
Subject: [TUHS] "Edition 0" manual
In-Reply-To: <201511240155.tAO1tap2016965@coolidge.cs.Dartmouth.EDU>
References: <201511240155.tAO1tap2016965@coolidge.cs.Dartmouth.EDU>
Message-ID: <20151124025754.GA13195@www.oztivo.net>

On Mon, Nov 23, 2015 at 08:55:36PM -0500, Doug McIlroy wrote:
> Among the papers of the late Bob Morris I have found a
> Unix manual that I don't remember at all--a draft by
> Dennis Ritchie, in the style of (but not designated as)
> a technical report with numbered sections and subsections.
> It does not resemble the familiar layout of the numbered
> editions. Besides the usual overview of kernel and shell,
> it describes system calls and some commands, in a layout
> unrelated to the familiar man-page style. Detailed
> reference/tutorial manuals for as, roff, db and ed
> are included as appendices.
> 
> The famous and well-justified claim that "UNIX contains a numer
> of features very seldom offered even by larger systems"
> appears on page 1.
> 
> A little poking around tuhs.org didn't reveal a copy of
> this document. Does anybody know of one somewhere else?

No, I've not seen anything before Dennis' scan of the 1st
Edition manuals. Can you make a scan of this one available?

Many thanks, Warren


From arnold at skeeve.com  Tue Nov 24 13:55:54 2015
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Mon, 23 Nov 2015 20:55:54 -0700
Subject: [TUHS] "Edition 0" manual
In-Reply-To: <20151124025754.GA13195@www.oztivo.net>
References: <201511240155.tAO1tap2016965@coolidge.cs.Dartmouth.EDU>
 <20151124025754.GA13195@www.oztivo.net>
Message-ID: <201511240355.tAO3tsk0020862@freefriends.org>

> > A little poking around tuhs.org didn't reveal a copy of
> > this document. Does anybody know of one somewhere else?
>
> No, I've not seen anything before Dennis' scan of the 1st
> Edition manuals. Can you make a scan of this one available?

Seconded. Please? Pretty please?

Thanks!

Arnold


From random832 at fastmail.com  Tue Nov 24 16:41:15 2015
From: random832 at fastmail.com (Random832)
Date: Tue, 24 Nov 2015 06:41:15 +0000 (UTC)
Subject: [TUHS] "Edition 0" manual
References: <201511240155.tAO1tap2016965@coolidge.cs.Dartmouth.EDU>
Message-ID: <n310qa$92q$2@ger.gmane.org>

On 2015-11-24, Doug McIlroy wrote:
> The famous and well-justified claim that "UNIX contains a numer
> of features very seldom offered even by larger systems"
> appears on page 1.
>
> A little poking around tuhs.org didn't reveal a copy of
> this document. Does anybody know of one somewhere else?

Is this The UNIX Time-Sharing System, or related to it? The same
claim appears in the first paragraph:

https://www.bell-labs.com/usr/dmr/www/cacm.html



From milov at cs.uwlax.edu  Wed Nov 25 00:12:40 2015
From: milov at cs.uwlax.edu (=?utf-8?Q?Milo_Velimirovi=C4=87?=)
Date: Tue, 24 Nov 2015 08:12:40 -0600
Subject: [TUHS] 101 fixes for unix V6?
In-Reply-To: <201511240210.tAO2AhxJ017230@coolidge.cs.Dartmouth.EDU>
References: <201511240210.tAO2AhxJ017230@coolidge.cs.Dartmouth.EDU>
Message-ID: <2807955C-14EA-4C76-BEE1-2DCA1993E166@cs.uwlax.edu>


> On Nov 23, 2015, at 8:10 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
> 
>> The phototypesetter version of Unix was V7.
> 
> I'm not sure of what's being said here. Manuals from
> the 4th edition on were phototypeaet, first on a
> CAT and later a Linotron (if I remember the name right).

Mergenthaler(-Linotype) Linotron 202

I used one of these beasts, a CRT based phototypesetter, in the late 1980s - 8” floppy disks, serial communication that pretended to be a paper tape reader. One of those times we really needed a Users' Group and there wasn’t one.

See also the memo, recently publicized here, ‘Experience with the Mergenthaler Linotron 202 Phototypesetter, or, How We Spent Our Summer Vacation’ https://www.cs.princeton.edu/~bwk/202/summer.scanned.pdf

I wish I had had access to the schematics at the end of the memo. That would have saved days of work!
 

 - MIlo

From doug at cs.dartmouth.edu  Wed Nov 25 08:40:50 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Tue, 24 Nov 2015 17:40:50 -0500
Subject: [TUHS] "Edition 0" manual
Message-ID: <201511242240.tAOMeok8029855@coolidge.cs.Dartmouth.EDU>


> I've not seen anything before Dennis' scan of the 1st
> Edition manuals. Can you make a scan of this one available?

I shall, as I had intended to do if this document was as
unknown or forgotten by others as it was by me.

Doug


From aek at bitsavers.org  Wed Nov 25 10:09:18 2015
From: aek at bitsavers.org (Al Kossow)
Date: Tue, 24 Nov 2015 16:09:18 -0800
Subject: [TUHS] Porting 2.11 BSD
In-Reply-To: <26595.1448268040@cesium.clock.org>
References: <CAH1jEzYW9DBrSE0A=NnREq8qyq6vOQ6nWN6d-dwEa3mp1r20Gw@mail.gmail.com>
 <26595.1448268040@cesium.clock.org>
Message-ID: <5654FC2E.9010207@bitsavers.org>



On 11/23/15 12:40 AM, Erik E. Fair wrote:
> The undergrads who used that system to learn Unix ported many
> a BSD
> utility to that system (at least the ones that weren't too RAM-hungry),
> starting with BerkNet so we could move files around easily & have E-mail.
>
>

That reminds me that you are going to run into utilities that use the
overlaying ld that jumps through hoops to get large programs (vi) to run 
in a 16 bit address space.

I'll dig through my archives and see if there was a Z8000 version of pcc
in the MIT compiler kit.





From wkt at tuhs.org  Wed Nov 25 14:49:20 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 25 Nov 2015 15:49:20 +1100
Subject: [TUHS] What's planned for mid-2019 for Unix's 50th anniversary?
Message-ID: <20151125044920.GA18103@www.oztivo.net>

I know that I'm jumping the gun a bit, but if/when someone has any news
of any 50th anniversary celebrations for Unix in mid-2019?

I'd love to start planning things now, given I'm in Australia and I also
need to convince my darling wife of the need for a holiday in the U.S
[or elsewhere 8-) ].

I will keep asking every six months.

Cheers, Warren


From doug at cs.dartmouth.edu  Wed Nov 25 15:08:17 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Wed, 25 Nov 2015 00:08:17 -0500
Subject: [TUHS] "Edition 0" manual
Message-ID: <201511250508.tAP58HYf032656@coolidge.cs.Dartmouth.EDU>


> It's worth noting that Unix was built for troff.  Typesetting patents
if I recall correctly.

This is a stretch. Unix was really built because Ken and Dennis
had a good idea. The purchase of a PDP-11 for it was in part
justified by the goal of making a word-processing system. The
first in-house "sale" of Unix was indeed to the patent department
for typing patents--the selling point was that roff could be
made (by an overnight modification) to print line numbers as
USPTO required, whereas that was not a feature of a commercial
competitor. The timeline is really roff--Unix--patent--nroff--troff.
Though roff antedated Unix, it did not motivate Unix.

> Is this The UNIX Time-Sharing System, or related to it? The same
> claim appears in the first paragraph:
> https://www.bell-labs.com/usr/dmr/www/cacm.html

This draft clearly dates from 1971. Pieces of it were worked
into subsequent versions of the manual as well as published
descriptions of Unix, including the SIGOPS/CACM paper.

Doug


From b4 at gewt.net  Wed Nov 25 15:55:13 2015
From: b4 at gewt.net (Cory Smelosky)
Date: Tue, 24 Nov 2015 21:55:13 -0800
Subject: [TUHS] What's planned for mid-2019 for Unix's 50th anniversary?
In-Reply-To: <20151125044920.GA18103@www.oztivo.net>
References: <20151125044920.GA18103@www.oztivo.net>
Message-ID: <52FAA821-5AA8-4AB9-973E-8EB0304849E6@gewt.net>

Maybe I'll get some BSDi people to crowd around the recovered BSDi signage...;)

Sent from my iPhone

> On Nov 24, 2015, at 20:49, Warren Toomey <wkt at tuhs.org> wrote:
> 
> I know that I'm jumping the gun a bit, but if/when someone has any news
> of any 50th anniversary celebrations for Unix in mid-2019?
> 
> I'd love to start planning things now, given I'm in Australia and I also
> need to convince my darling wife of the need for a holiday in the U.S
> [or elsewhere 8-) ].
> 
> I will keep asking every six months.
> 
> Cheers, Warren
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From b4 at gewt.net  Wed Nov 25 15:56:18 2015
From: b4 at gewt.net (Cory Smelosky)
Date: Tue, 24 Nov 2015 21:56:18 -0800
Subject: [TUHS] What's planned for mid-2019 for Unix's 50th anniversary?
In-Reply-To: <52FAA821-5AA8-4AB9-973E-8EB0304849E6@gewt.net>
References: <20151125044920.GA18103@www.oztivo.net>
 <52FAA821-5AA8-4AB9-973E-8EB0304849E6@gewt.net>
Message-ID: <3496E36B-E455-47FD-A3E2-5670EBE9B675@gewt.net>

Kidding. ;)

Maybe a co-written historical post from a bunch of UNIX people, arranged chronologically?

Sent from my iPhone

> On Nov 24, 2015, at 21:55, Cory Smelosky <b4 at gewt.net> wrote:
> 
> Maybe I'll get some BSDi people to crowd around the recovered BSDi signage...;)
> 
> Sent from my iPhone
> 
>> On Nov 24, 2015, at 20:49, Warren Toomey <wkt at tuhs.org> wrote:
>> 
>> I know that I'm jumping the gun a bit, but if/when someone has any news
>> of any 50th anniversary celebrations for Unix in mid-2019?
>> 
>> I'd love to start planning things now, given I'm in Australia and I also
>> need to convince my darling wife of the need for a holiday in the U.S
>> [or elsewhere 8-) ].
>> 
>> I will keep asking every six months.
>> 
>> Cheers, Warren
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs


From lehmann at ans-netz.de  Wed Nov 25 20:14:51 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Wed, 25 Nov 2015 11:14:51 +0100
Subject: [TUHS] Porting 2.11 BSD
In-Reply-To: <5654FC2E.9010207@bitsavers.org>
References: <CAH1jEzYW9DBrSE0A=NnREq8qyq6vOQ6nWN6d-dwEa3mp1r20Gw@mail.gmail.com>
 <26595.1448268040@cesium.clock.org> <5654FC2E.9010207@bitsavers.org>
Message-ID: <20151125111451.Horde.YYentpTkevlAUuLEIvnGxYQ@avocado.salatschuessel.net>


Al Kossow <aek at bitsavers.org> wrote:

> On 11/23/15 12:40 AM, Erik E. Fair wrote:
>> The undergrads who used that system to learn Unix ported many
>> a BSD
>> utility to that system (at least the ones that weren't too RAM-hungry),
>> starting with BerkNet so we could move files around easily & have E-mail.
>>
>>
>
> That reminds me that you are going to run into utilities that use the
> overlaying ld that jumps through hoops to get large programs (vi) to  
> run in a 16 bit address space.

Good point. I was also thinking if 2.11 is realy the right choice to use
for porting. From what I understood:

- The PDP11 can only access up to 64KB address space.
- 2.11 uses overlay to "show" and "hide" memory into this 64K address
   space.

A Z8001 can address up to 128 segments of 64KB. Means, a single array can
only be up to 64KB, but you can have 8MB of memory per "section". My system
has 3 MMUs while one is dedicated to the code section and one to the data
section. So my Code section can be max up to 8MB and my data section can be
up to additional 8MB. Currently my system has up to 5.5MB of RAM (but can
be upgraded to 16MB easily)

I was thinking if 4.3 BSD would be better to port as the whole overlay logic
which is implemented in 2.11 could make 2.11 maybe to complex to port? I
mean, all this overlay logic would not be needed for the Z8001 and it maybe
would not even work. (remember - I plan to use my existing SYSIII compiler
which knows nothing about overlaying!)

What I understand for 4.3 BSD is, that it is meant to run on machines with
a memory configuration where the memory is adressable in "one block" which
is of course not true for the Z8001. But - the compiler/assembler handles
all this adressing for C code so why should it be imported on how the is
addressed internaly?

Additionaly, my system has NO floating point support. The current SYSIII
uses a lengthy floating point emulation Assembler Source to "work around"
that:
https://github.com/OlliL/P8000/blob/master/WEGA/src/uts/conf/fpe.s

I saw, that 2.11 also has some FPU-emulation. What about 4.3?

Could 4.3 be a better choice? If so - which 4.3 should I use?

In general - I'm looking for a good target OS. It should be not too
complex (-> "modern") but should provide a TCP/IP stack which is my
main motivation in porting at all.


> I'll dig through my archives and see if there was a Z8000 version of pcc
> in the MIT compiler kit.

That would be great - maybe you could also answer my private mail about
the Onyx C8002 I sent you some days ago ;)
The compilers for Z8000 I found so far where either able to address 64K
only, or where able to only generate COFF-format objects which I can't
link on my SYSIII...


Oliver


From downing.nick at gmail.com  Wed Nov 25 21:25:18 2015
From: downing.nick at gmail.com (Nick Downing)
Date: Wed, 25 Nov 2015 22:25:18 +1100
Subject: [TUHS] Porting 2.11 BSD
In-Reply-To: <20151125111451.Horde.YYentpTkevlAUuLEIvnGxYQ@avocado.salatschuessel.net>
References: <CAH1jEzYW9DBrSE0A=NnREq8qyq6vOQ6nWN6d-dwEa3mp1r20Gw@mail.gmail.com>
 <26595.1448268040@cesium.clock.org>
 <5654FC2E.9010207@bitsavers.org>
 <20151125111451.Horde.YYentpTkevlAUuLEIvnGxYQ@avocado.salatschuessel.net>
Message-ID: <CAH1jEzY2d-dVgjtLRKEQwTJcvAk000kAx7+T63QgMyfyKs0TbA@mail.gmail.com>

According to this:
https://archive.org/stream/bitsavers_zilogz80000mmu_742400/z8010_mmu_djvu.txt
You could use only segment 0 and program the code MMU to point segment 0 to
some physical address and the data and stack MMUs to point segment 0 to
some other physical address and you have a split I/D system capable of
running 2.11bsd assuming the compiler knows nothing of segments as you
said. Or, as outlined in my previous posts you can use a compiler that has
23-bit pointers and understands how to output the high 7 bits as the
segment and the low 16 bits as the logical address each time it
dereferences a pointer (if such a compiler exists) and port 4.3bsd.

Nick
On 25/11/2015 9:15 PM, "Oliver Lehmann" <lehmann at ans-netz.de> wrote:

>
> Al Kossow <aek at bitsavers.org> wrote:
>
> On 11/23/15 12:40 AM, Erik E. Fair wrote:
>>
>>> The undergrads who used that system to learn Unix ported many
>>> a BSD
>>> utility to that system (at least the ones that weren't too RAM-hungry),
>>> starting with BerkNet so we could move files around easily & have E-mail.
>>>
>>>
>>>
>> That reminds me that you are going to run into utilities that use the
>> overlaying ld that jumps through hoops to get large programs (vi) to run
>> in a 16 bit address space.
>>
>
> Good point. I was also thinking if 2.11 is realy the right choice to use
> for porting. From what I understood:
>
> - The PDP11 can only access up to 64KB address space.
> - 2.11 uses overlay to "show" and "hide" memory into this 64K address
>   space.
>
> A Z8001 can address up to 128 segments of 64KB. Means, a single array can
> only be up to 64KB, but you can have 8MB of memory per "section". My system
> has 3 MMUs while one is dedicated to the code section and one to the data
> section. So my Code section can be max up to 8MB and my data section can be
> up to additional 8MB. Currently my system has up to 5.5MB of RAM (but can
> be upgraded to 16MB easily)
>
> I was thinking if 4.3 BSD would be better to port as the whole overlay
> logic
> which is implemented in 2.11 could make 2.11 maybe to complex to port? I
> mean, all this overlay logic would not be needed for the Z8001 and it maybe
> would not even work. (remember - I plan to use my existing SYSIII compiler
> which knows nothing about overlaying!)
>
> What I understand for 4.3 BSD is, that it is meant to run on machines with
> a memory configuration where the memory is adressable in "one block" which
> is of course not true for the Z8001. But - the compiler/assembler handles
> all this adressing for C code so why should it be imported on how the is
> addressed internaly?
>
> Additionaly, my system has NO floating point support. The current SYSIII
> uses a lengthy floating point emulation Assembler Source to "work around"
> that:
> https://github.com/OlliL/P8000/blob/master/WEGA/src/uts/conf/fpe.s
>
> I saw, that 2.11 also has some FPU-emulation. What about 4.3?
>
> Could 4.3 be a better choice? If so - which 4.3 should I use?
>
> In general - I'm looking for a good target OS. It should be not too
> complex (-> "modern") but should provide a TCP/IP stack which is my
> main motivation in porting at all.
>
>
> I'll dig through my archives and see if there was a Z8000 version of pcc
>> in the MIT compiler kit.
>>
>
> That would be great - maybe you could also answer my private mail about
> the Onyx C8002 I sent you some days ago ;)
> The compilers for Z8000 I found so far where either able to address 64K
> only, or where able to only generate COFF-format objects which I can't
> link on my SYSIII...
>
>
> Oliver
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151125/8690acff/attachment.html>

From downing.nick at gmail.com  Wed Nov 25 21:46:51 2015
From: downing.nick at gmail.com (Nick Downing)
Date: Wed, 25 Nov 2015 22:46:51 +1100
Subject: [TUHS] Porting 2.11 BSD
In-Reply-To: <CAH1jEzY2d-dVgjtLRKEQwTJcvAk000kAx7+T63QgMyfyKs0TbA@mail.gmail.com>
References: <CAH1jEzYW9DBrSE0A=NnREq8qyq6vOQ6nWN6d-dwEa3mp1r20Gw@mail.gmail.com>
 <26595.1448268040@cesium.clock.org>
 <5654FC2E.9010207@bitsavers.org>
 <20151125111451.Horde.YYentpTkevlAUuLEIvnGxYQ@avocado.salatschuessel.net>
 <CAH1jEzY2d-dVgjtLRKEQwTJcvAk000kAx7+T63QgMyfyKs0TbA@mail.gmail.com>
Message-ID: <CAH1jEzY0WJ1HMgAJYuwWw8b0epi3Ev6mLp7eb230r3mbCcseMg@mail.gmail.com>

Oh yeah, the other thing i was going to say was you'd be well advised to
use the "ld" that comes with 2.11bsd, which generates a.out (a header of
about 16 bytes followed by the raw code and data segments), as well as its
somewhat primitive *.o file format (which is an a.out executable followed
by relocation and linkage tables, so *.o objects are actually executable if
they contain a main() function and no unresolved linkage).

What you could do is create a small converter that changes your COFF or
whatever objects into the right format. Then everything will just work(tm).
The linker itself is a bit hard to modify IIRC, it's a split I/D executable
that basically constructs the output executable in its D address space so
memory is a bit tight and some tricks are used like doing separate passes
for code and data.

Having said all that, I think in my case I took a simple Z80 assembler and
linker that were open sourced and not too horrible internally, and
understood Intel HEX records, and then I simply had the IAR compiler (a
commercial product) generate assembly and I didn't use the IAR assembler or
linker. Then I modified the linker to create a either an original style
(non split I/D) a.out executable or a special extended a.out executable
that was similar to split I/D except the instructions were in multiple
pages 4kbytes in size and the data was up to 56kbytes in size, so they
could share the 64kbyte logical address space (the first 4kbytes was
permanently mapped regardless of context switches and contained interrupt
and trap handlers).

You probably won't need to go to the above extremes, but you could easily
modify my linker to create normal a.out executables with/without split I/D
if you're wanting to use HEX records as the input rather than 2.11bsd's *.o
files. Only thing is it's a cross linker, the code is quite simple but it
won't link big executables from a small address space the way 2.11bsd "ld"
would do.

Nick
On 25/11/2015 10:26 PM, downing.nick at gmail.com wrote:

> According to this:
>
> https://archive.org/stream/bitsavers_zilogz80000mmu_742400/z8010_mmu_djvu.txt
> You could use only segment 0 and program the code MMU to point segment 0
> to some physical address and the data and stack MMUs to point segment 0 to
> some other physical address and you have a split I/D system capable of
> running 2.11bsd assuming the compiler knows nothing of segments as you
> said. Or, as outlined in my previous posts you can use a compiler that has
> 23-bit pointers and understands how to output the high 7 bits as the
> segment and the low 16 bits as the logical address each time it
> dereferences a pointer (if such a compiler exists) and port 4.3bsd.
>
> Nick
> On 25/11/2015 9:15 PM, "Oliver Lehmann" <lehmann at ans-netz.de> wrote:
>
>>
>> Al Kossow <aek at bitsavers.org> wrote:
>>
>> On 11/23/15 12:40 AM, Erik E. Fair wrote:
>>>
>>>> The undergrads who used that system to learn Unix ported many
>>>> a BSD
>>>> utility to that system (at least the ones that weren't too RAM-hungry),
>>>> starting with BerkNet so we could move files around easily & have
>>>> E-mail.
>>>>
>>>>
>>>>
>>> That reminds me that you are going to run into utilities that use the
>>> overlaying ld that jumps through hoops to get large programs (vi) to run
>>> in a 16 bit address space.
>>>
>>
>> Good point. I was also thinking if 2.11 is realy the right choice to use
>> for porting. From what I understood:
>>
>> - The PDP11 can only access up to 64KB address space.
>> - 2.11 uses overlay to "show" and "hide" memory into this 64K address
>>   space.
>>
>> A Z8001 can address up to 128 segments of 64KB. Means, a single array can
>> only be up to 64KB, but you can have 8MB of memory per "section". My
>> system
>> has 3 MMUs while one is dedicated to the code section and one to the data
>> section. So my Code section can be max up to 8MB and my data section can
>> be
>> up to additional 8MB. Currently my system has up to 5.5MB of RAM (but can
>> be upgraded to 16MB easily)
>>
>> I was thinking if 4.3 BSD would be better to port as the whole overlay
>> logic
>> which is implemented in 2.11 could make 2.11 maybe to complex to port? I
>> mean, all this overlay logic would not be needed for the Z8001 and it
>> maybe
>> would not even work. (remember - I plan to use my existing SYSIII compiler
>> which knows nothing about overlaying!)
>>
>> What I understand for 4.3 BSD is, that it is meant to run on machines with
>> a memory configuration where the memory is adressable in "one block" which
>> is of course not true for the Z8001. But - the compiler/assembler handles
>> all this adressing for C code so why should it be imported on how the is
>> addressed internaly?
>>
>> Additionaly, my system has NO floating point support. The current SYSIII
>> uses a lengthy floating point emulation Assembler Source to "work around"
>> that:
>> https://github.com/OlliL/P8000/blob/master/WEGA/src/uts/conf/fpe.s
>>
>> I saw, that 2.11 also has some FPU-emulation. What about 4.3?
>>
>> Could 4.3 be a better choice? If so - which 4.3 should I use?
>>
>> In general - I'm looking for a good target OS. It should be not too
>> complex (-> "modern") but should provide a TCP/IP stack which is my
>> main motivation in porting at all.
>>
>>
>> I'll dig through my archives and see if there was a Z8000 version of pcc
>>> in the MIT compiler kit.
>>>
>>
>> That would be great - maybe you could also answer my private mail about
>> the Onyx C8002 I sent you some days ago ;)
>> The compilers for Z8000 I found so far where either able to address 64K
>> only, or where able to only generate COFF-format objects which I can't
>> link on my SYSIII...
>>
>>
>> Oliver
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151125/d8366ed9/attachment.html>

From lehmann at ans-netz.de  Wed Nov 25 21:51:28 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Wed, 25 Nov 2015 12:51:28 +0100
Subject: [TUHS] Porting 2.11 BSD
In-Reply-To: <CAH1jEzY2d-dVgjtLRKEQwTJcvAk000kAx7+T63QgMyfyKs0TbA@mail.gmail.com>
References: <CAH1jEzYW9DBrSE0A=NnREq8qyq6vOQ6nWN6d-dwEa3mp1r20Gw@mail.gmail.com>
 <26595.1448268040@cesium.clock.org> <5654FC2E.9010207@bitsavers.org>
 <20151125111451.Horde.YYentpTkevlAUuLEIvnGxYQ@avocado.salatschuessel.net>
 <CAH1jEzY2d-dVgjtLRKEQwTJcvAk000kAx7+T63QgMyfyKs0TbA@mail.gmail.com>
Message-ID: <20151125125128.Horde.oGU9jlpPxZu6Cp9of9ENj6W@avocado.salatschuessel.net>

Hi Nick,


Nick Downing <downing.nick at gmail.com> wrote:

> According to this:
> https://archive.org/stream/bitsavers_zilogz80000mmu_742400/z8010_mmu_djvu.txt
> You could use only segment 0 and program the code MMU to point segment 0 to
> some physical address and the data and stack MMUs to point segment 0 to
> some other physical address and you have a split I/D system capable of
> running 2.11bsd assuming the compiler knows nothing of segments as you
> said. Or, as outlined in my previous posts you can use a compiler that has
> 23-bit pointers and understands how to output the high 7 bits as the
> segment and the low 16 bits as the logical address each time it
> dereferences a pointer (if such a compiler exists) and port 4.3bsd.

I have two compilers ;)

One compiler which creates "unsegmented binaries". The assembler code which
is generated only uses 16bit pointer addresses (r0-r15) and only works on
segment 0.

This compiler is for example used to compile the boot loaders and standalone
utilities iirc and other "small" binaries on my SYSIII.

http://pofo.de/cgi-bin/man.cgi?query=cc


There is also a "segmented compiler" which uses the 32bit registers (rr0-rr14)
to store the pointer adresses.
It is currently used for compiling the SYSIII kernel (which is much  
bigger than
the 2.11 BSD kernel I saw) and all other "to big" binaries.

http://pofo.de/cgi-bin/man.cgi?query=scc

And this would mean that "such a compiler exists" (referencing to your
mail) and I could or should port 4.3 BSD?


From lehmann at ans-netz.de  Wed Nov 25 21:56:56 2015
From: lehmann at ans-netz.de (Oliver Lehmann)
Date: Wed, 25 Nov 2015 12:56:56 +0100
Subject: [TUHS] Porting 2.11 BSD
In-Reply-To: <CAH1jEzY0WJ1HMgAJYuwWw8b0epi3Ev6mLp7eb230r3mbCcseMg@mail.gmail.com>
References: <CAH1jEzYW9DBrSE0A=NnREq8qyq6vOQ6nWN6d-dwEa3mp1r20Gw@mail.gmail.com>
 <26595.1448268040@cesium.clock.org> <5654FC2E.9010207@bitsavers.org>
 <20151125111451.Horde.YYentpTkevlAUuLEIvnGxYQ@avocado.salatschuessel.net>
 <CAH1jEzY2d-dVgjtLRKEQwTJcvAk000kAx7+T63QgMyfyKs0TbA@mail.gmail.com>
 <CAH1jEzY0WJ1HMgAJYuwWw8b0epi3Ev6mLp7eb230r3mbCcseMg@mail.gmail.com>
Message-ID: <20151125125656.Horde.Ig6s1CBXkowBNyqca0D4dGJ@avocado.salatschuessel.net>

Hi Nick,

why can't I just "reuse" my SYSIII linker which has all the support for
segmented and unsegmented binaries what a.out does not support. The Zilog
format is called s.out.

I thought I could teach the BSD kernel how to execute s.out binaries
(how to execute them is already there in my SYSIII sources) and I could
just reuse the ld and sld (for segmented programms) from my SYSIII?

Please check the header for all the magics currently supported.
https://github.com/OlliL/P8000/blob/master/WEGA/src/head/s.out.h

So why should I use the COFF assembler at all? I plan to do the development
on my current SYSIII-System where I have all the toolchain available....

I still don't see the need of an cross-compiler-environment while I have
the real hardware there capable of compiling my code.... I would just go
and fill up the BSD kernel with functionality, reboot the system, load the
kernel and do that until it goes up and tries to mount rootfs. When
this happens, I'll go and teach my boot0-loader UFS and start creating an
UFS harddisk and put the kernel onto that. Until that point I could even
test all my stuff on my SYSIII-Filesystem. And I guess it will be LOTS of
time until I reach the step when the rootfs is being accessed.

Oliver

Nick Downing <downing.nick at gmail.com> wrote:

> Oh yeah, the other thing i was going to say was you'd be well advised to
> use the "ld" that comes with 2.11bsd, which generates a.out (a header of
> about 16 bytes followed by the raw code and data segments), as well as its
> somewhat primitive *.o file format (which is an a.out executable followed
> by relocation and linkage tables, so *.o objects are actually executable if
> they contain a main() function and no unresolved linkage).
>
> What you could do is create a small converter that changes your COFF or
> whatever objects into the right format. Then everything will just work(tm).
> The linker itself is a bit hard to modify IIRC, it's a split I/D executable
> that basically constructs the output executable in its D address space so
> memory is a bit tight and some tricks are used like doing separate passes
> for code and data.
>
> Having said all that, I think in my case I took a simple Z80 assembler and
> linker that were open sourced and not too horrible internally, and
> understood Intel HEX records, and then I simply had the IAR compiler (a
> commercial product) generate assembly and I didn't use the IAR assembler or
> linker. Then I modified the linker to create a either an original style
> (non split I/D) a.out executable or a special extended a.out executable
> that was similar to split I/D except the instructions were in multiple
> pages 4kbytes in size and the data was up to 56kbytes in size, so they
> could share the 64kbyte logical address space (the first 4kbytes was
> permanently mapped regardless of context switches and contained interrupt
> and trap handlers).
>
> You probably won't need to go to the above extremes, but you could easily
> modify my linker to create normal a.out executables with/without split I/D
> if you're wanting to use HEX records as the input rather than 2.11bsd's *.o
> files. Only thing is it's a cross linker, the code is quite simple but it
> won't link big executables from a small address space the way 2.11bsd "ld"
> would do.
>
> Nick
> On 25/11/2015 10:26 PM, downing.nick at gmail.com wrote:
>
>> According to this:
>>
>> https://archive.org/stream/bitsavers_zilogz80000mmu_742400/z8010_mmu_djvu.txt
>> You could use only segment 0 and program the code MMU to point segment 0
>> to some physical address and the data and stack MMUs to point segment 0 to
>> some other physical address and you have a split I/D system capable of
>> running 2.11bsd assuming the compiler knows nothing of segments as you
>> said. Or, as outlined in my previous posts you can use a compiler that has
>> 23-bit pointers and understands how to output the high 7 bits as the
>> segment and the low 16 bits as the logical address each time it
>> dereferences a pointer (if such a compiler exists) and port 4.3bsd.
>>
>> Nick
>> On 25/11/2015 9:15 PM, "Oliver Lehmann" <lehmann at ans-netz.de> wrote:
>>
>>>
>>> Al Kossow <aek at bitsavers.org> wrote:
>>>
>>> On 11/23/15 12:40 AM, Erik E. Fair wrote:
>>>>
>>>>> The undergrads who used that system to learn Unix ported many
>>>>> a BSD
>>>>> utility to that system (at least the ones that weren't too RAM-hungry),
>>>>> starting with BerkNet so we could move files around easily & have
>>>>> E-mail.
>>>>>
>>>>>
>>>>>
>>>> That reminds me that you are going to run into utilities that use the
>>>> overlaying ld that jumps through hoops to get large programs (vi) to run
>>>> in a 16 bit address space.
>>>>
>>>
>>> Good point. I was also thinking if 2.11 is realy the right choice to use
>>> for porting. From what I understood:
>>>
>>> - The PDP11 can only access up to 64KB address space.
>>> - 2.11 uses overlay to "show" and "hide" memory into this 64K address
>>>   space.
>>>
>>> A Z8001 can address up to 128 segments of 64KB. Means, a single array can
>>> only be up to 64KB, but you can have 8MB of memory per "section". My
>>> system
>>> has 3 MMUs while one is dedicated to the code section and one to the data
>>> section. So my Code section can be max up to 8MB and my data section can
>>> be
>>> up to additional 8MB. Currently my system has up to 5.5MB of RAM (but can
>>> be upgraded to 16MB easily)
>>>
>>> I was thinking if 4.3 BSD would be better to port as the whole overlay
>>> logic
>>> which is implemented in 2.11 could make 2.11 maybe to complex to port? I
>>> mean, all this overlay logic would not be needed for the Z8001 and it
>>> maybe
>>> would not even work. (remember - I plan to use my existing SYSIII compiler
>>> which knows nothing about overlaying!)
>>>
>>> What I understand for 4.3 BSD is, that it is meant to run on machines with
>>> a memory configuration where the memory is adressable in "one block" which
>>> is of course not true for the Z8001. But - the compiler/assembler handles
>>> all this adressing for C code so why should it be imported on how the is
>>> addressed internaly?
>>>
>>> Additionaly, my system has NO floating point support. The current SYSIII
>>> uses a lengthy floating point emulation Assembler Source to "work around"
>>> that:
>>> https://github.com/OlliL/P8000/blob/master/WEGA/src/uts/conf/fpe.s
>>>
>>> I saw, that 2.11 also has some FPU-emulation. What about 4.3?
>>>
>>> Could 4.3 be a better choice? If so - which 4.3 should I use?
>>>
>>> In general - I'm looking for a good target OS. It should be not too
>>> complex (-> "modern") but should provide a TCP/IP stack which is my
>>> main motivation in porting at all.
>>>
>>>
>>> I'll dig through my archives and see if there was a Z8000 version of pcc
>>>> in the MIT compiler kit.
>>>>
>>>
>>> That would be great - maybe you could also answer my private mail about
>>> the Onyx C8002 I sent you some days ago ;)
>>> The compilers for Z8000 I found so far where either able to address 64K
>>> only, or where able to only generate COFF-format objects which I can't
>>> link on my SYSIII...
>>>
>>>
>>> Oliver
>>> _______________________________________________
>>> TUHS mailing list
>>> TUHS at minnie.tuhs.org
>>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>>
>>




From downing.nick at gmail.com  Wed Nov 25 22:01:07 2015
From: downing.nick at gmail.com (Nick Downing)
Date: Wed, 25 Nov 2015 23:01:07 +1100
Subject: [TUHS] Porting 2.11 BSD
In-Reply-To: <20151125125128.Horde.oGU9jlpPxZu6Cp9of9ENj6W@avocado.salatschuessel.net>
References: <CAH1jEzYW9DBrSE0A=NnREq8qyq6vOQ6nWN6d-dwEa3mp1r20Gw@mail.gmail.com>
 <26595.1448268040@cesium.clock.org>
 <5654FC2E.9010207@bitsavers.org>
 <20151125111451.Horde.YYentpTkevlAUuLEIvnGxYQ@avocado.salatschuessel.net>
 <CAH1jEzY2d-dVgjtLRKEQwTJcvAk000kAx7+T63QgMyfyKs0TbA@mail.gmail.com>
 <20151125125128.Horde.oGU9jlpPxZu6Cp9of9ENj6W@avocado.salatschuessel.net>
Message-ID: <CAH1jEzZvD1ncAHAMWVT9cH9HUTFey1tunWK5LJXMqV+ox3bCAA@mail.gmail.com>

Yeah, I would definitely go for 4.3bsd using scc in that case. The 64 kbyte
limitation of 2.11bsd using cc will cause continual hassles, even with
split I/D which relaxes things a bit (for example the issue of linking big
executables and the workarounds employed by 2.11bsd "ld"). You might also
consider 4.4bsdlite if you want to be able to release your work, you could
grab any missing pieces that aren't in assembly from 386bsd etc.
Nick
On 25/11/2015 10:51 PM, "Oliver Lehmann" <lehmann at ans-netz.de> wrote:

> Hi Nick,
>
>
> Nick Downing <downing.nick at gmail.com> wrote:
>
> According to this:
>>
>> https://archive.org/stream/bitsavers_zilogz80000mmu_742400/z8010_mmu_djvu.txt
>> You could use only segment 0 and program the code MMU to point segment 0
>> to
>> some physical address and the data and stack MMUs to point segment 0 to
>> some other physical address and you have a split I/D system capable of
>> running 2.11bsd assuming the compiler knows nothing of segments as you
>> said. Or, as outlined in my previous posts you can use a compiler that has
>> 23-bit pointers and understands how to output the high 7 bits as the
>> segment and the low 16 bits as the logical address each time it
>> dereferences a pointer (if such a compiler exists) and port 4.3bsd.
>>
>
> I have two compilers ;)
>
> One compiler which creates "unsegmented binaries". The assembler code which
> is generated only uses 16bit pointer addresses (r0-r15) and only works on
> segment 0.
>
> This compiler is for example used to compile the boot loaders and
> standalone
> utilities iirc and other "small" binaries on my SYSIII.
>
> http://pofo.de/cgi-bin/man.cgi?query=cc
>
>
> There is also a "segmented compiler" which uses the 32bit registers
> (rr0-rr14)
> to store the pointer adresses.
> It is currently used for compiling the SYSIII kernel (which is much bigger
> than
> the 2.11 BSD kernel I saw) and all other "to big" binaries.
>
> http://pofo.de/cgi-bin/man.cgi?query=scc
>
> And this would mean that "such a compiler exists" (referencing to your
> mail) and I could or should port 4.3 BSD?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151125/4073ca48/attachment.html>

From downing.nick at gmail.com  Wed Nov 25 22:10:26 2015
From: downing.nick at gmail.com (Nick Downing)
Date: Wed, 25 Nov 2015 23:10:26 +1100
Subject: [TUHS] Porting 2.11 BSD
In-Reply-To: <20151125125656.Horde.Ig6s1CBXkowBNyqca0D4dGJ@avocado.salatschuessel.net>
References: <CAH1jEzYW9DBrSE0A=NnREq8qyq6vOQ6nWN6d-dwEa3mp1r20Gw@mail.gmail.com>
 <26595.1448268040@cesium.clock.org>
 <5654FC2E.9010207@bitsavers.org>
 <20151125111451.Horde.YYentpTkevlAUuLEIvnGxYQ@avocado.salatschuessel.net>
 <CAH1jEzY2d-dVgjtLRKEQwTJcvAk000kAx7+T63QgMyfyKs0TbA@mail.gmail.com>
 <CAH1jEzY0WJ1HMgAJYuwWw8b0epi3Ev6mLp7eb230r3mbCcseMg@mail.gmail.com>
 <20151125125656.Horde.Ig6s1CBXkowBNyqca0D4dGJ@avocado.salatschuessel.net>
Message-ID: <CAH1jEzZSDUTrkVLfNp_MBjkoXASb48pvLxR7FgrsYn8_nsjY7A@mail.gmail.com>

Yes I agree with everything you said, except to say that compile times are
very long and I feel that it is worth the initial effort to set up a cross
toolchain that can be compiled and executed under linux. For 2.11bsd this
involved me line-by-line translating "as" from assembly into C, patching a
PDP-11 floating-point emulator library into cc0, cc1 etc (the compiler
passes) to handle any compile-time constants or calculations without
resorting to IEEE format, and using "cproto" and other tools and #ifdef to
modernize the code to run on a modern gcc and glibc. If you have the source
for "scc", "as" and "ld" this would be well worth doing. If you don't then
it would still be worth running part of your toolchain under emulation as a
cross tool (as I did for "f77" which I was not interested in translating).
Nick
On 25/11/2015 10:56 PM, "Oliver Lehmann" <lehmann at ans-netz.de> wrote:

> Hi Nick,
>
> why can't I just "reuse" my SYSIII linker which has all the support for
> segmented and unsegmented binaries what a.out does not support. The Zilog
> format is called s.out.
>
> I thought I could teach the BSD kernel how to execute s.out binaries
> (how to execute them is already there in my SYSIII sources) and I could
> just reuse the ld and sld (for segmented programms) from my SYSIII?
>
> Please check the header for all the magics currently supported.
> https://github.com/OlliL/P8000/blob/master/WEGA/src/head/s.out.h
>
> So why should I use the COFF assembler at all? I plan to do the development
> on my current SYSIII-System where I have all the toolchain available....
>
> I still don't see the need of an cross-compiler-environment while I have
> the real hardware there capable of compiling my code.... I would just go
> and fill up the BSD kernel with functionality, reboot the system, load the
> kernel and do that until it goes up and tries to mount rootfs. When
> this happens, I'll go and teach my boot0-loader UFS and start creating an
> UFS harddisk and put the kernel onto that. Until that point I could even
> test all my stuff on my SYSIII-Filesystem. And I guess it will be LOTS of
> time until I reach the step when the rootfs is being accessed.
>
> Oliver
>
> Nick Downing <downing.nick at gmail.com> wrote:
>
> Oh yeah, the other thing i was going to say was you'd be well advised to
>> use the "ld" that comes with 2.11bsd, which generates a.out (a header of
>> about 16 bytes followed by the raw code and data segments), as well as its
>> somewhat primitive *.o file format (which is an a.out executable followed
>> by relocation and linkage tables, so *.o objects are actually executable
>> if
>> they contain a main() function and no unresolved linkage).
>>
>> What you could do is create a small converter that changes your COFF or
>> whatever objects into the right format. Then everything will just
>> work(tm).
>> The linker itself is a bit hard to modify IIRC, it's a split I/D
>> executable
>> that basically constructs the output executable in its D address space so
>> memory is a bit tight and some tricks are used like doing separate passes
>> for code and data.
>>
>> Having said all that, I think in my case I took a simple Z80 assembler and
>> linker that were open sourced and not too horrible internally, and
>> understood Intel HEX records, and then I simply had the IAR compiler (a
>> commercial product) generate assembly and I didn't use the IAR assembler
>> or
>> linker. Then I modified the linker to create a either an original style
>> (non split I/D) a.out executable or a special extended a.out executable
>> that was similar to split I/D except the instructions were in multiple
>> pages 4kbytes in size and the data was up to 56kbytes in size, so they
>> could share the 64kbyte logical address space (the first 4kbytes was
>> permanently mapped regardless of context switches and contained interrupt
>> and trap handlers).
>>
>> You probably won't need to go to the above extremes, but you could easily
>> modify my linker to create normal a.out executables with/without split I/D
>> if you're wanting to use HEX records as the input rather than 2.11bsd's
>> *.o
>> files. Only thing is it's a cross linker, the code is quite simple but it
>> won't link big executables from a small address space the way 2.11bsd "ld"
>> would do.
>>
>> Nick
>> On 25/11/2015 10:26 PM, downing.nick at gmail.com wrote:
>>
>> According to this:
>>>
>>>
>>> https://archive.org/stream/bitsavers_zilogz80000mmu_742400/z8010_mmu_djvu.txt
>>> You could use only segment 0 and program the code MMU to point segment 0
>>> to some physical address and the data and stack MMUs to point segment 0
>>> to
>>> some other physical address and you have a split I/D system capable of
>>> running 2.11bsd assuming the compiler knows nothing of segments as you
>>> said. Or, as outlined in my previous posts you can use a compiler that
>>> has
>>> 23-bit pointers and understands how to output the high 7 bits as the
>>> segment and the low 16 bits as the logical address each time it
>>> dereferences a pointer (if such a compiler exists) and port 4.3bsd.
>>>
>>> Nick
>>> On 25/11/2015 9:15 PM, "Oliver Lehmann" <lehmann at ans-netz.de> wrote:
>>>
>>>
>>>> Al Kossow <aek at bitsavers.org> wrote:
>>>>
>>>> On 11/23/15 12:40 AM, Erik E. Fair wrote:
>>>>
>>>>>
>>>>> The undergrads who used that system to learn Unix ported many
>>>>>> a BSD
>>>>>> utility to that system (at least the ones that weren't too
>>>>>> RAM-hungry),
>>>>>> starting with BerkNet so we could move files around easily & have
>>>>>> E-mail.
>>>>>>
>>>>>>
>>>>>>
>>>>>> That reminds me that you are going to run into utilities that use the
>>>>> overlaying ld that jumps through hoops to get large programs (vi) to
>>>>> run
>>>>> in a 16 bit address space.
>>>>>
>>>>>
>>>> Good point. I was also thinking if 2.11 is realy the right choice to use
>>>> for porting. From what I understood:
>>>>
>>>> - The PDP11 can only access up to 64KB address space.
>>>> - 2.11 uses overlay to "show" and "hide" memory into this 64K address
>>>>   space.
>>>>
>>>> A Z8001 can address up to 128 segments of 64KB. Means, a single array
>>>> can
>>>> only be up to 64KB, but you can have 8MB of memory per "section". My
>>>> system
>>>> has 3 MMUs while one is dedicated to the code section and one to the
>>>> data
>>>> section. So my Code section can be max up to 8MB and my data section can
>>>> be
>>>> up to additional 8MB. Currently my system has up to 5.5MB of RAM (but
>>>> can
>>>> be upgraded to 16MB easily)
>>>>
>>>> I was thinking if 4.3 BSD would be better to port as the whole overlay
>>>> logic
>>>> which is implemented in 2.11 could make 2.11 maybe to complex to port? I
>>>> mean, all this overlay logic would not be needed for the Z8001 and it
>>>> maybe
>>>> would not even work. (remember - I plan to use my existing SYSIII
>>>> compiler
>>>> which knows nothing about overlaying!)
>>>>
>>>> What I understand for 4.3 BSD is, that it is meant to run on machines
>>>> with
>>>> a memory configuration where the memory is adressable in "one block"
>>>> which
>>>> is of course not true for the Z8001. But - the compiler/assembler
>>>> handles
>>>> all this adressing for C code so why should it be imported on how the is
>>>> addressed internaly?
>>>>
>>>> Additionaly, my system has NO floating point support. The current SYSIII
>>>> uses a lengthy floating point emulation Assembler Source to "work
>>>> around"
>>>> that:
>>>> https://github.com/OlliL/P8000/blob/master/WEGA/src/uts/conf/fpe.s
>>>>
>>>> I saw, that 2.11 also has some FPU-emulation. What about 4.3?
>>>>
>>>> Could 4.3 be a better choice? If so - which 4.3 should I use?
>>>>
>>>> In general - I'm looking for a good target OS. It should be not too
>>>> complex (-> "modern") but should provide a TCP/IP stack which is my
>>>> main motivation in porting at all.
>>>>
>>>>
>>>> I'll dig through my archives and see if there was a Z8000 version of pcc
>>>>
>>>>> in the MIT compiler kit.
>>>>>
>>>>>
>>>> That would be great - maybe you could also answer my private mail about
>>>> the Onyx C8002 I sent you some days ago ;)
>>>> The compilers for Z8000 I found so far where either able to address 64K
>>>> only, or where able to only generate COFF-format objects which I can't
>>>> link on my SYSIII...
>>>>
>>>>
>>>> Oliver
>>>> _______________________________________________
>>>> TUHS mailing list
>>>> TUHS at minnie.tuhs.org
>>>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>>>
>>>>
>>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151125/bba5791c/attachment.html>

From lm at mcvoy.com  Thu Nov 26 01:44:13 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Wed, 25 Nov 2015 07:44:13 -0800
Subject: [TUHS] "Edition 0" manual
In-Reply-To: <201511250508.tAP58HYf032656@coolidge.cs.Dartmouth.EDU>
References: <201511250508.tAP58HYf032656@coolidge.cs.Dartmouth.EDU>
Message-ID: <20151125154413.GZ3979@mcvoy.com>

I was a little tongue in cheek, but it worked, I was trying to tease
out more details about the beginning.

And I personally love troff, had to write a paper in Latex recently
and found it painful.

On Wed, Nov 25, 2015 at 12:08:17AM -0500, Doug McIlroy wrote:
> 
> > It's worth noting that Unix was built for troff.  Typesetting patents
> if I recall correctly.
> 
> This is a stretch. Unix was really built because Ken and Dennis
> had a good idea. The purchase of a PDP-11 for it was in part
> justified by the goal of making a word-processing system. The
> first in-house "sale" of Unix was indeed to the patent department
> for typing patents--the selling point was that roff could be
> made (by an overnight modification) to print line numbers as
> USPTO required, whereas that was not a feature of a commercial
> competitor. The timeline is really roff--Unix--patent--nroff--troff.
> Though roff antedated Unix, it did not motivate Unix.
> 
> > Is this The UNIX Time-Sharing System, or related to it? The same
> > claim appears in the first paragraph:
> > https://www.bell-labs.com/usr/dmr/www/cacm.html
> 
> This draft clearly dates from 1971. Pieces of it were worked
> into subsequent versions of the manual as well as published
> descriptions of Unix, including the SIGOPS/CACM paper.
> 
> Doug
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From lm at mcvoy.com  Sat Nov 28 08:26:52 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 27 Nov 2015 14:26:52 -0800
Subject: [TUHS] tool (that wnj wrote?) that reduced the data segment size?
Message-ID: <20151127222652.GA21698@mcvoy.com>

I've gotten sucked into an embedded system project and they are running out of
memory.  I have a vague memory of some sort of tool that I think Bill Joy
wrote (or maybe he told me about it) that would do some magic processing of
all the string constants and somehow it de-dupped the space.

Though now that I'm typing this that doesn't seem possible.  Does this ring
a bell with anyone?  I'm sure it was for the PDP 11 port.

Thanks,

--lm


From dave at horsfall.org  Sat Nov 28 09:44:58 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Sat, 28 Nov 2015 10:44:58 +1100 (EST)
Subject: [TUHS] tool (that wnj wrote?) that reduced the data segment
 size?
In-Reply-To: <20151127222652.GA21698@mcvoy.com>
References: <20151127222652.GA21698@mcvoy.com>
Message-ID: <alpine.BSF.2.11.1511281038260.60532@aneurin.horsfall.org>

On Fri, 27 Nov 2015, Larry McVoy wrote:

> I've gotten sucked into an embedded system project and they are running 
> out of memory.  I have a vague memory of some sort of tool that I think 
> Bill Joy wrote (or maybe he told me about it) that would do some magic 
> processing of all the string constants and somehow it de-dupped the 
> space.
> 
> Though now that I'm typing this that doesn't seem possible.  Does this 
> ring a bell with anyone?  I'm sure it was for the PDP 11 port.

I think you're referring to an abomination called "xstrings" (or "xstr"?).

It was described by a colleague of mine as "about as subtle as a car 
crash"; it worked by comparing strings at compilation time, even unto the 
tails of said strings.

Woe betide the user if any string was changed at run time...

It ranks right up there with nargs() as What Not To Do.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From lm at mcvoy.com  Sat Nov 28 10:03:56 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Fri, 27 Nov 2015 16:03:56 -0800
Subject: [TUHS] tool (that wnj wrote?) that reduced the data segment
	size?
In-Reply-To: <alpine.BSF.2.11.1511281038260.60532@aneurin.horsfall.org>
References: <20151127222652.GA21698@mcvoy.com>
 <alpine.BSF.2.11.1511281038260.60532@aneurin.horsfall.org>
Message-ID: <20151128000356.GC21698@mcvoy.com>

On Sat, Nov 28, 2015 at 10:44:58AM +1100, Dave Horsfall wrote:
> On Fri, 27 Nov 2015, Larry McVoy wrote:
> 
> > I've gotten sucked into an embedded system project and they are running 
> > out of memory.  I have a vague memory of some sort of tool that I think 
> > Bill Joy wrote (or maybe he told me about it) that would do some magic 
> > processing of all the string constants and somehow it de-dupped the 
> > space.
> > 
> > Though now that I'm typing this that doesn't seem possible.  Does this 
> > ring a bell with anyone?  I'm sure it was for the PDP 11 port.
> 
> I think you're referring to an abomination called "xstrings" (or "xstr"?).

Yup, that's it.  Cool, thanks.

> It was described by a colleague of mine as "about as subtle as a car 
> crash"; it worked by comparing strings at compilation time, even unto the 
> tails of said strings.
> 
> Woe betide the user if any string was changed at run time...

I get it.  I also get that I have 32KB of RAM and I'm down to my last 1.2KB.

--lm


From doug at cs.dartmouth.edu  Sun Nov 29 00:58:45 2015
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Sat, 28 Nov 2015 09:58:45 -0500
Subject: [TUHS] tool (that wnj wrote?) that reduced the data segment
 size?
Message-ID: <201511281458.tASEwj19027759@tahoe.cs.Dartmouth.EDU>

> Woe betide the user if any string was changed at run time...

That was then. Now it would be OK to do so for const data.
(Unless the tool chain has discarded const indications.)

Doug


From wkt at tuhs.org  Sun Nov 29 09:24:13 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 29 Nov 2015 10:24:13 +1100
Subject: [TUHS] Scan of "Edition 0" manual
In-Reply-To: <201511240155.tAO1tap2016965@coolidge.cs.Dartmouth.EDU>
References: <201511240155.tAO1tap2016965@coolidge.cs.Dartmouth.EDU>
Message-ID: <20151128232413.GA24191@www.oztivo.net>

On Mon, Nov 23, 2015 at 08:55:36PM -0500, Doug McIlroy wrote:
> Among the papers of the late Bob Morris I have found a
> Unix manual that I don't remember at all--a draft by
> Dennis Ritchie, in the style of (but not designated as)
> a technical report with numbered sections and subsections.

Doug has kindly made available a scan of this document. I've placed
a copy of it into the Unix Archive at:

http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/

It's certainly an interesting read. It comes across as a mingling
of the CACM paper and the user manuals. I'd love to get a more
definite date than 1971, though.

Many thanks for this, Doug!

Cheers, Warren


From norman at oclsc.org  Sun Nov 29 09:30:53 2015
From: norman at oclsc.org (Norman Wilson)
Date: Sat, 28 Nov 2015 18:30:53 -0500
Subject: [TUHS] tool (that wnj wrote?) that reduced the data
	segment	size?
Message-ID: <1448753456.23036.for-standards-violators@oclsc.org>

I'm too tired to dig for the exact words in the ISO standard,
but I had the impression that the official C rule these days
is that the effect of writing on a string literal is undefined.

So it's legal for an implementation to make strings read-only,
or to point several references to "What's the recipe today, Jim"
to one copy of the stripng in memory, and even to point uses of
"Jim" to the tail of the same string.  Or both.

It is also legal for every string literal to reside in its own
memory and to be writable, but since the effect is undefined,
code that relies on that is on thin ice, especially if meant to
be portable code.

I have used, and even fixed (unrelated) bugs in, a compiler
that merged identical strings.  I forget whether it also looked
for suffix matches.  Whether the strings went in read-only
memory was up to the code generator (of course); in the new
back-end I wrote for it, I made them so.  This turned up quite a
few fumbles in very-old UNIX code that assumed unique, writable
string literals, especially those that called mktemp(3).  To my
mind that just meant the programs needed to be fixed to match
current standards (just as many old programs needed fixes to
compile without error in ISO C), so I fixed them.

I didn't (and still don't) like Joy's heavy-handed hack, but I
see his point, and think it's just fine for the language rules
to allow the compiler to do it hacklessly.

Norman Wilson
Toronto ON


From charles.unix.pro at gmail.com  Sun Nov 29 09:38:06 2015
From: charles.unix.pro at gmail.com (Charles Anthony)
Date: Sat, 28 Nov 2015 15:38:06 -0800
Subject: [TUHS] tool (that wnj wrote?) that reduced the data segment
	size?
In-Reply-To: <1448753456.23036.for-standards-violators@oclsc.org>
References: <1448753456.23036.for-standards-violators@oclsc.org>
Message-ID: <CANV78LS-wQEswOg7GMFcv4vwqtEJj=-z38isNtzJDW1ukhKd=w@mail.gmail.com>

On Sat, Nov 28, 2015 at 3:30 PM, Norman Wilson <norman at oclsc.org> wrote:

>
> I didn't (and still don't) like Joy's heavy-handed hack, but I
> see his point, and think it's just fine for the language rules
> to allow the compiler to do it hacklessly.
>
>
IIRC, in "The Design of an Optimizing Compiler", it says something like:

"The Optimizing Compiler Writer's Motto: It is no sin to make a wrong
program worse."

-- Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151128/ad9a22a4/attachment.html>

From wkt at tuhs.org  Sun Nov 29 12:01:44 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 29 Nov 2015 13:01:44 +1100
Subject: [TUHS] Scan of "Edition 0" manual
In-Reply-To: <20151128232413.GA24191@www.oztivo.net>
References: <201511240155.tAO1tap2016965@coolidge.cs.Dartmouth.EDU>
 <20151128232413.GA24191@www.oztivo.net>
Message-ID: <20151129020144.GA8036@www.oztivo.net>

On Sun, Nov 29, 2015 at 10:24:13AM +1100, Warren Toomey wrote:
> It's certainly an interesting read. It comes across as a mingling
> of the CACM paper and the user manuals. I'd love to get a more
> definite date than 1971, though.

Edit: mid-1971.

Cheers, Warren


From clemc at ccc.com  Mon Nov 30 00:31:53 2015
From: clemc at ccc.com (Clem cole)
Date: Sun, 29 Nov 2015 09:31:53 -0500
Subject: [TUHS] Scan of "Edition 0" manual
In-Reply-To: <20151129020144.GA8036@www.oztivo.net>
References: <201511240155.tAO1tap2016965@coolidge.cs.Dartmouth.EDU>
 <20151128232413.GA24191@www.oztivo.net>
 <20151129020144.GA8036@www.oztivo.net>
Message-ID: <9AD9EB44-83F0-4C2B-AA71-D473C635AF52@ccc.com>

Thank you both. 

Sent from my iPhone

> On Nov 28, 2015, at 9:01 PM, Warren Toomey <wkt at tuhs.org> wrote:
> 
>> On Sun, Nov 29, 2015 at 10:24:13AM +1100, Warren Toomey wrote:
>> It's certainly an interesting read. It comes across as a mingling
>> of the CACM paper and the user manuals. I'd love to get a more
>> definite date than 1971, though.
> 
> Edit: mid-1971.
> 
> Cheers, Warren
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs


From beebe at math.utah.edu  Mon Nov 30 03:51:19 2015
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Sun, 29 Nov 2015 10:51:19 -0700
Subject: [TUHS] Scan of "Edition 0" manual
Message-ID: <CMM.0.95.0.1448819479.beebe@gamma.math.utah.edu>

Thanks, Doug and Warren, for the new files at

	http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/

At the TUHS mirror at my site, you can find an additional file 

	http://www.math.utah.edu/pub/mirrors/minnie.tuhs.org/PDP-11/Distributions/research/McIlroy_v0/UnixEditionZero-OCR.pdf
	ftp://ftp.math.utah.edu/pub/mirrors/minnie.tuhs.org/PDP-11/Distributions/research/McIlroy_v0/UnixEditionZero-OCR.pdf

that is less than half the size, and is (somewhat) searchable, thanks
to Adobe Acrobat Pro 11 OCR conversion.  Please include that in the
TUHS master archive, even renaming it to the original file, if you
wish.

I like the beginning of "Section 2. Hardware", where Dennis wrote:

>> ...
>> The PDP-11 on which UNIX is implemented is a 16-bit 12K computer,
>> and UNIX occupies 8K words. More than half of this space, however, is
>> utilized for a variable number of disk buffers; with some loss of
>> speed the number of buffers could be cut significantly.
>> ...

How much more powerful early Unix was compared to CP/M and MS-DOS, in
a small fraction of their memory space!

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------


From wkt at tuhs.org  Mon Nov 30 06:00:05 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 30 Nov 2015 07:00:05 +1100
Subject: [TUHS] Scan of "Edition 0" manual
In-Reply-To: <CMM.0.95.0.1448819479.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1448819479.beebe@gamma.math.utah.edu>
Message-ID: <20151129200005.GA9851@www.oztivo.net>

On Sun, Nov 29, 2015 at 10:51:19AM -0700, Nelson H. F. Beebe wrote:
> Thanks, Doug and Warren, for the new files at
> 
> 	http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/
> 
> At the TUHS mirror at my site, you can find an additional file 
> 
> 	http://www.math.utah.edu/pub/mirrors/minnie.tuhs.org/PDP-11/Distributions/research/McIlroy_v0/UnixEditionZero-OCR.pdf
> 	ftp://ftp.math.utah.edu/pub/mirrors/minnie.tuhs.org/PDP-11/Distributions/research/McIlroy_v0/UnixEditionZero-OCR.pdf
> 
> that is less than half the size, and is (somewhat) searchable, thanks
> to Adobe Acrobat Pro 11 OCR conversion.  Please include that in the
> TUHS master archive, even renaming it to the original file, if you
> wish.

Thanks Nelson. I've placed your OCR'd file in the same location as
Doug's original file.

Cheers, Warren


From chneukirchen at gmail.com  Mon Nov 30 06:21:05 2015
From: chneukirchen at gmail.com (Christian Neukirchen)
Date: Sun, 29 Nov 2015 21:21:05 +0100
Subject: [TUHS] Scan of "Edition 0" manual
In-Reply-To: <20151128232413.GA24191@www.oztivo.net> (Warren Toomey's message
 of "Sun, 29 Nov 2015 10:24:13 +1100")
References: <201511240155.tAO1tap2016965@coolidge.cs.Dartmouth.EDU>
 <20151128232413.GA24191@www.oztivo.net>
Message-ID: <87610kftfy.fsf@gmail.com>

Warren Toomey <wkt at tuhs.org> writes:

> On Mon, Nov 23, 2015 at 08:55:36PM -0500, Doug McIlroy wrote:
>> Among the papers of the late Bob Morris I have found a
>> Unix manual that I don't remember at all--a draft by
>> Dennis Ritchie, in the style of (but not designated as)
>> a technical report with numbered sections and subsections.
>
> Doug has kindly made available a scan of this document. I've placed
> a copy of it into the Unix Archive at:
>
> http://www.tuhs.org/Archive/PDP-11/Distributions/research/McIlroy_v0/
>
> It's certainly an interesting read.

Anyone else notice that create(2) is spelled with an "e" (Sec. 3.5.2)?
But not in the appendix A1.6...

-- 
Christian Neukirchen  <chneukirchen at gmail.com>  http://chneukirchen.org


From beebe at math.utah.edu  Mon Nov 30 06:40:59 2015
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Sun, 29 Nov 2015 13:40:59 -0700
Subject: [TUHS] Scan of "Edition 0" manual
In-Reply-To: <87610kftfy.fsf@gmail.com>
Message-ID: <CMM.0.95.0.1448829659.beebe@gamma.math.utah.edu>

>> Anyone else notice that create(2) is spelled with an "e" (Sec. 3.5.2)?
>> But not in the appendix A1.6...

I did when I read UnixEditionZero.pdf this morning.  I seem to recall
Dennis or Ken being quoted as having said that the one thing they'd
do over in Unix was to spell "creat" with a final "e".

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------


From arnold at skeeve.com  Mon Nov 30 07:45:32 2015
From: arnold at skeeve.com (arnold at skeeve.com)
Date: Sun, 29 Nov 2015 14:45:32 -0700
Subject: [TUHS] Scan of "Edition 0" manual
In-Reply-To: <CMM.0.95.0.1448829659.beebe@gamma.math.utah.edu>
References: <CMM.0.95.0.1448829659.beebe@gamma.math.utah.edu>
Message-ID: <201511292145.tATLjWPQ000926@freefriends.org>

> >> Anyone else notice that create(2) is spelled with an "e" (Sec. 3.5.2)?
> >> But not in the appendix A1.6...

"Nelson H. F. Beebe" <beebe at math.utah.edu> wrote:

> I did when I read UnixEditionZero.pdf this morning.  I seem to recall
> Dennis or Ken being quoted as having said that the one thing they'd
> do over in Unix was to spell "creat" with a final "e".

It was Ken. And indeed he did so, for Plan 9.

Arnold


From will.senn at gmail.com  Mon Nov 30 08:20:01 2015
From: will.senn at gmail.com (Will Senn)
Date: Sun, 29 Nov 2015 16:20:01 -0600
Subject: [TUHS] Portable Pascal and a 1BSD question
Message-ID: <A731853E-E882-430B-B38C-7F092E135C81@gmail.com>

Hi all,

In v2 no5 AUUGN Jun-Jul 1980, Andy Tanenbaum announced the availability of a Portable Pascal Compiler for the then proposed ISO standard. A tape was made for v6, v7, and non-unix platforms. Does anyone know if there is a tape image around that has the distro?

On a related note, has anyone successfully installed 1BSD on a v6 install running in SImH? 1BSD has the Berkeley Pascal Instructional system on it.

Regards,

Will

Sent from my iPhone

From fair-tuhs at netbsd.org  Mon Nov 30 12:45:29 2015
From: fair-tuhs at netbsd.org (Erik E. Fair)
Date: Sun, 29 Nov 2015 18:45:29 -0800
Subject: [TUHS] tool (that wnj wrote?) that reduced the data segment
	size?
In-Reply-To: <20151128000356.GC21698@mcvoy.com>
References: <alpine.BSF.2.11.1511281038260.60532@aneurin.horsfall.org>
Message-ID: <21101.1448851529@cesium.clock.org>

The xstr(1) program is still maintained in the NetBSD distribution.
It's not a part of the C compiler - it's much more akin to a C
pre-processor:

	http://man.netbsd.org/7.0/usr/share/man/html1/xstr.html

See also mkstr(1):

	http://man.netbsd.org/7.0/usr/share/man/html1/mkstr.html

As ham-handed as these tools are, they can be used for input to
manual programmer string storage reduction.

	Erik <fair at netbsd.org>


From cowan at mercury.ccil.org  Mon Nov 30 13:07:02 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Sun, 29 Nov 2015 22:07:02 -0500
Subject: [TUHS] tool (that wnj wrote?) that reduced the data segment
 size?
In-Reply-To: <CANV78LS-wQEswOg7GMFcv4vwqtEJj=-z38isNtzJDW1ukhKd=w@mail.gmail.com>
References: <1448753456.23036.for-standards-violators@oclsc.org>
 <CANV78LS-wQEswOg7GMFcv4vwqtEJj=-z38isNtzJDW1ukhKd=w@mail.gmail.com>
Message-ID: <20151130030702.GF32175@mercury.ccil.org>

Charles Anthony scripsit:

> "The Optimizing Compiler Writer's Motto: It is no sin to make a wrong
> program worse."

It is if the rules for which programs are wrong are essentially beyond
human comprehension on the fly.  Anyway: "That program has about a
thousand bugs.  Which would you rather, that we fixed all the bugs or
that we made it run a thousand times faster?"

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Heckler: "Go on, Al, tell 'em all you know.  It won't take long."
Al Smith: "I'll tell 'em all we *both* know.  It won't take any longer."


From lm at mcvoy.com  Mon Nov 30 13:28:50 2015
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 29 Nov 2015 19:28:50 -0800
Subject: [TUHS] Does anyone know what wnj is doing?
Message-ID: <20151130032850.GB5084@mcvoy.com>

Last I heard, and this is ~25 years ago, he was in Aspen just hanging out.
Is he OK?

--lm


From cowan at mercury.ccil.org  Mon Nov 30 14:02:44 2015
From: cowan at mercury.ccil.org (John Cowan)
Date: Sun, 29 Nov 2015 23:02:44 -0500
Subject: [TUHS] Scan of "Edition 0" manual
In-Reply-To: <20151128232413.GA24191@www.oztivo.net>
References: <201511240155.tAO1tap2016965@coolidge.cs.Dartmouth.EDU>
 <20151128232413.GA24191@www.oztivo.net>
Message-ID: <20151130040244.GI32175@mercury.ccil.org>

Warren Toomey scripsit:

> It's certainly an interesting read. 

Some things that strike me particularly:

- the presence of only one execute bit (a file is either executable or
it isn't!)

- the "@" prompt of the shell

- the blocked paper tape driver

- the fact that ^\ causes an arbitrary non-shell process to core dump
if several are running and DEL (aka ^C) does not exist yet

- the fact that switches don't yet exist (and indeed when passing files
to the B interpreter one must precede them with a hyphen)

I also note the marginal "NO!" next to the statement that the second
argument to 'creat' is the file mode.  I wonder what that was about.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
"Make a case, man; you're full of naked assertions, just like Nietzsche."
"Oh, i suffer from that, too.  But you know, naked assertions or GTFO."
                        --heard on #scheme, sorta


From dave at horsfall.org  Mon Nov 30 14:26:35 2015
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 30 Nov 2015 15:26:35 +1100 (EST)
Subject: [TUHS] Scan of "Edition 0" manual
In-Reply-To: <20151130040244.GI32175@mercury.ccil.org>
References: <201511240155.tAO1tap2016965@coolidge.cs.Dartmouth.EDU>
 <20151128232413.GA24191@www.oztivo.net>
 <20151130040244.GI32175@mercury.ccil.org>
Message-ID: <alpine.BSF.2.11.1511301524530.60532@aneurin.horsfall.org>

On Sun, 29 Nov 2015, John Cowan wrote:

> I also note the marginal "NO!" next to the statement that the second 
> argument to 'creat' is the file mode.  I wonder what that was about.

I liked the way that fork(label) worked, although the assembler doc says 
it's a white lie...

And I think page A7 is missing.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From downing.nick at gmail.com  Mon Nov 30 15:38:24 2015
From: downing.nick at gmail.com (Nick Downing)
Date: Mon, 30 Nov 2015 16:38:24 +1100
Subject: [TUHS] tool (that wnj wrote?) that reduced the data segment
	size?
In-Reply-To: <20151130030702.GF32175@mercury.ccil.org>
References: <1448753456.23036.for-standards-violators@oclsc.org>
 <CANV78LS-wQEswOg7GMFcv4vwqtEJj=-z38isNtzJDW1ukhKd=w@mail.gmail.com>
 <20151130030702.GF32175@mercury.ccil.org>
Message-ID: <CAH1jEzZ1DiiOuRZhSUk-Y75n5sqfxS9pCAgbwmR4C1eQXiy4ZA@mail.gmail.com>

Guys I wrote a more modern version of xstr for a project (porting PDP11
utilities and games to a modern compiler for a different embedded system).
How it worked was similar to i18n utilities on a modern system. (I planned
to internationalize later). So what it did was remove any strings bracketed
with _("blah blah") to a strings file and then replace with a 32-bit
integer offset into the file. I had utilities like _printf(long off, ...)
which would access the strings file to get the necessary string and print
it, or just _strdup() which would bring it into memory where the programmer
could use as normal and free when done. What I did next was to have the
linker treat the strings file as a resource and merge it into the
executable, so that with a little trickery the strings could be directly
accessed from flash ROM while not taking any of the precious 64 kbytes RAM
in the program's data space. Happy to dig this up and share.
Nick
On 30/11/2015 2:26 PM, "John Cowan" <cowan at mercury.ccil.org> wrote:

> Charles Anthony scripsit:
>
> > "The Optimizing Compiler Writer's Motto: It is no sin to make a wrong
> > program worse."
>
> It is if the rules for which programs are wrong are essentially beyond
> human comprehension on the fly.  Anyway: "That program has about a
> thousand bugs.  Which would you rather, that we fixed all the bugs or
> that we made it run a thousand times faster?"
>
> --
> John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
> Heckler: "Go on, Al, tell 'em all you know.  It won't take long."
> Al Smith: "I'll tell 'em all we *both* know.  It won't take any longer."
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151130/db77d327/attachment.html>

From wkt at tuhs.org  Mon Nov 30 19:06:37 2015
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 30 Nov 2015 20:06:37 +1100
Subject: [TUHS] Scan of "Edition 0" manual
In-Reply-To: <353E052F-541F-47C1-9ACF-587EB9EC6088@mcjones.org>
References: <mailman.3.1448845201.3730.tuhs@minnie.tuhs.org>
 <353E052F-541F-47C1-9ACF-587EB9EC6088@mcjones.org>
Message-ID: <20151130090637.GA16550@www.oztivo.net>

On Sun, Nov 29, 2015 at 08:55:23PM -0800, Paul McJones wrote:
> Thanks very much for making the original and the OCR-enhanced versions
> of Doug’s scan of the “UnixEditionZero” document available
> on tuhs.org. I notice that even with Nelson’s enhanced version,
> the file size is still large for a scanned text document, apparently
> because it was originally scanned in RGB mode, 24 bits/pixel. The
> attached version is 2.5MB, and to my eye is identical looks identical
> to UnixEditionZero-OCR.pdf.

Paul, I've added your version into the same directory. Thanks!

	Warren


