Discussion:
networking with CP/M
(too old to reply)
d***@cs.csbuak.edu
2005-02-09 00:27:01 UTC
Permalink
The guy I'm working with on this P112 project is talking about designing
an ethernet card for the P112. It'll probably be just 10baseT. I guess
it'll work with UZ180, but what about CP/M?
--
David Griffith
***@cs.csbuak.edu <-- Switch the 'b' and 'u'
Roger Ivie
2005-02-09 01:08:28 UTC
Permalink
Post by d***@cs.csbuak.edu
The guy I'm working with on this P112 project is talking about designing
an ethernet card for the P112. It'll probably be just 10baseT. I guess
it'll work with UZ180, but what about CP/M?
CP/NET would be your obvious candidate here. It's on my list of things
to play with, but I'm playing with other things at the moment. And
haven't made any progress on them since Christmas...
--
Roger Ivie
***@ridgenet.net
http://anachronda.webhop.org/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/P d- s:+++ a+ C++ UB--(++++) !P L- !E W++ N++ o-- K w O- M+ V+++ PS+
PE++ Y+ PGP t+ 5+ X-- R tv++ b++ DI+++ D+ G e++ h--- r+++ z+++
------END GEEK CODE BLOCK------
Jay Maynard
2005-02-09 01:26:47 UTC
Permalink
Post by d***@cs.csbuak.edu
The guy I'm working with on this P112 project is talking about designing
an ethernet card for the P112. It'll probably be just 10baseT. I guess
it'll work with UZ180, but what about CP/M?
The original KA9Q TCP/IP package was written for CP/M, though it outgrew it
fairly early on. A simple TCP/IP stack for one specific Ethernet card,
providing mainly FTP and Telnet capabilities, should be doable. A BYE3-style
telnet server might even be within the realm of possibility, though I'm not
sure how much TPA it would leave.

No, I don't know where one might find a copy of the CP/M KA9Q.
p***@nospam.demon.co.uk
2005-02-09 06:55:57 UTC
Permalink
Post by Jay Maynard
The original KA9Q TCP/IP package was written for CP/M, though it outgrew it
fairly early on. A simple TCP/IP stack for one specific Ethernet card,
providing mainly FTP and Telnet capabilities, should be doable. A BYE3-style
telnet server might even be within the realm of possibility, though I'm not
sure how much TPA it would leave.
No, I don't know where one might find a copy of the CP/M KA9Q.
Might be worth trying to contact the author?

http://people.qualcomm.com/karn/
or
http://www.ka9q.net

Pete
[this reply posted using ka9q under plain dos 6.22 :-) ]
--
"We have not inherited the earth from our ancestors,
we have borrowed it from our descendants."
Jay Maynard
2005-02-09 08:05:43 UTC
Permalink
Post by p***@nospam.demon.co.uk
Post by Jay Maynard
No, I don't know where one might find a copy of the CP/M KA9Q.
Might be worth trying to contact the author?
http://people.qualcomm.com/karn/
or
http://www.ka9q.net
Last I heard, Phil had long since lost the original code, and was
recommending people not even both trying to play with it as it was very
limited in scope. Of course, that doesn't stop CP/M folks. :-)
Frank McConnell
2005-02-10 00:14:49 UTC
Permalink
Post by Jay Maynard
Last I heard, Phil had long since lost the original code, and was
recommending people not even both trying to play with it as it was very
limited in scope. Of course, that doesn't stop CP/M folks. :-)
A couple years ago Dave Horsfall found a copy of sources and put it
up on his web server, which was "on the wrong end of a 56kb modem" and
looks to have gone missing in the meantime, and he posted a link here.
I snarfed (thanks Dave!) but can't say that I've done anything with it.
Tarball at <http://www.reanimators.org/tmp/cpm-tcp.tar.gz>.

-Frank McConnell
d***@cs.csbuak.edu
2005-02-10 00:29:07 UTC
Permalink
Post by Frank McConnell
Post by Jay Maynard
Last I heard, Phil had long since lost the original code, and was
recommending people not even both trying to play with it as it was very
limited in scope. Of course, that doesn't stop CP/M folks. :-)
A couple years ago Dave Horsfall found a copy of sources and put it
up on his web server, which was "on the wrong end of a 56kb modem" and
looks to have gone missing in the meantime, and he posted a link here.
I snarfed (thanks Dave!) but can't say that I've done anything with it.
Tarball at <http://www.reanimators.org/tmp/cpm-tcp.tar.gz>.
Thanks! I'll put this on the P112 documentation CD.
--
David Griffith
***@cs.csbuak.edu <-- Switch the 'b' and 'u'
Randy McLaughlin
2005-02-10 01:03:02 UTC
Permalink
Post by d***@cs.csbuak.edu
Post by Frank McConnell
Post by Jay Maynard
Last I heard, Phil had long since lost the original code, and was
recommending people not even both trying to play with it as it was very
limited in scope. Of course, that doesn't stop CP/M folks. :-)
A couple years ago Dave Horsfall found a copy of sources and put it
up on his web server, which was "on the wrong end of a 56kb modem" and
looks to have gone missing in the meantime, and he posted a link here.
I snarfed (thanks Dave!) but can't say that I've done anything with it.
Tarball at <http://www.reanimators.org/tmp/cpm-tcp.tar.gz>.
Thanks! I'll put this on the P112 documentation CD.
--
David Griffith
I uploaded a copy to my server in the "unclassified section":

http://www.s100-manuals.com/download/cpm-tcp.tar


Randy
www.s100-manuals.com
Randy McLaughlin
2005-02-10 01:32:32 UTC
Permalink
Post by Randy McLaughlin
Post by d***@cs.csbuak.edu
Post by Frank McConnell
Post by Jay Maynard
Last I heard, Phil had long since lost the original code, and was
recommending people not even both trying to play with it as it was very
limited in scope. Of course, that doesn't stop CP/M folks. :-)
A couple years ago Dave Horsfall found a copy of sources and put it
up on his web server, which was "on the wrong end of a 56kb modem" and
looks to have gone missing in the meantime, and he posted a link here.
I snarfed (thanks Dave!) but can't say that I've done anything with it.
Tarball at <http://www.reanimators.org/tmp/cpm-tcp.tar.gz>.
Thanks! I'll put this on the P112 documentation CD.
--
David Griffith
http://www.s100-manuals.com/download/cpm-tcp.tar
I had trouble downloading the file, it always renamed it to cpm-tcp.tar even
though it was still a gzipped file.

I tried by naming it cpm-tcp.tgz with the same problem.

I made a winzip self extracting file (cpm-tcp.exe) and that works fine.


Randy
www.s100-manuals.com
s***@yahoo.com
2005-02-16 03:47:38 UTC
Permalink
Post by Jay Maynard
Post by p***@nospam.demon.co.uk
Post by Jay Maynard
No, I don't know where one might find a copy of the CP/M KA9Q.
Might be worth trying to contact the author?
http://people.qualcomm.com/karn/
or
http://www.ka9q.net
Last I heard, Phil had long since lost the original code, and was
recommending people not even both trying to play with it as it was very
limited in scope. Of course, that doesn't stop CP/M folks. :-)
Since that stuff is packet radio related, I dug up this stuff:

ftp://ftp.ucsd.edu/hamradio/packet/tcpip/old/net/

although it is x86 related, it looks like most of the sources are in C,
perhaps drivers.arc is of some use to somebody.

further up the tree is:

ftp://ftp.ucsd.edu/hamradio/packet/tcpip/ka9q/

Also, an interesting x186 40mhz controller with built-in Ethernet:

http://www.jkmicro.com/technicalinfo/ti_picoflash.html

Probably could be used to serve cp/m-80 connection to the internet, or
run cp/m-86 as it is msDos based. An interesting option is 'M-Systems
DiskOnChip'. Hunt around there and you'll find source code as well.

Steve
_***@lr_dot_los-gatos_dot_ca.us
2005-02-09 18:45:00 UTC
Permalink
Post by p***@nospam.demon.co.uk
Post by Jay Maynard
The original KA9Q TCP/IP package was written for CP/M, though it outgrew it
fairly early on. ...
No, I don't know where one might find a copy of the CP/M KA9Q.
Might be worth trying to contact the author?
http://people.qualcomm.com/karn/
or
http://www.ka9q.net
...
No, it is not worth trying: He doesn't have the source, and doesn't
know who has it. And he recommends staying away from it. I got the
impression that he is quite annoyed at requests for it.

Matter-of-fact, I looked for ka9q for cp/m ages ago (could be over a
decade), and already at that point nobody had the source any more. It
seems very likely to me that it doesn't exist any longer.
--
The address in the header is invalid for obvious reasons. Please
reconstruct the address from the information below (look for _).
Ralph Becker-Szendy ***@lr_dot_los-gatos_dot_ca.us
Randy McLaughlin
2005-02-09 19:13:30 UTC
Permalink
Post by _***@lr_dot_los-gatos_dot_ca.us
Post by p***@nospam.demon.co.uk
Post by Jay Maynard
The original KA9Q TCP/IP package was written for CP/M, though it outgrew it
fairly early on. ...
No, I don't know where one might find a copy of the CP/M KA9Q.
Might be worth trying to contact the author?
http://people.qualcomm.com/karn/
or
http://www.ka9q.net
...
No, it is not worth trying: He doesn't have the source, and doesn't
know who has it. And he recommends staying away from it. I got the
impression that he is quite annoyed at requests for it.
Matter-of-fact, I looked for ka9q for cp/m ages ago (could be over a
decade), and already at that point nobody had the source any more. It
seems very likely to me that it doesn't exist any longer.
I don't know of any 8080/Z80 existing TCP/IP stacks but there is a 6502
program out there. It may be a good starting point for legacy systems.

If one is created for CP/M it would require bank switching. An easier way
to go would be using an F91 (eZ80 with enet), there are already TCP/IP
stacks for it. It is the processor being used on the Imsai Series 2 and the
acclaim is a cheap way in.


Randy
www.s100-manuals.com
Randy McLaughlin
2005-02-09 19:26:32 UTC
Permalink
"Randy McLaughlin" <***@nospam.com> wrote in message news:9gtOd.55$***@bignews4.bellsouth.net...
<snip>
Post by Randy McLaughlin
I don't know of any 8080/Z80 existing TCP/IP stacks but there is a 6502
program out there. It may be a good starting point for legacy systems.
If one is created for CP/M it would require bank switching. An easier way
to go would be using an F91 (eZ80 with enet), there are already TCP/IP
stacks for it. It is the processor being used on the Imsai Series 2 and
the acclaim is a cheap way in.
I forgot to mention that there are plenty of enet adapters that use a simple
parallel interface. For legacy systems it might be best to use a slave
processor to handle the TCP/IP stack, on the eZ80 it can be run as a
separate task from CP/M.

For the eZ80 there is a real time OS but a simple task switcher could be
used.


I would like to look into getting an ftp client working under CP/M. There
are plenty of free ftp servers including for windows. This would probably
be the easiest way to directly transfer files to and from a PC.


Randy
www.s100-manuals.com
CBFalconer
2005-02-09 21:35:42 UTC
Permalink
Randy McLaughlin wrote:
... snip ...
Post by Randy McLaughlin
I would like to look into getting an ftp client working under CP/M.
There are plenty of free ftp servers including for windows. This
would probably be the easiest way to directly transfer files to and
from a PC.
Whats wrong with Zmodem? The PC already has Hyperterm, which
implements it. You can usually get MDM7 running easily on a CP/M
box. Now all you need is a null modem cable. Or am I
misremembering the existence of Zmodem on MDM7?
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Jay Maynard
2005-02-09 21:44:55 UTC
Permalink
Post by CBFalconer
Whats wrong with Zmodem? The PC already has Hyperterm, which
implements it. You can usually get MDM7 running easily on a CP/M
box. Now all you need is a null modem cable. Or am I
misremembering the existence of Zmodem on MDM7?
I just looked at my copy of the MDM716 source, and it looks like it'll do
XMODEM and XMODEM in batch mode, but nothing newer. I don't konw if that's
good enough for Hyperterm or not.
Randy McLaughlin
2005-02-09 22:04:52 UTC
Permalink
Post by Jay Maynard
Post by CBFalconer
Whats wrong with Zmodem? The PC already has Hyperterm, which
implements it. You can usually get MDM7 running easily on a CP/M
box. Now all you need is a null modem cable. Or am I
misremembering the existence of Zmodem on MDM7?
I just looked at my copy of the MDM716 source, and it looks like it'll do
XMODEM and XMODEM in batch mode, but nothing newer. I don't konw if that's
good enough for Hyperterm or not.
Ethernet adapters are getting popular on micro-controllers, I see no reason
to bend them to CP/M networking.

CP/NET is fine so is TurboDOS and other networking schemes but it limits
clients.

The question becomes how to interface CP/M to DOS or Linux.

With the concept that it is best to learn how to crawl before running FTP
would be the easiest TCP/IP networking to get running for file sharing.

Samba would be a laudable goal.


Randy
www.s100-manuals.com
Jay Maynard
2005-02-09 22:13:56 UTC
Permalink
Post by Randy McLaughlin
Ethernet adapters are getting popular on micro-controllers, I see no reason
to bend them to CP/M networking.
Yeah. For that matter, it shouldn't be hard to interface a common Ethernet
devie to a Z-80; the trick is pickign one that doesn't require much in the
way of programming support.
Post by Randy McLaughlin
CP/NET is fine so is TurboDOS and other networking schemes but it limits
clients.
Indeed. OTOH, if someone wants to get CP/NET running, why not?
Post by Randy McLaughlin
With the concept that it is best to learn how to crawl before running FTP
would be the easiest TCP/IP networking to get running for file sharing.
An FTP client should be fairly simple, although I would not expect it to be
running along with anything else.
Post by Randy McLaughlin
Samba would be a laudable goal.
Sorry, but I don't see this happening. Way too much code would be needed.
primo
2005-02-10 17:27:09 UTC
Permalink
Post by CBFalconer
... snip ...
Post by Randy McLaughlin
I would like to look into getting an ftp client working under CP/M.
There are plenty of free ftp servers including for windows. This
would probably be the easiest way to directly transfer files to and
from a PC.
Whats wrong with Zmodem? The PC already has Hyperterm, which
implements it. You can usually get MDM7 running easily on a CP/M
box. Now all you need is a null modem cable. Or am I
misremembering the existence of Zmodem on MDM7?
Zmp was the cp/m comm program that supported zmodem.
Imp supported xmodem and xmodem1k (also incorrectly referred to
sometimes as ymodem).
mdm7 just supports xmodem (both crc and checksum)
Kermit is also available for cross platform transfers as long as you
remember to set it up right to do 8 bit transfers.

If you have nothing available, then unload (remembering to specify
0100 org) will make a hex file and then that can be pip'd into a
target system and converted back to a com file with load.

I did all that years ago putting comm programs on xerox 820, balcones
bnv205, radio shack 4p and commodore 64 with cpm cart. If I could find
a serial card and apple cpm boot disk I might get my IIe working with
cp/m (it already has a softcard).
primo
2005-02-10 17:14:32 UTC
Permalink
On Wed, 09 Feb 2005 18:45:00 -0000,
Post by _***@lr_dot_los-gatos_dot_ca.us
Post by p***@nospam.demon.co.uk
Post by Jay Maynard
The original KA9Q TCP/IP package was written for CP/M, though it outgrew it
fairly early on. ...
No, I don't know where one might find a copy of the CP/M KA9Q.
Might be worth trying to contact the author?
http://people.qualcomm.com/karn/
or
http://www.ka9q.net
...
No, it is not worth trying: He doesn't have the source, and doesn't
know who has it. And he recommends staying away from it. I got the
impression that he is quite annoyed at requests for it.
Matter-of-fact, I looked for ka9q for cp/m ages ago (could be over a
decade), and already at that point nobody had the source any more. It
seems very likely to me that it doesn't exist any longer.
I think I have it somewhere, I am an amatuer radio operator also and
was playing with packet radio about that time, I recall getting a
version for the xerox 820 (which is what I eventually ran a fido net
node on). It would take some searching thru all the disks from that
era to find it though.
French Luser
2005-02-09 13:19:24 UTC
Permalink
Hello, David!
Post by d***@cs.csbuak.edu
The guy I'm working with on this P112 project is talking about designing
an ethernet card for the P112. It'll probably be just 10baseT. I guess
it'll work with UZ180, but what about CP/M?
Please, don't re-invent the wheel.

Digital Research spent years integrating networks
with theirs various Operating Systems.

If you are tinkering with CP/M (2.2),
implement CP/NET Version 1.2,
since (16-bit) DR Net recognizes it.

(If you have a look to the "BDOS Version
Number" used by DRI on their 16-bit OSes,
you will see that each OS has a specific
version number, depending whether it was
with or without networking support.)
(I seem to remember that I already
published this in the comp.os.cpm Newsgroup...
Yes: the 10 October 2003 (2003-10-10) )

Finally, remember that, besides network,
DRI also implemented a portable graphics
system, called GSX...

Yours Sincerely,
"French Luser"
Peter Smith
2005-02-10 15:44:22 UTC
Permalink
Post by French Luser
Post by d***@cs.csbuak.edu
The guy I'm working with on this P112 project is talking about designing
an ethernet card for the P112. It'll probably be just 10baseT. I guess
it'll work with UZ180, but what about CP/M?
[...]
Please, don't re-invent the wheel.
Digital Research spent years integrating networks
with theirs various Operating Systems.
If you are tinkering with CP/M (2.2),
implement CP/NET Version 1.2,
since (16-bit) DR Net recognizes it.
Hi Emmanuel,

I've found this text sniplet at
http://www.cisnet.com/glennmcc/download/drdos-hist.txt:
[...]

CPNETLDR- load the CP/NOS

CPNETSYS- displays the slave configuration table

CP/Net and DR/Net Master Commands

BROADCST- Broadcast mail to all slaves currently logged in

MRCVMAIL- receive mail

MSNDMAIL- send mail to another slave or master

SPOOL - spool list files to the printer and optionally delete them

Released at the same time as CP/M 2.2 and MP/M 1, CP/Net never caught
on, simply because it took up too much room in memory and the user could
not run most programs as a result. It has subsequently been replaced by
DR/Net.
[...]
It seems also that DR/Net (and FlexNet) is no more for sale (and is only
integrated in Concurrent DOS IMHO).

If this is true, it would be not a wise idea to re-implement CP/Net.
Instead, it should be simple enough to wrote a small agent to redirect
the proper BDOS calls for a fixed drive letter.
But I agree with others here, using an Ethernet interface with CP/M is
not a good idea (too much effort for the low level Ethernet routines and
not enough speed from the hosting system).
Instead, it is also simple to use an Ethernet-to-RS232 adapter to get a
network connection to a CP/M computer, or ?

Regards
Peter
Randy McLaughlin
2005-02-10 16:39:29 UTC
Permalink
"Peter Smith" <***@programmer.net> wrote in message news:***@individual.net...
<snip>
Post by Peter Smith
If this is true, it would be not a wise idea to re-implement CP/Net.
Instead, it should be simple enough to wrote a small agent to redirect the
proper BDOS calls for a fixed drive letter.
But I agree with others here, using an Ethernet interface with CP/M is not
a good idea (too much effort for the low level Ethernet routines and not
enough speed from the hosting system).
Instead, it is also simple to use an Ethernet-to-RS232 adapter to get a
network connection to a CP/M computer, or ?
Regards
Peter
Using an Ethernet-to-RS232 would be like watering your lawn through a straw,
it is uncommon for CP/M systems to run over 19200 baud (many are slower than
that). For the cost of one of these adapters you can buy a Zilog Acclaim
($99.00) and bring up a 50mhz CP/M system with the Ethernet adapter already
attached.

There are some cheap Ethernet adapters with a simple parallel interface.
These could be interfaced to a variety of S100 cards. Another problem with
many S100 systems is the lack of interrupts. I do not believe it is
reasonable to do TCP/IP with polling.

The best option could be to use a slave processor that does the TCP/IP and
talks to the S100 through a parallel or serial port. Taking cost and ease
of use for CP/M programmers into account the Zilog Acclaim jumps to mind.
For those that can afford the $99.00 price you get a 50mhz CP/M compatible
system, it can be interfaced via serial or parallel port to a S100 (or other
CP/M system). The F91 module alone sells for $75 the Acclaim comes with the
F91 along with a bunch of goodies (motherboard, power-supplies, cables, ZDI
interface, software, etc). To program the F91 you nees to use either a ZDI
or JTAG adapter (ZDI adapter included in the Acclaim).


Randy
www.s100-manuals.com
Kelly Hall
2005-02-10 17:21:23 UTC
Permalink
Post by Randy McLaughlin
I do not believe it is
reasonable to do TCP/IP with polling.
FreeBSD allows you to drive various device drivers, like Ethernet, from
a periodic timer instead of using system interrupts. While it's a bit
of overhead when the system is idle, it works great when the system is
being hammered.

To make this work well, though, requires an Ethernet chip with some
memory for the incoming packets. If you're using the RealTek ISA chip,
you're going to have to poll relatively quickly unless you want to
overflow it.

Of course, the whole CP/M system is so memory constrained anyway I'm
probably discussing the nuances of operatic swine...

Kelly
Randy McLaughlin
2005-02-10 17:48:42 UTC
Permalink
I do not believe it is reasonable to do TCP/IP with polling.
FreeBSD allows you to drive various device drivers, like Ethernet, from a
periodic timer instead of using system interrupts. While it's a bit of
overhead when the system is idle, it works great when the system is being
hammered.
To make this work well, though, requires an Ethernet chip with some memory
for the incoming packets. If you're using the RealTek ISA chip, you're
going to have to poll relatively quickly unless you want to overflow it.
Of course, the whole CP/M system is so memory constrained anyway I'm
probably discussing the nuances of operatic swine...
Kelly
Apples vs. oranges, having an interrupt driven clock to allow some drivers
to be polled is still using interrupts. Another point is the architecture
of a system running FreeBSD vs. the architecture of a system running CP/M is
significantly different, the memory and speed for two points.

For those not following he snipped the part where I said: "Another problem
with many S100 systems is the lack of interrupts. I do not believe it is
reasonable to do TCP/IP with polling."

TCP/IP for CP/M is reasonable, at least for some clients (telnet & ftp at
least). A common question is having people handle email, the answer is yes
and no: Text based email only needs a telenet program with a simple
wrapper, attachments and HTML is a bigger problem (not worth handling with a
2mhz 8080 ;-).


Randy
www.s100-manuals.com
Kelly Hall
2005-02-11 02:14:32 UTC
Permalink
Post by Randy McLaughlin
Apples vs. oranges, having an interrupt driven clock to allow some drivers
to be polled is still using interrupts.
I assume you meant "clock driven interrupts" but whatever. Does your
machine actually have no interupts at all? How amusingly primitive. I
don't recall ever owning a box without them, and most had some sort of
clock interrupt as well, although they called it the 'video blanking'
period or the keyboard scan routine ;)
Post by Randy McLaughlin
TCP/IP for CP/M is reasonable, at least for some clients (telnet & ftp at
least). A common question is having people handle email, the answer is yes
and no: Text based email only needs a telenet program with a simple
wrapper, attachments and HTML is a bigger problem (not worth handling with a
2mhz 8080 ;-).
The evil part (IMHO) is that you'll end up statically linking in the
TCP/IP to every application. That eats disk space.

You might look over the LWIP project to see if you can use their work.
Their stack doesn't handle everything one might like (IP fragmenting,
multicast) but the price is right and it's small.

Kelly
Randy McLaughlin
2005-02-11 22:50:09 UTC
Permalink
Post by Kelly Hall
Post by Randy McLaughlin
Apples vs. oranges, having an interrupt driven clock to allow some
drivers to be polled is still using interrupts.
I assume you meant "clock driven interrupts" but whatever. Does your
machine actually have no interupts at all? How amusingly primitive. I
don't recall ever owning a box without them, and most had some sort of
clock interrupt as well, although they called it the 'video blanking'
period or the keyboard scan routine ;)
Many CP/M systems had no interrupt support it was common to have separate
cards to support interrupts (Imsai's PIC-8, CompuPro's SS1 and others).
When you say "How amusingly primitive" are you referring to CP/M?
Post by Kelly Hall
Post by Randy McLaughlin
TCP/IP for CP/M is reasonable, at least for some clients (telnet & ftp at
least). A common question is having people handle email, the answer is
yes and no: Text based email only needs a telenet program with a simple
wrapper, attachments and HTML is a bigger problem (not worth handling
with a 2mhz 8080 ;-).
The evil part (IMHO) is that you'll end up statically linking in the
TCP/IP to every application. That eats disk space.
You might look over the LWIP project to see if you can use their work.
Their stack doesn't handle everything one might like (IP fragmenting,
multicast) but the price is right and it's small.
Kelly
Kelly Hall
2005-02-12 02:50:03 UTC
Permalink
Post by Randy McLaughlin
Many CP/M systems had no interrupt support it was common to have separate
cards to support interrupts (Imsai's PIC-8, CompuPro's SS1 and others).
When you say "How amusingly primitive" are you referring to CP/M?
CP/M doesn't amuse me, but a general purpose system without interrupts
(so that all IO is polled) I find quite amusing. In fact, I'd consider
it shite.

Kelly
Jay Maynard
2005-02-12 03:08:38 UTC
Permalink
Post by Kelly Hall
Post by Randy McLaughlin
Many CP/M systems had no interrupt support it was common to have separate
cards to support interrupts (Imsai's PIC-8, CompuPro's SS1 and others).
When you say "How amusingly primitive" are you referring to CP/M?
CP/M doesn't amuse me, but a general purpose system without interrupts
(so that all IO is polled) I find quite amusing. In fact, I'd consider
it shite.
Many, if not most, CP/M systems fit this description. A single-tasking
system on a Z-80 didn't need interrupts to work quite well.
Kelly Hall
2005-02-12 10:17:19 UTC
Permalink
Post by Jay Maynard
Many, if not most, CP/M systems fit this description. A single-tasking
system on a Z-80 didn't need interrupts to work quite well.
I'm dubious. Are you saying the designers usually just tied the Z80 INT
and NMI lines high? Seems like a huge waste to me.

Kelly
Jay Maynard
2005-02-12 13:12:12 UTC
Permalink
Post by Kelly Hall
Post by Jay Maynard
Many, if not most, CP/M systems fit this description. A single-tasking
system on a Z-80 didn't need interrupts to work quite well.
I'm dubious. Are you saying the designers usually just tied the Z80 INT
and NMI lines high? Seems like a huge waste to me.
That's exactly what I'm saying. Why bother with interrupts - including
having to debug them - when it's not needed?

My S-100 system is entirely typical of this. Serial I/O is polled. Disk I/O
on the Tarbell SSSD disk controller board is handled ina neat way: they
implemented an I/O port that, when you read it, asserts HOLD until the 1771
signals an interrupt. Thus, a read loop consists of issuing the read
command, then looping on doing an input from the wait port, doing an
input from the data port, saving the data byte in memory, then doing in
input from the status port, until the status indicates either an error or
completion of the sector.
CBFalconer
2005-02-12 14:32:59 UTC
Permalink
Post by Kelly Hall
Post by Jay Maynard
Many, if not most, CP/M systems fit this description. A single-tasking
system on a Z-80 didn't need interrupts to work quite well.
I'm dubious. Are you saying the designers usually just tied the
Z80 INT and NMI lines high? Seems like a huge waste to me.
No, they generally used the interrupt chain mechanism available on
the Z80 peripheral chips.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Randy McLaughlin
2005-02-12 19:44:12 UTC
Permalink
Post by Kelly Hall
Post by Jay Maynard
Many, if not most, CP/M systems fit this description. A single-tasking
system on a Z-80 didn't need interrupts to work quite well.
I'm dubious. Are you saying the designers usually just tied the Z80 INT
and NMI lines high? Seems like a huge waste to me.
Kelly
No, generally they were tied to the S100 bus or had jumper locations where
they could be connected. The problem is that most of the I/O devices could
only a NMI or a VI interrupt. NMI is not compatible with most disk drive
controllers and most systems didn't have a VI controller.

A few manufacturers had smart enough I/O devices to handle it all themselves
such as Cromemco but were not used for their single user systems.

Please remember this is a CP/M group and very very few CP/M systems used or
even had the ability to use interrupts.


Randy
www.s100-manuals.com
n***@nouce.bellatlantic.net
2005-02-12 23:31:03 UTC
Permalink
On Sat, 12 Feb 2005 13:44:12 -0600, "Randy McLaughlin"
Post by Randy McLaughlin
A few manufacturers had smart enough I/O devices to handle it all themselves
such as Cromemco but were not used for their single user systems.
Compupro had a nice board that was basically a smart contoller with
local ram and interrupts to unburden the main cpu. I have a MPX-1
in one of my S100 crates to do all the terminal IO and disk IO for a
Disk3 relieving the system cpu from those tasks and moving that
part of the bios to a second cpu. The one I have has a 6mhz
(internal clock speed ) HmosII part in it. The only interupt in that
system for the main CPU is a RST 3 "doorbell" interrupt to notify it
that some IO request is has completed.
Post by Randy McLaughlin
Please remember this is a CP/M group and very very few CP/M systems used or
even had the ability to use interrupts.
Very true. Unfortunate too. Near the end of the 8bit life (mid 80s)
many of the mid to high end systems had at least a heartbeat interrupt
like the Kaypro or better.

