[TUHS] Porting 2.11 BSD

[TUHS] Porting 2.11 BSD

[Oliver Lehmann]

Hi,

I wanted to at least give it a try porting 2.11 BSD to my Z8001
machine. I din't really wrote any kernel part until now so it
will be a huge learning curve for sure. No idea what my spare
time permits, but... at least I'm planning giving it a try.

I didn't found something like "thing you should do first when
porting 2.11 BSD to another architecture" online so I thought
myself... maybe it would be good to start with the standalone
utilities - more precisely with "disklabel".

Is there a good "HOWTO" for "first things first" as implementing
disklabel seems to require quite some "device work" before the
first "hello world" is there - is there something else which
should be could be done first and does not require so much to
port (the whole disk subsystem on that machine is different
from "usual" disk subsystems as it is handled via a PIO)

Regards, Oliver

[TUHS] Porting 2.11 BSD

[Jacob Goense]

On 2015-11-21 14:00, Oliver Lehmann wrote:
I wanted to at least give it a try porting 2.11 BSD to my Z8001
machine.

Have a look at http://retrobsd.org/ for some recent ports. Also
the good old Porting Unix to the 386 series by Jolitz could be
of help.

[TUHS] Porting 2.11 BSD

[Hellwig Geisse]

Hi Oliver,

On Sa, 2015-11-21 at 14:00 +0100, Oliver Lehmann wrote:
> Is there a good "HOWTO" for "first things first" as implementing
> disklabel seems to require quite some "device work" before the
> first "hello world" is there - is there something else which
> should be could be done first and does not require so much to
> port (the whole disk subsystem on that machine is different
> from "usual" disk subsystems as it is handled via a PIO)

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] Porting 2.11 BSD

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4444 bytes --]

Hellwig made some great tips.

Two other thoughts..

1.) Make sure you understand the low level interrupt mechanism and how
interrupts are turned into real C proceedure calls and back again.   This
is traditionally handled in the *.s file - which in the case of BSD is spit
out by Sam's config program.   So you'll eventuall need to rewrite the
proper stuff for your system - although as a step 1, you'll create it by
hand.

2.) A thought might be to walk before you try running.  The MIT guys took
V6 and the Lions book and rewrote it for the x86.   They use it for their
undergrad OS course.   They have excellent materials and have updated the
V6 code for a modern compiler.     A year ago, I answered a Quora question
about learning the kernel this was:
https://www.quora.com/Which-Linux-kernel-versions-source-code-is-better-for-newbie-to-read/answer/Clem-Cole?__snids__=1310704238&__nsrc__=1&__filter__=all


The most relevant part I have cut/pasted here:

 "a modern take on a classic" - the course if being offered this fall at
the URL:   6.828 / Fall 2014 <http://pdos.csail.mit.edu/6.828/2014/xv6.html>

The latest xv6 source is available via
        git clone git://pdos.csail.mit.edu/xv6/xv6.git
<http://git//pdos.csail.mit.edu/xv6/xv6.git>

Tools are can be found at:   6.828 / Fall 2014
<http://pdos.csail.mit.edu/6.828/2014/tools.html>

Using the MIT course or the Lion's text will teach how the kernel works and
how a user program interacts with it.   IMO: Lion's commentary is super and
100% of the source is there to read and ponder.  Please remember that
generations of the best kernel hackers started with this document (although
some of us predate it - but when I saw it I made a copy).

​My point is gett​ing the V6 kernel running on your HW.  The take your
learning from that and try a BSD kernel.   The hardest part of the ports
will be common and the V6 kernel is going to be a lot easier to get
working, because it small and simple.


No you went get networking at all the cool BSD features, but if the idea to
learn how to do it, start small scale as the MythBuster's guys always do ;-)

Clem

On Sat, Nov 21, 2015 at 9:03 AM, Hellwig Geisse <hellwig.geisse at mni.thm.de>
wrote:

> Hi Oliver,
>
> On Sa, 2015-11-21 at 14:00 +0100, Oliver Lehmann wrote:
> > Is there a good "HOWTO" for "first things first" as implementing
> > disklabel seems to require quite some "device work" before the
> > first "hello world" is there - is there something else which
> > should be could be done first and does not require so much to
> > port (the whole disk subsystem on that machine is different
> > from "usual" disk subsystems as it is handled via a PIO)
>
> 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 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/20151121/e290c0ee/attachment.html>

