[TUHS] System III - TCP/IP

[TUHS] System III - TCP/IP

[Oliver Lehmann]

Hi,

i have an old Z8001 based SysIII variant and I would love to have
TCP/IP on it (SLIP first, later with a homebrew ethernet device).

I wonder if someone ever saw TCP/IP available on a System III?

I have lets say 90% of the kernel running on it as source
available and I started digging in the available 4.2 BSD sources.

It looks like there would be much to do to hack in TCP/IP on my
own (no IPC, no Net, no PTY, no....).

I got K5JB running (userland TCP/IP implementation) after I fixed
some C code because the C Compiler available on the system is.....
kinda limited.

telnetd is of course not working as there are no pseudo-teletypes
on this SYSIII. At least I got ping, echoping and ftpd up and
running via SLIP

(10.1.1.2 is my SysIII box:)

# ping -c3 10.1.1.2
PING 10.1.1.2 (10.1.1.2): 56 data bytes
64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms
64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms
64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms

--- 10.1.1.2 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms
# ftp 10.1.1.2
Connected to 10.1.1.2.
220  FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991
Name (10.1.1.2:root): test
331 Enter PASS command
Password:
230 Logged in
ftp> get sa.timer
local: sa.timer remote: sa.timer
500 Unknown command
500 Unknown command
200 Port command okay
150 Opening data connection for RETR sa.timer
   2571       0.53 KB/s
226 File sent OK
2571 bytes received in 00:05 (0.48 KB/s)
ftp> get wega
local: wega remote: wega
200 Port command okay
150 Opening data connection for RETR wega
  98723       0.51 KB/s
226 File sent OK
98723 bytes received in 03:05 (0.51 KB/s)
ftp> exit
221 Goodbye!
#

So I wonder if someone got anything SYSIII -> Net/TCP/IP related
which could help me in any way to get a SYSIII kernel capable of
TCP/IP and PTYs to get a telnetd up and running via SLIP is my
first goal.

Regards,
Oliver

[TUHS] System III - TCP/IP

[Larry McVoy]

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:
> Hi,
> 
> i have an old Z8001 based SysIII variant and I would love to have
> TCP/IP on it (SLIP first, later with a homebrew ethernet device).
> 
> I wonder if someone ever saw TCP/IP available on a System III?
> 
> I have lets say 90% of the kernel running on it as source
> available and I started digging in the available 4.2 BSD sources.
> 
> It looks like there would be much to do to hack in TCP/IP on my
> own (no IPC, no Net, no PTY, no....).
> 
> I got K5JB running (userland TCP/IP implementation) after I fixed
> some C code because the C Compiler available on the system is.....
> kinda limited.
> 
> telnetd is of course not working as there are no pseudo-teletypes
> on this SYSIII. At least I got ping, echoping and ftpd up and
> running via SLIP
> 
> (10.1.1.2 is my SysIII box:)
> 
> # ping -c3 10.1.1.2
> PING 10.1.1.2 (10.1.1.2): 56 data bytes
> 64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms
> 64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms
> 64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms
> 
> --- 10.1.1.2 ping statistics ---
> 3 packets transmitted, 3 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms
> # ftp 10.1.1.2
> Connected to 10.1.1.2.
> 220  FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991
> Name (10.1.1.2:root): test
> 331 Enter PASS command
> Password:
> 230 Logged in
> ftp> get sa.timer
> local: sa.timer remote: sa.timer
> 500 Unknown command
> 500 Unknown command
> 200 Port command okay
> 150 Opening data connection for RETR sa.timer
>   2571       0.53 KB/s
> 226 File sent OK
> 2571 bytes received in 00:05 (0.48 KB/s)
> ftp> get wega
> local: wega remote: wega
> 200 Port command okay
> 150 Opening data connection for RETR wega
>  98723       0.51 KB/s
> 226 File sent OK
> 98723 bytes received in 03:05 (0.51 KB/s)
> ftp> exit
> 221 Goodbye!
> #
> 
> So I wonder if someone got anything SYSIII -> Net/TCP/IP related
> which could help me in any way to get a SYSIII kernel capable of
> TCP/IP and PTYs to get a telnetd up and running via SLIP is my
> first goal.
> 
> Regards,
> Oliver
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] System III - TCP/IP

[Cory Smelosky]

Any ideas if any of this would work on Sys III for VAX?

(Or the technically opened PDP-11 that includes VAX)

Sent from my iPhone

> On Nov 7, 2015, at 11:20, Larry McVoy <lm at mcvoy.com> wrote:
> 
> 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:
>> Hi,
>> 
>> i have an old Z8001 based SysIII variant and I would love to have
>> TCP/IP on it (SLIP first, later with a homebrew ethernet device).
>> 
>> I wonder if someone ever saw TCP/IP available on a System III?
>> 
>> I have lets say 90% of the kernel running on it as source
>> available and I started digging in the available 4.2 BSD sources.
>> 
>> It looks like there would be much to do to hack in TCP/IP on my
>> own (no IPC, no Net, no PTY, no....).
>> 
>> I got K5JB running (userland TCP/IP implementation) after I fixed
>> some C code because the C Compiler available on the system is.....
>> kinda limited.
>> 
>> telnetd is of course not working as there are no pseudo-teletypes
>> on this SYSIII. At least I got ping, echoping and ftpd up and
>> running via SLIP
>> 
>> (10.1.1.2 is my SysIII box:)
>> 
>> # ping -c3 10.1.1.2
>> PING 10.1.1.2 (10.1.1.2): 56 data bytes
>> 64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms
>> 64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms
>> 64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms
>> 
>> --- 10.1.1.2 ping statistics ---
>> 3 packets transmitted, 3 packets received, 0.0% packet loss
>> round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms
>> # ftp 10.1.1.2
>> Connected to 10.1.1.2.
>> 220  FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991
>> Name (10.1.1.2:root): test
>> 331 Enter PASS command
>> Password:
>> 230 Logged in
>> ftp> get sa.timer
>> local: sa.timer remote: sa.timer
>> 500 Unknown command
>> 500 Unknown command
>> 200 Port command okay
>> 150 Opening data connection for RETR sa.timer
>>  2571       0.53 KB/s
>> 226 File sent OK
>> 2571 bytes received in 00:05 (0.48 KB/s)
>> ftp> get wega
>> local: wega remote: wega
>> 200 Port command okay
>> 150 Opening data connection for RETR wega
>> 98723       0.51 KB/s
>> 226 File sent OK
>> 98723 bytes received in 03:05 (0.51 KB/s)
>> ftp> exit
>> 221 Goodbye!
>> #
>> 
>> So I wonder if someone got anything SYSIII -> Net/TCP/IP related
>> which could help me in any way to get a SYSIII kernel capable of
>> TCP/IP and PTYs to get a telnetd up and running via SLIP is my
>> first goal.
>> 
>> Regards,
>> Oliver
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
> 
> -- 
> ---
> Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] System III - TCP/IP

[Clem Cole]

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

> 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:
> > Hi,
> >
> > i have an old Z8001 based SysIII variant and I would love to have
> > TCP/IP on it (SLIP first, later with a homebrew ethernet device).
> >
> > I wonder if someone ever saw TCP/IP available on a System III?
> >
> > I have lets say 90% of the kernel running on it as source
> > available and I started digging in the available 4.2 BSD sources.
> >
> > It looks like there would be much to do to hack in TCP/IP on my
> > own (no IPC, no Net, no PTY, no....).
> >
> > I got K5JB running (userland TCP/IP implementation) after I fixed
> > some C code because the C Compiler available on the system is.....
> > kinda limited.
> >
> > telnetd is of course not working as there are no pseudo-teletypes
> > on this SYSIII. At least I got ping, echoping and ftpd up and
> > running via SLIP
> >
> > (10.1.1.2 is my SysIII box:)
> >
> > # ping -c3 10.1.1.2
> > PING 10.1.1.2 (10.1.1.2): 56 data bytes
> > 64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms
> > 64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms
> > 64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms
> >
> > --- 10.1.1.2 ping statistics ---
> > 3 packets transmitted, 3 packets received, 0.0% packet loss
> > round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms
> > # ftp 10.1.1.2
> > Connected to 10.1.1.2.
> > 220  FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991
> > Name (10.1.1.2:root): test
> > 331 Enter PASS command
> > Password:
> > 230 Logged in
> > ftp> get sa.timer
> > local: sa.timer remote: sa.timer
> > 500 Unknown command
> > 500 Unknown command
> > 200 Port command okay
> > 150 Opening data connection for RETR sa.timer
> >   2571       0.53 KB/s
> > 226 File sent OK
> > 2571 bytes received in 00:05 (0.48 KB/s)
> > ftp> get wega
> > local: wega remote: wega
> > 200 Port command okay
> > 150 Opening data connection for RETR wega
> >  98723       0.51 KB/s
> > 226 File sent OK
> > 98723 bytes received in 03:05 (0.51 KB/s)
> > ftp> exit
> > 221 Goodbye!
> > #
> >
> > So I wonder if someone got anything SYSIII -> Net/TCP/IP related
> > which could help me in any way to get a SYSIII kernel capable of
> > TCP/IP and PTYs to get a telnetd up and running via SLIP is my
> > first goal.
> >
> > Regards,
> > Oliver
> > _______________________________________________
> > TUHS mailing list
> > TUHS at minnie.tuhs.org
> > https://minnie.tuhs.org/mailman/listinfo/tuhs
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
> _______________________________________________
> 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/20151107/95db42d9/attachment.html>

[TUHS] System III - TCP/IP

[Cory Smelosky]

Sent from my iPhone

> On Nov 7, 2015, at 13:28, Clem Cole <clemc at ccc.com> wrote:
> 
> 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).

I have 4.1a and c source I think.

> 
> 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 at mcvoy.com> wrote:
>> 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:
>> > Hi,
>> >
>> > i have an old Z8001 based SysIII variant and I would love to have
>> > TCP/IP on it (SLIP first, later with a homebrew ethernet device).
>> >
>> > I wonder if someone ever saw TCP/IP available on a System III?
>> >
>> > I have lets say 90% of the kernel running on it as source
>> > available and I started digging in the available 4.2 BSD sources.
>> >
>> > It looks like there would be much to do to hack in TCP/IP on my
>> > own (no IPC, no Net, no PTY, no....).
>> >
>> > I got K5JB running (userland TCP/IP implementation) after I fixed
>> > some C code because the C Compiler available on the system is.....
>> > kinda limited.
>> >
>> > telnetd is of course not working as there are no pseudo-teletypes
>> > on this SYSIII. At least I got ping, echoping and ftpd up and
>> > running via SLIP
>> >
>> > (10.1.1.2 is my SysIII box:)
>> >
>> > # ping -c3 10.1.1.2
>> > PING 10.1.1.2 (10.1.1.2): 56 data bytes
>> > 64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms
>> > 64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms
>> > 64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms
>> >
>> > --- 10.1.1.2 ping statistics ---
>> > 3 packets transmitted, 3 packets received, 0.0% packet loss
>> > round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms
>> > # ftp 10.1.1.2
>> > Connected to 10.1.1.2.
>> > 220  FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991
>> > Name (10.1.1.2:root): test
>> > 331 Enter PASS command
>> > Password:
>> > 230 Logged in
>> > ftp> get sa.timer
>> > local: sa.timer remote: sa.timer
>> > 500 Unknown command
>> > 500 Unknown command
>> > 200 Port command okay
>> > 150 Opening data connection for RETR sa.timer
>> >   2571       0.53 KB/s
>> > 226 File sent OK
>> > 2571 bytes received in 00:05 (0.48 KB/s)
>> > ftp> get wega
>> > local: wega remote: wega
>> > 200 Port command okay
>> > 150 Opening data connection for RETR wega
>> >  98723       0.51 KB/s
>> > 226 File sent OK
>> > 98723 bytes received in 03:05 (0.51 KB/s)
>> > ftp> exit
>> > 221 Goodbye!
>> > #
>> >
>> > So I wonder if someone got anything SYSIII -> Net/TCP/IP related
>> > which could help me in any way to get a SYSIII kernel capable of
>> > TCP/IP and PTYs to get a telnetd up and running via SLIP is my
>> > first goal.
>> >
>> > Regards,
>> > Oliver
>> > _______________________________________________
>> > TUHS mailing list
>> > TUHS at minnie.tuhs.org
>> > https://minnie.tuhs.org/mailman/listinfo/tuhs
>> 
>> --
>> ---
>> Larry McVoy                  lm at mcvoy.com             http://www.mcvoy.com/lm
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151107/29e91783/attachment.html>

[TUHS] System III - TCP/IP

[Oliver Lehmann]

Clem Cole <clemc at ccc.com> wrote:

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

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


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

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

[TUHS] System III - TCP/IP

[Derek Fawcus]

On Sat, Nov 07, 2015 at 11:13:38pm +0100, Oliver Lehmann wrote:
> 
> 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)

Older versions of gcc (around 3.3/3.4) supported the z8000 family,  so you
could try using it to make things easier.  Have a look here:
  http://www.z80ne.com/m20/sections/download/z8kgcc/z8kgcc.html
which seems to be a version supporting segments - the '-mz8001' switch.

DF

[TUHS] System III - TCP/IP

[Nick Downing]

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 at employees.org>
wrote:

> On Sat, Nov 07, 2015 at 11:13:38pm +0100, Oliver Lehmann wrote:
> >
> > 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)
>
> Older versions of gcc (around 3.3/3.4) supported the z8000 family,  so you
> could try using it to make things easier.  Have a look here:
>   http://www.z80ne.com/m20/sections/download/z8kgcc/z8kgcc.html
> which seems to be a version supporting segments - the '-mz8001' switch.
>
> DF
> _______________________________________________
> 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/20151108/c7caac2f/attachment.html>

[TUHS] System III - TCP/IP

[Larry McVoy]

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:
> Any ideas if any of this would work on Sys III for VAX?
> 
> (Or the technically opened PDP-11 that includes VAX)
> 
> Sent from my iPhone
> 
> > On Nov 7, 2015, at 11:20, Larry McVoy <lm at mcvoy.com> wrote:
> > 
> > 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:
> >> Hi,
> >> 
> >> i have an old Z8001 based SysIII variant and I would love to have
> >> TCP/IP on it (SLIP first, later with a homebrew ethernet device).
> >> 
> >> I wonder if someone ever saw TCP/IP available on a System III?
> >> 
> >> I have lets say 90% of the kernel running on it as source
> >> available and I started digging in the available 4.2 BSD sources.
> >> 
> >> It looks like there would be much to do to hack in TCP/IP on my
> >> own (no IPC, no Net, no PTY, no....).
> >> 
> >> I got K5JB running (userland TCP/IP implementation) after I fixed
> >> some C code because the C Compiler available on the system is.....
> >> kinda limited.
> >> 
> >> telnetd is of course not working as there are no pseudo-teletypes
> >> on this SYSIII. At least I got ping, echoping and ftpd up and
> >> running via SLIP
> >> 
> >> (10.1.1.2 is my SysIII box:)
> >> 
> >> # ping -c3 10.1.1.2
> >> PING 10.1.1.2 (10.1.1.2): 56 data bytes
> >> 64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms
> >> 64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms
> >> 64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms
> >> 
> >> --- 10.1.1.2 ping statistics ---
> >> 3 packets transmitted, 3 packets received, 0.0% packet loss
> >> round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms
> >> # ftp 10.1.1.2
> >> Connected to 10.1.1.2.
> >> 220  FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991
> >> Name (10.1.1.2:root): test
> >> 331 Enter PASS command
> >> Password:
> >> 230 Logged in
> >> ftp> get sa.timer
> >> local: sa.timer remote: sa.timer
> >> 500 Unknown command
> >> 500 Unknown command
> >> 200 Port command okay
> >> 150 Opening data connection for RETR sa.timer
> >>  2571       0.53 KB/s
> >> 226 File sent OK
> >> 2571 bytes received in 00:05 (0.48 KB/s)
> >> ftp> get wega
> >> local: wega remote: wega
> >> 200 Port command okay
> >> 150 Opening data connection for RETR wega
> >> 98723       0.51 KB/s
> >> 226 File sent OK
> >> 98723 bytes received in 03:05 (0.51 KB/s)
> >> ftp> exit
> >> 221 Goodbye!
> >> #
> >> 
> >> So I wonder if someone got anything SYSIII -> Net/TCP/IP related
> >> which could help me in any way to get a SYSIII kernel capable of
> >> TCP/IP and PTYs to get a telnetd up and running via SLIP is my
> >> first goal.
> >> 
> >> Regards,
> >> Oliver
> >> _______________________________________________
> >> TUHS mailing list
> >> TUHS at minnie.tuhs.org
> >> https://minnie.tuhs.org/mailman/listinfo/tuhs
> > 
> > -- 
> > ---
> > Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 
> > _______________________________________________
> > TUHS mailing list
> > TUHS at minnie.tuhs.org
> > https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] System III - TCP/IP

[John Cowan]

Larry McVoy scripsit:

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

Bohr and Feynman at Los Alamos, to put it Star Trek-ly.

> I think there were some cool parts, didn't the PWB and DWB
> come form System III?  

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.

> Other than that, what's the System III attraction?

I tend to agree: a thoroughly vanilla release.


-- 
John Cowan          http://www.ccil.org/~cowan        cowan at 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

[TUHS] System III - TCP/IP

[Cory Smelosky]

On Sun, 8 Nov 2015, John Cowan wrote:

> Larry McVoy scripsit:
>
>> 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.)
>
> Bohr and Feynman at Los Alamos, to put it Star Trek-ly.
>
>> I think there were some cool parts, didn't the PWB and DWB
>> come form System III?
>
> 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.
>
>> Other than that, what's the System III attraction?
>
> I tend to agree: a thoroughly vanilla release.
>

What about SysV for PDP-11? ;D

>
>

-- 
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects

[TUHS] System III - TCP/IP

[Oliver Lehmann]

Yeah,

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

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

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

[TUHS] System III - TCP/IP

[Oliver Lehmann]

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

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

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?!

[TUHS] System III - TCP/IP

[Dave Horsfall]

On Sat, 7 Nov 2015, Larry McVoy wrote:

> Just getting back to email (spent the day taking pictures at a hockey 
> tournament).

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 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?

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

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

Indeed.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] System III - TCP/IP

[Steve Nickolas]

On Mon, 9 Nov 2015, Dave Horsfall wrote:

> On Sat, 7 Nov 2015, Larry McVoy wrote:
>
>> Just getting back to email (spent the day taking pictures at a hockey
>> tournament).
>
> 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?

Dragon Ball Z? *shot*

-uso.

[TUHS] System III - TCP/IP

[Nick Downing]

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 at ans-netz.de> wrote:
>
> Nick Downing <downing.nick at gmail.com> wrote:
>
>> 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.
>
>
> 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?!
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] System III - TCP/IP

[Nick Downing]

By the way, there's no reason you can't use your existing Zilog
toolchain. You can just modify the makefiles that come with 2.11BSD to
run the Zilog tools. Or another option might be to write a compiler
driver that acts like "cc" and invokes the Zilog tools as
subprocesses, you have the source for 2.11BSD "cc" so this shouldn't
be too hard to do. Whatever naming convention the Zilog compiler uses,
you could rename the object files to ".o" and the 2.11BSD build system
would work largely unchanged. The most tricky part will be creating
the a.out executables, which are in the simplest case a header of
maybe 18 bytes (depends slightly on the magic number of the executable
since there were a few different compatible versions) followed by the
code and data segments followed by relocation records. To do this, I
am pretty sure I created my own linker, or modified the unix linker
(cannot remember exactly) in order to read the object files from the
IAR Z180 assembler (and I think these were in S-record format that you
mentioned) and create the a.out executables, I also had an extended
a.out format for the large multi-segment executables (including the
kernel), in which I arranged the code into 4 kbyte segments using a
first-fit algorithm. Again I'm happy to give you whatever I have on
this.
Nick


On Mon, Nov 9, 2015 at 12:38 AM, Oliver Lehmann <lehmann at ans-netz.de> wrote:
>
> Nick Downing <downing.nick at gmail.com> wrote:
>
>> 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.
>
>
> 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?!
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

[TUHS] System III - TCP/IP

[Larry McVoy]

On Mon, Nov 09, 2015 at 01:45:18AM +1100, Dave Horsfall wrote:
> On Sat, 7 Nov 2015, Larry McVoy wrote:
> 
> > Just getting back to email (spent the day taking pictures at a hockey 
> > tournament).
> 
> 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'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

[TUHS] System III - TCP/IP

