Hi Oliver, On Sa, 2015-11-21 at 14:00 +0100, Oliver Lehmann wrote: I don't have an exact HOWTO for porting BSD, but we gathered some experience in these things while porting NetBSD to our processor ECO32. First and most important is a working tool-chain (which in case of BSD means GCC). You should really know your tools, because you will frequently dig deep into them to understand various aspects of e.g. linker scripts. We totally underestimated the amount of work to be done here. Then you must decide if you will do cross-development, or if you can do it on a running BSD system. Even if so, you will have to generate a file system for the target BSD system from which you boot your machine. You can do that with the tools included in BSD, but they are not running yet. (Btw, byte-order is an especially nasty thing in this context.) Memory management was another area which required a fair amount of work. I have no experience with 2.11 BSD, but in case of NetBSD the code is divided into at least three layers to obtain a good degree of re-usability for different architectures. Alas, the documentation was rather poor, and the relevant book ("The Design and Implementation of the 4.4 BSD Operating System" by McKusick et al.) is a bit outdated. The project of porting BSD to a yet unsupported machine is certainly feasible, and is indeed a valuable experience. But don't expect to have it done in only a couple of weeks... :-) Good luck! Hellwig _______________________________________________ TUHS mailing list TUHS(a)minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/tuhs

On Sat, Nov 21, 2015, at 08:00, Oliver Lehmann wrote: Is there an emulator for this system so people without one can follow along? _______________________________________________ TUHS mailing list TUHS(a)minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/tuhs

Is there an emulator for this system so people without one can follow along?

William Pechter <pechter(a)gmail.com> wrote: And I also redid (disassembled objects, translated it back to C) nearly all Kernel sources of the SYSIII (only lock.c is missing with file locking features - I only disassembled it) https://github.com/OlliL/P8000/tree/master/WEGA/src/uts Yes... he built the Emulator based on MAME back in 2008 with quite some info from me - he used to work on a P8000 back in the 90s so he felt for it building the Emulator.... ;) Cool... you found my page ;) _______________________________________________ TUHS mailing list TUHS(a)minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/tuhs