However, the NMI on the z80 is loc 66H making it awkard for CP/M
and IM1 vectors to 38H (aka RST7) which is used by DDT.
So there had to be a bit more hardware to either puch the RST0-through
7 or a Z80 IM2 (vectored) with the device or something supplying
V7->V1 (V0 is always 0) bits on the data bus. Enough hardware to
do a vectored RST0-7 setup that was about 4 chips (ca 1980ish) and
not less than two for a modified IM2 mode that is for Z80. If you
were running an 8085 that part had several useful interrupts without
additional hardware (Trap (a NMI), RST5.5, 6.5 and 7.5. the older
8080 system went by faster and where more difficult to put a full
interrupt scheme on (higher chip count). However most of the Multibus
based 8080 boards (I-mds and MDS800 are examples) had the full
RST0-7 logic and supported interrupts well.

This is a CP/M issue frequently because if the hardware was there
even in some simple form the bios never used it. the likely reason
for this was writing interupt driven software was not as easy as
polled. The bios is where one could make CP/M be bland or
as an exceptional system. One example of this was the
NS* Horizon running CP/M. The hardware to do a fully vectored
system was there if a ZPB-A and Horzon backplane and IO was
there. On the bus was 9 interrupts (NMI and rst0 thorugh 7) . Yet
none of the packaged CP/M varients (sail, lifeboat, etal) had a
bios that used them.

Historically this all came to ahead when modems hit faster than
300baud and more systems started using them with BBSs and
access to Compuserve, Delphi, and the Source. To do decent IO
quickly on a Z80 (or 8085) and not drop bytes, buffered IO using
interrupts is a solution. Instead we faced systems like Kaypro
that hit the wall at 1200 baud or others that required a special
version of some modem software that knew that systems IO
rather than use IObyte and standard IO. Clearly a standards
and implmentation issue.

When doing any networking (regardless of interface) on a CP/M
machine you need an interrupt to tell you **hey theres data on the
pipe and it may be for you** without sitting in a wasteful polling
loop. This is very important when the controller was stupid and
the CPU had to handle all the bytes to see if they were for you or
not. Even if you had a smart controller with it's own CPU it was
still advantagous to have a "doorbell" to let the cpu know **hey
I got something, check it out** . A doorbell is a single level
interrupt that initates a scan check for a Ram or IO device(s) for
some indicator of whats pending. the Kaypro used that scheme
but it was infrequent enough that above a certain speed stuff was
going to be missed due to input buffer overrun.


After working with PDP11s and other systems in the late 70s on I found
the single thing I missed most was type ahead. The ability to type
something in before the display or was done and have the system
start acting on it that much sooner.



Allison
Peter Smith
2005-02-13 09:16:30 UTC
Permalink
Post by n***@nouce.bellatlantic.net
[...]
Historically this all came to ahead when modems hit faster than
300baud and more systems started using them with BBSs and
access to Compuserve, Delphi, and the Source. To do decent IO
quickly on a Z80 (or 8085) and not drop bytes, buffered IO using
interrupts is a solution. Instead we faced systems like Kaypro
that hit the wall at 1200 baud or others that required a special
version of some modem software that knew that systems IO
rather than use IObyte and standard IO. Clearly a standards
and implmentation issue.
When doing any networking (regardless of interface) on a CP/M
machine you need an interrupt to tell you **hey theres data on the
pipe and it may be for you** without sitting in a wasteful polling
loop. This is very important when the controller was stupid and
the CPU had to handle all the bytes to see if they were for you or
not. Even if you had a smart controller with it's own CPU it was
still advantagous to have a "doorbell" to let the cpu know **hey
I got something, check it out** . A doorbell is a single level
interrupt that initates a scan check for a Ram or IO device(s) for
some indicator of whats pending. the Kaypro used that scheme
but it was infrequent enough that above a certain speed stuff was
going to be missed due to input buffer overrun.
Hey, that's a very good description of exactly the problem I was headed
with (the BBS problem). Fortunately you can ease this by using a faster
system (instead of using 2 or 4 MHz, use an Z80H with 8 MHz for
example). This does not really solve the problem (as you already
described in detail), but my experience was, that 2400 Baud is possible
with 8 MHz (that sounds not much, but in 1990 it was superior) and a BBS
software.
I would suggest to use the Interrupt DDT was/is using, changing the
BDOS/BIOS for it, too. DDT can still be used if there is a chain which
choose DDT (if a flag was set) after leaving the routine for gathering
the bytes from the interface, or ?

Regards
Peter
n***@nouce.bellatlantic.net
2005-02-13 15:23:05 UTC
Permalink
On Sun, 13 Feb 2005 10:16:30 +0100, Peter Smith
Post by Peter Smith
Hey, that's a very good description of exactly the problem I was headed
with (the BBS problem). Fortunately you can ease this by using a faster
system (instead of using 2 or 4 MHz, use an Z80H with 8 MHz for
example). This does not really solve the problem (as you already
described in detail), but my experience was, that 2400 Baud is possible
with 8 MHz (that sounds not much, but in 1990 it was superior) and a BBS
software.
At the time I was seeing the problem 4mhz was common, 6 and 8mhz were
rare and ram fast enough very costly. Running with interrupts and
ring buffers allowed better than 2400 baud even with 2mhz z80s.
Post by Peter Smith
I would suggest to use the Interrupt DDT was/is using, changing the
BDOS/BIOS for it, too. DDT can still be used if there is a chain which
choose DDT (if a flag was set) after leaving the routine for gathering
the bytes from the interface, or ?
RST7 was the "cheap interrupt". What your suggesting is a OR-tied
interrupt (shared or common ) that any interrupting device could
assert and the cpu would then scan/poll to see what the interrupting
source was. This works, it's far faster and less wasteful of the
processor than looping on a bit to see if it changes.

Allison
Jay Maynard
2005-02-13 16:21:55 UTC
Permalink
Post by n***@nouce.bellatlantic.net
RST7 was the "cheap interrupt". What your suggesting is a OR-tied
interrupt (shared or common ) that any interrupting device could
assert and the cpu would then scan/poll to see what the interrupting
source was. This works, it's far faster and less wasteful of the
processor than looping on a bit to see if it changes.
That's true, but it implicitly assumes the CPU has better things to be
doing. It didn't in most CP/M systems.
n***@nouce.bellatlantic.net
2005-02-13 21:39:04 UTC
Permalink
On Sun, 13 Feb 2005 16:21:55 GMT, Jay Maynard
Post by Jay Maynard
That's true, but it implicitly assumes the CPU has better things to be
doing. It didn't in most CP/M systems.
There lies the error. While CP/M is single tasked there was no reason
to assume that while waiting for a keypress it could not be checking
for other IO which many bios didn't do. With interrupts the IO can
be more random and less limited performance wise. There is little
reason why a 4mhz Z80 can't run at 38.4kbaud <or faster> if done
right. To do that the CPU must be available when ever a byte is
recieved and maybe buffer it until the applications wants it.

Allison
Randy McLaughlin
2005-02-13 22:02:24 UTC
Permalink
Post by n***@nouce.bellatlantic.net
On Sun, 13 Feb 2005 16:21:55 GMT, Jay Maynard
Post by Jay Maynard
That's true, but it implicitly assumes the CPU has better things to be
doing. It didn't in most CP/M systems.
There lies the error. While CP/M is single tasked there was no reason
to assume that while waiting for a keypress it could not be checking
for other IO which many bios didn't do. With interrupts the IO can
be more random and less limited performance wise. There is little
reason why a 4mhz Z80 can't run at 38.4kbaud <or faster> if done
right. To do that the CPU must be available when ever a byte is
recieved and maybe buffer it until the applications wants it.
Allison
The original point of this thread was using Ethernet on CP/M.

It MAY be possible to handle Ethernet using polling as long as it is limited
to simple client programs.

The biggest question is how to hook up an Ethernet adapter to the system?

Does anyone want to design a new S100 card?

How about a "new" CP/M system with an integrated Ethernet adapter?

How about a generic Ethernet adapter using a serial or parallel port? If
you use a generic adapter should it be basic or intelligent?


Randy
n***@nouce.bellatlantic.net
2005-02-14 00:00:38 UTC
Permalink
On Sun, 13 Feb 2005 16:02:24 -0600, "Randy McLaughlin"
Post by Randy McLaughlin
The original point of this thread was using Ethernet on CP/M.
Exactly! The problem with eithernet is you need decent speed or you
get overrun errors or timeout errors. Granted using a modern card
that buffers the packet on card can really help. But only to a point.
And the drift was from the comentary and analogy that fast modems hit
that same wall under CP/M. Essentually the Eithenet adaptor is a very
fast modem.
Post by Randy McLaughlin
It MAY be possible to handle Ethernet using polling as long as it is limited
to simple client programs.
Very simple.
Post by Randy McLaughlin
The biggest question is how to hook up an Ethernet adapter to the system?
Find one designed for ISA-8 would be easiest but likely scarce. Next
bet is ISA16 bus card (still common) and treat it as it it were a
really big IC and use that. That means creating a very limited subset
of ISA-16 bus, some work but not much worse than IDE adaptor.
Post by Randy McLaughlin
Does anyone want to design a new S100 card?
Not I, I'd want to count on a decent processor interrupt structure.
Post by Randy McLaughlin
How about a "new" CP/M system with an integrated Ethernet adapter?
Easier and would eliminate bus based problems and would also give
a handle on configuration.
Post by Randy McLaughlin
How about a generic Ethernet adapter using a serial or parallel port? If
you use a generic adapter should it be basic or intelligent?
Most of the parallel adaptors (I have a slew of Xircom PE3s) are
somewhat smart and tolerate the slow parallel printer port. However
finding programming data on how to talk to something like that has
eluded me. The interface is pretty much a known thing, stock IBM AT
class improved bidirectional port. Duplicating that port on a S100
board or similar is fairly trivial.


Allison
Randy McLaughlin
2005-02-14 01:06:54 UTC
Permalink
Post by n***@nouce.bellatlantic.net
On Sun, 13 Feb 2005 16:02:24 -0600, "Randy McLaughlin"
Post by Randy McLaughlin
The original point of this thread was using Ethernet on CP/M.
<snip>
Post by n***@nouce.bellatlantic.net
Post by Randy McLaughlin
The biggest question is how to hook up an Ethernet adapter to the system?
Find one designed for ISA-8 would be easiest but likely scarce. Next
bet is ISA16 bus card (still common) and treat it as it it were a
really big IC and use that. That means creating a very limited subset
of ISA-16 bus, some work but not much worse than IDE adaptor.
Some of the problems with interfacing PC hardware to CP/M systems include
how many people will use different cards and it can get expensive to play
around with the interfacing. You would end up with one person succeeding
and no one else.
Post by n***@nouce.bellatlantic.net
Post by Randy McLaughlin
Does anyone want to design a new S100 card?
Not I, I'd want to count on a decent processor interrupt structure.
Post by Randy McLaughlin
How about a "new" CP/M system with an integrated Ethernet adapter?
Easier and would eliminate bus based problems and would also give
a handle on configuration.
It exists from Zilog 50mhz eZ80 Acclaim (50mhz should be fast enough), it
comes with a TCP/IP stack $99.00.
Post by n***@nouce.bellatlantic.net
Post by Randy McLaughlin
How about a generic Ethernet adapter using a serial or parallel port? If
you use a generic adapter should it be basic or intelligent?
Most of the parallel adaptors (I have a slew of Xircom PE3s) are
somewhat smart and tolerate the slow parallel printer port. However
finding programming data on how to talk to something like that has
eluded me. The interface is pretty much a known thing, stock IBM AT
class improved bidirectional port. Duplicating that port on a S100
board or similar is fairly trivial.
Allison
Randy
www.s100-manuals.com
n***@nouce.bellatlantic.net
2005-02-14 02:17:01 UTC
Permalink
On Sun, 13 Feb 2005 19:06:54 -0600, "Randy McLaughlin"
Post by Randy McLaughlin
Some of the problems with interfacing PC hardware to CP/M systems include
how many people will use different cards and it can get expensive to play
around with the interfacing. You would end up with one person succeeding
and no one else.
Well maybe not one but, not everyone. That is a problem.
Post by Randy McLaughlin
Post by n***@nouce.bellatlantic.net
Post by Randy McLaughlin
How about a "new" CP/M system with an integrated Ethernet adapter?
Easier and would eliminate bus based problems and would also give
a handle on configuration.
It exists from Zilog 50mhz eZ80 Acclaim (50mhz should be fast enough), it
comes with a TCP/IP stack $99.00.
A far more direct path and has the needed configuration control. Plus
there is no excuse for limiting the implemtation. I think even a
20mhz one would do well.

I started a topic to seperate the hardware issues from the software.
They are related but it may be easier to build the higher levels of
software (applications) and then fill in the hardware as it becomes
real.

Allison
Barry Watzman
2005-02-14 04:22:41 UTC
Permalink
Ok, consider this:

There do exist parallel port to Ethernet adapters. The were used in
early laptops, and occasionally desktops, to connect to Ethernet
networks. You can probably still find them on E-Bay. I know that they
exist, I have one, made by Xircom (later acquired by Intel).

It's certainly possible to connect one of those to a CP/M system's
parallel port, at least from a hardware perspective. [although they are
SO old, that a quick search didn't turn any of them up :-( ]

So that could be the solution on the hardware end.

The software issues, of course, remain
Post by Randy McLaughlin
Post by n***@nouce.bellatlantic.net
On Sun, 13 Feb 2005 16:21:55 GMT, Jay Maynard
Post by Jay Maynard
That's true, but it implicitly assumes the CPU has better things to be
doing. It didn't in most CP/M systems.
There lies the error. While CP/M is single tasked there was no reason
to assume that while waiting for a keypress it could not be checking
for other IO which many bios didn't do. With interrupts the IO can
be more random and less limited performance wise. There is little
reason why a 4mhz Z80 can't run at 38.4kbaud <or faster> if done
right. To do that the CPU must be available when ever a byte is
recieved and maybe buffer it until the applications wants it.
Allison
The original point of this thread was using Ethernet on CP/M.
It MAY be possible to handle Ethernet using polling as long as it is limited
to simple client programs.
The biggest question is how to hook up an Ethernet adapter to the system?
Does anyone want to design a new S100 card?
How about a "new" CP/M system with an integrated Ethernet adapter?
How about a generic Ethernet adapter using a serial or parallel port? If
you use a generic adapter should it be basic or intelligent?
Randy
n***@nouce.bellatlantic.net
2005-02-14 14:53:24 UTC
Permalink
On Mon, 14 Feb 2005 04:22:41 GMT, Barry Watzman
Post by Barry Watzman
There do exist parallel port to Ethernet adapters. The were used in
early laptops, and occasionally desktops, to connect to Ethernet
networks. You can probably still find them on E-Bay. I know that they
exist, I have one, made by Xircom (later acquired by Intel).
Obviously you didn't read another post of mine, thats ok. I happen to
have about 6 of the Xircom PE3 adaptors you speek of and still use
them on laptops.
Post by Barry Watzman
It's certainly possible to connect one of those to a CP/M system's
parallel port, at least from a hardware perspective. [although they are
SO old, that a quick search didn't turn any of them up :-( ]
Nasty little detail missed. Most CP/M system the parallel port while
ventronics compatable is NOT bidirectional. All PC-AT (and later)
ports are bidirectional. This is an important difference.

While for many machines making a PC compatable port is trivial
it assumes there is a bus. The alternate is to do something like
Timan Reh's GIDE and lift the Z80 to a scandiwtch board with the port
IO.
Post by Barry Watzman
So that could be the solution on the hardware end.
Indeed it could. I still see PE3s around occasionally.
Post by Barry Watzman
The software issues, of course, remain
That's a nasty one. I've been looking for a interface and driver
specification for those PE3s lately and so far nothing.

We could also look at the credit card NICs as well, they are available
cheap and may be better documented.

Allison
Jay Maynard
2005-02-13 22:06:49 UTC
Permalink
Post by n***@nouce.bellatlantic.net
On Sun, 13 Feb 2005 16:21:55 GMT, Jay Maynard
Post by Jay Maynard
That's true, but it implicitly assumes the CPU has better things to be
doing. It didn't in most CP/M systems.
There lies the error. While CP/M is single tasked there was no reason
to assume that while waiting for a keypress it could not be checking
for other IO which many bios didn't do.
Doing serial transfers at 38.4 wasn't something many systems of any speed or
size could do in the late 1970s or early 1980s. There was no point in
allowing for a 38.4K modem when you couldn't even buy anything faster than
300.

Try not to look at a 1977 system with 2005 eyes.

Yes, now that there *is* such a thing as Ethernet, the design decisions of
the late 70s are inappropriate. That does not make them inappropriate when
they were made.
Randy McLaughlin
2005-02-13 22:49:11 UTC
Permalink
Post by Jay Maynard
Post by n***@nouce.bellatlantic.net
On Sun, 13 Feb 2005 16:21:55 GMT, Jay Maynard
Post by Jay Maynard
That's true, but it implicitly assumes the CPU has better things to be
doing. It didn't in most CP/M systems.
There lies the error. While CP/M is single tasked there was no reason
to assume that while waiting for a keypress it could not be checking
for other IO which many bios didn't do.
Doing serial transfers at 38.4 wasn't something many systems of any speed or
size could do in the late 1970s or early 1980s. There was no point in
allowing for a 38.4K modem when you couldn't even buy anything faster than
300.
Try not to look at a 1977 system with 2005 eyes.
Yes, now that there *is* such a thing as Ethernet, the design decisions of
the late 70s are inappropriate. That does not make them inappropriate when
they were made.
Actually 38.4K was possible (with interrupts) but very few devices could
handle it.

19,200 baud was what I normally used.

I did use 38.4 on some systems with Wyse terminals.


Randy
www.s100-manuals.com
n***@nouce.bellatlantic.net
2005-02-14 00:26:44 UTC
Permalink
On Sun, 13 Feb 2005 16:49:11 -0600, "Randy McLaughlin"
Post by Randy McLaughlin
19,200 baud was what I normally used.
I did use 38.4 on some systems with Wyse terminals.
No surprize. Those were nice terminals.

Many terminals in 1978 could do that and did. I know
in '76 I was working for Hazeltine on the H1500 series
and the H1420. Those used 8080/2mhz and 8048/6mhz
and really weren't taxed. I must have 50 or so DEC Vt100
STP (serial printer buffer for V102) cards those had an
8085 at 3mhz and three serial ports that could all handle
19.2kb any two concurrently and 9600 all three concurrently.
That was 1982 tech.

To get back to the core of this topic. Slow CP/M IO was due to poor
implementation and not a processor limitation. Eithernet can work if
the same "we had to be simple and slow then" mind set is not accepted.
Though there is work to do as CP/M does not imply much
standardization hardware wise.


Allison
Jay Maynard
2005-02-14 00:39:46 UTC
Permalink
Post by n***@nouce.bellatlantic.net
To get back to the core of this topic. Slow CP/M IO was due to poor
implementation and not a processor limitation. Eithernet can work if
the same "we had to be simple and slow then" mind set is not accepted.
You're STILL being too judgmental.
The common, polled I/O implementation was plenty good enough for nearly
everyone in those days. It wasn't a poor implementation, it was an
acceptable one, and made a good tradeoff when compared with the pain and
effort required to get an interrupt-driven system working.

Yes, I agree that an interrupt-driven environment is likely necessary if
Ethernet is to be brought to CP/M. Just, please, stop slamming the common
CP/M polled environment as "poor", okkay? It was good enough for the times.
Post by n***@nouce.bellatlantic.net
Though there is work to do as CP/M does not imply much
standardization hardware wise.
Indeed not. This goes for every I/O device ever made for CP/M. In its own
way, the IBM PC was a great leap forward in that it simply forced everyone
making stuff for it to settle on the same standards.
n***@nouce.bellatlantic.net
2005-02-14 03:17:08 UTC
Permalink
On Mon, 14 Feb 2005 00:39:46 GMT, Jay Maynard
Post by Jay Maynard
Yes, I agree that an interrupt-driven environment is likely necessary if
Ethernet is to be brought to CP/M. Just, please, stop slamming the common
CP/M polled environment as "poor", okkay? It was good enough for the times.
We agree but our perspective is very different. I'm not looking back,
I was there looking forward. I was working with big systems and felt
then that many big system characteristices were desireable even on
the lowly 8080. My goal then and still is, get as much out of the
system as possible. The end result was I was still running CP/M on
medium powered (8mhz z80) S100 crates and my AmproLB+ with
SCSI disk in '91 to access usenet via 2400baud modems.

My last system built was in concert with Tim Olmstead a few years
back. His goal was a Z280 with Z8000. I build an intermediate system
with Z280/12.5mhz with cache, 16mb of SIMM ram and using ISA16 bus
for interface hardware using standard PC-AT cards as proof of
concept. The idea being build the CPU and memory and use
available and cheap PC IO. I likely could plug in a ISA16 NIC, the
bus signals would be valid and there is DMA and interrupt support.
It's the fastest CP/M thing I have next to the 1ghz PC running MyZ80.

So no, I'm not looking back judgementally. I took lessons and
learned. Why should I accept less than the best then or now. Why
should I use a NS* Horizon and not use the interrupts built in
to full advantage? The average NS* had the hardware and never
used it.
Post by Jay Maynard
Post by n***@nouce.bellatlantic.net
Though there is work to do as CP/M does not imply much
standardization hardware wise.
Indeed not. This goes for every I/O device ever made for CP/M. In its own
way, the IBM PC was a great leap forward in that it simply forced everyone
making stuff for it to settle on the same standards.
Yes, that was a double edged sword. The PC really represented the
dark side. In early '82 I was running a 8086/8mhz Multibus system
with 512k of ram and a very high performance 1mb 8" double sided
drives and controller. It ran circles around the PC-XT. People put
808xs in S100 crates and ported pc-DOS (you could back then) to S100
hardware for stellar performance. But, they werent standard and
adding new hardware was an intergration and programming chore.

CP/M in the 8 bit world was the closest thing to a standard we had and
it was excellent. Some of the hardware was somewhat standardized
in the S100 world and fostered some very good projects. But you
could not write a universal BISO that could allow for the wide variety
of disk controllers and other IO. Though within a vendor family
such as Cromemco, Compupro and others it was done.

In the monoboard world where Ampro, Micromint SB180, the
Xerox Big board and others lived fosterd a standard hardware to
evolve to the next level of system software without the problem if
you developed a better BIOS for an Ampro would it run on all of
them. That didn't solve all the problems but, it did evolve.


Allison
n***@nouce.bellatlantic.net
2005-02-14 00:13:23 UTC
Permalink
On Sun, 13 Feb 2005 22:06:49 GMT, Jay Maynard
Post by Jay Maynard
Doing serial transfers at 38.4 wasn't something many systems of any speed or
size could do in the late 1970s or early 1980s. There was no point in
allowing for a 38.4K modem when you couldn't even buy anything faster than
300.
Didn't use modems. I was useing my CP/M hardware talking via serial
wire to PDP-11s at 38.4Kb. I started doing it initally at 9600 in
1980 and by '82 I was up to 38.4k and for short lines (VAX end
permitting) at 56k using 6mhz z80s.

Along the way I was doing serial interfaced Hard disk (shareable
between systems aka serial bus) at 64kb/s with 4mhz Z80s and 5mhz
8085s. Keep in mind 64kb/s is only one byte every 125uS and compared
to floppies thats really slow. People had been doing floppies for
years by then.

Inshort I was trying to get data from one point to another using
serial and fast. If Eithenet hardware wasn't $500+ per system in
'83 I'd have looked at that more seriously. It didn't drop under 100$
a system till about mid 1990s. Now, in 2005 I much consider it as
it's <10$ a system for the interface and offers a nice fast serial
bus.
Post by Jay Maynard
Try not to look at a 1977 system with 2005 eyes.
;) I've accused many of the PC centric of that. I built my Altair in
Jan 1975, My NS* Horizon in '77 and was one of the users of CP/M 1.3,
later 1.4 and 2.2. I still ahve a 1.4 system! So I've been there
for a while and only have a few dozen CP/M systems here that I can use
and refer to.
Post by Jay Maynard
Yes, now that there *is* such a thing as Ethernet, the design decisions of
the late 70s are inappropriate. That does not make them inappropriate when
they were made.
Eithernet was available and in use by 1980. DEC had the largest
network in the works running Eithernet hardware (50 nodes in 1981)
as they were one of the developers. A refresher, it used to be called
DIX eithernet and DIX stood for Digitial Equipment Corp (DEC), Intel
and Xerox.

Allison
primo
2005-02-13 21:20:42 UTC
Permalink
On Sun, 13 Feb 2005 10:16:30 +0100, Peter Smith
Post by Peter Smith
Hey, that's a very good description of exactly the problem I was headed
with (the BBS problem). Fortunately you can ease this by using a faster
system (instead of using 2 or 4 MHz, use an Z80H with 8 MHz for
example). This does not really solve the problem (as you already
described in detail), but my experience was, that 2400 Baud is possible
with 8 MHz (that sounds not much, but in 1990 it was superior) and a BBS
software.
Regards
Peter
Even a 4 mhz z80 could keep up with 2400, I ran a fidonode on a
Xerox820IIHD that even handled zmodem protocol file transfers over
fidonet at 2400. That was using the drbs software and bye. Using
mdm740, mex, imp or zmp I didn't have problems till I got up over
9600.

My Balcones bnv205 (s100 box based on a teletek fdc1 card) even uses
up to a 9600 bps speed for the terminal port, I can have imp running
at 9600 on the serial port at the same time that console output is
going to the terminal at 9600.
n***@nouce.bellatlantic.net
2005-02-13 21:34:06 UTC
Permalink
Post by primo
Even a 4 mhz z80 could keep up with 2400, I ran a fidonode on a
Xerox820IIHD that even handled zmodem protocol file transfers over
fidonet at 2400. That was using the drbs software and bye. Using
mdm740, mex, imp or zmp I didn't have problems till I got up over
9600.
Some machines like the early Kaypros were slow and had high overhead
for the video.

My amproLB+ loafed at 2400 and ran well even at 4800, On a direct line
I'd even tried it connected to a VAX at 9600. Some systems and bios
however did poorly.
Post by primo
My Balcones bnv205 (s100 box based on a teletek fdc1 card) even uses
up to a 9600 bps speed for the terminal port, I can have imp running
at 9600 on the serial port at the same time that console output is
going to the terminal at 9600.
Not surprizing.

Allison
French Luser
2005-02-15 13:04:19 UTC
Permalink
Hello, "primo"!
Even a 4 mhz z80 could keep up with 2400, I ran a fido node on a
Xerox820IIHD that even handled zmodem protocol file transfers over
fidonet at 2400. That was using the drbs software and bye. Using
mdm740, mex, imp or zmp I didn't have problems till I got up over
9600.
You seem to be more experienced about ZMODEM than me.

My question: What happened to the source code of ZMODEM?

Was it ever released to the public domain, or did it remain
"proprietary"?

(I was considering making a 8086 port, but decided that,
without original source code, it would be too much work.)

Yours Sincerely,
"French Luser"
CBFalconer
2005-02-15 17:41:59 UTC
Permalink
French Luser wrote:
... snip ...
Post by French Luser
My question: What happened to the source code of ZMODEM?
Was it ever released to the public domain, or did it remain
"proprietary"?
(I was considering making a 8086 port, but decided that,
without original source code, it would be too much work.)
Long since done (late '80s). Look up the PD domain source for
Binkleyterm. This was the communications module that allowed
everything else on FidoNet to work on the 88 up. IIRC the Zmodem
modules were part of it. Binkley in turn depended on a TSR module
that provided the raw modem communications.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
French Luser
2005-02-15 12:50:10 UTC
Permalink
Post by n***@nouce.bellatlantic.net
When doing any networking (regardless of interface) on a CP/M
machine you need an interrupt to tell you **hey theres data on the
pipe and it may be for you** without sitting in a wasteful polling
loop.
That's why I wrote several times that the only logical version
of CP/M (to access the Internet, or provide a Web server)
is Concurrent CP/M. CP/M-86, being a mere 8086 version
of CP/M 2.2, is not sophisticated enough. All the Internet
utilities are designed for a multi-tasking OS, and Concurrent
CP/M (as its name implies) is such an OS. And we know that
DR Net was working. Of course, at the time it was not using
TCP/IP, but there is nothing, technically, preventing one to
implement a version of DR Net using TCP/IP.

Yours Sincerely,
"French Luser"
Jay Maynard
2005-02-15 13:44:28 UTC
Permalink
Post by n***@nouce.bellatlantic.net
When doing any networking (regardless of interface) on a CP/M
machine you need an interrupt to tell you **hey theres data on the
pipe and it may be for you** without sitting in a wasteful polling
loop.
This does not exclude CP/M from consideration; it just means that older
systems will have to be significantly reworked if they're to be included.
All the Internet utilities are designed for a multi-tasking OS
See uIP ( http://www.sics.se/~adam/uip/ ) for a counterexample by
demonstration.

Personally, I'm thinking in terms of a BYE-style implementation of uIP with
built-in FTP server. A telnet/FTP client should be even simpler. In either
case, this, with a SLIP link, should be feasible on just about any system.
n***@nouce.bellatlantic.net
2005-02-15 14:29:39 UTC
Permalink
On Tue, 15 Feb 2005 13:44:28 GMT, Jay Maynard
Post by Jay Maynard
This does not exclude CP/M from consideration; it just means that older
systems will have to be significantly reworked if they're to be included.
BIOS improvements would help.
Post by Jay Maynard
See uIP ( http://www.sics.se/~adam/uip/ ) for a counterexample by
demonstration.
Works on some fairly small cpus when compared to a Z80/Z180.
Post by Jay Maynard
Personally, I'm thinking in terms of a BYE-style implementation of uIP with
built-in FTP server. A telnet/FTP client should be even simpler. In either
case, this, with a SLIP link, should be feasible on just about any system.
Don't neglect PPP as a link. Telnet and FTP are the likely and most
useful candidates. The scarey one I've seen a few times over the
years here is mutterings about doing a web browser. I think that's
doable if it's a lynx style (text only) as a Mosaic style means doing
a lot of GUI work that many z80 systems just can't. Though with
modest low res(320x160 cellphone resolution) graphics it could be
done. The latter is really a display and interface hardware problem.


Allison
Jay Maynard
2005-02-15 14:46:04 UTC
Permalink
Post by n***@nouce.bellatlantic.net
On Tue, 15 Feb 2005 13:44:28 GMT, Jay Maynard
Post by Jay Maynard
This does not exclude CP/M from consideration; it just means that older
systems will have to be significantly reworked if they're to be included.
BIOS improvements would help.
I think I just said that. :-)
Post by n***@nouce.bellatlantic.net
Post by Jay Maynard
See uIP ( http://www.sics.se/~adam/uip/ ) for a counterexample by
demonstration.
Works on some fairly small cpus when compared to a Z80/Z180.
Indeed. I think the big issue with porting uIP to CP/M will be in making the
code compile with BDS C. (Is there another C compiler out there for CP/M
that's freely available and does ANSI C? If so, that will make life a lot
simpler.)
Post by n***@nouce.bellatlantic.net
Don't neglect PPP as a link.
Indeed, although I'm not sure it gains anything in this case over the
simpler SLIP. The extra code may not be worth it, since we're not proposing
to use it over a modem with a random ISP. (Are we?)
Post by n***@nouce.bellatlantic.net
Telnet and FTP are the likely and most useful candidates.
Indeed. An HTTP server might be useful, but only as a demonstration project.
Post by n***@nouce.bellatlantic.net
The scarey one I've seen a few times over the
years here is mutterings about doing a web browser. I think that's
doable if it's a lynx style (text only) as a Mosaic style means doing
a lot of GUI work that many z80 systems just can't. Though with
modest low res(320x160 cellphone resolution) graphics it could be
done. The latter is really a display and interface hardware problem.
Yeah, but can you fit it into CP/M? lynx, on my system, is a meg and a half.
Getting even a non-graphical web browser on CP/M will almost certainly
involve lots of overlays, if not banked memory.
n***@nouce.bellatlantic.net
2005-02-15 15:25:32 UTC
Permalink
On Tue, 15 Feb 2005 14:46:04 GMT, Jay Maynard
Post by Jay Maynard
Post by n***@nouce.bellatlantic.net
Post by Jay Maynard
See uIP ( http://www.sics.se/~adam/uip/ ) for a counterexample by
demonstration.
Works on some fairly small cpus when compared to a Z80/Z180.
Indeed. I think the big issue with porting uIP to CP/M will be in making the
code compile with BDS C. (Is there another C compiler out there for CP/M
that's freely available and does ANSI C? If so, that will make life a lot
simpler.)
Look around for Hitech C, it's available for free and very good.
Post by Jay Maynard
Post by n***@nouce.bellatlantic.net
Don't neglect PPP as a link.
Indeed, although I'm not sure it gains anything in this case over the
simpler SLIP. The extra code may not be worth it, since we're not proposing
to use it over a modem with a random ISP. (Are we?)
We might! ;) It was a thought rather than a requirement.
Post by Jay Maynard
Post by n***@nouce.bellatlantic.net
Telnet and FTP are the likely and most useful candidates.
Indeed. An HTTP server might be useful, but only as a demonstration project.
HTTP server is easy, it's been done on some trivially small cpus.
Post by Jay Maynard
Post by n***@nouce.bellatlantic.net
The scarey one I've seen a few times over the
years here is mutterings about doing a web browser. I think that's
doable if it's a lynx style (text only) as a Mosaic style means doing
a lot of GUI work that many z80 systems just can't. Though with
modest low res(320x160 cellphone resolution) graphics it could be
done. The latter is really a display and interface hardware problem.
Yeah, but can you fit it into CP/M? lynx, on my system, is a meg and a half.
Getting even a non-graphical web browser on CP/M will almost certainly
involve lots of overlays, if not banked memory.
I think yes but, it would have to be very tight code for size and
speed. lynx is actually fairly small. I also have a brwoser I use
for winders called OffbyOne (OB1) and while it's not a complete
browser compared to mozilla or firefox its remarkably useful and fast
(even on a 486 running winders95 and 16mb), FYI: for a win95 install
it's under 2mb. Based on that a limited GUI browser that does say
320x160x256 is likely manageable but it will be a truncated
application. I think that would be more an exercize than useful
wer lynx is practical and easier to apply to a wider range of systems.


Allison
Jay Maynard
2005-02-15 15:47:07 UTC
Permalink
Post by n***@nouce.bellatlantic.net
On Tue, 15 Feb 2005 14:46:04 GMT, Jay Maynard
Post by Jay Maynard
Indeed. I think the big issue with porting uIP to CP/M will be in making the
code compile with BDS C. (Is there another C compiler out there for CP/M
that's freely available and does ANSI C? If so, that will make life a lot
simpler.)
Look around for Hitech C, it's available for free and very good.
Just snagged it. Looks like it just might do the trick; it's certainly
closer than BDS C would be.
Post by n***@nouce.bellatlantic.net
Post by Jay Maynard
Indeed. An HTTP server might be useful, but only as a demonstration project.
HTTP server is easy, it's been done on some trivially small cpus.
The server itself is easy; it's included as a sample with uIP. The hard part
is doing something useful with one.
n***@nouce.bellatlantic.net
2005-02-15 16:37:49 UTC
Permalink
On Tue, 15 Feb 2005 15:47:07 GMT, Jay Maynard
Post by Jay Maynard
Just snagged it. Looks like it just might do the trick; it's certainly
closer than BDS C would be.
I'd also forgotten Borland Turbo-C, its' also free and archived on the
Borland site last I looked.
Post by Jay Maynard
Post by n***@nouce.bellatlantic.net
Post by Jay Maynard
Indeed. An HTTP server might be useful, but only as a demonstration project.
HTTP server is easy, it's been done on some trivially small cpus.
The server itself is easy; it's included as a sample with uIP. The hard part
is doing something useful with one.
Static pages would be one. Also I'd think simple stuff like time,
temperature and other enviornment information.

Myself I still think print-server and disk servers for CP/M systems
that are disk poor is a useful server task. It would be easiest to
provide those services using linux and a old 486 or small Pentium the
client side is the needed part for CP/M. Not to say that cannot be
done using Z80/Z180 hardware and it's certainly doable. I've done it
but not using IP based networking.

Allison
n***@nouce.bellatlantic.net
2005-02-15 16:58:01 UTC
Permalink
On Tue, 15 Feb 2005 16:37:49 GMT, ***@nouce.bellatlantic.net wrote:

One appication I'd totally blanked on is EMAIL! a cp/m system to do
text email via an IP net would be useful. Virus resistant too!

The ability to directly network to a POP/SMTP serverand collect email
similar to something like pine would be reasonable for CP/M.
Translating basic HTML email to readable text would be a good and
still avoid the issues of a GUI. Thinking about that has an appeal to
me.

Allison
Randy McLaughlin
2005-02-15 17:34:21 UTC
Permalink
Post by n***@nouce.bellatlantic.net
One appication I'd totally blanked on is EMAIL! a cp/m system to do
text email via an IP net would be useful. Virus resistant too!
The ability to directly network to a POP/SMTP serverand collect email
similar to something like pine would be reasonable for CP/M.
Translating basic HTML email to readable text would be a good and
still avoid the issues of a GUI. Thinking about that has an appeal to
me.
Allison
Text only email is basically Telnet with a simple database. Anyone can read
or write their own email using just a telnet program.

As for HTML just ignore it, I have a two way pager (T900) that is a wireless
email device, when people sent me HTML (rich text) I see the HTML code but
most emails are still readable. The biggest problem I have is email size
which would not be a problem with CP/M (within reason).


Randy
n***@nouce.bellatlantic.net
2005-02-15 18:32:16 UTC
Permalink
On Tue, 15 Feb 2005 11:34:21 -0600, "Randy McLaughlin"
Post by Randy McLaughlin
Text only email is basically Telnet with a simple database. Anyone can read
or write their own email using just a telnet program.
Yes, it brings a real app that is useful. the datbase part it
trivial.
Post by Randy McLaughlin
As for HTML just ignore it, I have a two way pager (T900) that is a wireless
email device, when people sent me HTML (rich text) I see the HTML code but
most emails are still readable. The biggest problem I have is email size
which would not be a problem with CP/M (within reason).
I find that annoying. I use on some of my PC systems Popcorn (very
small 240k of widers bloat) it fits completely on a floppy with room
to spare. it also doesnt read HTML though it displays the source.
Actually it would be trivial to recognize the basic tags and do what
runoff did. The the resulting pruned result would be much more
readable.

As to mail size, for text I'd think 10-20K of is do able in a 56k or
better system. The html to text module would be less than a few K.
A real factor is disk space for storage of recieve emails.

Allison
n***@nouce.bellatlantic.net
2005-02-15 14:22:14 UTC
Permalink
On Tue, 15 Feb 2005 13:50:10 +0100, "French Luser"
Post by French Luser
Post by n***@nouce.bellatlantic.net
When doing any networking (regardless of interface) on a CP/M
machine you need an interrupt to tell you **hey theres data on the
pipe and it may be for you** without sitting in a wasteful polling
loop.
That's why I wrote several times that the only logical version
of CP/M (to access the Internet, or provide a Web server)
is Concurrent CP/M. CP/M-86, being a mere 8086 version
of CP/M 2.2, is not sophisticated enough. All the Internet
utilities are designed for a multi-tasking OS, and Concurrent
CP/M (as its name implies) is such an OS.
You do not need Concurrent CP/M to use interrupts, nor MPM.
CP/M 2.2 is sophisticated enough though, as I've said repeatedly the
BIOS may be very unsophisticated. There lies the difference.
I may add the biggest difference between CP/M2 and MPM or later
Concurrent was in the area of things reguired of the BIOS. For
example you could use a basic CP/M 2 bios to get MPM booted and
basically running but, it was a strangled system until all the
required functionality was operational.

For many applications via a network a single tasking system like
CP/M2.2 is easily adaquate (assuming the bios is decent).
Adding simple forground backround tasking is also trivial for
CP/M2.2 [it's been done with printspoolers and many other things].

I does beg the question. What network task/application would you
want a Z80 doing that requirs multitasking?

I've maintained that the only limits on CP/M2.2 that's mildly annoying
is it's not reentrant and the file systems doesn't go byond 8mb
and those are solved in the later improved (P2DOS, Novados ZRdos)
replacements for the BDOS.
Post by French Luser
And we know that
DR Net was working. Of course, at the time it was not using
TCP/IP, but there is nothing, technically, preventing one to
implement a version of DR Net using TCP/IP.
DR Net didn't care how the systems communicated as that was
an implmentation issue. So doing it with TCP/IP networking
is just an implmentation issue.

Allison
Anonymous Guy
2005-02-15 22:36:20 UTC
Permalink
Post by French Luser
Post by n***@nouce.bellatlantic.net
When doing any networking (regardless of interface) on a CP/M
machine you need an interrupt to tell you **hey theres data on
the pipe and it may be for you** without sitting in a wasteful
polling loop.
That's why I wrote several times that the only logical version
of CP/M (to access the Internet, or provide a Web server)
is Concurrent CP/M. CP/M-86, being a mere 8086 version
of CP/M 2.2, is not sophisticated enough.
This is incorrect.

Single-tasking CP/M-86 is sufficiently 'sophisticated' to allow
programmatic access to the resources of the underlying hardware.

These resources include 640K (or much more) of system memory, plus
the ROM BIOS -- where many specialized interrupt services are
available to the CP/M-86 programmer.

Software to access the 'Net could MOST DEFINITELY be written for
single-tasking CP/M-86, using one of two possible philosophies:

1. The 'networking layer' could be installed as a separate, memory-
resident FIDD (field-installable device driver), with the 'Net
access software written to call the services of this driver.

Or,

2. The 'Net access software itself could be written to include its
own 'networking layer' which loads when the program is invoked,
and disappears when the program is terminated.

Frankly, I prefer the second approach. It's much easier for the
user, and also doesn't require system memory to be permanently
allocated for 'networking.'

I've been speaking, here, of 'CP/M-86 For The IBM' -- which gives
the programmer virtually unfettered access to system resources.

'Personal CP/M-86' -- which is the O.S. that you use, Emmanuel --
is slightly more problematic. 'Personal CP/M-86' is somewhat
'dictatorial,' and deliberately blocks access to some system
resources. This is a major reason why I don't like, and won't
use, 'Personal CP/M-86.'
Post by French Luser
All the Internet utilities are designed for a multi-tasking OS...
Wrong again. This message was posted to Usenet using software
operating under DOS -- a single-tasking O.S.

So either your premise is flawed, or else this message is merely
a figment of your imagination. You decide. :)
n***@nouce.bellatlantic.net
2005-02-16 14:55:05 UTC
Permalink
On Tue, 15 Feb 2005 22:36:20 +0000 (UTC), "Anonymous Guy"
Post by Anonymous Guy
Post by French Luser
Post by n***@nouce.bellatlantic.net
When doing any networking (regardless of interface) on a CP/M
machine you need an interrupt to tell you **hey theres data on
the pipe and it may be for you** without sitting in a wasteful
polling loop.
That's why I wrote several times that the only logical version
of CP/M (to access the Internet, or provide a Web server)
is Concurrent CP/M. CP/M-86, being a mere 8086 version
of CP/M 2.2, is not sophisticated enough.
This is incorrect.
Single-tasking CP/M-86 is sufficiently 'sophisticated' to allow
programmatic access to the resources of the underlying hardware.
While CP/M-86 is similar to "CP/M" meaning common use CP/M-80
your point is meaningless.

I never said that underlying resourcees are are unaccessable. I was
talking to wasteful programmed polling loops vs actions that are
asynchronously triggers by an interrupt.
Post by Anonymous Guy
These resources include 640K (or much more) of system memory, plus
the ROM BIOS -- where many specialized interrupt services are
available to the CP/M-86 programmer.
ONLY on a PC. We are not speaking of PCs and the generalized CP/M
world is not PC/x86 based.
Post by Anonymous Guy
Software to access the 'Net could MOST DEFINITELY be written for
IT's been done for PC hardware.
Post by Anonymous Guy
Post by French Luser
All the Internet utilities are designed for a multi-tasking OS...
Wrong again. This message was posted to Usenet using software
operating under DOS -- a single-tasking O.S.
Dos allowed background tasks driven of the real time clock interrupt.
Most CP/M (ESPECIALLY those based on 8080, z80,z180,NSC800 and
8085) are generally without the same IO structures as a PC/
Post by Anonymous Guy
So either your premise is flawed, or else this message is merely
a figment of your imagination. You decide. :)
Figment of your imagination. If I wanted a PC Id use one.

The major point of the whole discussion of how to do networking under
CP/M really should be "how to do CP/M networking on a NON-PC system
without the implied underlying BIOS and hardware resources.".
The average S100 crate and other NON-PC hardware does not generally
enjoy the standardization or bounty of hardware. It can but, the
different _it can_ vs expected. Also I have a Multibus-II based
CP/M-86 system and I can assure you the bios looks nothing like a PC
as I personally wrote it. It would be nearly a year after that
before I'd see a IBM-PC. I might add I was appalled at how slow it
was.


Allison
Anonymous Guy
2005-02-16 23:27:47 UTC
Permalink
[ ... snip ... ]
Post by Anonymous Guy
These resources include 640K (or much more) of system memory,
plus the ROM BIOS -- where many specialized interrupt services
are available to the CP/M-86 programmer.
ONLY on a PC. We are not speaking of PCs and the generalized
CP/M world is not PC/x86 based.
I was responding to Emmanuel Roche's specific assertion that
"...CP/M-86, being a mere 8086 version of CP/M 2.2, is not
sophisticated enough" to access the 'Net.

I also mentioned that I was speaking of 'CP/M-86 For The IBM.'

Monsieur Roche does, indeed, run CP/M-86 on an IBM clone, so
the response was relevant.

The brief quote from your message was included merely to set
the context for Emmanuel's remarks. No aspersions were cast
on you personally.
The major point of the whole discussion of how to do networking
under CP/M really should be "how to do CP/M networking on a NON-PC
system without the implied underlying BIOS and hardware resources."
[ ... snip ... ]
Allison
Well, we took a momentary side trip. It happens sometimes.

Carry on.

Bob McConnell
2005-02-13 00:41:25 UTC
Permalink
Post by Kelly Hall
Post by Jay Maynard
Many, if not most, CP/M systems fit this description. A single-tasking
system on a Z-80 didn't need interrupts to work quite well.
I'm dubious. Are you saying the designers usually just tied the Z80 INT
and NMI lines high? Seems like a huge waste to me.
Kelly
Not on any system I ever worked on. But I did have to write ISR
routines for a couple of them. The standard BIOS did not support type
ahead buffers on the console.

Bob McConnell
N2SPP
n***@nouce.bellatlantic.net
2005-02-12 16:59:00 UTC
Permalink
On Sat, 12 Feb 2005 03:08:38 GMT, Jay Maynard
Post by Jay Maynard
Post by Kelly Hall
Post by Randy McLaughlin
Many CP/M systems had no interrupt support it was common to have separate
cards to support interrupts (Imsai's PIC-8, CompuPro's SS1 and others).
When you say "How amusingly primitive" are you referring to CP/M?
CP/M doesn't amuse me, but a general purpose system without interrupts
(so that all IO is polled) I find quite amusing. In fact, I'd consider
it shite.
Many, if not most, CP/M systems fit this description. A single-tasking
system on a Z-80 didn't need interrupts to work quite well.
I happen to agree with Kelly. Yes, CP/M does work well enough with
interrupts (none at all) and it's cheap to implment that way too.

However, once you've use a CP/M system with interrupts on the IO
such that you can type ahead and not have to wait for the printer to
complete to go back to typing you suddenly realize how big a
difference it is. That's not a CP/M issue in it self as CP/M doesnt
care but, the bios design can make a bland cp/m system look good
or soso and thats where buffered IO and interrupts are important.

Allison
Peter Smith
2005-02-10 18:00:34 UTC
Permalink
Post by Randy McLaughlin
Using an Ethernet-to-RS232 would be like watering your lawn through a straw,
it is uncommon for CP/M systems to run over 19200 baud (many are slower than
that). For the cost of one of these adapters you can buy a Zilog Acclaim
($99.00) and bring up a 50mhz CP/M system with the Ethernet adapter already
attached.
You talk about making a new system, not using an old (already built)
system and connect it via Ethernet. That's a total different approach.

OK, you can build your new system with smart highly integrated chips,
but this is not really an art, or ?

Unfortunately my URL ends on a german page, but may be some other here
are interested in a COM-to-LAN kit :
http://www.segor.de/L1Bausaetze/ComLanA.shtml

Regards
Peter
Randy McLaughlin
2005-02-10 18:26:17 UTC
Permalink
Post by Peter Smith
Post by Randy McLaughlin
Using an Ethernet-to-RS232 would be like watering your lawn through a
straw, it is uncommon for CP/M systems to run over 19200 baud (many are
slower than that). For the cost of one of these adapters you can buy a
Zilog Acclaim ($99.00) and bring up a 50mhz CP/M system with the Ethernet
adapter already attached.
You talk about making a new system, not using an old (already built)
system and connect it via Ethernet. That's a total different approach.
OK, you can build your new system with smart highly integrated chips, but
this is not really an art, or ?
Unfortunately my URL ends on a german page, but may be some other here are
http://www.segor.de/L1Bausaetze/ComLanA.shtml
Regards
Peter
Having a Ethernet-to-RS232 plugged into your computer still gives you
nothing until you decide how to drive it. The Acclaim has two serial ports
and can do the same thing. Most Ethernet-to-RS232 adapters use 8052 cores
and as such are not as familiar as the eZ80 for and code changes desired.
I'd have to see the specs on the particular adapters you would recommend but
thos I've looked at usually act as webservers or ftp servers where
process-controll devices pass their data to hosts via data drops and as is
would not be adaptable to CP/M networking.

The biggest plus for the Acclaim is that it is CP/M compatible and CP/M is
being brought up on it. The F91 used in the Acclaim is also the same CPU as
the Imsai Series 2.

The F91 (Acclaim) will have a base of users that will be running CP/M on it
so the ethernet it has is a good starting point.

I also believe that the F91 can be used as an add-on adapter for existing
CP/M systems. The Acclaim is available for the right price and has both
serial and parallel ports included.


Randy
www.s100-manuals.com
Jay Maynard
2005-02-10 19:16:45 UTC
Permalink
Post by Randy McLaughlin
would not be adaptable to CP/M networking.
Okkay, time out. We may be talking about different things here.

Just what do people mean by "CP/M networking"? To me, it means attaching a
CP/M system to my LAN, then transferring files in and out of it and
connecting as though you were at a local console from elsewhere on the LAN.

The obvious way to go about this, given everyone's Internet familiarity, is
vis FTP and telnet. Clients for both are fairly straightforward; an FTP
server isn't bad either. A telnet server gets a bit more interesting if you
want any reasonable amount of TPA to run things in from the remote
connection.

Providing these functions through an intelligent adapter (either an eZ80, or
one of the parallel port adapters) will require some programming on the CP/M
side. There's some value in using a platform folks already know, but if an
adapter can be found that requires NO on-board programming, that's even
better. This means that the parallel or serial-attached adapters would have
to do the desired protocol all by themselves, and present an interface that
the CP/M system can talk to. This is easy for telnet servers, as there are
plenty of those in the marketplace. File transfer gets harder.

So...what are we looking to accomplish, first of all? Once we agree on that,
then the how is something we can meaningfully talk about.
Randy McLaughlin
2005-02-10 19:38:15 UTC
Permalink
Post by Jay Maynard
Post by Randy McLaughlin
would not be adaptable to CP/M networking.
Okkay, time out. We may be talking about different things here.
Just what do people mean by "CP/M networking"? To me, it means attaching a
CP/M system to my LAN, then transferring files in and out of it and
connecting as though you were at a local console from elsewhere on the LAN.
The obvious way to go about this, given everyone's Internet familiarity, is
vis FTP and telnet. Clients for both are fairly straightforward; an FTP
server isn't bad either. A telnet server gets a bit more interesting if you
want any reasonable amount of TPA to run things in from the remote
connection.
Providing these functions through an intelligent adapter (either an eZ80, or
one of the parallel port adapters) will require some programming on the CP/M
side. There's some value in using a platform folks already know, but if an
adapter can be found that requires NO on-board programming, that's even
better. This means that the parallel or serial-attached adapters would have
to do the desired protocol all by themselves, and present an interface that
the CP/M system can talk to. This is easy for telnet servers, as there are
plenty of those in the marketplace. File transfer gets harder.
So...what are we looking to accomplish, first of all? Once we agree on that,
then the how is something we can meaningfully talk about.
I agree, in a previous post I said crawl before you run. The biggest trick
is to simply decide on a goal.

For me a reasonable goal would be an ftp client running on CP/M, telneting
in or out is interesting but that's about it.


I want a good amount of control, a general purpose device to ethernet is the
obvious way to go. There are two methods: A simple ethernet controller
connected via parallel port or a smart controller connected by either a
serial or parallel port.

With the simple ethernet controller everything is done by the host CPU and
as such would require more resources. It is reasonable if the host has a
decent speed, especially if it has more than 64K.

With a smart controller I recommend one that is user programable.


I would also say that if multiple people are interested in the same goal
then try and use as few different methods as possible, this can speed up
development.


Randy
www.s100-manuals.com
Bill Sudbrink
2005-02-10 22:10:31 UTC
Permalink
Hmmm... How's this for a silly idea. A card that has ethernet
on one side and a 34 and/or 50 connector card edge on the other.
On the ethernet side, it does tftp to an ip address set on the
card via dip switches maybe. On the card edge side, it looks
like a 5 1/4 or 8 inch floppy drive. It buffers a "track" of
data, read from the tftp server, at a time, responding to seeks,
just like a real drive. The buffered data depends on what "track"
the pseudo-head is on.

It would have to take the binary data and recreate the FM or
MFM or whatever signal coming from the pseudo-head and the index
pulses as well. Maybe some more switches to set hard or soft
sectored, encoding, number of sectors, etc.???

Just blue skying without thinking too much about how hard it would
really be.
Frank McConnell
2005-02-11 02:34:53 UTC
Permalink
Post by Randy McLaughlin
There are some cheap Ethernet adapters with a simple parallel interface.
These could be interfaced to a variety of S100 cards. Another problem with
many S100 systems is the lack of interrupts. I do not believe it is
reasonable to do TCP/IP with polling.
It Depends.

Suppose what you want out of "networking with CP/M" is a Telnet client
done as a monolithic application including terminal emulator, Telnet
client, TCP/IP stack, and network interface driver. I'd expect that
polling could be made to work OK for that. The main loop would be
something that calls routines as follows:

(a) poll the keyboard for input; push any received input character(s)
down the stack through the Telnet client

(b) poll the network for input; push any received packets up the stack
from the bottom (which dispatches them to IP or ARP)

(c) poll the stack to let it run time-oriented tasks like IP fragment
reassembly timeout and TCP retransmission

You do need some sort of time counter so that the time-oriented tasks
know when to do their things. A clock tick with frequency 2Hz would
probably suffice. 10Hz-100Hz would perhaps be better. It would best
be run off a periodic interrupt, but could in a pinch be derived from
how many times per second you make it through the main loop.

I used to work on a portable embeddable TCP/IP stack for a living, and
have done this sort of stuff to get a port basically functional while
still working out the details of how to program the timers and
interrupt controller and stuff like that.

If you fit a TFTP server in there too, that would probably work OK in
this environment too, and then you'd have something not too different
from the original MIT PC-IP in terms of functionality.

-Frank McConnell (funny From: fully functional)
French Luser
2005-02-11 12:11:08 UTC
Permalink
I have read all the messages in this thread.
Post by French Luser
Please, don't re-invent the wheel.
Digital Research spent years integrating networks
with theirs various Operating Systems.
If you are tinkering with CP/M (2.2),
implement CP/NET Version 1.2,
since (16-bit) DR Net recognizes it.
I have also written, several years ago,
that the logical way, for me, to reach
the Internet, was via a Linux box linked
to a CP/M 2.2 system by CP/NET 1.2.

This way, the Linux box is specialized
with all the Internet standards (which are
based upon Unix), and the CP/M system
is not changed at all. (Not one byte!)

In addition, Digital Research worked
several years, to be sure that CP/NET /
DR/Net can be implemented in a
portable way, even by using C...

It would be totally crazy not to take
advantage of all this work.

Unless, of course, if you have enough
time and money to re-invent the wheel...

(Another advantage of CP/NET is that
one of its implementation, based on
ARCnet is still widely used in factories...
and factories are much less subject
to fashion or marketing fads! As long
as it will keep running, they will keep
using it... Like us CP/M systems!)

(By the way, this proves that CP/NET
can be implemented using several
ways...)

Yours Sincerely,
"French Luser"
Hector Peraza
2005-02-11 13:23:03 UTC
Permalink
French Luser <***@microsoft.com> wrote:
: I have also written, several years ago,
: that the logical way, for me, to reach
: the Internet, was via a Linux box linked
: to a CP/M 2.2 system by CP/NET 1.2.

That sounds like an interesting idea, and if I have sometime this weekend
I'll write a simple Linux CP/NET server and try it with my P112 board.

One thing still is not very clear to me and is how one could reach the
internet using just CP/NET. If I understand it correctly, CP/NET lets you to
connect to disk drives on the server (master) so they look like local drives
on the client machine (requester), and to access in a similar way to remote
printers.

Regards,
Hector.
d***@cs.csbuak.edu
2005-02-11 22:13:03 UTC
Permalink
Post by French Luser
(Another advantage of CP/NET is that
one of its implementation, based on
ARCnet is still widely used in factories...
and factories are much less subject
to fashion or marketing fads! As long
as it will keep running, they will keep
using it... Like us CP/M systems!)
Speaking of ARCnet, I have eight 8-bit ISA ARCnet cards that can ride
along for free with P112 kits.
--
David Griffith
***@cs.csbuak.edu <-- Switch the 'b' and 'u'
Shawn Sijnstra
2005-02-14 04:37:09 UTC
Permalink
Post by French Luser
I have read all the messages in this thread.
Post by French Luser
Please, don't re-invent the wheel.
Digital Research spent years integrating networks
with theirs various Operating Systems.
If you are tinkering with CP/M (2.2),
implement CP/NET Version 1.2,
since (16-bit) DR Net recognizes it.
(Another advantage of CP/NET is that
one of its implementation, based on
ARCnet is still widely used in factories...
and factories are much less subject
to fashion or marketing fads! As long
as it will keep running, they will keep
using it... Like us CP/M systems!)
(By the way, this proves that CP/NET
can be implemented using several
ways...)
Are you suggesting that CP/NET can natively talk TCP/IP
over ethernet? Is that being reinvented here? Just curious
what you are complaining about.


Thanks,
Shawn
n***@nouce.bellatlantic.net
2005-02-14 15:06:02 UTC
Permalink
On Mon, 14 Feb 2005 15:37:09 +1100, Shawn Sijnstra
Post by Shawn Sijnstra
Are you suggesting that CP/NET can natively talk TCP/IP
over ethernet? Is that being reinvented here? Just curious
what you are complaining about.
No!

CP/net had a few primitives added to the BDOS to do
intersystem communications. Doing IP, arnet or any other
protocal was in the BIOS space or seperately loaded.

Those were:

37 Reset Drive
39 Free Drive
64 Login
66 Send Message on Network
67 Receive Message on Network
70 Set Compatibility Attributes
106 Set Default Password

I might add 37 and 39 are not in CP/MV2.2 but space was made for
them. Those above 40 are added and a few of the CP/M(v2) generic
calls (below 40) have some ambigious facits defined.

It is the job of the SNIOS( Slave Network IO system) and MNIOS
(Master Network IO system) to implment the actual functions.
Both are extensions to the BIOS and may or may not utilize the
same physical devices.

I'd seen CP/m (may have been cp/net they look the same)
with arcnet and but I'd seen a bunch more systems running
CP/M on a shared parallel bus (S100) with a MPM host.
Ampro did a processor to processor things using the SCSI
that the LB+ had.


Allison
French Luser
2005-02-15 13:11:06 UTC
Permalink
CPNET.TXT
---------

Ok. Recently, there was a thread about CP/NET in the comp.os.cpm
Newsgroup. As usual, it soon started going in all directions,
since most persons (99%) simply have no idea what they are
talking about.

In the hope of refocusing the messages towards the target, I am
submitting the obvious: some relevant technical information.

----------

"CP/NET-80 Reference Manual" -- Fifth Edition: November 1982

Section 4.4 Implementing Non-MP/M II Servers
--------------------------------------------

It is possible to implement a CP/NET server on any computer
system, under any operating system. There are several reasons
why you might choose another operating system:

MP/M II servers limit the number of requesters to 16.
You might want more than 16 workstations to have access
to a common database.

You might require higher performance levels. The high
speed of a mainframe CPU can substantially increase
CP/NET performance.

You might want your system to take advantage of the
large base of CP/M applications programs, but maintain
its files under another operating system.

Or you might want to create a gateway to one of the
other commercially available network systems. A special
server could translate CP/NET messages into an
appropriate format for the other network.

The module SERVER.RSP cannot be used on a different processor or
under a different operating system. So, you must not only create
the equivalent of the NETWRKIF for the target computer system;
you must also write the logical portion of the server.

The server processes under MP/M II act essentially as a proxy
for the requester assigned to them. For example, the requester
wants to open a file on a networked drive but it does not have
access to the operating system controlling that drive. Instead,
the requester sends a message to a server process that does have
direct access to the controlling operating system, and asks that
process to open the file for the requester. The server
obligingly performs the operation for the requester, and tells
it what happened. This is often referred to as a ghosted process
model of a server, because the operating system thinks it is
running the entire application program as a process, while in
fact the application is running somewhere else, but has a friend
to help out.

Using the logical messages included in this manual, you can
write a ghosted process server for CP/NET under almost any
multitasking operating system. You can even write a CP/NET
server under a single-tasking operating system. (CP/NET servers
have actually been implemented under CP/M.)

The basic elements of such a server are:

- A communications interface.

- A function interpreter. This module must interpret the
logical messages sent by the CP/NET requester and take
the appropriate action.

- A file system translator. This module must convert CP/M
BDOS File Control Blocks passed by the requester into
native operating system File Control Blocks.

- An operating system interface. This module must
translate a CP/NET function that corresponds exactly to
a function supported by MP/M II into a function or set
of functions supported by the native operating system.

Each of these functional modules varies depending on the
environment under which it is forced to execute. The
communications interface is governed by the types of process
architectures the target operating system can support. The
remaining modules can be a set of reentrant processes, as they
are under MP/M II, or they can be a single process that keeps
track of the requester it is currently servicing. If the latter
method is used, the server must keep track of such context
sensitive information as directory search first/search next
information, and shared files.

It might not be possible to support all CP/M functions under a
non-MP/M II server. If this is the case, choose applications
that do not require the use of the unsupportable functions.

Finally, it might be necessary to have several different
computer systems and operating systems acting as servers in the
same network. It is best to make the server implementation as
portable as possible. Implementing the server in a high-level
language is a first step to portabilty.

Making the system highly modular can improve its portability.
For example, break the communications interface into a hardware
interface module, a data link module, a network module, and a
transport module. All of these modules, with the exception of
the hardware interface, can port to different systems with
minimal modification.

The server's function interpreter should be completely portable,
but you will probably have to rewrite the file system
interpreter and the operating system interface modules.

-----------

In short, the Americans have an accronym: RTFM!!!

As usual, I will remind those "blablabla" people that, several
months (years?) ago, I wrote about CP/NET. Use Google -- Groups
-- Advanced Search for the details.

At the time, CP/NET-80 was running on S-100 Bus "mainframes",
using some S-100 Bus cards made at the time. I tried to find one
of those cards, but without success (of course, living so far
away from the USA did not help).

As far as I know, besides my messages in the comp.os.cpm
Newsgroup, the only source of information about CP/NET-80 on the
Internet is Roger Ivie's Web site where he provides an HTML
version of the "CP/NET-80 Reference Manual". (I have it in WS4
format. As explained in the comp.os.cpm Newsgroup, I have
recreated the source code of the files provided in the
Appendices. If someone ever find one of the S-100 Bus cards, ask
me and I will provide you with the source code (nobody ever
asked me to provide those files on an Internet site).)

As usual, I believe (contrary to Newbies) in reading the
documentation. Besides the "CP/NET-80 Reference Manual", I
managed to find one article dealing with CP/NET-80 published by
the ACM. The name probably does not mean anything to Newbies.
Yet, in the hope that someone will find it interesting, one day,
I have decided to publish it. Maybe, one day, someone will
understand the technical value of CP/NET-80?

Yours Sincerely,
"French Luser"


EOF
n***@nouce.bellatlantic.net
2005-02-15 15:02:12 UTC
Permalink
On Tue, 15 Feb 2005 14:11:06 +0100, "French Luser"
Post by French Luser
manual excert snipped
In short, the Americans have an accronym: RTFM!!!
Yep and you didn't understand much of that.
Post by French Luser
As usual, I will remind those "blablabla" people that, several
months (years?) ago, I wrote about CP/NET. Use Google -- Groups
-- Advanced Search for the details.
You find me there too, likely years before you.
Post by French Luser
At the time, CP/NET-80 was running on S-100 Bus "mainframes",
using some S-100 Bus cards made at the time. I tried to find one
of those cards, but without success (of course, living so far
away from the USA did not help).
In that manual when it was written mainframes meant a VAX/VMS, UNIX
on a PDP -11 or interdata or other really big machine. S100 was not
a "mainframe" as often it was the client.

Also the authors of the manual had little knowledge of the inner
working of other OSs so some of the comments were made in a vacuum
about other OSs not having the required functions.

Those network cards were scarce here too. Bus cards for S100 at the
time were minimmally a 400-1000$ item and often sold with propriatory
software( no sources).

None of that stopped people as you could use common serial cards
in a star configuration (Zilog SIO was nice as it could support very
fast HDLC links). the number of machine that had the SIO or could
use a card contining one made it less a problem. There were also
cards with the NEC7201 (aka intel 8274) and COM5025/2601,
8251/2651 in sync mode to name a few. I have some of them
both raw and on S100 cards. The cards in themselves are
nothing remarkable.
Post by French Luser
As far as I know, besides my messages in the comp.os.cpm
Newsgroup, the only source of information about CP/NET-80 on the
Internet is Roger Ivie's Web site where he provides an HTML
version of the "CP/NET-80 Reference Manual". (I have it in WS4
format. As explained in the comp.os.cpm Newsgroup, I have
recreated the source code of the files provided in the
Appendices. If someone ever find one of the S-100 Bus cards, ask
me and I will provide you with the source code (nobody ever
asked me to provide those files on an Internet site).)
I've hard a hard copy of it since it released back inthe 80s.
I also have the OS on disk.
Post by French Luser
As usual, I believe (contrary to Newbies) in reading the
documentation. Besides the "CP/NET-80 Reference Manual", I
managed to find one article dealing with CP/NET-80 published by
the ACM. The name probably does not mean anything to Newbies.
Yet, in the hope that someone will find it interesting, one day,
I have decided to publish it. Maybe, one day, someone will
understand the technical value of CP/NET-80?
Have you actually implemented anything in the CP/M realm?
I have. Further I have my former employers full systems
That's 5 S100 crates that ran CCP/M on a compupro 816,
and CP/M2.2, they didn't use a special NIC or any kind.
I did sell off the another five as they were clones of the five I kept
and not unique enough to warrent storage (s100 crates are bulky).
That system used fast serial lines in a star topology with
the box containing the 816 being the "server". before they went to
CCP//M it ran MPM and also CDOS. I had to understand that
collection as it was replaced with PCs running win3.11/lanman.
The functional replacement was easy. I figure I've gotten 25% of the
way through understanding it enough to reconstruct, it as it took them
5 years to get it fully operational, nothing was out of box. I still
have over 200 8" disks to analyse and extract relevent peices.

One of the interesting artifact is since not one box (they had 11)
had an identical BIOS even though 9 of them ran CP/M2 or CP/M+
and all had S100 box, CPU and IO made by Compupro.


Allison
n***@nouce.bellatlantic.net
2005-02-11 15:57:22 UTC
Permalink
Post by d***@cs.csbuak.edu
The guy I'm working with on this P112 project is talking about designing
an ethernet card for the P112. It'll probably be just 10baseT. I guess
it'll work with UZ180, but what about CP/M?
This is long and rambles some but from someone thats played a bit.

I went this path and to me telnet via eithenet on a CP/M system is
MDM740 Via a very fast modem and not much more.
Think of what that really is. It's a single task that does simple
communications via a connection. Useful but limited. When I took
on the idea of networking I wanted far more than that as I'd seen
examples that were very close to the typical networking of today
only it was 1981.

First a few things.

Your system will need interrupts, a fully vectored system preferably.
Heartbeat [periodic] interrupt at a minium.

It better be fast or it will not serve much use.

DMA is very desireable, maybe even required.

Eithernet (802) using 10mb/S hardware meand you have a burst byte rate
of 1.25 mbytes/S. The average Z80 systems will choke at that rate
even if it has DMA.

Multitasking is Very desireable. At a minimum forground background
system. You need to be able to do a few specific things while
generally doing the usual stuff.

Now for some background.. How I know this.

Back in early '81 I had more than one CPM system and they had
differing disks and only one had a really nice 5MB hard disk. I
wanted to transfer files like I could using PDP-11s and VAX on a
network (serial or other fast net). Back then DEC interconnected
systems using parallel interconnects, serial networks (sync protocal
and DDCMP) and some had Eithernet (10b5). This gave me a model.

Early testing found the 4mhz z80 could sustain a 38.4kbaud serial
connection for binary transfers using a protocal similar to xmodem.
The reason for a protocal was simple, you needed to package binary
data, transfer it and check it was recieved correctly then acknowledge
it. Easy enough and there were two programs (UP and DOWN) that were
very small and around for use. I also found that if there was any
excess time added to the loops it would slow below what the SIO
devices needed to sustain the data for a syncronous transfer. Worked
well if it were Async though. The other problem is while this was
going on you sat there and watched it as there was little cpu left to
do anything. But it did move binary (or any ) data. It got me aroud
tha fact that of 4 CP/M systems none had a common disk format! It
also was a learning experience.

Now I wanted to do a few things that are taken for granted now with PC
networks. I wanted to share a disk(s), I wanted to share a printer, I
wished to run all my systems from a single tube if possible. All
under CPM2.2 I may add. Why? I only had one hard disk, One CRT
and one decent printer and an assortment of systems with Hard disk,
Hard sector Floppies, 8" floppies and there was one system with no
storage as of yet. All of those things then (1981) were expensive!
With all that in mind and a one article on networking computers I'd
read I figured I could do some of that. There were a lot of steps and
misteps and a few system hardware things that eventually happend.
In early '82 I could get z80s sorted for 6 and a few 8mhz parts,
5mhz 8085s and 12mhz 8749s so I had a few fast [then] cpus laying
around. Step two was a physical network, I used asynchronous serial
as all my systems had it and only one could do Synchronous. So that
lead a slow CDCS/MA bus (coax based as I had it and it was cheap) that
ran at 19.2Kb. It was supportable by every CPM machine I had (by then
that was 4+). The bios was modded that if a device (disk,
terminal,printer) was needed remote it was sent to a handler that
added information. There were many evolutionary steps. the most
important being the idea of a source address (source system),
destination address (target system) and that all transfers would get
an acknowlege or some response if there was an error.

While I was not in a vacuum back then I'd not encoutered unix or IP
style networking back then. Initial work was sharing the printer,
fairly easily done by making one (non disk rom based with large ram)
sytem a crude printer server. Any system would send a source address,
a destination address and the data and the printer server would listen
for it's address and buffer bytes for it and print them. When it got
a "done" message it would finish printing and eject a sheet spacer.
Next was terminal sharing and similarly done. When I started on the
disk sharing I realized several things, speed and I needed a richer
protocal to handle the need to transfer data, control and status
messages. I also bumped into CP/M limitations as a serial
monoprocess. So at that point I did a lot of backsteps, a ton of
programming and a fair amount of hardware building. I arrived at a
real vectored interrupt system for the two S100 crates, a heartbeat
interrupt, multiple processors and some rudimentary task sceduling for
CP/M to support multiple processors. I may add a healthy wish for far
more ram! The latter meant adding a memory manager, and 256k of ram.
Task scheduling was simple to add to CP/M, it was a process that was
initialed after cold boot that was set up in high memory and was
triggered by a non maskable interrupt. It did only a few things,
every interrupt or (return VIA RST7) it tracked the reason for it's
activation (next task or continue from hearbeat) and depeinding on the
cause it would either continue the current process (basically a RET)
or start the next process in the tasklist. This allowed things like a
program to send data to a printer spool buffer and then a seperate
process could empty the buffer and print or send it elsewhere.

One of the more mind twisting parts of this of the project was
messages and keeping track of whos who and whats what. That required
a protocal that was not tied to the hardware. The well known (even
then) ISO stack was the model. It divided the layers and tasks to be
one in a symetric fashon to the reciever and the sender could stay on
the same page. To do this I had a protocal. Specifically the header
contained [origin system number, destination system, device type,
transfer length, data or control and Check bytes) and it expected a
return packet with addresses of sender, destination and an ACK or NAK.
The device type field was most important ans it identified the task or
type of operations needed. Everything else supported the idea of Who
and Where are the players (sources and destination) , What are we
going to do, and how much. My model for this was a conversation at a
cocktail party. The basic idea is that when two people talk they
identify, establish a subject and acknowlege the converstation either
with words or other gestures.

I'm getting very long on this and theres more. In the end I had,more
than 5 systems all connected at 19.2k (later faster to 56k) that could
use each others disk, terminal IO and printer and generally pas data
as needed from an application on one to an application on another.
There were limitations and caveats as some of the lesser systems were
ram or interrupt poor tending to make them single serial task
orieneted. The better and more expanable S100 crates however had
perpiheral CPUs (z80s, 8085s and 8749s) to offload tasks like
serializing data, running the disk subsystems and even in one crate a
multiprocessor (3 Z80s with 64k ram each and mmu to public ram).

Conclusions reached were manifold. The Z80 and 8085 are good fast
versitile cpu. The z80 at 8mhz was still not fast enough. Memory
addressing of 64k was also limiting. CP/M2.2 is growable to do all
the things MPM did. For text based tasks enough disk, ram and
good IO held off the PC until the 90s! Eithernet was always too
costly and had system speed requirements that only a much faster z80
could support than was available at the time.

There were also a number of side tracks I took alone the way for
thinks like Ramdisk, Eprom disk, and multiprocessor task sharing.
Such is the case when exploring and trying to encompass new
ideas that would expand the system in modern terms [speed it
everything!] and still stay withing the rich appication framework that
CP/M provided.


NOTE: I might add that in October 1983 William Wong in Microsystems
had also gone down the same path and arrived at many of the same ideas
With CP/net. It's a worthy read.

Much of the hardware and software has been retained though not used.
much of it is system specific and would not port to other CP/m
hardware as much is it was one off. I don't run a full suite of cpm
S100 crates anymore (too many noisy fans!). But many things did stay,
one was a serial packet port as part of the bios (I use IO byte) to
transfer from one system to another. This idea is that you can set
the modem port to essentually run a minixmodem to another sytem rahter
than output plain ascii and all Buffereing, the packet work and hand
shakes are taken care of in the driver. The idea of a standard DCE
DTE pair that only required four (4) wires (protective ground, signal
ground, TX and RX) with serial software handshake. Ram/Romdisk for
fast storage, The idea of sharing devices (concept) even if another
system owns it. The idea that a task can be split over many eneral or
specific hardware/software sections that can be designed and run
independantly but have a shared interface. The concept of a multitask
or multi process executive regardless of how simple or complex a
system.


If your going to use eithenet now, I'd speculate this. You need an
adaptor that FULLY buffers packets, does not require fast IO to work
though fast IO is desired and some level of multitasking (or at least
a backgound forground arrangement) to support user IO while
net IO is going on. Also look at a the love level stuff the device
needs for setuo and housekeeping.


Allison
Hal
2005-02-11 22:59:13 UTC
Permalink
On Fri, 11 Feb 2005 15:57:22 GMT
Post by n***@nouce.bellatlantic.net
Post by d***@cs.csbuak.edu
The guy I'm working with on this P112 project is talking about
designing an ethernet card for the P112. It'll probably be just
10baseT. I guess it'll work with UZ180, but what about CP/M?
This is long and rambles some but from someone thats played a bit.
Good rundown, Allison. Yours was much more polished and complete than a
brief demo I did for a class in 1985 where I used an RSX and polling of
the serial port status to receive packets. I polished the design up in
the mid-90s for Trenton Computer Fest in '95 (IIRC) and demonstrated two
systems running banked ZSDOS with RSX's for the LAN. Collision
Detection was implemented by matching sent chars against received chars
(simple blocking diode and biased twisted pair) and variable backoff
when collisions were detected. User interface had a simple repetoire of
'status', 'get', 'put' and 'clear' or some such, and provided the bridge
between the foreground user and the RSX effectively running in
background. While polling was used on older Z80 systems such as an S100
system and Ampro Little Board, Interrupts were used with HD64180s and
Z180s (including a P112 with Z182).


The complete code package for this is 'CHEAPLAN.LBR' at
http://home.att.net/~halbower


Hal
n***@nouce.bellatlantic.net
2005-02-11 23:41:36 UTC
Permalink
Post by Hal
the mid-90s for Trenton Computer Fest in '95 (IIRC) and demonstrated two
systems running banked ZSDOS with RSX's for the LAN. Collision
Never got to see that. We'd have enjoyed talking. By '85 I'd been
working at DEC for a while and was used to DECnet networking and it's
utility even at that time. By 1987 I'd finished with the first
networking project at DEC, networked printer using DECnet and also IP
networking where the printer was an atunomus node.
Post by Hal
Detection was implemented by matching sent chars against received chars
(simple blocking diode and biased twisted pair) and variable backoff
when collisions were detected.
Essentually what I did only I used coax as I had RG-59 and Type F
connectors comming out of my ears.
Post by Hal
User interface had a simple repetoire of
'status', 'get', 'put' and 'clear' or some such, and provided the bridge
between the foreground user and the RSX effectively running in
background. While polling was used on older Z80 systems such as an S100
system and Ampro Little Board, Interrupts were used with HD64180s and
Z180s (including a P112 with Z182).
Polling works ok for a single tasking system. With real vectored
interupts and a background buffered IO the untility and general
performance improves. When I was doing most of that the systems
were a much souped up NS* Horizon, a HB S100 Z80/8mhz a AmproLB+
several DEC VT180s CPM processor cards (aka robin), and a few
8085 based boards orignially designed for VT100 printer buffers.

I fould CP/M to be a go OS platform that had few limits but most
packaged hardware of the generic cpm crate did little to fully exploit
the Z80 nor interrupts for performance.
Post by Hal
The complete code package for this is 'CHEAPLAN.LBR' at
http://home.att.net/~halbower
I have it and have tried to look at it many times over the years.
I've never been successful. I've cracked the LBR down but the doc
file was unreadable, looks like spanish! I suspect it was written for
some text editor I don't use under cp/m or on the wintel boxen.


Allison
Hal
2005-02-12 11:50:07 UTC
Permalink
On Fri, 11 Feb 2005 23:41:36 GMT
Post by n***@nouce.bellatlantic.net
Post by Hal
The complete code package for this is 'CHEAPLAN.LBR' at
http://home.att.net/~halbower
I have it and have tried to look at it many times over the years.
I've never been successful.
Oooops! The CHEAPLAN.TXT file is really a WordStar Document file, so
the MSB of ending letters in words is set. You should be able to read
it from within WordStar Ok, though Xemacs and all my Linux tools do show
interesting character combinations. Well, another item to be fixed in
the TDD list ;-o

BTW, 'lbrate' is a good tool to extract libraries under Linux, and I
used it to extract a freshly-downloaded copy of the library just to make
sure my local copy didn't interfere with checking.

Hal
Fritz G. Chwolka
2005-02-12 13:10:38 UTC
Permalink
Post by Hal
On Fri, 11 Feb 2005 23:41:36 GMT
interesting character combinations. Well, another item to be fixed in
the TDD list ;-o
BTW, 'lbrate' is a good tool to extract libraries under Linux, and I
used it to extract a freshly-downloaded copy of the library just to make
sure my local copy didn't interfere with checking.
Hal
Hi Hal ...
Isn't your Reel2Reel driven by an Z80 -)

Ok.. that's a joke but for Linux and LBR you can try CFX from:

http://oldcomputers.dyndns.org/public/pub/program/pc-side/compress/cfx
/info.html

As I mostly work with OS/2 and the MSDOS of OS/2 is very usefull I
do only use CFX for DOS
or make that all on my Z280 remotely (Thanks OS/2 and a an PCCOM 8Port
RS232 in the basemant.)
--
Greetings

Fritz Chwolka
Post by Hal
collecting old computers just for fun<
< at www.alterechner.de >
n***@nouce.bellatlantic.net
2005-02-12 17:02:43 UTC
Permalink
Post by Hal
Oooops! The CHEAPLAN.TXT file is really a WordStar Document file, so
the MSB of ending letters in words is set. You should be able to read
it from within WordStar Ok, though Xemacs and all my Linux tools do show
interesting character combinations. Well, another item to be fixed in
the TDD list ;-o
Ah. I have WS kit but never used it. I prefer VEDIT and Word-80. If
it's only a bit7 problem thats easy to fix. I have a utility for
dealing with that on the CP/M machines, I'll copy it to the wintel box
(similar to a dosboxen) and run it under MyZ80 and fix it when I get a
chance. If I do I"ll send you the plaintext.

Allison
Roger Ivie
2005-02-12 20:47:30 UTC
Permalink
Post by n***@nouce.bellatlantic.net
If
it's only a bit7 problem thats easy to fix. I have a utility for
dealing with that on the CP/M machines,
PIP [Z] ?
--
Roger Ivie
***@ridgenet.net
http://anachronda.webhop.org/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/P d- s:+++ a+ C++ UB--(++++) !P L- !E W++ N++ o-- K w O- M+ V+++ PS+
PE++ Y+ PGP t+ 5+ X-- R tv++ b++ DI+++ D+ G e++ h--- r+++ z+++
------END GEEK CODE BLOCK------
Hal
2005-02-12 21:23:25 UTC
Permalink
On Sat, 12 Feb 2005 17:02:43 GMT
Post by n***@nouce.bellatlantic.net
Ah. I have WS kit but never used it. I prefer VEDIT and Word-80. If
it's only a bit7 problem thats easy to fix. I have a utility for
dealing with that on the CP/M machines, I'll copy it to the wintel box
(similar to a dosboxen) and run it under MyZ80 and fix it when I get a
chance. If I do I"ll send you the plaintext.
No need to forward, Allison. I have enough copies backed up various
places. Just need to fix (easy with the "real" WS4), but then rebuild
the library, copy to DOS 360 kB 5.25" floppy with DosDisk, Read into a
Linux box via /dev/fd1h360 (No Dos or Windows Boxes in the house, but
Linux machines with dual-media floppy drives), then upload to the page.
I couldn't think of a harder way to do it, so I'm stuck with this ;-)

Hal
Randy McLaughlin
2005-02-12 21:33:09 UTC
Permalink
Post by Hal
On Sat, 12 Feb 2005 17:02:43 GMT
Post by n***@nouce.bellatlantic.net
Ah. I have WS kit but never used it. I prefer VEDIT and Word-80. If
it's only a bit7 problem thats easy to fix. I have a utility for
dealing with that on the CP/M machines, I'll copy it to the wintel box
(similar to a dosboxen) and run it under MyZ80 and fix it when I get a
chance. If I do I"ll send you the plaintext.
No need to forward, Allison. I have enough copies backed up various
places. Just need to fix (easy with the "real" WS4), but then rebuild
the library, copy to DOS 360 kB 5.25" floppy with DosDisk, Read into a
Linux box via /dev/fd1h360 (No Dos or Windows Boxes in the house, but
Linux machines with dual-media floppy drives), then upload to the page.
I couldn't think of a harder way to do it, so I'm stuck with this ;-)
Hal
Many CP/M readme (and other text) files are written with WordStar, with CP/M
all you need is pip to fix it well enough to read. With Windoze you have
more trouble, bigger is better right?


Randy
www.s100-manuals.com
n***@nouce.bellatlantic.net
2005-02-12 23:34:40 UTC
Permalink
On Sat, 12 Feb 2005 15:33:09 -0600, "Randy McLaughlin"
Post by Randy McLaughlin
Many CP/M readme (and other text) files are written with WordStar, with CP/M
all you need is pip to fix it well enough to read. With Windoze you have
more trouble, bigger is better right?
Winders long since forgot about the simple stuff. ;)

Pip under Myz80, better. I have a utility that does more than that
and can add line breaks at word spaces less than specified line
length and a few other handy tricks needed to deal with info gleaned
of usenet in the 80s.

Allison
primo
2005-02-13 21:03:47 UTC
Permalink
On Sat, 12 Feb 2005 15:33:09 -0600, "Randy McLaughlin"
Post by Randy McLaughlin
Many CP/M readme (and other text) files are written with WordStar, with CP/M
all you need is pip to fix it well enough to read. With Windoze you have
more trouble, bigger is better right?
Randy
www.s100-manuals.com
I recall that Berg's list.com would read wordstar doc files on a dos
box. I still use it here to read files with odd control chars in them.
Its been a while since I fired up WS4 and created any doc files. I
don't think I have typed anything over a page long in years. With WS4
I managed to edit complete books.
n***@nouce.bellatlantic.net
2005-02-12 22:21:56 UTC
Permalink
Post by Hal
No need to forward, Allison. I have enough copies backed up various
places.
Ok!
Post by Hal
Just need to fix (easy with the "real" WS4), but then rebuild
the library, copy to DOS 360 kB 5.25" floppy with DosDisk, Read into a
Linux box via /dev/fd1h360 (No Dos or Windows Boxes in the house, but
Linux machines with dual-media floppy drives), then upload to the page.
I couldn't think of a harder way to do it, so I'm stuck with this ;-)
I keep a few around for compatability with those that wintel is the
only world. That and I have some mightly small 486/50s that run
win95 well enough, networking and MYz80 just fine. ;)

