TCP/IP for CP/M 2.2
Roger Schmidt
cpu can do it I cant see why CP/M can't on a Z80/8080/8085!
commod...@gmail.com
> Has anyone tried to code or know of a stack for TCP/IP? If the homebrew
> cpu can do it I cant see why CP/M can't on a Z80/8080/8085!
Hmm...I'm not a networking expert, but there is something called
LightweightIP (http://en.wikipedia.org/wiki/LwIP) that is a full TCP/
IP stack in 40KB of code and 10+ KB of data RAM...that's a little
large for CP/M purposes (CP/M 3, maybe,) but if there are any
unnecessary features, or better Z80-centric ways to code it (odds are
it's in C for portability, so that's entirely possible,) it might be
possible. I recall there being a TCP/IP implementation for C64, so I
wouldn't rule it out.
commod...@gmail.com
> cpu can do it I cant see why CP/M can't on a Z80/8080/8085!
Hmm. I'm not a networking expert, but I do know there is a small-
systems TCP/IP implementation called LightweightIP (http://
en.wikipedia.org/wiki/LwIP) that uses about 40KB of code. That's a
little hefty for CP/M purposes (CP/M 3 possibly excepted,) but perhaps
if there were any less than commonly-used features that could be
excised, and/or the code could be made smaller by rewriting it in Z80
assembler, it might work. I seem to recall there being a TCP/IP stack
for the Commodore 64, so I wouldn't rule out the possibility.
glen herrmannsfeldt
> Has anyone tried to code or know of a stack for TCP/IP? If the homebrew
> cpu can do it I cant see why CP/M can't on a Z80/8080/8085!
I haven't looked at it recently, but in the DOS days
there was NCSA Telnet. It ran on DOS machines
with no built in IP at all, directly connecting
to the ethernet card and doing all the TCP itself.
That might be bigger than 64K, but included in one EXE
file many ethernet cards, and also terminal emulation.
It also included ftp support, and probably some other
things that could have been done separately.
The source should still be available.
-- glen
Peter Hill
wrote:
I find it odd that TCP/IP needs that much space. It was developed back
when systems that ran UNIX didn't have much memory. TCP has origins
back in 1973. OS like RT-11, TSX-Plus and UNIX with TCP/IP ran on DEC
PDP 11's that had 64K addressing and maybe 256K total. You could
hardly allocate 1/4 of a multiuser computer to networking.
--
Peter Hill
Spamtrap reply domain as per NNTP-Posting-Host in header
Can of worms - what every fisherman wants.
Can of worms - what every PC owner gets!
commod...@gmail.com
wrote:
> I find it odd that TCP/IP needs that much space. It was developed back
> when systems that ran UNIX didn't have much memory. TCP has origins
> back in 1973. OS like RT-11, TSX-Plus and UNIX with TCP/IP ran on DEC
> PDP 11's that had 64K addressing and maybe 256K total. You could
> hardly allocate 1/4 of a multiuser computer to networking.
Well, as I stated, it is written in C, so it's probably not optimized,
and 40KB was just the figure Wikipedia gave for an unknown (probably
386) processor. Recoded in assembler, it might be significantly
smaller, I dunno.
Bill Gunshannon
Peter Hill <peter....@nospam.demon.co.uk> writes:
> On Tue, 17 Mar 2009 14:01:23 -0700 (PDT), commod...@gmail.com
> wrote:
>
>>On Mar 17, 3:20 pm, Roger Schmidt <ro...@ammeberg.com> wrote:
>>> Has anyone tried to code or know of a stack for TCP/IP? If the homebrew
>>> cpu can do it I cant see why CP/M can't on a Z80/8080/8085!
>>
>>Hmm...I'm not a networking expert, but there is something called
>>LightweightIP (http://en.wikipedia.org/wiki/LwIP) that is a full TCP/
>>IP stack in 40KB of code and 10+ KB of data RAM...that's a little
>>large for CP/M purposes (CP/M 3, maybe,) but if there are any
>>unnecessary features, or better Z80-centric ways to code it (odds are
>>it's in C for portability, so that's entirely possible,) it might be
>>possible. I recall there being a TCP/IP implementation for C64, so I
>>wouldn't rule it out.
>
> I find it odd that TCP/IP needs that much space. It was developed back
> when systems that ran UNIX didn't have much memory. TCP has origins
> back in 1973. OS like RT-11, TSX-Plus and UNIX with TCP/IP ran on DEC
> PDP 11's that had 64K addressing and maybe 256K total. You could
> hardly allocate 1/4 of a multiuser computer to networking.
Not under RT-11 and to the best of my knowledge, not under TSX either.
Under Ultrix-11, yes but certainly not in 256K of memory. Mine all
have the full 4Meg and still have a hard time effectively using
anything beyond the simplest of IP capabilities.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Bill H
> Has anyone tried to code or know of a stack for TCP/IP? If the homebrew
> cpu can do it I cant see why CP/M can't on a Z80/8080/8085!
No reason why it can't be done.
http://zx81-siggi.endoftheinternet.org/index.html
Running a tcp/ip stack and webserver on a ZX81 (z80, 64kb)
Bill H
commod...@gmail.com
Well, there you go. From the documentation for the uIP stack (http://
www.sics.se/~adam/uip/index.php/Main_Page) it uses: "The code size is
on the order of a few kilobytes and RAM usage can be configured to be
as low as a few hundred bytes." You could probably run this thing on a
middling TRS-80; making it work with CP/M should be a snap.
All...@localhost.net
wrote:
>Has anyone tried to code or know of a stack for TCP/IP? If the homebrew
>cpu can do it I cant see why CP/M can't on a Z80/8080/8085!
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.
FYI there are Ethernet to serial adaptors available and the serial
side only has to to do part of the packet assembly and higher
protoocals.
there is no reason why it can tbe done on Z80 and kin.
Allison
Roger Ivie
> That might be bigger than 64K, but included in one EXE
> file many ethernet cards,
As I recall, NCSA telnet required you to have a "packet driver" for your
network hardware loaded as a TSR. NCSA telnet spoke to the packet
driver, so there weren't (AFAIK) actual network drivers in the EXE.
--
roger ivie
ri...@ridgenet.net
glen herrmannsfeldt
There were two versions. One used packet drivers, which supported
boards that weren't included in the other.
I believe the non-packetdriver version came first.
There are also two versions for the Mac, one which drives
boards directly and the other that uses MacTCP.
-- glen
Peter Dassow
> Has anyone tried to code or know of a stack for TCP/IP? If the homebrew
> cpu can do it I cant see why CP/M can't on a Z80/8080/8085!
Roger, excuse for that, but every year it's the same, all questions
reoccur again and again, for me it's a Deja vu.
See also my blog entry at
http://www.z80.eu/blog/index.php?entry=entry080725-160000
Regards
Peter
All...@localhost.net
wrote:
Peter, Two problems. One being the need for multitasking
and that can be solved as CP/M does not inhibit that or there is
always MPM. The other is WHY, IP? Often people are asking
about TCP/IP without context and they both do not want all of IP
nor need all of IP. When you see PICs, and other small mpus
running tiny IP stacks the question is fair.
There are only a few good reasons for IP on z80, one being
connectivity as in access to resources on some local PC and
a serial port can do that... save for serial ports on PCs are extinct!
The other is experiment, what can I do if..? That has validity as
well and with various stacks out there it's certianly doable.
Let everyone forget Ethernet is not always IP nor is IP always
Eithernet. The likely best example is PPP/IP and SLIP. Both are
reasonable to implemnet to allow connection to a server.
Oh and if one really wants Ethernet there are Ethernet to USB and
Ethernet to serial adaptors and other networks protocals are such
as NetBeui, DECnet and IPX are still out there and supported by Linux
and even M$.
If people do the research there are at least 4 maybe more IP stacks
that could be run on Z80. Answer why and what for as may be trying
to do what PCs do is a bit too over the top.
Allison
Roger Schmidt
file? I cant seem to open it. I was looking at a WIZ chip strange that eh?
Roger
>
> Why? - It works good in my CP/M machine.
>
> The basis work is done during last year and I use TFTP for about 10
> months to transfer files in my home network.
>
> All what you need is the hardware interface. The CP/M 2.x software run
> without modification. We tried this with 3 very different CP/M
> systems.
>
> Next week we have our Annual Meeting - there are 4 CP/M machines with
> such a interface and this will be the first hard test for the 4
> network programs,
>
> I described the project here:
>
> http://www.kc85.susowa.homeftp.net/index.php?option=com_content&task=category§ionid=8&id=66&Itemid=147
>
> Feel free to ask me per Mail, if you are interested in using the work
> for your system.
>
> susowa
glen herrmannsfeldt
> Peter, Two problems. One being the need for multitasking
> and that can be solved as CP/M does not inhibit that or there is
> always MPM. The other is WHY, IP? Often people are asking
> about TCP/IP without context and they both do not want all of IP
> nor need all of IP. When you see PICs, and other small mpus
> running tiny IP stacks the question is fair.
I don't believe that multitasking is required, though
it does make it easier.
> There are only a few good reasons for IP on z80, one being
> connectivity as in access to resources on some local PC and
> a serial port can do that... save for serial ports on PCs are extinct!
I previously wrote here about NFS. NFS is traditionally
done over UDP, which is somewhat simpler than TCP.
Maybe one of the easier places to start is TFTP, which is
a UDP based file transfer protocol. In the days of diskless
Suns, the process went something like:
RARP to find my IP address.
BOOTPARAMD (I believe also UDP based) to find the server address
and boot file name.
TFTP to load the second level boot program, which is then run.
RARP to find my IP address
BOOTPARAMD to find the NFS server and root file system
NFS mount the root file system
load and execute the unix kernel.
The first three steps are done using a fairly small
(by today's standards) ROM.
> The other is experiment, what can I do if..? That has validity as
> well and with various stacks out there it's certianly doable.
> Let everyone forget Ethernet is not always IP nor is IP always
> Eithernet. The likely best example is PPP/IP and SLIP. Both are
> reasonable to implemnet to allow connection to a server.
Yes, but you still have to implement IP in those cases,
and TCP if you want a TCP based protocol.
> Oh and if one really wants Ethernet there are Ethernet to USB and
> Ethernet to serial adaptors and other networks protocals are such
> as NetBeui, DECnet and IPX are still out there and supported by Linux
> and even M$.
It shouldn't be hard to interface an ISA ethernet board
to a Z80/8080 system. Some have their own buffer, others
don't, and that will make some difference.
> If people do the research there are at least 4 maybe more IP stacks
> that could be run on Z80. Answer why and what for as may be trying
> to do what PCs do is a bit too over the top.
-- glen
Steven Hirsch
>> Oh and if one really wants Ethernet there are Ethernet to USB and
>> Ethernet to serial adaptors and other networks protocals are such
>> as NetBeui, DECnet and IPX are still out there and supported by Linux
>> and even M$.
>
> It shouldn't be hard to interface an ISA ethernet board
> to a Z80/8080 system. Some have their own buffer, others
> don't, and that will make some difference.
Software stack aside, Alex Freed's Z80 card for the Apple 2 can easily be
fitted up with a FIFO-to-USB adapter. Right now we have ZMODEM support
working, but a simple IP stack shouldn't be too much trouble. The card has
512KB of bankable memory with choice of 8 or 16k common area. Also a 27C512
PROM if a stack could be made rom-able.
Jonathan Graham Harston
> I find it odd that TCP/IP needs that much space. It was developed back
> when systems that ran UNIX didn't have much memory. TCP has origins
http://mdfs.net/Apps/Networking/EcoTCP
--
J.G.Harston - j...@arcade.demon.co.uk - mdfs.net/User/JGH
PDP-11 BBC BASIC development - http://mdfs.net/PDP11/BBCBasic/blog
All...@localhost.net
wrote:
Here uIP anotehr small IP stack.
http://www.sics.se/~adam/uip/index.php/Main_Page
Allison
All...@localhost.net
wrote:
>Has anyone tried to code or know of a stack for TCP/IP? If the homebrew
>cpu can do it I cant see why CP/M can't on a Z80/8080/8085!
A lot of answers but lets try questions as I suspec the answers are
not matching the question.
Generally the answer is yes to the question ans presented. However I
think that wuation is not a complete one.
First Z80s have done networking for years, the hams had Packet Radio
which is simplest terms was IP over radio. Commies, and all mannor
of other non z80 systems were used as well. The commmon use for that
connectivity was Email and propagation data that was brodcast to all
subscribed and connected recipients. the limitation of the time was
data rate (1200 was common) and 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 the question was asked
the requestor had a request that 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 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).
Allison
susowa
> "I want TCP/IP
> suite for my one off CP/M system that has Ethernet ready to go and for
> under $xx.00 dollars.".
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 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.
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.
> 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 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.
Roger Schmidt
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!
Roger
All...@localhost.net
wrote:
>To answer some of your questions;
>
>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
Been following the project for years.
>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!
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.
>
>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!
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.
Allison
All...@localhost.net
wrote:
>On 21 Mrz., 00:52, Alli...@localhost.net wrote:
>> "I want TCP/IP
>> suite for my one off CP/M system that has Ethernet ready to go and for
>> under $xx.00 dollars.".
>
>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 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.
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.
>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
There aren't any to speak of! Thats 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.
>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.
as a user there is no $59.99 solution for CP/M, never was. The bit of
networking seen back when (outside of packet radio) was typically
1000-2000 dollare per node and required serious effort to get going.
Far from PC stle plug and play.
>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.
no 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.
>> 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 first step, is to get it to work. Then you can think over a
>integration in the system.
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.
>For single application tasks there is no need for bios-integration.
True, but that also 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.
Allison
susowa
> 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!
> Roger
Hallo Roger,
what is done:
- 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
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.
You see - I DO and you can discuss about solutions !
The better way would be:
- 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 !
- shame about you :-)
glen herrmannsfeldt
> 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 an NFS server for Windows, free last time
I looked. I don't know SMB well at all, so I won't try
to compare them.
-- glen
susowa
> is involved SMB?
FTP - Yes
SCP -No
Thppd - ???
SMB - I think this makes no sense (over 100 message-types!), too much
for me :-)
> FYI browsing and seriving files is relly no different to the IP stack
> and it's only different to the application layered on it.
I know, technically it isn't a problem but my time is limited. First
the protocols I want use.
> as a user there is no $59.99 solution for CP/M, never was. The bit of
> networking seen back when (outside of packet radio) was typically
> 1000-2000 dollare per node and required serious effort to get going.
> Far from PC stle plug and play.
Our KC85 Modul for networking and usb (vinculum VDIP2) costs about 130
EUR. So far we have about 30 advance orders.
> no not true. 4mhz is plenty fast if the physical layer is either slow
> (SLIP or PPP on serial line)
And the usability for the user isn't one.
> or some external device handles the fast
> work like the ethernet to serial device I highlighted earlier.
Not freely programmable - a 'must have' for me.
> True, but that also 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.
Thats true, but this is the problem of CP/M. It has no driver concept
for hardware drivers or a HAL like windows. Every hardware expansion
makes it more incompatible than before. I can't solve CP/M problems
with new hardware, thats why I selected the PIO - Z80 standard in
every Z80 system but the I/O-address has to be chosen from the user
system needs.
All...@localhost.net
wrote:
>> Seems trivial enough do you plan to use FTP, SCP, Thppd or if winders
>> is involved SMB?
>
>FTP - Yes
>SCP -No
>Thppd - ???
Simple server good for files, outgoing.
>SMB - I think this makes no sense (over 100 message-types!), too much
>for me :-)
Winders uses that for file transfers via IP.
>> FYI browsing and seriving files is relly no different to the IP stack
>> and it's only different to the application layered on it.
>
>I know, technically it isn't a problem but my time is limited. First
>the protocols I want use.
>
>
>> as a user there is no $59.99 solution for CP/M, never was. The bit of
>> networking seen back when (outside of packet radio) was typically
>> 1000-2000 dollare per node and required serious effort to get going.
>> Far from PC stle plug and play.
>
>Our KC85 Modul for networking and usb (vinculum VDIP2) costs about 130
>EUR. So far we have about 30 advance orders.
Yes, that is the most economical solution and does a large portion of
the protocal work. But the solution while solving some of the
problems does not solve all.
However on this side of the pond the KC85 is rarely seen.
>
>> no not true. 4mhz is plenty fast if the physical layer is either slow
>> (SLIP or PPP on serial line)
>
>And the usability for the user isn't one.
Not sure what you mean there. For CP/M like work 4mhz is fast
enough but it depends on what you want to do.
>
>> or some external device handles the fast
>> work like the ethernet to serial device I highlighted earlier.
>
>Not freely programmable - a 'must have' for me.
hence the Vinculum VDIP2.
>
>> True, but that also 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.
>
>Thats true, but this is the problem of CP/M. It has no driver concept
>for hardware drivers or a HAL like windows. Every hardware expansion
Actually the idea of loadable hardware drivers in CP/M is one of
implementation and it was done. For example the Konan and Teletek
hard disk boards for S100 installed by trapping the bios calls and
vectoring to high memory (you did have to resize to leave space)
and all the ZCPR add ons had RSXs.
>makes it more incompatible than before. I can't solve CP/M problems
>with new hardware, thats why I selected the PIO - Z80 standard in
>every Z80 system but the I/O-address has to be chosen from the user
>system needs.
The HAL is the BIOS. From the bios level the hardware is abstracted
to match the BDOS logical interface. the problem is once you start
talking to deviced directly the OS is not helping you. For modem like
work (FTP) thats reasonable. If the hardware expansion is a serial
port that is by far the most common and most likely to be already
available. Even serial has you dealing with the "modem serial port"
problem already mentioned.
Also PIO is not standard. I have at least 5 differnt and common
(amproLB+, DEC VT180, NS* Horizon, Compupro, CCS, Altair)
systems where PIO is unidirectional. The solution is an adaptor
in each case. Serial is universal, very few Z80 systems only have
one serial so you can take advanatage of the second part that was
formerly used for a modem.
Allison
All...@localhost.net
wrote:
>On 21 Mrz., 15:46, Roger Schmidt <ro...@ammeberg.com> wrote:
>> 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!
>> Roger
>
>Hallo Roger,
>
>what is done:
>
>- 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
That is useful for serving files.
>These programs are ready, I use they often with my machine and PC's
>with linux or windows.
I've done that over serial lines using PPP to a PPP host. FTP is
a prime apps as it can do both PUTs and GETs.
>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.
>
>
>You see - I DO and you can discuss about solutions !
>
>
>The better way would be:
>
> - 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 !
>- shame about you :-)
Send me a KC85 and I'd be interested. My solution leans toward S100
and my AMproLB+ and VT180 systems So serial lines are common one
those where PIO is different or nonexistent for for the those.
Actually I've been playing more with storage (non rotating disk) and
and other things. I do have a network going that I designed for
myself to link multiple cp/m systems but never included the PCs
as the network was pre-IP (looks like DECNET DDCMP).
Allison
Roger Ivie
> Thppd - ???
Doubtless a typo for httpd (a web server).
--
roger ivie
ri...@ridgenet.net
All...@localhost.net
(Edmund H. Ramm) wrote:
>In <13a8s4ldckauhuck2...@4ax.com> All...@localhost.net writes:
>
>> [...]
>> First Z80s have done networking for years, the hams had Packet Radio
>> which is simplest terms was IP over radio.
>> [...]
>
> That was plain AX.25, i.e. layer 2. IP wasn't involved.
>
> Eddi ._._.
That grew to include higher layers.
Allison
KB1GMX ..._._
All...@localhost.net
wrote:
>On 2009-03-21, susowa <susow...@web.de> wrote:
>> Thppd - ???
>
>Doubtless a typo for httpd (a web server).
Yes, it was a too but it's thttpd. I use the mini version all the
time at work to move files under uClinux.
Allison
Roger Ivie
Ah, yes. I've run thttpd for years under NetBSD on PC, Mac (PowerPC),
and VAX. Nice little webserver.
--
roger ivie
ri...@ridgenet.net
susowa
> >Thppd - ???
> Simple server good for files, outgoing.
Ah - now I understand. The basis is the rfc for http and thttpd is the
(an) application that uses it.
> >SMB - I think this makes no sense (over 100 message-types!), too much
> >for me :-)
> Winders uses that for file transfers via IP.
Like I wrote before, I know SMB and I reviewed it last year in the
beginning of the software development. There are several versions of
SMB from the early days up to WindowsXP, in Vista MS cleared up the
"monster" to version 2.0 with much less message types than 1.x. I see
no sense in making CP/M compatible with SMB, you need too much code to
handle such a extensive protocol.
> Yes, that is the most economical solution and does a large portion of
> the protocal work. But the solution while solving some of the
> problems does not solve all.
I'm not the CP/M-godfather and solve all problems for you but I can
show you one possible way to get TCPIP over ethernet for your system -
not more.
> >> no not true. 4mhz is plenty fast if the physical layer is either slow
> >> (SLIP or PPP on serial line)
> >And the usability for the user isn't one.
> Not sure what you mean there. For CP/M like work 4mhz is fast
> enough but it depends on what you want to do.
In my opinion is and never was serial an option for TCPIP because you
have to do the stack in software:
IP-Layer -> UDP/TCP Layer -> application Layer for the rfc-protocol ->
application that uses the rfc
What do you think how many percent of your CPU performance remain for
the last? I think not enough to reach a agreeable usability for the
user. The WIZnet offloads the (code extensive and performance hungry)
first and second task from the system, so I have the CPU for part 3
and 4. And this works fast, seamless and very responsive in my slow
machine with 1,75 MHz.
> >> or some external device handles the fast
> >> work like the ethernet to serial device I highlighted earlier.
> >Not freely programmable - a 'must have' for me.
> hence the Vinculum VDIP2.
We spoke about the WIZnet !
> Actually the idea of loadable hardware drivers in CP/M is one of
> implementation and it was done. For example the Konan and Teletek
> hard disk boards for S100 installed by trapping the bios calls and
> vectoring to high memory (you did have to resize to leave space)
> and all the ZCPR add ons had RSXs.
You are right. I use NZCOM and ZSDOS/ZDDOS with ide-harddisk or ide-
flash in my system. But you speak here over the last step, this can be
a integration in the system. I have the full sources for our bios and
can make my own compatible system.
But at this time I have to play more with the software and test it
more to find weaks and possibly hidden errors.
Next will be a usable TCP-application, so far all protocols
(DHCP,DNS,TFTP) uses UDP. I do my projects step by step and make the
improvements, when I think the time is right for.
> The HAL is the BIOS. From the bios level the hardware is abstracted
> to match the BDOS logical interface.
OK - please tell me the number of the bios-call for talk to a serial
device or talk to a network!
> the problem is once you start talking to deviced directly the OS is not helping you.
I know this problem but the original CP/M has no standards for - you
must expand and define the bios-vector table by yourself.
> Also PIO is not standard. I have at least 5 differnt and common
> (amproLB+, DEC VT180, NS* Horizon, Compupro, CCS, Altair)
> systems where PIO is unidirectional. The solution is an adaptor
> in each case.
No - the solution is an own interface card with its own PIO - I never
wrote, you have to use a PIO of your system. And because the Z80PIO is
standard for a Z80-system this is a STANDARD!
> Send me a KC85 and I'd be interested. My solution leans toward S100
> and my AMproLB+ and VT180 systems So serial lines are common one
> those where PIO is different or nonexistent for for the those.
OK - successful wishes for your aims but I'm afraid that it finishes
like the other tries.
All...@localhost.net
wrote:
>On 21 Mrz., 23:21, Alli...@localhost.net wrote:
>> >Thppd - ???
>> Simple server good for files, outgoing.
>
>Ah - now I understand. The basis is the rfc for http and thttpd is the
>(an) application that uses it.
>
>
>> >SMB - I think this makes no sense (over 100 message-types!), too much
>> >for me :-)
>> Winders uses that for file transfers via IP.
>
>Like I wrote before, I know SMB and I reviewed it last year in the
>beginning of the software development. There are several versions of
>SMB from the early days up to WindowsXP, in Vista MS cleared up the
>"monster" to version 2.0 with much less message types than 1.x. I see
>no sense in making CP/M compatible with SMB, you need too much code to
>handle such a extensive protocol.
>
That forces winders uses that communicate with non winders to use more
IP friendly apps. I have no problem with that.
>> Yes, that is the most economical solution and does a large portion of
>> the protocal work. But the solution while solving some of the
>> problems does not solve all.
>
>I'm not the CP/M-godfather and solve all problems for you but I can
>show you one possible way to get TCPIP over ethernet for your system -
>not more.
I've solved it for mine. But the solution is far from usiversal and I
take advantage of a banked bios for code space and z80s running faster
than 6mhz.
>
>> >> no not true. 4mhz is plenty fast if the physical layer is either slow
>> >> (SLIP or PPP on serial line)
>> >And the usability for the user isn't one.
>> Not sure what you mean there. For CP/M like work 4mhz is fast
>> enough but it depends on what you want to do.
>
>In my opinion is and never was serial an option for TCPIP because you
>have to do the stack in software:
There is but the stack is smaller as the physical layer is simpler
thats where you get to compromize.
>IP-Layer -> UDP/TCP Layer -> application Layer for the rfc-protocol ->
>application that uses the rfc
>
>What do you think how many percent of your CPU performance remain for
>the last? I think not enough to reach a agreeable usability for the
>user. The WIZnet offloads the (code extensive and performance hungry)
>first and second task from the system, so I have the CPU for part 3
>and 4. And this works fast, seamless and very responsive in my slow
>machine with 1,75 MHz.
Well, at 1.75mhz I personally consider a z80 as crippled severely as
the slowest parts are 2.5mhz. With that constraint you really do have
to push as much offboard or have to expect poor useability.
>> >> or some external device handles the fast
>> >> work like the ethernet to serial device I highlighted earlier.
>> >Not freely programmable - a 'must have' for me.
>> hence the Vinculum VDIP2.
>
>We spoke about the WIZnet !
>
We did. I've looked at a different part from another source.
There are a few similar parts to do the task out there.
>> Actually the idea of loadable hardware drivers in CP/M is one of
>> implementation and it was done. For example the Konan and Teletek
>> hard disk boards for S100 installed by trapping the bios calls and
>> vectoring to high memory (you did have to resize to leave space)
>> and all the ZCPR add ons had RSXs.
>
>You are right. I use NZCOM and ZSDOS/ZDDOS with ide-harddisk or ide-
>flash in my system. But you speak here over the last step, this can be
>a integration in the system. I have the full sources for our bios and
>can make my own compatible system.
With full source that makes life much easier.
>But at this time I have to play more with the software and test it
>more to find weaks and possibly hidden errors.
>Next will be a usable TCP-application, so far all protocols
>(DHCP,DNS,TFTP) uses UDP. I do my projects step by step and make the
>improvements, when I think the time is right for.
>
>
>> The HAL is the BIOS. From the bios level the hardware is abstracted
>> to match the BDOS logical interface.
>
>OK - please tell me the number of the bios-call for talk to a serial
>device or talk to a network!
Well since CP/M never had a network theres no bios call but there are
more than a few for serial and if IObyte is used then you can used the
same interface point to handle more than a serial line.
>
>> the problem is once you start talking to deviced directly the OS is not helping you.
>
>I know this problem but the original CP/M has no standards for - you
>must expand and define the bios-vector table by yourself.
Not unreasonable.
>
>> Also PIO is not standard. I have at least 5 differnt and common
>> (amproLB+, DEC VT180, NS* Horizon, Compupro, CCS, Altair)
>> systems where PIO is unidirectional. The solution is an adaptor
>> in each case.
>
>No - the solution is an own interface card with its own PIO - I never
>wrote, you have to use a PIO of your system. And because the Z80PIO is
>standard for a Z80-system this is a STANDARD!
? I have at least one system that has No parallel IO at all, and
Z80PIO while a cool part is not a standard for CP/M based systems.
In fact the larger volume of Z80 system do not use the CTC, PIO or SIO
as back when these were very expenive compared to most of the other
parallel, serial and timer chips. Of all my systems (outside of
homebrew) I have only one that uses two of the three. The AmproLB+
uses the CTC and SIO/DART. This is why I am surprized.
>> Send me a KC85 and I'd be interested. My solution leans toward S100
>> and my AMproLB+ and VT180 systems So serial lines are common one
>> those where PIO is different or nonexistent for for the those.
>
>OK - successful wishes for your aims but I'm afraid that it finishes
>like the other tries.
It's working now doing PPP over serial port at the limit for the
slowest system (9600 baud). It does eat about a 4k chunk of
space but I think there are room for improvement. I found removing
DHCP and ARP and using static address saves a potload of space.
Another trick one of the big system idea is to slot in the high
protocal handlers as needed. My biggest problem is is I do some of
this on ARM and Blackfin where space, speed and hardware support
are built in so you often dont think of the fine details. Many of
those I work with haven't a clue what Z80 can do, one equates it as
less than PIC18, imagine that!
Keep up up to date on your progress.
Allison
Mr Emmanuel Roche, France
> Well since CP/M never had a network...
Allison, how I love you when you have such a stubborn bad faith!
Have you ever heard about Digital Research? Read on.
- "CP/NET Reference Manual"
Digital Research
Fifth Edition: November 1982
Section 1: CP/NET Overview
-----------------------------
"By separating the logical operating system from the hardware
environment and placing all hardware-independent code in a separate I/
O module, CP/M and MP/M II have gained widespread industry acceptance.
The CP/NET operating system uses this same design approach. CP/NET is
network independent. The Slave Network I/O System (SNIOS) module
contains all network-dependent code for the requester. The Network
Interface Process (NETWRKIF) module contains all network-dependent
code for the server. Logical messages passed to and from the SNIOS or
NETWRKIF are transmitted over an arbitrary network between servers and
requesters using an arbitrary network protocol."
Section 3.3 CP/NET Function Extensions to CP/M (2.2)
------------------------------------------------------------
(...) This section describes CP/NET functions that have no counterpart
under CP/M. These include MP/M II functions that do not exist under CP/
M, as well as a set of dedicated CP/NET functions. All of these
functions adhere to exactly the same calling conventions as the rest
of CP/M and all follow the same conventions regarding return codes.
FUNCTION 38: ACCESS DRIVE
FUNCTION 39: FREE DRIVE
FUNCTION 42: LOCK RECORD
FUNCTION 43: UNLOCK RECORD
FUNCTION 45: SET BDOS ERROR MODE
FUNCTION 64: LOGIN
FUNCTION 65: LOGOFF
FUNCTION 66: SEND MESSAGE ON NETWORK
FUNCTION 67: RECEIVE MESSAGE ON NETWORK
FUNCTION 68: GET NETWORK STATUS
FUNCTION 69: GET CONFIGURATION TABLE ADDRESS
FUNCTION 70: SET COMPATIBILITY ATTRIBUTES
FUNCTION 71: GET SERVER CONFIGURATION TABLE ADDRESS
FUNCTION 106: SET DEFAULT PASSWORD
Yours Sincerely,
Mr. Emmanuel Roche, France
All...@localhost.net
Allison
All...@localhost.net
(Edmund H. Ramm) wrote:
>In <ihuas4d3c5ui6f1bb...@4ax.com> All...@localhost.net writes:
>
>>On Sat, 21 Mar 2009 18:18:11 +0000 (GMT), ehr...@dk3uz.ampr.org
>>(Edmund H. Ramm) wrote:
>
>>>In <13a8s4ldckauhuck2...@4ax.com> All...@localhost.net writes:
>>>
>>>> [...]
>>>> First Z80s have done networking for years, the hams had Packet Radio
>>>> which is simplest terms was IP over radio.
>>>> [...]
>>>
>>> That was plain AX.25, i.e. layer 2. IP wasn't involved.
>
>> That grew to include higher layers.
>
> Not on a Z80.
Ok, tell me why not? Or are you saying the media level parts require
fast IO that z80 can't directly suppoort with PIO.
Allison
>
> Eddi ._._.
Mr Emmanuel Roche, France
> Not relevent to IP or establishing the needed links to an IP driver.
It is you, who is "not relevent"! CP/NET is protocol-independent!
Ever heard about Gary Kildall? Read on.
CP/NET (BYTE, June 1981)
------
CP/NET, introduced in late 1980, leads a series of network-oriented
operating systems that distribute operating system functions
throughout a network of non-homogeneous processors. CP/NET connects CP/
M requesters to MP/M servers through the use of an arbitrary network
protocol. Similar to CP/M and MP/M, CP/NET consists of the invariant
portion, along with a set of field-reconfigurable subroutines that
define the interface to a particular network. For purposes of CP/NET,
this interface need only provide point-to-point data-packet
transmission. Since the actual data transmission media are unimportant
to CP/NET, any one of the number of standard protocols can be used,
from low-speed RS-232C through high-speed Ethernet. Physical
connections are also arbitrary, allowing active hub-star, ring, and
common-bus architectures.
The invariant portions of CP/NET operate under a standard CP/M system
to direct various system calls over the network to an MP/M server. The
MP/M server, in turn, responds to network requests by simulating the
actions of CP/M. This simulation is transparent to an application
program: any program operating under standard CP/M operates properly
in the network environment.
Suppose, for example, you wish to store common business letters in a
central data base under MP/M and access these letters from a CP/Mbased
word processor. You begin by assigning one local disk drive to the MP/
M master, using the CP/NET interface. You then direct your word
processing system to read the particular letter on the assigned drive,
causing the data to be obtained from the server rather than from the
local disk. After local update using your word processor, you can
print the result on your local printer or optionally assign your
listing device to the network for printing at the MP/M server.
CP/NET is accompanied by three related network operating systems: CP/
NOS, MP/NET, and MP/NOS. CP/NOS is, in effect, a diskless CP/M, which
can be stored in read-only memory, and that operates with a console,
memory, and network interface. MP/NET, on the other hand, is a
complete MP/M system with an embedded network interface that, like CP/
NET, allows local devices to be reassigned to the network. MP/NET
configurations allow MP/M systems as both requesters and servers with
CP/M requesters. Finally, MP/NOS contains the real-time portion of MP/
M without local disk facilities. Like CP/NOS, MP/NOS performs all disk
functions through the network.
The interface protocol is publicly defined so that non-MP/M or non-CP/
M systems can participate in network interactions. A server interface
for the VAX 11/780, for example, is under preparation so that it can
perform I/O functions for a large number of MP/M and CP/M requesters.
The principal advantage of CP/NET is that all CP/M-compatible software
becomes immediately available for operation in the network
environment, solving the problem that builders of network hardware
face: the total absence of application software. Although the promise
is there, networking is in its infancy, and CP/NET is truly a software
package awaiting the evolution of suitable hardware.
Roger Ivie
> Allison wrote:
>
>> Not relevent to IP or establishing the needed links to an IP driver.
>
> It is you, who is "not relevent"! CP/NET is protocol-independent!
Allison's point is that CP/NET doesn't provide the hooks necessary to do
IP. Saying that it is protocol-independent does not change that.
CP/NET would be *using* IP, not *providing* it.
--
roger ivie
ri...@ridgenet.net
All...@localhost.net
Read the header It says "TCP/IP for CP/M 2.2".
You are still not relevent.
If you really must force a new thread the answer is still there is
nothing there to assist implementing IP. There are a few things
there that may assist applications. However the NIOS implements
the networking and there is nothing there it assist developing IP.
The good news is there nothing there to inhibit it any more than
CP/M 2.x would. Also as I already pointed out MPM would he helpful
for those that might desire mutitasking support but it's not a hard
requirement.
Allison
Ole Christensen
> Has anyone tried to code or know of a stack for TCP/IP? If the >homebrew
> cpu can do it I cant see why CP/M can't on a Z80/8080/8085!
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)":
http://www.a2retrosystems.com/
http://uzix.sourceforge.net/
http://www.picoweb.net/
but sure are: You do need a solder iron,
fantasy and the will...
Good luck...!
<ole>
-----
Ole Christensen
> Hey Thats exactly what i was looking for! But what exactly is a PMA
> file? I cant seem to open it. I was looking at a WIZ chip strange that eh?
>
> Roger
Roger if, (and only IF), You manages to drag the source out
of that strange thing could You please send me a copy
in a _common_ compressed format?, (zip, rar, gz, tgz whatever)...
You know the address...
Thanks...!
<ole>
-----
Bill Gunshannon
ehr...@dk3uz.ampr.org (Edmund H. Ramm) writes:
> In <ge3ds4dod4bafvrvq...@4ax.com> All...@localhost.net writes:
>
>>On Sun, 22 Mar 2009 16:09:44 +0000 (GMT), ehr...@dk3uz.ampr.org
>>(Edmund H. Ramm) wrote:
>
>>>In <ihuas4d3c5ui6f1bb...@4ax.com> All...@localhost.net writes:
>>>
>>>>On Sat, 21 Mar 2009 18:18:11 +0000 (GMT), ehr...@dk3uz.ampr.org
>>>>(Edmund H. Ramm) wrote:
>>>
>>>>>In <13a8s4ldckauhuck2...@4ax.com> All...@localhost.net writes:
>>>>>
>>>>>> [...]
>>>>>> First Z80s have done networking for years, the hams had Packet Radio
>>>>>> which is simplest terms was IP over radio.
>>>>>> [...]
>>>>>
>>>>> That was plain AX.25, i.e. layer 2. IP wasn't involved.
>>>
>>>> That grew to include higher layers.
>>>
>>> Not on a Z80.
>
>> Ok, tell me why not?
>
>
>> Or are you saying the media level parts require fast IO that z80 can't
>> directly suppoort with PIO.
>
> radio program running on a Z80.
Sorry to disappoint you, but here it is straight fromt he horse's mouth.
http://www.ka9q.net/code/ka9qnos/
"My KA9Q NOS TCP/IP package began life way back in late 1985 on a
surplus Xerox 820 computer board running CP/M with a 4 MHz Zilog
Z-80 CPU, 64KB of RAM and a 8" floppy drive holding all of 243KB.
("KB" stands for kilo bytes -- not mega or giga)."
bill KB3YV
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
All...@localhost.net
<ole2...@newsguy.com> wrote:
>Roger Schmidt skrev:
> > Has anyone tried to code or know of a stack for TCP/IP? If the >homebrew
> > cpu can do it I cant see why CP/M can't on a Z80/8080/8085!
>
>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)":
>
> 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!)
and you happen to like *nix.
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 callanges.
>but sure are: You do need a solder iron,
>fantasy and the will...
I agree the will has to be here as everyone thats done it has not done
a unique solution that isn't portable.
Allison
>Good luck...!
><ole>
>-----
Uwe Nass
>
> Sorry to disappoint you, but here it is straight fromt he horse's mouth.
>
> http://www.ka9q.net/code/ka9qnos/
>
> "My KA9Q NOS TCP/IP package began life way back in late 1985 on a
> surplus Xerox 820 computer board running CP/M with a 4 MHz Zilog
> Z-80 CPU, 64KB of RAM and a 8" floppy drive holding all of 243KB.
> ("KB" stands for kilo bytes -- not mega or giga)."
>
> bill KB3YV
>
Hi Bill,
but where are the CP/M sources or binaries????
Greetings,
Uwe.
Bill Gunshannon
Don't know. Maybe lost. I haven't worked with the KA9Q code for close
to 20 years. And, even then, I did mostly Unix versions (I did a port
to XENIX on the Tandy Model 16 and maintained it for a while.) You
could always ask Phil Karn (KA9Q). There is contact information on
his web site. In fact, I may do that myself. If I do and I can get
old copies of the code, I'll let people here know. I probably even
have them in my collection of 8" disks at home, but unfortunately at
this point in time all of that is packed and is not likely to get unpacked
again for a couple of years when I retire.
bill
larsn...@adelphia.net
Back to your original question, what is available out there for
connecting CP/M Z80 systems to the internet?
There are several all software solutions that use a serial port that
use SLIP through a PC to get on a network. Howver, Susowa's solution
uses the WIZNET chip to connect directly to a network. He also uses
an ARM processor to interface the Z80 to WIZNET via a PIO chip. I
have looked at his code (which is only about 4k total) and there is
only a very small portion that needs to be customized. I believe it
can be easily adapted to a wide range of systems. He has done most of
the heavy lifting. Furthermore the project is pretty well
documented. The pity is that he is in the former East Germany and his
work has had little exposure in the English speaking CP/M community.
Almost all of his work is either in German or Bable-Fish translated
English which makes reading very difficult. I too have ordered some
WIZNET modules and plan to use his code as a starting point to bring
internet connectivity to CP/M.
Lars
Herbert Johnson
>
> >> Sorry to disappoint you, but here it is straight from the horse's mouth.
>
> >>http://www.ka9q.net/code/ka9qnos/
>
> >> "My KA9Q NOS TCP/IP package began life way back in late 1985 on a
> >> surplus Xerox 820 computer board
> > but where are the CP/M sources or binaries????
> Don't know. Maybe lost. I haven't worked with the KA9Q code for close
> to 20 years. And, even then, I did mostly Unix versions (I did a port
> to XENIX on the Tandy Model 16 and maintained it for a while.) You
> could always ask Phil Karn (KA9Q). There is contact information on
> his web site. In fact, I may do that myself.
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
and they depend
on specific TNC hardware with its own software. (Yes, you can buy
TNC's today. Then what?)
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.)
Herb Johnson
retrotechnology.com
Mr Emmanuel Roche, France
When Allison mentioned KA9Q, several months ago, I made a
(unsuccessful) search for it (A few months later, a copy of KA9Q was
found.). Among other things, I got the following message:
Date : Thu, 08 Oct 1992 17:22:00 GMT
From : atha!aupair.cs.athabascau.ca!tech@... (Richard Loken)
Subject: Re: Is KA9Q still available for CP/M systems?
fraser_h@... writes:
>Many times I've seen mention that KA9Q was originally developed for
>Z80 CPM systems. Is that original distribution still available anywhere?
If you should stumble across a copy I would dearly love to see it.
Mr. Karn has a religious objection to CP/M and waxes rhetorical about
8 bits and TCP/IP when the subject comes up. The song is to the
effect that 8 bits are dead and gone and XT boards can be had loaded
for $50.00. Phil aparantly has the floppies in his garage but intends
to leave them there.
Ironically the tcp-group has been tearing itself apart on a similar
vein over the last year. To whit, NOS and DOS have overstayed their
welcome so why use them when you can get a 40 MHz 386 machine fully
configured for $1500.00 Canadian and run Unix with native TCP/IP. I
notice the "get out of the dark ages" rhetoric is less warmly received
when it is directed at NOS instead of CP/M.
I think the demise of NOS and DOS is inevitable as a true operating
system that will handle lots of memory for Intel chips becomes
popular. At that time NOS, which is as much a task scheduler as a TCP/
IP package will be outmoded by TCP/IP services that are written to run
under the control of said OS. Rumours that Microsoft are going to
dump DOS as it now is known are starting to crop up - it may be
called DOS and look like DOS to they the user but the similarity will
end there.
Hmmppph. The uninitiated would think I knew what I was talking about
but I am sure many of you can see through the smoke and mirrors.
--
Richard Loken VE6BSV : "ISDN (acronym)
Athabasca University, Athabasca, Alberta Canada : Innovations
tech@... : Subscribers Don't
Need."
{atha|aunro}!cs.athabascau.ca!tech : - some sorehead
or other
Ole Christensen
> On Mon, 23 Mar 2009 11:15:29 +0100, Ole Christensen
> <ole2...@newsguy.com> wrote:
>
>> Roger Schmidt skrev:
>>> Has anyone tried to code or know of a stack for TCP/IP? If the
>homebrew
>>> cpu can do it I cant see why CP/M can't on a Z80/8080/8085!
>> 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)":
>>
>> http://www.a2retrosystems.com/
>
> Contiki I presume... still not CP/M.
good point,... agree!
> 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
good point again,... agree!
> 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!)
> and you happen to like *nix.
The bad thing here are that what i was, in my mind,
pointing You to should have been:
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
---
(sorry)...
(still not CP/M,... agree!)
how hard can it be...?
>
>
>> http://www.picoweb.net/
>
> Interesting application of a Atmel AVR 8bit risc.
> Not z80 and not CP/M
good point again,... agree!
> though the code for it is GNU and compact. However porting it
> to other CPUs may present callanges.
>
>> but sure are: You do need a solder iron,
>> fantasy and the will...
>
> I agree the will has to be here as everyone thats done it has not 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>
------
Bill Gunshannon
Herbert Johnson <herbrj...@gmail.com> writes:
>> > Bill Gunshannon wrote
>>
>> >> Sorry to disappoint you, but here it is straight from the horse's mouth.
>>
>> >>http://www.ka9q.net/code/ka9qnos/
>>
>> >> "My KA9Q NOS TCP/IP package began life way back in late 1985 on a
>> >> surplus Xerox 820 computer board
>> > but where are the CP/M sources or binaries????
>> Don't know. Maybe lost. I haven't worked with the KA9Q code for close
>> to 20 years. And, even then, I did mostly Unix versions (I did a port
>> to XENIX on the Tandy Model 16 and maintained it for a while.) You
>> could always ask Phil Karn (KA9Q). There is contact information on
>> his web site. In fact, I may do that myself.
> 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.
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 couldtry 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 Joisey 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.)
> I don't
> pretend to know much about this, but my impression is that KA9Q moved
> quickly to IBM PC
> versions,
He did move to the PC quickly, but other versions thrived as well.
> and/or to use "TNC" or terminal network controller hardware
> to run "lower" parts of the
> protocols.
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.
> 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.
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.
> 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
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.
> (Yes, you can buy
> TNC's today. Then what?)
Get a ham license and put it on the air. :-)
> 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.)
Looks like you found it after all. I'll have to grab a copy myself before
it really disappears.
Bill Gunshannon
Interesting and not at all surprising. But then, it was strictly targeted
at the Ham Radio domain and they can be very strange birds when they want,
especially in the US.
_firstname_@lr_dot_los-gatos_dot_ca_dot_us
assertions. For the record, I don't know of any working TCP/IP
package for cp/m; in particular none that uses Ethernet, rather than
serial (SLIP/PPP/X.25) or parallel (PLIP).
In article <gqakke$22n$1...@news-a.stw-bonn.de>,
Uwe Nass <un...@astro.uni-bonn.de> wrote:
>Bill Gunshannon wrote
>>
>> Sorry to disappoint you, but here it is straight fromt he horse's mouth.
>>
>> http://www.ka9q.net/code/ka9qnos/
>>
>> "My KA9Q NOS TCP/IP package began life way back in late 1985 on a
>> surplus Xerox 820 computer board running CP/M with a 4 MHz Zilog
>> Z-80 CPU, 64KB of RAM and a 8" floppy drive holding all of 243KB.
>> ("KB" stands for kilo bytes -- not mega or giga)."
>>
>
> but where are the CP/M sources or binaries????
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.
Someone from the cp/m community, or from the historic computer
community (Al Kossow? Computer History Museum?) might want to contact
Phil Karn, and ask him whether he can find the source code for really
early KA9Q versions (in particular the cp/m version), and release it
for historic research purposes. People should have NO expectation of
this being a runnable version.
--
Ralph Becker-Szendy _firstname_@lr_dot_los-gatos_dot_ca_dot_us
735 Sunset Ridge Road; Los Gatos, CA 95033
All...@localhost.net
wrote:
Look at Gabys web page. I posted that a few messages back.
Allison
All...@localhost.net
Most of the true archives like Oak.oakland, SIMTEL, and the like have
gone away on the last 10 years but they carried all those sources and
more. FYI if you have the WC Cdrom or access to it it's there too as
that was compendium of the major CP/M archives.
I could post the zip here but that might get lost, again.
Allison
On Tue, 24 Mar 2009 13:45:02 +0100, Uwe Nass <un...@astro.uni-bonn.de>
wrote:
>Bill Gunshannon wrote
All...@localhost.net
<ole2...@newsguy.com> wrote:
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.
Yes, it's amazing how understanding simple cp/m makes
larger OSs concepts more bite sized.
>
>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...
Yes, some examples will port easier and be easier to understand.
>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...!"
;) 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
pe...@nospam.demon.co.uk
un...@astro.uni-bonn.de "Uwe Nass" writes:
Apologies for butting in, but you might find something at Phil
Karn's place: www.ka9q.net. Or maybe contact him via facebook at
facebook.com/people/Phil-Karn/564951485 (hope I typed that OK).
If anyone still knows where the remains of the Z80 source are,
he is probably "yer man".
FWIW I still use daily a derivative of KA9Q for DOS (GremNOS, and
I'll be using it to post this). Having said that, it's a tight
fit into 640K -- let alone 64K! The source I have is predominantly
C, so I'd say the only way one is remotely likely to get a stack
running inside 64K is a write-from-scratch asm version; not a
trivial task unless you can find some existing asm source.
Good luck in your search!
Pete
--
"We have not inherited the earth from our ancestors,
we have borrowed it from our descendants."
Roger Schmidt
I received my Wiznet modules yesterday and noticed that i should have
read the datasheet all the way to the bottom and should have noticed
that the pins were 2.0mm and not 2.54mm which would have made it easier.
So all i have to do now is either order new modules of make an adapter.
There is only one other thing stopping you making a interface the same
you need the ATMEGA162 (not ARM) chip to be programmed, this part is not
available for download! you are going to have to either program your own
code for that device or buy a preprogrammed on from Susowa. Me I'm not
sure what I'm going to do. Just get the modules connected first would be
a great start!
Roger
All...@localhost.net
wrote:
>In article <gqakke$22n$1...@news-a.stw-bonn.de>
> un...@astro.uni-bonn.de "Uwe Nass" writes:
>
>> Bill Gunshannon wrote
>> >
>> > Sorry to disappoint you, but here it is straight fromt he horse's mouth.
>> >
>> > http://www.ka9q.net/code/ka9qnos/
>> >
>> > "My KA9Q NOS TCP/IP package began life way back in late 1985 on a
>> > surplus Xerox 820 computer board running CP/M with a 4 MHz Zilog
>> > Z-80 CPU, 64KB of RAM and a 8" floppy drive holding all of 243KB.
>> > ("KB" stands for kilo bytes -- not mega or giga)."
>> >
>> > bill KB3YV
>> >
>>
>> Hi Bill,
>>
>> but where are the CP/M sources or binaries????
>>
>> Greetings,
>>
>> Uwe.
>
>Apologies for butting in, but you might find something at Phil
>Karn's place: www.ka9q.net. Or maybe contact him via facebook at
>facebook.com/people/Phil-Karn/564951485 (hope I typed that OK).
>If anyone still knows where the remains of the Z80 source are,
>he is probably "yer man".
>
Hes already made it clear it's old stuff hes not bothering with.
He abandoned the 8bit platform soon as PC got cheap enough
for speed and more memory.
Gabys site has the Xerox 820 stuff including most of the sources.
>FWIW I still use daily a derivative of KA9Q for DOS (GremNOS, and
>I'll be using it to post this). Having said that, it's a tight
>fit into 640K -- let alone 64K! The source I have is predominantly
>C, so I'd say the only way one is remotely likely to get a stack
>running inside 64K is a write-from-scratch asm version; not a
>trivial task unless you can find some existing asm source.
It's out there I have the DOS exe still. It's not so tight into 640k
but most of the apps people want to use all compete for a large part
of that 640K.
Like I said most of the code is on Gabys site and a few others
scattered around and the C code looks complete.
Allison
Ole Christensen
> Lars,
> I received my Wiznet modules yesterday and noticed that i should have
> read the datasheet all the way to the bottom and should have noticed
> that the pins were 2.0mm and not 2.54mm which would have made it easier.
> So all i have to do now is either order new modules of make an adapter.
> There is only one other thing stopping you making a interface the same
> you need the ATMEGA162 (not ARM) chip to be programmed, this part is not
> available for download! you are going to have to either program your own
> code for that device or buy a preprogrammed on from Susowa. Me I'm not
> sure what I'm going to do. Just get the modules connected first would be
> a great start!
>
> Roger
The WIZ810MJ are 2.0mm and the WIZ811MJ are 2.54mm...
(me to have WIZ810MJ)
The ATmel ATmega-series, (AVR), are easy In-System-Programmable and a
lot of open-source tools are to be found added to the ATmel line-up,
should be no-problem...
Depending of what You want:
1: PnP from Susowa,
2: or roll Your own.
If rolling Your own are the choice then start out with
Google ""w5100" & "avr""
More info on ATmega You will find at www.atmel.com
The rest are in the W5100 / WIZ810MJ Datasheet...
And You are free to select the controller of Your choice
so if ARM fit You better...
But also the talk about AVR's and the like are OT in this CP/M-forum,
i think, even if it is connected to that kind of thing...
good luck...!
<ole>
Bill Gunshannon
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.
Roger Schmidt
programmed into your own MEGA162 if you supply a MAC.
Roger
Matthew Phillips
on 17 Mar 2009 Roger Schmidt wrote:
> Has anyone tried to code or know of a stack for TCP/IP? If the homebrew
> cpu can do it I cant see why CP/M can't on a Z80/8080/8085!
A bit late for a follow-up (I've not been reading this group lately) but
there exists a TCP/IP stack for the Amstrad CPC, a Z80-based machine which
also ran CP/M 2.2 and CP/M+.
"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."
--
Matthew Phillips
Dundee
Herbert Johnson
> A bit late for a follow-up (I've not been reading this group lately) but
> there exists a TCP/IP stack for the Amstrad CPC, a Z80-based machine which
> also ran CP/M 2.2 and CP/M+.
>
> http://www.cepece.info/cpcip/
>
> "CPC/IP is an implementation of [TCP/IP, etc] for Amstrad CPC computers...
Thanks for the reminder of the discussion of TCP/IP for CP/M, back in
March. Since the question comes up a few times a year, that discussion
seemed to me to be a good opportunity to organize the various
responses into a Web page for future reference. I've done so and the
link is:
http://www.retrotechnology.com/dri/cpm_tcpip.html
Some of the participants have looked it over and they find it
acceptable. Essentially I've captured some of the discussion, and
checked out most of the Web links. Thanks to Allison Parent and Gaby
Chaudry, additional archives of early KA9Q Z80-based work are now
available on Gaby's CP/M archive site, in a section "TCP/IP stacks"
specific to the subject.
http://www.gaby.de/ecpmlink.htm
Of course, I'd welcome corrections and additions to the page.
As I see it, there are many implementations of "TCP/IP" already DONE,
which are either on Z80 microprocessors, or similar microprocessors.
Some of them are the KA9Q packet radio implementations, which use a
separate "Terminal Network Controller" or TNC , to support amateur
radio packet networking. Others provide various degrees of Internet
support. Some are finished old projects, some not finished. There are
also implementations using modern "serial to Ethernet" devices, chips
or modules. In most cases, you have to spend money to buy some
hardware, a budget of tens of dollars or more - this was mentioned as
a consideration.
But, there is no simple package that one can buy and "run", under CP/
M, to provide "Internet" service. My page draws no conclusions, makes
no recommendations.
The fact is, what we call "internet" today consists of layers of
support, from hardware for Ethenet, to software and hardware to handle
packets, to software for your computer to provide services (FTP, HTTP,
etc) and to display results. Many "Internet" services, mostly expect
to have "modern" capabilities for use. Much of those capabilities,
just ain't there for CP/M class systems. Yet, some people have come up
with some "internet" services you can run from older, simpler CP/M-
class systems. It's very, very informative to *look at what has been
done*, to see what the issues are about "running Internet under CP/M".
My Web page provides some links and discussions, taken from my
comp.os.cpm colleagues, to help people find responses to that
question. My thanks to all those participants, for their posts and for
their support of my Web page of their comments and links.
Herb Johnson
retrotechnology.com