[TUHS] Porting 2.11 BSD

[Random832]

On Sat, Nov 21, 2015, at 08:00, Oliver Lehmann wrote:
> I wanted to at least give it a try porting 2.11 BSD to my Z8001
> machine.

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

[TUHS] Porting 2.11 BSD

[Michael Kerpan]

Sadly, I haven't ever seen much in the realm of Z8001-based systems
emulation. There's an emulator for something called the P8000, but
that's about it. Even the Olivetti M20 (probably the most
widely-deployed Z8001 system in real life) lacks an emulator.

Mike

On Sat, Nov 21, 2015 at 7:13 PM, Random832 <random832 at fastmail.us> wrote:
> On Sat, Nov 21, 2015, at 08:00, Oliver Lehmann wrote:
>> I wanted to at least give it a try porting 2.11 BSD to my Z8001
>> machine.
>
> Is there an emulator for this system so people without one can follow
> along?
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] Porting 2.11 BSD

[Jonathan Gevaryahu]

There is a functional emulator of the Olivetti M20 in the MESS emulator, 
now a subpart of MAME (same executable for both).
http://www.mamedev.org/

On 11/21/2015 7:27 PM, Michael Kerpan wrote:
> Sadly, I haven't ever seen much in the realm of Z8001-based systems
> emulation. There's an emulator for something called the P8000, but
> that's about it. Even the Olivetti M20 (probably the most
> widely-deployed Z8001 system in real life) lacks an emulator.
>
> Mike
>
> On Sat, Nov 21, 2015 at 7:13 PM, Random832 <random832 at fastmail.us> wrote:
>> On Sat, Nov 21, 2015, at 08:00, Oliver Lehmann wrote:
>>> I wanted to at least give it a try porting 2.11 BSD to my Z8001
>>> machine.
>> Is there an emulator for this system so people without one can follow
>> along?
>> _______________________________________________
>> 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
>
>


-- 
Jonathan Gevaryahu AKA Lord Nightmare
jgevaryahu at gmail.com
jgevaryahu at hotmail.com

[TUHS] Porting 2.11 BSD

[William Pechter]

Random832 wrote:
> Is there an emulator for this system so people without one can follow
> along?
I found this for a Z8000 System III box.  It was an East German dual cpu 
Z80/Z8001 clone box running SysIII -- perhaps this may be of some help 
as a comparison.

Emulator
http://www.knothusa.net/Home.php

More P8000 info
http://www.pofo.de/P8000/
Z8000 docs
http://www.pofo.de/P8000/  (there's some Zilog System 8000 Z8000 Zeus 
info here as well.

-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-gmail.com  http://xkcd.com/705/

[TUHS] Porting 2.11 BSD

[Oliver Lehmann]

William Pechter <pechter at gmail.com> wrote:


> I found this for a Z8000 System III box.  It was an East German dual  
> cpu Z80/Z8001 clone box running SysIII -- perhaps this may be of  
> some help as a comparison.

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


> Emulator
> http://www.knothusa.net/Home.php

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.... ;)


> More P8000 info
> http://www.pofo.de/P8000/

> Z8000 docs
> http://www.pofo.de/P8000/  (there's some Zilog System 8000 Z8000  
> Zeus info here as well.

Cool... you found my page ;)

[TUHS] Porting 2.11 BSD

[William Pechter]

Oliver Lehmann wrote:
>
> William Pechter <pechter at gmail.com> wrote:
>
>
>> I found this for a Z8000 System III box. It was an East German dual 
>> cpu Z80/Z8001 clone box running SysIII -- perhaps this may be of some 
>> help as a comparison.
>
> 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
>
>
>> Emulator
>> http://www.knothusa.net/Home.php
>
> 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.... ;)
>
>
>> More P8000 info
>> http://www.pofo.de/P8000/
>
>> Z8000 docs
>> http://www.pofo.de/P8000/  (there's some Zilog System 8000 Z8000 Zeus 
>> info here as well.
>
> Cool... you found my page ;)
>
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