Allison
French Luser
2005-02-15 13:20:10 UTC
Permalink
Post by n***@nouce.bellatlantic.net
NOTE: I might add that in October 1983 William Wong in Microsystems
had also gone down the same path and arrived at many of the same ideas
With CP/net. It's a worthy read.
Allison, I only have a few past-mid-1984 copies of Microsystems
(I was a DDJ fan). Could you send me this CP/NET article, so I
can retype it?

(Reading all the messages, I think that you are the only one
understanding all the details, since you already did one NOS.
I encourage you strongly to do a CP/NET-80 port for your
favorite CP/M system before nobody else will be able to do it.
I hope that you will either publish regularly the details on the
comp.os.cpm Newsgroup, or set up a Web site. I hope that
this will "start the ball rolling", as you say in English.)

Yours Sincerely,
"French Luser"
n***@nouce.bellatlantic.net
2005-02-15 15:14:39 UTC
Permalink
On Tue, 15 Feb 2005 14:20:10 +0100, "French Luser"
Post by French Luser
Allison, I only have a few past-mid-1984 copies of Microsystems
(I was a DDJ fan). Could you send me this CP/NET article, so I
can retype it?
No, no scanning capability at this time. I'm not a wintel PC
hardware collector so I often use a 486 winNT/4 box to do
usenet. It's not fast but it's solid.
Post by French Luser
(Reading all the messages, I think that you are the only one
understanding all the details, since you already did one NOS.
I encourage you strongly to do a CP/NET-80 port for your
favorite CP/M system before nobody else will be able to do it.
I hope that you will either publish regularly the details on the
comp.os.cpm Newsgroup, or set up a Web site. I hope that
this will "start the ball rolling", as you say in English.)
I have no plans for a CP/M-80 port. it adds little to my experience
to date and as CP/M-80 (aka cp/net) has all the limitations of CP/M2x
it's a step backward. I prefer to use the CP/M2.x BDOS replacements
as that doesn't limit me on disk space addressing and there are many
things cleaned up in them. While I'll comment and suggest things and
maybe code bits I tend to have very unique hardware [I build hardware
too!] so software is not portable relative to hardware. For example
I use DMA and interrupts to delegate low level stuff to a 8085 or
8749 dedicated for that functional task [ a 56kb/S link serial IO
buffering in one case]. I also have uncommon hardware like the
Compupro MPX-1 that can implement many things as a IO
subprocessor.


