* [TUHS] System III - TCP/IP
@ 2015-11-08 15:52 Noel Chiappa
0 siblings, 0 replies; 26+ messages in thread
From: Noel Chiappa @ 2015-11-08 15:52 UTC (permalink / raw)
> From: Dave Horsfall <dave at horsfall.org>
> I thought PWB (makers of "make") came from Harvard?
PWB? As in "Programmer's Work Bench"? The OS part of that came straight out
of Bell - see pg. 266 in the first Unix BSTJ issue. Not sure about all the
applications (well, SCCS came from Bell).
Noel
^ permalink raw reply [flat|nested] 26+ messages in thread* [TUHS] System III - TCP/IP @ 2015-11-07 19:03 Oliver Lehmann 2015-11-07 19:20 ` Larry McVoy 2015-11-11 1:54 ` Cornelius Keck 0 siblings, 2 replies; 26+ messages in thread From: Oliver Lehmann @ 2015-11-07 19:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-07 19:03 Oliver Lehmann @ 2015-11-07 19:20 ` Larry McVoy 2015-11-07 20:27 ` Cory Smelosky 2015-11-07 21:28 ` Clem Cole 2015-11-11 1:54 ` Cornelius Keck 1 sibling, 2 replies; 26+ messages in thread From: Larry McVoy @ 2015-11-07 19:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-07 19:20 ` Larry McVoy @ 2015-11-07 20:27 ` Cory Smelosky 2015-11-08 7:11 ` Larry McVoy 2015-11-07 21:28 ` Clem Cole 1 sibling, 1 reply; 26+ messages in thread From: Cory Smelosky @ 2015-11-07 20:27 UTC (permalink / raw) Any ideas if any of this would work on Sys III for VAX? (Or the technically opened PDP-11 that includes VAX) Sent from my iPhone > On Nov 7, 2015, at 11:20, Larry McVoy <lm at mcvoy.com> wrote: > > So this seems pretty tough, 16 bit machine and all. If you were to get > it to work it would probably be with Lachman's STREAMS based TCP/IP. > No idea if that was open sourced. > >> On Sat, Nov 07, 2015 at 08:03:58PM +0100, Oliver Lehmann wrote: >> Hi, >> >> i have an old Z8001 based SysIII variant and I would love to have >> TCP/IP on it (SLIP first, later with a homebrew ethernet device). >> >> I wonder if someone ever saw TCP/IP available on a System III? >> >> I have lets say 90% of the kernel running on it as source >> available and I started digging in the available 4.2 BSD sources. >> >> It looks like there would be much to do to hack in TCP/IP on my >> own (no IPC, no Net, no PTY, no....). >> >> I got K5JB running (userland TCP/IP implementation) after I fixed >> some C code because the C Compiler available on the system is..... >> kinda limited. >> >> telnetd is of course not working as there are no pseudo-teletypes >> on this SYSIII. At least I got ping, echoping and ftpd up and >> running via SLIP >> >> (10.1.1.2 is my SysIII box:) >> >> # ping -c3 10.1.1.2 >> PING 10.1.1.2 (10.1.1.2): 56 data bytes >> 64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms >> 64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms >> 64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms >> >> --- 10.1.1.2 ping statistics --- >> 3 packets transmitted, 3 packets received, 0.0% packet loss >> round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms >> # ftp 10.1.1.2 >> Connected to 10.1.1.2. >> 220 FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991 >> Name (10.1.1.2:root): test >> 331 Enter PASS command >> Password: >> 230 Logged in >> ftp> get sa.timer >> local: sa.timer remote: sa.timer >> 500 Unknown command >> 500 Unknown command >> 200 Port command okay >> 150 Opening data connection for RETR sa.timer >> 2571 0.53 KB/s >> 226 File sent OK >> 2571 bytes received in 00:05 (0.48 KB/s) >> ftp> get wega >> local: wega remote: wega >> 200 Port command okay >> 150 Opening data connection for RETR wega >> 98723 0.51 KB/s >> 226 File sent OK >> 98723 bytes received in 03:05 (0.51 KB/s) >> ftp> exit >> 221 Goodbye! >> # >> >> So I wonder if someone got anything SYSIII -> Net/TCP/IP related >> which could help me in any way to get a SYSIII kernel capable of >> TCP/IP and PTYs to get a telnetd up and running via SLIP is my >> first goal. >> >> Regards, >> Oliver >> _______________________________________________ >> TUHS mailing list >> TUHS at minnie.tuhs.org >> https://minnie.tuhs.org/mailman/listinfo/tuhs > > -- > --- > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-07 20:27 ` Cory Smelosky @ 2015-11-08 7:11 ` Larry McVoy 2015-11-08 7:22 ` John Cowan 2015-11-08 14:45 ` Dave Horsfall 0 siblings, 2 replies; 26+ messages in thread From: Larry McVoy @ 2015-11-08 7:11 UTC (permalink / raw) Just getting back to email (spent the day taking pictures at a hockey tournament). Others have replied, no STREAMS System III (that's what Sys 5 did, Dennis did "streams", they are not the same, Dennis' stuff was sane, STREAMS was not, he and I talked a bit about that - which was classic Dennis because I was nobody, fresh out of grad school porting a STREAMS based TCP/IP stack and I felt it was weird so I reached out to dmr and he of course replied in depth.) I tend to agree with whoever said 2.11BSD. If you have to do 16 bit and you want all the goodies, 2.11BSD is where you want to be. Back porting all that stuff to System III really makes me ask the question of "why?". Why bother? I get that it could be like a mountain you want to climb, if that's the case, cool. But I never saw System III as much of a cool mountain. I think there were some cool parts, didn't the PWB and DWB come form System III? If so, those where the things I'd want to have ported forward. Other than that, what's the System III attraction? If you actually have a need to have this work and have networking then once again Clem has the right idea, grab one of those boards. (And once again I want to meet Clem in person, lot of love for the Masscomp work and all his stories). --lm On Sat, Nov 07, 2015 at 12:27:27PM -0800, Cory Smelosky wrote: > Any ideas if any of this would work on Sys III for VAX? > > (Or the technically opened PDP-11 that includes VAX) > > Sent from my iPhone > > > On Nov 7, 2015, at 11:20, Larry McVoy <lm at mcvoy.com> wrote: > > > > So this seems pretty tough, 16 bit machine and all. If you were to get > > it to work it would probably be with Lachman's STREAMS based TCP/IP. > > No idea if that was open sourced. > > > >> On Sat, Nov 07, 2015 at 08:03:58PM +0100, Oliver Lehmann wrote: > >> Hi, > >> > >> i have an old Z8001 based SysIII variant and I would love to have > >> TCP/IP on it (SLIP first, later with a homebrew ethernet device). > >> > >> I wonder if someone ever saw TCP/IP available on a System III? > >> > >> I have lets say 90% of the kernel running on it as source > >> available and I started digging in the available 4.2 BSD sources. > >> > >> It looks like there would be much to do to hack in TCP/IP on my > >> own (no IPC, no Net, no PTY, no....). > >> > >> I got K5JB running (userland TCP/IP implementation) after I fixed > >> some C code because the C Compiler available on the system is..... > >> kinda limited. > >> > >> telnetd is of course not working as there are no pseudo-teletypes > >> on this SYSIII. At least I got ping, echoping and ftpd up and > >> running via SLIP > >> > >> (10.1.1.2 is my SysIII box:) > >> > >> # ping -c3 10.1.1.2 > >> PING 10.1.1.2 (10.1.1.2): 56 data bytes > >> 64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms > >> 64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms > >> 64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms > >> > >> --- 10.1.1.2 ping statistics --- > >> 3 packets transmitted, 3 packets received, 0.0% packet loss > >> round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms > >> # ftp 10.1.1.2 > >> Connected to 10.1.1.2. > >> 220 FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991 > >> Name (10.1.1.2:root): test > >> 331 Enter PASS command > >> Password: > >> 230 Logged in > >> ftp> get sa.timer > >> local: sa.timer remote: sa.timer > >> 500 Unknown command > >> 500 Unknown command > >> 200 Port command okay > >> 150 Opening data connection for RETR sa.timer > >> 2571 0.53 KB/s > >> 226 File sent OK > >> 2571 bytes received in 00:05 (0.48 KB/s) > >> ftp> get wega > >> local: wega remote: wega > >> 200 Port command okay > >> 150 Opening data connection for RETR wega > >> 98723 0.51 KB/s > >> 226 File sent OK > >> 98723 bytes received in 03:05 (0.51 KB/s) > >> ftp> exit > >> 221 Goodbye! > >> # > >> > >> So I wonder if someone got anything SYSIII -> Net/TCP/IP related > >> which could help me in any way to get a SYSIII kernel capable of > >> TCP/IP and PTYs to get a telnetd up and running via SLIP is my > >> first goal. > >> > >> Regards, > >> Oliver > >> _______________________________________________ > >> TUHS mailing list > >> TUHS at minnie.tuhs.org > >> https://minnie.tuhs.org/mailman/listinfo/tuhs > > > > -- > > --- > > Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm > > _______________________________________________ > > TUHS mailing list > > TUHS at minnie.tuhs.org > > https://minnie.tuhs.org/mailman/listinfo/tuhs -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-08 7:11 ` Larry McVoy @ 2015-11-08 7:22 ` John Cowan 2015-11-08 8:20 ` Cory Smelosky 2015-11-08 14:45 ` Dave Horsfall 1 sibling, 1 reply; 26+ messages in thread From: John Cowan @ 2015-11-08 7:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-08 7:22 ` John Cowan @ 2015-11-08 8:20 ` Cory Smelosky 0 siblings, 0 replies; 26+ messages in thread From: Cory Smelosky @ 2015-11-08 8:20 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-08 7:11 ` Larry McVoy 2015-11-08 7:22 ` John Cowan @ 2015-11-08 14:45 ` Dave Horsfall 2015-11-08 17:04 ` Steve Nickolas 2015-11-09 4:34 ` Larry McVoy 1 sibling, 2 replies; 26+ messages in thread From: Dave Horsfall @ 2015-11-08 14:45 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-08 14:45 ` Dave Horsfall @ 2015-11-08 17:04 ` Steve Nickolas 2015-11-09 4:34 ` Larry McVoy 1 sibling, 0 replies; 26+ messages in thread From: Steve Nickolas @ 2015-11-08 17:04 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-08 14:45 ` Dave Horsfall 2015-11-08 17:04 ` Steve Nickolas @ 2015-11-09 4:34 ` Larry McVoy 1 sibling, 0 replies; 26+ messages in thread From: Larry McVoy @ 2015-11-09 4:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-07 19:20 ` Larry McVoy 2015-11-07 20:27 ` Cory Smelosky @ 2015-11-07 21:28 ` Clem Cole 2015-11-07 22:07 ` Cory Smelosky 2015-11-07 22:13 ` Oliver Lehmann 1 sibling, 2 replies; 26+ messages in thread From: Clem Cole @ 2015-11-07 21:28 UTC (permalink / raw) hmm... 0.) adding pty's is pretty easy. Just grab the BSD code and start hacking. Grab the original version of Steven's book - he will talk to you through it in detail. It's a two drivers, the control (ptyX) and the slave (ttypX) . Having them in your system is handy anyway for a number of things besides networking (like the expect(1) program). 1.) Larry's memory might be better than mine but I did not think streams shows up until System V.3. I have an old PWB 3.0 (System III) manual and see no evidence of streams in it. Given that Dennis did not create them until the V8 tty driver, and then later, the Summit guys use the streams interface for networking, I'm not surprised its not in System III. So I think using streams is likely to be a dead end. 2.) Perry Flinn, Bob Doolittle, and I spliced BSD sockets and the 4.2 stack into a System III -ish kernel for the Masscomp's RTU. So it's definitely doable - although work. The biggest issue is that the memory systems between BSD and System III are different. So Rob Gurwitiz's old mbuf code will need to be hacked. Definitely get a copy of Steven's, maybe the current BSD book and go for it. 3.) One other thought if all you want to a solid IP/TCP network stack and can forgo the sockets API, then you might try to find the old BBN distribution for BSD 4.1 (Vax) -- which is what Joy started with[remember - Berkeley did not have contract for IP/TCP support for the Vax, BBN did - joy took the BBN code and redid it). By definition its is a FOSS - because the US tax payer paid for it - although I'm not sure where to find the code these days (google in your friend). Anyway, the BBN stack splices into the kernel with one small hook (a hack in nami - similar to the MIT ChaosNet stack) but otherwise things just look like devices: i.e. open("/dev/tcp",...) or instead of socket(...) There was a later version/distribution from BBN that included the BSD sockets code as an update for 4.2, but was the BBN guts (we actually used that version for the Stellar machine - splicing it into a System V3 based kernel after adding the BSD APIs). 4.) It strikes me that it would be easiest of all to just take something like a $20-$30 "Wiznet" 5100 board from Sparkfun and interface it to the system either via serial or better if you have a parallel port. Then run the IP/TCP stack externally. This is what we do for Arduino's and other small micro controllers - the board is well documents and easy to talk too. They have both RJ45 style and wireless too. I have a hand full of them here and am pretty happy with them for what they provide. The fact is that for the Masscomp system originally, we ran the IP/TCP stack in a coprocessor (in that case an 186) for realtime reasons (we did not want networking to interrupt the main processor which was 10MHz 68K). But when we finally went to the '020 the processor was so much faster, we put the stack into the kernel and just use the co-processor as a very large buffer. Anyway - the idea is that the system hacking for a tcp stack become very small, just a driver. You don't get things like UNIX domain sockets, but if what you want it telnet/ftp and the like - a cheap coprocessor like the Wiznet should work fine. Clem On Sat, Nov 7, 2015 at 2:20 PM, Larry McVoy <lm at mcvoy.com> wrote: > So this seems pretty tough, 16 bit machine and all. If you were to get > it to work it would probably be with Lachman's STREAMS based TCP/IP. > No idea if that was open sourced. > > On Sat, Nov 07, 2015 at 08:03:58PM +0100, Oliver Lehmann wrote: > > Hi, > > > > i have an old Z8001 based SysIII variant and I would love to have > > TCP/IP on it (SLIP first, later with a homebrew ethernet device). > > > > I wonder if someone ever saw TCP/IP available on a System III? > > > > I have lets say 90% of the kernel running on it as source > > available and I started digging in the available 4.2 BSD sources. > > > > It looks like there would be much to do to hack in TCP/IP on my > > own (no IPC, no Net, no PTY, no....). > > > > I got K5JB running (userland TCP/IP implementation) after I fixed > > some C code because the C Compiler available on the system is..... > > kinda limited. > > > > telnetd is of course not working as there are no pseudo-teletypes > > on this SYSIII. At least I got ping, echoping and ftpd up and > > running via SLIP > > > > (10.1.1.2 is my SysIII box:) > > > > # ping -c3 10.1.1.2 > > PING 10.1.1.2 (10.1.1.2): 56 data bytes > > 64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms > > 64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms > > 64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms > > > > --- 10.1.1.2 ping statistics --- > > 3 packets transmitted, 3 packets received, 0.0% packet loss > > round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms > > # ftp 10.1.1.2 > > Connected to 10.1.1.2. > > 220 FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991 > > Name (10.1.1.2:root): test > > 331 Enter PASS command > > Password: > > 230 Logged in > > ftp> get sa.timer > > local: sa.timer remote: sa.timer > > 500 Unknown command > > 500 Unknown command > > 200 Port command okay > > 150 Opening data connection for RETR sa.timer > > 2571 0.53 KB/s > > 226 File sent OK > > 2571 bytes received in 00:05 (0.48 KB/s) > > ftp> get wega > > local: wega remote: wega > > 200 Port command okay > > 150 Opening data connection for RETR wega > > 98723 0.51 KB/s > > 226 File sent OK > > 98723 bytes received in 03:05 (0.51 KB/s) > > ftp> exit > > 221 Goodbye! > > # > > > > So I wonder if someone got anything SYSIII -> Net/TCP/IP related > > which could help me in any way to get a SYSIII kernel capable of > > TCP/IP and PTYs to get a telnetd up and running via SLIP is my > > first goal. > > > > Regards, > > Oliver > > _______________________________________________ > > TUHS mailing list > > TUHS at minnie.tuhs.org > > https://minnie.tuhs.org/mailman/listinfo/tuhs > > -- > --- > Larry McVoy lm at mcvoy.com > http://www.mcvoy.com/lm > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151107/95db42d9/attachment.html> ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-07 21:28 ` Clem Cole @ 2015-11-07 22:07 ` Cory Smelosky 2015-11-07 22:13 ` Oliver Lehmann 1 sibling, 0 replies; 26+ messages in thread From: Cory Smelosky @ 2015-11-07 22:07 UTC (permalink / raw) Sent from my iPhone > On Nov 7, 2015, at 13:28, Clem Cole <clemc at ccc.com> wrote: > > hmm... > > 0.) adding pty's is pretty easy. Just grab the BSD code and start hacking. Grab the original version of Steven's book - he will talk to you through it in detail. It's a two drivers, the control (ptyX) and the slave (ttypX) . Having them in your system is handy anyway for a number of things besides networking (like the expect(1) program). > > 1.) Larry's memory might be better than mine but I did not think streams shows up until System V.3. I have an old PWB 3.0 (System III) manual and see no evidence of streams in it. Given that Dennis did not create them until the V8 tty driver, and then later, the Summit guys use the streams interface for networking, I'm not surprised its not in System III. So I think using streams is likely to be a dead end. > > 2.) Perry Flinn, Bob Doolittle, and I spliced BSD sockets and the 4.2 stack into a System III -ish kernel for the Masscomp's RTU. So it's definitely doable - although work. The biggest issue is that the memory systems between BSD and System III are different. So Rob Gurwitiz's old mbuf code will need to be hacked. Definitely get a copy of Steven's, maybe the current BSD book and go for it. > > 3.) One other thought if all you want to a solid IP/TCP network stack and can forgo the sockets API, then you might try to find the old BBN distribution for BSD 4.1 (Vax) -- which is what Joy started with[remember - Berkeley did not have contract for IP/TCP support for the Vax, BBN did - joy took the BBN code and redid it). By definition its is a FOSS - because the US tax payer paid for it - although I'm not sure where to find the code these days (google in your friend). Anyway, the BBN stack splices into the kernel with one small hook (a hack in nami - similar to the MIT ChaosNet stack) but otherwise things just look like devices: i.e. open("/dev/tcp",...) or instead of socket(...) There was a later version/distribution from BBN that included the BSD sockets code as an update for 4.2, but was the BBN guts (we actually used that version for the Stellar machine - splicing it into a System V3 based kernel after adding the BSD APIs). I have 4.1a and c source I think. > > 4.) It strikes me that it would be easiest of all to just take something like a $20-$30 "Wiznet" 5100 board from Sparkfun and interface it to the system either via serial or better if you have a parallel port. Then run the IP/TCP stack externally. This is what we do for Arduino's and other small micro controllers - the board is well documents and easy to talk too. They have both RJ45 style and wireless too. I have a hand full of them here and am pretty happy with them for what they provide. > > The fact is that for the Masscomp system originally, we ran the IP/TCP stack in a coprocessor (in that case an 186) for realtime reasons (we did not want networking to interrupt the main processor which was 10MHz 68K). But when we finally went to the '020 the processor was so much faster, we put the stack into the kernel and just use the co-processor as a very large buffer. > > Anyway - the idea is that the system hacking for a tcp stack become very small, just a driver. You don't get things like UNIX domain sockets, but if what you want it telnet/ftp and the like - a cheap coprocessor like the Wiznet should work fine. > > Clem > >> On Sat, Nov 7, 2015 at 2:20 PM, Larry McVoy <lm at mcvoy.com> wrote: >> So this seems pretty tough, 16 bit machine and all. If you were to get >> it to work it would probably be with Lachman's STREAMS based TCP/IP. >> No idea if that was open sourced. >> >> On Sat, Nov 07, 2015 at 08:03:58PM +0100, Oliver Lehmann wrote: >> > Hi, >> > >> > i have an old Z8001 based SysIII variant and I would love to have >> > TCP/IP on it (SLIP first, later with a homebrew ethernet device). >> > >> > I wonder if someone ever saw TCP/IP available on a System III? >> > >> > I have lets say 90% of the kernel running on it as source >> > available and I started digging in the available 4.2 BSD sources. >> > >> > It looks like there would be much to do to hack in TCP/IP on my >> > own (no IPC, no Net, no PTY, no....). >> > >> > I got K5JB running (userland TCP/IP implementation) after I fixed >> > some C code because the C Compiler available on the system is..... >> > kinda limited. >> > >> > telnetd is of course not working as there are no pseudo-teletypes >> > on this SYSIII. At least I got ping, echoping and ftpd up and >> > running via SLIP >> > >> > (10.1.1.2 is my SysIII box:) >> > >> > # ping -c3 10.1.1.2 >> > PING 10.1.1.2 (10.1.1.2): 56 data bytes >> > 64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms >> > 64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms >> > 64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms >> > >> > --- 10.1.1.2 ping statistics --- >> > 3 packets transmitted, 3 packets received, 0.0% packet loss >> > round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms >> > # ftp 10.1.1.2 >> > Connected to 10.1.1.2. >> > 220 FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991 >> > Name (10.1.1.2:root): test >> > 331 Enter PASS command >> > Password: >> > 230 Logged in >> > ftp> get sa.timer >> > local: sa.timer remote: sa.timer >> > 500 Unknown command >> > 500 Unknown command >> > 200 Port command okay >> > 150 Opening data connection for RETR sa.timer >> > 2571 0.53 KB/s >> > 226 File sent OK >> > 2571 bytes received in 00:05 (0.48 KB/s) >> > ftp> get wega >> > local: wega remote: wega >> > 200 Port command okay >> > 150 Opening data connection for RETR wega >> > 98723 0.51 KB/s >> > 226 File sent OK >> > 98723 bytes received in 03:05 (0.51 KB/s) >> > ftp> exit >> > 221 Goodbye! >> > # >> > >> > So I wonder if someone got anything SYSIII -> Net/TCP/IP related >> > which could help me in any way to get a SYSIII kernel capable of >> > TCP/IP and PTYs to get a telnetd up and running via SLIP is my >> > first goal. >> > >> > Regards, >> > Oliver >> > _______________________________________________ >> > TUHS mailing list >> > TUHS at minnie.tuhs.org >> > https://minnie.tuhs.org/mailman/listinfo/tuhs >> >> -- >> --- >> Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm >> _______________________________________________ >> TUHS mailing list >> TUHS at minnie.tuhs.org >> https://minnie.tuhs.org/mailman/listinfo/tuhs > > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151107/29e91783/attachment.html> ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-07 21:28 ` Clem Cole 2015-11-07 22:07 ` Cory Smelosky @ 2015-11-07 22:13 ` Oliver Lehmann 2015-11-08 5:10 ` Derek Fawcus 1 sibling, 1 reply; 26+ messages in thread From: Oliver Lehmann @ 2015-11-07 22:13 UTC (permalink / raw) Clem Cole <clemc at ccc.com> wrote: > 0.) adding pty's is pretty easy. Just grab the BSD code and start > hacking. Grab the original version of Steven's book - he will talk to you > through it in detail. It's a two drivers, the control (ptyX) and the > slave (ttypX) . Having them in your system is handy anyway for a number > of things besides networking (like the expect(1) program). Yeah.. having pty would be good anyway but the C compiler is so limited that it would be just some sort of rewrite instead of "porting"... It is basically a pcc as of 1981 with whatever Zilog hacked into it additionally. I once tried to get a current pcc onto the system but... yeah... I guess I lack skill ;) - the new PCC would need to create Z8001 ASM code.... something I lack skill. - an optimizer... haha... no way I could even optimize Z8001 ASM code by hand ;) - if a new linker is needed - how to create Zilogs s.out format... - I guess I would need to recompile the whole kernel with this new compiler to have every object work "together" - but I still lack some sources (most of them I "retranslated" from disassembled object files to C code - but 2 or 3 are just are too hard to retranslate) I also had a look at the C-Compiler which comes with Plexis SYSIII (which is available as source somewhere in the WWW) but this is a compiler capable of non-segmented executables (one 64K segment adressable) only but I need a Compiler creating segmented executables (128 64k segments accessable = 8MB address space) So I'm stuck with this '81ish C compiler - ok - but who said that it would be an easy task ;) > 4.) It strikes me that it would be easiest of all to just take something > like a $20-$30 "Wiznet" 5100 board from Sparkfun and interface it to the > system either via serial or better if you have a parallel port. Then run > the IP/TCP stack externally. This is what we do for Arduino's and other > small micro controllers - the board is well documents and easy to talk > too. They have both RJ45 style and wireless too. I have a hand full of > them here and am pretty happy with them for what they provide. I was thinking about the same. I have connectors on the board where I have access to the System complete bus. They where used for things like a RTC, system memory, Tape controller and so on. So I could build up a board using Wiznet and thats it. So no need of a PIO or SIO which would things kinda slow anyway... Wiznet would be of course faster as the Z8001 would do in any way. But what comes to my mind with that solution... I would need a kernel part which interacts with the wiznet chip (driver). I can not directly access the wiznet from userland which would be non privileged code which is not allowed to execute privileged instructions (raises a trap). On the userland side... I probably have to "rewrite" all the stuff which comes with BSD and uses libnet. Pr is there something like a compatibility layer which provides a library looking like a libnet API but internally "redirects" everything to the wiznet (via the to-be-written-kernel-driver) so I wouldn't need to reinvent all the userland tools as well? Oliver ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-07 22:13 ` Oliver Lehmann @ 2015-11-08 5:10 ` Derek Fawcus 2015-11-08 5:39 ` Nick Downing 0 siblings, 1 reply; 26+ messages in thread From: Derek Fawcus @ 2015-11-08 5:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-08 5:10 ` Derek Fawcus @ 2015-11-08 5:39 ` Nick Downing 2015-11-08 9:40 ` Oliver Lehmann 2015-11-08 13:38 ` Oliver Lehmann 0 siblings, 2 replies; 26+ messages in thread From: Nick Downing @ 2015-11-08 5:39 UTC (permalink / raw) I think you might get better mileage by just trying to port 2.11BSD over to your Z8001 device, since it is a self contained system, no interface hacking will be needed, just porting. You will have to hack in the device drivers for your disks, ports etc, and create a bootstrap and do a little assembly hacking for the memory management, the context switches, exec() and system calls, BUT you have all this in your Sys3 source anyway. I think it would be easier and cleaner to do this than try to transplant a lot of gory internals. My own experience in this was I wanted TCP/IP running on a Z180 machine (1MB RAM but 64k address space with a very basic MMU), so I started with a primitive unix called UZI see http://www.dougbraun.com/oldstuff and hacked in sockets from NOS see http://www.qsl.net/ah6rh/am-radio/packet/jnos.html and honestly it took months, was incredibly tedious and bug-prone, very detailed interfacing work and restructuring to get things like socket timeouts to work, expose functionality via system calls and so on... I reached a point where I was medium satisfied but then my laptop got stolen and I had to revert to month-old backup and decided to throw it away and start again. I also did not finish the 2.11BSD port but I got as far as making 2.11BSD cross compile from a linux system, was going to drop in the Z180 cross toolchain as the next step, but for whatever reason put it aside. I am happy to pass on what I have. Nick On 08/11/2015 4:17 PM, "Derek Fawcus" <dfawcus+lists-tuhs at employees.org> wrote: > On Sat, Nov 07, 2015 at 11:13:38pm +0100, Oliver Lehmann wrote: > > > > It is basically a pcc as of 1981 with whatever Zilog hacked into it > > additionally. I once tried to get a current pcc onto the system but... > > yeah... I guess I lack skill ;) > > - the new PCC would need to create Z8001 ASM code.... something I lack > skill. > > - an optimizer... haha... no way I could even optimize Z8001 ASM code > by > > hand ;) > > - if a new linker is needed - how to create Zilogs s.out format... > > - I guess I would need to recompile the whole kernel with this new > compiler > > to have every object work "together" - but I still lack some sources > (most > > of them I "retranslated" from disassembled object files to C code - but > 2 or > > 3 are just are too hard to retranslate) > > I also had a look at the C-Compiler which comes with Plexis SYSIII (which > > is available as source somewhere in the WWW) but this is a compiler > capable > > of non-segmented executables (one 64K segment adressable) only but I > need a > > Compiler creating segmented executables (128 64k segments accessable = > 8MB > > address space) > > Older versions of gcc (around 3.3/3.4) supported the z8000 family, so you > could try using it to make things easier. Have a look here: > http://www.z80ne.com/m20/sections/download/z8kgcc/z8kgcc.html > which seems to be a version supporting segments - the '-mz8001' switch. > > DF > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151108/c7caac2f/attachment.html> ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-08 5:39 ` Nick Downing @ 2015-11-08 9:40 ` Oliver Lehmann 2015-11-08 13:38 ` Oliver Lehmann 1 sibling, 0 replies; 26+ messages in thread From: Oliver Lehmann @ 2015-11-08 9:40 UTC (permalink / raw) Yeah, Nick Downing <downing.nick at gmail.com> wrote: > I think you might get better mileage by just trying to port 2.11BSD over to > your Z8001 device, since it is a self contained system, no interface > hacking will be needed, just porting. would be of course a way to do, but then it is just another BSD installation. I could also run on every other hardware. And being able to crosscompile which would be lets say - mandatory - to not transfer files via 9600baud every single time would involve getting a compiler create Assembler code. And of course the 2.11 BSD need to understand and execute Zilogs s.out format as I have a bunch of software (involving the Assembler) where I have zero sources for. I have once tried to port the old gcc as well as - I forgot the name - some other sort of C compiler with Z8001 support - but they all lack the s.out format support and have a sligthly different ASM syntax than the Assembler I have supports. Missing features like extended math functions and so on..... But you might be right... porting a "complete" system like 2.11 BSD might be easier than extracting every little piece just to find out that another piece needs to be extracted as well... wich probably makes you end up with a BSD kernel anyway ;) Regards, Oliver ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-08 5:39 ` Nick Downing 2015-11-08 9:40 ` Oliver Lehmann @ 2015-11-08 13:38 ` Oliver Lehmann 2015-11-09 0:21 ` Nick Downing 2015-11-09 0:31 ` Nick Downing 1 sibling, 2 replies; 26+ messages in thread From: Oliver Lehmann @ 2015-11-08 13:38 UTC (permalink / raw) Nick Downing <downing.nick at gmail.com> wrote: > I think you might get better mileage by just trying to port 2.11BSD over to > your Z8001 device, since it is a self contained system, no interface > hacking will be needed, just porting. By the way - why do you think 2.11 BSD would be better to port instead of the original 4.3 BSD? The system has no 64KB addressing limitation. It can adress up to 128 64KB segments (=8MB). I mean, on a first look, it looks like 2.11BSD contains a lot more Assembler Code I would need to move to Z8001 ASM mnemonics as 4.3 does?! ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-08 13:38 ` Oliver Lehmann @ 2015-11-09 0:21 ` Nick Downing 2015-11-09 8:15 ` Oliver Lehmann 2015-11-09 0:31 ` Nick Downing 1 sibling, 1 reply; 26+ messages in thread From: Nick Downing @ 2015-11-09 0:21 UTC (permalink / raw) Although the Z8000 has segments, they will require special code to access, and so you will have to regard it as a 16 bit CPU from the viewpoint of running ordinary unix kernel/applications. You can most likely implement a split I/D architecture by having code execute out of a different segment than data, although I haven't checked the datasheet so I don't know for sure if this is possible. You can also do a few other things -- you could for example make mbufs and bufs reside in different segments and wrap all kernel accesses to them in macros, which would free up significant space in the main kernel data segment. Or you could do what I did for the Z180 implementation, (the first try -- UZI / NOS derivative, not the proposed 2.11BSD port), which I somewhat borrowed from the IAR's Z180 C compiler -- the calling convention allows for a segment switch on function call and return, so you can have large multi-segment executables. In my implementation I had a 768 kbyte RAM disk which was formatted unix style (not BSD style unfortunately), but I had an alignment routine which put executable files into contiguous blocks on 4kbyte boundaries (normally the filesystem had 1kbyte blocks), and I created a mapping table, and I revised the IAR compiler's calling stubs to allow executing multi segment executables direct from RAM disk. This would work in your system with minor porting, but unfortunately it's not implemented in 2.11BSD, it's in my earlier code. You're welcome to it, though. The kernel and some of the utilities in 2.11BSD are large enough to require split I/D, I didn't have that, but proposed to get around it by using multi-segmented executables (my memory map allowed for 4 kbytes of stubs and utility code/data, 56 kbytes of data and 4 kbytes of the currently visible code segment). So you will have to either implement split I/D or multi-segmented executables, it doesn't matter which. Check how your sys3 system handles this, because you will probably want to take as much of the assembly code from the sys3 system as possible. So given you're implementing a 16 bit system, you should definitely go for 2.11BSD, it's simply the most advanced and the only reasonable unix system out there that executes in 64 kbytes. You can look at 4.3BSD, personally I looked at a later BSD and I discovered that the network stack is significantly cut down in 2.11BSD, and for good reasons. For example it does not implement syn cookies (protection against TCP SYN DOS attacks), presumably because this required some largeish kernel tables. You don't need the complexity, you want 2.11BSD I think. Nick On Mon, Nov 9, 2015 at 12:38 AM, Oliver Lehmann <lehmann at ans-netz.de> wrote: > > Nick Downing <downing.nick at gmail.com> wrote: > >> I think you might get better mileage by just trying to port 2.11BSD over >> to >> your Z8001 device, since it is a self contained system, no interface >> hacking will be needed, just porting. > > > By the way - why do you think 2.11 BSD would be better to port instead of > the > original 4.3 BSD? The system has no 64KB addressing limitation. It can > adress > up to 128 64KB segments (=8MB). I mean, on a first look, it looks like > 2.11BSD > contains a lot more Assembler Code I would need to move to Z8001 ASM > mnemonics > as 4.3 does?! > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-09 0:21 ` Nick Downing @ 2015-11-09 8:15 ` Oliver Lehmann 2015-11-09 8:16 ` Oliver Lehmann 0 siblings, 1 reply; 26+ messages in thread From: Oliver Lehmann @ 2015-11-09 8:15 UTC (permalink / raw) Nick Downing <downing.nick at gmail.com> wrote: > You can most likely implement a split I/D architecture by having code > execute out of a different segment than data, although I haven't > checked the datasheet so I don't know for sure if this is possible. I have 3 different MMUs available. Stack, Code and Data it is called in the Circuit diagram. I probably have to lookup the references but I still don't get why the kernel can only work with 64k of RAM as it is right now compiled as a segmented programm and uses more memory already with SysIII. Only the boot0-loader is compiled unsegmented and also some small utilities. Every other portion of the system uses the segmentation features of the Z8001 and is not limited to 64k adressable space. The system has right now MB of ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-09 8:15 ` Oliver Lehmann @ 2015-11-09 8:16 ` Oliver Lehmann 2015-11-09 9:40 ` Oliver Lehmann 0 siblings, 1 reply; 26+ messages in thread From: Oliver Lehmann @ 2015-11-09 8:16 UTC (permalink / raw) I hit the send button to fast :( Oliver Lehmann <lehmann at ans-netz.de> wrote: > Nick Downing <downing.nick at gmail.com> wrote: > >> You can most likely implement a split I/D architecture by having code >> execute out of a different segment than data, although I haven't >> checked the datasheet so I don't know for sure if this is possible. > > I have 3 different MMUs available. Stack, Code and Data it is called in > the Circuit diagram. I probably have to lookup the references but I still > don't get why the kernel can only work with 64k of RAM as it is right now > compiled as a segmented programm and uses more memory already with SysIII. > Only the boot0-loader is compiled unsegmented and also some small > utilities. Every other portion of the system uses the segmentation features > of the Z8001 and is not limited to 64k adressable space. > > The system has right now MB of The system has right now around 6 MB of RAM but can be upgraded to 16MB minus 64KB (Due to a firmware bug) of RAM. ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-09 8:16 ` Oliver Lehmann @ 2015-11-09 9:40 ` Oliver Lehmann 2015-11-09 9:40 ` Oliver Lehmann 0 siblings, 1 reply; 26+ messages in thread From: Oliver Lehmann @ 2015-11-09 9:40 UTC (permalink / raw) This is for example the ureg.c which shows the Segmentation Code for the current SysIII Kernel I redid from original SysIII Sources + Disassembled object-File analysis of the current SysIII Kernel running on the system: http://cvs.laladev.org/index.html/P8000/WEGA/src/uts/sys/ureg.c?rev=1.1&content-type=text/x-cvsweb-markup Oliver Lehmann <lehmann at ans-netz.de> wrote: > I hit the send button to fast :( > > Oliver Lehmann <lehmann at ans-netz.de> wrote: > >> Nick Downing <downing.nick at gmail.com> wrote: >> >>> You can most likely implement a split I/D architecture by having code >>> execute out of a different segment than data, although I haven't >>> checked the datasheet so I don't know for sure if this is possible. >> >> I have 3 different MMUs available. Stack, Code and Data it is called in >> the Circuit diagram. I probably have to lookup the references but I still >> don't get why the kernel can only work with 64k of RAM as it is right now >> compiled as a segmented programm and uses more memory already with SysIII. >> Only the boot0-loader is compiled unsegmented and also some small >> utilities. Every other portion of the system uses the segmentation features >> of the Z8001 and is not limited to 64k adressable space. >> >> The system has right now MB of > > The system has right now around 6 MB of RAM but can be upgraded to 16MB > minus 64KB (Due to a firmware bug) of RAM. ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-09 9:40 ` Oliver Lehmann @ 2015-11-09 9:40 ` Oliver Lehmann 2015-11-09 22:36 ` Nick Downing 0 siblings, 1 reply; 26+ messages in thread From: Oliver Lehmann @ 2015-11-09 9:40 UTC (permalink / raw) http://cvs.laladev.org/index.html/P8000/WEGA/src/uts/sys/ureg.c?rev=1.9&content-type=text/x-cvsweb-markup 1.9 is the current version 1.1 is the plain SysIII file... Oliver Lehmann <lehmann at ans-netz.de> wrote: > This is for example the ureg.c which shows the Segmentation Code for the > current SysIII Kernel I redid from original SysIII Sources + Disassembled > object-File analysis of the current SysIII Kernel running on the system: > > http://cvs.laladev.org/index.html/P8000/WEGA/src/uts/sys/ureg.c?rev=1.1&content-type=text/x-cvsweb-markup > > > > Oliver Lehmann <lehmann at ans-netz.de> wrote: > >> I hit the send button to fast :( >> >> Oliver Lehmann <lehmann at ans-netz.de> wrote: >> >>> Nick Downing <downing.nick at gmail.com> wrote: >>> >>>> You can most likely implement a split I/D architecture by having code >>>> execute out of a different segment than data, although I haven't >>>> checked the datasheet so I don't know for sure if this is possible. >>> >>> I have 3 different MMUs available. Stack, Code and Data it is called in >>> the Circuit diagram. I probably have to lookup the references but I still >>> don't get why the kernel can only work with 64k of RAM as it is right now >>> compiled as a segmented programm and uses more memory already with SysIII. >>> Only the boot0-loader is compiled unsegmented and also some small >>> utilities. Every other portion of the system uses the segmentation features >>> of the Z8001 and is not limited to 64k adressable space. >>> >>> The system has right now MB of >> >> The system has right now around 6 MB of RAM but can be upgraded to 16MB >> minus 64KB (Due to a firmware bug) of RAM. ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-09 9:40 ` Oliver Lehmann @ 2015-11-09 22:36 ` Nick Downing 0 siblings, 0 replies; 26+ messages in thread From: Nick Downing @ 2015-11-09 22:36 UTC (permalink / raw) Well that looks to me like a standard split I/D setup where each process, and the kernel, can have up to 64 kb of code and 64 kb of data. It will run 2.11bsd with a relatively straightforward porting effort -- direct translation of each code fragment to do something equivalent on your device. What I discussed as another option (that I did on Z180 which did not have split I/D and hence had too small a logical address space to run 2.11bsd or any other reasonable unix)... was to increase the code limit past 64 kb by segmentation. Whilst this is difficult to do, it can be achieved without (much) compiler support. Code pointers become 3 bytes instead of 2, but luckily, code pointers are hardly used, and this limitation can be got around by using stubs. You are right though, in that a natively running system that can freely utilize your 6 Mb or 8 Mb or whatever, certainly IS possible. The MS DOS C compilers for PC/XT, PC/AT etc, supported this. The "large" memory model had segmented code and data, any process could have multiple code and data segments. Pointers were 4 bytes (equivalent to 3 bytes in your case, a 16-bit offset and a 7-bit segment). However, pointer arithmetic did not carry into the segment field, so arrays and structs and the biggest "malloc" were limited to 64 kbytes. It was somewhat slower than the "small" memory model (2 byte pointers) and everything took more memory. The "huge" memory model removed the 64 kbyte limitation altogether via a software emulation of a flat address space (by doing carrying arithmetic whenever pointers, arrays or structs were derefenced) but was of course MUCH slower. If your compiler supports these things, go ahead and use them and port 4.3BSD across, it would be great. I thought you were talking about a smaller system like 1 Mb, with 1 Mb you could support say 3 users and a kernel @ 256 kbytes each using a 2.11bsd-like split I/D system and a small memory model. They could run a reasonable toolchain consisting of a shell spawning cc spawning a compiler or linker (for example) and an editor, simultaneously, though it would be tight. In that case I would be concerned about speed and size and would recommend a "small" memory model. But if you have 6 Mb and your processor is relatively fast (say 8 MHz) and your compiler efficient, then I guess a "large" model would be reasonable. I like tiny unices, though :) Nick On 09/11/2015 8:40 PM, "Oliver Lehmann" <lehmann at ans-netz.de> wrote: > > http://cvs.laladev.org/index.html/P8000/WEGA/src/uts/sys/ureg.c?rev=1.9&content-type=text/x-cvsweb-markup > > 1.9 is the current version 1.1 is the plain SysIII file... > > > Oliver Lehmann <lehmann at ans-netz.de> wrote: > > This is for example the ureg.c which shows the Segmentation Code for the >> current SysIII Kernel I redid from original SysIII Sources + Disassembled >> object-File analysis of the current SysIII Kernel running on the system: >> >> >> http://cvs.laladev.org/index.html/P8000/WEGA/src/uts/sys/ureg.c?rev=1.1&content-type=text/x-cvsweb-markup >> >> >> >> Oliver Lehmann <lehmann at ans-netz.de> wrote: >> >> I hit the send button to fast :( >>> >>> Oliver Lehmann <lehmann at ans-netz.de> wrote: >>> >>> Nick Downing <downing.nick at gmail.com> wrote: >>>> >>>> You can most likely implement a split I/D architecture by having code >>>>> execute out of a different segment than data, although I haven't >>>>> checked the datasheet so I don't know for sure if this is possible. >>>>> >>>> >>>> I have 3 different MMUs available. Stack, Code and Data it is called in >>>> the Circuit diagram. I probably have to lookup the references but I >>>> still >>>> don't get why the kernel can only work with 64k of RAM as it is right >>>> now >>>> compiled as a segmented programm and uses more memory already with >>>> SysIII. >>>> Only the boot0-loader is compiled unsegmented and also some small >>>> utilities. Every other portion of the system uses the segmentation >>>> features >>>> of the Z8001 and is not limited to 64k adressable space. >>>> >>>> The system has right now MB of >>>> >>> >>> The system has right now around 6 MB of RAM but can be upgraded to 16MB >>> minus 64KB (Due to a firmware bug) of RAM. >>> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151110/9074cfd5/attachment.html> ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-08 13:38 ` Oliver Lehmann 2015-11-09 0:21 ` Nick Downing @ 2015-11-09 0:31 ` Nick Downing 1 sibling, 0 replies; 26+ messages in thread From: Nick Downing @ 2015-11-09 0:31 UTC (permalink / raw) By the way, there's no reason you can't use your existing Zilog toolchain. You can just modify the makefiles that come with 2.11BSD to run the Zilog tools. Or another option might be to write a compiler driver that acts like "cc" and invokes the Zilog tools as subprocesses, you have the source for 2.11BSD "cc" so this shouldn't be too hard to do. Whatever naming convention the Zilog compiler uses, you could rename the object files to ".o" and the 2.11BSD build system would work largely unchanged. The most tricky part will be creating the a.out executables, which are in the simplest case a header of maybe 18 bytes (depends slightly on the magic number of the executable since there were a few different compatible versions) followed by the code and data segments followed by relocation records. To do this, I am pretty sure I created my own linker, or modified the unix linker (cannot remember exactly) in order to read the object files from the IAR Z180 assembler (and I think these were in S-record format that you mentioned) and create the a.out executables, I also had an extended a.out format for the large multi-segment executables (including the kernel), in which I arranged the code into 4 kbyte segments using a first-fit algorithm. Again I'm happy to give you whatever I have on this. Nick On Mon, Nov 9, 2015 at 12:38 AM, Oliver Lehmann <lehmann at ans-netz.de> wrote: > > Nick Downing <downing.nick at gmail.com> wrote: > >> I think you might get better mileage by just trying to port 2.11BSD over >> to >> your Z8001 device, since it is a self contained system, no interface >> hacking will be needed, just porting. > > > By the way - why do you think 2.11 BSD would be better to port instead of > the > original 4.3 BSD? The system has no 64KB addressing limitation. It can > adress > up to 128 64KB segments (=8MB). I mean, on a first look, it looks like > 2.11BSD > contains a lot more Assembler Code I would need to move to Z8001 ASM > mnemonics > as 4.3 does?! > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-07 19:03 Oliver Lehmann 2015-11-07 19:20 ` Larry McVoy @ 2015-11-11 1:54 ` Cornelius Keck 2015-11-11 6:46 ` Oliver Lehmann 1 sibling, 1 reply; 26+ messages in thread From: Cornelius Keck @ 2015-11-11 1:54 UTC (permalink / raw) 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 > > ^ permalink raw reply [flat|nested] 26+ messages in thread
* [TUHS] System III - TCP/IP 2015-11-11 1:54 ` Cornelius Keck @ 2015-11-11 6:46 ` Oliver Lehmann 0 siblings, 0 replies; 26+ messages in thread From: Oliver Lehmann @ 2015-11-11 6:46 UTC (permalink / raw) Hi Cornelius, the system is more or less a clone of the Zilog System 8000 which ran ZEUS. The clone was made in the eastern part of germany behind the iron curtain. The 16Bit part of the system is more or less a 1:1 clone of the System 8000 and so is the OS also a clone of ZEUS (with modified part of the kernel to adress the differences in hardware). If you are more interested about the system itself, feel free to read more on my page (page itself is english, but most linked documents are in german) http://www.pofo.de/P8000/ Regards, Oliver Cornelius Keck <ckeck at texoma.net> wrote: > Z8001 with SysIII, what hardware is that? Sounds a bit like Commodore's > CBM900, but that ran Coherent 0.7.3 or so, was actually fairly snappy for > its time. Coherent roughly resembled Unix System 7. Didn't have an IP > stack. > > On Sat, November 7, 2015 14:03, Oliver Lehmann wrote: >> Hi, >> >> >> i have an old Z8001 based SysIII variant and I would love to have TCP/IP >> on it (SLIP first, later with a homebrew ethernet device). >> >> I wonder if someone ever saw TCP/IP available on a System III? >> >> >> I have lets say 90% of the kernel running on it as source >> available and I started digging in the available 4.2 BSD sources. >> >> It looks like there would be much to do to hack in TCP/IP on my >> own (no IPC, no Net, no PTY, no....). >> >> I got K5JB running (userland TCP/IP implementation) after I fixed >> some C code because the C Compiler available on the system is..... kinda >> limited. >> >> telnetd is of course not working as there are no pseudo-teletypes on this >> SYSIII. At least I got ping, echoping and ftpd up and >> running via SLIP >> >> (10.1.1.2 is my SysIII box:) >> >> >> # ping -c3 10.1.1.2 >> PING 10.1.1.2 (10.1.1.2): 56 data bytes >> 64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms >> 64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms >> 64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms >> >> >> --- 10.1.1.2 ping statistics --- >> 3 packets transmitted, 3 packets received, 0.0% packet loss >> round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms # ftp >> 10.1.1.2 >> Connected to 10.1.1.2. >> 220 FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991 >> Name (10.1.1.2:root): test >> 331 Enter PASS command >> Password: >> 230 Logged in >> ftp> get sa.timer local: sa.timer remote: sa.timer >> 500 Unknown command >> 500 Unknown command >> 200 Port command okay >> 150 Opening data connection for RETR sa.timer >> 2571 0.53 KB/s >> 226 File sent OK >> 2571 bytes received in 00:05 (0.48 KB/s) >> ftp> get wega local: wega remote: wega >> 200 Port command okay >> 150 Opening data connection for RETR wega >> 98723 0.51 KB/s >> 226 File sent OK >> 98723 bytes received in 03:05 (0.51 KB/s) >> ftp> exit 221 Goodbye! >> # >> >> >> So I wonder if someone got anything SYSIII -> Net/TCP/IP related >> which could help me in any way to get a SYSIII kernel capable of TCP/IP and >> PTYs to get a telnetd up and running via SLIP is my >> first goal. >> >> Regards, >> Oliver >> _______________________________________________ >> TUHS mailing list >> TUHS at minnie.tuhs.org >> https://minnie.tuhs.org/mailman/listinfo/tuhs >> >> ^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2015-11-11 6:46 UTC | newest] Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-11-08 15:52 [TUHS] System III - TCP/IP Noel Chiappa -- strict thread matches above, loose matches on Subject: below -- 2015-11-07 19:03 Oliver Lehmann 2015-11-07 19:20 ` Larry McVoy 2015-11-07 20:27 ` Cory Smelosky 2015-11-08 7:11 ` Larry McVoy 2015-11-08 7:22 ` John Cowan 2015-11-08 8:20 ` Cory Smelosky 2015-11-08 14:45 ` Dave Horsfall 2015-11-08 17:04 ` Steve Nickolas 2015-11-09 4:34 ` Larry McVoy 2015-11-07 21:28 ` Clem Cole 2015-11-07 22:07 ` Cory Smelosky 2015-11-07 22:13 ` Oliver Lehmann 2015-11-08 5:10 ` Derek Fawcus 2015-11-08 5:39 ` Nick Downing 2015-11-08 9:40 ` Oliver Lehmann 2015-11-08 13:38 ` Oliver Lehmann 2015-11-09 0:21 ` Nick Downing 2015-11-09 8:15 ` Oliver Lehmann 2015-11-09 8:16 ` Oliver Lehmann 2015-11-09 9:40 ` Oliver Lehmann 2015-11-09 9:40 ` Oliver Lehmann 2015-11-09 22:36 ` Nick Downing 2015-11-09 0:31 ` Nick Downing 2015-11-11 1:54 ` Cornelius Keck 2015-11-11 6:46 ` Oliver Lehmann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).