Nice site... I worked for DEC back in the 80's and I ended up installing 
Exxon Office Systems'  Vaxes which
they used for software development for the Zeus systems.  Some employees 
were from the Berkeley area
and New Jersey, even Princeton, seemed to be culture shock.

The computer room was directly under the flight path to the little 
Princeton Airport and the rented building
wasn't really designed for those machines.  The place was small offices 
for insurance sales, accounting,
lawyers and such.   They later moved over to a new building on the RT 1 
corridor which had a real computer room after they had all the 
electricity put in for the 11/780.

They moved from California to Princeton, New Jersey back around '81 or 
so and were gone shortly
when Exxon closed them down in '84.

I think they were the first Ultrix32 box I saw in my lifetime... which 
was much more AT&T focused working
for DEC in New Jersey.  By 92 or so I was doing SunOS 4.1.3 at work and 
FreeBSD/NetBSD at home.

I never could figure out how AT&T kept the miserable self-destructive 
Unix Filesystem alive with it's 13 character filename limit and no 
symbolic links.  SysVR4 finally showed some promise, and I even
thought they had a winner with their object-oriented management tools to 
manage getty's and printers and such.

FACE, the SVR4 character terminal graphic utilities were not too bad. 
You could finally run the whole system without vi-ing configurations -- 
kind of like a pre-SUSE  Yast that used the button labels on function keys.
Perkin-Elmer/Concurrent had a similar thing in Xelos (SVR2) on their 
block-mode capable 1251 and 6312
terminals...  That was the thing in the 80's -- menu or function button 
Unix sysadmin screens.

AT&T killed their future OEM's by allowing the OSF/USL split to happen 
over their Sun investment
and promise that Sun would get the new Unix before everyone else. The 
Unix wars made sure there
wouldn't be one binary/source compatible version of Unix across all 
hardware platforms.

When I started to work with Solaris2 I was amazed as to how different it 
seemed than straight SVR4 and
I helped write Pyramid's training for their OS/x SVR4 MIPS R3000 product.

Had AT&T been more willing to supply the code equally and get out of the 
way you wouldn't have had
the waste of the NCR purchase later after the less than stellar 3b and 
3b2 sales of the late 80's.

To bring this back to the Z8000 ZEUS and Zilog:

Pyramid was an OEM for AT&T and AT&T was to sell Pyramid boxes to the US 
Government to replace
the Z8000 Zilog Zeus machines which were used by the IRS.  I think this 
all fell apart after the
NCR purchase.  My job kind of went with it as Pyramid went through a 
downward sales spiral
as AT&T stopped buying MIServers and the MIPS MIServer-S line (R3000 
SVR4) multicpu boxes.

Bill

-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-gmail.com  http://xkcd.com/705/

[TUHS] Porting 2.11 BSD

[Nick Downing]

What I would do personally is:
1. Run in an emulator such as the ones linked above, it will be heaps
easier than the bare hardware. Need not emulate your particular machine.
Preferably would emulate your Z800x CPU but even that isn't 100% essential.
2. Get yourself a 2.11bsd filesystem, best way might be install or download
2.11bsd for PDP-11 and run in simh. Hopefully the simulated disk is in raw
form so it can be moved between simh and your emulator, otherwise you could
modify one of the emulators or convert the file somehow.
3. Figure out a way of copying between your real disk and your simulated
disk. For example run an sshd under simh and "scp" to your disk. Or mount
your file as a tape and "dd" it over to your disk with correct name. Or
whatever, there could be existing utilities that can do this. (Kind of like
msdosutils on linux has a userspace implementation of vfat and can do
simple things to vfat formatted floppies or disk images).
4. Figure out how the bootstrap works and translate it to Z800x assembly.
In essence the boot sector will load the next 16 or so sectors into memory
and jump to it. Those 16 sectors contain a cutdown version of a 2.11bsd
filesystem mounted rdonly, enough to read superblock, locate inode table,
maybe locate /boot/kernel and then load and jump to it. I can send some
examples in Z80 code for my project. Or I can take a look in 2.11bsd and
tell you how this works.
5. You now have a cross assembler and linker and a development system. Get
C working too. Compile the kernel with as many things as possible disabled
-- no disk, network, etc. Find a way for dprintf() or similar to work --
such as polled output to a serial port, or even just defining an unused
Z8001 opcode to putchar() whatever is in R1. No need for any finesse here.
6. In the first line of the kernel startup put a dprintf of "hello world".
Copy resulting kernel to /boot/kernel or whatever it is supposed to be
called. Put similar diagnostics in your bootstrap. Run and debug until your
messages come out. Then gradually step through the kernel initialization
and main loop fixing things as you go. Eventually add more subsystems.

