Updated last on Feb 9 2011. Document (c) 2011 Herb Johnson, except for quotes by individuals as noted. Quotes were either posted publicly in Usenet comp.os.cpm, or from private discussions and used with permission. Please contact me with any corrections, errors, or omissions.
For more information about CP/M, check my home page about CP/M and Digital Research. - Herb Johnson
Over the years, many people post a "simple" question in comp.os.cpm: "Is there a way to run "TCP/IP" in CP/M?" or variations like "where is TCP/IP for CP/M?" or how it could be done, etc. It's asked a few times a year. The simplest answer is "check the archives of comp.os.cpm for previous responses." There is good discussion to find, and more often than not the same answers and same resources are discussed. Much of this note, is from discussions in March 2009 in comp.os.cpm.
One issue which comes up often, is the fact that it is EASY to ask for "TCP/IP". It's just six letters, easy to type. But TCP/IP is just some communications protocols, a kind of hardware and software language. The pertinant response then is "TCP/IP to support WHAT?" For some applications, like showing videos from the Internet, CP/M with TCP/IP is about as useful as putting a V-8 automobile engine on a golf cart (or a lawn mower engine in a Humvee, etc.). So "TCP/IP for CP/M" is not just about an Internet connection, but what you can run to support whatever you access on the Web.
Another common response to the question, is to refer to "packet radio", an activity started by radio amateurs in the early 1980's to use X.25 and TCP/IP protocols over two-way radio. The problems with that solution are two. One is to find early versions which are Z80 based in some way, as the hams moved to IBM PC's fairly quickly. The other is the hams used "TNC" or terminal network controllers, which are seperate small computers to run the lower layers of networking; they are a kind of "modem" for packet radio. So, old ham code would use "old" TNC's. Also, some CP/M enthusiasts "want" to run TCP/IP "on" their CP/M systems (whatever that means) and not on auxiliary hardware.
Another issue which comes up, less directly, is that most people who ask about "TCP/IP for CP/M", don't want to spend more than $99 to do it; or $59; or maybe ANY money. Chances are, however, to buy enough hardware to implement any solution, will probably cost within or above that price range. The old ham hardware which "did it" may well cost that much too - when you can find it. So keep a "budget" in mind when you ask for "help" on this subject.
Otherwise, the question when stated this simply, is often just a means to start a conversation, not to start to do anything useful. Point being: If you want to do anything useful or interesting on this within CP/M, first see what HAS been done or talked about. Search comp.os.cpm and read messages from years ago. TCP/IP, and CP/M, have not changed in more than several years.
In any event, here are some of those responses from March 2009, when "TCP/IP for CP/M" came up. I've accumulated, categorized, and updated them in 2009. This page has discussions of common solutions for TCP/IP on Z80 and similar processors, discusses KA9Q as one of the earliest packet radio/Z80 solutions, and discussions of recent products which provide networking.
I'd like to thank Allison Parent, "susowa" AKA Ralf Kästner of Germany and KC-Net, and Gaby Chaudry of the "unofficial CP/M archive" for their support, review and donation and archiving of code, and private discussions (some of which are included here with permission).
- Herb Johnson
Common answers and responses to "TCP/IP for CP/M?" with links to the sections below.
Old 8-bit implementations of TCP/IP 1) Here is a lightweight (or older) version of TCP/IP for PC's or PDP-11's, etc.....
The problem with most of these, is that they are written in C and written for 32-bit or older 16-bit processors. They
require more memory and more processor speed than a CP/M system with 64K memory space and a 2, 4, or 6MHz Z80.
Furthermore, it's no small effort to recode from one processor family to another, or one compiler to another.
2) This was done ALREADY, decades ago, by radio amateurs.
"KA9Q did it back in the 80s when IP was core of Amateur radio Packet
radio. The low level stuff was x25 but more modern netowrk interfaces
can unload all the fast stuff." - Allison Parent
[According to Phil Karn's KA9Q Web page at http://www.ka9q.net/code/ka9qnos/],
an archive of KA9Q is [also] at ftp://ftp.funet.fi/pub/ham/packet/tcpip/ka9q/
Also at ftp://ftp.ucsd.edu/hamradio/packet/tcpip/ [are implementations for several OS's]
Another archive of Amateur Packet is at ftp://ftp.tapr.org/software_lib/
The Web site is at http://tapr.org/
TAPR is a radio amateur organization which created the "TNC" or Terminal Network COntroller, a Z80 board which went
between a computer and your transciever to perform X.25 and TCP/IP over Amateur Radio airwaves. This work was first done in
the early 1980's, some of it continues today.
But here's the problem with KA9Q and its major Web sites. It's difficult to find all the pieces of KA9Q AND the TNC pieces AND find them for Z80/CPM use. It was apparently used from the late 1970's to the mid-1980s.
CHeck this page of a KA9Q developer for some history.
From the Xerox 820 Z80 board, it went on to be used on IBM PC's in the era, and then on Linux. Almost all of the "KA9Q" sites exclude the early Z80 code.
Another general difficulty: many old archives are in old CP/M based compression schemes (crunched, ARCed, ARKed, LBRed, etc). These either have to be uncompressed with old MS-DOS tools, or older CP/M tools. The Walnut Creek CP/M CD-ROM has many of these utilities, as so do CP/M archive Web sites.
But thanks to this discussion and recent work, some older KA9Q and Z80 archives have been unconvered: see discussion of early KA9Q and archives of it, on this section of this Web page. The bottom line: Allison provides and describes two ZIPped KA9Q Xerox 820 collections she provided to Herb, and to Gaby's CP/M archive. Also, Herb Johnson extracted and ZIPped the Walnut Creek "packet radio" archives. They are all available from Gaby's CP/M archive on this Web page.
3) This was done ALREADY, decades ago in some cases, for various 8-bit systems, some Z80 based. For instance...
Here's some often-cited examples. Details of these old (or recent) TCP/IP 8-bit code Web links are elsewhere on this Web page.
Peter Dassow: "See also my blog entry at http://www.z80.eu/blog/index.php?entry=entry080725-160000
Details of these are elsewhere on this Web page as "old 8-bit code".
5) This question has been asked before. Here's *my* response on *my* site...
Of course, this document is one example of that. ;)Here's some general discussion in comp.os.cpm for March 2009 on the question.Again, a search of comp.os.cpm for "TCP/IP" will find years of discussion, much of it relevant, if not repetative. Of course, many of the Web links on this page also have discussion, documentation, code, etc....
To the response "This was done ALREADY, some of it decades ago, for various 8-bit systems.. Here's some often-cited examples.
Peter Dassow: "See also my blog entry at http://www.z80.eu/blog/index.php?entry=entry080725-160000
Andrew J. Kroll has a site: http://cpm.dr.ea.ms/ Commodore 64 in CP/M mode for TCP/IP support.
CPC/IP - A TCP/IP stack for Amstrad CPCs -- http://www.nenie.org/cpcip/
Matthew Phillips quotes the Web site: "CPC/IP is an implementation of the PPP, SLIP, IP, ICMP, UDP, TCP, DNS, TFTP,
HTTP, ping, finger and telnet protocols for Amstrad CPC computers with an
Amstrad, Pace or CPC Amstrad International serial interface. The code
occupies about 14K, excluding the serial, filing system and IP buffers, but
including all the clients and servers and their buffers/data."
Another report: LightweightIP (http://en.wikipedia.org/wiki/LwIP) that uses about 40KB of code.
[This is a variation of uIP, see below. - Herb]
(year 2000 post) "Yes, and there is a TCP/IP stack under development for a Z80 machine, the
Amstrad CPC, which also runs CP/M." See http://www.altsoft.demon.co.uk/cpcip/
Allison Parent: Here's uIP anotehr small IP stack. http://www.sics.se/~adam/uip/index.php/Main_Page
Later she wrote: [check this Web link]
"I was looking for something about IP for [other work] and lo and behold this turned up.
There is info uIP for z80, uIP for TRS80/M3 and the KA9Q archive or lat least one with docs
for the Xerox 820 and Big board. looks like done before to me. -end--
Herb responded privately: "The five uIP or lwIP links there are under the title "TCP/IP stacks for z80 or CP/M based machines":
These three are or were the same project. The "savannah" lwIP page seems to be a fork of uIP on the "sics" page. Version 1.3.0 is dated March 2008. Under a megabyte for the ZIP code files. The "geocities" Model 3 mode runs under TRSDOS 1.3 and LDOS 5.3.1., using SDCC or Misosys C compilers. "Remember, SDCC is *really* buggy.." Page refers to the sics Web site above.
[Update: a Z80 port of uIP from year 2002 is at this link. - herb]
d) http://www.cpm.z80.de/randyfiles/DRI/cpm-tcp.zip TCP for the Xerox 820
My guess is that this was donated by Randy McLaughlin, who was active in S-100 and CP/M several years ago and then VANISHED. The "readme" says "OK: I can't remember from where I got this stuff, OK?". Looks like
AX25 and Xerox 820 C and asm code from 1991. may use Aztec C. The "TCPGUIDE" says "KA9Q Amateur Radio", so this may be KA9Q's earliest code, which he does not offer on his Web site today. The MAKE file has statements like "cz -DZ80 -ib: b:mbuf.c" and "as -zap b:mbuf"
which may help identify the compiler. No dates, no version numbers, no author names.
See this part of this Web page for KA9Q and Z80 code and discussion. - Herb
e) http://www.cepece.info/cpcip/
A SLIP/IP/UDP/TCP/DNS/TFTP/ping/finger/telnet stack Amstrad CPCs
"CPC/IP is an implementation of the PPP, SLIP, IP, ICMP, UDP, TCP, DNS, TFTP, HTTP, ping, finger and telnet protocols for Amstrad CPC computers with an Amstrad, Pace or CPC Amstrad International serial interface. The code occupies about 14K [less buffers]..." No changes since 2001, at version 0.20. Apparently in assembler, Assemble it all using ZMAC. Apparently it's used to connect to a "peer" computer (a CPC or a Linux box) running SLIP or PPP. "CPC/IP is Copyright (c) 1999-2001 Mark RISON. You may not distribute it without my permission..." but he suggests he would be flexible, as of
2001. -end-
Ole Christensen said:
Just some little inspiration, (and for those people in this group saying):
"this can't be done", "You need multitasking" "not before the Z80 come with more cores"
"WHY...?, (for heaven sake)": [three Web links provided as below]
See the discussion of these by Allison Parent, later in this document. --end--
You can buy some serial to Ethernet adapters, or use PIC or other processors with some Ethernet "interface" chips,
as such adapters. Then you "talk" to these devices from your CP/M (or other) system to "do" Internet "things". On
the Web, look for "serial to Ethernet" converters, or "run your PIC processor on the Internet", etc.
Microchip has a series of two chip sets to support Ethernet and TCP/IP. One chip set is their "PIC18" processor series, for which they offer
TCP/IP code (called a "stack"), and supporting code to operate various protocols (consider these as rules for
message types to do things) like mail, Web browsing, file transfer. The other chip set are their ENJ28J60 Ethernet controller series. These are interface chips to an Ethernet "RJ45" jack, in order to support the needed "physical" features of
10bT (ten-base-tee) Ethernet hardware connections.
Microchip and other companies offer either development boards, or products, which use these sort of chips to
provide various degrees of "serial to Internet" connectivity.
A few other companies use similar products from other chip makers. But Microchip has provided THEIR chip series for
a long time, and they provide all the details and code for free. Products with chips from other companies,
may become obsolete in a few years, and the chip companies may not provide details and code - you could be stuck
without support or replacements.
Another product is "Wiznet 7010B+ or WIZ810MJ" network module with Wiznet proprietary chip.
WizNet Inc. of Korea produces a number of hardware Ethernet and TCPIP-Stack Chips and modules. An external ATmeg162 processor bridges the commands of the Z80 CPU over a standard Z80-PIO to the registers and memory of the WIZnet hardware TCPIP-Stack. In this way the Z80 system can use and control the supported TCP/IP protocols of the WIZnet chip in a transparent way.
Susowa, KC85, Z80, and TCP/IP
[In 2011 the KC85 domain was changed, follow this link.]
"Susowa" (Website of Ralf Kästner) in Germany has done substantial work on the KC85 Z80 system, to support a KC-net using the WizNet Ethernet interface and TCP/IP. He discussed some of his work during the March 2009 comp.os.cpm discussion. Check his Web site for further information, documentation and discussion. Some of his discussion is included here with permission.
here's a Web link to a 2009 document in English on the KC85 Web site, about Z80 and TCP/IP work by him and others.
In 2010 I learned of use of the Wiznet product with KC85 computers on this
German Web page for Robotron computers. These are modern versions of Z80 based boards built for the "K1520 bus", a Eurocard connector format. I'm an English speaker but Google's Translate facility provided readable translation from German text.
[Ralph Becker-Szendy posted the following:]
I spoke to Phil Karn (the author of KA9Q) by phone in the mid-1980s
about this. At that time, he already had a working version of KA9Q
for (MS-) DOS on the PC platform, which was capable of using serial
IO, and some early Ethernet card. He had already abandoned his cp/m
machine, for good reasons (PCs were widely available, better and
cheaper than cp/m machines). He still had the working source code for
KA9Q for cp/m (I think it was only using serial ports, most likely
X.25 for his amateur radio stuff), but he was unwilling to share the
source code with anyone. His reason for that was unfortunate, but
sensible: He didn't want people to start using KA9Q on cp/m, because
they would have problems, and he would have to spend time on helping
them; time that should better be spent on making the PC or DOS version
better. - end-
["french Luser" posted a comp.os.cpm message from the early 1990's,
which more or less agreed with the above situation.]
-- Bill Gunshannon wrote in response to Herbert Johnson :
Bill wrote:
As I said, I may have an early version but it will be packed away at the
moment. I can think of at least one other person I could try to get in
touch with about this. Ham TCP/IP never really took off around here so
there really weren't many of us doing it that long ago. I do remember
on at least one occaison demonstrating for my father that I could connect
to the KA9Q VAX in [New jersey] from my fathers home in NEPA all done over ham
radio. And then, when I first moved back here I had a 1200 baud link to
the INTERNET from my house thru the University using a Unix version of
KA9Q on this end and a PC at home. (The University of Scranton was the
first NEPA site on the INTERNET, there were no ISP's.)
He did move to the PC quickly, but other versions thrived as well.
TNC's provided the Physical layer. Frames were sent to it using KISS
protocol and these were then transmited. Even the Data Link layer was
formated in the KA9Q software.
KA9Q supported SLIP and PPP and later ethernet so it worked and played
well with others. I would imagine the CPM version supported all the
serial formats. But, even if it didn't, one could tie a CPM machine
running KA9Q to the INTERNET by using a PC that also ran KA9Q as a
gateway.
I don't expect that you are going to find a version actually labeled
"for CPM". You will need to grab the earliest version you can find and
look in the code. Older code was not usually removed and there may actually
be #ifdef's in there for CPM (although it is more likely to say something
like "Aztec C".)
> > and they depend on specific TNC hardware with its own software.
Well, yes, they are all going to support KISS and comments will be geared
towards ham radio use, after all, that ws its purpose. But, the other
serial protocols should be in just about all of them. A TNC would certainly
not be necessary and of little use.
Looks like you found it after all. I'll have to grab a copy myself before
it really disappears. -- Bill Gunshannon
[ The above are available from Gaby's CP/M archive on this Web page, or at the links given as of 2009.]
Allison said privately:
This is the KA9Q Xerox 820 implementation. If I get a moment to zip it up I _may_ have a
more complete version. Mine however does have the doc pages that describe it.
I really have to get that zipped and out there. Assume [a date] around 1984-85.
FYI: don't let the ax.25 serial protocol mask the fact that IP handles stuff above that
like getting stuff from here to there and not how the bits on the wire are done. It's
not much different functionally to the user than running SLIP over a V.32 (33.6kbaud)
[dial-up] modem to an ISP that provides a gateway to the internet. Packet radio did indeed
have a few gateways to internet, once it was possible for private users to afford them.
Bottom line [in all this discussion,] is IP family prototcols are out there and have been for
a long while, for small cpus including 6502, z80 and others.. Do recognize that if people
are scared of BIOS floppy and hard disk code then you can easily imagine that they would be
terrified of networking as they understand that [even] less. It can be simplified and the
whole suite is not required to do FTP (get or put files) or HTTP: to serve a file or many,
or Telnet connect to a remote system as terminal and Rlogin allow a remote system to connect
as a terminal. If I called FTP PIP with a net connection to a friendly system it's less
fiendish sounding. Telnet is Modem7 using something other than modem (network) and so on.
CP/M has done those things and I may add Email and BBS too.
I do ask has anyone looked at http://www.ka9q.net/code/ka9qnos/? Scroll down to the bottom
of the page for some interesting links. Note that the page was written for the current
state and only touches on the history and code as Phil has made it clear that works is
mostly lost or are dead [to him] as there are many modern OSs with IP solutions.
[These links are to Linux and MS-DOS versions, and a site for versions for Amiga, OS9,
OS/2, Sun, etc. Dates I see are post-1991, 92- Herb] ---end---
Bill Gunshannon wrote:
OK, I grabbed the KA9Q code from the link on Gaby's site. I looked at it.
It has SLIP (as well as AX.25) support so if you really want to connect a
CPM machine to the INTERNET this should do the trick. Assuming you have
the Aztec C compiler to build it with. -- end--
Herb Johnson wrote privately:
This reminds me, Allison. I sent you a ZIP of the Walnut Creek CP/M CDROM's code on "packet radio". [Herb Johnson extracted and ZIPped the Walnut Creek "packet radio" archives. They are all available from Gaby's CP/M archive on this Web page.}
That part of the archive has the following:
* Z80 sources for MULRPT AX.25 Xerox 820 repeater and a TNC (no author) There are also three sets of PROM HEX code by WA8DED ver 1.2, for "TAPR TNC-1 (or equivalent, such as the AEA PKT-1 or Heath HD-4040)", a 6809 based device; or the PK87; or the TAPR TNC-2 (or equivalent, such as the MFJ-1270 or AEA PK-80), a Z80 based device. NO SOURCE CODE, but these were apparently the TNC's in use by the above code.
POint being, I painfully uncompressed from the old compression formats and ZIPped them for convenience. Now these are a lot more accessible. But, is this stuff worth sending to Gaby, to add to her archive? I think they are not the same as what she has. At least they are "on topic" ;) as Z80/8080 or CP/M.
Allison reponds:
Thas from a different directory on the CDrom, one I hadn't paid much attention to.
I think that CDrom is far more valuable today then when it was produced as it containes archives that seem to have disappeared in their entirety.
I looked real fast at the files and they are NOT KA9Q. They are rom images for the various TNCs which have some value to those that exist out there and I know the TNC-2 was a kit back then. The rest is all assembler and other. I'm not sure of most of it on first glance but one file stood out and that was the SOURCE for the Xerox-820 board. There may be people that would desire or need that! It is also a typical example of a BIOS of the day as well so thats more than about IP. I have to look at it more but some of it's application level such as PBBS and a few items I ahve to look harder at. - Allison
[Allison describes two ZIPped KA9Q Xerox 820 collections she provided to Herb. They are also available from Gaby's CP/M archive on this Web page.]
You will note the DOCs zip file has an .EXE Thats the NOS [network OS] for DOS.
It's included for completeness and also as it spans the history of that
code from the 1984 Xerox 820 to first 386 class PCs. the docs while
written for the PC version has enough of the history encapsulated
and some very good tutorial as well.
The other file is the Xerox 802 stuff and may be identical to Gaby's
archive. It also has doc files and the source code in C is both readable
and Aztec C is available if memory serves to even compile it.
I was digging for something else in the ARRL Radio Amateurs Handbook 1986 edition
and KA9Q and his work is documented there. If you can find a copy it's
a worthy read for historical dates and why it was significant.
1986 RAH section 19- pages 40-50.
It's interesting reading and I did a quick Index serch of ARRL publications and
the first instances that the elecronic systems have of KA9Q is 1984 and that
didn't look like a first
article. However the amount of stuff ARRL has on line is spotty back then
though they are trying to increase that. Apparently if you can identify
the issue and the article they do have a archive of film or issues they
can pull from though I've never used it.
Enjoy reading, Allison
When discussing CP/M and "the internet", SLIP or PPP are often mentioned. "Serial Line IP"
and "Point to Point Protocol" are means to network which describe the "packet" formats of actual
binary communications - it's just "above" the hardware description. SLIP refers specifically to
serial line connections. 1990's use of Windows 95/98 and other systems to access the Internet, often
involved using SLIP and telephone line modems to an Internet providing computer. Some of the software
and hardware mentioned on this page, includes SLIP or PPP protocols.
The following is private discussion between myself and Allison Parent
on the subject. More information on SLIP and PPP can be found with a Web search
and use of books. "Layering" refers to the standard models of networking with layers of
design from hardware to protocols to software. "Sockets" refers to standard network
services provided by many operating systems as OS calls. - Herb
Herb wrote:
Allison: PPP is still around and widely used in the form of PPPoE Used to connect
PCs to DSL modems. Same thing just faster.
Allison Parent posted this response in March 2009:
A lot of answers but let's try questions as I suspect the answers are
not matching the question.
Generally the answer is yes to the question as presented. However I
think that situation is not a complete one.
First Z80s have done networking for years, the hams had Packet Radio
which in simplest terms was IP over radio. Commodore 64's, and all manner
of other non-z80 systems were used as well. The common use for that
connectivity was Email and radio propagation data that was broadcast to all
subscribed and connected recipients. The limitation of the time was low
data rate (1200 was common) and there was no commercial traffic.
QUESTIONS:
Are you looking for a complete code base to solve all the possible IP
implmentations?
Have you a conectivity solution you wish to have, such as SLIP, PPP
over serial line to a server, or Ethernet as client?
Is this a no assembly (or C or soldering) required project?
Is the intent to have CP/M network freely like PCs do?
What end point applications do you wish to implement? or to allow for
a rancge of answers, you have a connection, what do you plan to do
with it?
If you think it silly to ask, previous times when the question was asked,
the requestor had a request which distilled down to "I want TCP/IP
suite for my one off CP/M system that has Ethernet ready to go and for
under $xx.00 dollars.". This is hard to say yes to, even though
potentially doable. FYI: what is often forgotten is that the system
has a unique BIOS. Applications are portable but
the bios is very machine specific and a IP stack may be a BIOS
addition (very custom). ---end---
Susowa (Ralf Kästner) said in reply the following:
(Check susowa's KC85 Web site for more information.)
Yes, this was the question and the KCNET-hardware + 3,75 kB driver
code in a network program opens the possibility to work with/program
nearly every rfc-protocol that makes sense for cp/m.
I don't want to browse or serve files in the internet with my cp/m
computer. But I want to connect it with others (universal at our meetings
and at home), transfer files in my network, remote it, trade files
with my computer friends through other servers (ftp) and so on. I'm
absolutely free in programming, I will use and program these
possibilities for learning and better understanding the function and
mechanisms of networking and IP+UDP/TCP.
I think, before you can discuss about IP or TCPIP you have to learn
how it works in detail. To to this, it is the best do play with it. It
doesn't matter, what you take, serial with PPP, SLIP or on top of
Ethernet - but where are the solutions for cp/m up to the application
level ??? I didn't found them so far - forget IP, you need a API to
UDP/TCP to do an application. And I'm a User not a hacker - I want use
it, not say: " Eh, see - it works, I've done it!" Thats why I took
ethernet and a hardware stack - it gives me speed and it needs only
TPA for some driver code - the remaining is for the application more
than enough.
You can't program a better solution with a software-stack + network
application. Your machine with 4 MHz has not enough power to handle
the transfer of network data between all layers in a user-friendly
time and the TPA sets your application at one point the border for a
rich functionality.
The first step, is to get it to work. Then you can think over a
integration in the system.
For single application tasks there is no need for bios-integration.
[Here's what was done with the KCNET-hardware + 3.75 kB driver]:
These programs are ready, I use they often with my machine and PC's
with linux or windows.
What I do in future? I want use telnet and ftp. I will write telnet-
and ftp-clients for my interface and then I can use it.
The better way would be:
- Susowa (Ralf Kästner)
One person who asked the question (Roger Schmidt) and got some of the above answers said this:
I was thinking about it after seeing the Magic-1 project, dont know if you have heard of it? But i thought if that machine has ethernet conectivity then surely something like CP/M should as it has been around for quite some time. Mainly i thought that it would be cool to be able to download files with FTP and telnet to other machines. I did think of PPP but was unsure of how to set up a PPP server on a linux machine. I have read quite a lot on the PPP subject so the idea was there, but now i found a device called WIZnet that can connect to an 8 bit data bus and has a small address foot print! It has some smart functions and has 4 built in sockets. I have ordered a couple of the little thingys and they should be arriving any day! I have read the datasheet for them and they seem quite simple. I have done some IP protocol work in the past but that was a while ago. I'm pretty sure i remember how to send and recieve ARP and DNS packet, when in doubt use wireshark and see how to set those packets!
But as the original question read, i was just curious if there was something allready done or been worked on. And i got a few answers! ---end---
Allison's reply:
"What you forget is simple stuff like telnet are not so bad but with
winders you need SMB to transfer files and that things is a monster
and a pain to manage even under linux....There is stuff, lots of it but most is either demo, college credit or maybe a bit old. In the end it's up to the user to do most of the work."
"Seems trivial enough do you plan to use FTP, SCP, Thppd or if winders
is involved SMB? Those are the next layer up and simply having IP
doesnt solve that. FYI browsing and seriving files is relly no different to the IP stack
and it's only different to the application layered on it. "
[You ask:] "where are the solutions for cp/m up to the application level ??? I didn't found
them so far - forget IP, you need a API..."
"There aren't any [API's] to speak of! That's left to the developer. having an
IP stack implies nothing as to how to utilize it. In some sense it's
no differnt than haven a printer port or serial port and no devices
to utilize them."
"[You say] "I'm a user not a hacker". As a user there is no $59.99 solution for CP/M,
never was. The bit of networking seen back [in the early 1980's] (outside of packet radio) was typically 1000-2000 dollare per node and required serious effort to get going.
Far from PC style plug and play."
"[You say 4Mhz CPU is not fast enough.] So not true. 4mhz is plenty fast
if the physical layer is either slow
(SLIP or PPP on serial line) or some external device handles the fast
work like the ethernet to serial device I highlighted earlier. The
one item that is real is the fact that CP/M is single thread, single
task and single user. That translates to applications like FTP,
network terminal replacement and remote file services."
[As for getting it to work first, then system integration". Integration is unique as the only thing you can be certain of is the beginning of the bios has the standard jump table. Beyond
that nothing is guarenteed inside the bios. [Not integrating it in the BIOS]
violates the idea of portability. Go look at
modem programs, each one had to be tweaked for every differnt system
as the modem port was at different address, differnt device type or
worse had no support at all and a third party board was needed." ---end---
Ole Christensen said: Just some little inspiration, (and for those people in this group saying):
"this can't be done", "You need multitasking" "not before the Z80 come with more cores"
"WHY...?, (for heaven sake)": [three Web links provided as below]
Reply by Allison:
> > http://www.a2retrosystems.com/
Contiki I presume... still not CP/M. Interesting but they
do mention a typical application taking 40K of
romspace and 2k of ram. the IP stack however
has been mentioned and has been ported to Z80.
> > http://uzix.sourceforge.net/
UZI-X UZi unix for MSX.. also not cp/m
UZI unix is nice and adding IP to it is a suitable platform if... You
z80 is fast (>4mhz) has banked memory in abundance (it's 32K pages!)
and you happen to like *nix.
> > http://www.picoweb.net/
Interesting application of a Atmel AVR 8bit risc. Not z80 and not
CP/M though the code for it is GNU and compact. However porting it
to other CPUs may present challenges. --end--
On Mon, 23 Mar 2009 Ole Christensen responds to Allison:
The bad thing here are that what i was, in my mind [about UZI]
should have been [pointing you to:
http://www.techborder.com/projects/MSXNIC/ReportMSX_Ethernet.html
Final Report, EEL 4914 Electrical and Computer Engineering Design
(Senior Design) Spring Semester 2003, MSX Network Interface
Allison replies:
Nice peice of work. MSX is sufficiently different from CP/M to
warrent a differnt codebase. Also you chose to drive the 8900 MAC
device and there are already cooked parts that only need a
serial line. That makes the solder and PCB effort easier
at a small expense of speed.
I agree the will has to be here as everyone that's done it
has done a unique solution that isn't portable. The point also is a bit of "what could i expect"...
i don't think any of these people was thinking
of how many % of the server-market they could
gain to say 2015. None of them was thinking that
_this_ will be the next OS-cracker...
They was just "wasting" time,... in the same way as You and i
do with CP/M and i do hope they have fun doing so...
(and maybe learning a bit by the way)
porting yes,... if we can't figure out something on our own
we can do a port, in that case we need to understand that we
porting from that we are porting and the one we porting to...
But now that i have "susowa" source, honesty send to me by
Mr. Schmidt, Thank You "susowa" & Mr. Schmidt, i am able to
start "porting" that to my Wave Mate Bullet, (CP/M 3 is also OT),
then,... later, (if i get it to work),... i will be able to hook
up my giga-byte multitasking 2009 OS with full-blow TCP/IP
as an "dump terminal" to the "Bullet" and connect to internet,
this is, of cause, not only waste of time but also of resource...!
So: "waste time and have fun...!"
> [ole wrote?] Yes, it's amazing how understanding simple cp/m makes larger OSs concepts more bite sized.
;) indeed. I view it more like doing floppy BIOS or adding hard disk
to a minimal BIOS. For thsoe that have never done that it's
frightening once done and understood it drops to the level of
a chore. Networking has that problem, if you do not understand it
it's a big task and scary, once done it comes down to size and
the fright factor goes away. In the end doing is the only way to get
through it as someone else plug and play solution is just another
black box mystery. - Allison -
Herb wrote to Allison privately:
In principle, one can re-implement 16-bit or 32-bit implementations of TCP/IP on 8-bit devices.
You know porting issues better than I, but I think it's tough to stuff 16-bit or 32-bit C code
"down" into an 8-bit device. I myself would provide Web links, categorize these in that
fashion, and leave them at that.
Allison responds:
It can be as things like 16 or 32 bit math can be slow depending on
complexity but if speed is not an issue most of that can work out.
Much of that for this case is simple adds or subtracts (network addresses
and masks). If it can fit in memory even as overlays or modules it's
doable is shear speed is not a constraint. If a PIC can do HTTP with
less than 8K of ROM and maybe 1K or two of ram that says a lot. The
TCP/IP suite is both large and vast but not all by a long shot is
needed. When you start pruning off things down to TCP, ICMP, IP and
UDP you have most everything to talk to the world even if the vocabulary
is a bit limited.if some can be farmed out to hardware to manage then it
can be something very manageable and useful.
---end---
here's a Web link to a 2009 document in English on the KC85 Web site, about Z80 and TCP/IP work by him and others. [In 2011 the KC85 domain was changed, follow this link.]
There's work in discussion and in progress, about networking variations of the N8VEM Z80 CPU board.
James Moxham, AKA "Dr. Ackula", in Australia is connecting several Z80 boards by serial wire or wireless, to monitor and control devices over modest distances. He's also working with the Parallax Propeller multiple-processor as a way to emulate a Z80 multiple times. This work is in progress as of early 2010. It is discussed in newsgroup comp.os.cpm; on the N8VEM discussion Web site; and on other discussion groups relevant to Z80's and Propeller's,
such as the Parallax forum.
One consequence of Moxham's discussion was some prior work, pointed at by Emmanuel Roche, of
Hal Bower's CheapLAN for local networking of ZSDOS
ZSDOS, ehancements for CP/M, was developed and sold by Hal many years ago, then released under GNU on his site.
Oct 2010: In response to my question about active BBS's, John Crane posted in comp.sys.northstar: "These BBSs are definitely "endangered". I remember when there were 100+ in my state alone. Now the list is down to 31 total.
[The list is maintained on this linked Web site page.]
Contact information:
Copyright © 2011 Herb Johnson
Recent serial to Ethernet products
KAQ9 on Z80 in CP/M at Gaby's CP/M archive
Walnut Creek CD-ROM for "packet radio"
Allison's archive of KA9Q Xerox 820
SLIP and PPP
KC85, "susowa" and TCP/IP
General discussion in comp.os.cpm for March 2009
Subsequent discussion and activity
Common answers and responses to "TCP/IP for CP/M?"
from ???: http://zx81-siggi.endoftheinternet.org/index.html Sinclair ZX81
From Harston: http://mdfs.net/Apps/Networking/EcoTCP 6502 processor
From "susowa" (Website of Ralf Kästner): http://www.kc85.susowa.homeftp.net/ [in German and English]
[In 2011 the KC85 domain was changed, follow this link.]
Andrew J. Kroll has a site: http://cpm.dr.ea.ms/ Commodore 64 in CP/M mode for TCP/IP support.
Another report: LightweightIP (http://en.wikipedia.org/wiki/LwIP) that uses about 40KB of code.
(year 2000 post) "TCP/IP stack under development for the Amstrad CPC". See http://www.altsoft.demon.co.uk/cpcip/
Allison Parent; Here's uIP anotehr small IP stack. http://www.sics.se/~adam/uip/index.php/Main_Page
Allison also found three other Web sites, care of Gaby's CP/M archive at http://www.gaby.de/ecpmlink.htm
* http://savannah.nongnu.org/projects/lwip/ lwIP - A Lightweight TC/IP stack
* http://www.cpm.z80.de/randyfiles/DRI/cpm-tcp.zip TCP for the Xerox 820
* http://www.cepece.info/cpcip/ A SLIP/IP/UDP/TCP/DNS/TFTP/ping/finger/telnet stack Amstrad CPCs
Ole Christensen also provided three:
* http://www.a2retrosystems.com/ Contiki OS
* http://uzix.sourceforge.net/ UZIX OS
* http://www.picoweb.net/ on Atmel AVR 8bit RISC processor
Old 8-bit implementations of TCP/IP
from ???: http://zx81-siggi.endoftheinternet.org/index.html Sinclair ZX81
From Harston: http://mdfs.net/Apps/Networking/EcoTCP 6502 processor
From "susowa" (Website of Ralf Kästner) : KC85 Web site [in German and English]
see this discussion
a) http://savannah.nongnu.org/projects/lwip/
lwIP - A Lightweight TC/IP stack
b) http://www.sics.se/~adam/uip/index.html
The uIP TCP/IP Stack for Embedded Microcontrollers
c) http://www.geocities.com/maboytim/uip/
uIP for the TRS-80 Model 3
> > http://www.a2retrosystems.com/ Contiki OS
> > http://uzix.sourceforge.net/ UZIX OS
> > http://www.picoweb.net/ on Atmel AVR 8bit RISC processor
Recent serial to Ethernet products
KAQ9 on Z80 in CP/M at Gaby's CP/M archive
> Herb wrote:
> > My impression from the KA9Q site is that he doesn't have them. Seems
> > like these have
> > been asked about for years, without a known set of files for the
> > earliest Z80 versions.
> > I don't
> > pretend to know much about this, but my impression is that KA9Q moved
> > quickly to IBM PC versions, and/or to use "TNC" or terminal
> > network controller hardware to run "lower" parts of the
> > protocols.
> > Those versions seem to have survived in various archives.
> > Finally, keep in mind this is packet radio and not strictly
> > "plug in the wall Internet" as in cable or DSL modems used
> > today.
> > An archive of KA9Q is at ftp://ftp.funet.fi/pub/ham/packet/tcpip/ka9q/
> > Also at ftp://ftp.ucsd.edu/hamradio/packet/tcpip/
> > Someone can check these out again but I don't think they are Z80 based
> > But, thanks to an email from Allison Parent, I looked at one of Gaby's
> > archives:
> > http://www.gaby.de/ecpmlink.htm
> > Look for a set of five links under the title "TCP/IP stacks for z80 or
> > CP/M based machines":
> > 4) http://www.cpm.z80.de/randyfiles/DRI/cpm-tcp.zip
> > "TCP for the Xerox 820"
> > My guess is that this was donated by Randy McLaughlin, who was active
> > in S-100 and CP/M several years ago and then VANISHED. The "readme"
> > says "OK: I can't remember from where I got this stuff, OK?". Looks
> > like AX25 and Xerox 820 C and asm code Zipped up from 1991. may use
> > Aztec C. The "TCPGUIDE" says "KA9Q Amateur Radio", so this may be
> > KA9Q's earliest code, which he does not offer on his Web site today.
> > The MAKE file has statements like below, which may help identify the
> > compiler:
> > cz -DZ80 -ib: b:mbuf.c
> > as -zap b:mbuf
> > No dates, no version numbers, no author names.
> > That's about all I could glean from 15 minutes of review, from more
> > time spent looking at the other four links (three of them refer to the
> > same
> > code base, none of the other four are KA9Q stuff.)
Walnut Creek CD-ROM for "packet radio"
* Z80 sources for "packet" use of Heath H89 and a TNC by "RAY, N6UE"
* BASIC code for TRS80 Model 100 MINI-PBBS and a TNC by "Dick Roux N1AED"
* "general purpose packet radio server node", with a Xerox 820 & CP/M,
and one or TWO TNC's. "MailBox and GateWay Version 12.0 - 5/11/87"
Allison's archive of KA9Q Xerox 820
SLIP and PPP
>It's maybe worth mentioning SLIP and PPP, however, those *are*
>reasonable ways to hard-wire connect a PC to say a CP/M system. I used
>"slirp" with Win 95 and a dial-up modem to a Linux Internet provider,
>back in the day. Had to compile the slirp on the provider side, and use
>Win95 SLIP on my client side. In the CP/M world, I'm not sure what CP/M
>programs would talk to a slip "driver", you'd probably need the CP/M
>equivalent of "sockets" to support a standard SLIP
>implementation....Maybe I should avoid this subject, unless you know of
>some CP/M SLIP work somewhere.
>Point being, SLIP and PPP I imagine assume a "layered" and "socketed"
>implementation of TCP/IP and application support. Whereas, I think what
>has been done in and around Z80 and CP/M, is probably not very "layered"
>or "socketed", but ad-hoc.
Yes, they do,... you could have layers or sockets. CP/M is layered
to me. It's just so simple as there are few layers, ex CCP is the user interface
or the application, BDOS system are the primitives, BIOS the hardware abstraction,
next layer below is hardware. You can get finer grained about it but thats the
essence. Networking is no much different and so the common problem is that people
confuse connectivity with what you can *do* with connectivity. You can
just as easily connect two systems with SCSI in place of Ethernet and
still call the software IP (to be pedantic it would be IPoSCSI [IP over SCSI]).
General discussion in comp.os.cpm for March 2009:
> "I want TCP/IP
> > suite for my one off CP/M system that has Ethernet ready to go and for
> > under $xx.00 dollars.".
> > FYI: what is often forgotten is is the system
> > has a comomized bios it's unique. Applications are portable
> > the bios is very machine specific and a IP stack may be a BIOS
> > addition (very custom).
- the interface works over a standard Z80-PIO in every system with 4
free I/O-addresses in polling or IM2 mode (you don't need IM2, but it
can be used too)
- I developed a driver-framework for using the stack on MAC/IP/UDP/TCP
layer of the stack, it is ready for use and well tested, there are
easy to program bsd-like socket-call's on top of the framework for
network-applications and some service functions in the interface-
firmware for timing and ip-saving for example
- I wrote a dns-client for query and inverse query (resolves hostnames
in ip-addresses and vice versa)
- I wrote a network-config program for the manually or automatically
(dhcp-client or apipa) configuration of the stack for CP/M 2.x
- I wrote a full featured ICMP-client and server for PING'ing with CP/
M 2.x
- I wrote a TFTP-client and server program for CP/M 2.x to tranfer
files in a local network universal
- how can made universal interfaces for many CP/M-systems (our KC85
solution is not universal, development is done and we will start the
first production in about 4 weeks)
- we will do a universal solution for old east-german business
computers with the K1520-Bus, this solution contains a DIP-switch for
the PIO-I/O address from 0 to FF and the bus-logic for the PIO - such
a solution can be done for S-100 or other standard-busses also I
think. but who can DO !!! it
- I search for nearly 1,5 years for people, who want participate in
the project and do with me this work (plan, design and program network-
applications) - nobody was found !
> Susowa says:
> >I don't want browse or serve files in the internet with my cp/m
> >computer. But I want connect it with others (universal at our meetings
> >and at home), transfer files in my network, remote it, trade files
> >with my computer friends through other servers (ftp) and so on. I'm
> >absolutely free in programming, I will use and program these
> >possibilities for learning and better understanding the function and
> >mechanisms of networking and IP+UDP/TCP.
Subsequent discussion and activity about Z80 and networking
New Jersey, USA
To email @ me, see see my ordering Web page