Allison
French Luser
2005-02-16 13:36:41 UTC
Permalink
Post by n***@nouce.bellatlantic.net
Post by French Luser
Allison, I only have a few past-mid-1984 copies of Microsystems
(I was a DDJ fan). Could you send me this CP/NET article, so I
can retype it?
No, no scanning capability at this time. I'm not a wintel PC
hardware collector so I often use a 486 winNT/4 box to do
usenet. It's not fast but it's solid.
You can also send me this CP/NET article as a photocopy...
(That Americans named "Xeroxes" at the beginning,
after the name of the company would introduced it.)

Of course, you should know my postal address?

(Unfortunately, if you are American, the US Customs
will prevent me from sending you some local food
in exchange... They would probably think that I want
to poison you with French food! Hahaha! Very funny,
since it is the Americans who invented "Junk Food"...)

Yours Sincerely,
"French Luser"
n***@nouce.bellatlantic.net
2005-02-16 15:08:29 UTC
Permalink
On Wed, 16 Feb 2005 14:36:41 +0100, "French Luser"
Post by French Luser
You can also send me this CP/NET article as a photocopy...
(That Americans named "Xeroxes" at the beginning,
after the name of the company would introduced it.)
And my personal incentive to do this is? Sorry, making a
copy and sending it is a project that extends a long list.
I'd ask that anyone else with scanning capability do this
for every one.