Nick
On 22/11/2015 1:14 PM, "William Pechter" <pechter at gmail.com> wrote:

> Oliver Lehmann wrote:
>
>>
>> William Pechter <pechter at gmail.com> wrote:
>>
>>
>> I found this for a Z8000 System III box. It was an East German dual cpu
>>> Z80/Z8001 clone box running SysIII -- perhaps this may be of some help as a
>>> comparison.
>>>
>>
>> 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
>>
>>
>> Emulator
>>> http://www.knothusa.net/Home.php
>>>
>>
>> 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.... ;)
>>
>>
>> More P8000 info
>>> http://www.pofo.de/P8000/
>>>
>>
>> Z8000 docs
>>> http://www.pofo.de/P8000/  (there's some Zilog System 8000 Z8000 Zeus
>>> info here as well.
>>>
>>
>> Cool... you found my page ;)
>>
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>
>
> Nice site... I worked for DEC back in the 80's and I ended up installing
> Exxon Office Systems'  Vaxes which
> they used for software development for the Zeus systems.  Some employees
> were from the Berkeley area
> and New Jersey, even Princeton, seemed to be culture shock.
>
> The computer room was directly under the flight path to the little
> Princeton Airport and the rented building
> wasn't really designed for those machines.  The place was small offices
> for insurance sales, accounting,
> lawyers and such.   They later moved over to a new building on the RT 1
> corridor which had a real computer room after they had all the electricity
> put in for the 11/780.
>
> They moved from California to Princeton, New Jersey back around '81 or so
> and were gone shortly
> when Exxon closed them down in '84.
>
> I think they were the first Ultrix32 box I saw in my lifetime... which was
> much more AT&T focused working
> for DEC in New Jersey.  By 92 or so I was doing SunOS 4.1.3 at work and
> FreeBSD/NetBSD at home.
>
> I never could figure out how AT&T kept the miserable self-destructive Unix
> Filesystem alive with it's 13 character filename limit and no symbolic
> links.  SysVR4 finally showed some promise, and I even
> thought they had a winner with their object-oriented management tools to
> manage getty's and printers and such.
>
> FACE, the SVR4 character terminal graphic utilities were not too bad. You
> could finally run the whole system without vi-ing configurations -- kind of
> like a pre-SUSE  Yast that used the button labels on function keys.
> Perkin-Elmer/Concurrent had a similar thing in Xelos (SVR2) on their
> block-mode capable 1251 and 6312
> terminals...  That was the thing in the 80's -- menu or function button
> Unix sysadmin screens.
>
> AT&T killed their future OEM's by allowing the OSF/USL split to happen
> over their Sun investment
> and promise that Sun would get the new Unix before everyone else. The Unix
> wars made sure there
> wouldn't be one binary/source compatible version of Unix across all
> hardware platforms.
>
> When I started to work with Solaris2 I was amazed as to how different it
> seemed than straight SVR4 and
> I helped write Pyramid's training for their OS/x SVR4 MIPS R3000 product.
>
> Had AT&T been more willing to supply the code equally and get out of the
> way you wouldn't have had
> the waste of the NCR purchase later after the less than stellar 3b and 3b2
> sales of the late 80's.
>
> To bring this back to the Z8000 ZEUS and Zilog:
>
> Pyramid was an OEM for AT&T and AT&T was to sell Pyramid boxes to the US
> Government to replace
> the Z8000 Zilog Zeus machines which were used by the IRS.  I think this
> all fell apart after the
> NCR purchase.  My job kind of went with it as Pyramid went through a
> downward sales spiral
> as AT&T stopped buying MIServers and the MIPS MIServer-S line (R3000 SVR4)
> multicpu boxes.
>
> Bill
>
> --
> Digital had it then.  Don't you wish you could buy it now!
> pechter-at-gmail.com  http://xkcd.com/705/
>
> _______________________________________________
> 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/20151123/7a4fe56c/attachment.html>

