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: -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

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(a)mcvoy.com> wrote:

Clem Cole <clemc(a)ccc.com> wrote: 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 ;) 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

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(a)employees.org> wrote:

Larry McVoy scripsit: Bohr and Feynman at Los Alamos, to put it Star Trek-ly. 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. I tend to agree: a thoroughly vanilla release. -- John Cowan http://www.ccil.org/~cowan cowan(a)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

Yeah, Nick Downing <downing.nick(a)gmail.com> wrote: 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

On Sat, 7 Nov 2015, Larry McVoy wrote: 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 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... Indeed. -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

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(a)ans-netz.de> wrote:

On Mon, Nov 09, 2015 at 01:45:18AM +1100, Dave Horsfall wrote: 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

I hit the send button to fast :( Oliver Lehmann <lehmann(a)ans-netz.de> wrote: 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.

http://cvs.laladev.org/index.html/P8000/WEGA/src/uts/sys/ureg.c?rev=1.9&… 1.9 is the current version 1.1 is the plain SysIII file... Oliver Lehmann <lehmann(a)ans-netz.de> 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: