The possibility exists certainly, several solutions are known for 8-bit systems.
TCP/IP
The following article gives a short overview and should not be exhaustive. I will show the problems of existing TCP/IP implementations and explain the advantages of the KCNet-interface for my needs in an usual home network.
In principle, this subject has interested me for long and I have pursued the development very carefully for many years. Since 1996 I use the internet, I built my first BNC home network with 5 PC's and a Linux softwarerouter behind the cable-modem 2002. Today I drive a Gigabit home network with its own network-server and VoIP-hardwarerouter with WLan.There are 8 PC's in the network, which has a 16-MBit ADSL-connection to the internet.
The only thing missing in the home network was my KC85 system!
If you want to build a network, you must know, how to do it. If it works, you want to know how the technology behind it operates. Sometime, you are interested in the software also and come to the TCP/IP stack inevitably. Then, you must work through a lot of theory and unfamiliar names and terms, before you understand how the components work with each other. Therefore, the following pictures summarize the most important things and concepts shortly.
There are masses of documents about this topic in the internet. Very good and extensive overviews can be found for example at:
| The TCP/IP Guide | http://www.tcpipguide.com/free/index.htm |
| IBM Redbook "TCP/IP Tutorial and Technical Overview" | HTML/Java version |
| Microsoft TechNet Library | TCP/IP Fundamentals for Windows |
The OSI reference model is the fundamental networking model. It was published in 1984 by the ISO as standard ISO 7498. The model is a very useful tool for education and development. It defines a set of layers and a number of concepts for their use, that make understanding networks easier.
OSI splits the entire "network monster" in layers with individual tasks. Each of the modular components is responsible for a particular function. The particular function of one layer refers specifically to a set of communication rules, instructions and/or procedures. They describe the communication between specific software or hardware elements, running at the same layer on different machines within a network : the horizontal communication protocol of corresponding layers.
Interfaces are between the layered components for data transfers in both directions. Vertical communication is done up and down the protocol stack, every time anything is sent or received across the network. This occurs because the higher levels are implemented as logical functions in software. There is no actual physical connection.
In the case of a TCP/IP network, the TCP/IP reference model is used in discussions of this suite. It has many similarities to the OSI model, but also some differences. TCP/IP in general, covers many layers of the OSI model and provide services to other protocols, as well as services provided to end users directly.
The protocol services consist of the core functions, implemented by the main TCP/IP protocols: IP, TCP and UDP. These services are designed to actually accomplish the internetworking functions of the protocol suite. The IP protocol provides functions at Internet layer 2, such as addressing, delivery and datagram packaging, fragmentation and reassembly. TCP and UDP are concerned at the Transport layer 3 with encapsulating user data and managing connections between devices. Higher layer protocols use these services, allowing them to concentrate, on what they are intended to accomplish.
The other general types of service provided by TCP/IP are end-user services. These facilitate the operation at the Application layer 4, like www, that users run to make use of the power of the Internet and other TCP/IP networks.
The function of the Network layer 1 and how it has to work, is not exactly spezified. It makes use of other existing protocols like Ethernet or Slip. The network layer protocol defines, how a host must be connected to a network for the transmission of IP-packets.
Data Encapsulation is the hell of data flow through the layers. Every layer protocol adds / removes its own information as header in front of (or footer behind) the data of the next upper or lower layer. The entire contents of the higher layer message are encapsulated as the data payload of the message at the lower layer.
An Ethernet-based TCP/IP network needs 4 addresses to transport data, from the Ethernet-line up to the Application layer and vice versa. This is very confusing for beginners, but necessary to implement the OSI model with independent components:
- physical network address (MAC) on the network layer
- internet address (IP) on the internet layer
- transport protocol number on the transport layer
- port number on the application layer
TCP/IP speaks its own language. Many terms there are for the unique identification of data in the individual layers. With such a specific term, it is clear where the data are in the TCP/IP stack, and what structures and contents they have. The picture shows the important terms for an Ethernet network.
KCNet Project
Because of the long preparatory period, I had enough time to think over a solution. In 2007, the following development goals were defined for the KCNet - Project:
- freely programmable TCP/IP stack without restrictions
- lowest possible memory usage
- low system load through the stack itself
- high stability and reliability
- standalone solution without other computer or server
- low system load through network activity
- high-speed transfer of data between host to host applications
- low response time and a felt fast interface for the user
- universal communication with hosts in- and outside the local network
- easy implementation of standard RFC-protocols
- convenient API for network programming on all layers
- interface-compatibility with as many Z80 systems as possible
- no need for login and/or authentification and a permanent connection for sharing data in the network
In the last years, it was somewhat quieter about 8-bit computer and TCP/IP, the most known solutions originated predominantly in the time between 1998 and 2002 as the internet became a mass-medium. The connection was done by analog modems over the serial RS-232 interface.
Today, modems are obsolete at home. The ADSL internet is constantly available. A (hardware) router with DSL-modem or cable-modem is the link. Often the router is included for little money or for free as an addition to the provider contract. Such a router manages the internet access data of the provider and connection establishment alone. It contains some important services for easy building of home networks. The entire computer technology behind the router is linked, usually via Ethernet and cable or wlan.
That's why a serial modem connection is not very helpful. What I wanted, was a direct Ethernet access over TCP/IP : the communication standard! This will give me two things in one: access to the ressources of the home network, and universal communication possibilities over the internet. Today, TCP/IP is no more only the standard for the internet communication, but also for the operation of an usual home network with Ethernet.
Beside RS-232 and modem there are other ways and means to implement TCP/IP functionality in a 8-bit system. Below a comparison of other known projects is carried out with the stated aims of the project "KCNet". There are three things to note in particular, if an universal solution should be created for many Z80 systems:
- how the data of the application are handed over to the stack (network API)
- the connection point of the system and TCP/IP-stack layer (network hardware-connection)
- the need and usage of system ressources like memory and I/O space (network driver and/or software)
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.
Ethernet Controller
The second possible solution is, so far not seen with a Z80 system, to take a suitable Ethernet-Controller and connect it with the bus of your system. This works like a PC network-card and allows direct access to a Ethernet network. The following picture illustrates this.
The software TCP/IP-stack sits on top of the hardware interface, which must be programmed from a driver for memory-mapped I/O or direct I/O. This depends on the elected Ethernet-controller.
The "RR-Net" for the C64 is one example from the year 2003.
2003: RR-Net - 10 MBit Ethernet Network-Card for C64
- Jens Schönfeld
- http://www.jschoenfeld.com/news/news88_e.htm
- http://www.c64web.com
- Clock-Port
- memory-mapped I/O
- 6510 Assembler
So far, not many software exists for this card. I cannot judge exactly this solution, but the second link above shows the "real thing" : a "contiki" based web server on a C64. By substituting the slow RS-232 interface with a fast Ethernet controller, a disadvantage is removed, all other circumstances remain similar as with PPP / SLIP.
freely programmable - very good memory usage - extremely high system load through the stack - high stability and reliability - depends on memory usage other computer or server needed - no system load through network activity - can become high transfer speed of network data - bad response time and usability - 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 hardware interface login / authentification / connection - no
One must build a hardware-interface for the system, that would not really be an obstacle. But the high memory requirement for a software stack with network application, and the burden of the entire system through the stack itself are reasons to drop this way. If new hardware is required, there are other solutions.
Further problems can occur with this solution as well. The software stack must process all Ethernet-packets of the network, in order to find out whether they are intended for it. With high broadcast's traffic, this leads to a heavy system load and response time, and usability can decrease drastically!
Serial to Ethernet Adapter
That is another possibility to connect a system with RS-232 interface with an Ethernet network. The hardware-connection is quickly made, but there are strong limitations on the software side. The following picture represents the structure.
The crucial disadvantage is that there is no direct access to the TCP/IP-stack. It is hidden behind the non-standard device-specific protocol of the adapter (firmware). The Z80 software will work with adapters from the same manufacturer only. The functionality is directly influenced by the instruction set of the device protocol. The stack is not freely programmable.
There is an attempt in the "The N8VEM Home Brew Computer Project" with such adapters:
2008 ... : MSS100 - Serial to Ethernet Gateway / Device Server
- James Moxham and Richard Haseman
- RetroBrew Computers N8VEM
- UART
- not standardized and limited Device-Protocol over RS-232
- Z80 Assembler
This project is in the very beginning and not reusable until now. So far, it was possible to establish a Telnet session, but there exists no API, just some experimental code.
freely programmable - no memory usage - low system load through the stack - no stability and reliability - yes other computer or server needed - no system load through network activity - no transfer speed of network data - bad response time and usability - depends on RS-232 hard- and software communication capabilities - depends on adapter firmware implementation of standard RFC-protocols - depends on adapter firmware convenient API for network programming - no compatibility with other Z80 systems - only with the same adapter login / authentification / connection - no
The restricted functionality of the device protocol decides against this solution. It sits over the application level of the TCP/IP stack. If there is a command or application not implemented in the adapter firmware, it is impossible to write an according network program.
Because the device protocol of such a serial to Ethernet adapters isn't portable, this cannot become a solution for a common Z80 TCP/IP-interface.
The same problem exists with other MCU's like PIC's, AVR's or ARM's, which can do the TCP/IP-stack for a Z80 system. Without an exactly defined hard- and software-interface for both sides on one layer of the TCP/IP-stack, an universal TCP/IP binding for a Z80 system will never exist. This development effort must be done twice : this requires a lot of time, experience and knowledge.
You need a generic protocol in order to program without restrictions, if you use external hardware!
Hardware TCP/IP-Stack + Ethernet Controller
In 2003, I discovered the first information about the chips of the company "WIZnet", which had managed a complete TCP/IP-stack in an integrated circuit. That went in the direction, favored by me : the lowest time-critical and complex layers of the TCP/IP-stack reside in external hardware, and the KC85 must send and receive network data with a corresponding protocol (RFC) "only".
In October 2006, I bought an experimental board with a WIZnet chip and started the KCNet project later:
2007 - 2008: KCNet - Native TCP/IP Stack for Z80 Systems
- Ralf Kästner
- Z80 PIO
- BSD like Socket API
- Z80 Assembler
This way of connecting a Z80 system over a fast parallel connection to a hardware TCP/IP-stack removes all disadvantages of the other solutions : no red markers, what a surprise :-) :
freely programmable - very good memory usage - very low system load through the stack - no stability and reliability - yes other computer or server needed - no system load through network activity - no transfer speed of network data - high response time and usability - very good communication capabilities - very good implementation of standard RFC-protocols - yes convenient API for network programming - yes compatibility with other Z80 systems - very good login / authentification / connection - no
The Z80-PIO hands over the network data to the stack, and ensures high bidirectional transfer-speed with a very simple hardware-handshake. Because the PIO is a standard peripheral circuit for Z80 systems, the hardware-interface is highly portable.
With the existing API, the TCP/IP-stack behaves like memory for the Z80 system, and can be used very easy. The high-level socket CALL's let application programming be a snap for network programmers.
The 4 channels of the WIZnet stack can be programmed on the TCP/UDP transport layer, but on the IP-layer or network-layer (MAC) too.
For academic reasons, it would even be possible to write the stack in software and use the MAC-layer of the stack as connection to the network (hybrid mode), where the hardware limitation to 4 sockets no longer exists.
The low-level commands of the hardware interface form a generic protocol, and do not restrict a programmer in doing anything with the stack.
The software, which is required in order to use the stack, may be included in each network program, due to the small size. There is, compared to the first two solutions, almost no memory consumption.