[TUHS] Porting 2.11 BSD

[Oliver Lehmann]

Hi Nick,

first - thank you very much the time you spent writing!

Thing is - yes - there is a P8000 emulator but it has some bugs which may
render the assembler not to produce code and so on. I feel better to use
the original hardware and my SYSIII to compile the stuff I need.

Using a harddisk image made by simh is a great idea. Porting disklabel,
mkfs and so on first would be a huge task before it works. But with the
way you proposed I would see much earlier "something" running on the
system.

Getting data from and to the current SYSIII is not an issue as I have kermit
on it and can transfer files via serial without any problem.

Getting a filesystem to the "BSD disk" for the system should also be easy
as I already build a WDC-Controller emulation hardware which uses a SD-Card
or an IDE harddrive as datastorage but behaves 100% compatible to the P8000
like the original Controller.
Using an SDCard makes it kinda easy to just dd the filesystem to/from it.

The current SYSIII Firmware, Boot and Kernel sources are as good as 100%
available which I guess would it make it a lot easier to port it to boot
from a BSD Filesystem.

The current boot process on the SYSIII is "rather simple". The firmware has
some basic functionality to boot from the harddisk. It just loads block 0
of disk 1 with a length of 200 byte into Address %8000 and executes whatever
is on that address after it was loaded

https://github.com/OlliL/P8000/blob/master/firmware/MON16/p.boot.s
(See line 609-636 - sorry for the german comments)

I definitly do not want to change the firmware in any way as I want to make
a "drop in replacement" to the current SYSIII - so no firmware modifications.
I wonder this would mean to not use disklabels for example. I guess disklabels
are stored in block 0 which would make it incompatible with the current
boot0 loading which is expected to be in block 0 - right?


Then there is currently the boot0 loader which is currently on block 0 of
the harddisk which is now executed.

This one is also implemented in ASM and is now able to understand the
filesystem. It is configured by default to open again block 0, reads a
defined inode and searches for the secondary bootloader "boot".

https://github.com/OlliL/P8000/blob/master/WEGA/src/cmd/BOOT0/boot0.md.s
(See line 128 - 277)

The secondary bootloader is implemented in C and is the first program, able
to execute segmented code like the kernel:

https://github.com/OlliL/P8000/blob/master/WEGA/src/uts/conf/boot.c


I guess, I have to port the primary bootloader first to be able to understand
UFS/FFS as it is probably different than the current SYSIII-FS and the primary
bootloader needs to "understand" it to look for the secondary bootloader.
I plan to "reuse" the current primary bootloader and just change the
filesystem code. I guess this should be enough.

The secondary bootloader is hopefully also implemented in C in 2.11  
BSD (didn't
looked it up yet) So I can modify it to understand Zilogs s.out format instead
of BSDs a.out format.
This is vital as the whole toolchain needs to be taken over to BSD as there is
just no other toolchain available compiling, assembling and linking  
Z8001 code.
I also have important binaries with no source code which need to be able to
run in BSD as well as they did in SYSIII (Z80-RIO-Emulator, CP/M-Emulator,
Cross-Assemblers for Z8, Z80). So making BSD able to understand the s.out
format of SYSIII is vital as I'm only able to compile code in s.out format
the first place.

So to summarize it... The first thing would be:

0. get simh up and running
1. get a 2.11-BSD filesystem onto a (new) SD-Card
2. modify the primary bootloader to read the UFS-filesystem
3. write a secondary bootloader which only does "hello world"
4. place the secondary bootloader onto that filesystem
5. boot it
6. fix it until it works
7. create a /unix kernel which does a "hello world"
8. modify the secondary bootloader until it is able to load
    the kernel.

What do you think?

- Is a current FreeBSD still able to read/write 2.11 BSD disks?
- I wonder how much difference the SYSIII-FS and UFS has regarding to the
   primary bootloader (boot0.md.s lines 128-158 searches for "boot").

Regards, Oliver

[TUHS] Porting 2.11 BSD

[Erik E. Fair]

With regard to cooperating with extant system firmware, this is a problem that
NetBSD has on almost every platform it runs on (and it runs on many). You can
find many examples of how to cooperate or work-around firmware bootloaders in
our BSD-licensed codebase:

	http://www.netbsd.org/

