The possibility exists certainly, several solutions are known for 8-bit systems.
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"
|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.
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
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
- Z80 Assembler
- Dominic Morris
2001 - 2002: EZ80 - TCP/IP Stack für Z80
- Jens Dietrich
(Netzwerk-Technik: "Embedded Internet Z80 Board")
- Z80 Assembler
1999 - 2005: UZIX - UNIX Implementation for MSX
- Adriano C. R. da Cunha / Douglas Braun
2000: ICE - Internet Connectivity for Eight-bit ataris
- Kenneth Siders
1993 - 2004: LUnix / LNG - LUnix next generation C64
- Daniel Dallman
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.
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
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!
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
- 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
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!
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