The issue is: Microsystems Vol4/Number 10, October 1983
There are three articles by W. Wong:

An introduction to local area networks: part 1
A low cost local network for microcomputers
CP/Net: The cpm network operating sytem

I don't work outside my personal office. I don't own a Xerox
as the need is infrequent and I go to a copy center.
Post by French Luser
(Unfortunately, if you are American, the US Customs
will prevent me from sending you some local food
in exchange... They would probably think that I want
to poison you with French food! Hahaha! Very funny,
since it is the Americans who invented "Junk Food"...)
As an American I would remind you all stereotypes of people are
unflattering. As an American of French and Irish decent I'm
insulted.

It would be very hard to send a good traditional cassoulet
and a nice red! I hate fast food, it's often not fast and only
sometimes passes for food.

Allison
French Luser
2005-02-15 13:13:48 UTC
Permalink
CPNETART.WS4 (CP/NET ARTicle)
------------

"An Analysis of CP/NET"
George H. Clapp
ACM "SIGPC Notes", Vol.6, No.2, 1983, p.117
(1983 ACM Conference on Personal and Small Computers)

(Retyped by Emmanuel ROCHE.)


Abstract
--------

CP/NET, a software package designed to add networking
capabilities to microcomputers running under the CP/M-80
Operating System, is examined with respect to internal logical
organization, separation of functions, and correspondence with
the ISO OSI reference model.


Introduction
------------

CP/NET, or "Control Program for a NETwork", is a software
package which adds networking capabilities to a computer running
under the CP/M-80 Operating System. CP/M-80, or "Control Program
for Microcomputers", is an operating system for 8080-, 8085-,
and Z-80-based microcomputers produced by Digital Research,
Inc., of Pacific Grove, California. CP/NET is designed to
enhance the currently dominant version, CP/M-80 2.2. Another
Digital Research product, MP/M II, or "MultiProgramming for
Microcomputers", provides multiprogramming capabilities on a Z-
80- or 8086-based microcomputer. CP/NET is designed to connect
computers running under these two operating systems, creating a
network in which CP/M-80 machines are single user workstations
which make requests to be serviced by an MP/M II machine. In the
parlance of Digital Research, the CP/M-80 machines are
"requesters", and the MP/M II machines are "servers". Only
requesters can initiate actions; a server merely responds. The
CP/NET package includes software written for both the CP/M-80
and the MP/M II machines. Our analysis shall focus on the CP/M-
80 software for two reasons: as the initiator, the CP/M-80
software defines the network; and, second, the goal of the
author is to support CP/NET with a Unix server, in which case
the software at the MP/M II server is irrelevant.

CP/NET [Ref: DIGI82] is capable of supporting a variety of
network architectures. This capability results from a design
philosophy in which the logical machine is separated from the
physical machine. CP/M-80 exemplifies this design approach; it
consists of three components: the BDOS, or "Basic Disk Operating
System", the CCP, or "Console Command Processor", and the BIOS,
or "Basic Input/Output System". The BDOS deals with a logical
machine, and remains unchanged across a spectrum of
microcomputers. The CCP intercepts and interprets operator
input, and passes requests to a logical machine; it remains
unchanged as well. The BIOS alone deals with the physical
machine, and must therefore be "fitted" to each particular
microcomputer architecture.

The following figure depicts the relationships between the
operator, application program, the CCP, BDOS, and BIOS:

+-------------+
| Application |--->-------+
| program | |
| CCP |--->-------+
+-------------+ |
| BDOS |--->---+<--+
+-------------+ |
| BIOS |---+<--+
+-------------+ |
| Physical |<--+
| machine |
+-------------+

Figure 1. Logical diagram of a CP/M machine.

The diagram represents layers of logical machines: as one
traverses outwards, the machines become more logical, or
"abstract"; as one traverses inwards, the machines become more
physical until, at the center, one encounters the actual
hardware. A boundary between two layers depicts the interface
which the inner layer presents to the outer, and the arrows
represent requests for service which one layer may make upon
another. Notice that an arrow goes only from an outer to an
inner layer, indicating that a less "abstract" machine does not
(or should not) request a service from one more abstract.

The BIOS requests services from the physical machine, and the
BDOS, in turn, requests services from the logical machine
presented at the BDOS/BIOS interface. The emphasized boundary
about the BDOS layer represents the CP/M-80 machine. This
strictly defined interface is the logical machine used by all
CP/M-80 compatible application programs. The CCP and application
programs are peers which use the CP/M-80 machine to provide
services to the operator. Notice that an application program may
circumvent the BDOS, and call directly upon the BIOS. This is
done relatively infrequently, however.

The CP/M-80 software modules BIOS, BDOS, and CCP reside in
memory as indicated below:

+-------+
high | BIOS | 4 KB
+-------+
| BDOS | 3.5 KB
+-------+<--+
| CCP | |
+-------+ |
| | 56.25 KB
| TPA | |
| | |
+-------+<--+
| Base | 0.25 KB
low | Page |
+-------+

Figure 2. Memory layout of a CP/M machine.

The BIOS resides in highest memory. The BDOS is placed
immediately below the BIOS, and the CCP immediately below the
BDOS. The first 256 bytes is called the "Base Page", and is
reserved for system use. Memory from the end of the Base Page to
the beginning of the BDOS is available to an application
program. Digital Research refers to this region of memory as the
"Transient Program Area", or TPA. Since the CCP and application
programs are peers, an application program may overwrite the
CCP, and make use of the memory in which the CCP resides. The
BDOS copies the CCP back into memory as part of the "warm boot"
process, which occurs upon termination of an application
program.

The typical BIOS requires 4 KB; BDOS consumes 3.5 KB. Taking the
Base Page into consideration, a 64 KB CP/M-80 microcomputer is
left with 56.25 KB available to application programs.

Digital Research has extended the philosophy of separating the
logical from the physical to the design of CP/NET. The logical
network is supported by a software module entitled NDOS, or
"Network Disk Operating System", and the physical network is
supported by a second module entitled SNIOS, or "Slave Network
I/O System". Due to this separation, CP/NET may be implemented
on several of the currently available physical network
architectures.

The logical machine diagram for a CP/M-80 machine in which
CP/NET resides in given below:

+---------------+---------------+
| Application : CCP |
+-+---| program : |---+
| | +---------------+---------------+ |
| +-->| NDOS |<--+
| +-------------------------------+
| +---| BDOS |---+
| | +-------------------------------+ |
+-+-->| BIOS : SNIOS |<--+
+---------------+---------------+
| Local : Remote |
+---------------+---------------+

Figure 3. Logical diagram of a CP/NET machine.

There are several noteworthy attributes of this "CP/NET"
machine. Most important, the physical hardware consists of two
entities: the local machine, and the network machine. The BIOS
requests service from the local machine only; the SNIOS deals
only with the network machine. Another attribute is that the
NDOS, rather than the BDOS, presents the CP/M-80 interface to
the CCP or to an application program. Digital Research has taken
pains to maintain compatibility with existing CP/M-80
application software. With only a few extensions (not
exceptions), the interface presented by NDOS mimics that of
BDOS. An CP/M-80 application program will typically run on a
CP/NET machine with no modifications.

As indicated by the diagram, a primary function of NDOS is to
route requests to the appropriate destination: a request for a
local resource to the local machine, a request for a remote
resource to the network machine. NDOS routes requests for local
resources to the BDOS. It transforms a request for a remote
resource into a logical message, and passes the message to
SNIOS, which in turn transmits the message to a network server.

NDOS routes requests immediately upon receipt for all resources,
except for two I/O devices. In Digital Research's terminology,
these are the console and the list (i.e., printer) devices.
Rather than route these requests upon receipt, NDOS passes these
requests directly to the BDOS, where they are translated to BIOS
calls. It is not until the BDOS calls upon the BIOS that the
NDOS intercepts and routes these requests according to the
location of the resource. Therefore, a SECOND logical entry
point exists in NDOS, which intercepts BIOS rather than BDOS
service requests. Presently, only the BIOS routines related to
the console and list devices, and to the warm boot process, are
intercepted in this manner.

A possible rationale for this approach is that it allows
application programs to make direct calls upon the BIOS, yet
retains the mapping from logical to local/remote resources. The
remaining non-disk I/O devices, reader and punch, are not
intercepted in this manner, because they cannot be networked.
However, direct BIOS calls for disk resources are not
intercepted in this manner. The reason may lie in a practical
necessity related to the Control-P function. Control-P is a
toggle which enables program output to be echoed to the list, as
well as the console, device. Yet, there are ample opportunities
for NDOS to determine the destination(s) of output prior to
entry to BIOS. The approach taken by Digital Research requires a
less "abstract" machine, the BIOS, to request a service from one
more "abstract", the NDOS. The result is a product more
conceptually complex, less theoretically "clean" than might be
desired.

The CP/NET software modules reside in memory as indicated in the
next diagram:

+-------+
high | BIOS | 4 KB
+-------+
| BDOS | 3.5 KB
+-------+
| SNIOS | 0.75 KB
+-------+
| NDOS | 3 KB
+-------+<--+
| CCP | |
+-------+ |
| | 52.5 KB
| TPA | |
| | |
+-------+<--+
| Base | 0.25 KB
low | Page |
+-------+

