mirror of
https://github.com/SEPPDROID/Digital-Research-Source-Code.git
synced 2025-10-26 09:54:20 +00:00
166 lines
6.8 KiB
TeX
166 lines
6.8 KiB
TeX
.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
|
||
|