seppdroid/Digital-Research-Source-Code
1
0
Fork 0
mirror of https://github.com/SEPPDROID/Digital-Research-Source-Code.git synced 2025-12-11 15:53:01 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Upload

Browse Source 
Digital Research
This commit is contained in:
Sepp J Morris
2020-11-06 18:50:37 +01:00
parent 621ed8ccaf
commit 31738079c4
8481 changed files with 1888323 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

59
MPM OPERATING SYSTEMS/MPM I/MPM I SOURCE/14/apnote01.tex Normal file
View File

@@ -0,0 +1,59 @@
D I G I T A L R E S E A R C H
P. O. Box 579, Pacific Grove, CA 93950, (408) 649-3896
*** MP/M 1.0 ***
Application Note #01
Integrating a custom LDRBIOS into MPMLDR.COM
--------------------------------------------
The MP/M 1.0 loader resides in a file named MPMLDR.COM. This
loader contains a BIOS called the LDRBIOS org'd at 1700H. MP/M is
distributed with an MPMLDR.COM that is configured for a four drive
single density or mixed double/single Intel MDS-800. This MPMLDR.COM
can be configured for a different hardware environment by coding
a LDRBIOS as described in section 3.1 of the "MP/M User's Guide".
The following steps can be used to integrate a custom LDRBIOS
into the MPMLDR.COM:
1.) Obtain access to CP/M version 1.4 or 2.0 and prepare the
LDRBIOS.HEX file.
2.) Read the MPMLDR.COM file into memory using either DDT
or SID.
A>DDT MPMLDR.COM
DDT VERS 2.0
NEXT PC
1A00 0100
3.) Using the input command ('I') specify that the LDRBIOS.HEX
file is to be read in and then read ('R') in the file. The effect
of this operation is to overlay the BIOS portion of the MP/M
loader.
-ILDRBIOS.HEX
-R
NEXT PC
1A00 0000
4.) Return to the CP/M console command processor (CCP) by
executing a jump to location zero.
-G0
5.) Write the updated memory image onto a disk file using
the CP/M 'SAVE' command. The 'X' placed in front of the file
name is used simply to designate an experimental version, preserving
the orginal.
A>SAVE 26 XMPMLDR.COM
6.) Test XMPMLDR.COM and then rename it to MPMLDR.COM.


83
MPM OPERATING SYSTEMS/MPM I/MPM I SOURCE/14/apnote02.tex Normal file
View File

@@ -0,0 +1,83 @@
D I G I T A L R E S E A R C H
P. O. Box 579, Pacific Grove, CA 93950, (408) 649-3896
*** MP/M 1.0 ***
Application Note #02
Preparing a Custom Cold Start Loader
------------------------------------
The MP/M 1.0 cold start loader is usually placed on the first
two tracks of a diskette. It contains a boot program followed by
the MP/M loader. The MP/M loader is the same exact code as the
MPMLDR.COM file. MP/M is distributed with a cold start loader that
is configured for a four drive single density or mixed double/single
density Intel MDS-800.
The following steps can be used to prepare a custom cold start
loader:
1.) Prepare the MPMLDR.COM file by integrating your custom
LDRBIOS as described in Application Note #01. Test the MPMLDR.COM
and verify that it operates properly.
2.) Execute either DDT or SID.
A>DDT
DDT VERS 2.0
3.) Using the input command ('I') specify that the MPMLDR.COM
file is to be read in and then read ('R') in the file with an
offset of 880H bytes.
-IMPMLDR.COM
-R880
NEXT PC
2480 0100
4.) Using the 'I' command specify that the BOOT.HEX file is to
be read in and then read in the file with an offset that will load
the boot into memory at 900H. The 'H' command can be used to
calculate the offset.
-H900 3000
3900 D900
-IBOOT.HEX
-RD900
NEXT PC
2480 0000
MP/M 1.0 Application Note #02 (Cont'd)
5.) Return to the CP/M console command processor (CCP) by
jumping to location zero and then use the SYSGEN program to write
the new cold start loader onto the first two tracks of the diskette.
-G0
6.) Use the SYSGEN program to write the new cold start loader
onto the first two tracks of the diskette.
A>SYSGEN
SYSGEN VER 2.0
SOURCE DRIVE NAME (OR RETURN TO SKIP)<cr>
DESTINATION DRIVE NAME (OR RETURN TO REBOOT)B
DESTINATION ON B, THEN TYPE RETURN<cr>
FUNCTION COMPLETE


38
MPM OPERATING SYSTEMS/MPM I/MPM I SOURCE/14/apnote03.tex Normal file
View File

@@ -0,0 +1,38 @@
D I G I T A L R E S E A R C H
P. O. Box 579, Pacific Grove, CA 93950, (408) 649-3896
*** MP/M 1.0 ***
Application Note #03
Suppressing the MP/M Loader Display
-----------------------------------
When the MP/M 1.0 loader reads in and relocates the MPM.SYS
file, a load map is diplayed on console #0. In some applications
it may be desirable to suppress this display.
The MP/M loader display can be suppressed as follows:
1.) Edit the LDRBIOS.ASM file, replacing the console output
code with a RET instruction.
;Loader BIOS jump vector
...
jmp conout
...
conout:
ret
2.) Follow the steps provided in Application Note #01 to
integrate the new LDRBIOS into the MPMLDR.COM file.
3.) Follow the steps provided in Application Note #02 to
update the cold start loader with the new MPMLDR.COM file.


54
MPM OPERATING SYSTEMS/MPM I/MPM I SOURCE/14/apnote04.tex Normal file
View File

@@ -0,0 +1,54 @@
D I G I T A L R E S E A R C H
P. O. Box 579, Pacific Grove, CA 93950, (408) 649-3896
*** MP/M 1.0 ***
Application Note #04
Customizing the MP/M Sign-on Message
------------------------------------
The MP/M 1.0 sign-on message can be customized to include an
ASCII string of your choice which is up to 35 characters. The
string must be terminated with an ASCII '$' character.
The following steps can be used to customize the MP/M sign-on
message:
1.) Obtain access to CP/M version 1.4 or 2.0.
2.) Read the XDOS.SPR file into memory using either DDT
or SID.
A>SID XDOS.SPR
SID VERS 2.0
NEXT PC
2600 0100
3.) Store your customized sign-on message beginning at
location 022AH. Note that the message should probably begin
with some <cr> and <lf>'s and that it must be terminate with
a '$' character.
-S22A
022A -- 0D
022B -- 0A
022C -- "New sign-on message$
0240 -- .
4.) Return to the CP/M console command processor (CCP) by
executing a jump to location zero and then save the updated
memory image onto a disk file using the CP/M 'SAVE' command.
-G0
A>SAVE 37 XDOS.SPR ; 37 = 25H
5.) Run the GENSYS program which will integrate the new
XDOS.SPR into the MPM.SYS file.


115
MPM OPERATING SYSTEMS/MPM I/MPM I SOURCE/14/apnote05.tex Normal file
View File

@@ -0,0 +1,115 @@
D I G I T A L R E S E A R C H
P. O. Box 579, Pacific Grove, CA 93950, (408) 649-3896
*** MP/M 1.0 ***
Application Note #05
Debugging an XIOS or a Resident System Process
----------------------------------------------
An XIOS or a resident system process can be debugged using
DDT or SID running under CP/M 1.4 or 2.0. The debugging
technique is outlined in the following steps:
1.) Using GENSYS running under either CP/M or MP/M generate
a MPM.SYS file which specifies the top of memory as 'C0'H.
...
Top page of memory = C0
...
Also while executing GENSYS specify the breakpoint
restart number as that used by the CP/M SID or DDT which you
will be executing. This restart is usually #7.
...
Breakpoint RST # = 7
...
2.) If a resident system process is being debugged make
certain that it is selected for inclusion in MPM.SYS.
3.) Using CP/M 1.4 or 2.0, load the MPMLDR.COM file into
memory.
A>DDT MPMLDR.COM
DDT VERS 2.0
NEXT PC
1A00 0100
4.) Place a 'B' character into the second position of
default FCB. This operation can be done with the 'I' command:
-IB
5.) Execute the MPMLDR.COM program by entering a 'G'
command:
-G
6.) At point the MP/M loader will load the MP/M operating
system into memory, displaying a memory map.
MP/M 1.0 Application Note #05 (Cont'd)
7.) If you are debugging an XIOS, note the address of the
XIOS.SPR memory segment. If you are debugging a resident system
process, note the address of the resident system process. This
address is the relative 0000H address of the code being debugged.
You must also note the address of SYSTEM.DAT.
8.) Using the 'S' command, set the byte at SYSTEM.DAT + 2
to the restart number which you want the MP/M debugger to use.
Do not select the same restart as that being used by the CP/M
debugger.
...
Memory Segment Table:
SYSTEM DAT C000H 0100H
...
-SC002
C002 07 05
9.) Using the 'X' command, determine the MP/M beginning
execution address. The address is the first location past
the current program counter.
-X
....................... P = 08CD .....
10.) Begin execution of MP/M using the 'G' command, specifying
any breakpoints which you need in your code. Actual memory address
can be determined using the 'H' command to add the code segment
base address given in the memory map to the relative displacement
address in your XIOS or resident system process listing.
The following example shows how to set a breakpoint to
debug an XIOS list subroutine:
Given the following memory map-
XIOS SPR B800H 0500H
Begin MP/M execution with the following breakpoint-
-G8CE,B80F
11.) At this point you have MP/M running with CP/M and its
debugger also in memory. Since interrupts are left enabled during
operation of the CP/M debugger when a breakpoint is reached, care
must be taken to ensure that interrupt driven code does not
execute through the point at which you have broken.


2
MPM OPERATING SYSTEMS/MPM I/MPM I SOURCE/14/break.tex Normal file
View File

@@ -0,0 +1,2 @@
.BR


64
MPM OPERATING SYSTEMS/MPM I/MPM I SOURCE/14/coverltr.tex Normal file
View File

