Digital PDFs

AA-P309A-TV

April 1983

42 pages

Original

2.1MB

Document:	Rainbow 100 CPM-86 80 Software Design and Maintenance Manual
Order Number:	AA-P309A-TV
Revision:
Pages:	42
Original Filename:	http://bitsavers.org/pdf/dec/rainbow/AA-P309A-TV_Rainbow_100_CPM-86_80_Software_Design_and_Maintenance_Manual_Apr83.pdf

OCR Text

AA-P309A-TV

RainbowTM

100
CP/M-86/S0 Software Design
and Maintenance Manual

digital equipment corporation

First Printing, April 1983
© Digital Equipment Corporation 1983. All Rights Reserved.

The information in this document is subject to change without notice and should
not be construed as a commitment by Digital Equipment Corporation. Digital
Equipment Corporation assumes no responsibility for any errors that may
appear in this document.
The software described in this document is furnished under a license and may
only be used or copied in accordance with the terms of such license.
No responsibility is assumed for the use or reliability of software on equipment
that is not supplied by DIGITAL or its affiliated companies.
CP/M®, CP/M®-80 and CP/M®-86 are registered trademarks of Digital
Research Inc.
Z80® is a registered trademark of Zilog, Inc.
8088® is a registered trademark of Intel Corporation.
The following are trademarks of Digital Equipment Corporation:

~D~DD~DTM
DEC
DECmate
DECsystem-10
DECSYSTEM-20
DECUS
DECwriter
DIBOL

MASSBUS
PDP

P/OS
Professional
Rainbow
RSTS
RSX

UNIBUS
VAX
VMS

VT
Work Processor

The postage-prepaid READER'S COMMENTS form on the last page of this
document requests the user's critical evaluation to assist us in preparing future
documentation.

Printed in U.S.A.

CONTENTS

SYSTEM ORGANIZATION • • • • •
• • ••
1
SYSTEM OVERVIEW
• • • • • • • • • •
• 5
Utilities • • • • • • • •
• • 5
LDCOPY (8088 executable) • • • •
• • 5
SAVE (8088 executable) •
• • 5
Bootstrap Programs (Z80 executable)
• 5
BOOT100 • • • • • •
• • • • • 6
BOOT1 0 1 • • • • • • • • • • • •
• • • • • • 6
CROSS-CPU COMMUNICATION
• • 6
CPM. SYS • • • • • • • •
• • • •
• 9
CCP Patches • • • • •
• • • • •
• • 9
Saving the Boot Drive Number •
• •••••• 9
Allowing Z80 Transients
• 9
BOOS Patches • • • • • • • • • •
• • • •• 11
BDOS Function 10 -- delete-character
11
modification • • • ••
•••••
11
MOVE Routine - call to new BIOS function •
4.2.2
12
4.3
Digital Research Patches • •
12
5.0
BIOS . • • • • . • • • . • • ..
12
5.1
Initialization • • • • • • • • • • • •
5.2
BIOS Character I/O Routines
13
5.2.1
Hardware Device Drivers
13
5.2.1.1
Console I/O • • • • • • •
14
5.2.1.2
Control Blocks • • • • • • •
14
5.2.1.3
Serial Port Initialization •
15
15
5.2.1.4
Input and Output • • • • • • • • • •
5.2.2
Physical Device Drivers
15
5.2.2.1
Mapping of Device Names to Ports •
15
16
5.2.2.2
Relation to Hardware Device Drivers
16
5.2.3
Logical Device Drivers •
5.2.3.1
I/O Redirection (IOBYTE)
16
5.2.3.2
Default I/O Assignments
16
5.3
BIOS Interrupt Handlers
• • • • • •
16
5.3.1
RS-232 Receive Ready.
•••••
17
5.3.2
Z80 Interrupts • • • • • • • • • • • • • •
18
5.4
• • • •
18
BIOS Disk I/O Routines • • • •
5.4.1
Logical I/O Routines • • •
•• • • •
19
5.4.2
Blocking and Deblocking
• • • • •
20
5.4.3
Error Message Display
••••••
20
5.4.4
Physical I/O Routines
• • • • •
21
21
5.5
BIOS Utility Subroutines •
21
5.5.1
Message Display • • • •
21
Decimal Number Display
5.5.2
21
6.0
INTERFACE LAYER • • • • • • • • • •
6.1
21
Interface Layer Initialization •
6.2
22
Z80 Interruption • • •
Z80 Request Interrupts
6.3
22
7.0
PRIMITIVE ROUTINES • • • • •
22

1.0
2.0
2.1
2.1.1
2.1. 2
2.2
2.2.1
2.2.2
3.0
4.0
4.1
4.1.1
4.1. 2
4.2
4.2.1

iii

CONTENTS (Cont.)

7.1
7.1.1
7.1. 2
7.1.2.1
7.1.2.2
7.1.2.3
7.1.2.4
7.1.2.5
7.1.2.6
7.2
7.3
8.0
8.1
8.2'
8.3
8.4
8.5
9.0
9.1
9.2
9.3
9.3.1
9.3.2
9.3.3
9.3.4
10.0
10.1
10.2
10.2.1
10.2.2
10.2.3
10.2.4
10.2.5
10.2.6
10.3
10.3.1
10.3.2
10.3.3
10.3.4
10.3.5
10.4
10.4.1
10.4.2
11.0
12.0

Disk I/O . . . . . . . . . . . . . . . . . .
Check Media • • • • • • • • • • •
Read/Write Sector(s) • • • • • •
Read/Write Sector(s) Processing
Drive Ready
Disk Home
Disk Seek
Disk I/O Loop •
Read/Write Error Recovery • • • •
MOVE • • • • • • • •
Start Z80 • • • • • • • • • • • • •
PSEUDO BDOS AND PSEUDO BIOS • • • •
IOBYTE • • • • • • •
Cold and Warm Boot •
BIOS SECTRAN •
Reply Latency
Console Status Checks • • • •
•••••
Z80CCP.SYS • • • • • • • • • • •
• ••••
Z80 Transient System Configuration •
8088 Transient System Configuration
Executing a Z80 Transient • • • • •
Initialization for Z80 Transients
Code Relocation • • • • • • •
••• •
Loading and Executing the .COM File
Z80 Service Routine • • • • • • • • • • • •
SYSTEM DISK GENERATION • • • • • • • • • • • • • .
System Disk Generation Requirements
Preparation of System Files
BOOTI00.SYS
.•••
BOOTI0l.SYS . . • • • • • •
LOADER.CMD • •
Z80BASE.COM • • • • •
PRMTVPVT.SYS •
File Placement: System Tracks • • • • •
Preparation of System Files for Data Tracks
CPM.SYS
•••••
Z80CCP.SYS • • • • • • • • • • • •
Z8 O. SYS
• • • • • • • . • • •
PRMTVPVT. SYS • • • • • • • • • • •
Placement of Files: Data Tracks
Utility File Preparation • • • • • • • • • • •
LDCOPY.CMD • • • • •
• ••••
SAVE.CMD • • • • • •
SUBMIT.CMD MODIFICATION
LISTINGS • • • • • • • •

23
23
23
23
23
24
24
24
24
24
25
25
26
26
26
26
26
26
27
27
27
27
28
28
28
30
30
30
31
31
31
32
32
32
33
33
34
34
34
34
34
34
35
35
36

FIGURES
1-1
1-2
1-3
3-1
3-2

CP/M-86/80 Initial Configuration • • • • • • • • • •
Z80 Transient Execution Execution (63K System).
Z80 Transient Execution (128K or greater System) • •
8088 Code Guide for Cross-CPU Communication
•
Z80 Code Guide for Cross-CPU Communication • • • • •

2
3
4
7
8

1.0

SYSTEM ORGANIZATION

The CP/M-86/80 operating system (Version 1.0) is an enhanced version
of CP/M-86 V1.1 The enhancements allow the operating system to execute
both Z80 processor and 8088 processor transients.
The system is initially configured to provide the largest available
transient program area (TPA)
to ~088 transients (03000H to top of
RAM). The CP/M-86/80 operating system is therefore placed at 400H,
above the 8088 interrupt vectors.
A data block needed for Z80
interfacing is located just above the CP/M-86/80 operating system.
See Figure 1-1.
When a Z80 transient is requested, the system must be reconfigured to
allow the transient to start executing at 100H. Therefore, all needed
modules must be placed as high in memory as possible to make the
largest TPA available to Z80 transients. See Figures 1-2 and 1-3.

(If Available)
64K ____________________
1
1
1

1
1

TPA

1
1
1
1
1

1
1

1--------------------------------------------3DOOH
1
Data Block
1--------------------------------------------1
1

CPM.SYS : 8088

1
1

2K - 800H I

1--~D~~r;s~k~I~7~O~a-n~d~------I~------------------

1
1
1

Interface Layer
Z80
Figure 1-1

1--------------------1 Interrupt Vectors
1

------~8~0~8~8---------

CP/M-86/80 Initial Configuration

lK - 400H

64K

11
11
Interface Layer : ZSO
1-------------------------------------------1
1
Disk I/O Primitives : ZSO
1
1------------------------------------------1
Pseudo BIOS, BOOS, CCP : zao
1------------------------------------------1
CPM.SYS : SOSS

1
1

1------------------------------------------1
Jump To Pseudo BOOS
(BFOO) *1------------------------------------------1
1
1
1

TPA

1
I
I
I
1

1
I
I
I
1 2K

1
1

I
I

Z80 Service
Routine

1
1

1--------------------1 1K

I Interrupt Vectors

I _ _ _-="'~_-_-I
ZSO
Figure 1-2

I
SOSS

ZSO Transient Execution (64K System)

* Location S = JMP BF06.
Therefore,
the
maximum
TPA
is
BF40(Hex)-100(Hex) = BEOO which is approximately equal to 47.SK bytes.
3

1
1
1
1

CPM.SYS

8088

64K

1
1

1
Interface Layer : Z80
1
-------------------------------------------
1
Disk I/O Primitives : Z80
1

1-------------------------------------------1
1 Pseudo BIOS, BOOS, CCP : Z80
1
1-------------------------------------------1
Jump To Pseudo BOOS
1
61K

-------------------------------------------11

1
1
1
1
1

1
1

1
1 2K

1 ----~Z8~0~S~e-r-v-i~c-e-----1
1
Routine
1

1--------------------1 lK

--------~z·~S~6---------

Figure 1-3

1 Interrupt Vectors
I

SOBS

1
1

Z80 Transient Execution (128K or greater System)

2.0

SYSTEM OVERVIEW

