Yes, OK, I see that there are unanticipated problems with the 2BSD Z180 port. Basically I had thought that the kernel ran like a userspace program, I knew there might be overlays involved with the code space, but I hadn't realized there are also overlays with the data space (from what you say I guess the mbufs are accessed using a kind of a "far" pointer). Anyway, I will check into it further. Based on the previous day's conversations I got inspired to continue the project, I got out the 2.11BSD toolchain which I had ported to a modern machine as a cross compiler (actually Mac OSX although I was using it like a poor man's Linux)... started again using Linux and a different way of building that would require less change to the Makefiles, fixed all compile warnings, fixed many bugs, it now produces: bin/ar bin/as bin/cc bin/ld bin/nm lib/c0 lib/c1 lib/c2 lib/cpp lib/crt0.o lib/libc.a lib/mcrt0.o usr/bin/lorder usr/bin/ranlib usr/lib/libc_p.a The executables above are x86-64 Linux ELF executables that work alike to the corresponding PDP-11 2.11BSD a.out executables, except that hard coded paths like /usr/include or /usr/lib have an extra prefix added to them, at the moment it works like this: /home/nick/src/2bsd_cc.git/bin/cc contains a hard coded executable path of /home/nick/2bsd_cc.git/lib.cpp /home/nick/src/2bsd_cc.git/lib/cpp contains a hard coded include path of /home/nick/src/2bsd_cc.git/usr/include and so on, these are set up at build time. Changes to the makefiles are pretty minimal, in the libc source directory I had to change things a bit to make it refer to the cross compiler rather than the native compiler, by changing stuff like "cc" to "${CC}" and adding stuff like: DESTDIR=../../.. CC=${DESTDIR}/bin/cc and so forth. The revised toolchain if compiled with -DPDP11 will be more-or-less as original, so it should not break the self-hosted compile system (up to possible minor breakage because I haven't tested this mode yet), for instance if the original code looked like this: int some_function(); ... some_function(a) int a; { some code } then it would now look like this: int some_function PARAMS((int a)); ... int some_function(a) int a; { some code } where the PARAMS macro is set up appropriately depending on whether we are compiling on the PDP-11 or the modern Linux machine. One significant difference with the cross toolchain is that I have translated the PDP-11 assembler /bin/as from assembler into C. So I guess it will be slightly slower and use slightly more memory, but I doubt the difference would be noticeable in practice. In future when I merge my changes into 2.11BSD and fix any breakage, I'll probably just delete the as0.s, as2.s and replace with as0.c, as2.c. Also I fixed some memory allocation bugs and illegal pointer dereferences in the other utilities that just happened to be benign on PDP-11. Anyway, I'm pretty stoked because after successfully building the C library, etc, with the cross toolchain, I compiled a hello world program and copied it into the running simh system, it executed without problems. When I compiled the same program on the self-hosted compile system in the running simh system everything was the same except the final executable, I will have to pay a bit of attention to the lorder and tsort stuff when it builds the C library, to make sure everything comes out in a predictable way for comparison. I will test this more extensively in the coming weeks, e.g. by building a kernel using the cross toolchain and checking it's the same. I am nearly ready to put the cross toolchain on bitbucket, but I just want to take a bit of care before doing "git commit" to make sure it's not capturing any junk I don't want in there, so I will do it later. I had better pay some attention to the family :) Happy new year everyone. cheers, Nick On Fri, Dec 30, 2016 at 5:20 AM, Ron Natalie <ron(a)ronnatalie.com> wrote:

Yes, I am aware of the concept, I had used a similar emulator to run CP/M binaries on MS-DOS, specifically Microsoft Macro-80, Link-80 and Basic-80 compiler. Yes I was doing cash registers that far back :) :) It is really convenient having access to your host filesystem (compared with attaching a simh formatted emulated tape image, tarring to/from it, and converting to/rom simh format and plain binary as I did yesterday). I hadn't seen apout but it is a good idea, I was toying with doing the same thing by cross compiling the 2.11BSD kernel to create something like User Mode Linux (but then adding user mode PDP-11 CPU emulation since it does not make sense to compile x86-64 2.11BSD userspace executables even though it is theoretically possible). I don't know how stable is the ABI between Unix V7 and BSD or between BSD versions. I suspect it is very similar but there would be differences in things like struct stat which are bound to cause breakage. So I think it has to run the correct kernel to get the correct ABI, and in turn that kernel has to have null or pass thru drivers to access the host facilities. I do hope to get this working someday, especially since a full cross compile of 2.11BSD includes the f77 stuff which cannot reasonably be compiled on a modern system given the compiler is not written in C, I think it is PDP-11 assembly. For now I am trying to reduce the amount of stuff I need to change, so my idea is to modify simh to allow switching between Z80 and PDP-11 instruction sets (I could use the PSW so that it can process an interrupt or syscall in PDP-11 mode and transparently return to Z80 mode when it restores the PSW) and then just convert little pieces at a time, I could compile a Z80 hello world program and then link it against the PDP-11 C library for instance. So this puts off having to deal with MMU or driver issues till later on. I am looking at changing /lib/c1 and /bin/as to add a .z80 directive and the z80 instruction set. cheers, Nick On 31/12/2016 5:19 PM, "Robert Swierczek" <rmswierczek(a)gmail.com> wrote: