Z80 & TCP/IP - PPP / SLIP
- Geschrieben von: Ralf Kästner
- Zugriffe: 63667
Beitragsseiten
PPP / SLIP
This is the best known and most used method for Z80 systems. The picture shows the software TCP/IP-stack sitting on top of a serial interface. Because almost every system had this interface, it was also the most obvious way.
Here are some links to such projects : all of them have been more or less dead for years.
1999 - 2001: CPC/IP - A TCP/IP stack for Amstrad CPCs
- Mark Rison
- http://www.cepece.info/cpcip
- SIO
- SLIP/PPP
- Z80 Assembler
- Dominic Morris
- http://www.rst38.org.uk/zsock
- SIO
- SLIP
- C
2001 - 2002: EZ80 - TCP/IP Stack für Z80
- Jens Dietrich
- http://www.icplan.de
(Netzwerk-Technik: "Embedded Internet Z80 Board")- SIO
- SLIP
- Z80 Assembler
1999 - 2005: UZIX - UNIX Implementation for MSX
- Adriano C. R. da Cunha / Douglas Braun
- http://uzix.sourceforge.net
- SIO
- SLIP/PPP/PAP/CHAP
- C
2000: ICE - Internet Connectivity for Eight-bit ataris
- Kenneth Siders
- http://atari.ksiders.tzo.com/ice.htm
- SIO
- PPP/PAP
- Assembler
1993 - 2004: LUnix / LNG - LUnix next generation C64
- Daniel Dallman
- http://lng.sourceforge.net
- SIO
- SLIP/PPP
- Assembler
The results were rather mixed and ranged from "You can send and receive bytes." to full TCP/IP-stacks with network programs. What speaks for and against PPP or SLIP if one takes into account the defined goals:
freely programmable - very good memory usage - extremely high system load through the stack - very high stability and reliability - depends on memory usage other computer or server needed - yes system load through network activity - not significant transfer speed of network data - very bad response time and usability - very bad communication capabilities - very good implementation of standard RFC-protocols - depends on memory usage convenient API for network programming - depends on memory usage compatibility with other Z80 systems - depends on RS-232 hardware login / authentification / connection - needed for PPP
The critical points are marked in red and were the reason for me not to attempt to do it in this way. Other people have tried, here are two quotes from Mr. Phil Karn (KA9Q), found in the files "tcpguide" and "descript.doc" of his TCP/IP package:
"The implementation is highly modular. For example, if one wants to build dedicated packet switch without any local applications, the TCP and UDP modules may easily be omitted to save space."
"Speed improvements. I'm rather disappointed with the speed of this code on the 820, although a 2.5 MHz Z-80 isn't the fastest machine in the world. Channel speed is completely dominated by the interrupt routines in line.c, and while I've made them as tight as I can, some improvement might be had by coding sections of them in assembler. However, I'd MUCH rather have DMA hardware available, as this is the only way to get the really dramatic speedup we need to run speeds like 56 kB and up."
One example, the common baudrate of 19.200 Baud of a standard RS-232 interface gives a transmission speed of 1.920 Byte/s.
(19200 Baud * 8 Bit) / 10 (Start+8N1) = 15.360 Bit/s = 1.920 Byte/s
The layers of the software TCP/IP-stack, where all network data must be processed, leads to a further slowdown of data transmission. The entire construction ends below 1 kB/s effectively (estimated) : not acceptable for me as a user of the system.
The high memory requirement for a software stack with network application, the low speed of a standard RS-232 interface in a Z80 system, and the high burden of the entire system through the stack itself, are the main reasons that a usable TCP/IP implementation for my system, excluded on this basis. This applies to all other low-clocked standard cp/m 2.x systems equally.