CP/NET-80 Version 1.2
Arobase, Salle multimédia
---------------
By separating the logical operating system from the hardware
environment and placing all hardware-independent code in a
separate I/O module, CP/M and MP/M II have gained widespread
industry acceptance. The CP/NET operating system uses this same
design approach. CP/NET is network independent. The Slave
Network I/O System (SNIOS) module contains all network-dependent
code for the requester. The Network Interface Process (NETWRKIF)
module contains all network-dependent code for the server.
Logical messages passed to and from the SNIOS or NETWRKIF are
transmitted over an arbitrary network between servers and
requesters using an arbitrary network protocol.
CP/NET and CP/NOS can be combined in a composite network
consisting of MP/M II servers, CP/M requesters, and diskless
CP/NOS requesters.
CP/NET is a bridge between a microcomputer running MP/M II and a
microcomputer running CP/M. The MP/M II server manages resources
that are considered public to the network. The CP/NET requesters
executing CP/M have access to the public resources of the server
and to their own local private resources, which cannot be
accessed from the network. This architecture permits the
server's resources to be shared among the requesters, yet
guarantees the security of the requester's resources.
The MP/M II server responds to the network asynchronously in
real-time; the CP/M requesters perform sequential I/O, and are
usually not capable of monitoring a network interface in real-
time. Figure 1-1 illustrates the relationship between CP/M, MP/M
II, and CP/NET.
Figure 1-1. Standard CP/NET Configuration
CP/NOS, the second network operating system product, is designed
for applications where the requester microcomputer lacks disk
resources, and is therefore unable to run CP/M. CP/NOS consists
of
- a bootstrap loader that can be placed into ROM or PROM,
- a skeletal CP/M containing only the console and printer functions,
- the logical and physical portions of the CP/NET requester.
At the user level, CP/NOS provides a virtual CP/M 2.X system to
the requester microcomputer. A requester microcomputer can
consist of no more than a processor, memory, and an interface to
the network. Thus, a CRT with sufficient RAM can execute CP/M
programs, performing its computing locally and depending on the
network to provide all disk, printer, and other I/O facilities.
Figure 1-2 illustrates the relationship between CP/NOS, MP/M II,
and CP/NET.
Figure 1-2. CP/NOS Configuration
1.1 CP/NET Features
-------------------
CP/NET operates in multiple-processor environments ranging from
tightly to loosely coupled to networked processors. In this
manual, tightly coupled processors are those sharing at least a
portion of common memory. Interprocessor messages communicate at
memory speed. Loosely coupled processors do not have access to
memory that is common or accessible by both processors; they
communicate via a short, high-speed bus. Loosely coupled
processors usually reside in the same physical box. Networked
processors are usually physically separated, and communicate
over a serial link.
The CP/NET operating system is an upward-compatible version of
CP/M 2.2, which provides system I/O facilities to requester
microcomputers through a network. Additions to the Basic I/O
System (BIOS) called the Slave Network I/O System (SNIOS), and a
new Basic Disk Operating System (BDOS) called the Network Disk
Operating System (NDOS), provide network access to System I/O
facilities. The requester NDOS and NIOS are loaded and executed
while running under CP/M 2.2.
In addition to the standard CP/M facilities, CP/NET provides the
following capabilities:
- The network can be accessed for system I/O facilities.
- The network environment can be reconfigured to access I/O
facilities according to application requirements.
- Messages can be transmitted and received between
requesters and servers.
- An electronic mail system allows requesters and servers
to send mail to each other.
The MP/M II server is implemented by adding some resident system
processes at system generation (GENSYS) time. The resident
system processes include server processes (SERVER) that perform
the logical message-handling functions for the server, and
network interface processes (NETWRKIF) that you can customize
for a particular hardware network interface.
1.2 CP/NET Configurations
-------------------------
CP/NET supports a number of different network topologies, and a
variety of system resources. The interprocessor message formats
permit a requester to access more than one server for different
resources.
Figure 1-3 illustrates an MP/M II system supporting a single
CP/NET requester. The requester is a totally independent system,
with its own console, printer, and disk resources. The requester
can also access the MP/M II system's resources over the network.
The MP/M II system also supports other users using local
terminals.
Figure 1-3. Single Requester Networked to MP/M II Server
Figure 1-4 shows an active hub-star network running CP/NET. Each
requester is networked to the server through a unique network
port. The requesters have their own local resources, but they
also share the server's disk and printer resources. This
topology is simple to implement, because you can adapt the
network protocol from the protocol used for RS-232 console
drivers. The sample system in Appendix E uses this topology.
Figure 1-4. Multiple Requesters in Active Hub-star Configuration
Figure 1-5 shows a system of three requesters and two servers
networked together in a bus or multi-drop configuration. The
network protocol must be capable of resolving conflicts when
nodes attempt to use the network simultaneously. Each requester
has access to the resources of both servers, in addition to its
own local resources. Appendixes F and G provide examples of
CP/NET systems using this network topology.
Figure 1-5. Multi-drop Network
Finally, you can combine these topologies, as well as other
topologies like loops and trees, into a hybrid network topology.
Figure 1-6 depicts such a topology, combining the bus, star, and
loop forms.
Figure 1-6. Hybrid Network
1.3 How the Requester Works
---------------------------
The CP/NET requester software runs under an unmodified CP/M
version 2 operating system. The requester operating system
consists of three object modules: NDOS.SPR, SNIOS.SPR, and
CCP.SPR. These modules are system page relocatable files that
can be loaded directly under the CP/M BDOS and BIOS, regardless
of their size or their location in memory.
The module NDOS.SPR contains the Network Disk Operating System
(NDOS), the logical portion of the CP/NET system. The NDOS
determines whether devices referenced by CP/M function calls are
local to the requester or whether they are located on a remote
system across a network. If a referenced device is networked,
the NDOS prepares messages to be sent across the network,
controls their transmission, and finally reformats the result
received from the network into a form usable by the calling
application program. NDOS.SPR is distributed in object form by
Digital Research. No modification to this module is required to
run CP/NET.
The Slave Network I/O System (SNIOS) is contained in the module
SNIOS.SPR. The systems implementer must customize this software
to run on a particular computer and network system. The SNIOS
performs primitive operations that allow the NDOS to send and
receive messages across a network. The SNIOS also provides a
number of housekeeping and status functions to the NDOS. Digital
Research distributes a number of example SNIOS modules in source
form with CP/NET.
The final module, CCP.SPR, is a replacement for the normal CP/M
2.2 CCP. Like the regular CCP, CCP.SPR is loaded directly below
the operating system. However, CCP.SPR performs a number of
special network functions that initialize the environment for a
program.
The logical origin of SPR files is location zero. Each file has
a 256-byte header, with locations 1 and 2 defined as the length
of the code in the file. A bit map, appended to the end of the
code, identifies bytes of the code that must be relocated when
the code is loaded on a particular page (256-byte) boundary. The
CP/NET utility CPNETLDR relocates the bytes defined by the bit
map.
CPNETLDR loads SNIOS.SPR directly below the CP/M BDOS. NDOS.SPR
is loaded directly below the SNIOS. CPNETLDR then passes control
to an initialization routine. This routine modifies key areas of
the operating system:
- Location 5, which contains a jump to the BDOS entry
point, is saved away by the NDOS. Location 5 is then
modified to jump to an entry point in the NDOS. This
assures that the NDOS intercepts all CP/M function
calls.
- The BIOS jump vector entries for console status, console
in, console out, list status, list out, and warm boot
are replaced with entries that jump into special NDOS
routines. The NDOS saves the BIOS entry points for these
routines, allowing direct BIOS calls to these routines
to be intercepted in exactly the same way that CP/M
function calls are intercepted.
After these modifications have been made, the NDOS calls the
SNIOS to initialize the network. The NDOS then jumps to its own
warm boot routine, which performs a disk system reset, loads
CCP.SPR, and then passes control to the CCP.
When an application program calls the CP/NET operating system
via location 5, the NDOS is entered instead of the BDOS. Invalid
functions return to the user program immediately as errors.
Functions dealing with console or printer I/O immediately pass
through to the local BDOS; but these functions are intercepted
by the NDOS again when the BDOS calls the BIOS. At this level,
the NDOS checks whether the console or printer is a networked
device. If so, the NDOS sends a request across the network for
the input or output.
Some functions have no meaning when they are sent across the
network to a remote server. Examples of these are Function 26
(Set DMA Address), Function 32 (Get/Set User Number), and
Function 12 (Return Version Number). The local BDOS always
handles these functions. But the NDOS saves certain parameters
from these functions for its own use, processing them before
allowing them through to the BDOS.
Finally, the NDOS checks most functions that deal with either
the disk drive system or the file system to determine whether
they reference local devices. If so, these functions pass
unmodified to the BDOS. The NDOS also checks whether these
functions reference devices that exist somewhere out on the
network. If they do, the NDOS constructs a network message to be
sent to the system on which the device exists. The network
message contains the network function to be performed and the
information necessary to perform it.
Figure 1-7 illustrates how the CP/NET operating system is
organized. The solid line outlines the function flow of an
operation on a networked disk drive. The dotted line traces the
flow of an I/O operation to a networked list device or console.
Arrows indicate possible function flow.
Figure 1-7. CP/NET Memory Structure
When an NDOS requester sends a function message out over the
network, a response from the addressed server is implied. As
soon as the NDOS has successfully called the SNIOS to send the
message, the NDOS calls the corresponding message receive
routine, also in the SNIOS. This procedure precludes the problem
of trying to recover sequencing information from an arbitrary
stream of messages.
The NDOS uses the network response to update the application
program that made the function call. The NDOS then returns to
the application program. If the device referenced was local,
then the requester's BDOS updates the application program.
1.4 How the Server Works
------------------------
Unlike the requester, the server software that runs under MP/M
II does not modify the actual operating system. Rather, the
operating system is a set of cooperating processes under MP/M
II.
In its most basic form, each requester to be attached to a
server requires two processes, communicating through two queues.
One process, resident in the NETWRKIF.RSP module, performs the
physical message transport task. The systems implementer must
modify this process to accommodate the network's node-to-node
protocol. The process's protocol must be compatible with that of
the requester's SNIOS.
The NETWRKIF must be capable of monitoring one or more network
lines in real-time and detecting when a requester is trying to
send a message. The NETWRKIF must then receive the message,
check it for data integrity, and send it on to the logical
portion of the server, contained in the module SERVER.RSP.
When the SERVER module returns its response to the logical
message, the NETWRKIF must receive the message, and then
transmit it across the network back to the requester.
The module SERVER.RSP performs the logical operation the
requester specifies. After receiving the message from the
NETWRKIF, SERVER.RSP checks to make sure that the requester is
logged in properly. Then SERVER.RSP responds to the message by
performing a series of MP/M II operating system calls. Using the
information returned by those calls, the SERVER constructs a
response message, and sends it to the NETWRKIF module for
transmission.
Both the NETWRKIF and SERVER modules are Resident System Process
files (RSPs). RSPs are built into the MP/M II system during its
GENSYS operation. When MP/M II is cold started, all RSPs are
automatically dispatched. Each RSP module might contain multiple
processes, but only one process per RSP is automatically
dispatched. Because each requester bound to a server might
require one process from the NETWRKIF and one from the SERVER,
both RSPs contain initialization code to create additional
copies of themselves. These processes can be reentrant. They
can share the same code, but they have separate data areas to
avoid conflict between program variables.
One of the simplest server architectures is shown in Figure 1-8.
Processes from the NETWRKIF are named NtwrkIP<x> where <x> is
the ASCII representation of a hexadecimal number between 0 and
F. SERVER processes are named SERVR<x>PR.
Figure 1-8. A Simple Server that Supports Three Requesters
A NtwrkIP<x> process writes the address of an input message to a
queue named NtwrkQI<x>. A SERVR<x>PR process reads this queue
while waiting for an input message. Because the queue is empty
when the requester is not requesting service, the SERVR<x>PR
process is suspended and consumes no CPU resources.
When the NtwrkIP<x> process writes to the queue, the SERVR<x>PR
process is dispatched, and it begins to operate on the message.
As soon as the NtwrkIP<x> process has finished sending the
incoming message to NtwrkQI<x>, NTWRKIP<x> immediately tries to
read a second queue, named NtwrkQO<x>. This queue is empty, and
the NtwrkIP<x> process is consequently suspended until the
SERVR<x>PR process writes the response message to it. The
NtwrkIP<x> can then transmit the message back to the requester.
Server functions can be divided into four categories:
1) session control functions
2) file serving functions
3) print serving functions
4) non-CP/NET functions
Session control functions permit a requester to log on to a
server, log off, set compatibility attributes, set default
passwords, and examine the server configuration table.
File serving functions make up the bulk of the server's work.
These functions include opening and closing networked files,
reading and writing files, and managing disk devices.
The server can operate as a print server in two different modes.
If the MP/M module SPOOL.RSP is present in the system, requester
outputs to a networked list device are spooled to a file for
future printing. If no spooler exists in the system, the server
manages the attaching and detaching of various print devices.
Finally, the NETWRKIF module can be designed to recognize a
logical message that has no meaning to the SERVER module, but
that can be operated on by a user-defined process. This feature
allows you to use functions CP/NET does not provide.
EOF
Arobase, Salle multimédia
Freek Heite
>> CP/NET Overview (CP/NET-80 Version 1.2)
Hello Arobase,
It might interest you (and others) that a very good looking, complete CP/NET
manual is available at
http://cc.usu.edu/~ivie/cpnet/cpnet.htm
although I'm not sure about its exact version. It's been done by Roger Ivie, he
also HTMLized a CP/M 2.2 manual at
http://dopey.usu.edu/~ivie/cpm2/
Freek.
ri...@ridgenet.net
They can also be found on the Unofficial CP/M web site, over in the Tim
Olmstead Memorial Library at Gaby's place: http://www.cpm.z80.de/drilib.html
--
Roger Ivie
ri...@ridgenet.net
Ross Simpson
Hello Freek,
> It might interest you (and others) that a very good looking, complete
CP/NET
> manual is available at
> http://cc.usu.edu/~ivie/cpnet/cpnet.htm
> although I'm not sure about its exact version. It's been done by Roger
Ivie, he
> also HTMLized a CP/M 2.2 manual at
> http://dopey.usu.edu/~ivie/cpm2/
Actually, it looks like Emmanuel is up to more of his tricks (coverting HTML
pages into Plain Text), that they he can view it in WordStar or something
(that's what he want's to do anyway).
With Regards,
Ross.
Arobase, Salle multimédia
beside me.
I would like to have a copy of the CP/M-86, MP/M-86,
or Concurrent CP/M-86 version.
I don't remember all the details, but I think that
CP/NET-80 version 1.0 is on the Web site of
Tim Olmstead, version 1.1 on "Gaby" Web site.
Recently, I was given some PRN files of CP/NET
version 1.2. Using a modification of one of my
BASIC program, I was able to recreate the source
code files. (I now have a PRN2ASM.BAS program.)
The only slight problem: Those PRN files were gathered
into another file, but their actual names (as usual for
Digital Research) are not written at the beginning of the
files.
So, at the moment, I only have FILE1.ASM, FILE2.ASM,
etc. But they assemble correctly with RMAC.
Finally, if there is a Unix freak out there, I should mention
that CP/NET is portable, that is to say: someone knowing
enough of CP/M, Unix, and transmission protocols COULD
write a C language program acting as a server of a Unix
system to a CP/M (-80 and -86) system acting as a "client".
Yours Sincerely,
"French Luser"
Richard Plinston
>
> Finally, if there is a Unix freak out there, I should mention
Maybe, but calling them 'freaks' will mean they just stop reading at
that point and call you a 'french fukwit'.
Bob Herlien
> Finally, if there is a Unix freak out there, I should mention
> that CP/NET is portable, that is to say: someone knowing
> enough of CP/M, Unix, and transmission protocols COULD
> write a C language program acting as a server of a Unix
> system to a CP/M (-80 and -86) system acting as a "client".
Portable, in the sense that the protocol is straightforward and at least
somewhat documented. But as you've found out, CP/Net-80 is in 8080
assembler,
so whoever wants to write a Unix server would have to rewrite the code
from scratch.
The CP/Net version for CDOS-86 (I forgot already what the name was,
possibly
just CP/Net-86), though, was written in C. It would be a better
starting point.
Although, as one of two authors of that product, I must warn that the C
code
was pretty ugly. We had to code around bugs in the C compiler, bugs in
the
Intel PIC chip for the sample NIOS, and interface the redirector to an
OS that
was written in assembly and hence didn't obey C calling conventions.
Some of
the comments we put in the code for these problems were hilarious.
I may have some documentation around for CP/Net-86. I probably still
have doc
for CP/M-68K, too, for which I was author of the BDOS and sample BIOS.
I used to have source code for both, but I threw out all my old 5.25"
disks
when modern systems stopped using them.
Bob Herlien
Arobase, Salle multimédia
"Bob Herlien" wrote:
> The CP/Net version for CDOS-86 (I forgot already what the name was,
> possibly just CP/Net-86), though, was written in C.
Even though I have never used Concurrent DOS, remembering some old
DRI advertisements, I think that its name was "DR Net".
Searching on the Internet, I found the following references:
DR Net Network Software:
----------------------------
User's Guide,
System Manager's Guide,
Programmer's Guide,
System Guide,
Model NIOS Description. 1984
Yours Sincerely,
"French Luser"
Arobase, Salle multimédia
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.