Further, we've got a standard secondary booter framework, though we retired
a.out quite a few releases ago. See src/sys/arch/*/stand (for "stand-alone")
in our source repository. Or grab the source tarballs as you see fit.

Some of this is deja vu for me: I was a co-founder of the "Undergraduate
Computing Facility" (UCF) at UCB in 1982, and helped set up the Z8002 based
Onyx system in B50 Evans Hall that was our first and for a long time, only,
computer. 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.

	good luck,

	Erik <fair at netbsd.org>

[TUHS] Porting 2.11 BSD

[Al Kossow]

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.

I'll dig through my archives and see if there was a Z8000 version of pcc
in the MIT compiler kit.

[TUHS] Porting 2.11 BSD

[Oliver Lehmann]

Al Kossow <aek at 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] Porting 2.11 BSD

[Nick Downing]

According to this:
https://archive.org/stream/bitsavers_zilogz80000mmu_742400/z8010_mmu_djvu.txt
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 at ans-netz.de> wrote:

>
> Al Kossow <aek at 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 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/20151125/8690acff/attachment.html>

[TUHS] Porting 2.11 BSD

[Nick Downing]

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 at gmail.com wrote:

> According to this:
>
> https://archive.org/stream/bitsavers_zilogz80000mmu_742400/z8010_mmu_djvu.txt
> 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 at ans-netz.de> wrote:
>
>>
>> Al Kossow <aek at 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 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/20151125/d8366ed9/attachment.html>

[TUHS] Porting 2.11 BSD

[Oliver Lehmann]

Hi Nick,

why can't I just "reuse" my SYSIII linker which has all the support for
segmented and unsegmented binaries what a.out does not support. The Zilog
format is called s.out.

I thought I could teach the BSD kernel how to execute s.out binaries
(how to execute them is already there in my SYSIII sources) and I could
just reuse the ld and sld (for segmented programms) from my SYSIII?

Please check the header for all the magics currently supported.
https://github.com/OlliL/P8000/blob/master/WEGA/src/head/s.out.h

So why should I use the COFF assembler at all? I plan to do the development
on my current SYSIII-System where I have all the toolchain available....

I still don't see the need of an cross-compiler-environment while I have
the real hardware there capable of compiling my code.... I would just go
and fill up the BSD kernel with functionality, reboot the system, load the
kernel and do that until it goes up and tries to mount rootfs. When
this happens, I'll go and teach my boot0-loader UFS and start creating an
UFS harddisk and put the kernel onto that. Until that point I could even
test all my stuff on my SYSIII-Filesystem. And I guess it will be LOTS of
time until I reach the step when the rootfs is being accessed.

Oliver

Nick Downing <downing.nick at gmail.com> wrote:

> 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 at gmail.com wrote:
>
>> According to this:
>>
>> https://archive.org/stream/bitsavers_zilogz80000mmu_742400/z8010_mmu_djvu.txt
>> 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 at ans-netz.de> wrote:
>>
>>>
>>> Al Kossow <aek at 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 at minnie.tuhs.org
>>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>>
>>

[TUHS] Porting 2.11 BSD

[Nick Downing]

Yes I agree with everything you said, except to say that compile times are
very long and I feel that it is worth the initial effort to set up a cross
toolchain that can be compiled and executed under linux. For 2.11bsd this
involved me line-by-line translating "as" from assembly into C, patching a
PDP-11 floating-point emulator library into cc0, cc1 etc (the compiler
passes) to handle any compile-time constants or calculations without
resorting to IEEE format, and using "cproto" and other tools and #ifdef to
modernize the code to run on a modern gcc and glibc. If you have the source
for "scc", "as" and "ld" this would be well worth doing. If you don't then
it would still be worth running part of your toolchain under emulation as a
cross tool (as I did for "f77" which I was not interested in translating).
Nick
On 25/11/2015 10:56 PM, "Oliver Lehmann" <lehmann at ans-netz.de> wrote:

> Hi Nick,
>
> why can't I just "reuse" my SYSIII linker which has all the support for
> segmented and unsegmented binaries what a.out does not support. The Zilog
> format is called s.out.
>
> I thought I could teach the BSD kernel how to execute s.out binaries
> (how to execute them is already there in my SYSIII sources) and I could
> just reuse the ld and sld (for segmented programms) from my SYSIII?
>
> Please check the header for all the magics currently supported.
> https://github.com/OlliL/P8000/blob/master/WEGA/src/head/s.out.h
>
> So why should I use the COFF assembler at all? I plan to do the development
> on my current SYSIII-System where I have all the toolchain available....
>
> I still don't see the need of an cross-compiler-environment while I have
> the real hardware there capable of compiling my code.... I would just go
> and fill up the BSD kernel with functionality, reboot the system, load the
> kernel and do that until it goes up and tries to mount rootfs. When
> this happens, I'll go and teach my boot0-loader UFS and start creating an
> UFS harddisk and put the kernel onto that. Until that point I could even
> test all my stuff on my SYSIII-Filesystem. And I guess it will be LOTS of
> time until I reach the step when the rootfs is being accessed.
>
> Oliver
>
> Nick Downing <downing.nick at gmail.com> wrote:
>
> 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 at gmail.com wrote:
>>
>> According to this:
>>>
>>>
>>> https://archive.org/stream/bitsavers_zilogz80000mmu_742400/z8010_mmu_djvu.txt
>>> 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 at ans-netz.de> wrote:
>>>
>>>
>>>> Al Kossow <aek at 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 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/20151125/bba5791c/attachment.html>

[TUHS] Porting 2.11 BSD

[Oliver Lehmann]

Hi Nick,


Nick Downing <downing.nick at gmail.com> wrote:

> According to this:
> https://archive.org/stream/bitsavers_zilogz80000mmu_742400/z8010_mmu_djvu.txt
> 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.

I have two compilers ;)

One compiler which creates "unsegmented binaries". The assembler code which
is generated only uses 16bit pointer addresses (r0-r15) and only works on
segment 0.

This compiler is for example used to compile the boot loaders and standalone
utilities iirc and other "small" binaries on my SYSIII.

http://pofo.de/cgi-bin/man.cgi?query=cc


There is also a "segmented compiler" which uses the 32bit registers (rr0-rr14)
to store the pointer adresses.
It is currently used for compiling the SYSIII kernel (which is much  
bigger than
the 2.11 BSD kernel I saw) and all other "to big" binaries.

http://pofo.de/cgi-bin/man.cgi?query=scc

And this would mean that "such a compiler exists" (referencing to your
mail) and I could or should port 4.3 BSD?

[TUHS] Porting 2.11 BSD

[Nick Downing]

Yeah, I would definitely go for 4.3bsd using scc in that case. The 64 kbyte
limitation of 2.11bsd using cc will cause continual hassles, even with
split I/D which relaxes things a bit (for example the issue of linking big
executables and the workarounds employed by 2.11bsd "ld"). You might also
consider 4.4bsdlite if you want to be able to release your work, you could
grab any missing pieces that aren't in assembly from 386bsd etc.
Nick
On 25/11/2015 10:51 PM, "Oliver Lehmann" <lehmann at ans-netz.de> wrote:

> Hi Nick,
>
>
> Nick Downing <downing.nick at gmail.com> wrote:
>
> According to this:
>>
>> https://archive.org/stream/bitsavers_zilogz80000mmu_742400/z8010_mmu_djvu.txt
>> 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.
>>
>
> I have two compilers ;)
>
> One compiler which creates "unsegmented binaries". The assembler code which
> is generated only uses 16bit pointer addresses (r0-r15) and only works on
> segment 0.
>
> This compiler is for example used to compile the boot loaders and
> standalone
> utilities iirc and other "small" binaries on my SYSIII.
>
> http://pofo.de/cgi-bin/man.cgi?query=cc
>
>
> There is also a "segmented compiler" which uses the 32bit registers
> (rr0-rr14)
> to store the pointer adresses.
> It is currently used for compiling the SYSIII kernel (which is much bigger
> than
> the 2.11 BSD kernel I saw) and all other "to big" binaries.
>
> http://pofo.de/cgi-bin/man.cgi?query=scc
>
> And this would mean that "such a compiler exists" (referencing to your
> mail) and I could or should port 4.3 BSD?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151125/4073ca48/attachment.html>