Patches made to the CCP and BOOS within the CPM.SYS file allow the
CP/M-S6/S0 operating system to execute both ZSO and SOSS transients.
Patches released by Digital Research Inc. have also been applied (see
Sections 4.1, 4.2 and 4.3. The BIOS portion of CPM.SYS is written to
support the operating system facilities of CP/M on the Rainbow lOOts
dual CPU.
A ZSO executable Interface Layer module handles the
cross-CPU
communication for the ZSO. This module is physically combined with
the Primitive Routines which perform functions the SOSS cannot, as
follows:
1.

Disk I/O

Moving to/from private ZSO memory from/to shared memory

Executing ZSO code at a specific location

A pseudo BOOS and pseudo BIOS (ZSO executable) module stores a ZSO
transient's BOOS/BIOS parameters in shared RAM and via the Interface
Layer, transfers control to the waiting ZSO Service Routine in private
SOSS memory.
The system must be reconfigured prior to the execution of a ZSO
transient.
To accomplish this, the system loads ZSOCCP.SYS (SOSS
executable). This module is also used to reconfigure the system
before resuming the execution of SOSS transients.
While the ZSO transient is executing, the SOSS waits in its ZSO
Service Routine (in private SOSS memory) for BOOS and BIOS requests
from the ZSO. When the ZSO Service Routine gets control, it analyzes
the parameters and then performs the actual BOOS call.
Buffers and data areas necessary for cross-CPU communication and
system reconfiguration are contained in the Pointers/Buffers Data
Block. This data block must reside in shared memory.

2.1

Utilities

2.1.1 LDCOPY (8088 executable) - This program
tracks on a Rainbow 100 formatted disk.

the

system

2.1.2 SAVE (8088 executable) - This program saves a specified
of pages of ZSO memory into a specified file.

number

2.2

Bootstrap Programs (Z80 executable)

creates

2.2.1 BOOTIOO - This bootstrap program resides on the first sector of
the first track and is loaded by the Read Only Memory (ROM). When
BOOTIOO receives control, it reads the remainder of the first track
and the entire second track by doing direct disk I/O. These tracks
contain the loader program (8088 executable) and the interface and
primitive routines (Z80 executable) needed for loading CPM.SYS and for
executing the CP/M-86/80 operating system.

2.2.2 BOOTIOI - The BOOTIOl program resides on the first sector of
the second track. It is essentially the same as BOOTIOO, but includes
preface information required by the RX50 bootstrap specification.
(This file is not included in the CP/M-86/80 operating system BIOS
listings. The code is not executed.)

3.0

CROSS-CPU COMMUNICATION

The 8088 and the Z80 communicate via message packets. When either CPU
requests service from the other, the address of the message packet
(packet pointer) is stored into an agreed upon location and the
"master" CPU interrupts the "slave" CPU. The "master" waits while the
"slave" CPU retrieves the packet pointer, performs the requested
function, and indicates completion by interrupting the "master." See
Figures 3-1 and 3-2.
The 8088 and the Z80 reverse master and slave roles when the 8088
requests the Z80 to start executing at a specific address -- the Z80
is now the "master" and the 8088 is the "slave." When the Z80 is
finished, it does a BOOS call 0 to make the 8088 the "master" CPU
again and the Z80 the "slave".
All message packets and the packet pointers must be in shared Random
Access
Memory (RAM).
Message packets are constructed for the
following functions:
FUNCTION
CODE (HEX)

FUNCTION

MASTER
CPU

Reads one sector on a
specified drive

8088

Writes one sector on a
specified drive

8088

Check media on a specified drive

8088

Start a Z80 program at a specified
address

8088 to Z80

Move blocks of data in Z80 RAM space

8088

>40

BOOS/BIOS
(for BOOS call 0) ----->

Z80
Z80 to 8088

See Sections 7.1 through 7.3 for message packet formats.

8088 REQUESTING Z80 SERVICE (disk/move)
======================================

(Code exists in the CP/M-86/80 operating system BIOS)
clear done flag
store packet address (in data block)
interrupt Z8D
wait for Z80 to clear interrupt
wait for done flag to be set <---(interrupt 39)
get packet address (in BIOS)
8088 REQUESTING Z80 SERVICE (start)
================================:==

(Code exists in Z80CCP.SYS in private 8088 memory)
clear done flag
store packet address (in data block)
interrupt Z80
wait for Z80 to clear interrupt
go to 8088 Service Loop (see below)
8088 SERVICE LOOP FOR Z80 REQUESTS (BOOS/BIOS)
=============================================

(Code exists in Z80CCP.SYS in private 8088 memory)
wait for done flag to be set <---(interrupt 39)
get packet address (in BIOS)
perform BOOS/BIOS function
(if function is BOOS call 0, control is not returned
to this loop but to the ccp)
set status in packet
clear done flag
store packet address (in data block)
interrupt Z80
wait for Z80 to clear interrupt
8088 INTERRUPT 39 SERVICE ROUTINE
=================================

(Code exists in the CP/M-86/80 operating system BIOS)
clear interrupt
retrieve packet address (in data block)
save packet address (in BIOS)
set done flag
interrupt return
Figure 3-1

8088 Code Guide for Cross-CPU Communication

Z80 REQUESTING 8088 SERVICE (BOOS/BIOS)
======================================
clear done flag
store packet address (in data block)
interrupt 8088
wait for 8088 to clear interrupt
wait for done flag to be set (---(RST 6)
(If the routine called returns data)
Z80 SERVICE LOOP FOR 8088 REQUESTS (disk/move/start)
====================================================
halt (wait for interrupt from 8088)
Z80 RST 6 SERVICE ROUTINE
=========================
clear interrupt
retrieve packet address (in data block)
get packet function code
if
function is a Z80 function (disk/move/start)
perform function
(if function is start, control is not returned
to this routine; a BOOS call 0 is eventually done
instead)
set status in packet
store packet address (in data block)
interrupt 8088
wait for 8088 to clear interrupt
else
set done flag
endif
interrupt return
Figure 3-2

Z80 Code Guide for Cross-CPU Communication

4.0

CPM.SYS

4.1

CCP Patches

The following changes are applied as patches against the CP/M-86
operating system V1.1. They exist in the file CPLPATCH.A86 with the
BDOS patches. The patch space is ORG'd after the BIOS.

4.1.1 Saving the Boot Drive Number - The system loads system files
from the boot disk, so it must save the boot drive number to use in
the File Control Blocks (FCB's). This boot drive number is passed
from the boot routine to the loader to the CP/M-86/80 cold start
routine (in BIOS) and then to the CCP where it is saved.
MODIFICATIONS TO CODE
New code is marked by an asterisk (*) in the left margin.
CCPSTART:

BOOTDRV

MOV
MOV
CALL

CDISK,AL
BOOTDRV,AL
SELECT

;SAVE BOOT DRIVE#

4.1.2 Allowing Z80 Transients - When a transient is requested, a test
is made for the existence of a .CMD file.
If it exists, and if it is
not SAVE.CMD, and if the system is currently configured for 8088
transients, the .CMD file is loaded and executed as in CP/M-86.
If
the system must be reconfigured, Z80CCP.SYS is loaded from the boot
disk and executed. Upon return, the .CMD file is loaded and executed.
If a .CMD file does not exist when a transient is requested, a test is
made for the existence of a .COM file.
If a .COM file exists,
Z80CCP.SYS is loaded and executed. Z80CCP.SYS reconfigures the system
if necessary, loads the .COM file, and turns control over to the Z80
for execution of the .COM file.
Note that if SAVE(.CMD) is requested, it runs only if the most recent
transient was a .COM file.
SAVE.CMD is created using GENCMD SAVE 8080
CODE[A40]. This insures that SAVE is loaded in private 8088 space so
that the data in Z80 private space and shared memory can be saved
undisturbed.
If the most recent transient was a .CMD file, the CP/M-86/80 operating
system occupies the space where SAVE is to be loaded and CP/M returns
with a 'MEMORY NOT AVAILABLE' message.

See Section
conditions.

9.0

for

Z80CCP

parameters,

return

codes,

and

error

MODIFICATIONS TO CODE
Code is modified where the CCP tests for a .CMD transient:
New code is m~rked by an asterisk (*) in the left margin:
code is marked by a semicolon (i) in the left margin.

deleted

USERFI:
CALL

SETDSK

MOV

SI,OFFSET CMDTYPE

CALL
OPENC
JNZ
LOADUSER
(new code to load Z80CCP.SYS if necessary)
CALL
RESETDISK

MODIFICATIONS TO CODE
A new label is added after the user FCB information has been
determined before the information is moved to the user's page O. This
label is needed to execute the .CMD file after the system is
reconfigured.
GOUSER:

MOV
MOV

COMFCB+16,AL
BYTE PTR COMPEC,OH

MOV

DI,USERFCB

GOUSERI:

MODIFICATIONS TO CODE
Code is also modified just before the registers
doing a CALLF to execute the .CMD transient:

are

reset

BMOVE3 :

MOV
MOV
(new code
MOV
MOV

BPTR,OH
COMLEN,OOH
to run Z80CCP.SYS if necessary)
ES,PAGO
DS,PAGO

prior

4.2

BOOS Patches

The following changes are applied as patches against the CP/M-86
operating system Vl.l. They exist in the file CPLPATCH.A86 with the
cep patches. The patch space is ORG'd after the BIOS.

4.2.1 BOOS Function 10 -- delete-character modification - A
modification has been made to BOOS to make the delete character behave
like a backspace character.
MODIFICATIONS TO CODE
New code is marked by an asterisk (*) in the left margin;
code is marked by a semicolon (;) in the left margin.

deleted

L19:

JNZ

NOTH

CH,CH

CMP
JNZ
JMPS
OR
JZ
MOV
DEC
DEC
JMPS

AL,RUBOUT
NOTRUB
DOBACKSP
CH,CH
READNX
AL,ES: [BX]
CH
BX
RDECHI

DOBACKSP:

NOTH:

4.2.2 MOVE Routine - call to new BIOS function - Whenever
data
is
moved to a user's data area, a test must be made to determine if the
data to be moved is/will be in private Z80 space.
This
is
accomplished by calling a new BIOS function which performs the test
and data move.
MODIFICATIONS TO CODE
New code is marked by an asterisk (*) in the left margin;
code is marked by a semicolon (;) in the left margin.

deleted

ZMOVEF

EQU

2500+(3*21)

MOVE:

MOV
MOV
CLD
REP MOVS
CALL
POP

;

4.3

SI,DX
DI,BX
AL,AL
ZMOVEF
CX

Digital Research Patches

Digital Research Inc. patches to CP/M-86 Vl.l CCP and BDOS have been
applied to the CP/M-86/80 operating system. They are contained in the
DRIPATCH.A86 file.

5.0

BIOS

The source code of the BIOS (in
seven sections:

file

CPLBIOS.A86)

divided

into

The jump table at the beginning of the BIOS provides entry
points to the 21 functions specified in Digital Research Inc.
documentation and to 2 functions which have been added for
the CP/M-86/80 operating system.

The initialization routines (in INCLUDEd
are described in Section 5.1.

The character input/output routines
(in
INCLUDEd
file
CPLBIOSl.A86)
handle single character I/O functions for the
console, list, reader, and punch devices. These routines are
described in Section 5.2.

The interrupt handlers
(in INCLUDEd file
CPLBIOSl.A86)
process the serial port receive and Z80 interrupts. These
handlers are described in Section 5.3.

The disk input/output routines (in INCLUDEd files CPLBLOK.LIB
and CAT. LIB) perform all CP/M disk functions, including
blocking and deblocking. They are described in Section 5.4.

The utility subroutines, described in Section 5.5,
to display error messages.

The data area is in INCLUDEd file CPLBIOS2.A86.

file

CPLBIOSl.A86)

are

used

5.1

Initialization

The cold boot routine, INIT,
functions:

performs

the

following

initialization

•

Sets the segment register values and the stack

•

Sets the IOBYTE to its default setting

•

Indicates that the Z80 is not running

•

Initializes the interrupt vectors

•

Displays the signon message

•

Transmits the default disk drive identity to the CCP

•

Initializes the serial I/O ports

INIT clears the screen and sets the cursor at line 3 before displaying
the signon message.
The warm boot routine, WBOOT, performs
functions:

5.2

the

following

•

Indicates that the Z80 is not running

•

Initializes the interrupt vectors

•

Initializes the serial I/O ports

initialization

BIOS Character I/O Routines

The character I/O routines handle all input and output for the CP/M
console, list, reader, and punch devices. The routines operate at
three levels: the logical level (which CP/M sees), the physical level
(which CP/M uses for I/O redirection), and the hardware level. These
are described below.

5.2.1 Hardware Device Drivers - The hardware device drivers are at
the lowest level of the character I/O hierarchy.
All console
input/output is handled by the ROM via software interrupt 40.
The
serial port drivers for the communications port and the printer are
described below.
There is also a set of drivers for null devices.
The null input
driver, PNULIN, returns end-of-file (control-Z) at each call. The
null output driver, PNULOUT, returns immediately.
The input and
output null status test drivers, PNULSTI and PNULSTO, always return a
"ready" status.

5.2.1.1 Console I/O - All console input and output is handled by
ROM. The parameters are passed in the registers as follows:

the

CONSOLE OUT (CRTOUT)
DI = function code = 0
AL = ASCII character code
CONSOLE IN (CRTIN)
DI
function code = 2
AL = returned character
CL = returned status
o = no character available
FF = character available in AL

CONSOLE IN STATUS (CRTSTI)
DI = function code = 4
CL = returned status
o = no character available
FF = character available
The BIOS uses these ROM routines for Console In, Console Out, and
Console Status. Console Out simply invokes ROM function 0 and Console
Status invokes ROM function 2. It repeats this until a character
becomes available.
Therefore, it always returns with a character.
The BIOS also contains a CRTSTO routine which returns a "ready"
status.

5.2.1.2 Control Blocks - Each serial
port
(Communications
and
Printer)
is associated with a control block which contains the port
address, input processing information, and an input buffer for the
port.
This control block is used by all communication routines that
access the physical device.
The format of the control block is:
OFFSET

NAME

CONTENTS

QTPORT

Control port address

QTFLAGS

Processing flags
Bit 0 set to suspend output
Bit 1 set for XON/XOFF
Bit 2 set if initialization required

QTNRCHR

Number of characters currently in buffer

QTCAP

Buffer capacity in bytes

QTINPTR

Buffer input pointer
(offset
of
character to be stored in buffer)

QTOTPTR

Buffer output pointer
(offset of
character to be removed from buffer)

QTDEND

Offset of last data byte position in buffer

QTDEVID

Physical device identification for
error message

QTDATA

Buffer data area

All offset data contains offsets relative
control block.

the

beginning

timeout

the

5.2.1.3 Serial Port Initialization - The subroutine P232INIT performs
initialization of all the serial ports. Each of the serial ports is
set to the proper configuration by loading the BX register with the
port control block offset, loading the SI register with the offset of
the initialization sequence, and calling P232IPR which initializes one
port.
The printer and standard communications ports are initialized
by the firmware, thus the control blocks are set not to initialize
them (interrupts are initialized). The optional communication port
control block is set to not perform the initialization.

5.2.1.4 Input and Output - The hardware input/output drivers are
called by the physical I/O routines to directly access the serial port
USARTs. Four subroutines perform the hardware I/O tasks.
P232IN retrieves an input character from the circular buffer in the
port control block
(whose offset is in the BX register). If the
buffer is empty, the routine waits until a character is available from
the buffer.
The characters are placed into the buffer by the serial
port interrupt handler 1232RX.
P2320UT writes a character to a serial port.
Before writing the
character, it makes sure that the USART transmitter is ready and that
output is not suspended.
If the port is a printer port, XOFF
characters are not transmitted.
P232STI determines whether an input character is ready by checking the
number of characters in the circular buffer. If the character count
is zero, then "not ready" status is returned.
P232STO determines whether an output port is ready to receive a
character.
If the USART transmitter is ready and the output is not
inhibited, "ready" status is returned. Otherwise, "not ready" status
is returned.

5.2.2 Physical Device Drivers - There are eleven physical devices
defined by CP/M.
Those not associated with actual hardware devices
are normally regarded as null devices.

5.2.2.1 Mapping of Device Names to Ports - Each of the physical
device names is associated with a hardware input/output device or is
regarded as a null device.
A null device returns an end-of-file
indication (control Z) on each input call, returns immediately on each
output call, and returns a "ready" ~tatus at all times.
The
correspondence of I/O devices to CP/M physical devices in this BIOS is
as follows:
NAME

DEVICE

TTY:
CRT:
UCl:
PTR:
URI:
UR2:
PTP:
UPl:
UP2:
LPT:
ULl:

Printer
Console
Optional communications port
Communications port
Null device
Null device
Communications port
Null device
Null device
(Same as TTY:)
Null device
15

5.2.2.2 Relation to Hardware Device Drivers - Except for the CRT,
which has no control block, the physical device drivers for serial I/O
are implemented in their simplest form by code which loads the BX
register with the address of the appropriate hardware device control
block and branches to the applicable hardware driver.
In the case of
null devices, the physical device drivers are equated directly to the
null device drivers.

5.2.3 Logical Device Drivers - In CP/M there are four logical devices
used for character input/output:
CON:

The console device

AXI:

The auxilIary input device

AXO:

The auxilIary output device

LST:

The list device

These devices are referred to implicitly by BIOS calls.
They, in
turn, call physical device drivers to perform the input, output, or
status testing function.

5.2.3.1 I/O Redirection (IOBYTE) - The CP/M-86/80 operating system
supports redirection of character input/output from logical device
drivers to various physical devices. The redirection is specified by
setting bits in a location called the IOBYTE. This BIOS implements
the full redirection of all four logical devices.
This redirection is accomplished by code in the logical drivers that
fetches the IOBYTE, isolates the 2-bit field of interest, and branches
to a physical driver according to the value in that field.

5.2.3.2 Default I/O Assignments - The IOBYTE is set during the cold
boot process to associate the four logical device drivers with default
physical drivers. These default settings are:
Logical
CON:
AXI:
AXO:
LST:

5.3

Physical
CRT:
PTR:
PTP:
LPT:

BIOS Interrupt Handlers

The 8088 generates five interrupts of concern to the BIOS. BOOS calls
are type-224.
A "receive ready" condition at either of the two
standard serial ports causes a type-36 interrupt. Interruption by the
Z80 causes a type-39 interrupt. A "receive ready" condition at the
optional communications port causes a type-37 interrupt.
Once every
line cycle, a type-44 interrupt is generated by the hardware. This
interrupt is intercepted by BIOS, which in turn generates a type-IOO
interrupt, which can be intercepted by a user program. The interrupt
vectors are initialized during cold and warm boot procedures.

5.3.1 RS-232 Receive Ready - The serial port
interrupt
handler,
I232RX, processes interrupts from any or both of the standard serial
port receive functions. The I232RPT subroutine performs interrupt
processing for a given port.
I232RX first saves all the registers.
The address of each port
control block is placed in the BX register and I232RPT is called.
After processing each port, the registers are restored and an
interrupt return operation is performed. The optional communication
port interrupt handler, I232RX2, operates similarly for the optional
communication port.
The subroutine I232RPT tests to see if the port (whose control block
address is in the BX register) has a receiver ready condition;
if
not, it tests for a break condition. If neither condition exists, an
immediate exit is made. If a break condition exists on the line, the
line is reset and the data port is cleared. If a character is ready,
it is read and processed. If an overrun error occurs, it is assumed
that an XON character may have been lost, and the output is
unconditionally enabled.
If the port is the communications port, the character is stored in the
control block buffer.
If the port is the printer port, special
processing is necessary for XON and XOFF control characters, which are
used to enable and disable output. This feature is controlled by a
flag in QTFLAGS. The following table shows the processing logic.
OUTPUT IS

CHARACTER

ACTION

Enabled

XOFF
XON
any other

Suspend output; discard character
Place into buffer
Place into buffer

Suspended

XOFF
XON
any other

Discard character
Enable output; discard character
Place into buffer

The output is suspended or resumed by changing the state of a flag
QTFLAGS.

If the printer's buffer becomes half full, an XOFF character is
transmitted.
Similarly, should the printer's buffer become entirely
full an XOFF and a BEL character are transmitted.
When the buffer
returns to being less than half full, an XON character is transmitted
to the printer port.
If any overrun error condition exists at the port and the received
character is an XON, it is assumed that the lost character was an
XOFF. The character is discarded and output is enabled.
The code at label I232RP20 stores a character in the circular buffer.
If
a parity error has occurred, an ASCII "SUB" character is
substituted for the received character. The code at label 1232RP30
sends a BEL character to the device when the circular buffer is full.
Label I232RP40 contains code to process a break condition.

5.3.2 Z80 Interrupts - The ZSD interrupt
handler,
TYPE 39 SEFV,
processes hardware interrupts from the ZSD. The handler saves the
packet pointer
(ZSOPKT)
and indicates that a ZSD interrupt was
received by setting a done flag (ZOT).
Note that ZSDFLAG and ZOT must be positioned immediately before
TYPE_39_SERV so that ZSOCCP.SYS and SAVE.CMD can access these flags.
When the BIOS wishes to communicate with the ZSO, it calls the PACKEF
routine which takes items off the stack and places them into a message
packet buffer.
The packet pointer is stored and the ZSO
is
interrupted
(SENDPKT routine).
PACKER then waits for the ZSO to
finish (WAITZSO) by testing the done flag (ZOT).

5.4

BIOS Disk I/O Routines

The discussion of disk input/output routines is divided into four
components:
logical I/O, blocking/deblocking, error message display,
and physical I/O. Because CP/M operates with reference to 12S-byte
logical disk sectors and the Rainbow 100 physical disk contains
512-byte sectors, the logical and physical I/O levels are separate,
and special routines are used to block and deblock logical records to
and from physical records.
Error message display provides diagnostic
information for the user.
The standard CP/M disk parameter tables are used
to
provide
information on disk characteristics. The disk parameter headers (at
DPEO through DPE3)
are generated using the DISKS
macro
from
DISKDEF.LIB. The disk parameter blocks are generated using the GENDEF
utility with the following parameters:

First physical sector
Last physical sector
Skew factor
Data allocation block size
Disk size (in blocks)
Directory entries
Checked directory entries
System tracks

39
1
204S
195
12S
12S
2

The disk sector translation table generated at XLTO is overlaid with a
special table providing a blocking factor of four and a physical skew
factor of two.
A dummy disk parameter header is generated for VTlSO media reference:

First physical sector
Last physical sector
Skew factor
Data allocation block size
Disk size (in blocks)
Directory entries
Checked directory entries
System tracks

35
1

1024
171
64
64
2

5.4.1 Logical I/O Routines - The nine logical disk I/O
routines
perform the functions specified in the Digital Research Inc.'s CP/M-86
System Guide.
The implementation of each function is
briefly
oescribeo below.
HOME sets the desired track to zero.
The physical
deferred until a read or write operation is performed.

seek

SELOSK stores the desired drive number and returns the address
of the disk parameter header for the desired drive. The actual
physical select of the drive is performed only when a read or
write operation is performed. If the drive selected is above the
allowable range ("An throught "0"), the routine returns with an
error condition.
For example, if the BOOS calls and an error
condition is returned, the message "BOOS ERR ON x:
SELECT:
is
displayed. If an unallocated disk is selected, SELOSK performs a
media check to determine if it is VT180 media. If necessary, the
pointer to the correct disk parameter block (that is, DPBO or
OPB4) is updated in the selected disk's parameter header.
This
routine also checks the BOOS log-in vector to determine if a disk
reset has occurred.
SETTRK stores the desired track number of use
write operation is performed.
SETSEC stores the desired sector for use when a
operation is performed.

when

read

read
or

write

SECTRAN performs a simple translation of the passed sector
number (based at zero) in register CX using the translation table
address passed in register ox.
SETOMA stores the desired memory offset for use when a
write operation is performed.

read

SETDMAB stores the desired memory segment for use when a read or
write operation is performed.
READ moves one logical record from the physical sector buffer to
the memory (OMAB:OMA) address specified by the user.
WRITE moves one logical record from the DMA address to the
physical sector buffer. The flag HSTWFT is set to indicate that
the buffer has been changed. If an attempt is made to write to a
ROBIN disk, the message "Cannot write on VT180 disk on drive xn
is displayed.

5.4.2 Blocking and Deblocking - Because the logical disk I/O routines
deal with 128-byte sectors and the physical disk format contains 512
bytes, auxiliary routines are necessary to map the logical sector
numbers onto physical sector numbers, assist in extracting the desired
data from the physical sector buffer, and manage the contents of the
buffer.
READ and WRITE use RWOPER to assist in the blocking of logical
records into 512-byte physical sectors. Using the logical sector
number, RWOPER computes the physical sector number and the
location within the buffer for the logical sector data. The
identity of the buffer contents is maintained in the variables
HSTDSK, HSTTRK, and HSTSEC, which contain the drive, track, and
physical sector associated with the current buffer contents.
If
the desired drive, track, and (physical) sector are the same as
those associated with the buffer contents, the appropriate data
is moved to/from the buffer. If, however, the buffer has been
changed (as indicated by the value of HSTWRT) it is written to
disk.
The desired sector is read from disk unless the BDOS has
specified that this is a write to a previously unallocated block.
Because BDOS signals a write to only the first sector of an
unallocated block, RWOPER must check each non-directory write to
see if the drive, track, and sector are still within the
previously unallocated block. RWOPER calls READHST and WRITEHST
to read and write physical sectors.
READHST sets up a message packet for the Z80 to read into the
sector buffer.
An error message is displayed if a hard error
condition occurs.
WRITEHST sets up a message packet for the Z80 to write from the
sector buffer.
An error message is displayed if a hard error
condition occurs.

5.4.3 Error Message Display - READHST and WRITEHST display
on the logical console when disk error conditions occur.

messages

In the message formats shown below, the "d" identifies the drive, "tt"
the track (decimal), and "ssg the physical sector (decimal).
Drive not ready -- d:
Press CTRL-C to restart,
space bar to retry, or any other key to continue.
Drive write protected -- d:
Press CTRL-C to restart,
space bar to retry, or any other key to continue.
Seek error on drive d:, track tt
Press CTRL-C to restart,
space bar to retry, or any other key to continue.
Read error on drive d:, track tt, sector ss
Press return to ignore error, any other key to continue
Write error on drive d:, track tt, sector ss
Press return to ignore error, any other key to continue

5.4.4 Physical I/O Routines - Physical I/O is controlled by the
See Section 7.1.

5.5

ZSO.

BIOS Utility Subroutines

Two utility subroutines are used for displaying messages directly from
the BIOS routines.
These messages consists of error or warning
notifications requiring action by the console operator.

5.5.1 Message Display - The message display routine, PMSG, is called
with register BX pointing to the message text. A zero byte terminates
the message text.

5.5.2 Decimal Number Display - The decimal display routine, DECPRT,
is used to display track and sector numbers in disk I/O error
messages.

6.0

INTERFACE LAYER

The Interface Layer handles cross-CPU communication for the ZSO.
Two
copies of these routines exist on the system disk: one is ORG'd at
100H and is used when the CP/M-S6/S0 operating system is executing
.CMD transients~ the other is ORG'd at the high end of shared memory
and is used when the CP/M-S6/S0 operating system is executing .COM
transients.
The Interface Layer code is in the ZSOCODE.ASM file. PRIVATE.ASM and
SHARED.ASM contain different assembly time conditional values to
control the assembly of the appropriate addresses and routines.
This
code is physically combined with the Primitive Routines (see Section
7.0).

6.1

Interface Layer Initialization

The boot routine loads the Interface Layer
(and its associated
Primitive Routines)
into ZSO private memory. When the boot routine
has completed its functions, the' Interface Layer's initialization
routine initializes the RST6 vectors and appropriate data areas~
enables interrupts~ and then halts at RST4 until it is interrupted by
the SOSS.
When a new copy of the Interface Layer (and its associated Primitive
Routines)
is
loaded,
control is passed to it by using the
"controlling" copy of the Interface Layer to execute a Start-ZSO
function at the "new" interface's initialization routine. The "new"
copy now has control and the RST6 vectors and data areas are
reinitialized.
A return from the start function never occurs~
instead, the ZSO halts at RST4 waiting for an 80SS interrupt.

6.2

zao Interruption

When the ZSO is interrupted, control is given to the RST6 address
(30H) •
A jump is taken to a routine
(PKTPRO) which clears the
interrupt, retrieves the packet pointer
(ISSPKT), determines the
function number and jumps to the specific function handler routine.
Upon return from the disk and move functions, the packet pointer is
stored (ZSOPKT), the ZSO interrupts the SOSS, and the interrupt return
is taken.
A BOOS/BIOS call is initiated by the ZSO (in ISSSVC, see 6.3 below).
The RST6 routine is entered because the SOSS has indicated that the
call was performed. The waiting ZSO routine
(IS8SVC)
is therefore
signalled that the SOSS is finished by setting a flag (OONEFL),
placing the packet pointer in register HL, and performing an interrupt
return.
No interrupt return is taken if the function is Start-ZSO.
All registers are preserved upon entry.
after saving the registers and after
routine.

6.3

Interrupts are re-enabled
a return from any disk I/O

zao Request Interrupts

When the pseudo BOOS/BIOS routines wish to interrupt the SOSS for
actual BOOS/BIOS service, it calls ISSSVC, which expects a pointer to
the message packet in register HL.
This packet pointer is stored
(ZSOPKT) and a done flag is cleared (OONEFL). The SOSS is interrupted
and interrupts are re-enabled.
While the SOSS is processing the ZSO request, the ZSO is halted. When
execution
resumes, an interrupt has already been received and
processed. The done flag is tested to see if the ZSO's service
request has been completed.
If not, the ZSO halts again.
(The SOSS
might request disk I/O or move service from the ZSO before it can
complete the ZSO's BOOS/BIOS service request.)
If the requested
service has been performed, register HL contains the packet pointer.
Interrupts are re-enabled and control is returned to the pseudo
BOOS/BIOS routines.
If service for BOOS call 0 was requested, the ZSO will remain halted
(not RST4) until another start-ZSO function occurs or until the system
is reconfigured. Control does not return to the pseudo BOOS/BIOS
routines.

7.0

PRIMITIVE ROUTINES

Code for the Primitive Routines is contained in the ZSOCOOE.ASM file.
PRIVATE.ASM and SHAREO.ASM contain different assembly time conditional
values to control the assembly of the appropriate addresses and
routines.
This code is physically combined with the Interface Layer
(see Section 6.0).
The following routines receive control from the
with the packet pointer in register IX.

RST6

routine

PKTPRO

7.1

Disk I/O

7.1.1 Check Media - Called by the BIOS in the 8088 whenever a drive
is selected for the first time after a system reset, this function
attempts to determine whether a Rainbow 100 or VT180 disk is mounted
on the specified drive.
The check media function Message Packet uses the following format:

= 15H

Byte 0

Function code

Byte 1

Returned status 0 = RAINBOW
2
VT-180

Byte 2

Bits 0-4
Bits 5-7

not used
drive number (binary value)

A disk restore operation and then a read of sector 10 is first
performed.
If a record is not found, VT180 media is assumed. If the
record is successfully read or if any other error occurs, Rainbow 100
media is assumed. Appropriate data areas are initialized to reflect
media type.

Primitive

7.1.2 Read/Write Sector(s) - This
following Message Packet format:

Routine

uses

the

= 13H for read, 14H for write

Byte 0

function code

Byte 1

returned controller status

Byte 2

bits 0-4
bits 5-7

sector number to begin reading/writing (binary)
drive number (binary)

Byte 3

bits 0-6
7
bit

track number (binary value)
not used

Byte 4

LSB of data address in shared RAM

Byte 5

MSB of data address in shared RAM

Byte 6

Number of sectors to read/write

7.1.2.1 Read/Write Sector(s) Processing - The drive is
selected
before reading or writing to a sector. The first access of the drive
causes it to be homed. If necessary, a seek of the appropriate track
is performed.
Appropriate error recovery operations are performed
with the read or write.

7.1.2.2 Drive Ready - The drive is considered ready if the controller
reports ready status and if the disk is determined to be right side up
on the first access of the drive. A change in the index pulse status
determines correct disk placement.

7.1.2.3 Disk Home - Two attempts are made tp home a disk.
If the
first attempt fails, the controller performs five "step-in's" and then
tries again.

7.1.2.4 Disk Seek - Two attempts are made to locate a track. If the
first attempt fails, the drive is homed and the seek is attempted
again.
For a VT1S0 disk, the desired track" number is multiplied by two to get
the seek track number. The seek is performed with no verification.
The track number is then read and compared to the desired track
number.

7.1.2.5 Disk I/O Loop - The disk I/O loop used is ORGd at ZSO
The appropriate I/O instruction is
location 40 (see ZSOBASE.ASM).
stored at location 46 before this loop is executed.
The low-memory
location prevents SOSS-induced wait states from affecting disk I/O
performance.

7.1.2.6 Read/Write Error Recovery - Five attempts are made to read or
write a sector. If these five attempts fail, and the original attempt
failed because of a CRC error or a Record Not Found error, an advanced
error recovery procedure is performed. This procedure consists of:
•

Homing the drive

•

Retrying the seek

Then four more attempts are made to read or write the sector. If this
still fails, a seek to track 79 is made, followed by a seek to the
desired track and four more attempts.
If this fails still, the
original error is reported.

7.2

MOVE

This function is called to move data within ZSO memory.
Message Packet format is used:
Byte 0

Function code = 22H

Byte 1

Not used

Byte 2

LSB of source address

Byte 3

MSB of source address

Byte 4

LSB of destination address

Byte 5

MSB of destination address

Byte 6

LSB of number of bytes to move

Byte 7

MSB of number of bytes to move

The following

The source and destination addresses specify addresses in zao memory.
They are moved to registers HL and DE respectively. The byte count is
placed in register BC and a string move is performed.
Control is
returned to the RST6 routine.

7.3

Start Z80

This function is called to start a Z80 transient
(and also to turn
control over to a new copy of the Interface layer -- see Section 6.1).
The following Message Packet format is used:
Byte 0

Function code = 21H

Byte 1

Not used

Byte 2

LSB of Z80 start address

Byte 3

MSB of ZSO start address

Interrupts are disabled and the stack pointer is reset to the base of
the stack.
A return address of 100 1 is placed on the stack (in case
the ZSO transient does a IRETI to the operating system).
The start
address is obtained, interrupts are re-enab1ed, and the ZSO starts
executing the transient.
Control does not return to the RST6 routine. A BDOS call 0 is made
via RST3 and control is returned to the CP/M-S6/S0 operating system
when the ZSO transient terminates.

S.O

PSEUDO BDOS AND PSEUDO BIOS

The Pseudo BDOS/BIOS routines receive control when a ZSO transient
requests BDOS or BIOS service. The code for this module is in the
ZSOCODE.ASM file.
It is assembled when combined with the SHARED.ASM
file (see Section 10.3.3).
These routines place the parameters (in the registers) into a buffer
and set the appropriate function code. A pointer to the buffer is
placed in register HL and the ROS8 is interrupted by calling ISSSVC.
When control is returned, the parameters are replaced in the registers
and the ZSO transient continues execution.
These routines use their own stack.
ZSO/SOSS register mapping for the Pseudo BOOS/BIOS routines
below.
Message
Packet Byte
0
1
2
3

4
5
6
7
8

ZSO

8088
Register
Register
Register
Register
Register
Register
Register
Register
IOBYTE

Function code*
Register A
Register C
Register B
Register E
Register D
Register L
Register H
IOBYTE

AH
AL
CL
CH
DL
DH
BL
BH

* function code = 90H for BDOS, 40H to 90H for BIOS
25

shown

8.1

IOBYTE

Since Z80 transients may change the IOBYTE value directly, it is a
parameter on every BOOS/BIOS call (so that the 8088's BIOS has the
same value). On return, it is replaced (possibly with a new value).

8.2

Cold and Warm Boot

The BIOS BOOT and WBOOT calls are not expected to return to the Pseudo
BOOS/BIOS routines.

8.3

BIOS SECTRAN

The BIOS SECTRAN call is not serviced by the SOSS.
Since no
CP/M-S6/80 BIOS data fields are updated nor any I/O takes place, the
Pseudo BIOS handles this call directly to reduce disk latency time.

S.4

Reply Latency

For both BIOS and BOOS there are functions which do not wait for
reply, such as PRINT and CONOUT. In these cases, the Z80 signals the
SOS8 to perform the function while the ZSO resumes processing.
This
reduces ZSO reply latency.

8.5

Console Status Checks

Console status checks are stored in shared memory, so that BIOS and
BOOS functions that need this information can access it without
calling the SOSS.

9.0

Z80CCP.SYS

ZSOCCP is loaded by the CP/M-S6/S0 CCP whenever a Z80 transient is
requested and when the system must be reconfigured before loading and
executing an SOSS transient. The code for this module is contained in
the Z80CCP.ASM file and in the INCLUDEd file Z80SVC.LIB.
Z80CCP is passed the following parameters:
ES
BX

= Segment base of CP/M-S6/S0
Offset to parameter block

Where parameter block
bytes 0-1

Offset to FCB of requested transient

Current disk drive number

Boot drive number

Return codes are:
AX = 0
AX = 0

System has been reconfigured, run .CMD file
Error

Possible error conditions are:

9.1

The File PRMTVPVT.SYS Not Found on Boot Disk

The File Z80.SYS Not Found on Boot Disk

CANNOT LOAD .COM FILE (.COM file is too large
TPA)

for

available

Z80 Transient System Configuration

The system must be reconfigured if the Pseudo BDOS/BIOS routines are
not in memory (PCPMADR OFFSET). These routines, with the Interface
Layer and Primitive Routines, are loaded into high Z80 memory from
Z80.SYS.
Next, the pointer/buffers data block and the CP/M-86/80
operating system are moved. All appropriate tables and pointers are
reset. Control is then transferred to the new Interface Layer (by the
Start-Z80 function -- see Section 6.1) and to the new CP/M
(by
resetting the interrupt vector segments, the CALLF return segment
value, and the stack segment). The system is now configured as shown
in Figure 1-2 or Figure 1-3. The Z80 transient must now be loaded.
See Section 9.3.

9.2

8088 Transient System Configuration

A new copy of the Interface Layer/Primitive Routines is loaded in
private Z80 memory from PRMTVPVT.SYS. Next, the pointers/buffers data
block and the CP/M-86/80 operating system are moved. All appropriate
tables and pointers are reset and control is transferred to the new
modules.
(See Section 9.1.) The system is now configured as shown in
Figure 1-1.
Control is returned to the CCP for the loading and
execution of the .CMD transient.

9.3

Executing a Z80 Transient

Before executing a Z80 transient, the base page must be initialized
and the transient must be loaded.
After execution begins (under
control of the Z80), the 8088 must wait in a service loop for
BDOS/BIOS calls.

9.3.1 Initialization for Z80 Transients - The
locations are initialized:
0-2
3

4
5 - 7

5C - 7C

following

base

Jump to Pseudo BIOS warm boot
IOBYTE
Current disk drive
Jump to location containing a "Jump to Pseudo BOOS"
File Control Block

In addition, the "jump to Pseudo BOOS" location is initialized.

page

Locations 5 - 7 do not contain a direct jump ~o Pseudo BDOS because
some transients use the jump address to determine the size of the TPA.
A direct jump to BDOS could terminate CP/M on a 64K bytes system.
Therefore, a jump is taken to the end of the TPA and from there a jump
is taken to the Pseudo BDOS.
A dummy disk parameter header area (PSDPH) is also initialized with
absolute pointers to the translate table area (PSTRN), disk parameter
block area (PSDPB), and the allocation vector (PSALV).

9.3.2 Code Relocation - Before the Z80 transient can be loaded, the
code that performs the loading and the code for the service routine
must be relocated into private 8088 memory.
Therefore, this code
cannot exceed 400H bytes.

9.3.3 Loading and Executing the .COM File - Before reading the .COM
file, a Z80-running-flag is set so that it will appear to the BIOS
that the Z80 is requesting the read. This causes the records to be
read directly into Z80 memory.
After the Z80 file is loaded, a
Start-Z80 function is performed and the 8088 falls through to the
waiting service routine.

9.3.4 Z80 Service Routine - This routine begins execution when a Z80
transient program calls a BIOS or BDOS routine through the Pseudo
BIOS/BDOS.
It determines if any "pre-conditioning" of the BDOS
parameters is necessary (BDJMPS table), does the actual BDOS call, and
then performs any necessary "post-conditioning" (BDYJMPS table).
Z80
BIOS calls are serviced through the 8088 BDOS Direct BIOS call
(function *50).
Upon completion of the BDOS call, the Z80 is
interrupted as an indication that the request has been serviced. The
service routine then waits for another BDOS/BIOS call from the Z80.
Special consideration is given to the following:
IOBYTE
If the IOBYTE value has
(function 8) is made.

changed,

BDOS

Set

I/O

Byte

call

BDOS System Reset (Function 0)
BIOS Init (Function 0)
The Z80-running-flag is reset and BDOS call 0 is made with memory
released. Control is returned to the CCP.
BOOS Direct Console I/O (Function 6)
(instead of X'FE' and
CP/M-80 uses X'FF' for status and input
X'FF').
If a character is ready, it is read.
If not, 0 is
returned.
BOOS Set I/O Byte (Function 8)
The returned IOBYTE value is saved and returned to the Z80.

BOOS Get Console Status (Function 11)
CP/M-SO uses a non-zero value of X'FF' instead of X'Ol'.
BOOS Return Login Vector (Function 24)
CP/M has register A = register L for backward compatability.
BOOS Calls using Buffer Addresses
(Functions 9, 10, 15, 16, 17, 19, 20, 21
22, 23, 30, 33, 34, 35, 36, and 40)
If necessary, data in the buffer is moved to a shared memory
buffer. The offset of the shared memory buffer ~s given to BOOS.
Upon return, the data is moved into the ZSO buffer. FCB buffers
are 36 bytes long~ string buffers are defaulted to 12S bytes.
The Read Console Buffer call (Function tlO) is limited to 126
input bytes.
BOOS calls returning Allocation Vector pointer (Function 27)
The Allocation Vector data is moved into a shared memory buffer
(PSALV) and a pointer to the shared memory buffer is returned to
the ZSO.
BOOS calls returning Disk Parameter Block pointer (Function 31)
The Disk Parameter Block data is moved into a shared memory
buffer (PSDPB) and a pointer to the shared memory buffer is
returned to the ZSO.
BIOS calls returning Disk Parameter Header pointer (Function 50)
Upon return from the BOOS Direct BIOS call, the translate table
data, the disk parameter block data, and the allocation vector
data are moved into a shared memory buffer (PSTRN, PSDPB, PSALV)
and a pointer to the shared memory buffer (PSDPH) is returned to
the ZSO.
BIOS SECTRAN (Function 16)
This call is handled by the Pseudo BIOS (see Section S.4).

10.0

SYSTEM DISK GENERATION

This description of CP/M-86/80 system disk generation for the
100 computer is divided into five parts:

10.1

Tools and files required for system disk generation

Preparation and placement of files on system tracks

Preparation and placement of System files on data tracks

Tools required for the generation of Rainbow 100 utilities

Utility file preparation

System Disk Generation Requirements

The following tools and source/hex files are required
system disk:
Tools
ASM86.CMD
DDT. COM
DDT86.CMD
GENCMD.CMD
LDCOPY.CMD

LOAD. COM
MAC.COM
PIP.CMD
SAVE.CMD
Z80.LIB

Source/Hex Files
BOOT100.ASM
CAT. LIB
CPLBIOS.A86
CPLBIOS1.A86
CPLBIOS2.A86
CPLBLOK.LIB
CPLDBIOS.A86
CPLLDCPM.A86
CPLPATCH.A86
CPM.H86

10.2

Rainbow

DEFBUF.LIB
DRIPATCH.AS6
LDBDOS.HS6
PIHVATE • ASM
SHARED.ASM
ZSOBASE.ASM
ZSOCCP.AS6
Z80CODE.ASM
ZSOSVC.LIB

Preparation of System Files

The appropriate disk drive is indicated by "d."

generate

10.2.1

BOOTI00.SYS-

Use the BOOTI00.ASM file

MAC BOOTI00 $AdHdPd+S

d:DDT BOOTI00.HEX
-MI000,llFF,100
AC
SAVE 2 d:BOOTI00.SYS
NOTE
BOOTI0l.HEX must
drive.

10.2.2

the

logged-in

BOOTIOl.SYS-

Use the BOOTIOI.ASM file

MAC BOOTIOI $AdHdPd+S

d:DDT BOOTIOI.HEX
-MIOOO,llFF,IOO
AC
SAVE 2 d:BOOTIOl.SYS
NOTE
BOOTI01.HEX must be on the logged-in drive.

10.2.3

LOADER.CHD-

Use CPLLDCPM.A86 with DEFBUF.LIB (on the same drive)
CPLDBIOS.A86 with DEFBUF.LIB (all on the same drive)
CPLBIOSI.A86
CPLBLOK.LIB
CPLBIOS2.A86
CAT.LIB
LDBDOS.H86

ASM86 CPLLDCPM $Ad Hd Pd Sd

ASM86 CPLDBIOS $Ad Hd Pd Sd

PIP d:LOADER.H86=d:CPLLDCPM.H86,d:LDBDOS.H86,
d:CPLDBIOS.H86

GENCMD d:LOADER 8080

ERA d:LOADER.H86

10.2.4

Z80BASE.COM-

Use the ZBOBASE.ASM file

MAC ZaOBASE $AdHdPd+S

LOAD d:ZaOBASE

10.2.5

PRMTVPVT.SYS-

Use the PRIVATE.ASM and
ZBOCODE.ASM files

PIP d:PRMTVPVT.ASM=d:PRIVATE.ASM,d:ZaOCODE.ASM

AMC PRMTVPVT $AdHdPd+S

ERA d:PRMTVPVT.ASM

LOAD PRMTVPVT

REN d:PFMTVPVT.SYS=PRMTVPVT.COM
or PIP d:PRMTVPVT.SYS=d:PRMTVPVT.COM

10.2.6
1.

File Placement: System Tracks d: DDTB6
-F400:0,27FF,lA
-WDUMMY.LDX,400:0,400:27FF
NOTE
All files read and written with the
'R'
commands must be on the logged-in drive.
-RDUMMY.LDX
START
END
[SO) :0000 [SO) :27FF
-RBOOT100.SYS
START
END
[Sl) : 0000 [Sl): 01FF
-RLOADER.CMD
START
END
[S2) : 0000 [S2): [L2)
-RZBOBASE.COM
START
END
[S3): 0000 [S3]: [L3]
-RPRMTVPVT.SYS
START
END
[S4]: 0000 [S4]: [L4]
-RBOOT1010 SYS
START
END
[S5]: 0000 [S5]: [L5]

and

'w'

NOTE
SO., Sl, S2, S3, S4, L2, L3, L4 are
DDTB6 'R' commands above.

supplied

-M[Sl] :O,lFF, [SO]:O
-M[S2] :BO,127F, [SO] :200
-M[SS] :0, [LS], [SO] :1400
-M[S2] :12.BO, [L2], [SO] :1600
-M[S3] :0, [L3], [SO] :2200
-M[S4] :0, [L4], [SO] :2300
-WLOADFILE.LDX,[SO]:0,[SO]:27FF

"'c

ERA d:DUMMY.LDX

LDCOPY d:LOADFILE.LDX

10.3

Preparation of System Files for Data Tracks

The appropriate disk drive is indicated by nd. n

10.3.1

CPM.SYS-

Use DRIPATCH.AB6
CPLBIOS.AB6 with DEFBUF.LIB (all on the same drive)
CPLBIOS1.AB6
CPLBLOK.LIB
CPLBIOS2.AB6
CAT.LIB
CPLPATCH.AB6 with DEFBUF.LIB (on the same drive)
CPM.HB6

ASMB6 DRIPATCH $Ad Hd Pd Sd

ASMB6 CPLBIOS $AD Hd Pd Sd

ASMB6 CPLPATCH $Ad Hd Pd Sd

PIP d:CPMSYS.HB6=d:CPM.HB6,d:DRIPATCH.HB6,
d:CPLBIOS.HB6,d:CPLPATCH.HB6

GENCMD d:CPMSYS BOBO CODE[A40]

ERA d:CPMSYS.HB6

REN d:CPM.SYS=CPMSYS.CMD
or PIP d:CPM.SYS=D:CPMSYS.CMD

the

10.3.2

Z80CCP.SYS-

Use ZSOCCP.AS6 with ZSOSVC.LIB (all on the same drive)
DEFBUF.LIB

ASMS6 ZSOCCP $Ad Hd Pd Sd

GENCMD d:ZSOCCP CODE[A3DO] DATA[A450]

REN d:ZSOCCP.SYS=ZSOCCP.CMD

10.3.3

Z80.SYS-

Use the SHARED.ASM and
ZSOCODE.ASM files

PIP d:ZSOSYS.ASM=d:SHARED.ASM,d:ZSOCODE.ASM

MAC ZSOSYS $AdHdPd+S

ERA d:ZSOSYS.ASM
NOTE
ZSOSYS.HEX must be on the logged-in drive.

10.3.4

d:DDT
-IZSOSYS.HEX
-ROBOO
AC
SAVE 7 d:ZSO.SYS

PRMTVPVT.SYS - See Section 10.2.4 above.

10.3.5 Placement of Files: Data Tracks - CPM.SYS must be the first
file following the directory
(required for the SERIAL utility).
ZSOCCP.SYS, ZSO.SYS, and PRMTVPVT.SYS are placed after CPM.SYS
(order
is unimportant).

10.4

Utility File Preparation

10.4.1

LDCOPY.CMD-

Use the LDCOPY.AS6 file

ASMS6 LDCOPY $Ad Hd Pd Sd

GENCMD d:LDCOPY

10.4.2

11.0

SAVE.CMD-

Use the SAVE.AS6 file

ASMS6 SAVE $Ad Hd Pd Sd

GENCMD d:SAVE SOSO CODE[A40]

SUBMIT.CMD MODIFICATION

A patch has been applied to the SUBMIT.CMD file supplied by Digital
Research Inc. using the DDTS6 utility. This modification causes the
SUBMIT utility to accept the user-selected Rainbow 100 boot drive as
the controlling drive instead of automatically defaulting to drive A.
The following scenario depicts the patch being made to SUBMIT.CMD with
DDTS6.
A)DDTS6
-RSUBMIT.CMD
START
[SEG] : 0000

END
[SEG] :
OF7F

-SA
[SEG] : OOOA AD
[SEG] : OOOB 00
-SE
[SEG] : OOOE AD
[SEG] : OOOF 00
-A97
[SEG] : 0097 JMP
[SEG] : 009A
-AF60
[SEG] : F60
PUSH
(SEG] : F6l
XOR
MOV
(SEG] : F63
MOV
(SEG] : F65
(SEG] : F69
MOV
[SEG] : F6C
POP
[SEG] : F6D
INC
[SEG] : F6F
MOV
[SEG] : F72
CALL
[SEG] : F75
JMP
[SEG] : F78
-W SUBMIT.CMD

AF
AF
F60
OS
AX,AX
DS,AX
OS, [3 S2]
AL, [24B7]
OS
AL
[139] ,a1
FO
9A

12.0

LISTINGS

The following PIP command lines may be used to
appropriate disk drive is indicated by "d:"):
PIP<cr>
*LST:=d:BOOT100.PRN
*LST:=d:CPLLDCPM.LST
*LST:=d:CPLLDCPM.SYM[P
*LST:=d:CPLDBIOS.LST
*LST:=d:CPLDBIOS.SYM[P
*LST:=d:ZSOBASE.PRN
*LST:=d:PRMTVPVT.PRN
*LST:~d:DRIPATCH.LST

*LST:=d:DRIPATCH.SYM[P
*LST:-d:CPLBIOS.LST
*LST:=d:CPLBIOS.SYM[P
*LST:=d:CPLPATCH.LST
*LST:=d:CPLPATCH.SYM[P
*LST:=d:ZSOCCP.LST
*LST:=d:ZSOCCP.SYM[P
*LST:=d:ZSOSYS.PRN
*LST:=d:COPYDSK.PRN
*LST:=d:FORMAT.PRN
*LST:=d:LDCOPY.LST
*LST:=d:LDCOPY.SYM[P
*LST:=d:MAINT.PRN
*LST:=d:BDOSS6.PRN
*LST:=d:R100VID.PRN
*LST:=d:MAINT.MAP
*LST:=d:SAVE.LST
*LST:=d:SAVE.SYM[P
*LST:=d:SERIAL.PRN
AC

obtain

listings

(the

Rainbow ™ 100
CP/M-S6/S0 Software Design
and Maintenance Manual
AA-P309A-TV

READER'S COMMENTS
Did you find this manual understandable, usable, and well-organized? Please make
suggestions for improvement.

Did you find errors in this manual? If so, specify the error and the page number.

Please indicate the type of reader that you most nearly represent.

D First-time computer user
D Experienced computer user
D Application package user
D Programmer
D Other (please specify)_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __
Name,___________________________________________________________

Dme____________________________________________________________
Organization,_____________________________________________________
Streetl-_________________________________________________________
City_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __
~

State_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __
Zip Code
orCount~--------------------------------------------------------

-------~.--aDo aT-~Oald l
_,Not

Hao

-ffnll--------~~;~; ~,

T.~ ---------------------

if Mailed in the
United States

BUSINESS REPLY MAIL
FIRST CLASS PERMIT NO. 33 MAYNARD MASS.
POSTAGE WILL BE PAID BY ADDRESSEE

SOFTWARE PUBLICATIONS
200 FOREST STREET MR01-2/L12
MARLBOROUGH, MA 01752

- ----- --

Do Not Tear - Fold Here and Tape

-- - - - - - - - - - - - - - - - -- - - - - -- - - -- - -- - - - - - - - ----