CP/Net - Please help

197 views
Skip to first unread message

Tadeusz Pycio

unread,
Oct 2, 2021, 2:59:11 PM10/2/21
to
Please help. Does anyone have access and can provide me with the contents of "CP/NET V1.2 Application Note #2" dated 11-11-82 or have a SERVER.RSP patch with a single queue?

Mr. Emmanuel Roche, France

unread,
Oct 2, 2021, 5:52:04 PM10/2/21
to
Tadeusz Pycio wrote:

> Please help. Does anyone have access and can provide me with the contents of "CP/NET V1.2 Application Note #2" dated 11-11-82 or have a SERVER.RSP patch with a single queue?

1) See below.

2) The CP/NET expert that I know is Hector Peraza. I suggest contacting him for any questions. (He has a "Github" page about the "P112" micro.)

Yours Sincerely,
Mr. Emmanuel Roche, France

CP/NET V1.2
Application Note 02, 11/11/82
Allowing CP/NET Servers to Use Bank-switched Technology

Copyright (C) 1982 by Digital Research
CP/NET is a registered trademark of Digital Research.
CP/NOS and MP/M-II are trademarks of Digital Research.
Compiled November 1982

(Retyped by Emmanuel ROCHE.)

Applicable Products and Version Numbers: CP/NET V1.2

Because of the size of the SERVER.RSP and NETWRKIF.RSP modules in a CP/NET or
CP/NOS server, MP/M-II servers usually have common memory requirements greater
than the amount of common memory available on the target computer. The CP/NET
user is limited to only 1 bank of the system, wasting any additional banks
which might be put to use running auxiliary processes.

This Application Note details how to customize the NETWRKIF module into a
small, Resident System Process portion (RSP), and a larger, Banked Resident
System Process portion (BRS). This note also provides a method for modifying
the object code of the SERVER.RSP module to create a banked-out version
consisting of 2 modules: SERVR0PR.RSP and SERVR0PR.BRS.

By reducing the size of the required RSP modules, common memory requirements
are sufficiently reduced, so that most MP/M-II systems running CP/NET
servers can take advantage of their additional memory banks. The remainder of
the server code resides in the system bank, below the common memory area.


Modifying the NETWRKIF
----------------------

The only sections of the server code that must reside in common memory are
Process Descriptors (PDs) and Queue Control Blocks (QPBs). A source module
must, therefore, be prepared containing the XDOS entry point, all the NTWRKIPx
Process Descriptors, all the NTWRKQIx Queue Control Blocks, and all the
NTWRKQOx Queue Control Blocks. Also, storage must be allocated for all SERVER
Process Descriptors greater than SERVR3PR. Process Descriptors SERVR1PR,
SERVR2PR, and SERVR3PR are set up by the modified SERVER code.

The Process Descriptor NTWRKIP0 must be allocated immediately after the XDOS
entry point for the module (for example, at relative location 2). Its memory
segment value should be 0, signifying that a BRS module is associated with it.

If any auxiliary process exists in the NETWRKIF, for example Watchdog
processes, their Process Descriptors must also be included in this module.

This source module should be assembled and linked into RSP format, following
the procedure in the "CP/NET Network Operating System Reference Manual". It
should be named NTWRKIP0.RSP.

The main body of the NETWRKIF source module should then be used to form a
second source module. All Process Descriptors and Queue Control Blocks should
be removed, and the following header should be placed at relative location 0:

RSP$ADR: DS 2
STK$ADR: DW NTWRKIS0+46
BRS$NAME: DB 'NTWRKIP0'

Notice that the starting stack address of a particular module may be different
if the implementation differs significantly from the example given in Appendix
E of the "CP/NET Network Operating System Reference Manual". This description
is merely the standard format for a BRS module. It is described in more detail
in the "MP/M-II System Guide".

Because the Process Descriptors and Queue Control Blocks are in a separate
RSP, they cannot be resolved as simple externals. They must be defined in
terms of known offsets from the beginning of NTWRKIP0.RSP. At run time, the
variable RSP$ADR contains a pointer to the beginning of this RSP. Using this
pointer and the predefined offsets, required references to these data objects
can be resolved.

The process NTWRKIP0 should, on start-up, perform the following
initialization:

1) The Stack Pointer field in Process Descriptors NTWRKIP1 through
NTWRKIPx should be initialized with a pointer to the top of the stack
associated with each process.

2) All user Queue Control Blocs should load a pointer to the actual QCBs
in their pointer fields. This process allows a subsequent Make Queue
function call to be performed properly.

3) The tops of the stacks associated with processes SERVR4PR through
SERVRxPR should be initialized to contain a pointer to their Process
Descriptors. The stacks for SERVR1PR, SERVR2PR, and SERVR3PR need not
be initialized because the process SERVR0PR makes those Process
Descriptors internal to the module SERVR0PR.RSP.

4) Space need not be allocated for Process Descriptors SERVR1PR,
SERVR2PR, and SERVR3PR, because SERVR0PR creates these Process
Descriptors internal to the module SERVR0PR.RSP.

This module requires a different way of referencing the operating system,
because it does not contain a pointer to the XDOS entry point. The RSP,
however, does contain such a pointer as its first 2 bytes. The following is an
example of a subroutine which transparently performs operating system calls:

DO$OS:
LHLD RSP$ADR
MOV A,M
INX H
MOV H,M
MOV L,A
PCHL

This module must also be assembled and linked into RSP format, but it should
be named NTWRKIP0.BRS.


Modifying the Server
--------------------

The following patch uses the object code in SERVER.RSP to produce 2 files,
SERVR0PR.RSP and SERV0PR.BRS, that can be run in a Banked MP/M system:

0A>ddt server.rsp
[MP/M II] DDT VERS 2.0
NEXT PC
0D00 0100
-S0101
0101 57 36
0102 09 0
0103 00 .
-S0211
0211 FF 0
021200 .
-F0236,023C,0
-Iservr0pr.rsp
-W3
-Iserver.rsp
-R
NEXT PC
0D00 0100
-S0202
0202 00 5C
0203 00 00
0204 00 53
0205 64 45
0206 5C 52
0207 00 56
0208 53 52
0209 45 30
020A 52 50
020B 56 52
020C D2 .
-B0107,0
-B0103,1
-A0470
0479 jmp c
047C .
-A020C
020C lhld 0
020F mov a,m
0210 inx h
0211 mov h,m
0212 mov l,a
0213 pchl
0214 .
-B010E,1
-A04AF
04AF jmp c
04B2 .
-A04BD
04BD jmp c
04C0 .
-A0AEB
0AEB jmp 14
0AEE pop h
0AEF .
-A0214
0214 push h
0215 lhld 0
0218 lxi d,54
021B dad d
021C xchg
021D jmp 8EE
0220 .
-B09ED,1
-B0117,1
-B011F,1
-A0AF5
0AF5 cpi 5
0AF7 jmp 20
0AFA xchg
0AFB .
-A0220
0220 jc 27
0223 mov e,m
0224 inx h
0225 mov d,m
0226 dcx h
0227 push h
0228 push d
0229 lhld0
022C inx h
022D inx h
022E jmp 8FA
0231 .
-B09FA,0
-B09F9,1
-B0122,1
-B012B,1
-B0130,1
-Iservr0pr.brs
-W18
-G0
0A>


System Generation and Performance Issues
----------------------------------------

GENSYS should be performed with a banked system specified. Additional memory
segments can be added to occupy the new banks. Their address ranges are
prompted at the end of GENSYS.

When RSPs are selected, do not use NETWRKIF.RSP and SERVER.RSP. Use the
NTWRKIP0.RSP and SERVR0PR.RSP modules just created.

The following table details the combined size and the common memory
requirements of the 2 new RSPs for various numbers of requesters, assuming 2
Queue Control Blocks per requester, as in the example in Appendix E of the
"CP/NET Network Operating System Reference Manual".

Table 1. Size and Memory Requirements

Number of Pages required Pages required
requesters with no watchdog with one watchdog
---------- ---------------- -----------------
1 2 2
2 2 3
3 3 3
4 3 3
5 4 4
6 4 4
7 4 5
8 5 5
9 5 5
10 6 6
11 6 6
12 6 7
13 7 7
14 7 7
15 8 8
16 8 8

If the number of supported requesters requires more common memory than is
available, using the banked version of the server gains nothing. It is
possible to reduce the requirements listed in the table by implementing a
system that uses a single network interface process to feed all of the server
processes. This process is detailed in "CP/NET V1.2 Application Note 01".

A banked-out server has a marginally slower response time, because the
dispatcher must select the system bank, and the added level of indirection in
calling the operating system. This degradation should be insignificant.

Although banking out the server provides additional user segments under MP/M-
II, the temptation to add additional consoles to the system should be avoided.
Performance on any such additional consoles is very poor because of the high
priority at which the server runs. However, these extra banks provide the user
with a means of performing occasional jobs directly from the MP/M level.

Extra segments can enhance the server. Using alternate formats with CP/NET
messages, the user can implement additional dedicated print servers, gather
statistics on network performance, implement sophisticated electronic mail
systems, etc. Such enhancements can greatly improve the quality of the overall
CP/NET environment.


Licensed users are granted the right to include these modifications in CP/NET
software.


EOF

Tadeusz Pycio

unread,
Oct 3, 2021, 7:43:17 AM10/3/21
to
Many thanks for sharing. The document wasn't the one I was looking for (the documentation referred to it incorrectly), but it's worth reading and leaving for others. My search is still ongoing as the information in APN2 takes me to Application Note #1 , so if anyone has access to this document please share it.
I am currently looking for Application Note #1 :(

Mr. Emmanuel Roche, France

unread,
Oct 3, 2021, 9:15:22 AM10/3/21
to
Tadeusz Pycio wrote:

> I am currently looking for Application Note #1

See below.

Yours Sincerely,
Mr. Emmanuel Roche, France

CP/NET V1.2
Application Note 01, 11/11/82
Writing Improved NETWRKIF Modules for CP/NET

Copyright (C) 1982 by Digital Research
CP/NET is a registered trademark of Digital Research.
MP/M-II is a trademark of Digital Research.
Compiled November 1982

(Retyped by Emmanuel ROCHE.)

Applicable Products and Version Numbers: CP/NET V1.2

Use a small patch to the SERVER.RSP module to write a NETWRKIF module that has
marked space and performance efficiencies.

The patch causes all of the SERVER processes to write their output to the same
queue, NtwrkQ00:

0A>pip server.sav=server.rsp
0A>ddt server.rsp
[MP/M II] DDT VERS 2.0
NEXT PC
0D00 0100
-A0543
0543 mvi a,30
0545 jmp 34F
0548 .
-Iserver.rsp
-W18
-G0
0A>

The patched SERVER.RSP must now be GENSYSed into MP/M-II.

With this patch installed, a server architecture is possible that requires
only 2 non-reentrant NETWRKIF processes: one queue to the output NETWRKIF
process, and one input queue for every server process on the host computer.
The relationship between queues and processes is shown in the following
figure.

********** +----------+
+--->* NtwrkQI0 *--->| SERVR0PR |--->+
| ********** +----------+ |
| |
+----------+ ********** +----------+ |
| NTWRKIN |--->* NtwrkQI1 *--->| SERVR1PR |--->+
+----------+ ********** +----------+ |
| |
| ********** +----------+ |
+--->* NtwrkQI2 *--->| SERVR2PR |--->+
********** +----------+ |
|
+----------+ |
| NTWRKOUT | ... ... |
+----------+ |
^ |
| |
********** |
* NtwrkQO0 * ... ... |
********** |
^ |
| |
+----------------------<-------------------+

Figure 1. Server architecture

The process NTWRKIN handles all network input and routes messages from the
network interface to the appropriate server process through an input queue.
The process NTWRKOUT reads the single output queue and sends a response
message back out over the network.

Minimizing the number of Process Descriptors (PD) and queues improves MP/M-II
dispatch time, because the process and queue threads are shorter and take less
time to traverse. Less common memory is required, because fewer Process
Descriptors and Queue Control Block (QCB) are needed.

Enough buffer space must be allocated to the output queue, so that a pointer
to a message from every server process in the system can be written
simultaneously, or the NETWRKIF module can limit the number of messages being
worked on at any one time, and size the queue buffer accordingly. This process
involves a small amount of buffer management analogous to the MX queue
demonstrated in Appendix E of the "CP/NET Network Operating System Reference
Manual".

This type of server architecture is demonstrate by the example programs in
Appendices F and G.

Tadeusz Pycio

unread,
Oct 3, 2021, 12:06:07 PM10/3/21
to
Hi Emmanuel,

Thank you so much, this is what I was looking for. You are truly a wealth of knowledge. Do you have any more documents not available on the Web? I searched for them for two days without success.

Thanks and Have a great day!
Tadeusz Pycio

Mr. Emmanuel Roche, France

unread,
Oct 3, 2021, 1:49:40 PM10/3/21
to
Tadeusz Pycio wrote:

> Thank you so much, this is what I was looking for. You are truly a wealth of knowledge. Do you have any more documents not available on the Web? I searched for them for two days without success.

See below.

Yours Sincerely,
Mr. Emmanuel Roche, France

CP/NET V1.2
Application Note 03, 11/11/82
Changing the CP/NET and CP/NOS Version Number

Copyright (C) 1982 by Digital Research
CP/M and CP/NET are registered trademarks of Digital Research.
CB-80, CP/M Plus, CP/NOS, MP/M and MP/M-II
are trademarks of Digital Research.
Compiled November 1982

(Retyped by Emmanuel ROCHE.)

Applicable Products and Version Numbers: CP/NET V1.2

Function 12, Return Version Number, returns a 2-byte value in register HL. The
low-order byte contains the release number. This number is set to 22
hexadecimal if CP/NET is running under CP/M Version 2.2. The high-order byte
specifies the operating system type: 0=CP/M, 1=MP/M-II, and 2=CP/NET or
CP/NOS.

Many application programs specifically check to ensure that they are running
under either CP/M or MP/M-II. They might fail when run under CP/NET or CP/NOS.
Another problem arises when applications check the release number before
performing certain shared file operations. For example, CB-80 requires a
hexadecimal 30 or greater in the release number before opening a file in
shared mode.

The following patch causes Function 12 to return any desired version number
when the NDOS has been loaded for CP/NET operations.

A>ren ndos.sav=ndos.spr
A>ddt ndos.spr
DDT VERS 2.2
NEXT PC
0F80 0100
-A0AC0
0AC0 lxi h,(version number)
0AC3 nop
0AC4 .
-G0
A>save 15 ndos.spr

where (version number) is an hexadecimal value, chosen to support a desired
application:

0022 makes the system look like unmodified CP/M 2.2
0130 makes the system look like MP/M-II
0230 CP/NET, but with a version number that allows
CB-80 to run using shared files.

This same patch can be applied to CP/NOS. Link CP/NOS as you would to produce
a COM file. The patch is made to the COM file before converting it to ROM, or
to a form that you can download.

A>ren cpnos.sav=cpnos.com
A>ddt cpnos.com
DDT VERS 2.2
NEXT PC
0F80 0100
-A082E
082E lxi h,(version number)
082F nop
0830 .
-G0
A>save xx cpnos.com

The size of the COM file depends on the size of your CPNIOS and CPBIOS
modules. Save the correct number of pages after performing the patch.

Because this patch makes the CP/NET or CP/NOS system have the same version
number as a CP/M system, applications that specifically check for a CP/NET
system might now function improperly. Applications that require the system to
look like MP/M-II might not work when the system is configured to look like
CP/M. All CP/NET utilities check to make sure that the operating system type
is set to 2, for CP/NET. It might be useful to write a set of programs that
dynamically perform the patching process. This allows a user to invoke the
appropriate version number before running an application.

When running either CP/NET or CP/NOS with a version number of 30 or greater,
make sure that the application makes no calls to MP/M-II or CP/M Plus
functions not supported by CP/NET. Examples of such functions are queue
handling calls, attach and detach functions, multisector I/O, and memory
management. Invoking such functions results in a program error.

Tadeusz Pycio

unread,
Oct 6, 2021, 3:17:19 PM10/6/21
to
Hi Emmanuel,
Your documentation resources enabled me to take the next step, I've already modified SEVRER.SPR module (APN #1) and written NETWRKIF.RSP using one output queue. I still need to refine the Arcnet protocol matching to CP/Net and I'll be enjoying a computer network from the 80's. The end of my work is slowly appearing. Thanks again.

Tadeusz Pycio

unread,
Nov 16, 2021, 6:18:45 PM11/16/21
to
The result of my work (almost) completed thanks to the information I have received here.
https://www.youtube.com/watch?v=b__bgcLBE9c
Reply all
Reply to author
Forward
0 new messages