Figure 4. Memory layout of a CP/NET machine.

As before, the BIOS and BDOS together occupy 7.5 KB. The NDOS
requires 3 KB, and a sample SNIOS included in the CP/NET package
consumes 0.75 KB. After taking the Base Page into consideration,
an application program has 52.5 KB of memory available for use.

Given the logical organization and memory layout of the CP/NET
machine, it is instructive to follow the paths taken by a
request. These paths are depicted in the following diagrams.
There are three possibilities: 1) a request for a local
resource, 2) for a networked disk resource, and 3) for a
networked console or list (printer) resource.

+-------+
+---| BIOS |<--+
4 | +-------+ | 3
+-->| BDOS |---+
+---| |<--+
| +-------+ |
5 | | SNIOS | | 2
| +-------+ |
+-->| NDOS |---+
+---| |<--+
| +-------+ |
6 | | CCP | | 1
| +-------+ |
+-->| |---+
| TPA |
| |
+-------+
| Base |
low | Page |
+-------+

Figure 5. (1) Path taken by a request for local resource.


+-------+
| BIOS |
+-------+
| BDOS |
| |<--+
3 <-- 4 -->+-------+ |
+---| SNIOS | | 2
5 | +-------+ |
+-->| NDOS |---+
+---| |<--+
| +-------+ |
6 | | CCP | | 1
| +-------+ |
+-->| |---+
| TPA |
| |
+-------+
| Base |
low | Page |
+-------+

Figure 6. (2) Path taken by a request for a remote disk.


+-------+
| BIOS |
+-------+
| BDOS |--->---+
| |<--+ |
5 <-- 6 -->+-------+ | | 3
+---| SNIOS |<--|-2-|---+
7 | +-------+ | | | 4
+-->| NDOS |---+<--+ |
+---| |<--+--->---+
| +-------+ |
8 | | CCP | | 1
| +-------+ |
+-->| |---+
| TPA |
| |
+-------+
| Base |
low | Page |
+-------+

Figure 7. (3) Path taken by a request for a remote
console or list device.


With this understanding of CP/NET, it is possible to place
CP/NET in context. The International Standards Organization
(ISO) has proposed the "Reference Model of Open Systems
Interconnection", or the "ISO OSI reference model", in an effort
towards network standardization [Ref: TANE81, LARS83]. The ISO
reference model consists of seven layers as depicted below:

+--------------+ +--------------+
| Application |<-->| Application |
+------+-------+ +------+-------+
| Presentation |<-->| Presentation |
+------+-------+ +------+-------+
| Session |<-->| Session |
+------+-------+ +------+-------+
| Transport |<-->| Transport |
+------+-------+ +------+-------+
+--------|-------------------|---------+
| +------+-------+ +------+-------+ |
| | Network |<-->| Network | |
| +------+-------+ +------+-------+ |
| | Data-Link |<-->| Data-Link | |
| +------+-------+ +------+-------+ |
| | Physical |<-->| Physical | |
| +--------------+ +--------------+ |
+--------------------------------------+
Communication Subnet

Figure 8. The ISO OSI reference model.

Each layer is briefly described below:

Application layer
This layer is the entry point into the network, and presents the
interface experienced by the operator. It deals with the
problems of human engineering, network transparency, and optimal
solutions to user tasks. Sample services are query optimization
in distributed data bases, security checks, and address
validation.

Presentation layer
The presentation layer provides frequently requested utilities,
typically conversion utilities, such as text compression,
encryption, and file format conversion.

Session layer
A session is a communications connection between two application
processes, and an appropriate title for the session layer is
"communications connection manager". This layer is responsible
for establishing and maintaining the logical connection between
two users. In addition, the session layer may reorder, or group,
transmitted messages, as required by the application program.

Transport layer
While the session layer manages the connection between two
application PROCESSES, the transport layer is responsible for
establishing, maintaining, and terminating the connection
between the ultimate source and destination NODES. The transport
layer establishes the connection at the request of the session
layer, divides the message into smaller units, if necessary, and
transmits the message to the destination node(s). It ensures
that the message is received correctly, and that the destination
node is not swamped with messages.

The application, session, and transport layers of the source
node communicate "directly" with their peers at the destination
node. It is truly "end to end" communication. In contrast, the
lower layers, the network, data-link, and physical layers,
communicate only with their immediate neighbors, which may or
may not be the ultimate source or destination nodes. In more
complex networks, the neighbors often are not the end
communicators. Therefore, the lower three levels present a
logical network to the higher levels, and are collectively
referred to as the "communication subnet".

Network layer
This layer accepts messages from the transport layer, "packets",
and routes them over an existing virtual circuit. In short, the
functions of the network layer are packetization, routing, and
congestion control.

Data-link layer
The data-link layer provides the error-free circuit expected by
the network layer. Frequently a collaboration of hardware and
software, the data-link layer implements a data-link protocol
which ensures that a message transmitted over the "raw" circuit
is received correctly. Messages descending from the network
layer are "enveloped", or "framed", and sent to a remote node.
The destination node acknowledges the message, informing the
sender whether or not the message was received intact. If the
message was garbled, the sender retransmits, and again awaits
acknowledgment. The process is repeated until success occurs.

physical layer
This layer is the only "non-virtual" circuit in the ISO model,
and consists of the electrical and mechanical components which
provide the raw transmission medium used by the higher levels.

With the ISO reference model in mind, the functions performed by
NDOS and SNIOS may be explored more fully. The NDOS provides the
following functions:

1. It intercepts and routes disk, console, and printer
resource requests to the appropriate location.

2. It transforms requests for remote resources into
packets, and passes the packets to the SNIOS for
transmission.

3. It receives packets from the SNIOS, and transforms the
packet information into the form expected by CP/M-80.

4. It intercepts and executes certain BDOS system
information and control functions, circumventing the
BDOS entirely.

5. It provides extensions to the CP/M-80 2.2 functions.
These extensions serve two purposes: to reconcile the
discrepancies between the CP/M-80 and MP/M II operating
systems, which occur primarily in the file systems, and
to support network functions, such as "login" and "send
message".

Unlike NDOS, which is sold only in load module form, sample
SNIOS's are sold to the customer in the form of 8080 assembler
source code. The SNIOS functions are strictly defined, as are
those of CP/M-80's BIOS, and consist of the following:

1. Network system information and control functions, such
as network interface initialization and returning the
network status.

2. Transmit and receive a message on the network.

NDOS is static, and acts as an interface between CP/M-80 and the
logical network provided by the SNIOS. The simple SNIOS function
titles, "send/receive a message", hide a mass of network
functions which may range from routing to data-link protocols.
The flexibility gained by shoving the physical network onto the
SNIOS comes at the price of a less than clear delineation of the
ISO reference model layer functions between the NDOS and the
SNIOS, and of requiring the customer to have knowledgeable
programming support. The division of the ISO reference model
layer functions between the NDOS and SNIOS will be discussed
shortly. Digital Research has attempted to alleviate the latter
problem by providing sample SNIOS's written to support three
network architectures: 1) the Corvus OMNINET, 2) the ULCnet of
Orange Compuco, Inc., and 3) a simple, default architecture, in
which the requester is connected to one or more servers via a
serial I/O port.

In addition to NDOS and SNIOS, Digital Research sells several
other programs as part of the CP/NET package. These include a
CCP customized for the CP/NET environment, an electronic MAIL
program, LOGIN and LOGOFF utilities, and a program entitled
CPNETLDR, which loads NDOS and SNIOS below the BDOS. Two
important programs are NETWORK and LOCAL, which enable the
operator to declare system resources as either remote or local.

The correspondence of CP/NET with the ISO reference model can
now be examined.


Application layer
-----------------

The CP/NET programs CPNETLDR, CCP, MAIL, NETWORK, and LOCAL
belong in this layer. Until the operator executes CPNETLDR, the
network does not even exist, and although network initialization
is not specifically mentioned as a function of the application
layer, it is a necessary precursor to all the functions provided
by lower levels. The CCP serves as a network interface in which
the primary concern is network transparency. Its interaction
with the server is relatively minor, and its functions are
restricted to such housekeeping chores as ensuring that file
attributes are compatible across the network, and releasing
allocated server drives upon termination of a local application
program. MAIL, NETWORK, and LOCAL are application programs whose
purposes were described earlier.


Presentation layer
------------------

The session layer is the primary interface between the
application program and the network. The application layer sends
a suitably formatted message to the session layer, and the
presentation layer usually plays a minor supporting role. In
CP/NET, however, the application programs were written before
CP/NET existed. They have no conception of messages, or of
remote resources. An important function of NDOS, therefore, is
to convert a system call made by an application program into a
message suitable for transmission over the network, and to
convert a message from the network into a form acceptable to the
application program.


Session layer
-------------

The session layer manages communications between application
PROCESSES. A CP/NET requester identifies the destination of a
message by a server ID number, and by his own requester ID
number. The server ID specifies the destination NODE; the
requester ID specifies the destination PROCESS. The programs
LOGIN and LOGOFF fit neatly into the session layer. LOGIN
establishes the logical connection between requester and server
processes; LOGOFF dismantles the connection.

However, to clarify the architecture of CP/NET, it should be
noted that it is impossible for a requester to communicate with
more than one process at a server node. CP/M-80 is a SINGLE
tasking operating system. The designers of CP/NET did not
envisage a situation in which multiple processes at a requester
would interleave service requests to a single MP/M II server.
Therefore, CP/NET makes no distinction between a destination
node and a destination process.

The session layer has the additional responsibilities of
maintaining the communications connection, and of reordering or
grouping messages as required by the application program. NDOS
maintains the connection in a negative sense: if a message
cannot be sent or received, NDOS simply returns an error to the
application program, and allows it to make any attempt at
recovery it desires. With regard to message sequencing, NDOS
orders the messages in strict request/response pairs: each
request requires a response.

Digital Research offers to the application programmer the
capacity both to evade the ordering normally imposed upon
messages, and to circumvent the conversion performed by NDOS at
the presentation level. The system calls "Send Message on
Network" and "Receive Message on Network" cause NDOS to pass
messages between the application layer and the transport layer
virtually untouched. The action taken by NDOS at the session
layer is merely to indicate the success or failure of the
transmission. These system calls are the means by which future
application programs can exploit the extended facilities offered
by CP/NET.

In summary, the functions of the session layer are provided by
three elements of the CP/NET package: LOGIN and LOGOFF provide
session creation and termination; NDOS provides connection
maintenance.

Digital Research has left the next three ISO reference model
layers: the transport, network, and data-link layers, to the
SNIOS. In effect, the communication subnet has been extended to
include the transport layer, and left in the hands of the SNIOS.
The lowest layer, the physical layer, is a matter of electrical
hardware, and is beyond the scope of CP/NET.


Transport layer
---------------

Since CP/NET does not distinguish between destination nodes and
processes, the problem of managing nodal communication is
subsumed by NDOS in the session layer. Also, since NDOS acts in
the presentation layer to convert system calls to messages which
are suitable at the data-link layer, it is not necessary to
split a message into smaller units. The transport layer is
unnecessary in CP/NET, and no module performs its functions. The
SNIOS could be modified to provide these functions, in the event
that a network architecture required them.


Network layer
-------------

It is difficult, or at least improbable, to imagine a CP/NET
topology in which routing represents a significant problem.
CP/NET lends itself most readily to a star topology in which
each requester has a dedicated port on the central server.
Routing is then a trivial affair, and is no more difficult with
a bus or ring topology. Although surprising, a ring topology is
possible under CP/NET. The requester must respond to I/O
interrupts on the network port, and execute an interrupt routine
which will pass the message on to the next requester.

Packetization and congestion control, like routing, are
functions unlikely to occur, except in the most sophisticated
implementations of CP/NET. As is the case with all the
communication subnet layers, the SNIOS can be modified to
provide the desired function.


Data-link layer
---------------

Digital Research has proposed a simple byte count oriented data-
link protocol, in an effort towards cross-system compatibility
[Ref: MCNA77]. The logical messages are clearly defined; the
figure given below depicts the standard format:

+-----+-----+-----+-----+-----+-...-+
| FMT | DID | SID | FNC | SIZ | MSG |
+-----+-----+-----+-----+-----+-...-+

Figure 9. CP/NET logical message format.

Each field, except the MSG field, occupies a single byte, and is
defined as follows:

FMT: message ForMaT code
DID: message Destination ID
SID: message Source ID
FNC: message FuNCtion code
SIZ: data field length - 1
MSG: MeSsaGe data (SIZ + 1 bytes)

The data-link protocol devised by Digital Research is
demonstrated in the next figure.

Source Destination
------ -----------
ENQ -->
<-- ACK
SOH -+
FMT |
DID |
SID |-->
FNC |
SIZ |
HCS -+
<-- ACK
STX -+
DB0 |
... |
DBn |-->
ETX |
CKS |
EOT -+
<-- ACK

Figure 10. CP/NET data-link protocol.

Although not indicated in the diagram, timeouts and
retransmissions are part of the protocol as well. The checksum,
which is simply the negative of the sum, modulo 256, of the
logical message bytes, is not as rigorous as a cyclic redundancy
code, which can be implemented in a simple and short subroutine.
Also, the ENQ and ACK characters exchanged in the handshaking
sequence are transmitted naked over the physical link. Control
messages might be sent in the headers of messages, with no data
but with checksums, as is done with other byte count oriented
protocols. Despite these failings, however, the protocol is
workable and simple to implement.


Physical layer
--------------

As mentioned previously, CP/NET leaves the physical layer in
other hands.


Conclusion
----------

The following diagram shows the relationship between CP/NET and
the ISO reference model.

+------------------+ CCP,
| +--------------+ | CPNETLDR, MAIL,
| | Application | | LOCAL, NETWORK
| +------+-------+ |
+--------|---------+
| +------+-------+ |
| | Presentation | |
| +------+-------+ | NDOS
| | Session | |
| +------+-------+ |
+--------|---------+
| +------+-------+ |
| | Transport | |
| +------+-------+ |
| | Network | | SNIOS
| +------+-------+ |
| | Data-Link | |
| +------+-------+ |
+--------|---------+
+------+-------+
| Physical |
+--------------+

Figure 11. CP/NET and the ISO OSI reference model.

NDOS and SNIOS separate cleanly at the session-transport
interface. NDOS provides the functions at the presentation and
session layers; SNIOS provides the communication subnet, which
is expanded by CP/NET to include the transport layer.

CP/NET logical message formats cannot presently support an
addressing scheme which will distinguish between processes at a
destination node. It is true that CP/M-80 machines are presently
single tasking, but sixteen bit microprocessors will become the
predominant architecture in personal workstations, and
multiprogramming will be the norm, rather than the exception.
Digital Research itself sells a multiprogramming version of
CP/M-80 designed for the 8086, their "Concurrent CP/M". The
authors of CP/NET may come to regret this melding of the
destination process and node.

Another flaw in the design of CP/NET is the decision to have the
NDOS intercept calls at the BIOS, as well as the BDOS, level.
Perhaps they were forced to do so by practical necessity, but
the result is a more cluttered, less straightforward design.

CP/NET's strengths are its compatibility with existing
application programs, and the variety of architectures which it
can support. The wealth of CP/M-80 software, and the large and
increasing number of CP/M-80 machines, represent an important
market to innovative manufacturers of inexpensive networks. By
placing the communication subnet in the SNIOS, Digital Research
has offered these vendors an avenue into this market.


Bibliography
------------

[CORT82]
"Inside CP/M: A guide for users and programmers, with CP/M-86
and MP/M II"
David E. Cortesi
Holt, Rinehart and Winston, 1982

[DIGI78]
"CP/M 2.2 Manual"
Digital Research, Inc.

[DIGI82]
"CP/NET Reference Manual"
Digital Research, Inc.
5th Edition, November, 1982

[DITL83]
"Idealism Spawns Realism"
Steve Ditlea
"Collegiate Microcomputer", Vol.1, No.1, February, 1983, pp.57-65

[LARS83]
"Adding another layer to the ISO net architecture reduces costs"
Kenneth N. Larson & W. Roy Chestnut
"Data Communications", Vol.12, No.3, March, 1983, pp.215-222

[MCNA77]
"Technical Aspects of Data Communication"
John E. McNamara
Digital Press, 1977

[ROLA82]
"Network software borrows design from microcomputer operating system"
Thomas A. Rolander, Randall Baird, & John Wharton
"Data Communications", Vol.11, No.13, pp.123-133

[TANE81]
"Computer Networks"
Andrew S. Tanenbaum
Prentice-Hall, Inc., 1981


EOF
n***@nouce.bellatlantic.net
2005-02-16 15:22:56 UTC
Permalink
On Tue, 15 Feb 2005 14:13:48 +0100, "French Luser"
Post by French Luser
CPNETART.WS4 (CP/NET ARTicle)
------------
"An Analysis of CP/NET"
George H. Clapp
ACM "SIGPC Notes", Vol.6, No.2, 1983, p.117
(1983 ACM Conference on Personal and Small Computers)
(Retyped by Emmanuel ROCHE.)
Abstract
--------
CP/NET, a software package designed to add networking
capabilities to microcomputers running under the CP/M-80
Operating System, is examined with respect to internal logical
organization, separation of functions, and correspondence with
the ISO OSI reference model.
Certainly useful and worth reading. The important component is only
hinted at. The SNIOS is only discussed in abstract and it's
construction is not trivial. If you've ever writtin a bios for CP/M
you know there are many things to be met and while a minimal bios is
easier and can work it limits the system. A SNIOS the minimal
implementation is far more complex, there are moer things that must be
done and it is of course depedent on the network IO subsystem. At the
time of writing The use of "network" only implied intercommunication
not Eithernet so it was common to use parallel busses, Async serieal
IO and Faster synchronous serial using bisync, SDLC, HDLC With
associated layered link protocals. Now, some of those have their
implmentation requirements that further extend the things the SNIOS
MUST do.

So to be clear, thats only the visible tip of the iceburg and does
little to help the real work. I've already said CP/M V2.2 is adaquate
and CP/Net only adds a few primitives that are mildly helpful. What
I've very strongly said was the IO package being part of the BIOS,
SNIOS or a seperately loaded package must run with a far higher
perfomance than was generally implemented for many modem
programs used to access BBSs. And if done right and bound to
the OS correctly it allows networking not unlike early PC style under
dos.


Allison
Loading...