The undergrads who used that system to learn Unix ported many a BSD utility to that system (at least the ones that weren't too RAM-hungry), starting with BerkNet so we could move files around easily & have E-mail.

Al Kossow <aek(a)bitsavers.org> wrote: On 11/23/15 12:40 AM, Erik E. Fair wrote: Good point. I was also thinking if 2.11 is realy the right choice to use for porting. From what I understood: - The PDP11 can only access up to 64KB address space. - 2.11 uses overlay to "show" and "hide" memory into this 64K address space. A Z8001 can address up to 128 segments of 64KB. Means, a single array can only be up to 64KB, but you can have 8MB of memory per "section". My system has 3 MMUs while one is dedicated to the code section and one to the data section. So my Code section can be max up to 8MB and my data section can be up to additional 8MB. Currently my system has up to 5.5MB of RAM (but can be upgraded to 16MB easily) I was thinking if 4.3 BSD would be better to port as the whole overlay logic which is implemented in 2.11 could make 2.11 maybe to complex to port? I mean, all this overlay logic would not be needed for the Z8001 and it maybe would not even work. (remember - I plan to use my existing SYSIII compiler which knows nothing about overlaying!) What I understand for 4.3 BSD is, that it is meant to run on machines with a memory configuration where the memory is adressable in "one block" which is of course not true for the Z8001. But - the compiler/assembler handles all this adressing for C code so why should it be imported on how the is addressed internaly? Additionaly, my system has NO floating point support. The current SYSIII uses a lengthy floating point emulation Assembler Source to "work around" that: https://github.com/OlliL/P8000/blob/master/WEGA/src/uts/conf/fpe.s I saw, that 2.11 also has some FPU-emulation. What about 4.3? Could 4.3 be a better choice? If so - which 4.3 should I use? In general - I'm looking for a good target OS. It should be not too complex (-> "modern") but should provide a TCP/IP stack which is my main motivation in porting at all. I'll dig through my archives and see if there was a Z8000 version of pcc That would be great - maybe you could also answer my private mail about the Onyx C8002 I sent you some days ago ;) The compilers for Z8000 I found so far where either able to address 64K only, or where able to only generate COFF-format objects which I can't link on my SYSIII... Oliver _______________________________________________ TUHS mailing list TUHS(a)minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/tuhs

Oh yeah, the other thing i was going to say was you'd be well advised to use the "ld" that comes with 2.11bsd, which generates a.out (a header of about 16 bytes followed by the raw code and data segments), as well as its somewhat primitive *.o file format (which is an a.out executable followed by relocation and linkage tables, so *.o objects are actually executable if they contain a main() function and no unresolved linkage). What you could do is create a small converter that changes your COFF or whatever objects into the right format. Then everything will just work(tm). The linker itself is a bit hard to modify IIRC, it's a split I/D executable that basically constructs the output executable in its D address space so memory is a bit tight and some tricks are used like doing separate passes for code and data. Having said all that, I think in my case I took a simple Z80 assembler and linker that were open sourced and not too horrible internally, and understood Intel HEX records, and then I simply had the IAR compiler (a commercial product) generate assembly and I didn't use the IAR assembler or linker. Then I modified the linker to create a either an original style (non split I/D) a.out executable or a special extended a.out executable that was similar to split I/D except the instructions were in multiple pages 4kbytes in size and the data was up to 56kbytes in size, so they could share the 64kbyte logical address space (the first 4kbytes was permanently mapped regardless of context switches and contained interrupt and trap handlers). You probably won't need to go to the above extremes, but you could easily modify my linker to create normal a.out executables with/without split I/D if you're wanting to use HEX records as the input rather than 2.11bsd's *.o files. Only thing is it's a cross linker, the code is quite simple but it won't link big executables from a small address space the way 2.11bsd "ld" would do. Nick On 25/11/2015 10:26 PM, downing.nick(a)gmail.com wrote: > According to this: > > https://archive.org/stream/bitsavers_zilogz80000mmu_742400/z8010_mmu_djvu.t… > You could use only segment 0 and program the code MMU to point segment 0 > to some physical address and the data and stack MMUs to point segment 0 to > some other physical address and you have a split I/D system capable of > running 2.11bsd assuming the compiler knows nothing of segments as you > said. Or, as outlined in my previous posts you can use a compiler that has > 23-bit pointers and understands how to output the high 7 bits as the > segment and the low 16 bits as the logical address each time it > dereferences a pointer (if such a compiler exists) and port 4.3bsd. > > Nick > On 25/11/2015 9:15 PM, "Oliver Lehmann" <lehmann(a)ans-netz.de> wrote: > >> >> Al Kossow <aek(a)bitsavers.org> wrote: >> >> On 11/23/15 12:40 AM, Erik E. Fair wrote: >>> >>>> The undergrads who used that system to learn Unix ported many >>>> a BSD >>>> utility to that system (at least the ones that weren't too RAM-hungry), >>>> starting with BerkNet so we could move files around easily & have >>>> E-mail. >>>> >>>> >>>> >>> That reminds me that you are going to run into utilities that use the >>> overlaying ld that jumps through hoops to get large programs (vi) to run >>> in a 16 bit address space. >>> >> >> Good point. I was also thinking if 2.11 is realy the right choice to use >> for porting. From what I understood: >> >> - The PDP11 can only access up to 64KB address space. >> - 2.11 uses overlay to "show" and "hide" memory into this 64K address >> space. >> >> A Z8001 can address up to 128 segments of 64KB. Means, a single array can >> only be up to 64KB, but you can have 8MB of memory per "section". My >> system >> has 3 MMUs while one is dedicated to the code section and one to the data >> section. So my Code section can be max up to 8MB and my data section can >> be >> up to additional 8MB. Currently my system has up to 5.5MB of RAM (but can >> be upgraded to 16MB easily) >> >> I was thinking if 4.3 BSD would be better to port as the whole overlay >> logic >> which is implemented in 2.11 could make 2.11 maybe to complex to port? I >> mean, all this overlay logic would not be needed for the Z8001 and it >> maybe >> would not even work. (remember - I plan to use my existing SYSIII compiler >> which knows nothing about overlaying!) >> >> What I understand for 4.3 BSD is, that it is meant to run on machines with >> a memory configuration where the memory is adressable in "one block" which >> is of course not true for the Z8001. But - the compiler/assembler handles >> all this adressing for C code so why should it be imported on how the is >> addressed internaly? >> >> Additionaly, my system has NO floating point support. The current SYSIII >> uses a lengthy floating point emulation Assembler Source to "work around" >> that: >> https://github.com/OlliL/P8000/blob/master/WEGA/src/uts/conf/fpe.s >> >> I saw, that 2.11 also has some FPU-emulation. What about 4.3? >> >> Could 4.3 be a better choice? If so - which 4.3 should I use? >> >> In general - I'm looking for a good target OS. It should be not too >> complex (-> "modern") but should provide a TCP/IP stack which is my >> main motivation in porting at all. >> >> >> I'll dig through my archives and see if there was a Z8000 version of pcc >>> in the MIT compiler kit. >>> >> >> That would be great - maybe you could also answer my private mail about >> the Onyx C8002 I sent you some days ago ;) >> The compilers for Z8000 I found so far where either able to address 64K >> only, or where able to only generate COFF-format objects which I can't >> link on my SYSIII... >> >> >> Oliver >> _______________________________________________ >> TUHS mailing list >> TUHS(a)minnie.tuhs.org >> https://minnie.tuhs.org/mailman/listinfo/tuhs >> >

According to this: https://archive.org/stream/bitsavers_zilogz80000mmu_742400/z8010_mmu_djvu.t… You could use only segment 0 and program the code MMU to point segment 0 to some physical address and the data and stack MMUs to point segment 0 to some other physical address and you have a split I/D system capable of running 2.11bsd assuming the compiler knows nothing of segments as you said. Or, as outlined in my previous posts you can use a compiler that has 23-bit pointers and understands how to output the high 7 bits as the segment and the low 16 bits as the logical address each time it dereferences a pointer (if such a compiler exists) and port 4.3bsd.