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 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: 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 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: 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: References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net> <20151107192043.GA11895@mcvoy.com> Message-ID: <5C15A998-5D10-47C7-888E-EADF42C1BFBE@gewt.net> Sent from my iPhone > On Nov 7, 2015, at 13:28, Clem Cole 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 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: 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: References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net> <20151107192043.GA11895@mcvoy.com> Message-ID: <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net> Clem Cole 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> <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> <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net> <20151108051028.GA32246@cowbell.employees.org> Message-ID: 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" 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: 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 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: 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: References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net> <20151107192043.GA11895@mcvoy.com> <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net> <20151108051028.GA32246@cowbell.employees.org> Message-ID: <20151108104016.Horde.RqrbT03f_72g8VsxukB9eQv@avocado.salatschuessel.net> Yeah, Nick Downing 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: References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net> <20151107192043.GA11895@mcvoy.com> <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net> <20151108051028.GA32246@cowbell.employees.org> Message-ID: <20151108143817.Horde.tlWgdF0OWmzmg-kXXO-AxUO@avocado.salatschuessel.net> Nick Downing 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: 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 > 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: References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net> <20151107192043.GA11895@mcvoy.com> <1C0DB3B7-988D-435F-A590-6C0AB14249A3@gewt.net> <20151108071102.GA7290@mcvoy.com> Message-ID: 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> <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net> <20151108051028.GA32246@cowbell.employees.org> <20151108143817.Horde.tlWgdF0OWmzmg-kXXO-AxUO@avocado.salatschuessel.net> Message-ID: 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 wrote: > > Nick Downing 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> <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net> <20151108051028.GA32246@cowbell.employees.org> <20151108143817.Horde.tlWgdF0OWmzmg-kXXO-AxUO@avocado.salatschuessel.net> Message-ID: 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 wrote: > > Nick Downing 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 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: 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 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 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 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 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 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: References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU> <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com> <52F63A89-B372-409E-9296-BAA4CBF848AF@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 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 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 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 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> <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 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 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 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 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 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> Message-ID: Win Treese 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: References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net> <20151107192043.GA11895@mcvoy.com> <1C0DB3B7-988D-435F-A590-6C0AB14249A3@gewt.net> <20151108071102.GA7290@mcvoy.com> 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: References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU> <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com> <52F63A89-B372-409E-9296-BAA4CBF848AF@acm.org> 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 wrote: > > Win Treese 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 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 wrote: > > On Sun, 8 Nov 2015 21:38:19 -0800 > Cory Smelosky 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: References: <20151107200358.Horde.M1lYZZyTC4t0Qb8KrygKzhy@avocado.salatschuessel.net> <20151107192043.GA11895@mcvoy.com> <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net> <20151108051028.GA32246@cowbell.employees.org> <20151108143817.Horde.tlWgdF0OWmzmg-kXXO-AxUO@avocado.salatschuessel.net> Message-ID: <20151109091551.Horde.vyfPFb7gspsxIQB3WGNcE_A@avocado.salatschuessel.net> Nick Downing 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> <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net> <20151108051028.GA32246@cowbell.employees.org> <20151108143817.Horde.tlWgdF0OWmzmg-kXXO-AxUO@avocado.salatschuessel.net> <20151109091551.Horde.vyfPFb7gspsxIQB3WGNcE_A@avocado.salatschuessel.net> Message-ID: <20151109091646.Horde.WJOBgOU20u5J3ItIHNJDwO9@avocado.salatschuessel.net> I hit the send button to fast :( Oliver Lehmann wrote: > Nick Downing 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: 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 wrote: > They end up with hp300 stuff?! Huh. > > Sent from my iPhone > >> On Nov 8, 2015, at 22:40, Lyle Bickley wrote: >> >> On Sun, 8 Nov 2015 21:38:19 -0800 >> Cory Smelosky 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> <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net> <20151108051028.GA32246@cowbell.employees.org> <20151108143817.Horde.tlWgdF0OWmzmg-kXXO-AxUO@avocado.salatschuessel.net> <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 wrote: > I hit the send button to fast :( > > Oliver Lehmann wrote: > >> Nick Downing 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> <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net> <20151108051028.GA32246@cowbell.employees.org> <20151108143817.Horde.tlWgdF0OWmzmg-kXXO-AxUO@avocado.salatschuessel.net> <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 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 wrote: > >> I hit the send button to fast :( >> >> Oliver Lehmann wrote: >> >>> Nick Downing 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 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: 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: References: <3AEEECE6-5A5F-469E-BB81-F526D2194F53@gewt.net> <20151108224025.6e49cbc1@asrock.bcwi.net> <4DCC6F06-A048-40D4-B821-009796E9F17D@gewt.net> 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 wrote: > > They end up with hp300 stuff?! Huh. > > > > Sent from my iPhone > > > >> On Nov 8, 2015, at 22:40, Lyle Bickley wrote: > >> > >> On Sun, 8 Nov 2015 21:38:19 -0800 > >> Cory Smelosky 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> <65204902-BAB1-4624-8D14-A65BEC60A574@ccc.com> Message-ID: 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: References: <201511090139.tA91dCvK006536@coolidge.cs.Dartmouth.EDU> <627C631F-2B0E-45FC-97DB-7A8FE4DBB3B8@ccc.com> <52F63A89-B372-409E-9296-BAA4CBF848AF@acm.org> <65204902-BAB1-4624-8D14-A65BEC60A574@ccc.com> Message-ID: Sorry - typo/brain f*rt -- Ken Arnold On Mon, Nov 9, 2015 at 10:40 AM, Dave Horsfall 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: 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> <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 : > 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> <20151107231338.Horde.d8EIgIMMf9VYCExfovc2K_M@avocado.salatschuessel.net> <20151108051028.GA32246@cowbell.employees.org> <20151108143817.Horde.tlWgdF0OWmzmg-kXXO-AxUO@avocado.salatschuessel.net> <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: 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" 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 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 wrote: >> >> I hit the send button to fast :( >>> >>> Oliver Lehmann wrote: >>> >>> Nick Downing 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: 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: 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: 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: 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: References: 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: <20151109230509.GC24474@mcvoy.com> Message-ID: 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 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: 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: References: <20151109230509.GC24474@mcvoy.com> Message-ID: 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 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 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: 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: References: <20151109230509.GC24474@mcvoy.com> Message-ID: 💩 On Nov 9, 2015 6:09 PM, "Clem Cole" 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 > 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 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: 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> Message-ID: <87r3jyfq81.fsf@fastmail.com> "Jeremy C. Reed" 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 > > 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: On Tue, Nov 10, 2015 at 3:26 PM, markus schnalke wrote: > http://marmaro.de/docs/freiesmagazin/cut/cut.en.pdf ​Fascinating ​- thanks for sharing. Clem -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: On Tue, Nov 10, 2015 at 9:26 PM, markus schnalke wrote: > [2015-11-09 08:58] Doug McIlroy >> >> 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: 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: <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> <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> <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 writes: > [2015-11-09 08:58] Doug McIlroy >> 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 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 > > 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: 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: References: 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: 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 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: 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: >> > > 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: 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 wrote: >> On Nov 13, 2015, at 1:48 PM, Oliver Lehmann 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 > On Nov 13, 2015, at 2:12 PM, Oliver Lehmann wrote: > > > Ronald Natalie wrote: > >>> On Nov 13, 2015, at 1:48 PM, Oliver Lehmann 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2284 bytes Desc: not available URL: 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 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 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 <>offset, so in my case <<62>>%F600 - but of course it does not work and the assembler yields and error :( Oliver Lehmann wrote: > Oliver Lehmann 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: 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: References: <20151113203320.Horde.VokfqdGcy16czyeqhojbDVa@avocado.salatschuessel.net> Message-ID: iPhone email > On Nov 13, 2015, at 2:38 PM, Brantley Coile 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 wrote: >> >> >> Oliver Lehmann 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 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: Oliver Lehmann 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: 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: 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: 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: References: Message-ID: 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: 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: Oliver Lehmann 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: References: <20151114133415.Horde.waGYhqdGBssNHzZf3_TcC5x@avocado.salatschuessel.net> <20151114135635.Horde.6nqJB5AyLmQsx2fCZX4iZtZ@avocado.salatschuessel.net> <20151114161757.Horde.RL0PZVub39UDZ9-Qr0wtXdW@avocado.salatschuessel.net> Message-ID: <20151114224205.Horde.pNedl1JFkdNwTKQKHr6OiXv@avocado.salatschuessel.net> Random832 wrote: > Oliver Lehmann 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> <20151114224205.Horde.pNedl1JFkdNwTKQKHr6OiXv@avocado.salatschuessel.net> Message-ID: Oliver Lehmann 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: References: <20151114133415.Horde.waGYhqdGBssNHzZf3_TcC5x@avocado.salatschuessel.net> <20151114135635.Horde.6nqJB5AyLmQsx2fCZX4iZtZ@avocado.salatschuessel.net> <20151114161757.Horde.RL0PZVub39UDZ9-Qr0wtXdW@avocado.salatschuessel.net> <20151114224205.Horde.pNedl1JFkdNwTKQKHr6OiXv@avocado.salatschuessel.net> Message-ID: <20151115154349.Horde.6dHXDRnHFazVunVIgPsob3u@avocado.salatschuessel.net> Random832 wrote: > Oliver Lehmann 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: Random832 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 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 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: "Erik E. Fair" 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 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 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: 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: 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 The latest xv6 source is available via git clone git://pdos.csail.mit.edu/xv6/xv6.git Tools are can be found at: 6.828 / Fall 2014 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 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: 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: 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 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 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: References: <20151121140022.Horde.ZwPZMYWApn-dXiuNCkiDWDA@avocado.salatschuessel.net> <1448151215.3670388.446383649.14D3C39D@webmail.messagingengine.com> Message-ID: 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 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 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: 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: 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: 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 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: 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: 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" wrote: > Oliver Lehmann wrote: > >> >> William Pechter 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: 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: 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: <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: 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 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: 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 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: <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 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 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 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: <26595.1448268040@cesium.clock.org> <5654FC2E.9010207@bitsavers.org> Message-ID: <20151125111451.Horde.YYentpTkevlAUuLEIvnGxYQ@avocado.salatschuessel.net> Al Kossow 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: <26595.1448268040@cesium.clock.org> <5654FC2E.9010207@bitsavers.org> <20151125111451.Horde.YYentpTkevlAUuLEIvnGxYQ@avocado.salatschuessel.net> Message-ID: 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" wrote: > > Al Kossow 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: 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: References: <26595.1448268040@cesium.clock.org> <5654FC2E.9010207@bitsavers.org> <20151125111451.Horde.YYentpTkevlAUuLEIvnGxYQ@avocado.salatschuessel.net> Message-ID: 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" wrote: > >> >> Al Kossow 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: 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: References: <26595.1448268040@cesium.clock.org> <5654FC2E.9010207@bitsavers.org> <20151125111451.Horde.YYentpTkevlAUuLEIvnGxYQ@avocado.salatschuessel.net> Message-ID: <20151125125128.Horde.oGU9jlpPxZu6Cp9of9ENj6W@avocado.salatschuessel.net> Hi Nick, Nick Downing 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: References: <26595.1448268040@cesium.clock.org> <5654FC2E.9010207@bitsavers.org> <20151125111451.Horde.YYentpTkevlAUuLEIvnGxYQ@avocado.salatschuessel.net> 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 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" wrote: >> >>> >>> Al Kossow 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: <26595.1448268040@cesium.clock.org> <5654FC2E.9010207@bitsavers.org> <20151125111451.Horde.YYentpTkevlAUuLEIvnGxYQ@avocado.salatschuessel.net> <20151125125128.Horde.oGU9jlpPxZu6Cp9of9ENj6W@avocado.salatschuessel.net> Message-ID: 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" wrote: > Hi Nick, > > > Nick Downing 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: 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: <26595.1448268040@cesium.clock.org> <5654FC2E.9010207@bitsavers.org> <20151125111451.Horde.YYentpTkevlAUuLEIvnGxYQ@avocado.salatschuessel.net> <20151125125656.Horde.Ig6s1CBXkowBNyqca0D4dGJ@avocado.salatschuessel.net> Message-ID: 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" 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 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" wrote: >>> >>> >>>> Al Kossow 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: 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: 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: References: <20151127222652.GA21698@mcvoy.com> 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: On Sat, Nov 28, 2015 at 3:30 PM, Norman Wilson 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: 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 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: 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: References: 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 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 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: >> 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: References: 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" 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: 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: 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 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: References: <1448753456.23036.for-standards-violators@oclsc.org> 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: 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> <20151130030702.GF32175@mercury.ccil.org> Message-ID: 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" 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: 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: <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