@@ -0,0 +1,64 @@
.mt 0
.mb 0
.op
Dear MP/M user:
Digita<EFBFBD><EFBFBD> Researc<72><63> ha<68><61> develope<70> th<74> MP/͠ operatin<69><6E> syste<74><65> i<> <20>
respons<EFBFBD> t<> numerou<6F> custome<6D> requests<74><73> Th<54> desig<69> o<> MP/<2F> i<> <20> <20>
reflectio<EFBFBD><EFBFBD> o<><6F>ou<6F><75> goa<6F> t<> provid<69> yo<79> wit<69> <20> stat<61> o<><6F> th<74><68> ar<61> <20>
operatin<EFBFBD> syste<74> whic<69> i<> easil<69> configure<72> fo<66> <20> wid<69> variet<65><74>o<EFBFBD> <20>
compute<EFBFBD> hardware.
Thi<EFBFBD> shipmen<65> contain<69> th<74> second releas<61> o<> ou<6F> MP/<2F> system<65><6D> We <20>
hav<EFBFBD><EFBFBD> bee<65><65> please<73> wit<69> th<74> respons<6E> w<> hav<61> ha<68><61> t<><74> th<74><68> firs<72> <20>
releas<EFBFBD><EFBFBD> o<> MP/<2F> an<61> hav<61> mad<61> som<6F> significan<61> improvement<6E><74> an<61> <20>
correcte<EFBFBD> th<74> know<6F> bugs<67><73> W<> ar<61> concerne<6E> tha<68> w<> receiv<69> you<6F> <20>
feedbac<EFBFBD> regardin<69> it<69> design<67> possibl<62> extensions<6E> an<61> error<6F> i<> <20>
implementatio<EFBFBD> s<> tha<68> w<> ca<63> attai<61> th<74> sam<61> leve<76> o<> confidenc<6E> <20>
tha<EFBFBD> th<74> compute<74> industr<74> ha<68> i<> ou<6F> CP/<2F> operatin<69> system.
Th<EFBFBD><EFBFBD> standar<61> MP/<2F> releas<61> i<> configure<72> fo<66> th<74><68> Inte<74><65> MDS-800<30> <20>
Thi<EFBFBD><EFBFBD> configuratio<69><6F> provide<64><65> <20><> goo<6F><6F> vehicl<63><6C> fo<66><6F> preliminar<61> <20>
evaluatio<EFBFBD> o<> MP/<2F> a<> wel<65> a<> t<> serv<72> a<> <20> simpl<70> exampl<70> o<> th<74> <20>
require<EFBFBD> hardwar<61> dependen<65> software<72><65> I<> <20> practica<63> sense<73> th<74> <20>
MDS-80<38><30> itsel<65><6C> i<> no<6E> wel<65> suite<74> fo<66> MP/<2F> application<6F><6E> fo<66><6F> <20> <20>
numbe<EFBFBD> o<> reasons<6E><73> Th<54> MDS-80<38> i<> relativel<65> slo<6C> (<28> Mhz)<29><> th<74> <20>
secon<EFBFBD><EFBFBD> seria<69> por<6F> i<> 11<31> bau<61> curren<65> loop<6F><70> an<61> th<74> tim<69><6D> bas<61> <20>
produce<EFBFBD><EFBFBD> interrupt<70> a<> <20> rat<61> o<> 1.02<EFBFBD> Kh<4B> whic<69> require<72> <20> goo<6F> <20>
dea<EFBFBD> o<> overhea<65> becaus<75> interrupt<70> mus<75> b<> divide<64> dow<6F> fo<66><6F> us<75> <20>
a<EFBFBD> <20> tim<69> o<> da<64> clock.
O<EFBFBD><EFBFBD> th<74><68> basi<73> o<> ou<6F> experienc<6E> an<61> th<74> experienc<6E><63> o<><6F> numerou<6F> <20>
MP/<2F> 1.<2E> users<72> w<> estimat<61> tha<68> i<> require<72> abou<6F> <20> t<> <20> day<61> t<> <20>
implemen<EFBFBD> <20> simpl<70> polle<6C> MP/<2F> o<> <20> compute<74> whic<69> ha<68> <20><> runnin<69> <20>
versio<EFBFBD> o<> CP/<2F> releas<61> 2<><32> T<> implemen<65> <20> highl<68> optimize<7A> MP/<2F> <20>
syste<EFBFBD><EFBFBD> wit<69> ful<75> interrupt<70> an<61> ban<61> switche<68> memor<6F> ca<63> requir<69> <20>
<EFBFBD><EFBFBD> t<><74> <20><> weeks<6B><73><EFBFBD> O<><4F> course<73><65><EFBFBD> th<74><68> tim<69><6D> t<><74> perfor<6F><72> suc<75><63> <20> <20>
reconfiguratio<EFBFBD><EFBFBD> wil<69> var<61> widel<65> dependin<69> o<> th<74> experienc<6E><63> o<> <20>
th<EFBFBD><EFBFBD> programme<6D> an<61> th<74> complexit<69> o<> th<74> hardwar<61> o<> th<74><68> targe<67> <20>
computer<EFBFBD><EFBFBD> Fee<65><65> fre<72> t<> contac<61> th<74> Digita<74> Researc<72><63> technica<63> <20>
suppor<EFBFBD> staff<66><66> (408<30> 375-6262<36> i<> yo<79> experienc<6E> difficultie<69> i<> <20>
reconfigurin<EFBFBD> MP/M.
A<EFBFBD><EFBFBD> shippe<70><65> MP/<2F> i<> configure<72> fo<66> tw<74><77> terminals<6C><73> al<61><6C> o<><6F> th<74> <20>
optiona<EFBFBD><EFBFBD> residen<65> syste<74> processes<65><73> an<61> thre<72> memor<6F><72> segments<74> <20>
Thi<EFBFBD> configuratio<69> i<> easil<69> change<67> wit<69> th<74> GENSY<53> program.
Th<EFBFBD><EFBFBD> MP/<2F> diskett<74> i<> singl<67> densit<69> an<61> ha<68> th<74> MP/͠ boot<6F><74> I<> <20>
yo<EFBFBD> hav<61> <20> doubl<62> densit<69> MDS-80<38> i<> i<> <20> relativel<65> eas<61> tas<61> t<> <20>
chang<EFBFBD><EFBFBD> fro<72><6F> th<74> fou<6F> driv<69> singl<67> densit<69> XIO<49> t<> <20> fou<6F><75> driv<69> <20>
mixe<EFBFBD><EFBFBD> single/doubl<62> densit<69> XIOS<4F><53> Th<54> XIOS.AS͠ fil<69><6C> contain<69> <20>
equate<EFBFBD> whic<69> ar<61> use<73> t<> specif<69> th<74> driv<69> densit<69> an<61> assemble<6C> <20>
bein<EFBFBD> used.
B<EFBFBD><EFBFBD> sendin<69> i<> you<6F> registratio<69> car<61> yo<79> ca<63> insur<75> tha<68> w<> wil<69> <20>
mai<EFBFBD><EFBFBD> yo<79><6F> MP/͠ applicatio<69> note<74> an<61><6E> an<61><6E> patche<68><65> t<><74> correc<65> <20>
implementatio<EFBFBD><EFBFBD> errors<72>
Digital Research
Technical Support Staff


196
MPM OPERATING SYSTEMS/MPM I/MPM I SOURCE/14/cpnet.tex Normal file
View File

@@ -0,0 +1,196 @@
.op
CP/NET 1.0
A Control Program
for
Microcomputer Networks
FUNCTIONAL SPECIFICATION
18 February 1980
****************
* CONFIDENTIAL *
****************
Copyright (C) 1980
Digital Research
<EFBFBD>
Table of Contents
1.0 PRODUCT IDENTIFICATION
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . 1
2.0 PRODUCT RATIONALE
2.1 Design Objectives . . . . . . . . . . . . . . . . . 2
2.2 Competitive Analysys . . . . . . . . . . . . . . . . 2
3.0 SYSTEM REQUIREMENTS
3.1 Hardware Environment . . . . . . . . . . . . . . . . 3
4.0 PERFORMANCE OBJECTIVES . . . . . . . . . . . . . . . . . 4
4.1 Memory Size . . . . . . . . . . . . . . . . . . . . 4
4.2 Speed . . . . . . . . . . . . . . . . . . . . . . . x
4.3 Reliability and Maintainability . . . . . . . . . . x
5.0 DOCUMENTATION
5.1 External and End User . . . . . . . . . . . . . . . x
5.2 Internal and OEM . . . . . . . . . . . . . . . . . . x
6.0 DESCRIPTION OF FEATURES
6.1 MP/M Master . . . . . . . . . . . . . . . . . . . . x
6.1.1 Resident System Process . . . . . . . . . . . x
6.2 CP/M Slave . . . . . . . . . . . . . . . . . . . . . x
6.2.1 Network Basic I/O System (NBIOS) . . . . . . x
6.2.2 Network Basic Disk Operating System (NBDOS) . x
6.3 MP/M Slave . . . . . . . . . . . . . . . . . . . . . x
6.3.1 Network Extended I/O System (NXIOS) . . . . . x
6.4 Inter-Processor Message Format . . . . . . . . . . . x
<EFBFBD>.pn
.he CP/NET 1.0 Functional Specification Section 1.0
1.0 PRODUCT IDENTIFICATION
Name: Control Program for microcomputer networks
Mnemonic: CP/NET 1.0
1.1 Overview
<EFBFBD><EFBFBD><EFBFBD>Th<EFBFBD> purpos<6F> o<> <20> contro<72> progra<72> fo<66> microcompute<74> network<72> i<> <20>
<EFBFBD><EFBFBD><EFBFBD>t<EFBFBD><EFBFBD> enabl<62><6C> multipl<70> microcomputer<65> t<> shar<61> commo<6D><6F> resource<63> <20>
<EFBFBD><EFBFBD><EFBFBD>and to provide a mechanism for inter-processor communication.
<EFBFBD><EFBFBD><EFBFBD>CP/NEԠ wil<69><6C> b<><62> designe<6E> t<> operat<61><74> i<><69> multipl<70><6C> processo<73> <20>
<EFBFBD><EFBFBD><EFBFBD>environment<EFBFBD><EFBFBD> whic<69><63> rang<6E><67> fro<72> tightl<74><6C> t<><74> loosel<65><6C> couple<6C> <20>
<EFBFBD><EFBFBD><EFBFBD>processors.
<EFBFBD><EFBFBD><EFBFBD>A<EFBFBD><EFBFBD> th<74><68> use<73><65> leve<76> CP/NE<4E> wil<69> provid<69> <20><> virtua<75><61> CP/͠ 2.<2E> <20>
<EFBFBD><EFBFBD><EFBFBD>syste<EFBFBD> t<> eac<61> CP/<2F> slav<61> processor<6F> Th<54> CP/<2F> slav<61> processo<73> <20>
<EFBFBD><EFBFBD><EFBFBD>coul<EFBFBD> consis<69> o<> simpl<70> <20> processor<6F><72> memory<72> an<61> a<> interfac<61> <20>
<EFBFBD><EFBFBD><EFBFBD>t<EFBFBD> th<74> network<72> Thus<75> <20> CR<43> wit<69> sufficien<65> RA<52> coul<75> execut<75> <20>
<EFBFBD><EFBFBD><EFBFBD>CP/͠<> programs<6D><73><EFBFBD> performin<69><6E> it<69><74> computin<69><6E> locall<6C><6C><EFBFBD> whil<69> <20>
<EFBFBD><EFBFBD><EFBFBD>dependin<EFBFBD><EFBFBD> o<> th<74> networ<6F> t<> provid<69> al<61> dis<69> an<61> printe<74><65> I/<2F> <20>
<EFBFBD><EFBFBD><EFBFBD>facilities.
.pa
<EFBFBD>.he CP/NET 1.0 Functional Specification Section 2.0
2.0 PRODUCT RATIONALE
2.1 Design Objectives
2.2 Competitive Analysys
.pa
<EFBFBD>.he CP/NET 1.0 Functional Specification Section 3.0
3.0 SYSTEM REQUIREMENTS
3.1 Hardware Environment
<EFBFBD><EFBFBD><EFBFBD>Th<EFBFBD><EFBFBD> harwar<61><72> environmen<65> fo<66> CP/NE<4E> 1.<2E> mus<75> includ<75><64> tw<74><77> o<> <20>
<EFBFBD><EFBFBD><EFBFBD>mor<EFBFBD><EFBFBD> 8080<38><30> 8085<38><35> o<> Z8<5A> processor<6F> whic<69> hav<61> som<6F> mean<61><6E> o<> <20>
<EFBFBD><EFBFBD><EFBFBD>inter-processor communication.
.pa
<EFBFBD>.he CP/NET 1.0 Functional Specification Section 4.0
4.0 PERFORMANCE OBJECTIVES
4.1 Memory Size
4.2 Speed
4.3 Reliability and Maintenance
.pa
<EFBFBD>.he CP/NET 1.0 Functional Specification Section 5.0
5.0 DOCUMENTATION
5.1 External and End User
5.2 Internal and OEM
.pa
<EFBFBD>.he CP/NET 1.0 Functional Specification Section 6.1
6.0 DESCRIPTION OF FEATURES
6.1 MP/M Master
6.1.1 Resident System Process
.pa
<EFBFBD>.he CP/NET 1.0 Functional Specification Section 6.2
6.2 CP/M Slave
6.2.1 Network Basic I/O System (NBIOS)
6.2.2 Network Basic Disk Operating System (NBDOS)
.pa

165
MPM OPERATING SYSTEMS/MPM I/MPM I SOURCE/14/mpmug0.tex Normal file
View File

@@ -0,0 +1,165 @@
.MB +5
.MT -3
.LL 65
.BP
.OP
.NA
.SP 7
.CE
MP/M
.SP 4
.CE
Multi-Programming Monitor Control Program
.SP 4
.CE
USER'S GUIDE
.SP 9
.BP
.AD
.SP 4
.IN 6
.LL -6
.CE
COPYRIGHT
.SP 1
Copyright (c) 1979, 1980 by Digital Research. All rights
reserved. No part of this publication may be reproduced,
transmitted, transcribed, stored in a retrieval system, or
translated into any language or computer language, in any
form or by any means, electronic, mechanical, magnetic,
optical, chemical, manual or otherwise, without the prior
written permission of Digital Research, Post Office Box 579,
Pacific Grove, California 93950.
.SP
This manual is, however, tutorial in nature . Thus, permission
is granted to reproduce or abstract the example programs shown
in enclosed figures for the purposes of inclusion within the
reader's programs.
.SP
.CE
DISCLAIMER
.SP
Digital Research makes no representations or warranties with
respect to the contents hereof and specifically disclaims any
implied warranties of merchantability or fitness for any
particular purpose. Further, Digital Research reserves the
right to revise this publication and to make changes from
time to time in the content hereof without obligation of
Digital Research to notify any person of such revision or
changes.
.SP 1
.CE
TRADEMARKS
.SP 1
CP/M is a registered trademark of Digital Research. MP/M, MAC,
and SID are trademarks of Digital Research.
.sp 4
The "MP/M User's Guide" was prepared using the Digital Research
TEX text formatter.
.sp 3
.ce
**************************************
.ce
* Second Printing: February, 1980 *
.ce
**************************************
.QI
.LL +6
.HE MP/M User's Guide
.BP
.CE
Table of Contents
.LI
1. MP/M Features and Facilities . . . . . . . . . . . . . . 1
1.1 Introduction . . . . . . . . . . . . . . . . . . . 1
1.2 Functional Description of MP/M . . . . . . . . . . 3
1.3 Console Commands . . . . . . . . . . . . . . . . . 4
1.4 Commonly Used System Programs . . . . . . . . . . 8
1.5 Standard Resident System Processes . . . . . . . . 13
2. MP/M Interface Guide . . . . . . . . . . . . . . . . . . 17
2.1 Introduction . . . . . . . . . . . . . . . . . . . 17
2.2 Basic Disk Operating System Functions . . . . . . 29
2.3 Queue and Process Descriptor Data Structures . . . 53
2.4 Extended Disk Operating System Functions . . . . . 62
2.5 Preparation of Page Relocatable Programs . . . . . 81
2.6 Installation of Resident System Processes . . . . 83
3. MP/M Alteration Guide . . . . . . . . . . . . . . . . . 85
3.1 Introduction . . . . . . . . . . . . . . . . . . . 85
3.2 Basic I/O System Entry Points . . . . . . . . . . 96
3.3 Extended I/O System Entry Points . . . . . . . . 102
3.4 System File Components . . . . . . . . . . . . . 107
3.5 System Generation . . . . . . . . . . . . . . . 110
3.6 MP/M Loader . . . . . . . . . . . . . . . . . . 114
.BP
.SP 2
.CE
Appendix
.SP 2
.LI
A. Flag Assignments . . . . . . . . . . . . . . . . . 116
B. Process Priority Assignments . . . . . . . . . . . 117
C. BDOS Function Summary . . . . . . . . . . . . . . 118
D. XDOS Function Summary . . . . . . . . . . . . . . 119
E. Memory Segment Base Page Reserved Locations . . . 120
F. Operation of MP/M on the Intel MDS-800 . . . . . . 121
G. Sample Page Relocatable Program . . . . . . . . . 122
H. Sample Resident System Process . . . . . . . . . . 127
I. Sample XIOS . . . . . . . . . . . . . . . . . . . 131
J. MP/M DDT Enhancements . . . . . . . . . . . . . . 148
K. Page Relocatable (PRL) File Specification . . . . 149
.AD
.bp
.sp 2
.ce
FOREWORD
.sp
.pp
This manual is intended as a guide for three different levels of
MP/M users. Section 1 contains all the information required to
enable a person to operate applications programs running under the
MP/M Operating System. Thus, the first section of this manual
should enable the casual user to operate the system with a minimum
amount of study and training.
.pp
The second section of this manual describes the MP/M system
organization including the structure of memory and system call
functions. The intention is to provide the
necessary information required to write page relocatable programs and
resident system processes which operate under MP/M, and which use
the real-time multi-tasking, peripheral and disk I/O facilities of
the system.
.pp
The last section provides the information needed to tailor MP/M
to another computer system. In particular, the hardware dependent
basic and extended I/O system entry points are
described.
Preparation of the MP/M loader using a CP/M 2.0 BIOS is also
covered.
.pp
The system generation procedure is also described in the last
section. This procedure is of interest to all three levels of
MP/M users because it describes how to configure MP/M for a particular
applications environment. This configuration includes the specificaion
of memory segmentation, number of consoles, and selection optional
resident system processes such as the printer spooler.
.br


814
MPM OPERATING SYSTEMS/MPM I/MPM I SOURCE/14/mpmug1.tex Normal file
View File

@@ -0,0 +1,814 @@
.MB +5
.MT -3
.LL 65
.PN 1
.HE MP/M User's Guide
.FT (All Information Herein is Proprietary to Digital Research.)
.sp 2
1. MP/M FEATURES AND FACILITIES
.sp
.pp
1.1 Introduction
.pp
The purpose of the MP/M multi-programming monitor control program is to
provide a microcomputer operating system which
supports multi-terminal access with multi-programming at each terminal.
.sp
.CE
OVERVIEW
.PP
The MP/M operating system is an upward compatible
version of CP/M 2.0 with a number of added facilities. These added
facilities are contained in new logical sections of MP/M called the
extended I/O system and the extended
disk operating system.
In this manual the name XIOS will refer to the combined basic
and extended I/O system. BDOS will refer to the standard CP/M 2.0
basic disk operating system functions and XDOS will refer to the
extended disk operating system.
As an upward compatible version, users can
easily make the transition from CP/M to the MP/M
operating system.
In fact, existing CP/M *.COM files can be run under MP/M,
providing that the program has been correctly written. That is,
BDOS calls are made for I/O,
and the only direct BIOS calls made are for console and printer I/O.
There must also be at least 4 bytes of extra stack in the CP/M
*.COM program.
.SP
The following basic facilities are provided:
.LI
o Multi-terminal support
o Multi-Programming at each terminal
o Support for bank switched memory and
memory protection
o Concurrency of I/O and CPU operations
o Inter-process communication, mutual
exclusion and synchronization
o Ability to operate in sequential, polled
or interrupt driven environments
o System timing functions
o Logical interrupt system utilizing flags
o Selection of system options at system
generation time
o Dynamic system configuration at load time
The following optional facilities are provided:
o Spooling list files to the printer
o Scheduling programs to be run by date and time
o Displaying complete system run-time status
o Setting and reading of the date and time
.AD
.SP
.CE
HARDWARE ENVIRONMENT
.PP
The hardware environment for MP/M must include an 8080 or Z80 CPU,
a minimum of 32K bytes of memory, 1 to 16 consoles, 1 to 16
logical (or physical) disk drives
each containing up to eight megabytes, and a clock/timer interrupt.
.PP
The distributed form of the MP/M operating system is configured for
a polled I/O environment on the Intel MDS-800 with two consoles
and a real-time clock. Multi-programming at two terminals is supported with this
configuration. To improve the system performance and
capability the following incremental hardware additions can be utilized
by the operating system:
.SP
.IN +3
a. Full Interrupt System
.BR
b. Banked Memory
.BR
c. Additional Consoles
.QI
.AD
.SP
.CE
MEMORY SIZE
.PP
The MP/M operating system requires less than
15K bytes of memory when configured for
two consoles and eight memory segments on the Intel MDS-800.
Each additional console
requires 256 bytes.
.PP
Optional resident system processes can be specified at system
generation which require varying amounts of memory.
.SP
.CE
PERFORMANCE
.PP
When MP/M is configured for a single console and is executing
a single process, its speed approximates that of CP/M.
In environments where either multiple processes and/or users are
running, the speed of each individual process is degraded in
proportion to the amount of I/O and compute resources required.
A process
which performs a large amount of I/O in proportion to computing
exhibits only minor speed degradation. This also applies to a process
that performs a large amount of computing, but is running concurrently
with other processes that are largely I/O bound. On the other hand,
significant speed degradation occurs in environments in which
more than one compute bound process is running.
.bp
.sp
.pp
1.2 Functional Description of MP/M
.pp
The MP/M Operating System is based on a real-time multi-tasking
nucleus. This nucleus provides process dispatching, queue management,
flag management, memory management and system timing functions.
.pp
MP/M is a priority driven system. This means that the highest priority
ready process is given the CPU resource. The operation of determining
the highest priority ready process and then giving it the CPU is called
dispatching. Each process in the system has a process descriptor. The
purpose of the process descriptor is to provide a data structure which
contains all the information the system needs to know about a process.
This information is used during dispatching to save
the state of the currently running process, to determine which process is
to be run, and then to restore that processes state.
Process dispatching is performed at each system call, at each
interrupt, and at each tick of the system clock.
Processes with the same priority are "round-robin" scheduled. That is,
they are given equal slices of CPU time.
.pp
Queues perform several critical functions in a real-time multi-tasking
environment. They can be used for the communication of messages
between processes, to synchronize processes, and for mutual exclusion.
As the name "queue" implies, they provide a first in first out list of
messages, and as implemented in MP/M, a list of processes waiting for
messages.
.pp
The flag management provided by MP/M is used to synchronize processes
by signaling a significant event. Flags provide
a logical interrupt system for MP/M which is independent of the
physical interrupt system. Flags are used to signal interrupts,
mapping an arbitrary physical interrupt environment into a regular
structure.
.pp
MP/M manages memory in pre-defined memory segments.
Up to eight memory segments of 48K can be managed by MP/M.
This management
of memory is consistent with hardware environments where memory
is banked and/or protected in fixed segments.
.pp
System timing functions provide time of day, the capability to
schedule programs to be loaded from disk and executed, and the
ability to delay the execution of a process for a specified period
of time.
.bp
.sp
.pp
1.3 Console Commands
.PP
The purpose of this section is to describe the console commands
which make up the operator interface to the MP/M operating
system. It is important to note from the outset that there are
no system defined or built-in commands. That is, the system has no
reserved or special commands. All commands in the system are
provided by resident system processes specified during system
generation and programs residing on disk in either the CP/M
*.COM file format or in the MP/M *.PRL (page relocatable) file format.
.pp
When MP/M is loaded from disk a configuration table and memory segment map
are displayed on console #0.
When the loading is complete each of the 1 to 16
configured consoles is a system or master console.
Additional slave consoles (maximum total of slave and master consoles
is 16) can be accessed using XDOS system calls.
.pp
After loading, the following message is displayed on each console:
.sp
.ti +3
MP/M
.ti +3
xA>
.pp
The 'x' shown in the prompt is the user code. At cold start an
association is made between the user code and console number. The
initial user code is equal to the console number. For
example, console #0 is initialized to user #0 and the following
prompt is displayed on console #0:
.sp
.ti +3
0A>
.pp
The default user code can then be changed to any desired user code
with the USER command (see USER in section 1.4).
All users have access to files with a user code of 0. Thus, system
files and programs should have a user code of 0.
Caution must be used when operating under a user
code of 0 since all its files can be accessed while
operating under any other user code.
In general, user code 0 should be reserved for
files which are accessed by all users. In the event that a
file with the same name is present under user code 0 and
another user code, the first file found in the directory
will be accessed.
.pp
The 'A' in the prompt is the default (currently logged) disk for the
console. This can be changed individually at any console by typing
in a disk drive name (A,B,C,...,or P) followed by a colon (:) when
the prompt has been received.
Since there are no built-in commands, the default disk
specified must contain the desired command files (such as
DIR, REN, ERA etc.), or each command must be preceeded by
an "A:".
.SP
.CE
RUNNING A PROGRAM
.PP
A program is run by typing in the program name followed by a carriage return, <cr>. Some programs obtain parameters on the same line
following the program name. Characters on the line following the
program name constitute what is called the command tail. The command
tail is copied into location 0080H (relative to the base of the memory
segment in which the program resides) and converted to upper case by the Command Line Interpreter
(CLI). The CLI also parses the command tail producing two file control
blocks at 005CH and 006CH respectively.
.PP
The programs which are provided with MP/M are described in sections
1.4 and 1.5.
.SP
.CE
ABORTING A PROGRAM
.PP
A program may be aborted by typing a control C (^C) at the console.
The affect of the ^C is to terminate the program which currently
owns the console. Thus, a detached program cannot be aborted with
a ^C. A detached program must first be attached and then aborted.
A running program may also be aborted using the ABORT command (see
ABORT in section 1.5).
.SP
.CE
RUNNING A RESIDENT SYSTEM PROCESS
.PP
At the operator interface there is no difference between running
a program from disk and running a resident system process. The actual
difference is that resident system processes do not need to be
loaded from disk because they are loaded by the MP/M loader when
a system cold start is performed and remain resident.
.SP
.CE
DETACHING FROM A PROGRAM
.PP
There are two methods for detaching from a running program. The first
is to type a control D (^D) at the console. The second method is for
a program to make an XDOS detach call.
.PP
The restriction on the former method, typing ^D, is that the running
program must be performing a check console status to observe the
detach request.
A check console status is automatically performed each time
a user program makes a BDOS disk function call.
.SP
.CE
ATTACHING TO A DETACHED PROGRAM
.PP
A program which is detached from a console, that is it does not own a
console, may be attached to a console by typing 'ATTACH' followed by
the program name. A program may only be attached to the console from
which it was detached.
If the terminal message process (TMP)
has ownership of the console and the user enters a ^D, the
next highest priority ready process which is waiting for the console
begins running.
.SP
.CE
LINE EDITING AND OUTPUT CONTROL
.PP
The Terminal Message Process (TMP) allows certain line editing
functions while typing in command lines:
.LI
rubout Delete the last character typed at the console,
removes and echoes the last character
ctl-C MP/M abort program. Terminate running process.
ctl-D MP/M detach console.
ctl-E Physical end of line.
ctl-H Delete the last character typed at the console,
backspaces one character position.
ctl-J (line feed) terminate current input.
ctl-M (carriage return) terminates input.
ctl-R Retype current command line: types a "clean line"
following character deletion with rubouts.
ctl-U Remove current line after new line.
ctl-X Delete the entire line typed at the console,
backspaces to the beginning of the current line
ctl-Z End input from the console.
The control functions ctl-P, ctl-Q and ctl-S affect console
output as shown below.
ctl-P Copy all subsequent console output to the list
device. Output is sent to both the list device
and the console device until the next ctl-P
is typed. If the list device is not available
a 'Printer busy' message is displayed on the
console.
ctl-Q Obtain ownership of the printer mutual exclusion
message. Obtaining the printer using this command
will ensure that the MP/M spooler, PIP, and other
ctl-P or ctl-Q commands entered from other
consoles will not be allowed access to the
printer. The printer is "owned" by the TMP until
another ctl-P or ctl-Q is entered, releasing the
printer. The ctl-P should be used when a program
(such as a CP/M *.COM file) is executed that does
not obtain the printer mutual exclusion message
prior to accessing the printer. If the list
device is not available a 'Printer busy' message
is displayed on the console.
ctl-S Stop the console output temporarily. Program
execution and output continue when the next
character is typed at the console (e.g., another
ctl-S). This feature is used to stop output on
high speed consoles, such as CRT's, in order to
view a segment of output before continuing.
.AD
.bp
.sp
.pp
1.4 Commonly Used System Programs
.PP
The commonly used system programs (CUSPs) or transient commands, as
they are called in CP/M, are loaded from the currently logged
disk and executed in a relocatable memory segment if their type is
PRL or in an absolute TPA if their type is COM.
.PP
This section contains a brief description of the CUSPs. Operation of
many of the CUSPs is identical to that under CP/M. In these cases
the commands are marked with an asterisk '*' and
the reader is referred to the Digital Research document titled "An
Introduction to CP/M Features and Facilities" for a complete
description of the CUSP.
.SP
.CE
GET/SET USER CODE
.PP
The USER command is used to display the current user code as well as
to set the user code value.
Entering the command USER followed by a <cr> will display the
current user code.
Note that the user code is already displayed in the prompt.
.sp
.ti +3
1A>user
.ti +3
user = 1
.pp
Entering the command USER followed by a space, a user code and then
a <cr> will set the user code to the specified user code. Legal user
codes are in the range 0 to 15.
.sp
.ti +3
1A>user 3
.ti +3
user = 3
.ti +3
3A>
.sp
.CE
CONSOLE
.pp
The CONSOLE command is used to determine the console number at
which the command is entered. The console number is sometimes of
interest when examining the system status to determine the processes
which are detached from consoles.
.sp
.ti +3
1A>console
.ti +3
Console = 0
.sp
.ce
DISK RESET
.pp
The DSKRESET (disk reset) command is used to enable the
operator to change disks. If no parameter is entered all
the drives are reset. Specific drives to be reset may be
included as parameters.
.sp
.ti +3
1A>DSKRESET
.sp
.ti +3
1A>DSKRESET B:,E:
.pp
If there are any open files on the drive(s) to be reset,
the disk reset is denied and the cause of the disk reset
failure is shown:
.sp
.ti +3
1A>DSKRESET B:
.sp
.ti +3
Disk reset denied, Drive B: Console 0 Program Ed
.pp
The reason that disk reset is treated so carefully is that
files left open (e.g. in the process of being written) will
lose their updated information if they are not closed prior
to a disk reset.
.sp
.ce
ERASE FILE *
.PP
The ERA (erase) command removes specified files having the current
user code.
If no files can be found on the selected diskette which satisfy the
erase request, then the message "No file" is displayed at the console.
.sp
An attempt to erase all files,
.sp
.ti +3
2B>ERA *.*
.sp
will produce the following response from ERA:
.sp
.ti +3
Confirm delete all user files (Y/N)?
.pp
A second form of the erase command (ERAQ) enables the
operator to selectively delete files that match the
specified filename reference. For example:
.sp
.ti +3
0A>ERAQ *.LST
.sp
.ti +3
A:XIOS LST? y
.ti +3
A:MYFILE LST? n
.SP
.CE
TYPE A FILE *
.PP
The TYPE command displays the contents of the specified ASCII source
file on the console device. The TYPE command expands tabs (ctl-I
characters), assuming tab positions are set at every eighth column.
.pp
The TYPE command has a pause mode which is specified by
entering a 'P' followed by two decimal digits after the
filename. For example:
.sp
.ti +3
0A>TYPE DUMP.ASM P23
.sp
The specified number of lines will be displayed and then
TYPE will pause until a <cr> is entered.
.pp
The TYPE program is small and relatively slow because it
buffers only one sector at a time. The larger PIP program
can be used for faster displays in the following manner:
.sp
.ti +3
0A>PIP CON:=MYFILE.TEX
.SP
.CE
FILE DIRECTORY *
.PP
The DIR (directory) command causes the names of files on the specified or logged-in
disk to be listed on the console device. If no files can be found
on the selected diskette which satisfy the directory request, then
the message "Not found" is typed at the console.
.pp
The DIR command can include files which have the system
attribute set. This is done by using the 'S' option. For
example:
.sp
.ti +3
0A>DIR *.COM S
.SP
.CE
RENAME FILE *
.PP
The REN (rename) command allows the user to change the name of files
on disk.
If the destination filename exists the operator is given
the option of deleting the current destination file before
renaming the source file.
.SP
.CE
TEXT EDITOR *
.PP
The ED (editor) command allows the user to edit ASCII text files.
.SP
.CE
PERIPHERAL INTERCHANGE PROGRAM *
.PP
The PIP (peripheral interchange program) command allows the user to
perform disk file and peripheral transfer operations.
See the Digital Research document titled "CP/M 2.0 User's Guide for
CP/M 1.4 Owners" for a detailed description of new PIP operations.
.SP
.CE
ASSEMBLER *
.PP
The ASM (assembler) command allows the user to assemble the specified
program on disk.
.SP
.CE
SUBMIT *
.PP
The SUBMIT command allows the user to submit a file of commands for
batch processing.
.SP
.CE
STATUS *
.PP
The STAT (status) command provides general statistical information
about the file storage.
See the Digital Research document titled "CP/M 2.0 User's Guide for
CP/M 1.4 Owners" for a detailed description of new STAT operations.
.SP
.CE
DUMP *
.PP
The DUMP command types the contents of the specified disk file on the
console in hexadecimal form.
.SP
.CE
LOAD *
.PP
The LOAD command reads the specified disk file of type HEX and
produces a memory image file of type COM which can subsequently
be executed.
.SP
.CE
GENMOD
.PP
The GENMOD command accepts a file which contains two concatenated
files of type HEX which are offset from each other by 0100H bytes,
and produces a file of type PRL (page relocatable).
The form of the GENMOD command is as follows:
.sp
.ti +3
1A>genmod b:file.hex b:file.prl $1000
.sp
The first parameter is the file which contains two concatenated files
of type HEX. The second parameter is the name of the destination file
of type PRL. The optional third parameter is a specification of additional memory required by the program beyond the explicit code
space. The form of the third parameter is a '$' followed by four
hex ASCII digits.
For example, if the program has been written to use all of 'available'
memory for buffers, specification of the third parameter will ensure
a minimum buffer allocation.
.SP
.CE
GENHEX
.PP
The GENHEX command is used to produce a file of type HEX
from a file of type COM. This is useful to be able to
generate HEX files for GENMOD input. The GENHEX command
has two parameters, the first is the COM file name and the
second is the offset for the HEX file. For example:
.sp
.ti +3
0A>GENHEX PROG.COM 100
.SP
.CE
PRLCOM
.PP
The PRLCOM command accepts a file of PRL type and produces
a file of COM type. If the destination COM file exists, a
query is made to determine if the file should be deleted
before continuing.
.sp
.ti +3
0A>prlcom b:program.prl a:program.com
.SP
.CE
DYNAMIC DEBUGGING TOOL *
.PP
The DDT (dynamic debugging tool) command loads and executes the
MP/M debugger.
In systems with banked memory multiple DDT programs can be running
concurrently in absolute TPAs. A PRL (relocatable)
version of DDT is also provided
which enables mutiple DDTs to run in a non-banked system. The
name of the relocatable DDT is RDT.
.pp
MP/M DDT enhancements are described in Appendix J.
.BP
.sp
.pp
1.5 Standard Resident System Processes
.PP
The standard resident system processes (RSPs) are new programs
specifically
designed to facilitate use of the MP/M operating system. The RSPs
may either be present on disk as files of the PRL type, or they
may be resident system processes. Resident system processes are
selected at the time of system generation.
.SP
.CE
SYSTEM STATUS
.PP
The MPMSTAT command allows the user to display the run-time status
of the MP/M operating system. MPMSTAT is invoked by typing 'MPMSTAT'
followed by a <cr>. A sample MPMSTAT output is shown below:
.LI
****** MP/M Status Display ******
Top of memory = FFFFH
Number of consoles = 02
Debugger breakpoint restart # = 06
Stack is swapped on BDOS calls
Z80 complementary registers managed by dispatcher
Ready Process(es):
MPMSTAT Idle
Process(es) DQing:
[Sched ] Sched
[ATTACH ] ATTACH
[CliQ ] cli
Process(es) NQing:
Delayed Process(es):
Polling Process(es):
PIP
Process(es) Flag Waiting:
01 - Tick
02 - Clock
Flag(s) Set:
03
Queue(s):
MPMSTAT Sched CliQ ATTACH MXParse
MXList [Tmp0 ] MXDisk
Process(es) Attached to Consoles:
[0] - MPMSTAT
[1] - PIP
Process(es) Waiting for Consoles:
[0] - TMP0 DIR
[1] - TMP1
Memory Allocation:
Base = 0000H Size = 4000H Allocated to PIP [1]
Base = 4000H Size = 2000H * Free *
Base = 6000H Size = 1100H Allocated to DIR [0]
.AD
.bp
.pp
.cp 4
The MP/M status display is intepreted as follows:
.in +6
.pp
Ready Process(es): The ready processes are those processes which
are ready to run and are waiting for the CPU. The list of ready
processes is ordered by the priority of the processes and includes
the console number at which the process was initiated. The highest
priority ready process is the running process.
.pp
Process(es) DQing: The processes DQing are those processes which are
waiting for messages to be written to the specified queue. The queue
name is in brackets followed by the names of processes, in priority
order, which have executed read queue operations on the queue.
.pp
Process(es) NQing: The processes NQing are those processes which are
waiting for an available buffer to write a message to the specified
queue. The queue name is in brackets followed by the names of the
processes, in priority order, which are waiting for buffers.
.pp
Delayed Process(es): The delayed processes are those which are
delaying for a specified number of ticks of the system time unit.
.pp
Polling Process(es): The polling processes are those which
are polling a specified I/O device for a device ready status.
.pp
Process(es) Flag Waiting: The processes flag waiting are listed by
flag number and process name.
.pp
Flag(s) Set: The flags which are set are displayed.
.pp
Queue(s): All the queues in the system are listed by queue name.
Queue names which are all in capital letters are accessible by
command line interpreter
input. For example, the SPOOL queue can be sent a message to spool
a file by entering 'SPOOL' followed by a file name.
Processes DQing from queues which have a name that matches the
process name are given the console resource when they receive a
message.
Queue names that begin with 'MX' are called mutual exclusion queues.
The display of a mutual exclusion queue includes the name of the process,
if any, which has the mutual exclusion message.
.pp
Process(es) Attached to Consoles: The process attached to each console
is listed by console number and process name.
.pp
Process(es) Waiting for Consoles: The processes waiting for each
console are listed by console number and process name in priority
order. They are processes
which have detached from the console and are then waiting for the
console before they can continue execution.
.pp
Memory Allocation: The memory allocation map shows the base, size, bank,
and allocation of each memory segment. Segments which are not
allocated are shown as '* Free *', while allocated segments are
identified by process name and the console in brackets associated with
the process.
Memory segments which are set as pre-allocated during system generation
by specifying an attribute of 0FFH are shown as '* Reserved *'.
.qi
.sp
.CE
SPOOLER
.PP
The SPOOL command allows the user to spool ASCII text files to the
list device. Multiple file names may be specified in the command
tail. The spooler expands tabs (ctl-I characters), assuming tab
positions are set at every eighth column.
.PP
The spooler queue can be purged at any time by using the STOPSPLR
command.
.PP
An example of the SPOOL command is shown below:
.sp
.ti +3
1A>SPOOL LOAD.LST,LETTER.PRN
.pp
The non-resident version of the spooler (SPOOL.PRL) differs
in its operation from the SPOOL.RSP as follows: it uses all
of the memory available in the memory segment in which it
is running for buffer space; it displays a message
indicating its status and then detaches from the console;
it may be aborted from a console other than the initiator
only by specifying the console number of the initiator as a
parameter of the STOPSPLR command.
.sp
.ti +3
3B>STOPSPLR 2
.SP
.CE
DATE AND TIME
.PP
The TOD (time of day) command allows the user to read and set the
date and time. Entering 'TOD' followed by a <cr> will cause the
current date and time to be displayed on the console. Entering
'TOD' followed by a date and time will set the date and time
when a <cr> is entered following the prompt to strike a key.
Each of these TOD commands is illustrated below:
.sp
.li
1A>TOD <cr>
Wed 02/06/80 09:15:37
-or-
1A>TOD 2/9/80 10:30:00
Strike key to set time
Sat 02/09/80 10:30:00
.AD
.pp
Entering 'TOD P' will cause the current time and date to be
continuously displayed until a key is struck at the console.
.SP
.CE
SCHEDULER
.PP
The SCHED (scheduler) command allows the user to schedule a program
for execution. Entering 'SCHED' followed by a date, time and command
line will cause the command line to be executed when the specified
date and time is reached.
.PP
In the example shown below, the program 'SAMPLE' will be loaded from
disk and executed on February 8, 1980 at 10:30 PM.
Note that only hours and minutes are specified, not seconds. Programs
are scheduled to the nearest minute.
.sp
.ti +3
1A>SCHED 2/8/79 22:30 SAMPLE
.SP
.CE
ABORT
.PP
The ABORT command allows the user to abort a running
program. The program to be aborted is entered as a
parameter in the ABORT command.
.sp
.ti +3
1A>ABORT RDT
.pp
A program initiated from another console may only be
aborted by including its console number as
a parameter of the ABORT command.
.sp
.ti +3
3B>ABORT RDT 1
.sp
.br


586
MPM OPERATING SYSTEMS/MPM I/MPM I SOURCE/14/mpmug20.tex Normal file
View File

@@ -0,0 +1,586 @@
.MB +5
.MT -3
.LL 65
.PN 17
.HE MP/M User's Guide
.FT (All Information Herein is Proprietary to Digital Research.)
.sp 2
2. MP/M INTERFACE GUIDE
.sp
.pp
This section describes MP/M system organization including
the structure of memory and system call functions. The intention
is to provide the necessary information required to write
page relocatable programs and resident system processes
which operate under MP/M, and which use the real-time, multi-tasking,
peripheral, and disk I/O facilities of the system.
.sp
.pp
2.1 Introduction
.pp
MP/M is logically divided into several modules. The three primary
modules are named the Basic and Extended I/O
System (XIOS), the Basic Disk Operating System
(BDOS), and the Extended Disk Operating System (XDOS).
The XIOS is a hardware-dependent module which defines the
exact low level interface to a particular computer system which
is necessary for peripheral device I/O. Although a standard
XIOS is supplied by Digital Research, explicit instructions
are provided for field reconfiguration of the XIOS to match
nearly any hardware environment.
.pp
MP/M memory structure is shown below:
.sp
.cp 40
.li
--------------------------- --+
high | | |
| SYSTEM.DAT | |
| | |
--------------------------- |
| | |
| CONSOLE.DAT | |
| | |
--------------------------- |
| | |
| USERSYS.STK | |
| | |
--------------------------- |
| | | These segments
| XIOS | +-- must reside in
| | | common memory:
--------------------------- |
| | | memory always
| BDOS or ODOS | | accessible no
| | | matter which
--------------------------- | bank is
| | | switched in.
| XDOS | |
| | |
--------------------------- |
| | |
| RSPs | |
| | |
--------------------------- --+
| |
| BNKBDOS (Optional) |
| |
---------------------------
| |
| MEMSEG.USR |
| |
...
| |
| MEMSEG.USR |
| |
---------------------------
| |
| ABSOLUTE TPA |
low | |
---------------------------
.sp
.pp
The exact memory addresses for each of the memory segments shown
above will vary with MP/M version and depend on the
operator specifications made during the system generation process.
.bp
The memory segments are described as follows:
.sp
.in 16
.ti -8
SYSTEM.DAT The SYSTEM.DAT segment contains 256 bytes used by the
loader to dynamically configure the system. After loading, the
segment is used for storage of system data such as submit flags.
See section 3.4 under SYSTEM DATA for a detailed description of
the byte allocation.
.sp
.ti -8
CONSOLE.DAT The CONSOLE.DAT segment varies in length with the
number of consoles. Each console requires 256 bytes which contains
the TMP's process descriptor, stack and buffers.
.sp
.ti -8
USERSYS.STK The USERSYS.STK segment is optional depending upon
whether or not the user intends to run CP/M *.COM files. This
segment contains 64 bytes of stack space per user memory segment
and is used as a temporary stack when user programs make
BDOS calls. Specification of the option to include this segment
is made during system generation.
The size of the USERSYS.STK segment varies as follows:
.ti +3
000H - No user system stacks
.ti +3
100H - 1 to 4 memory segments
.ti +3
200H - 5 to 8 memory segments
.sp
.ti -8
XIOS The XIOS segment contains the user customized
basic and extended I/O system in page relocatable format.
.sp
.ti -8
BDOS/ODOS The BDOS segment contains the disk file and multiple
console management functions. The segment is about 1400H bytes
in length.
.sp
The ODOS segment contains the resident portion of the banked BDOS
file and console management functions. The segment is about 800H bytes
in length.
.sp
.ti -8
XDOS The XDOS segment contains the MP/M nucleus and
the extended disk operating system. The segment is about 2000H bytes
in length.
.sp
.ti -8
RSPs The operator makes a selection of Resident System
Processes during system generation. The RSPs require varying amounts
of memory.
.sp
.ti -8
BNKBDOS (Optional) The BNKBDOS segment is present only in systems with
a bank switched BDOS. It contains the non-resident portion of the
banked BDOS disk file management. This segment is about E00H bytes in
length.
.sp
.ti -8
MEMSEG.USR The user can specifiy 1 to 8 user memory segments during
the system generation process. These memory segments may be in the
same address space with different bank numbers.
.sp
.ti -8
TPA The ABSOLUTE TPA is a user memory segment which is based
at 0000H. In systems with bank switched memory there may be more
than one ABSOLUTE TPA.
.in 0
.pp
Each user memory segment, including the TPA, is further divided
into two regions. The first is called the system parameter area.
The system parameter area occupies the first 100H bytes of the
memory segment and is defined similarily to that of CP/M.
See APPENDIX E for
a detailed description of the system parameter area. This area is
also called the memory segment base page.
.pp
The second region of the user memory segment is the user code area.
This area begins at 0100H relative to the base of the memory segment.
When a program is loaded, code is placed into the user memory segment
beginning at the start of the user code area.
.pp
Transient programs are loaded into memory by the Command Line
Interpreter (CLI). CLI receives commands from the Terminal Message
Process (TMP) which accepts the operator console input.
The TMP is a reentrant program which is executed by as many processes
as there are system consoles.
The operator communicates with the TMP by typing command lines
following each prompt. Each command line generally takes one of the
forms:
.sp
.cp 4
.li
command
command file1
command file1 file2
.sp
where "command" is either a queue such as SPOOL or ATTACH,
or the name of a transient command or program.
.pp
A brief discussion of CLI operation will describe the loading of
transient programs.
.pp
When CLI receives a command line it parses the first entry on the
command line and then tries to open a queue using the parsed name.
If the open queue succeeds the command tail is written to the queue
and the CLI operation is finished. If the open queue fails, a file
type of PRL is entered for the parsed file name and a file open is
attempted. If the file open succeeds then the header of the PRL
file is read to determine the memory requirements.
A relocatable memory request is made to obtain a memory segment in
which to load and run the program. If this request is satisfied
the PRL file is read into the memory segment, relocated, and it is
executed, completing the CLI operation.
.PP
If the PRL file type open fails then the file type of COM is entered
for the parsed file name and a file open is attempted. If the open
succeeds then a memory request is made for an absolute TPA, memory
segment based at 0000H. If this request is satisfied the COM file is
read into the absolute TPA and it is executed, completing the CLI
operation.
.pp
If the command is followed by one or two file specifications, the CLI
prepares one or two file control block (FCB) names in the system
parameter area. These optional FCB's are in the form necessary
to access files through MP/M BDOS calls, and are described in
the next section.
.pp
The CLI creates a process descriptor for each program which is
loaded, setting up a 20 level stack which forces a branch to the base
of the user code area of the memory segment. The default stack is
set up so that a return from the loaded program causes a branch
to the MP/M facility which terminates the process.
This stack has 19 levels available which can generally be used by the transient
program since it is sufficiently large to handle system calls.
.pp
The transient program then begins execution,
perhaps using the I/O facilities of MP/M to communicate
with the operator's console and peripheral devices, including
the disk subsystem. The I/O system is accessed by passing a
"function number" and an "information address" to MP/M through
the entry point at the memory segment base +0005H. In the case of a
disk
read, for example, the transient program sends the number corresponding
to a disk read, along with the address of an FCB to MP/M.
MP/M, in turn, performs the operation and returns with either
a disk read completion indication or an error number indicating
that the disk read was unsuccessful. The function numbers and
error indicators are given in sections 2.2 and 2.4.
.sp 2
.ce
OPERATING SYSTEM CALL CONVENTIONS
.sp
.pp
The purpose of this section is to provide detailed information
for performing direct operating system calls from user programs.
Many of the functions listed below, however, are more simply
accessed through the I/O macro library provided with the MAC
macro assembler, and listed in the Digital Research manual
entitled "MAC Macro Assembler: Language Manual and Applications
Guide."
.pp
MP/M facilities which are available for access by transient
programs fall into two general categories: simple device
I/O, disk file I/O, and the XDOS functions.
.bp
.ti +6
The simple device operations include:
.sp
.cp 8
.li
Read/Write a Console Character
Write a List Device Character
Print Console Buffer
Read Console Buffer
Interrogate Console Ready
.pp
The BDOS operations which perform disk Input/Output are
.sp
.cp 16
.li
Disk System Reset
Drive Selection
File Creation
File Open
File Close
Directory Search
File Delete
File Rename
Random or Sequential Read
Random or Sequential Write
Interrogate Available Disks
Interrogate Selected Disk
Set DMA Address
Set/Reset File Indicators
Reset Drive
Access/Free Drive
Random Write With Zero Fill
.pp
The XDOS functions are
.sp
.cp 21
.li
Absolute and Relocatable Memory Request
Memory Free
Device Poll
Flag Waiting and Setting
Make Queue
Open Queue
Delete Queue
Read and Conditional Read Queue
Write and Conditional Write Queue
Delay
Dispatch
Terminate and Create Process
Set Priority
Attach and Detach Console
Set and Assign Console
Send CLI Command
Call Resident System Procedure
Parse Filename
Get Console Number
System Data Address
Get Date and Time
Return Process Descriptor Address
Abort Specified Process
.pp
As mentioned above, access to the MP/M functions is accomplished
by passing a function number and information address through the
primary entry point at location memory segment base +0005H.
In general, the function number is passed in register C with
the information address in the double byte pair DE.
Single byte values are returned in register A, with
double byte values returned in HL
(a zero value is returned when the function number is
out of range).
For reasons of compatibility,
register A = L and register B = H upon return in all cases.
Note that the register passing conventions of MP/M agree with
those of Intel's PL/M systems programming language.
.pp
The list of MP/M BDOS function numbers is given below.
.sp
.cp 20
.li
0 System Reset 21 Write Sequential
1 Console Input 22 Make File
2 Console Output 23 Rename File
3 Raw Console Input 24 Return Login Vector
4 Raw Console Output 25 Return Current Disk
5 List Output 26 Set DMA Address
6 Direct Console I/O 27 Get Addr(Alloc)
7 Get I/O Byte 28 Write Protect Disk
8 Set I/O Byte 29 Get R/O Vector
9 Print String 30 Set File Attributes
10 Read Console Buffer 31 Get Addr(Disk Parms)
11 Get Console Status 32 Set/Get User Code
12 Return Version Number 33 Read Random
13 Reset Disk System 34 Write Random
14 Select Disk 35 Compute File Size
15 Open File 36 Set Random Record
16 Close File 35 Compute File Size
17 Search for First 36 Set Random Record
18 Search for Next 37 Reset Drive
19 Delete File 38 Access Drive
20 Read Sequential 39 Free Drive
40 Write Random With Zero Fill
.bp
The list of MP/M XDOS function numbers is given below.
.sp
.cp 14
.li
128 Absolute Memory Rqst 143 Terminate Process
129 Relocatable Mem. Rqst 144 Create Process
130 Memory Free 145 Set Priority
131 Poll 146 Attach Console
132 Flag Wait 147 Detach Console
133 Flag Set 148 Set Console
134 Make Queue 149 Assign Console
135 Open Queue 150 Send CLI Command
136 Delete Queue 151 Call Resident Sys. Proc.
137 Read Queue 152 Parse Filename
138 Cond. Read Queue 153 Get Console Number
139 Write Queue 154 System Data Address
140 Cond. Write Queue 155 Get Date and Time
141 Delay 156 Return Proc. Descr. Adr.
142 Dispatch 157 Abort Specified Process
.sp
.ce
DISK FILE STRUCTURE
.pp
MP/M implements a named file structure on each disk, providing
a logical organization which allows any particular file to
contain any number of records from completely empty, to the
full capacity of the drive. Each drive is logically distinct
with a disk directory and file data area. The disk file names
are in three parts: the drive select code, the file name
consisting of one to eight non-blank characters, and the file
type consisting of zero to three non-blank characters.
The file type names the generic category of a particular
file, while the file name distinguishes individual files
in each category. The file types listed below name a few
generic categories which have been established, although
they are generally arbitrary:
.sp
.cp 10
.li
ASM Assembler Source PLI PL/I Source File
PRN Printer Listing REL Relocatable Module
HEX Hex Machine Code TEX TEX Formatter Source
BAS Basic Source File BAK ED Source Backup
INT Intermediate Code SYM SID Symbol File
COM CCP Command File $$$ Temporary File
PRL Page Relocatable RSP Resident Sys. Process
SPR Sys. Page Reloc. SYS System File
.sp
Source files are treated as a sequence of ASCII characters,
where each "line" of the source file is followed by
a carriage-return line-feed sequence (0DH followed by 0AH).
Thus one 128 byte MP/M record could contain several lines
of source text.
The end of an ASCII file is denoted by a control-Z character
(1AH) or a real end of file (i.e. no more sectors), returned by the
MP/M read operation.
Control-Z characters embedded within machine code files
(e.g., COM files) are ignored, however, and the end of
file condition returned by MP/M is used to terminate
read operations.
.pp
Files in MP/M can be thought of as a sequence of up to 65536
records of 128 bytes each, numbered from 0 through 65535,
thus allowing a maximum of 8 megabytes per file.
Note, however, that although the records may be considered
logically contiguous, they are not necessarily physically contiguous
in the disk data area.
Internally, all files are broken into 16K byte segments called
logical extents, so that counters are easily maintained as
8-bit values.
Although the decomposition into extents is discussed in
the paragraphs which follow, they are
of no particular consequence to the programmer
since each extent is automatically accessed in both sequential
and random access modes.
.pp
In the file operations
starting with function number 15, DE usually addresses a
file control block (FCB).
Transient programs often use the default file control block area
reserved by MP/M at location memory segment base +005CH for
simple file operations.
The basic unit of file information
is a 128 byte record used for all file operations, thus a
default location for disk I/O is provided by MP/M at location
memory segment base +0080H which is the initial default
DMA address (see function 26).
All directory
operations take place in a reserved area which does
not affect write buffers as was the case in CP/M release
1, with the exception of Search First and Search Next,
where compatibility is required.
.pp
The File Control Block (FCB) data area consists of a sequence
of 33 bytes for sequential access and a series of 36 bytes
in the case that the file is accessed randomly. The default
file control block normally located at memory segment base +005CH can
be used for random access files, since the three bytes starting
at memory segment base +007DH
are available for this purpose.
.bp
.li
The FCB format is shown with the following fields:
------------------------------------------------------------
|dr|f1|f2|/ /|f8|t1|t2|t3|ex|s1|s2|rc|d0|/ /|dn|cr|r0|r1|r2|
------------------------------------------------------------
00 01 02 ... 08 09 10 11 12 13 14 15 16 ... 31 32 33 34 35
where
dr drive code (0 - 16)
0 => use default drive for file
1 => auto disk select drive A,
2 => auto disk select drive B,
...
16=> auto disk select drive P.
f1...f8 contain the file name in ASCII
upper case, with high bit = 0
t1,t2,t3 contain the file type in ASCII
upper case, with high bit = 0
t1', t2', and t3' denote the
bit of these positions,
t1' = 1 => Read/Only file,
t2' = 1 => SYS file, no DIR list
t3' = 0 => File has been updated
ex contains the current extent number,
normally set to 00 by the user, but
in range 0 - 31 during file I/O
s1 reserved for internal system use
s2 reserved for internal system use, set
to zero on call to OPEN, MAKE, SEARCH
rc record count for extent "ex,"
takes on values from 0 - 128
d0...dn filled-in by MP/M, reserved for
system use
cr current record to read or write in
a sequential file operation, normally
set to zero by user
r0,r1,r2 optional random record number in the
range 0-65535, with overflow to r2,
r0,r1 constitute a 16-bit value with
low byte r0, and high byte r1
.pp
Each file being accessed through MP/M must have a corresponding
FCB which provides the name and allocation information for all
subsequent file operations. When accessing files, it is the
programmer's responsibility to fill the lower sixteen bytes
of the FCB and initialize the "cr" field. Normally,
bytes 1 through 11 are set to the ASCII character
values for the file name and file type, while all other
fields are zero.
.pp
FCB's are stored in a directory area of the disk, and are
brought into central memory before proceeding with file
operations (see the OPEN and MAKE functions). The memory
copy of the FCB is updated as file operations take place
and later recorded permanently on disk at the termination
of the file operation (see the CLOSE command).
.pp
The CLI constructs the first sixteen bytes of two optional
FCB's for a transient by scanning the remainder of the line
following the transient name, denoted by "file1" and "file2"
in the prototype command line described above,
with unspecified fields set to ASCII blanks. The first
FCB is constructed at location memory segment base +005CH, and can
be used as-is for subsequent file operations. The second
FCB occupies the d0 ... dn portion of the first FCB,
and must be moved to another area of memory before use.
If, for example, the operator types
.sp
.ce
PROGNAME B:X.ZOT Y.ZAP
.sp
the file PROGNAME.PRL is loaded into a user memory segment or if
it is not on the disk,
the file PROGNAME.COM is loaded into the TPA, and the default
FCB at memory segment base +005CH is initialized to drive code 2, file
name "X" and file type "ZOT". The second drive code takes
the default value 0, which is placed at memory segment base +006CH,
with the file name "Y" placed into location memory segment base +006DH
and file type "ZAP" located 8 bytes later at memory segment base +0075H.
All remaining fields through "cr" are set to zero. Note again
that it is the programmer's responsibility to move this second
file name and type to another area, usually a separate file
control block, before opening the file which begins at
memory segment base +005CH, due to the fact that the open operation
will overwrite the second name and type.
.pp
If no file names are specified in the original command,
then the fields beginning at memory segment base +005DH and +006DH
contain blanks. In all cases, the CLI translates lower
case alphabetics to upper case to be consistent with
the MP/M file naming conventions.
.pp
As an added convenience, the default buffer area at location
memory segment base +0080H is initialized to the command line tail
typed by the operator following the program name. The first
position contains the number of characters, with the characters
themselves following the character count.
.bp
Given the above
command line, the area beginning at memory segment base +0080H is
initialized as follows:
.sp
.cp 4
.li
Memory Segment Base +0080H:
+00 +01 +02 +03 +04 +05 +06 +07 +08 +09 +10 +11 +12 +13 +14
14 " " "B" ":" "X" "." "Z" "O" "T" " " "Y" "." "Z" "A" "P"
.sp
where the characters are translated to upper case ASCII with
uninitialized memory following the last valid character.
Again, it is the responsibility of the programmer to extract
the information from this buffer before any file operations
are performed, unless the default DMA address is explicitly
changed.
.pp
The individual functions are described in detail in the sections
which follow.
.br


1233
MPM OPERATING SYSTEMS/MPM I/MPM I SOURCE/14/mpmug21.tex Normal file
View File

File diff suppressed because it is too large Load Diff

447
MPM OPERATING SYSTEMS/MPM I/MPM I SOURCE/14/mpmug22.tex Normal file
View File

@@ -0,0 +1,447 @@
.MB +5
.MT -3
.LL 65
.PN 53
.HE MP/M User's Guide
.FT (All Information Herein is Proprietary to Digital Research.)
.sp
.pp
2.3 Queue and Process Descriptor Data Structures
.pp
This section contains a description of the queue and process
descriptor data structures used by the MP/M Extended Disk Operating
System (XDOS).
.sp
.ce
QUEUE DATA STRUCTURES
.pp
A queue is a first in first out (FIFO) mechanism which has been
implemented in MP/M to provide several essential functions in a
multi-tasking environment. Queues can be used for the communication
of messages between processes, to synchronize processes, and to provide
mutual exclusion.
.pp
MP/M has been designed to simplify queue management for both user
and system processes. In fact, queues are treated in a manner
similar to disk files. Queues can be created, opened, written to,
read from, and deleted.
.pp
A few illustrations should suffice to describe applications
for queues:
.pp
COMMUNICATION:
.pp
A queue can be used for communication to provide a FIFO list of
messages produced by a producer for consumption by a consumer.
For example, consider a data logging application where
data is continuously received via a serial communication link and is to
be written to a disk file. This would be a difficult application
for a sequential operating system such as CP/M because arriving
serial data would be lost while buffers were being written to
disk. Under MP/M a queue could be used by the producer to send
blocks of received serial data (or simply buffer pointers) to a consumer
which would write the blocks on disk. MP/M supports concurrency of
these operations, allowing the producer to quickly write a buffer to
the queue and then resume monitoring the serial input.
.pp
SYNCHRONIZATION:
.pp
When a process attempts to read a message at a queue and there are
no messages posted at the queue, the process is placed in a priority
ordered list of processes waiting for messages at the queue. The
process will remain in that state until a message arrives. Thus
synchronization of processes can be achieved, allowing the waiting
(DQing) process to continue execution when a message is sent to
the queue.
.cp 20
.pp
MUTUAL EXCLUSION:
.pp
A queue can also be used for mutual exclusion.
Mutual exclusion messages generally have a length of zero. A good
example of mutual exclusion is that which is used by MP/M to
control access to the printer. A queue is created (MXList)
and sent one message. When the printer is to be used by the spooler
or by entering a control-P (^P) at the console an attempt is
made to read the message from the list mutual exclusion queue.
This attempt is made using the MP/M conditional read queue function.
If the message is available, that is it has not been consumed by
some other process, it is read and the printer is used. When finished
with the printer,
the message is written back to the list mutual exclusion queue.
If the message is not available the user who entered the ^P
receives a message indicating that the printer is busy.
In the case of the spooler, it waits until the printer is available
before continuing.
.sp
.ce
QUEUE DATA STRUCTURES
.SP
.pp
The queue data structures include the queue control block and the user
queue control block. There are two types of queue control blocks,
circular or linked. The type of queue control block used depends upon
the message size. Message sizes of 0 to 2 bytes use circular queues
while message sizes of 3 or more bytes use linked queues.
.sp
.ce
CIRCULAR QUEUES
.pp
The following example illustrates how to setup a queue control block
for a circular queue with 80 messages of a one byte length.
Each example in this section will be shown both in PL/M and assembly
language.
.cp 17
.LI
PL/M:
DECLARE CIRCULAR$QUEUE STRUCTURE (
QL ADDRESS,
NAME(8) BYTE,
MSGLEN ADDRESS,
NMBMSGS ADDRESS,
DQPH ADDRESS,
NQPH ADDRESS,
MSG$IN ADDRESS,
MSG$OUT ADDRESS,
MSG$CNT ADDRESS,
BUFFER (80) BYTE )
INITIAL (0,'CIRCQUE ',1,80);
.ad
.cp 14
.li
Assembly Language:
CRCQUE:
DS 2 ; QL
DB 'CIRCQUE ' ; NAME
DW 1 ; MSGLEN
DW 80 ; NMBMSGS
DS 2 ; DQPH
DS 2 ; NQPH
DS 2 ; MSGIN
DS 2 ; MSGOUT
DS 2 ; MSGCNT
BUFFER: DS 80 ; BUFFER
.AD
The elements of the circular queue shown above are defined
as follows:
.LI
QL = 2 byte link, set by system
NAME = 8 ASCII character queue name,
set by user
MSGLEN = 2 bytes, length of message,
set by user
NMBMSGS = 2 bytes, number of messages,
set by user
DQPH = 2 bytes, DQ process head,
set by system
NQPH = 2 bytes, NQ process head,
set by system
MSG$IN = 2 bytes, pointer to next
message in, set by system
MSG$OUT = 2 bytes, pointer to next
message out, set by system
MSG$CNT = 2 bytes, number of messages
in the queue, set by system
BUFFER = n bytes, where n is equal to
the message length times the
number of messages, space
allocated by user, set by system
Note: Mutual exclusion queues require
a two byte buffer for the owner process
descriptor address.
Queue Overhead = 24 bytes
.AD
.sp
.ce
LINKED QUEUES
.pp
The following example illustrates how to setup a queue control block
for a linked queue containing 4 messages, each 33 bytes in length:
.cp 16
.LI
PL/M:
DECLARE LINKED$QUEUE STRUCTURE (
QL ADDRESS,
NAME (8) BYTE,
MSGLEN ADDRESS,
NMBMSGS ADDRESS,
DQPH ADDRESS,
NQPH ADDRESS,
MH ADDRESS,
MT ADDRESS,
BH ADDRESS,
BUFFER (140) BYTE )
INITIAL (0,'LNKQUE ',33,4);
.ad
.cp 21
.li
Assembly Language:
LNKQUE:
DS 2 ; QL
DB 'LNKQUE ' ; NAME
DW 33 ; MSGLEN
DW 4 ; NMBMSGS
DS 2 ; DQPH
DS 2 ; NQPH
DS 2 ; MH
DS 2 ; MT
DS 2 ; BH
BUFFER: DS 2 ; MSG #1 LINK
DS 33 ; MSG #1 DATA
DS 2 ; MSG #2 LINK
DS 33 ; MSG #2 DATA
DS 2 ; MSG #3 LINK
DS 33 ; MSG #3 DATA
DS 2 ; MSG #4 LINK
DS 33 ; MSG #4 DATA
.AD
The elements of the linked queue shown above are defined
as follows:
.LI
QL = 2 byte link, set by system
NAME = 8 ASCII character queue name,
set by user
MSGLEN = 2 bytes, length of message,
set by user
NMBMSGS = 2 bytes, number of messages,
set by user
DQPH = 2 bytes, DQ process head,
set by system
NQPH = 2 bytes, NQ process head,
set by system
MH = 2 bytes, message head,
set by system
MT = 2 bytes, message tail,
set by system
BH = 2 bytes, buffer head,
set by system
BUFFER = n bytes where n is equal to
the message length plus two,
times the number of messages,
space allocated by the user,
set by the system
.AD
.sp
.ce
USER QUEUE CONTROL BLOCK
.pp
The user queue control block data structure is used to provide
read/write access to queues in much the same manner that a file
control block provides access to a disk file. Queues are "opened",
an operation which fills in the actual queue control block address,
and then can be read from or written to.
.pp
If the actual queue address is known it can be filled in the
pointer field of the user queue control block, the 8 byte name
field can be omitted, and an open operation is not required in
order to access the queue.
.pp
The following example illustrates a user queue control block:
.cp 9
.LI
PL/M:
DECLARE USER$QUEUE$CONTROL$BLOCK STRUCTURE (
POINTER ADDRESS,
MSGADR ADDRESS,
NAME (8) BYTE )
INITIAL (0,.BUFFER,'SPOOL ');
DECLARE BUFFER (33) BYTE;
.ad
.cp 11
.li
Assembly Language:
UQCB:
DS 2 ; POINTER
DW BUFFER ; MSGADR
DB 'SPOOL ' ; NAME
BUFFER:
DS 33 ; BUFFER
.AD
.cp 14
.pp
The elements of the user queue control block shown above are defined
as follows:
.LI
POINTER = 2 bytes, set by system to address of
actual queue during an open queue
operation, or set by the user if the
actual queue address is known
MSGADR = 2 bytes, address of user buffer,
set by user
NAME = 8 bytes, ASCII queue name,
set by user, may be omitted if the
pointer field is set by the user
.AD
.sp
.ce
QUEUE NAMING CONVENTIONS
.pp
The following conventions should be used in the naming of
queues. Queues which are to be directly written to by the
Terminal Message Process (TMP) via the Command Line
Interpreter (CLI) must have an upper case ASCII name. Thus
when an operator enters the queue name followed by a
command tail at a console, the command tail is written to
the queue.
.pp
In order to make a queue inaccessible by a user at a
console it must contain at least one lower case character.
Mutual exclusion queues should be named upper case 'MX'
followed by 1 to 6 additional ASCII characters. These
queues are treated specially in that they must have a two
byte buffer in which MP/M places the address of the process
descriptor owning the mutual exclusion message.
.cp 35
.sp
.ce
PROCESS DESCRIPTOR
.pp
Each process in the MP/M system has a process descriptor which
defines all the characteristics of the process. The following
example illustrates the process descriptor:
.cp 28
.LI
PL/M:
DECLARE CNS$HNDLR STRUCTURE (
PL ADDRESS,
STATUS BYTE,
PRIORITY BYTE,
STKPTR ADDRESS,
NAME (8) BYTE,
CONSOLE BYTE,
MEMSEG BYTE,
B ADDRESS,
THREAD ADDRESS,
DISK$SET$DMA ADDRESS,
DISK$SLCT BYTE,
DCNT ADDRESS,
SEARCHL BYTE,
SEARCHA ADDRESS,
DRVACT ADDRESS,
REGISTERS (20) BYTE,
SCRATCH (2) BYTE )
INITIAL (0,0,200,.CNS$STK(19),
'CNS ',1,0FFH);
DECLARE CNS$STK (20) ADDRESS INITIAL (
0C7C7H,0C7C7H,0C7C7H,0C7C7H,0C7C7H,0C7C7H,
0C7C7H,0C7C7H,0C7C7H,0C7C7H,0C7C7H,0C7C7H,
0C7C7H,0C7C7H,0C7C7H,0C7C7H,0C7C7H,0C7C7H,
0C7C7H,STRT$CNS);
.ad
.cp 28
.li
Assembly Language:
CNSHND:
DW 0 ; PL
DB 0 ; STATUS
DB 200 ; PRIORITY
DW CNSTK+38 ;STKPTR
DB 'CNS ' ; NAME
DB 0 ; CONSOLE
DB 0FFH ; MEMSEG (FF = resident)
DS 2 ; B
DS 2 ; THREAD
DS 2 ; DISK SET DMA
DS 1 ; DISK SLCT
DS 2 ; DCNT
DS 1 ; SEARCHL
DS 2 ; SEARCHA
DS 2 ; DRVACT
DS 20 ; REGISTERS
DS 2 ; SCRATCH
CNSTK:
DW 0C7C7H,0C7C7H,0C7C7H,0C7C7H
DW 0C7C7H,0C7C7H,0C7C7H,0C7C7H
DW 0C7C7H,0C7C7H,0C7C7H,0C7C7H
DW 0C7C7H,0C7C7H,0C7C7H,0C7C7H
DW 0C7C7H,0C7C7H,0C7C7H
DW CNSPR ; CNSTK+38 = PROCEDURE ADR
.AD
.pp
The elements of the process descriptor shown above are defined
as follows:
.LI
PL = 2 byte link field, initially set by
user to address of next process
descriptor, or zero if no more
STATUS = 1 byte, process status, set by system
PRIORITY = 1 byte, process priority, set by user
STKPTR = 2 bytes, stack pointer, initially set
by user
NAME = 8 bytes, ASCII process name, set by user
The high order bit of each byte of the
process name is reserved for use by the
system. The high order bit of the first
byte (identified as NAME(0)') "on" indicates
that the process is performing direct
console BIOS calls and that MP/M is to
ignore all control characters. It is also
used to suppress the normal console status
check done when BDOS disk functions are
invoked. This bit may be set by the user.
CONSOLE = 1 byte, console to be used by process,
set by user
MEMSEG = 1 byte, memory segment table index
B = 2 bytes, system scatch area
THREAD = 2 bytes, process list thread, set
by system
DISK$SET$DMA = 2 bytes, default DMA address, set by user
DISK$SLCT = 1 byte, default disk/user code
DCNT = 2 bytes, system scratch byte
SEARCHL = 1 byte, system scratch byte
SEARCHA = 2 bytes, system scratch bytes
DRVACT = 2 bytes, 16 bit vector of drives being
accessed by the process
REGISTERS =20 bytes, 8080 / Z80 register save area
SCRATCH = 2 bytes, system scratch bytes
.AD
.sp
.ce
PROCESS NAMING CONVENTIONS
.pp
The following conventions should be used in the naming of
processes. Processes which wait on queues that are to be
sent command tails from the TMPs are given the console
resource if their name matches that of the queue which they
are reading.
Processes which are to be protected from abortion by an
operator using the ABORT command must have at least one
lower case character in the process name.
.br


933
MPM OPERATING SYSTEMS/MPM I/MPM I SOURCE/14/mpmug23.tex Normal file
View File

@@ -0,0 +1,933 @@
.MB +5
.MT -3
.LL 65
.PN 62
.HE MP/M User's Guide
.FT (All Information Herein is Proprietary to Digital Research.)
.sp
.pp
2.4 Extended Disk Operating System Functions
.pp
The Extending Disk Operating System (XDOS) functions are covered in
this section by describing the entry parameters and returned values
for each XDOS function. The XDOS calling conventions are identical
to those of the BDOS which are described in
OPERATING SYSTEM CALL CONVENTIONS in section 2.1.
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 128: ABSOLUTE MEMORY *
* REQUEST *
***************************************
* Entry Parameters: *
* Register C: 80H *
* DE: MD Address *
* *
* Returned Value: *
* Register A: Return code *
* MD filled in *
***************************************
.pp
The ABSOLUTE MEMORY REQUEST function allocates
an absolute block of memory specified by the passed memory descriptor
parameter. This
function allows non-relocatable programs,
such as CP/M *.COM files based at the absolute TPA address of
0100H, to run in
the MP/M 1.0 environment. The single passed parameter is the address
of a memory descriptor. The memory descriptor contains four bytes:
the memory segment base page address, the memory segment page size,
the memory segment attributes, and bank. The only parameters
filled in by the user
are the base and size, the other parameters are filled in by XDOS.
.pp
The operation returns a "boolean" indicating whether or not the
allocation was made.
A returned value of FFH indicates failure to allocate the requested
memory and a value of 0 indicates success.
Note that base and size specify base page address and page size where
a page is 256 bytes.
.li
Memory Descriptor Data Structure:
PL/M:
Declare memory$descriptor structure (
base byte,
size byte,
attrib byte,
bank byte );
.ad
.cp 10
.li
Assembly Language:
MEMDES:
DS 1 ; base
DS 1 ; size
DS 1 ; attributes
DS 1 ; bank
.ad
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 129: RELOCATABLE MEMORY *
* REQUEST *
***************************************
* Entry Parameters: *
* Register C: 81H *
* DE: MD Address *
* *
* Returned Value: *
* Register A: Return code *
* MD filled in *
***************************************
.PP
The RELOCATABLE MEMORY REQUEST function allocates
the requested contiguous memory to the calling program. The
single passed parameter is the address of a memory descriptor. The
only memory descriptor parameter filled in by the calling program is
the
size, the other parameters, base, attributes and bank, are filled in by
XDOS.
.pp
The operation returns a boolean indicating whether or not the memory
request could be satisifed.
A returned value of FFH indicates failure to
satisfy the request and a value of 0 indicates success.
.pp
Note that base and size specify base page address and page size where
a page is 256 bytes.
(See function 128: ABSOLUTE MEMORY REQUEST for a description of
the memory descriptor data structure.)
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 130: MEMORY FREE *
* *
***************************************
* Entry Parameters: *
* Register C: 82H *
* DE: MD Address *
* *
***************************************
.PP
The MEMORY FREE function releases the
specified memory segment back to the operating system. The passed
parameter is the address of a memory descriptor.
Nothing is returned as
a result of this operation.
(See function 128: ABSOLUTE MEMORY REQUEST for a description of
the memory descriptor data structure.)
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 131: POLL *
* *
***************************************
* Entry Parameters: *
* Register C: 83H *
* E: Device Number *
* *
***************************************
.PP
The POLL function polls the specified device
until a ready condition is received. The calling process relinquishes
the processor until the poll is satisfied, allowing other processes
to execute.
.pp
Note that the POLL function is intended for use in the custom XIOS
since an association is made in the XIOS between the device number
and the actual code executed for the poll operation. This does not
exclude other uses of the poll function but it does mean that an
application program making a poll call must be matched to a specific
XIOS.
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 132: FLAG WAIT *
* *
***************************************
* Entry Parameters: *
* Register C: 84H *
* E: Flag Number *
* *
* Returned Value: *
* Register A: Return code *
***************************************
.PP
The FLAG WAIT function causes a process to
relinquish the processor until the flag specified in the call is set.
The flag wait operation is used in an interrupt driven
system to cause the calling process to 'wait' until a specific
interrupt condition occurs.
.pp
The operation returns a boolean indicating whether or not a successful
FLAG WAIT was performed. A returned value of FFH indicates that no
flag wait occurred because another process was already waiting on
the specified flag. A returned value of 0 indicates success.
.pp
Note that flags are non-queued, which means that access to flags
must be carefully managed. Typically the physical interrupt handlers
will set flags while a single process will wait on each flag.
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 133: FLAG SET *
* *
***************************************
* Entry Parameters: *
* Register C: 85H *
* E: Flag Number *
* *
* Returned Value: *
* Register A: Return code *
***************************************
.PP
The FLAG SET function wakes up a waiting process.
The FLAG SET function is usually called by an interrupt service
routine after servicing an interrupt and determining which flag is
to be set.
.ti +6
The operation returns a boolean indicating whether or not a successful
FLAG SET was performed. A returned value of FFH indicates that a flag
over-run has occurred, i.e. the flag was already set when a flag set
function was called. A returned value of 0 indicates success.
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 134: MAKE QUEUE *
* *
***************************************
* Entry Parameters: *
* Register C: 86H *
* DE: QCB Address *
* *
***************************************
.PP
The MAKE QUEUE function sets up a queue control
block. A queue is configured as either circular or linked depending
upon the message size. Message sizes of 0 to 2 bytes use circular
queues while message sizes of 3 or more bytes use linked queues.
.PP
A single parameter is passed to make a queue, the queue control block
address. The queue control block must contain the queue name, message
length, number of messages, and sufficient space to accomodate the
messages (and links if the queue is linked).
.pp
The queue control block data structures for both circular and linked
queues are described in section 2.3.
.pp
Queues can only be created either in common memory or by
user programs in non-banked systems. The reason is that
queues are all maintained on a linked list which must be
accessible at all times. I.E., a queue cannot reside in a
memory segment which is bank switched. However, a queue
created in common memory can be accessed by all system and
user programs.
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 135: OPEN QUEUE *
* *
***************************************
* Entry Parameters: *
* Register C: 87H *
* DE: UQCB Address *
* *
* Returned Value: *
* Register A: Return code *
***************************************
.PP
The OPEN QUEUE function places the actual queue
control block address into the user queue control block.
The result of this function is that a user program can obtain access
to queues by knowing only the queue name, the actual address
of the queue itself is obtained as a result of opening the queue.
Once a queue has been opened, the queue may be read from or written to
using the queue read and write operations.
.PP
The function returns a boolean indicating whether or not the open
queue operation found the queue to be opened. A returned value of
0FFH indicates failure while a zero indicates success.
.pp
The user queue control block data structure is described in section
2.3.
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 136: DELETE QUEUE *
* *
***************************************
* Entry Parameters: *
* Register C: 88H *
* DE: QCB Address *
* *
* Returned Value: *
* Register A: Return Code *
***************************************
.PP
The DELETE QUEUE function removes the specified
queue from the queue list.
A single parameter is passed to delete a queue, the address of the
actual queue.
.PP
The function returns a boolean indicating whether or not the delete
queue operation deleted the queue. A returned value of
0FFH indicates failure, usually because some process is DQing from
the queue. A returned value of 0 indicates success.
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 137: READ QUEUE *
* *
***************************************
* Entry Parameters: *
* Register C: 89H *
* DE: UQCB Address *
* *
* Returned Value: *
* Message read *
***************************************
.PP
The READ QUEUE function reads a message from
a specified queue. If no message is available at the queue the
calling process relinquishes the processor until a message is posted
at the queue. The single passed parameter is the address of a user
queue control block.
When a message is available at the queue, it is copied into the
buffer pointed to by the MSGADR field of the user queue control block.
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 138: CONDITIONAL READ *
* QUEUE *
***************************************
* Entry Parameters: *
* Register C: 8AH *
* DE: UQCB Address *
* *
* Returned Value: *
* Register A: Return code *
* Message read if available *
***************************************
.PP
The CONDITIONAL READ QUEUE function reads
a message from a specified queue if a message is available.
The single passed parameter is the address of a user
queue control block.
If a message is available at the queue, it is copied into the
buffer pointed to by the MSGADR field of the user queue control block.
.PP
The operation returns a boolean indicating whether or not a
message was available at the queue. A returned value of
0FFH indicates no message while a zero indicates that a message was
available and that it was copied into the user buffer.
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 139: WRITE QUEUE *
* *
***************************************
* Entry Parameters: *
* Register C: 8BH *
* DE: UQCB Address *
* Message to be sent *
* *
***************************************
.PP
The WRITE QUEUE function writes a message to
a specified queue. If no buffers are available at the queue, the
calling process relinquishes the processor until a buffer is available
at the queue. The single passed parameter is the address of a user
queue control block.
When a buffer is available at the queue, the
buffer pointed to by the MSGADR field of the user queue control block
is copied into the actual queue.
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 140: CONDITIONAL WRITE *
* QUEUE *
* *
***************************************
* Entry Parameters: *
* Register C: 8CH *
* DE: UQCB Address *
* Message to be sent *
* *
* Returned Value: *
* Register A: Return code *
***************************************
.PP
The CONDITIONAL WRITE QUEUE function writes
a message to a specified queue if a buffer is available.
The single passed parameter is the address of a user
queue control block.
If a buffer is available at the queue, the
buffer pointed to by the MSGADR field of the user queue control block
is copied into the actual queue.
.PP
The operation returns a boolean indicating whether or not a
buffer was available at the queue. A returned value of
0FFH indicates no buffer while a zero indicates that a buffer was
available and that the user buffer was copied into it.
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 141: DELAY *
* *
***************************************
* Entry Parameters: *
* Register C: 8DH *
* DE: Number of Ticks *
* *
***************************************
.PP
The DELAY function delays execution of the
calling process for the specified number of system time units.
Use of the delay operation avoids the typical programmed delay
loop. It allows other processes to use the processor while the
specified period of time elapses. The system time unit is typically
60 Hz (16.67 milliseconds) but may vary according to application.
For example it is likely that in Europe it would be 50 Hz (20
milliseconds).
.PP
The delay is specifed as a 16-bit integer. Since calling the delay
procedure is usually asynchronous to the actual time base itself, there
is up to one tick of uncertainty in the exact amount of time delayed.
Thus a delay of 10 ticks gaurantees a delay of at least 10 ticks, but
it may be nearly 11 ticks.
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 142: DISPATCH *
* *
***************************************
* Entry Parameters: *
* Register C: 8EH *
* *
***************************************
.PP
The DISPATCH operation allows the operating system
to determine the highest priority ready process and then to give it the
processor. This call is provided in XDOS to allow systems without
interrupts the capability of sharing the processor among compute
bound processes. Since all user processes usually run at the same
priority, invoking the dispatch operation at various points
in a program will allow other users to obtain the processor
in a round-robin fashion.
Invoking the dispatch function does not take the calling process off
of the ready list.
.PP
Dispatch is intended for non-interrupt driven environments in
which it is desirable to enable a compute bound process
to relinquish the use of the processor.
.pp
Another use of the dispatch function is to safely enable interrupts
following the execution of a disable interrupt instruction (DI).
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 143: TERMINATE PROCESS *
* *
***************************************
* Entry Parameters: *
* Register C: 8FH *
* D: Conditional *
* Memory Free *
* E: Terminate Code *
* *
***************************************
.PP
The TERMINATE PROCESS function terminates
the calling process. The passed parameters indicate whether
or not the process should be terminated if it is a system process
and if the memory segment is to be released.
A 0FFH in the E register indicates that the process should be unconditionally terminated,
a zero indicates that only a user process is to be deleted.
If a user process is being terminated and Register D is a
0FFH, the memory segment is not released. Thus a process
which is a child of a parent process both executing in the
same memory segment can terminate without freeing the
memory segment which is also occupied by the parent.
.pp
There are no results
returned from this operation, the calling process simply ceases
to exist as far as MP/M is concerned.
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 144: CREATE PROCESS *
* *
***************************************
* Entry Parameters: *
* Register C: 90H *
* DE: PD Address *
* *
* Returned Value: *
* PD filled in *
***************************************
.PP
The CREATE PROCESS function creates one
or more processes by placing the passed process descriptors
on the MP/M ready list.
.PP
A single parameter is passed, the address of a process
descriptor. The first field of the process descriptor is a link
field which may point to another process descriptor.
.pp
Processes can only be created either in common memory or by
user programs in non-banked systems. The reason is that
process descriptors are all maintained on linked lists
which must be accessible at all times.
.pp
The process descriptor data structure is described in section 2.3.
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 145: SET PRIORITY *
* *
***************************************
* Entry Parameters: *
* Register C: 91H *
* E: Priority *
* *
***************************************
.PP
The SET PRIORITY function sets the priority of
the calling process to that of the passed parameter. This function
is useful in situations where a process needs to have a high priority
during an initialization phase, but after that is to run at a lower
priority.
.PP
A single passed parameter contains the new process priority. There
are no results returned from setting priority.
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 146: ATTACH CONSOLE *
* *
***************************************
* Entry Parameters: *
* Register C: 92H *
* *
***************************************
.PP
The ATTACH CONSOLE function attaches the console
specified in the CONSOLE field of the process descriptor
to the calling process. If the console is already attached to some
other process,
the calling process relinquishes the processor until the console
is detached from that process and the calling process is the highest
priority process waiting for the console.
.PP
There are no passed parameters and there are no returned results.
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 147: DETACH CONSOLE *
* *
***************************************
* Entry Parameters: *
* Register C: 93H *
* *
***************************************
.PP
The DETACH CONSOLE function detaches the console
specified in the CONSOLE field of the process descriptor
from the calling process. If the console is not currently attached
no action takes place.
.PP
There are no passed parameters and there are no returned results.
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 148: SET CONSOLE *
* *
***************************************
* Entry Parameters: *
* Register C: 94H *
* E: Console *
* *
***************************************
.PP
The SET CONSOLE function detaches the currently
attached console and then attaches the console specified as a calling
parameter. If the console to be attached is already attached to
another process descriptor, the calling process relinquishes the
processor until the console is available.
.PP
A single passed parameter contains the console number to be attached.
There are no returned results.
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 149: ASSIGN CONSOLE *
* *
***************************************
* Entry Parameters: *
* Register C: 95H *
* DE: APB Address *
* *
* Returned Value: *
* Register A: Return code *
***************************************
.PP
The ASSIGN CONSOLE function directly assigns
the console to a specified process. This assignment is done regardless
of whether or not the console is currently attached to some other
process.
A single parameter is passed to assign console which is the address
of a data structure containing the console number for the assignment,
an 8 character ASCII process name, and a boolean indicating whether
or not a match with the console field of the process descriptor
is required (true or 0FFH indicates it is required).
.PP
The operation returns a boolean indicating whether or not the
assignment was made. A returned value of 0FFH indicates failure to
assign the console, either because a process descriptor with the
specified name could not be found, or that a match was required and
the console field of the process descriptor did not match the
specified console. A returned value of zero indicates a successful
assignment.
.sp 2
.cp 24
.li
***************************************
* *
* FUNCTION 150: SEND CLI COMMAND *
* *
***************************************
* Entry Parameters: *
* Register C: 96H *
* DE: CLICMD Address *
* *
***************************************
.PP
The SEND CLI COMMAND function permits running
programs to send command lines to the Command Line Interpreter.
A single parameter is passed which is the address of a data
structure containing the default disk/user code, console and command
line itself (shown below).
.pp
The default disk/user code is the first byte of the data structure.
The high order four bits contain the default disk drive and the low
order four bits contain the user code. The second byte of the data
structure
contains the console number for the program being executed. The
ASCII command line begins with the third byte and is terminated with
a null byte.
.PP
There are no results returned to the calling program.
.pp
The following example illustrates the SEND CLI COMMAND data
structure:
.li
PL/M:
Declare CLI$command structure (
disk$user byte,
console byte,
command$line (129) byte);
Assembly Language:
CLICMD:
DS 1 ; default disk / user code
DS 1 ; console number
DS 129 ; command line
.ad
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 151: CALL RESIDENT *
* SYSTEM PROCEDURE *
***************************************
* Entry Parameters: *
* Register C: 97H *
* DE: CPB Address *
* *
* Returned Value: *
* Registers HL: Return code *
***************************************
.PP
The CALL RESIDENT SYSTEM PROCEDURE function
permits programs to call the optional resident system procedures.
A single passed parameter is the address of a call parameter
block data structure (shown below) which contains the address of an 8 character ASCII
resident
system procedure name followed by a two byte parameter to be passed
to the resident system procedure.
.PP
The operation returns a 0001H if the resident system procedure called
is not present, otherwise it returns the code passed back from
the resident system procedure. Typically a returned value of FFH
indicates failure while a zero indicates success.
.pp
The following example illustrates the call parameter block data
structure:
.li
PL/M:
Declare CALL$PB structure (
Name$adr address,
Param address ) initial (
.name,0);
Declare name (8) byte initial (
'Proc1 ');
Assembly Language:
CALLPB:
DW NAME
DW 0 ; parameter
NAME:
DB 'Proc1 '
.ad
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 152: PARSE FILENAME *
* *
***************************************
* Entry Parameters: *
* Register C: 98H *
* DE: PFCB Address *
* *
* Returned Value: *
* Registers HL: Return code *
* Parsed file control block *
***************************************
.PP
The PARSE FILENAME function prepares a file
control block from an input ASCII string containing a file name
terminated by a null or a carriage return.
The parameter is the address of a data structure (shown below) which contains
the address of the ASCII file name string followed by the address of
the target file control block.
.PP
The operation returns an FFFFH if the input ASCII string contains an
invalid file name. A zero is returned if the ASCII string contains
a single valid file name, otherwise the address of the first character
following the file name is returned.
.pp
The following example illustrates the parse file name control block
data structure:
.li
PL/M:
Declare Parse$FN$CB structure (
File$name$adr address,
FCB$adr address ) initial (
.file$name,.fcb );
Declare file$name (128) byte;
Declare fcb (36) byte;
Assembly Language:
PFNCB:
DW FLNAME
DW FCB
FLNAME:
DS 128
DS 36
.ad
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 153: GET CONSOLE NUMBER *
* *
***************************************
* Entry Parameters: *
* Register C: 99H *
* *
* Returned Value: *
* Register A: Console Number *
***************************************
.PP
The GET CONSOLE NUMBER funtion obtains
the value of the console field from the process descriptor of
the calling program. There are no passed parameters and the
returned result is the console number of the calling process.
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 154: SYSTEM DATA ADDRESS *
* *
***************************************
* Entry Parameters: *
* Register C: 9AH *
* *
* Returned Value: *
* Registers HL: System Data Page*
* Address *
***************************************
.PP
The SYSTEM DATA ADDRESS function obtains
the base address of the system data page. The system data page
resides in the top 256 bytes of available memory. It contains
configuration information used by the MP/M loader as well as
run time data including the submit flags.
The contents of the system data page are described in section 3.4
under SYSTEM DATA.
.pp
There are no passed parameters and the returned result is the
base address of the system data page.
.sp 2
.cp 18
.li
***************************************
* *
* FUNCTION 155: GET DATE AND TIME *
* *
***************************************
* Entry Parameters: *
* Register C: 9BH *
* DE: TOD Address *
* *
* Returned Value: *
* Time and date *
***************************************
.PP
The GET DATE AND TIME function obtains the
current encoded date and time. A single passed parameter is the
address of a data structure (shown below) which is to contain the date and time.
The date is represented as a 16-bit integer with day 1 corresponding
to January 1, 1978. The time is respresented as three bytes:
hours, minutes and seconds, stored as two BCD digits.
.pp
The following example illustrates the TOD data structure:
.li
PL/M:
Declare TOD structure (
date address,
hour byte,
min byte,
sec byte );
Assembly Language:
TOD: DS 2 ; Date
DS 1 ; Hour
DS 1 ; Minute
DS 1 ; Second
.ad
.sp 2
.cp 15
.li
***************************************
* *
* FUNCTION 156: RETURN PROCESS *
* DESCRIPTOR ADDRESS *
***************************************
* Entry Parameters: *
* Register C: 9CH *
* *
* Returned Value: *
* Register HL: PD Address *
***************************************
.pp
The RETURN PROCESS DESCRIPTOR ADDRESS function obtains the
address of calling processes process descriptor. By definition
this is the head of the ready list.
.sp 2
.cp 17
.li
***************************************
* *
* FUNCTION 157: ABORT SPECIFIED *
* PROCESS *
***************************************
* Entry Parameters: *
* Register C: 9DH *
* Register DE: APB Address *
* *
* Returned Value: *
* Register A: Return Code *
***************************************
.pp
The ABORT SPECIFIED PROCESS function permits a process to
terminate another specified process. The passed parameter is the
address of an Abort Parameter Block (ABTPB) which contains the
following data structure:
.li
PL/M:
Declare Abort$paramter$block structure (
pdadr address,
termination$code address,
name (8) byte,
console byte );
Assembly Language:
APB:
DS 2 ; process desciptor address
DS 2 ; termination code
DS 8 ; process name
DS 1 ; console used by process
.ad
.pp
If the process descriptor address is known it can be filled in and
the process name and console can be omitted. Otherwise the process
descriptor address field should be a zero and the process name and
console must be specified. In either case the termination code
must be supplied which is the parameter passed to FUNCTION 143:
TERMINATE PROCESS.
.br


166
MPM OPERATING SYSTEMS/MPM I/MPM I SOURCE/14/mpmug24.tex Normal file
View File

@@ -0,0 +1,166 @@
.MB +5
.MT -3
.LL 65
.PN 81
.HE MP/M User's Guide
.FT (All Information Herein is Proprietary to Digital Research.)
.sp
.pp
2.5 Preparation of Page Relocatable Programs
.pp
A page relocatable program is stored on diskette as a file of type
'PRL'. Appendix K contains a PRL file specification describing
the file format. A page relocatable program is prepared by
assembling the source program twice, in which the second
assembly has 100H added to each ORG statement.
The two hex files generated by assembling the source file twice are
concatenated with PIP and then provided as input to the GENMOD
program. The GENMOD program (described in section 1.4) produces a file of type 'PRL'.
.pp
This section describes APPENDIX G: Sample Page Relocatable
Program. The example program
illustrates the required use of ORG statements to access the
BDOS and the default file control block. Note that the initial
ORG is 0000H. Its purpose is to establish the equate for the symbol BASE,
the base of the relocatable segment. Next an ORG 100H statement
establishes the actual beginning of code for the program.
During the second assembly these two ORG statements are changed to
100H and 200H respectively. Note that the first assembly will
generate a file which can be LOADed to produce an executable 'COM'
file. In fact, it is desirable to first debug the program as a
'COM' file and then proceed to make the 'PRL' file.
.PP
It is VERY important to use BASE to offset all memory segment base page
references! Do not make a call to absolute 0005H for BDOS
calls. In this example BASE is used to offset the BDOS, FCB, and
BUFF equates. When a user program needs to determine the top of
its memory segment the following equate and code sequence should
be used:
.li
MEMSIZE EQU BASE+6
...
LHLD MEMSIZE ;HL = TOP OF MEMORY SEGMENT
.BR
The following steps show how to generate a page relocatable
file for this example using the Digital Research Macro Assembler (MAC):
.LI
* Prepare the user program, DUMP.ASM in this example, with
proper origin statements as described above.
* Assuming a system disk in drive A: and the DUMP.ASM file
is on drive B:, enter the commands-
1A>MAC B:DUMP $PP+S
;assemble and list the DUMP.ASM file
1A>ERA B:DUMP.HX0
1A>REN B:DUMP.HX0=B:DUMP.HEX
1A>MAC B:DUMP $PZSZ+R
;assemble the DUMP.ASM file again, offset by 100H
;the offset is generated with the +R MAC option
1A>PIP B:DUMP.HEX=B:DUMP.HX0,B:DUMP.HEX
;concatenate the HEX files
1A>GENMOD B:DUMP.HEX B:DUMP.PRL
;generate the relocatable DUMP.PRL file
.BR
.pp
The following steps show how to generate a page relocatable
file for this example using the Digital Research Assembler (ASM):
.li
* Prepare the user program, DUMP.ASM in this example, with
proper origin statements as described above.
* Assuming a system disk in drive A: and the DUMP.ASM file
is on drive B:, enter the commands-
1A>ASM B:DUMP
;assemble the DUMP.ASM file
1A>ERA B:DUMP.HX0
1A>REN B:DUMP.HX0=B:DUMP.HEX
1A>PIP LST:=B:DUMP.PRN[T8]
1A>ERA B:DUMP.PRN
* Edit the DUMP.ASM file, adding 100H to each ORG statement.
This can be done by concatenating a preamble to the
program which contains the two initial ORG statements.
A submit file to perform this function, named ASMPRL.SUB
is provided on the distribution diskette.
1A>ASM B:DUMP.BBZ
;assemble the DUMP.ASM file a second time
1A>PIP B:DUMP.HEX=B:DUMP.HX0,B:DUMP.HEX
;concatenate the HEX files
1A>GENMOD B:DUMP.HEX B:DUMP.PRL
;generate the relocatable DUMP.PRL file
.br
.BP
.pp
2.6 Installation of Resident System Processes
.pp
This section contains a description of APPENDIX H: Sample Resident
System Process. The example program
illustrates the required structure of a resident system process as well
as the BDOS/XDOS access mechanism.
.PP
The first two bytes of a resident system process are set to the
address of the BDOS/XDOS entry point. The address is filled in by the
loader, providing a simple means for a resident system process to
access the BDOS/XDOS by loading HL from the base of the program area and
then executing a PCHL instruction.
.PP
The process descriptor for the resident system process must immediately
follow the first two bytes which contain the address of the BDOS/XDOS
entry point. Observe the manner in
which the process descriptor is initialized in the example. The DS's
are used where storage is simply allocated. The DB's and DW's are used
where data in the process descriptor must be initialized.
Note that the stack pointer field of the process descriptor points to
the address immediately following the stack allocation.
This is the return address which is the actual process entry point.
.pp
It is important that the HEX file generated by assembling the RSP
span the entire program and data area. For this reason the first two
bytes of the resident system process which will contain the address
of the BDOS/XDOS entry point are defined with a DW. Using a DS
would not generate any HEX file code for those two bytes.
The end of the program and data area must be defined in a likewise
manner. If your RSP has DS statements preceding the END statement
it will be necessary to place a DB statment after the DS statements
before the END statement.
.PP
The steps to produce a resident system process closely follow
those illustrated in the previous section on page relocatable programs.
The only exception to the procedure is that the GENMOD output file
should have a type of 'RSP' rather than 'PRL' and the code in the
RSP is ORGed at 000H rather than 100H.
.pp
In addition to resident system processes MP/M supports resident system
procedures. The purpose of a resident system procedure is to
provide a means to use a piece of code as a serially reusable
resource. A resident system procedure is set up by a resident system
process. The function of the process is to create a queue which has
the name of the resident system procedure and to send it one 16 bit
message containing the address of the resident system procedure.
Once this is accomplished the resident system process
terminates itself. Access to the resident system procedure is made by
opening the queue with the resident system procedure name and then
reading the two byte message to obtain the actual memory address of
the procedure itself.
Since there is only one message posted at the queue, only one process
will gain access to the procedure at a time. When the process
executing the resident system procedure leaves the procedure it
sends the two byte message containing the procedure address back
to the queue. This action enables the next waiting process to
use the resident system procedure.
.pp
When the MP/M system generation program is executed it searches the
directory for all files with the type 'RSP'. The user is then
prompted with the file name and asked if it should be included in
the generated system file.
.BR