Networking for CP/M
James Moxham (Dr_Acula)
software I have been writing. The second is some questions about CP/M
Net.
Part 1: Software.
The CP/M propeller emulation is now able to network CP/M wirelessly.
Specifically, you can run a little program on computer A which logs
into computer B, and then you can talk to computer B as if it is a CP/
M computer in front of you. But computer B can be up to 3km away. The
program first asks what computer you want to talk to, and then gives
three options 1) send a file, 2) receive a file or 3) route all
keypresses to the remote computer and send all received data to the
local screen. So you can send a file with option 1 and then run it
with option 3. You can even run wordstar on the remote machine and the
only real difference is a slight delay with keypresses appearing on
the screen.
I change the screen colour when talking to a remote machine. The
program to do this was originally written in Z80 assembly but has been
ported over the SBasic to improve readability. There is an active
thread here http://forums.parallax.com/forums/default.aspx?f=25&p=012&m=405722
with code (interspersed with comments helping others get their boards
working.)
Having spent weeks modifying CP/M for custom keyboard and display
drivers for the N8VEM, coupled with endless reprogramming of eproms,
for this project I very much wanted to not modify CP/M at all. So -
this is CP/M 2.2 which is straight from the Altair SIMH site. I'm sure
other versions of CP/M will work too (someone else has had a banked
version working).
The propeller code sits underneath CP/M and handles things like
buffering serial ports, buffering keyboard input and listening for
little wakeup messages from remote boards. This is done with extra
ports so you can interact with this with assembly IN and OUT, or Basic
INP and OUT.
Next step is to write a router program. eg three computers, A, B and C
and A can talk to B and B to C but A is too far away from C. So send a
little router program from A to B, then run it, and this passes
messages from A to C. The delay will be longer, but ideally one can
then log into C and send files, receive files etc.
This is all great fun. There is something cool about writing a program
in Wordstar on computer A, sending that source to computer B and then
compiling and running it on computer B when computer B is on the other
side of a hill.
Part 2: CP/M Net (and DR Net)
I'm trying to understand more about how these programs worked. I found
the source for CP/M Net on Gaby's site, but there is a lot about it
that I don't understand. Down the bottom of this page
http://www.lesbell.com.au/Home.nsf/web/CP%2FM+and+Derivatives?OpenDocument
is a description of CP/M Net and a comment that it didn't really catch
on because it took up too much memory. (There are things I could
borrow though, like the NETWORK and LOCAL commands as well as the
messaging). But right down the bottom is mention of DR Net. Does
anyone know more about this product and how it worked, what sort of
hardware it ran on, list of commands etc? Has anyone here ever used
it?
Help and advice would be most appreciated.
Mr Emmanuel Roche, France
Haaaaa! Finally, something new!
> The program first asks what computer you want to talk to, and
> then gives three options 1) send a file, 2) receive a file or 3) route
> all keypresses to the remote computer and send all received data
> to the local screen.
I think that it could be further simplified. Do you remember the Ctrl-
P switch? You could change the CCP so that a control code (Control-D =
Detach from console) could change your I/O to either of 2 states:
"Online" and "Remote". (The problem being that the CCP would always
contain, by default, the code. Must be a bad idea. Better to stick to
CP/NET. In addition, it was the basis for DR-Net, which is, by
default, compatible with CP/NET Version 1.2.)
> I change the screen colour when talking to a remote machine.
Well, for a command-line computer, this is what used to be done.
(Black for online, and Red for remote.)
> The program to do this was originally written in Z80 assembly
> but has been ported over the SBasic to improve readability.
Hahaha! Still a fan of SBASIC? When will you discover CBASIC Compiler?
> This is all great fun.
Haaa! Why are you living so far away?
> Part 2: CP/M Net (and DR Net)
>
> I'm trying to understand more about how these programs worked. I found
> the source for CP/M Net on Gaby's site, but there is a lot about it
> that I don't understand. Down the bottom of this pagehttp://www.lesbell.com.au/Home.nsf/web/CP%2FM+and+Derivatives?OpenDoc...
> is a description of CP/M Net and a comment that it didn't really catch
> on because it took up too much memory. (There are things I could
> borrow though, like the NETWORK and LOCAL commands as well as the
> messaging). But right down the bottom is mention of DR Net. Does
> anyone know more about this product and how it worked, what sort of
> hardware it ran on, list of commands etc? Has anyone here ever used
> it?
I had a look, and found:
DR Net
------
This is the new networking system from Digital Research. Running under
Concurrent CP/M it extends the password protection schemes of that
operating system across the network. Machines can be mixed; the
prototype at Digital Research used Compupro systems mixed with IBM
PC's. Gifford Systems have had a network running for several months
which comprises fourteen computers (13 multi-user and 1 PC XT), with
463 Mbytes of disk storage and fifteen printers. Any user can log into
any disk drive and print on any printer - subject to security
constraints.
The network is not restricted to any particular kind of hardware,
although early systems have been implemented using ARCNet hardware and
Ethernet.
------------
Dr-Net is the 8086 version of CP/NET. It was funny to discover that,
in 1986, it was further named "FlexNet", so, with luck, one day, we
will also have it running under FlexOS, the Real-Time version of
Concurrent DOS.
Dr-Net is documented in several manuals, including a "System Guide".
By default, it uses the protocol of CP/NET Version 1.2, to be
compatible with the 8-bit version. This way, you can run Dr-Net under
either CP/M-86 or MS-DOS, and "talk" with an 8-bit CP/M 2.2 computer.
Each "node" of the network contains a table describing the computers
to which it is connected. So, if you like, you can arrange them like a
hierarchical directory, or in a loop, or in a line, or whatever. (CP/
NET is "requester" only. Dr-Net can, and should, be "server".)
I published an article written by Digital Research about Dr-Net in the
comp.os.cpm Newsgroup (Why are people not saving and learning by heart
what I publish?).
I simply do not know why there is so few interest in the Network OSes
developed by Digital Research.
Yours Sincerely,
Mr. Emmanuel Roche, France
Mr Emmanuel Roche, France
> Hello!
> Who have informations about operating system FlexOS?
> We need references of ETHERNET cards which are supported by FlexOS and FlexNET.
> The only reference of cards we have is SMC WD80X3, but these cards will be no
> longer produced in a few months.
> Thank you for help.
comp.os.msdos.misc
18 April 1996
Max Scane
<moxh...@internode.on.net> wrote:
> This post is in two parts. First is an update on CP/M networking
> software I have been writing. The second is some questions about CP/M
> Net.
>
> Part 1: Software.
>
> The CP/M propeller emulation is now able to network CP/M wirelessly.
> Specifically, you can run a little program on computer A which logs
> into computer B, and then you can talk to computer B as if it is a CP/
> M computer in front of you. But computer B can be up to 3km away. The
> program first asks what computer you want to talk to, and then gives
> three options 1) send a file, 2) receive a file or 3) route all
> keypresses to the remote computer and send all received data to the
> local screen. So you can send a file with option 1 and then run it
> with option 3. You can even run wordstar on the remote machine and the
> only real difference is a slight delay with keypresses appearing on
> the screen.
>
> I change the screen colour when talking to a remote machine. The
> program to do this was originally written in Z80 assembly but has been
> ported over the SBasic to improve readability. There is an active
> is a description of CP/M Net and a comment that it didn't really catch
> on because it took up too much memory. (There are things I could
> borrow though, like the NETWORK and LOCAL commands as well as the
> messaging). But right down the bottom is mention of DR Net. Does
> anyone know more about this product and how it worked, what sort of
> hardware it ran on, list of commands etc? Has anyone here ever used
> it?
>
> Help and advice would be most appreciated.
Hi James, the cp/net manual has a good description of how it works.
You can find it here:
http://www.cpm.z80.de/manuals/cpnet_ht.zip
Basically, cp/net allows you to do file, printer and console sharing
between multiple client CP/M
systems and a central "server" system. In the 8 bit CP/M environment,
the clients were based
on CP/M 2.2 and the server was an MP/M system. The manual also talks
about MP/M servers
talking to each other but I have never seen the code to do that.
There is also a disk-less client
called CP/NOS.
The client side code installed a re-director which intercepted BDOS
calls for file and i/o access
and depending on the contents of the configuration table, the calls
were re-directed to local or
remote resources as required. The commands like network, local etc
manipulated the table to
do this.
On the server side, the MP/M system was built with slave support
processes which handled the
client requests to access the MP/M file system.
In true DR style, both the client and the server packages contained a
fixed and variable part. The
variable components were effectively a network BIOS and the fixed
parts were the re-directors and servers.
cp/net didn't specify an underlying network hardware. Typically it was
used with individual serial links. The
manual does describe a system based on ARCnet as well. The
implementer develops the Slave Nerwork IO
System (SNIOS) using whatever comms link required. cp/net utilises
the SNIOS to talk to the server and
assumes a one to one topology.
The server was not limited to MP/M. In the version 1.2 manual, there
is a section about building a non MP/M
based server. Hector Peraza wrote a brilliant cp/net server for Linux
which I often use.
There is also an implementation of cp/net on the Altair SIMH site.
Some time ago, I posted a cp/net client modified for the N8VEM on the
old Google Groups site which used
a USB FiFo chip connected to the parallel port as the comms link. I
will see if I can move it to the wiki.
The problem initially with using cp/net on the N8VEM was that there
was only one serial port and that was the console. Now that the VDU
and the Zilog peripherals board are here that problem goes away.
Once I get my Dracblade up and running I want to test cp/net out on
it.
Cheers!
Max
James Moxham (Dr_Acula)
responses. This is going to keep me reading all night.
Mr Roche - some very interesting suggestions there. It would be great
to replicate old network instructions on a new board.
Re "Hahaha! Still a fan of SBASIC? When will you discover CBASIC
Compiler? "
I took a look at CBASIC just now.
PRINT "Hello World"
saved as HELLO.BAS
and ran SUBMIT CBASIC HELLO on the SIMH and it worked! Do you have
some more online links for CBASIC, eg an instruction manual?
Re Max - lots of background info there.
With more serial ports these operating systems could be resurrected.
The N8VEM seems to be expanding exponentially. I can't keep up!
The Propeller emulation uses 4 pins to create two serial ports. It
devotes 8 pins to a vga display. But it also has a small LCD display,
so potentially you could drop the VGA display and get 2 more serial
ports giving a total of 4 ports. Enough to run a MP/M server. The
software is already there for 4 asynchronous serial ports. Or, you
could use 4 lines to run a TV monitor and get 4 spare lines that way.
I am exploding with ideas!
Here's one that I just coded tonight. In Basic on CP/M you can write
A=PEEK(5000)
but on the new whizzo Propeller emulation, you could also write
A=PEEK_EXTENDED(500000)
How so? Well the ram chip for the propeller needed to be fast and it
needed to run at 3V, and looking at the prices the best value one is a
512k ram. CP/M only uses 64k so the rest of the ram is not being used.
Down the track, it will be perfect for MP/M, but in the meantime, I
wrote a little bit of code that sits underneath CP/M and handles the
data. 3 address bytes passed at locations 80H to 82H and the data byte
via a psuedo I/O port.
Easy to use. Here is the Main of a little SBASIC program (soon to
maybe be CBASIC??)
var address=fixed
var value=integer
input "Address value (0-524287): ";address
input "Value (0-255): ";value
print "Poking variable ";value;" to address ";address
Poke_Extended address,value
print "Peeking the location =";Peek_Extended(address)
Full source etc is over at the Propeller forum. It is a little slow
but it would only be a few more lines of code to do block moves of 128
bytes rather than single bytes.
Well, I must now go and do some more research on networking for CP/M
and also CBASIC.
All...@localhost.net
<roch...@laposte.net> wrote:
>Hello, James!
>
>Haaaaa! Finally, something new!
New? your kidding of course. You surely forget poor mans networking
and a bunch of other networked software and systems that didn't
require DR-net,MPM or CP/Net.
This was done 30 years ago. You poke that at me but you obviously
have a short memory for networking efforts of others.
Allison
Peter Dassow
> This post is in two parts. First is an update on CP/M networking
> software I have been writing. The second is some questions about CP/M
> Net.
Plz take also a look at http://www.retrotechnology.com/dri/cpm_tcpip.html ,
Herb collected a lot of infos already there.
Regards
Peter
Mr Emmanuel Roche, France
> New? your kidding of course. You surely forget poor mans
> networking and a bunch of other networked software and
> systems that didn't require Dr-Net, MP/NET or CP/NET.
Personally, my favorite is:
- "Ultra-Low-Cost Network for Personal Computers"
Ken Clements & Dave Daugherty
BYTE, October 1981, p.50
I retyped it many years ago, but never found a local electronician to
link all my computers (including the ASR-33 Teletype).
And now, James is in Australia...
When will I find someone knowledgeable enough to help me on the
hardware side?
Al Kossow
TCP/IP is one set of networking protocols, there were many others.
TCP is pretty heavyweight for use on systems with small address spaces.
There were many client/host systems including Corvus Omninet, and Digital
Microsystems' HiNet.
One interesting aspect of the early file sharing systems is very few had the
notion of a common shared file store. Most divided the shared disk server into
partitions which were spread across each of the client machines.
I'm curious when the first single-user systems using a bus style local area
network could transparently do peer-peer file operations. I don't think I ever
saw a system like this in the CP/M Z80 timeframe.
Mr Emmanuel Roche, France
> TCP/IP is one set of networking protocols, there were many others.
Yes, but this is the standard used by the Internet. (It is me who
published a Web page about the last IBM Clowns using XMODEM. And they
were phased out for "more modern standards".)
By the way, Al, where is the "FlexOS System Guide" (and the
"Distribution Disks" mentioned in the other guides)?
Herbert Johnson
> > This post is in two parts. First is an update on CP/M networking
> > software I have been writing. The second is some questions about CP/M
> > Net.
> > [...]
> > Help and advice would be most appreciated.
Peter Dassow wrote:
> Plz take also a look athttp://www.retrotechnology.com/dri/cpm_tcpip.html,
> Herb collected a lot of infos already there.
That Web page was written to respond to the general, often-asked
question "I want to hook my CP/M system to Ethernet (or the Internet,
or the Web)...". It's accumulated from prior discussions in
comp.os.cpm, but also includes links to specific resources. I worked
with the respondents, to gather from more obscure or private archives,
specific software packages related to early packet radio work which,
at the time, ran CP/M and supported versions of TCP/IP.
But the specific question from James Moxham was about CP/NET. That is
NOT a TCP/IP implementation, as has been pointed out. There are a few
resources about CP/M and CP/NET, which have been mentioned in this
thread. An additional resource, is:
http://www.unix4fun.org/z80pack/
Udo Munk's "z80pack" Z80 emulator site which includes whole
implementations of various CP/M and MP/M versions, plus
implementations of CP/NET. These are as simulated systems under Linux,
and then adapted to Windows. These were discussed at length in
comp.os.cpm, and Udo has considerable resources on his Web site.
A Google Groups search of comp.os.cpm will find this, and prior
discussions. I strongly recommend that to you, James. Also, a Google
search for "CP/M CP/NET" done by me (Google search provides different
results based on a person's prior searches) found a number of Web
sites already mentioned, and some CP/M archive sites. Again, I
recommend such searching.
Emmanuel Roche wrote:
> I published an article written by Digital Research about Dr-Net
> in the comp.os.cpm Newsgroup (Why are people not saving and
> learning by heart what I publish?).
Emmanuel Roche asserts that his posting large amounts of material in
comp.os.cpm is "publication". He refuses to use or cooperate with Web
sites or Web archival sites. Posts of any sort, are hard to find among
the hundreds of posts accumulated each month in comp.os.cpm, a group
decades old. Roche's schemes to add codes and names to his posts are
not useful because there's no index or archive of those schemes for
reference. In any event, his activities are an inappropriate use of a
Usenet newsgroup. That's a matter of Usenet policy and not just my
opinion.
My Web page on CP/M and TCP/IP, makes use of comp.os.cpm in a way that
is Web-searchable. It references other Web sites, links that can be
readily updated by me. Content can be accumulated and edited as
needed. (For example, I could add a reference to CP/NET.) It happens
to demonstrate why Web pages and Web archives are a far better way to
"publish" works of content, than using email/Usenet archives.
Herb Johnson
retrotechnology.com
Herbert R. Johnson, New Jersey USA
http://www.retrotechnology.com/ retro-technology home pages
-- S-100, CP/M history by "Dr. S-100"
contact me via my Web site, not "gmail" please
glen herrmannsfeldt
(snip)
> One interesting aspect of the early file sharing systems is very few had the
> notion of a common shared file store. Most divided the shared disk server into
> partitions which were spread across each of the client machines.
> I'm curious when the first single-user systems using a bus style local area
> network could transparently do peer-peer file operations. I don't think I ever
> saw a system like this in the CP/M Z80 timeframe.
Before ethernet became popular for small networks there was ARCnet.
I believe it was cheaper and sometimes used for such nets.
There was the Tandy/RS model 16, I believe both Z80 and 68000,
which I think was used in small networks.
Some might also have been done over RS232, though I don't remember
that so much.
-- glen
All...@localhost.net
<roch...@laposte.net> wrote:
>Allison "Invasion" Parent wrote:
>
>> New? �your kidding of course. �You surely forget poor mans
>> networking and a bunch of other networked software and
>> systems that didn't require Dr-Net, MP/NET or CP/NET.
>
>Personally, my favorite is:
>
>- "Ultra-Low-Cost Network for Personal Computers"
> Ken Clements & Dave Daugherty
> BYTE, October 1981, p.50
>
Yep works too. Implemented it back in '81 and extended it to be a
more functional network between multiple CP/M2.2 machines.
>I retyped it many years ago, but never found a local electronician to
>link all my computers (including the ASR-33 Teletype).
>
>And now, James is in Australia...
>
>When will I find someone knowledgeable enough to help me on the
>hardware side?
Keep looking.
Allison
All...@localhost.net
I handled it differntly, there is no need for internet style routing.
So the best fit is explicit connection, IE a program called "SETCONN"
was developed to basically fill a list in the BIOS as to what goes
where. Possible routed devices are Printer, Console (in and/or out)
and DIsks. That is the basic IO of a CP/M system (forget punch and
reader) and they can be virtual devices out at the end of a wire.
Obviously the SETCONN hand shakes with the other systems who have like
capability to insure deadlock (everyone sends their printer to A and A
is routing to someone else) and also to get persmission from the other
guy for connectivity. it's easier if the assumption is only one user
and multiple machines but I wasnted to ahve the functional ability to
have multiple users interacting.
>This is all great fun. There is something cool about writing a program
>in Wordstar on computer A, sending that source to computer B and then
>compiling and running it on computer B when computer B is on the other
>side of a hill.
The next step is having the source file on A compiled by B stored on C
and the bios support for A, B and C on D where the console is!
>
>Part 2: CP/M Net (and DR Net)
>
>I'm trying to understand more about how these programs worked. I found
>the source for CP/M Net on Gaby's site, but there is a lot about it
>that I don't understand. Down the bottom of this page
>http://www.lesbell.com.au/Home.nsf/web/CP%2FM+and+Derivatives?OpenDocument
>is a description of CP/M Net and a comment that it didn't really catch
>on because it took up too much memory. (There are things I could
>borrow though, like the NETWORK and LOCAL commands as well as the
>messaging). But right down the bottom is mention of DR Net. Does
>anyone know more about this product and how it worked, what sort of
>hardware it ran on, list of commands etc? Has anyone here ever used
>it?
>
>Help and advice would be most appreciated.
Just look at the CP/Net APIs (all but a very few are CP/M V2 and the
reamaining ones are for logining in, out and exchanging messages.
Allison
Jeff Jonas
>> I'm curious when the first single-user systems using a bus style local area
>> network could transparently do peer-peer file operations. I don't think I ever
>> saw a system like this in the CP/M Z80 timeframe.
My quick guess why peer to peer was slow to appear
- it's hard to implement since each node is client and server,
requiring a lot more RAM/core and CPU (when CPU cycles were still precious).
My "working definition" of a workstation vs. PC
was that a Workstation had the resources (CPU, ram, disk)
for peer to peer networking whereas the PC struggled as just a network client.
- harder to administer than a central server,
unless there is a single source for things such as
authentication and access control (e.g. Kerberos)
some scattered memories:
The Z80 Ampro LittleBoard folks were keen on using/developing
SCSI for networking, perhaps peer to peer not just client/server.
That's certainly "bus style local area network" but very length limited.
ARCnet, StarLAN: I never used it but salvaged many parts
as they were decommioned. At 1 megabit, I never bothered.
Their big win was using twisted pair cat-3 phone wiring
instead of coaxial or twin-axial (IBM).
In a PC environment, I never used NetBUI
but Novell Netware gave printer and file servers.
It somehow shoehorned/retrofit into the Windows 3.x stuff
way before M$ reinvented it all.
And it used the IPX protocol, not TCP
even if it's on 10-base-x ethernet.
DECnet: I never touched it but that too
used its own protocol and paradigms.
Mainframes had SNA, LU 6.2 and such,
ingeniously expanding their 3270 "green screen" infrastructure
to support peer to peer networking.
Zilog's Znet was their Z80/Z8000 ethernet-style network.
Serial line/dialup networks were popular such as UUCP, Fido, etc.
That was just "nodes" dialing each other as-needed/on-demand
sharing files, e-mail, etc.
There were data-switches such as Datakit for more of a star topology.
>Before ethernet became popular for small networks there was ARCnet.
>I believe it was cheaper and sometimes used for such nets.
I've heard that ARCnet's still alive and well as the basis
for very local, serial, twisted-pair networks of controllers.
Roger Ivie
> The Z80 Ampro LittleBoard folks were keen on using/developing
> SCSI for networking, perhaps peer to peer not just client/server.
> That's certainly "bus style local area network" but very length limited.
Did that once with VAXstation 4000s; I had a /60 and a /90 and a pair of
TURBOchannel dual-SCSI boards. It took both SCSI ports on each board to
do it, one configured as a target and the other as an initiator. I had
TCP/IP and DECnet talking over SCSI, but never attempted to form a
cluster.
The big killer was interrupt latency. Using the 53C94, one of the
machines (I forget whether it was the target or initiator) had to field
three interrupts for each network packet while the other had to field two.
Interestingly, although the /90 was a much faster machine than the
/60, the /60 had *much* better interrupt latency.
--
roger ivie
ri...@ridgenet.ne
James Moxham (Dr_Acula)
Net. I am reading through this all at the moment.
What I have working is two boards and each board can log into the
other, control the other as if typing locally on a keyboard and send
and receive files. This is a peer to peer network. The problem gets
more complex though when you have many boards talking via wireless,
because no computer is in charge of who talks when. Thanks to Mr
Roche's documents, I have had a sudden brainwave. I am going to create
a server/client model, but with a number of servers, each with their
local clients. I wrote it up last night before I forget how it will
work!
Notes re CP/M server program for wireless networks
The fundamental problem – only one board can transmit at any time. So
strict protocols are needed to prevent data clashes between boards.
The server program:
* Acts as a router between two clients.
* Can direct bytes between client 1 and client 2
* Can serve up files
* Can search for and find other servers within range
* Can’t do a local DIR nor run other local programs nor go back to CP/
M
Client boards/computers can:
* Run any local CP/M program
* Run a little program called NET4 that connects to any local board
within wireless range
* Connect to a server board that can then handle routing to any client
board within range of any server
Boards have names ALPHA BETA GAMMA etc
A byte string #ALP coming into serial port 2 will “wake up” a board.
Any further bytes coming into that serial port are directed to the
console as if typed on the local screen. Any output to the local
screen also goes to port 2. You can disconnect by running the program
PORT2OFF or LOGOFF (which does an OUT to port 71 (any byte)).
Boards also timeout and disconnect if no data transfer for 3 minutes.
Boards can directly transfer files if they are in range with the NET4
program. This program can also handle direct logins to other boards.
But the problem here is chaining messages from, say ALPHA to BETA to
GAMMA, particularly when ALPHA is not able to contact GAMMA directly.
So, consider a cluster ALPHA, BETA and server SIGMA. And consider
another cluster, GAMMA, EPSILON, and their server TAU.
ALPHA wants to log into GAMMA, but GAMMA is out of range.
So – ALPHA logs into SIGMA and SIGMA is running a network program.
SIGMA sends back a message to say it is online and gives a menu. The
menu includes local clients that SIGMA has tested it has good links
with. It also includes a list of other servers that SIGMA has found
(via longer range wireless for example). ALPHA might request a list of
local clients for TAU. SIGMA then sends out a message to ALPHA not to
print characters on its local display while it is talking to TAU.
SIGMA then wakes up TAU and requests a list of local nodes. These
might be transferred via xmodem in a small text file. SIGMA then sends
this list on to ALPHA. The list includes GAMMA.
ALPHA might then choose to build a link to GAMMA. A message is sent to
SIGMA to build the link. SIGMA replies to ALPHA saying the link is now
active. ALPHA now types some characters, eg a DIR These are passed to
SIGMA, SIGMA then sends a message back to ALPHA to ignore any RF
characters for the moment. SIGMA forwards the characters on to TAU
wrapped up in a packet. TAU wakes up GAMMA, sends the characters,
waits till characters stop coming back (a 5 second timeout maybe),
buffers them, wraps them up as a series of packets (or possibly as a
file if there are lots and sends via xmodem), sends this on to SIGMA,
who then wakes ALPHA back up and then sends them to ALPHA such that
they appear on the screen as if it was a response to a DIR.
The concept can be daisy chained with servers.
An emergency sequence of 4 bytes can be sent to a server to reboot it
if it is not responding. Servers have an autoexec file such that they
run the server program automatically.
Since file transfers are possible, it is possible to upgrade server
software via wireless.
The server software is a simple as possible. Functions include:
* Find local nodes (either manually or automatically from time to
time)
* Find other servers.
* Pass messages to local clients
* Pass messages to other servers wrapped up in data packets
* Receive messages from other servers.
* Transfer files to and from clients.
* Send new versions of server software to other servers and reboot
them.
The main role of the server is to wrap up data packets and route them
on. Consider, we have a link set up between ALPHA and EPSILON and
there are a whole lot of boards in between handling getting the data
there. The user types DIR, but they have a long pause between the I
and the R. Sooner or later the server decides that it may as well take
DI and wrap it up into a packet and send it on. This needs to be done
such that there are no data clashes, so the first thing is to tell the
sending board to just buffer input for the moment and not forward it
on. Then the server wraps this up in a packet with a source and
destination and sends it on via the server network such that it gets
to the nearest local server that is in range of the destination board.
That server then “types” it into that destination board as if someone
typed it on the keyboard. It then waits for a reply. In this case the
command is incomplete, so the remote board will just wait, and the
server network handles handshaking so that there are no data clashes.
What this means is that any client board can be either a new or an old
computer/board. All it really needs is a serial port and the UART port
codes to talk to that port. Usually that will be a few port numbers
between 0 and 255. The ‘terminal’ program is incredibly simple – it
just accepts keyboard input and routes it on to the serial port. It
also scans the serial port and routes characters to the display. And
it looks for a specific logoff character (I’m using ~, but maybe Esc
would be better?)
The big disadvantage of wireless is that only one board can talk at
any one time. So very strict protocols are needed for server
software.
But the huge advantage is you don’t need fancy RS232 routers (which
are very rare these days anyway). Even a server has just one serial
port with a wireless transceiver module (standard RS232 signals, cost
about $20). So this ought to be a way of linking old computers with
new boards, or 20 old computers with each other etc.
At present, the Propeller network is using the command #BET to log
into specific boards. This requires a layer underneath CP/M that runs
some code when these bytes arrive. But I think with servers no layer
is needed under CP/M, as any nominal logon sequence can be defined and
the server can listen for that and respond accordingly. So, if you
give up the (already working) direct links between two clients, and do
everything via a server, the sacrifice is a small time delay, but the
advantage is that no special code is needed so old computers (with a
serial port) can become part of the network.
Obviously this is going to need testing with real code, but the basic
principles are already working. It is possible right now to send and
receive files wirelessly via xmodem and to log into remote computers
wirelessly, so all that is needed now is server software with simple
menus to make this an easy process for the user. And the good news is
that about half that server software has already been written and
tested.
Another problem that comes up from time to time is "I have this old
computer and I can't get any software onto it". I've been thinking
about this and a similar model would be a N8VEM bare board, 32k of
eprom with a handful of programs and a blank ram disk. You need a
program to 'format' the ram disk and that is pretty easy as it is just
a few lines of assembly to fill it up with E5. Then you need to get
something through. If the board has a serial port to talk to a dumb
terminal (like my first CP/M machine did), that is very easy. If it
has a serial port as a 'second' port, that is a little more complex,
but it would only be a few lines of assembly to redirect keyboard to
the second port and to direct incoming data from the port to the local
display. I've got some source code for that. So assuming you have a
minimum of an assembler or mbasic or any other language, that might be
enough to build a simple program. If you have ED, the server could
'type' a program into ED and save it and compile it etc. I think PIP
might even be able to collect bytes from a serial port - if you tell
it where the port is. In a perfect world the computer might have the
serial port mapped to PUNCH or one of the other standard CP/M I/O
peripherals.
If a server detects a GUEST it can send some menu choices to that
computer. eg - do you have xmodem? If not, as a few questions about
the serial port number and then send over a customised xmodem program
- either the source that can be compiled locally or a .COM already
compiled.
Once xmodem is running, file transfers are a lot easier as it includes
error correction.
The above model is slightly different to CP/M Net as each client is
running its own local version of CP/M - it is not logged in as a user
on MP/M on a server. But it can still access all the files on the
server (which in the case of a propeller emulation would be 64mb on an
sd card). And some clients might have their own hard drives - or might
be more limited like the 448k ram drive for the N8VEM. As a general
point, by the time you build a "dumb terminal" with a propeller, like
the pocketerm, capable of driving a VGA monitor and a keyboard and a
couple of serial ports, adding in full CP/M is only another $20 or so.
But there still may even be a place for dumb terminals on this network
too, which would need an MP/M environment to service more than one.
I'm also thinking of putting each cluster on a different radio channel
(which is possible with many of the $20 transceiver units) so that
clusters don't interfere with other clusters.