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

On Sun, 8 Nov 2015, John Cowan wrote: What about SysV for PDP-11? ;D -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects

On Mon, 9 Nov 2015, Dave Horsfall wrote: Dragon Ball Z? *shot* -uso.

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:

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

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

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&… Oliver Lehmann <lehmann(a)ans-netz.de> wrote:

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