[Oliver Lehmann]

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

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

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

[TUHS] System III - TCP/IP

[Oliver Lehmann]

I hit the send button to fast :(

Oliver Lehmann <lehmann at ans-netz.de> wrote:

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

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.

[TUHS] System III - TCP/IP

[Oliver Lehmann]

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&content-type=text/x-cvsweb-markup



Oliver Lehmann <lehmann at ans-netz.de> wrote:

> I hit the send button to fast :(
>
> Oliver Lehmann <lehmann at ans-netz.de> wrote:
>
>> Nick Downing <downing.nick at gmail.com> wrote:
>>
>>> 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.
>>
>> 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
>
> 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.

[TUHS] System III - TCP/IP

[Oliver Lehmann]

http://cvs.laladev.org/index.html/P8000/WEGA/src/uts/sys/ureg.c?rev=1.9&content-type=text/x-cvsweb-markup

1.9 is the current version 1.1 is the plain SysIII file...


Oliver Lehmann <lehmann at ans-netz.de> wrote:

> 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&content-type=text/x-cvsweb-markup
>
>
>
> Oliver Lehmann <lehmann at ans-netz.de> wrote:
>
>> I hit the send button to fast :(
>>
>> Oliver Lehmann <lehmann at ans-netz.de> wrote:
>>
>>> Nick Downing <downing.nick at gmail.com> wrote:
>>>
>>>> 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.
>>>
>>> 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
>>
>> 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.

[TUHS] System III - TCP/IP

[Nick Downing]

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 at ans-netz.de> wrote:

>
> http://cvs.laladev.org/index.html/P8000/WEGA/src/uts/sys/ureg.c?rev=1.9&content-type=text/x-cvsweb-markup
>
> 1.9 is the current version 1.1 is the plain SysIII file...
>
>
> Oliver Lehmann <lehmann at ans-netz.de> wrote:
>
> 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&content-type=text/x-cvsweb-markup
>>
>>
>>
>> Oliver Lehmann <lehmann at ans-netz.de> wrote:
>>
>> I hit the send button to fast :(
>>>
>>> Oliver Lehmann <lehmann at ans-netz.de> wrote:
>>>
>>> Nick Downing <downing.nick at gmail.com> wrote:
>>>>
>>>> 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.
>>>>>
>>>>
>>>> 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
>>>>
>>>
>>> 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.
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20151110/9074cfd5/attachment.html>

[TUHS] System III - TCP/IP

[Cornelius Keck]

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:
> Hi,
>
>
> i have an old Z8001 based SysIII variant and I would love to have TCP/IP
> on it (SLIP first, later with a homebrew ethernet device).
>
> I wonder if someone ever saw TCP/IP available on a System III?
>
>
> I have lets say 90% of the kernel running on it as source
> available and I started digging in the available 4.2 BSD sources.
>
> It looks like there would be much to do to hack in TCP/IP on my
> own (no IPC, no Net, no PTY, no....).
>
> I got K5JB running (userland TCP/IP implementation) after I fixed
> some C code because the C Compiler available on the system is..... kinda
> limited.
>
> telnetd is of course not working as there are no pseudo-teletypes on this
> SYSIII. At least I got ping, echoping and ftpd up and
> running via SLIP
>
> (10.1.1.2 is my SysIII box:)
>
>
> # ping -c3 10.1.1.2
> PING 10.1.1.2 (10.1.1.2): 56 data bytes
> 64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms
> 64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms
> 64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms
>
>
> --- 10.1.1.2 ping statistics ---
> 3 packets transmitted, 3 packets received, 0.0% packet loss
> round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms # ftp
> 10.1.1.2
> Connected to 10.1.1.2.
> 220  FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991
> Name (10.1.1.2:root): test
> 331 Enter PASS command
> Password:
> 230 Logged in
> ftp> get sa.timer local: sa.timer remote: sa.timer
> 500 Unknown command
> 500 Unknown command
> 200 Port command okay
> 150 Opening data connection for RETR sa.timer
> 2571       0.53 KB/s
> 226 File sent OK
> 2571 bytes received in 00:05 (0.48 KB/s)
> ftp> get wega local: wega remote: wega
> 200 Port command okay
> 150 Opening data connection for RETR wega
> 98723       0.51 KB/s
> 226 File sent OK
> 98723 bytes received in 03:05 (0.51 KB/s)
> ftp> exit 221 Goodbye!
> #
>
>
> So I wonder if someone got anything SYSIII -> Net/TCP/IP related
> which could help me in any way to get a SYSIII kernel capable of TCP/IP and
> PTYs to get a telnetd up and running via SLIP is my
> first goal.
>
> Regards,
> Oliver
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>
>

[TUHS] System III - TCP/IP

[Oliver Lehmann]

Hi Cornelius,

the system is more or less a clone of the Zilog System 8000 which ran ZEUS.
The clone was made in the eastern part of germany behind the iron curtain.
The 16Bit part of the system is more or less a 1:1 clone of the System 8000
and so is the OS also a clone of ZEUS (with modified part of the kernel to
adress the differences in hardware). If you are more interested about the
system itself, feel free to read more on my page (page itself is english,
but most linked documents are in german)

http://www.pofo.de/P8000/

Regards,
Oliver

Cornelius Keck <ckeck at texoma.net> 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:
>> Hi,
>>
>>
>> i have an old Z8001 based SysIII variant and I would love to have TCP/IP
>> on it (SLIP first, later with a homebrew ethernet device).
>>
>> I wonder if someone ever saw TCP/IP available on a System III?
>>
>>
>> I have lets say 90% of the kernel running on it as source
>> available and I started digging in the available 4.2 BSD sources.
>>
>> It looks like there would be much to do to hack in TCP/IP on my
>> own (no IPC, no Net, no PTY, no....).
>>
>> I got K5JB running (userland TCP/IP implementation) after I fixed
>> some C code because the C Compiler available on the system is..... kinda
>> limited.
>>
>> telnetd is of course not working as there are no pseudo-teletypes on this
>> SYSIII. At least I got ping, echoping and ftpd up and
>> running via SLIP
>>
>> (10.1.1.2 is my SysIII box:)
>>
>>
>> # ping -c3 10.1.1.2
>> PING 10.1.1.2 (10.1.1.2): 56 data bytes
>> 64 bytes from 10.1.1.2: icmp_seq=0 ttl=254 time=316.317 ms
>> 64 bytes from 10.1.1.2: icmp_seq=1 ttl=254 time=297.328 ms
>> 64 bytes from 10.1.1.2: icmp_seq=2 ttl=254 time=296.369 ms
>>
>>
>> --- 10.1.1.2 ping statistics ---
>> 3 packets transmitted, 3 packets received, 0.0% packet loss
>> round-trip min/avg/max/stddev = 296.369/303.338/316.317/9.186 ms # ftp
>> 10.1.1.2
>> Connected to 10.1.1.2.
>> 220  FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991
>> Name (10.1.1.2:root): test
>> 331 Enter PASS command
>> Password:
>> 230 Logged in
>> ftp> get sa.timer local: sa.timer remote: sa.timer
>> 500 Unknown command
>> 500 Unknown command
>> 200 Port command okay
>> 150 Opening data connection for RETR sa.timer
>> 2571       0.53 KB/s
>> 226 File sent OK
>> 2571 bytes received in 00:05 (0.48 KB/s)
>> ftp> get wega local: wega remote: wega
>> 200 Port command okay
>> 150 Opening data connection for RETR wega
>> 98723       0.51 KB/s
>> 226 File sent OK
>> 98723 bytes received in 03:05 (0.51 KB/s)
>> ftp> exit 221 Goodbye!
>> #
>>
>>
>> So I wonder if someone got anything SYSIII -> Net/TCP/IP related
>> which could help me in any way to get a SYSIII kernel capable of TCP/IP and
>> PTYs to get a telnetd up and running via SLIP is my
>> first goal.
>>
>> Regards,
>> Oliver
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>
>>

[TUHS] System III - TCP/IP

[Noel Chiappa]

    > From: Dave Horsfall <dave at horsfall.org>

    > I thought PWB (makers of "make") came from Harvard? 

PWB? As in "Programmer's Work Bench"? The OS part of that came straight out
of Bell - see pg. 266 in the first Unix BSTJ issue. Not sure about all the
applications (well, SCCS came from Bell).

	Noel