Digital PDFs

DEC-15-FR3A-D

2000

188 pages

Original

9.3MB

Document:	PDP-15 Background Foreground Monitor Programmers Reference Manual
Order Number:	DEC-15-FR3A-D
Revision:
Pages:	188
Original Filename:	http://bitsavers.org/pdf/dec/pdp15/DEC-15-MR3A-DW2.pdf

OCR Text

PDP-lS/30AND PDP-lS/40
BACKGROUrJD/FOREGROUND r10N nOR
SOFTWARE SYSTEM

PROGRM1r~ERS

REFERErJCE r1ANUAL

To obtain additional copies of this manual, order number DEC-15·-MR3A-D
from the Program Library, Digital Equipment Corporation, Maynard,
Massachusetts, 01754.

Price

$6.50

Printed December, 1970
Second Printing, April, 1972

(£) 1970, 1971, 1972 Digital Equipment Corporation

The material in this manual is intended for
information purposes and is subject to change
without notice.

The following are trademarks of Digital
Equipment Corporation, Maynard, Massachusetts

DEC
FLIP CHIP
DIGITAL

PDP
FOCAL
COMPUTER LAB

CONTENTS

Page
SECTION 1

1.1
1.2
1. 2.1
1. 2.2
1. 2.3
1. 2.4
1. 2.5
1. 2.6
1. 2.7
1.3

BACKGROUND/FOREGROUND MONITOR

Introduction
Background/Foreground Monitor Functions
Scheduling of Processing Time
Protection of Foreground Core and I/O
Sharing of Multi-User Device Handlers
Use of Sottware priority Levels
Use of Real-Time Clock
Communication Between Background and Foreground Jobs
Use of CPU Registers
Hardware Requirements and Options

SECTION 2

BFKM15 - NON-RESIDENT BACKGROUND/FOREGROUND MONITOR

Introduction
2.1
2.2
Location and When Called
2.3
Initial Operation
2.4
Information Commands
2.4.1
The LOG Command (L)
2.4.2
The REQUEST Command (R)
2.4.3
The DIRECT Command (D)
2.4.4
The INUSE Command (I)
2.5
Allocation Commands
2.5.1
The ASSIGN Command (A)
2.5.2
The FILES Command (F)
2.5.3
The FCORE Command
The FCONTROL Command
2.5.4
2.5.5
The BCONTROL Command
The NEWDIR Command (N)
2.5.6
2.5.7
The SHARE Command (S)
2.5.8
The NOSHARE Command
The 7CHAN Command (7)
2.5.9
2.5.10
The 9CHAN Command (9)
2.5.11
The MPOFF Command
2.5.12
The MPON Command (M)
2.6
Program Load Commands
2.7
Final Operation
Control Characters
2.8
2.9
Summary of Commands
SECTION 3
3.1
3.2
3.3
3.4
3.5

3.6

1-1
1-1
1-2
1-3
1-4
1-4
1-4
1-4
1-5
1-5

2-1
2-1
2-2
2-3
2-4
2-4
2-5
2-5
2-5
2-6
2-7
2-8
2-9
2-9
2-10
2-11
2-11
2-11
2-12
2-12
2-12
2-13
2-13
2-13
2-14

CONTROL CHARACTERS

Purpose
Control Teletype
Teletype Handler
CTRL C (tC)
CTRL S (tS)
CTRL T (tT)

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

Page
3.7
3.7.1
3.7.2
3.7.3
3.8
3.9
3.10
3.11
3.12

CTRL P (tP)
NORMAL CTRL P
No Change
REAL-TIME CTRL P
CTRL R ( tR)
CTRL 0 (to)
CTRL U (@)
RUBOUT ('\)
CTRL D (tD)

SECTION 4
4.1
4.2
4.2.1
4.2.2
4.2.3
4.3
4.4
4.5
4.5.1
4.5.2
4.6
4.7

4-1
4-1
4-2
4-2
4-2
4-3
4-5
4-6
4-6
4-7
4-8
4-9

EXAMPLES OF BACKGROUND/FOREGROUND OPERATIONS

Introduction
Startup Procedures
Loading Master B/F Monitor System
System Generation
Examples
IDLE Loaded as the Foreground Job
Single-user FOCAL Loaded (Foreground)
Two-user FOCAL Loaded (Foreground)

SECTION 6
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9

LOADERS

Introduction
Foreground Linking Loader
Option Characters and Their Meanings
Use of + Terminator
Sequence of Operation
Background System Loader
Background Linking Loader
Loading XCT Files
EXECUTE in the Foreground
EXECUTE in the Background
Error Conditions
System Memory Maps

SECTION 5
5.1
5.2
5.2.1
5.2.2
5.3
5.3.1
5.3.2
5.3.3

3-3
3-4
3-5
3-5
3-5
3-5
3-6
3-7
3-7

5-1
5-1
5-1
5-3
5-3
5-3
5-4
5-4

BACKGROUND FOREGROUND MONITOR COMMANDS (SYSTEM MACROS)

Introduction
.REALR
.REALW
. IDLE
.IDLEC
.TIMER
.RLXIT
Mainstream Real-Time Subroutines
API Software Levels -- Programming Note

6-1
6-1
6-2
6-3
6-4
6-4
6-5
6-5
6-5

Pctge
SECTION 7

WRITING DEVICE HANDLERS FOR THE PDP-IS
BACKGROUND/FOREGROUND MONITOR SYSTEM

7.1
Introduction
7.2
I/O Service Routine
7.3
I/O Device Handler
7.3.1
Types of Device Handlers
7.3.2
General Structure of Device Handlers
7.4
Reentrallcy Protection
7.5
Device Handler's CAL Processor
7.5.1
Arguments of the CAL
7.5.2
. SETUP
7.5.3
Initiating I/O
7.6
Device Handler's Interrupt Processor
7.7
Error processing
7.8
Stop I/O Routines
7.9
Recovery From I/O Device Not Ready Condition
7.9.1
CTRL R Mechanism
7.9.2
.INIT Consideration
7.10
The .INIT Function
7.11
Sequential Multi-user Device Handler
7.11.1
Transition from Single-user Handler
7.11.2
Peculiarities
7.11. 3
Use of the .WAITR Function
7.12
External I/O Buffers
7.12.1
Calling for a Buffer
7.12.2
Releasing a Buffer
7.13
PDP-9/PDP-lS Compatibility
7.13.1
Page Mode
7.13.2
Bank Mode
7.14
Device Handler Listing
SECTION 8

7-1
7-1
7-5
7-6
7-7

7-7
7-8
7-8
7-14
7-15
7-15
7-20
7-21
7-23
7-23
7-21
7-27
7-28
7-28
7-29
7-29
7-29
7-30
7-31
7-31
7-31
7-31
7-31

SYSTEM GENERATION

8.1
Introduction
8.1.1
BFSGEN, Generation and Update Features
8.2
BFSGEN Device Requirements
8.2.1
DECtape Masters
8.2.2
Loading BFSGEN
8.3
System Generation Procedures
8.3.1
Section A
Initialization
Section B
System Selection & Read-in
8.3.2
8.3.3
Section C
System Parameters
8.3.4
Section D
Existing I/O Devices
8.3.4.1
Expendable (Deletable) Devices
8.3.5
Section E
Additional I/O Devices
8.3.6
Section F
PI Skip Chain
8.3.7
Section G
. IOTAB
8.3.8
Section H
.DAT Slots
8.3.9
Section I
Re-write System Information
8.4
Post-Generation Procedures
Error Detection
8.5

8-1
8-1
8-1
8-1
8-2
8-3
8-3
8-4
8-5
8-6
8-9
8-11
8-13
8-13
8-15

8-16
8-16
8-19

APPENDICES

I
II
III

.SCOM Registers
Errors
Teletype Hardware Characteristics
Monitor System Tables
iii

I-I
II-I
III-l

IV-l

SECTION 1
BACKGROUND/FOREGROUND MONITOR

i.l

INTRODUCTION

In the preparation of this manual, it was assumed that the reader is familiar
with the PDP-lS ADVANCED Monitor Software System as described in DEC-lS-MR2A-D.
A complete description of the Background/Foreground Monitor System is given in
this manual; however, where redundancy occurs, the reader has been referenced to
the ADVANCED Monitor manual.
1.2

BACKGROUND/FOREGROUND MONITOR FUNCTIONS

The Background/Foreground Monitor is designed to control processing and I/O
operations in a real-time or time-shared environment.

It is, essentially, an

extension of the ADVANCED Monitor and allows for time-shared use of a PDP-IS
by a protected, priority, user FOREGROUND program I and an unprotected system or
user BACKGROUND program.
The Background/Foreground Monitor greatly expands the capabilities of PDP-lS/20
ADVANCED Software and makes optimum use of all available hardware.

It permits

recovery of the free time (or dead time) that occurs between input/output
operations, thus promoting 100% utilization of central processor time.
FOREGROUND programs are defined as the hiqher-priority, debugged user programs l
that interface with the real-time environment.

They normally operate under

Program Interrupt (PI) or Automatic Priority Interrupt (API) control, and are
memory protected.

At load time they have top priority in selection of core

memory and I/O devices, and at execution time they have priority (according to
the assigned priority levels) over processing time.

Depending upon system

requirements, the user's Foreground program could be an Executive capable of
handling many real-time programs or subprograms at four levels of priority.
BACKGROUND processing is essentially the same as the processing normally
accomplished under control of the ADVANCED Monitor.

That is, it could be an

assembly, compilation, debugging run, production run, editing task, etc.
Background programs may use any facilities

(for example, core, I/O and processing

time) that are available and not simultaneously required by the Foreground job.
Under certain circumstances, I/O devices may be shared by both the Foreground
and the Background jobs.
lIt may be feasible in the future to provide system programs which will operate
in the FOREGROUND.

1-1

The Background/Foreground Monitor system is externally a keyboard-oriented
system; that is, Foreground and Background requests for systems information,
core, I/O devices, programs to be run, etc., are made via the Teletyp~keyboards.
At run time, the Monitor internally controls scheduling and processing of I/O
requests, while protecting the two resident users.
The Background/Foreground Monitor performs the following functions as it controls
the time-shared use of the PDP-IS central processor by two co-resident programs:
a.

Schedules processing time.

Protects the Foreground job's core and I/O devices.

Provides for the sharing of multi-user device handlers, such as
DECtape, by both Foreground and Background jobs.

d.
e.

Allows convenient use of API software levels by Foreground jobs.
Provides for convenient and shared use of the system Real Time
Clock.

Allows communication between the Background and Foreground jobs
via core-to-core transfers or by the shared use of bulk storage
devices.

Allows concurrent use of the CPU's active registers, such as the
AC and Index Register.

1.2.1

Scheduling of Processing Time

At run time, the Foreground job retains control except when it is I/O bound;
that is, when completion of an I/O request must occur before it can proceed
any further.

In the following example, if the .WAIT is reached before the input

requested by the .READ has been completed, control is transferred to a lower
priority Foreground segment or to the Background job until the input for the
Foreground job is completed.
.READ 3,

LNBUF, 48

.WAIT 3

/READ TO .DAT SLOT 3

/WAIT ON .DAT SLOT 3

Since multi-user device handlers can be shared by Foreground and Background
programs, there is a mechanism by which a Foreground I/O request may cause a
Background I/O operation to be stopped immediately so that the Foreground
operation can be honored.

On completion of the Foreground I/O, the Background

I/O is resumed with no adverse effects on the Background job.
The Foreground program can also indicate that it is I/O bound by means of the
ITeletype is a registered trademark of the Teletype Corporation.
1-2

.IDLE or .IDLEC command (Sections6.4 and 6.5).

This is useful when the

Foreground job is waiting for real-time input from anyone of a number of
input devices.

Consider the following example (see Section 6.2 for description

of real-time read .REALR command) .
. REALR 1, ~,LNBUFl, 32, CTRLl, Nl
.REALR 2, 2,LNBUF2, 42, CTRL2, N2
.REALR 3, 3,LNBUF3, 36, CTRL3, N3

/REAL
/TIME
/READS

. IDLE
If .IDLE is reached before any of the input requests have been satisfied, control
is transferred to a lower priority Foreground segment or to the Background job.
The lower priority job retains control until one of the Foreground input requests
is satisfied.

Control is then returned to the Foreground job by executing the

subroutine at the specified completion address

(CTRLl, CTRL2, CTRL3)

and at the

priority level specified by Nl, N2, N3 which may be:
Value of N

Level

Mainstreanl (lowest level)

Current level (level of .REALR)

Software level 5

Software level 6

Software level 7
NOTE
If real-time reads (.REALR), real-time writes (.REALW),
or interval timer (.TIMER) requests are employed in
the Background, N may be set to 0, 4, 5, 6, or 7, but
is converted to ~ since the Background job can run only
on the mainstream level. This allows the value of N to
be preset in cases where a Background program is to be
subsequently run in the Foreground.

1.2.2

Protection of Foreground Core and I/O

The Foreground job's core is protected by the Memory Protection Option (Type
KM15).

The Background job runs with memory protect enabled; the Foreground job

runs with memory protect disabled.
Protection of the Foreground job's I/O devices is accomplished via the haraware
by the Memory Protect Option (which prohibits lOT and Halt instructions in the
B~ckground

made via

area) and by the software since the Monitor screens all I/O requests
I/O macros.

Also, the Monitor and the Background Loaders prevent the

Background job from requesting I/O which would conflict with that of the Foreground job (for example, they would not honor a Background request for a paper

1-3

tape handler being used by the Foreground job).
1.2.3

Sharing of Multi-User Device Handlers

The Background/Foreground Monitor permits sharing of multi-user device handlers
(such as DECtape, Magnetic Tape and Disk) between Background and Foreground jobs.
Using these multi-user handlers, n files can be open simultaneously, where n
equals the number of .DAT slots associated with the particular bulk storage
device.

Some multi-unit handlers require external data buffers (assigned at

load time), one for each open file.

These buffers are acquired from and

released to a pool by the handler as needed.
When this count is not accurate (when the .DAT slots are not used simultaneously),
the keyboard command FILES (Section 2.5.2) can be used to specify the actual
number of files simultaneously open.

Both the Foreground and Background jobs

can indicate their file requirements by means of the FILES keyboard command.
The multi-user handlers are capable of stacking one Background I/O request.
This provision is made to exactly simulate program operation as it would occur
under ADVANCED or I/O Monitor (i.e., single user) control.

Thus, control is

returned to the Background job to allow non-I/O related processing when the
handler is preoccupied with an I/O request from the Foreground job.

For

example, if the Foreground job has requested DECtape I/O with a • READ, and is
waiting for its completion on a .WAIT, control is returned to the Background job.
If the Background job then requests DEC tape I/O with a • READ, the handler will
stack the request and return control to the Background job following the . READ.
The Background job can then continue with non-I/O related processing as though
rhe .READ were being honored.
1.2.4

Use of Software Priority Levels

The Background/Foreground Monitor allows convenient use of software priority
levels of the API by the Foreground job.

The Background job is permitted to use

only the mainstream level.
1.2.5

Use of Real-Time Clock

The Background/Foreground Monitor provides for convenient and shared use of
the system real-time clock.

It will effectively handle many intervals at the

same time; thus, the real-time clock can be used simultaneously by both Background and Foreground jobs.
1.2.6

Communication Between Background and Foreground Jobs

The Background/Foreground Monitor allows communication between Background and
1-4

Foreground jobs via core-to-core

transfers.

This is accomplished by means of a

special "Core I/O device" handler within lOPS.

Complementing I/O requests are

required for a core-to-core transfer to be effected; for example, a Foreground
.READ (.REALR)
core.

from core must be matched with a Background .WRITE (.REALW)

Two possible uses of this feature are:
a.

The Background job could be related to the Foreground job and,
as a result of its processing, pass on information that would
affect Foreground processing, or vice-versa.

The Background job could be a future Foreground job and the
current Foreground job, being its predecessor, could pass on
real-time data to create a true test environment.

Communication between two jobs can also be done by storing and retrieving data on
shared bulk storage devices.
1.2.7

Use of CPU Registers

Whenever control passes from one API software level to another, or to Foreground
mainstream or to Background, the following CPU registers are saved and restored.
XR

Index Register 1

Limit Register 1

Multiplier-Quotient Register

AIX

The Autoincrement Registers ---

The Link

The Program Counter (including bits to indicate the
state of memory protect and page/bank mode)

The Step Counter
ground job.

The

?
e

ccumulator are saved and restored only for the Backjob, because it runs with memory protect disabled,

can save the contents of the Step Counter in the two free

(non-interruptible)

instructions following a Normalize instruction by saving the AC (DAC) and then
loading the AC with the SC (LACS).

The AC is not saved for any level of the

Foreground job because a level can give up control only by issuing a Monitor
call (CAL)

(either .IDLE, .WAIT, or an implied .WAIT).

are not saved and r1estored by the CAL handler.
registers,

.SCOM+l,+2,+3,+4, and

+l~

The contents of the AC

In addition to these hardware

are swapped whenever control changes from

Foreground to Background or vice versa.
1.3

HARDWARE REQUIREMENTS AND OPTIONS

The following PDP-1S System hardware confiqurations are required to run the
In the bank mode system, the XE and LR registers are not saved and restored; all other registers
are handled as stated.

1-5

Background/Foreground Monitor Software System.
PDP-1S/30 DEC tape System

PDP-1S/40

PDP-1S CPU with a minimum of
16K core memory

PDP-1S CPU with a minimum
of 24K of core

KElS (EAE)

KSR3S Console Teletype l

PClS (High Speed Reader/Punch)

PC1S (High Speed Reader/Punch)

KA1S (API)

KAlS (API)

KW1S (Real Time Clock)

KM1S (Memory Protect)

TC~2D2or

TC1S (DECtape Control)

3 TUSS (DECtape Transports)
or
2 TUS6 (Dual-DECtape Transports)
as a minimum
An LTlS or an LTl9 2 Teletype Control
unit with at least one additional
KSR33 or KSR3S Teletype

DECdisk

System

TC1S (DECtape Control)

2 TUSS (DECtape Transports)
or
1 TUS6 (Dual-DECtape Transport)
as a minimum
An LTlS or an LTl9 2Teletype Control
Unit with at least one additional
KSR33 or KSR3S Teletype
RFlS (DECdisk control)
2 RS~~ (Disk platters) minimum;
4 maX1mum at present.

lThe basic system Teletype is normally assigned to the Background environment.
One Teletype of the external Teletype system must be reserved for the Foreground
job; additional Teletypes may be assigned to either Background or Foreground
functions.
Model 37 Teletypes are not supported. ~odels 33 or 35 ASR are supported only to
the extent that they operate as KSR's;, their paper tape input and output
facility cannot be used.
Detailed information concerning Teletype units is

given in Appendix III.
2The TC02D DECtape control and the LT19 Teletype Control require the DW1S.

1-6

In addition to the 15/30 and 15/40 configurations shown, the following
PDP-9 configurations may also be used when running the bank mode system.
PDP-9 DEC tape System

PDP-9 DECdisk or

RB~9

Disk System

PDP-9 with a minimum of 16K core
memory

PDP-9 with minimum of 24K core
memory

Real Time Clock

KX09A (Memory Protect)

KE09

(EAE)

2KSR 33/35 (Teletypes)

2KSR 33/35

PC02 (high speed paper tape
reader/punch)

KF09A (API)

TC02

(DECtape control)

3 TU55

(DECtape transports)

(DECtape control)

2 TU55

or
2 TU56

(Dual-DECtape transports)

LT19A (Teletype control)

(Teletypes)

(DECtape transports)
or

1 TU56

(Dual-DECtape transport)

LT19A (Teletype control)
RFOq lnF,Cdisk control) and
~~U9 !DF.rdisk plotterl or
KJ::HJ9 Cl~sk d.IlU contro.l

1-7

The following options currently supported by software may be added to improve
system performance (as noted):
Effect

Options
Additional 8192-word Core Memorr
Modules, Type MM15-A plus MK15A
(to a maximum of 32,768 words)

Increases the maximum size of
both Background and Foreground
programs that can be handled
by the system.

Additional DECtape Transports,
Type TU56, or IBM-compatible
Magnetic Tape Transports, Type
TU20A or TU20B and Tape Control
Type TC59D

Allows greater bulk storage
capability, simultaneous use
of storage media by more programs.
Since only one file may be open
at a time on IBM-compatible magnetic tape transports, more than
two Type TU20A or TU20B transports
may be desirable for some applications

~~i~~a;;cC~ine Printer, Type

Provides greater listing capabilities.

200 CPM Card Reader, Type CR03B

Provides another form of data
input to the machine.

Additional Teletype Line Units,
Type LT19E~ and Teletypes, Type
KSR33, KSR35 or equivalent
(standard system is configured
to handle up to 6 Teletype units
including the console unit. The
system may be expanded to handle up
up to 17 units including the
console unit).

Provides additional control
terminals useful for multiuser programs.

MM09 Band C core memory modules on the PDP-9.
2

Two line printers supported on the PDP-9 are designated T
647
and LPJl9.
ype

LTl9B on the PDP-9.

1-8

SECTION 2

BFKM1S - NON-RESIDENT BACKGROUND/FOREGROUND MONITOR

2.1

INTRODUCTION

The non-resident portion of the Background/Foreground Monitor, entitled BFKM15,
is identical in nature to the Keyboard listening section of the ADVANCED Monitor.
BFKM1S reads and interprets commands typed by the user at either the Background
control Teletype or the Foreground control Teletype.
There are three kinds of commands which the user may type:
a.

Requests for information, such as a directory listing of unit ~
of the system device;

Allocation parameters, such as free core required, number of open
files, and I/O devices to be used;

c.
2.2

Requests to load a system or user program.

LOCATION AND WHEN CALLED

BFKM1S is loaded from register 12000 of the highest core bank to the top of
memory and is transparent to the user since it is always overlayed.
When the Background/Foreground system is loaded or reloaded to start a new Foreground job, the Resident Monitor is first loaded into lower core from unit

of the system device, either by use of the paper tape bootstrap or by typing
CTRL C 1 at the Foreground control Teletype.

The Resident Monitor then brings

the Non-resident Monitor into the top of memory.

When operating in the Fore-

ground, BFKM15 runs with memory protect disabled.
After the Foreground user program has been loaded and has started to run, the
Non-resident Monitor is reloaded with memory protect enabled, to converse with
the user at the Background control Teletype.

BFKM15 is also reloaded whenever

the Background job exits or the user types CTRL C at the Background control
Teletype.
In both the Foreground and the Background, after the user has given a command
to load a program, the Non-resident Monitor brings the System Loader into
memory from the system device, overlaying the Non-resident Monitor.
lRefer to Section 3.4 for a discussion of CTRL C.

2-1

2.3

INITIAL OPERATION

When BFKMl5 is started for the Foreground job, it must perform some initialization
of which the following is of interest:
a.

Set the contents of .SCOM+25 to the initial size of free core
to be allotted to the Foreground job, in addition to the space
required by the Foreground user programs. The initial value
of .SCOM+25 is set during system generation. This value must
take into consideration the initial size of free core to be
allotted to the Foreground job plus the space required by the
Foreground user program. The user may change free core
allotted by issuing the FCORE command, described in Section 2.5.3.

BFKMl5 checks the entire Foreground Device Assignment Table
(.DATF) to see if any of those .DAT slots request the Teletype
handler and the unit number currently assigned to the Background
control Teletype.
If so, those slots are changed to the Foreground control Teletype and a message is output as in the following example.

EXAMPLE 1:

The Foreground control Teletype is TTl, the Background
control Teletype is TT~, and the initial contents of
.OATF slots I and 3 refer to TTA~.
.DATF slots I and
3 will be changed to refer to TTAI and the following
message will be printed on the Foreground control Teletype:
FGO .OATS CHANGED TO TTAI:

FKMl5 V3A 1
$

The Non-resident Monitor identifies itself to the Foreground user by printing FKMl5 V3A and types $ whenever
it is ready to accept a command.
When BFKMl5 is started for the Background job, it performs initialization, of
which the following is of interest:
a.

It builds the initial configuration of the Background .DAT table
(.OATB). Any .OATB slots which request a single user version of
a device handler (for example, OTF) will be changed to
the multi-user handler (DTA in this case) if it is already in
core for the Foreground job or if it is the resident system device
handler.

BFKM15 will check all Background .OAT slots to make certain that
they do not conflict with Foreground I/O. The Resident Monitor
contains, for this purpose, a table (.IOIN) which lists all I/O
handlers and unit numbers in use.
The following occurs:
(1)

If a handler for this I/O device is not already in core, the
Background .OAT slot is left untouched.

FKMl5 is the page mode monitor printout. F9/15 is the bank mode monitor
printout. Bank mode users should substitute the correct monitor printout
in further references.

2-2

(2)

If a single user handler for this device is already in
core for use by the Foreground job, by definition the
Background job may not use this device.
Therefore the
Background .OAT slot is cleared (set to zero).

(3)

If the multi-user handler for this device is in core, but
the device unit number in question is not assigned to the
Foreground job, Background is allowed to share that
handler.
unit ~ of the system device may always be
used by the Background job.

(4)

If the Backgrou~d .OAT slot requests a multi-user handler
and unit number already assigned to the Foreground,
normally this is illegal and that .OAT slot will be
cleared.
However, some users may wish to allow both jobs
to access the same unit.
Normally, this is permitted
only for bulk storage devices (OECtape, Disk, etc.)
provided that the Foreground user typed the command
SHARE, explained in Section 2.S.7.

If the initial Background .OAT table was altered by clearing .OAT slots for the
reasons given above, a message will be output to the Teletype as in the following
example.
EXAMPLE 2:

The Foreground job is running and has been assigned
device handlers and unit numbers OTAl, OTA2, TTAl,
TTA2, and PPA (paper tape punch handler - not
shareable).
The initial Background .OAT table contains
conflicting requests as follows:
.OAT SLOT

CONTENTS

-IS
-4
3

OTAI
OTA2
TTA2

PPA~

The following will be printed on the Background control
Teletype when BFKMlS is first loaded:
BGO .OATS CLEARED BECAUSE OF FGO I/O:
-IS -4 3 7
FCONTROL

TTAI

FGO OEV-UNITS:
TTA2
OTAI
OTA2
PPA~

BKMlS V3A 1
$

BKMlS is the page mode monitor printout.
B9/1S is the bank mode monitor
printout.
Bank mode users should substitute the correct monitor printout
in further references.

2-3

FCONTROL indicates which unit is the Foreground control
Teletype. The remainder of the message indicates what
I/O is being used by the Foreground job. The Monitor
identifies itself to the Background job user as BKMlS V3A
and signals that it is ready to accept a command by
printing $.
2.4

INFORMATION COMMANDS

The following information commands exist in Background/Foreground:

COMMAND

2.4.1

USE

LOG

To print a comment

REQUEST

To examine .DAT slots

DIRECT

To obtain a directory listing

INUSE

To list information about core and I/O
in use by the Foreground.

The LOG Command (L)

This command is legal in both Foreground and Background and may be abbreviated
by the single letter L.

It is used to record comments on the Teletype.

Unlike

all other commands, LOG is terminated only by the character ALTMODE, so that
multiple comment lines may be typed.
EXAMPLE 3:

$LOG

THIS LIN~
AS WELL AS THIS ON~
AND THIS ONE ARE IGNORED (ALTMODE)

2.4.2

The REQUEST Command (R)

This command is legal in both Foreground and Background and may be abbreviated
by the single letter R.

It is used to examine the contents of all or part of

the user's .DAT table.

The Foreground user may examine only the Foreground

.DAT table and

th~

FORM 1:

Background user, only the Background .DAT table.

This requests a printout of the entire .DAT table.

No example is given since

R is essentially the same request as in the ADVANCED Monitor System.

2-4

FORM 2:

Ra.,..USER)

This requests a printout of the contents of all the positive numbered .DAT
slots.

The result, again, is the same as in the ADVANCED Monitor System.
FORM 3:

RJ<YZ)

Here, XYZ stands for the name of a system program; e.g., MACRO, PIP, F4, LOAD,
etc.

The names given must be identical to those used to load the programs.

The information printed, as in the ADVANCED Monitor System, is those .DAT slots
used by the given system program.

Since, at present, the only system program

load commands allowed in the Foreground are LOAD, GLOAD, PIP and EXECUTE, only
these four may be used in Foreground REQUEST commands.

2-4A

FORM 4:

~.DATuj, k, 1,

... , r, s)

Here, j, k, 1, etc., are .DAT slot numbers.
EXAMPLE 4:

TTAl DTA2 NONE

LPA~

2.4.3

The DIRECT Command (D)

This command is legal in both Foreground and Background and may be abbreviated
as D.

The format is:

where n

= a unit number

through 7) on the system device.

Directory listings

have been altered in BFKM15 to print the number of free blocks before the file
names.

The Background user may not request directory listings of any units

owned by the Foreground job unless the Foreground user typed the SHARE command
(see below) .
2.4.4

The INUSE Command (I)

This command is legal only in the Background and may be abbreviated by the
single letter I.

It causes the Monitor to print the first free core location

above the Foreground job, the Foreground control Teletype unit number, and
any other I/O used by Foreground.
EXAMPLE 5:
$1)

1ST REG ABOVE FGD

323~1

FCONTROL = TTA2
FGD DEV-UNITS:
DTAl
LPA~

2.5

ALLOCATION COMMANDS

The following commands assign parameters, controls, and conditions:
2-5

PURPOSE

COMMAND

2.5.1

ASSIGN

To assign I/O handlers to .DAT slots

FILES

To specify handler file capacity

FCORE

To set up Foreground free core

FCONTROL

To select Foreground control Teletype

BCONTROL

To select Background control Teletype

NEWDIR

To write a new file directory

To allow jobs to share same I/O units

NOS HARE

To nullify effect of SHARE

7 CHAN

To specify 7-channel MAGtape operation

9 CHAN

To specify 9-channel MAGtape operation

MPOFF

To let Background access all of core

MPON

To nullify effect of MPOFF

The ASSIGN Command (A)

This command is legal in both Foreground and Background and may be abbreviated
by the single letter A.

Its format and function are, with a few exceptions,

identical to the same command in the ADVANCED Monitor System.
The format is:
AuPDLNum, n, ... , p/ ..• /DDLNum, n, ..• , p)
where

DD stands for the two letter device name; e.g., DT for DECtape,
PP for paper tape punch, etc.
L represents the third letter of a device handler name and is
optional. If not given, the third letter is assumed to be A;
e.g., DTI = DTAI. The "A" version of a handler is the multiuser, shareable handler, provided that one exists. PPA, for
example, is not a multi-user handler.
N is the unit number to go with the device handler and is also
optional. If the unit number is missing, N is assumed to be ~,
e.g., DTA = DTA~., Therefore, DT = DT~ = DTA = DTA~. The
letters m, n, •.. , p stand for .DAT slot numbers. The slash (/)
separates handlers.

To clear out a .DAT slot, assign NONE to it.

If any error is detected in the

command, none of the assignments will be made.
The Foreground and Background users may make assignments only to their
respective .DAT tables.

Foreground may not assign

is the Background control Teletype.

TTA~

if, for example, that

Since DTA is permanently in core with the

Resident Monitor (assuming that DECtape is the system device) DTE, DTF, etc.,
when assigned, will automatically be changed to DTA.

This applies as well to

handler assignments made in the Background whenever the multi-user version of
the handler is in core for Foreground use.
2-6

Background .DAT slot assignments are tested to ensure that they do not conflict
with Foreground I/O, as explained in section 2.3.

Whenever the Monitor detects

such a conflict, it will print the message:
OTHER JOB'S DEV-UNIT
To ensure that no conflict can occur when assigning the core-to-core handler,
COA., the unit number is preset to ~ for Foreground and 1 for Background.

The

core-to-core handler disregards the unit number anyway.
2.5.2

The FILES Command (F)

This command is legal in both Foreground and Background and may be abbreviated
as F.

The purpose of this command is to save core space by limiting the number

of I/O buffers assigned to multi-user device handlers.

The format of the FILES command is:

where:

DD stands for the multi-user handler or device name (e.g., DTA or DT).
N stands for an octal file count.

EXAMPLE 6:

Assume that the Foreground user programs are being loaded
into core by the Foreground Linking Loader and that these
programs use .DAT slots 1 through l~.
(.IODEV 1, 2, 3, ... ,
l~).
Further, assume that all l~ slots were assigned to
DECtape, DTAn (the unit numbers are unimportant to this
discussion).
Most multi-user handlers, DTA being one of them, require
that I/O buffers be assigned to them externally. This is
done by the various loaders. In this example, the Foreground Linking Loader, seeing that no FILES command was
given for the handler DTA, must assume that the user wants
l~ files open simultaneously.
This will require l~ buffers,
each 6~~ octal words in size.
The FILES command is used to tell the loaders to assign a
given number of buffers for a particular multi-user handler
based on the maximum number of files that the user programs
will have open simultaneously. Each multi-user handler
has a maximum open file capacity; for example, DTA may have
up to 2~ octal. If l~ I/O buffers are assigned for DTA in
the Foreground, then only up to l~ may be assigned for
Background. The FILES command issued in the Foreground
specifies only Foreground I/O buffers. Thus, to limit the
number of I/O buffers assigned to the Background, the
FILES command, for the same multi-user device, must also be
issued in the Background.

At load-time, I/O buffers are set aside in core by the Loaders.

The buffers are

recorded in a table within the Resident Monitor, .BFTAB, but are not flagged for
the exclusive use of particular device handlers. At run-time, each multi-user
2-7

handler which needs a buffer must request a buffer from the Monitor.

The handler

must also release the buffer to the pool when it. is no longer needed.
The resident buffer 1 , permanently assembled into the Resident Monitor, is always
available to the Background job. In the event that the Bac~ground job were to
.IODEV only one .DAT slot which is linked to a multi-user handler that requires
external buffers, (DTA. for example) the user could save 6~~ registers by
typing:

that is, assign one less buffer than is needed.
In the FILES command, the pseudo-device .• is recognized.
external buffer for this pseudo-device is

l~~

octal.

The size of the

Some functions in multi-

user handlers may require a smaller buffer size than others.

If the user were

only to use such function types, he could type, for example, $FILESuPTu? and
$FILESu"ur.
2.5.3

In DTA.,

.TRAN and .MTAPE commands only require the smaller buffer.

The FCORE Command

This command is legal only in the Foreground and may not be abbreviated.
The format of the FCORE command is:

where N is the amount (in octal) of free core requested for the Foreground job.
As in the ADVANCED Monitor System, unused (free) core is defined by the
address pointers in the registers .SCOM+2 and .SCOM+3, the lowest and the
highest free core location, respectively.

Since both the Foreground and the

Background jobs have their own separate free core areas, the values in .SCOM+2
and .SCOM+3 are changed appropriately whenever control passes from one job to
the other.
The FCORE command allows the Foreground user to specify how much free core his
program will need, in addition to that required to load his program.
value for FCORE is specified during system generation.
of core to be assigned to Foreground.

The default

It is possible for all

This means, however, that there will be

no room for Background to run, which is perfectly legal.

If this is the case,

the message:
SORRY, NO ROOM FOR BGD
IThe resident buffer (6~~8words) is assumed to be large enough to be used by
any multi-user handler
which might be used by the loaders.
2-8

is printed on the control Teletype.
2.5.4

The FCONTROL Command

This command is legal only in the Foreground and may not be abbreviated. It is
used to transfer control from the control Teletype to some other Teletype unit.
The format of the FCONTROL command is:

where:

N is the number (octal) of any Teletype on the system.

If N is already the Foreground control Teletype, the command is ignored.

If N

is the current Background control Teletype, the two Teletypes are swapped but
no message will be printed to this effect.

Changing the Background control

Teletype may affect Foreground .DAT slots and an appropriate message will be
printed on the Foreground control Teletype.
section on the

This is fully explained in the next

BCONTROL command.

When FCONTROL changes the Foreground control Teletype, the following action
takes place:
a.

The following message is printed on the old control unit:
CONTROL RELINQUISHED

The system is reloaded from the system device.

The Monitor prints
FKM15 V3A
$

on the new Foreground control unit and is ready to accept
commands there.
2.5.5

The BCONTROL Command

This command is legal both in the Foreground and in the Background and may not
be abbreviated.

It is used to transfer control from the Background control Tele-

type to some other Teletype unit.
The format of the BCONTROL command is:
BCONTROLuN)
where N is the number (octal) of any Teletype on the system.
2-9

This command is

illegal and is ignored if
a.

N is the Foreground control Teletype

b.
c.

N has been .IODEVed by a Foreground user program
N is already the Background control Teletype

If the Background control Teletype is changed by either a BCONTROL or FCONTROL
command in the Foreground, all Foreground .DAT slots which now refer to the new
Background control unit will be changed to the Foreground control unit to avoid
I/O conflict.

Should that situation occur, the following example shows what

would be printed on the Foreground control unit:
FGD .DATS CHANGED TO TTAI
-6 2 7 IfJ
If BCONTROL is issued in the Background, the following action takes place:
a.

The following message is printed on the old control unit:

1C is printed on the new unit

The Non-resident Monitor (BFKM15) is reloaded for Background
from the system device

The Monitor prints

CONTROL

RELINQUISHED

BKM15 V3A
$

on the new Background control Teletype and is ready to
accept commands there.
2.5.6

The NEWDIR Command (N)

This command is legal in both Foreground and Background and may be abbreviated
by the single letter N.

Just as in the ADVANCED Monitor System, this command

allows the user to write a new file directory on some unit of the system device ..
However, space will not be reserved for a tQ (CTRL Q) area.
The format of the NEWDIR command is:

NJII)
where M is some unit number (octal) on the system device.
used.

Unit fJ may not be

The Background may not write a new file directory on a unit that belongs

to the Foreground unless the Foreground has issued the SHARE command (see below) •
2-10

2.5.7.

The SHARE Command (S)

This command is legal only in the Foreground and may be abbreviated by the single
letter S.

Its purpose is to allow the Background job to assign and to use the

same units of any I/O devices that belong to the Foreground job, provided that
they are unit-shareable devices 1 (DECtape, Disk, MAGtape, etc.) and that the
device handlers are the multi-user versions.
allowing this condition to occur.

The user must be careful when

The "tape" could be fouled if both jobs were

to try to use the same unit for output at the same time.
The SHARE command also removes the restriction that the Foreground user program
may not use unit ~ on

~he

system device.

Normally, this unit is reserved for the

Background.
The format for this command is:
SHARE)
2.5.8

The NOSHARE Command

This command is legal both in Foreground and in Background and may not be
abbreviated.

It nullifies the effect of any previous SHARE command; i.e., does

not allow the Background to share device units with the Foreground.
When NOSHARE is issued in the Background, it may cause some Background .DAT slot
to be cleared.

A message, as in Example 2, will be printed to that effect.

The command format is:
NOS HARE)
2.5.9

The 7CHAN Command (7)

This command is legal only in the Foreground and may be abbreviated by the
single character 7.

The effect of this command is to clear bit 6 in .SCOM+4 to

inform the Magtape device handlers that the default assumption is 7-channel
operation.
The format of the 7CHAN Command is:

7 CHAN)

iNormally, only mass storage devices are unit-shareable.
2-11

2.5.10

The 9CHAN Command (9)

This command is legal only in the Foreground and may be abbreviated by the single
character 9.

It sets bit 6 in .SCOM+4 to inform the Magtape device handlers that

the default assumption is 9-channel operation.
The format of the 9CHAN command is:
9CHAN)
2.5.11

The MPOFF Command

This command is legal only in the Foreground and may not be abbreviated.
The format is:
MPOFF)
Under normal circumstances, the Background job operates in user mode (memory
protect enabled) with the memory protect boundary register set from the contents
of .SCOM+32.

The MPOFF Command does not disable memory protect for Background;

it causes the contents of the boundary register to be set to zero, independent
of .SCOM+32.
The effect this has is to allow the Background job to reference, modify, and
transfer to any location in core memory.

Any attempt to do so via a system

macro call (CAL sequence, such as .WAITR) will not result in a terminal error,
.ERR ~36.

Normally, the Monitor's CAL handler would validate Background argu-

ments by comparison with .SCOM+31 or .SCOM+32, as appropriate.
Since the Background still runs with memory protect on, lOT instructions,
non-existent memory references, double XCT instructions, HLT, and OAS will
trap to the Monitor.

OAS l is executed by the Monitor whether or not the MPOFF

command was issued.

lOT instructions are executed by the Monitor for the Back-

ground job (this includes lOT's that cause a skip) when MPOFF is in effect.
The reader is cautioned to avoid the use of instructions, such as CAF, EBA,
DBA, ISA, which could play havoc with the system if executed in the Background.
The MPOFF facility was provided to allow a limited amount of Foreground debugging
by using DDT in the Background (strictly for examination and modification--no
breakpoints) .
2.5.12

The MPON Command (M)

This command is legral in both Foreground and Background and may be abbreviated by
the letter M.

lOAS must not be microcoded with any skip instruction.
2-12

The format is:
MPON)
The MPON command nullifies the effect of MPOFF, thereby protecting the Foreground
job from the Background job in the normal manner.
2.6

PROGRAM LOAD COMMANDS

In the Foreground, only four load commands are legal:
EXECUTE L..I XXx).

LOAD), GLOAD), PIP), and

EXECUTE may be abbreviated by the single letter E.

LOAD and

GLOAD have the same meaning and effect as in the ADVANCED Monitor System.
The following program load commands exist in the Background:
PATCH)
CHAIN)
F4)
F4A)
EDIT)
PIP)
EXECUTEuXXX)
MACRO)
DTCOPY)
2.7

MAC ROA)
LOAD)
GLOAD)
DDT)
DDT~S)

DUMP)
UPDATE)

BFSGEN~

SRCCOM)

FINAL OPERATION

After BFKM1S has received a program load command from either the Foreground or the
Background, it will bring the System Loader (.SYSLD) into the top of core overlaying BFKM1S.
Loader.

In the Foreground, .SYSLD is actually the Foreground Linking

In the Background, .SYSLD loads Background System Programs, including

the Background Linking Loader.
2.8

CONTROL CHARACTERS

While control is in BFKM1S, the user may type CTRL P to terminate execution of
the current command and to restart.

Restart in this manner does not nullify the

effect of previously executed commands; e.g., will not reset the .DAT table to
its initial configuration.
may type CTRL C. 1

To reload the Monitor for the current job, the user

lRefer to section 3.4 for a discussion of CTRL C.

2-13

2.9

SUMMARY OF COMMANDS
LEGAL IN
F
F

B
B

ABBREVIATION
A

B
B
F
F

9
B
B
B
B
B

B
F

B
B
B

ASSIGN u DTAl ....2, 3/ TT1 u 1 , 4/DT....-4)
BCONTROLu.2)
BFSGEN)
CHAIN)
7 CHAN)
9 CHAN)
DDT)
DD'fNS)
DIRECT ~)
DTCOPY)
DUMP)
EDIT)

EXECUTE...){Xx)
F4)
F4A)
FCONTROL~l)

F
F
F
F

COMMAND EXAMPLE

FCORE..}4~1J

FILES~T..}J
GLOAD)
INUSE)
LOAD) .

B
B
B
B

B
B
B

F
F

B
B
B
B
B

NEWDIRuS)
NOSHARE)
PATCH)
PIP)

REQUEST~XX) or REQUESTuPSER) or
REQUESTu.DAT j,k,~ or REQUEST)

SHARE)

F
F

LOG u ...... (ALTMODE)
MACRO)
MACROA)
MPOFF)
MPON)

SRCCO~Y

UPDATR)

2-14

SECTION 3

CONTROL CHARACTERS

3.1

PURPOSE

Control characters are single characters, typed by the user at a Teletype, which
request special action by the Monitor.

Except for the character, RUBOUT, all

control characters are formed by holding down the control key, CTRL, while
striking the appropriate letter key.
The characters CTRL U a.nd RUB OUT are used as "erase" characters during Teletype
input or output.

CTRL C, CTRL P, CTRL S, and CTRL T are used to interrupt the

operation of the current program and to transfer control elsewhere.

CTRL R

is used to restart I/O after a not-ready condition has been detected for some
device.

CTRL Q stops the current job and dumps memory onto a specified area of

some unit of the system device.

CTRL D effects an end-of-file condition during

Teletype input.
3.2

CONTROL TELETYPE

In the Background/Foreground System, which may accommodate up to 17 (decimal)
Teletype units 1 , two Teletypes are designated as control Teletypes (one for
Background and one for Foreground).

Initially, it is assumed that unit

(the

console Teletype) is the control Teletype for Background and unit 1 is the control unit for Foreground 2 •
Control Teletypes differ from the other units in two ways:
a.

They are used to converse with the Non-resident Monitor and
system programs in order to set up parameters and conditions
for a job and to initiate the loading and execution of programs.

Certain control functions are honored only at control Teletypes;
i.e., they are ignored if they are typed on the other Teletype
units (see Section 3.4 and following).

IThe system as shipped to customers will handle a maximum of 6 Teletypes.
sion requires a simple reassembly of the code for the Resident Monitor.
2The initial control Teletypes are specified during system generation.

3-1

Expan-

3.3

TELETYPE HANDLER

The multi-user Teletype handler (TTA) which is imbedded in the Resident Monitor
makes special tests for control characters when it receives typed input.

Normally,

when no .READ request has been issued to a Teletype, characters received from
that unit are ignored unless

they are control characters.

A description of the

action taken in each case is given in the following paragraphs.
3.4

CTRL C (1(:)

This character is ignored unless typed at a control Teletype.

It is echoed to

the teleprinter as tC.
If a Background job is not in core and the user types CTRL C at the Foreground
control Teletype,

tc is echoed to it and the Resident Monitor is reloaded by

the resident bootstrap.
If a Background job is in core

when CTRL C is typed on the Foreground control

Teletype, tB is echoed to it to indicate that a Background job exists, a "bell"
is sent to the Background control Teletype, and a flag is set indicating that
CTRL C has been typed in the Foreground.

What happens thereafter depends on

which job is the "confirmer", a parameter set by the System Generator.

Once

CTRL C has been entered on the Foreground control Teletype, the Foreground job is
terminated.
When Foreground is the "confirmer", the second time CTRL C is typed on the
Foreground control Teletype tc is echoed to it and the Resident Monitor is
reloaded.
When Background is the "confirmer", CTRL C typed on the Foreground control
Teletype causes

to be printed on the Foreground control Teletype and a "bell"

to be sent to the Background control Teletype.
Background.

Thus Foreground cannot abort

When CTRL C is typed on the Background control Teletype,

1(: is

echoed to it and then the Resident Monitor is reloaded by the resident bootstrap.
In the normal case where Foreground is running and CTRL C is typed on the Background control Teletype but not on the Foreground control Teletype, the Foreground job is not affected.

The Background job is aborted and the Non-resident

Monitor is reloaded to start up a new Background job.
The "confirmer" flag is .SCOM+I-"4.

-" = Foreground.
I (nonzero) = Background.

3-2

3.5

CTRL S (tS)

CTRL S is recognized only at a control Teletype and, specifically, only after
the Monitor has printed

This is the result of loading a user program by

giving the command $LOAD (instead of $GLOAD) to the Non-resident Monitor.
commands bring in the Linking Loader to load user programs.
LOAD-AND-GO.

Both

$GLOAD means

$LOAD means load the user programs, signal the user that this has

been done (by printing ~), and then wait for the go-ahead signal (when the
user types CTRL S).
This feature allows the user to set up I/O devices before starting his program.
When CTRL S is typed by the user and is accepted by the Monitor, ts is echoed
back to the teleprinter.
3.6

CTRL T (tT)

This character is recognized only at the Background control Teletype when the
user has called in the system program DDT.

When CTRL T is typed and accepted,

it is echoed to the teleprinter as tT.
CTRL T provides a means of interrupting the execution of a user program and
transferring control to DDT.

When CTRL T is typed, the Monitor saves the

status of the Link, page/bank mode, and memory protect along with the interrupted
PC in .SCOM+7 so that DDT will be able to return control to the user program at
the point at which it was interrupted.

The contents of the AC at the time of

interruption is returned in the AC and saved by DDT.
3.7

CTRL P (tP)

CTRL P is the interrupt and restart character available to user and system
programs.

When it is typed on some Teletype and is accepted by the Monitor, tp

is echoed to the teleprinter on that unit.
In the Background/Foreground system there are two types of CTRL P functions:
1.

NORMAL CTRL P and

REAL TIME CTRL P.

The two CTRL P functions are described, individually, in paragraphs 3.7.1 and
3.7.3.
Setting a CTRL P restart address (ADDR) is accomplished by issuing the I/O
MACRO .INIT to any .DAT slot linked to the Teletype handler.

3-3

The format of the .INIT macro is:
.INIT A,M,P+ADDR
which is expanded by the MACRO assembler into the following machine code:
LOC
LOC+l
LOC+2
LOC+3
where A

a .DAT slot number (octal radix)

M
ADDR
P

Input

Output

transfer mode
a IS-bit address (octal) of a restart point in the program
or of the entry point of a closed real-time subroutine.
priority code

Normal CTRL P
Mainstream (REAL-TIME)
No change to CTRL P
Priority level of the .INIT
API level S
API level 6
API level 7

Background requests to an API level (4~~~~~ - 7~~~~~) will be converted to
Mainstream since Background programs cannot use the API software levels.
3.7.1

NORMAL CTRL P

A .INIT to set up a NORMAL CTRL P (priority code ~) may be done only to a
control Teletype.

NORMAL CTRL P was so named because the action taken when the

user types CTRL P is nearly the same as in the ADVANCED Monitor System.
When a control Telet.ype has been set up for a NORMAL CTRL P and that character
is typed by the user, the Teletype handler
that job (Background or Foreground).

will abort all Teletype I/O for

The Monitor will, when control is at

Mainstream, save the status of the Link, page/bank mode, and memory protect
with the interrupted PC in .SCOM+IO (whose contents are swapped in and out for
Background and Foreground), return the interrupted AC to the AC, and transfer
control to the restart address ADDR as specified by the last .INIT.
NOTE
When the Monitor processes a CTRL T or a NORMAL CTRL P, it
kills any pending mainstream real-time routines to be run

by zeroing the contents of .SCOM+57 (Foreground) or .SCOM+61
(Background). The user's program (if NORMAL CTRL p) or the
user (if CTRL T) must zero the entry points of all his mainstream real-time routines. CTRL P and CTRL T do not affect
API level real-time requests.
3-4

If the restart address ADDR = ~, CTRL P to the given Teletype will be disabled;
i.e., ignored if typed (except if P = 3~~~~~).
3.7.2

No Change

If .INIT for a given Teletype unit contains the priority code
restart address for that unit is not changed.

3~~~~~,

the CTRL P

DDT uses this so that it can .INIT

to abort a .READ to the Teletype without altering the CTRL P address set up by the
user's program.
3.7.3

REAL-TIME CTRL P

A .INIT to set up a REAL-TIME CTRL P may be done to any Teletype unit.
set up and the user types CTRL P, I/O to that Teletype is aborted.

When so

Control

eventually goes to a closed real-time subroutine, ADDR, at the priority level
defined by P, in the same manner as for a .REALR, .REALW, or .TIMER request.
If the restart address ADDR = ~, CTRL P to the given Teletype will be disabled,
i.e., ignored if typed.

REAL-TIME CTRL P is useful for multi-user programs, for instance

multi-user

FOCAL, where each Teletype has the ability to interrupt and restart.
3.8

CTRL R (tR)

In the Background/Foreground system, I/O device handlers which detect a not-ready
condition will request the Monitor to print a message on the appropriate control
Teletype.

The line printer handler message, for instance, would be:
LP~

NOT READY

The unit number has no significance for the line printer.

Some single-unit

handlers, such as the card reader handler, use the unit number designation to
indicate the cause of the not-ready condition.

After the message has been

printed, the user should ready the device and then type CTRL R, which is
echoed as tR.

I/O for that device is then resumed.

While the Monitor is waiting for the user to type CTRL R, the user's program
continues execution provided that it is not hung up waiting for completion of
I/O from the not-ready device.
per job.

The Monitor can handle one not-ready condition

Should a second not-ready request occur while another is being

processed, job execution will be aborted with a .ERR ~~4 terminal error.
3.9

CTRL Q (to)

CTRL Q may be typed at any time, but it is ignored if it is not issued at a
control Teletype.
3-5

The purpose of typing CTRL Q is to stop program execution and to dump all of
core memory onto a specified area of some unit on the system device.
starts with block

l~l

octal on the given unit and overlays any data that may

have existed in that area on the output device.
octal blocks
system,

2~~

The dump

(1~1-2~~);

octal blocks

a 24K system,
(l~l

14~

A 16K system will dump

octal blocks

(l~l

24~);

l~~

a 32K

3~~).

To ensure that CTRL Q will not overlay useful data, the user must employ the
system r-rogram PIP to write a new file directory on that unit, using the (S)
switch to reserve space for CTRL Q.

For example:

>NwXX\..4,...l.(S ))
where XX is the device name and u the unit number.

Note that the size of the

CTRL Q area reserved is based on the amount of core existing in the system in
whlch the new directory is written.

The area reserved on a DECtape in a 16K

system is not sufficient to do a protected CTRL Q in a 24K or 32K system.
When the Monitor accepts

CTI~

Q, it first terminates execution of the job

( Foreground if Foreground CTRL Q, Background if Background CTRL Q).

This

involves calling all device h-ndlers tied to that job to stop I/O, clearing all
Monltor queues of entries for that job and disabling all control characters for
that job except CTRL C.
The Monitor then prints tQ on the appropriate control Teletype and reads one
character.
is to occur.

The user must then type the number of the unit on which the dump
Unit zero may not be used.

If the SHARE command is not in effect,

a dump may not be done to a unit which belongs to the other job.

If the

Monitor rejects the typed character, it prints tQ again and waits for another
character.
When the unit number is accepted, the dump takes place; then the Monitor is
automatically reloaded.

A Background CTRL Q does not affect Foreground.

ground CTRL Q, on the other hand, aborts the Background job.

A Fore-

It is not possible

to load and restart a core dump in Background/Foreground.
'3.10

CTRL U (@)

CTRL U may be typed at any Teletype unit.

If a .READ or .REALR was issued to

some Teletype and the user decides he wants to "erase" everything he has
typed for that read request, he may type CTRL U, which will be echoed to the
teleprinter as @.

The .READ or .REALR will still be in effect and he may then

retype the input.
vJhile output to a Teletype is being done as a result of a . WRITE or . REALW,
3-6

the user may type CTRL U to terminate the write.

In this case nothing is echoed

to the teleprinter.
3.11 RUB OUT ( ' )
This character is recognized only while the user is typing input to satisfy a
.READ or .REALR request.

When .typed, RUBOUT deletes the last input character.

For example, if the user has typed ABC and then RUBOUT, the ~ will be "erased".
If he now types another RUBOUT, the B will be 'erased".

Every time a character is

so removed, the character ~ is echoed to the teleprinter.
3.12

CTRL D (tD)

The character CTRL D is recognized at all Teletypes and is echoed back as tD.
When typing input, CTRL D effects an end-of-file condition by terminating the
.READ or .REALR request and storing the end-of-file,
buffer header.

~~1~~5,

in the input line

Since the word pair count returned is a 1, any characters

typed prior to the CTRL D for the same read request will be lost.

3-7

SECTION 4

LOADERS

4.1

INTRODUCTION

There are three program Loaders in the Background/Foreground system.
system file directory they are listed as .SYSLD SYS1, BFLOAD

BIN 2

On the

and

EXECUT BIN 2 •
. SYSLD is an absolute system program that functions as two loaders:

when it is

called in for Foreground loading, it is the Foreground Linking Loader; when it
is called in for Background loading, it is the Background System Program
Loader.

BFLOAD is the Background Linking Loader.

EXECUTE operates in both Foreground and Background as a loader of overlay programs
(XCT files) built by the CHAIN system program.

A description of CHAIN and

EXECUTE is given in the utility manual.
4.2

FOREGROUND LINKING LOADER

Link loading of the Foreground job is initiated by typing GLOAD (Load-and-Go)
or LOAD (Load-and-Pause) to the Monitor at the Foreground control Teletype.
The Foreground Link Loader (.SYSLD) is then brought into the top of memory,
overlaying the Non-resident Monitor.

The following message will then be

printed:
FGLOAD V2A
>

The> signals the user that he may now type in his command string.
The command string format is the same as for the Linking Loader in the ADVANCED
Monitor System:
>options+mainprog, others, ... ALTMODE

lOperates in bank mode.
20perates in page mode; operates in bank mode only when running in bank mode.

4-1

4.2.1

Option Cha-acters and their Meanings
Meaning

Character

4.2.2

Print program names and their assigned relocation
factors

Print common block names and their assigned
locations

Print global symbol names and their definitions

Use of + Terminator

Prior to the terminator + all characters except option characters are ignored.
Carriage return pLeceding the

starts a continuation line headed by>.

preceding the + restarts the Loader; therefore,

ALTMODE

loading is done unless the

character + appears in the command string.
If no option characters precede t.he

~-,

the default assumption is that no memory

map is to be prinLed.
After the +, type the program names (main program first - no extensions)
separated by comma or carriage return.
ALTMODE.

Terminate the command string with

Before the terminating ALTMODE has been typed, the Loader may be re-

started by typing CTRL P.

All files named in the command string may contain I

or more program units, and all program units will be loaded in each file named.
4.2.3

Sequence of Operation

Once the command string has been accepted, the Loader will perform the following
sequence of operations:
a.

Load to end of file all user programs!
string, from .DATF -4.

specified in the command

These programs are loaded from the bottom

of core up, starting at the top of the Resident Monitor.

Calls to

external library routines via .GLOBL, common block definitions, and
.IODEV requests are saved in the Loader's symbol table, built from
the bott0ill of the Loader down.
(wh~ch

Programs containing executable code

excludes BLOCKDATA subprograms) are relocated such that

they do not overlap core page boundaries in the page mode system or
core bank boundaries in the bank mode system.
1

These programs will operate in page mode and must not execute the EBA
instruction which would change operation to bank mode. All programs
in the bank mode system operate in bank mode only. Avoid BBA lnstructions
in the bank mode system. Although EBA instructions have no effect on the
PDP-IS, they are equivalent to a LEM (leave extend mode) on the PDF-9.
LEM has disas:6rous results during a background/foreground system run.
4-2

If a library search is necessary and the contents of .DATF -S is
non-zero, the Loader will seek the user library, .LIBRS BIN, via
that .DAT slot, and will load all requested library routines l
which it finds.

I/O device handlers must not be in the user

library.
c.

If a library search is still necessary for non-I/O routines,
the Loader will search the system arithmetic libraryl,
.F4LIB BIN, via .DATF -7 in the same manner as above.
I/O device handlers must not be in .F4LIB.

If any I/O handlers l must be loaded, the Loader searches
through the system I/O Library, .IOLIB BIN, via .DATF -7.
After this has been done, program loading has terminated.

At this point, all undefined common blocks are defined and
assigned core space.

Common blocks are allowed to overlap

page boundaries.
f.

If there are still some undefined global symbols, they will
be matched with common block names and, if a match is found,
defined as the base address of the matching common block.

For all multi-user device handlers in use for the user's
programs, external I/O buffers are assigned core space (if
necessary) and recorded in .BFTAB within the Resident Monitor.
The number of such buffers depends on the $FILES counts given
by the user to the non-resident Monitor or, if no counts
given, the number of .IODEV'ed .DAT slots calling those
handlers.

I/O buffers are allowed to overlap core boundaries.

The amount of free core assigned to the Foreground job
(contents of .SCOM+2S) is added to the current size of
assigned Foreground core to determine the upper limit of the
Foreground job.

Pointers to the first and last registers in

Foreground free core are then stored in .SCOM+2 and .SCOM+3,
respectively.
i.

The Loader now exits to the Resident Monitor.

The Resident

Monitor prints tS and waits for the user to type CTRL S, if
the Loader is called by the LOAD command.

Control then is

given to the start address of the user's main program, which
4.3

was stored in .SCOM+6 by the Loader.
BACKGROUND SYSTEM LOADER

Loading of all system programs is done by the System Loader (.SYSLD), which

~These p:ogram~ will operate in page mode and must not execute the EBA
~nstruct~on wh~ch would change operation to bank mode.
All programs in the
bank mode system operate in bank mode only.
4-3

also performs link loading for the Foreground.

Initiation of the loading cycle

is done when the user, in the Background, types a request to the Non-resident
Monitor to load a system program; e.g., $PIP, $EDIT, etc.
The Non-resident Monitor puts a code number in .SCOM+5 to tell the System Loader
which program to load.

The System Loader is then loaded into upper core overlaying

the Non-resident Monitor.

When loading a Background program other than the

Linking Loader or EXECUTE,

.SYSLD contains a SYSBLK which lists the .DAT slots

used by each system program and information about the load address, start
address, size and initial block number on the system device for each system
program.

SYSBLK exists as block

on the system device and is also used by

PATCH.
To load a system program in the Background, .SYSLD performs the following
operations:
a.

For each .DAT slot (with non-zero contents) required by a system
program, it determines which device handlers 1 are needed; and, if
a library search is necessary, it brings in the handlers from the
file .IOLIB BIN on the system device through .DATB -7.

They are

loaded starting immediately above the top of the Foreground job.
b.

I/O buffers are then assigned core space immediately above the
handlers as in the description in paragraph 4.2.3g.

The hardware

memory protect bound is set above the handlers and buffers.
c.

If the load command was $LOAD, $GLOAD, $DDT, or $DDTNS, the
Background Link Loader (BFLOAD) 1, a relocatable file, is loaded
starting just above the new hardware protect bound.

For all other system programs (excluding EXECUTE) 1, .SYSLD builds
a short routine just above the hardware protect bound to bring in
the program 2 overlaying the System Loader.

Finally, .SYSLD exits to the Resident Monitor 2 ,which establishes
the new hardware protect bound and then passes control to the
system program via the address stored by .SYSLD in .SCOM+5.

The Loader allows the loading of absolute .LOC programs prior to loading any
relocatable files.

This permits the user to load programs which may overlay

parts of the Resident Monitor.

Mixing of absolute and relocatable .LOC's in

the same program file is not allowed and will be flagged as an error.

The

loperate(s) in page mode; operates in bank mode only when using bank mode system.
20perates in bank mode.

4-4

Loader ensures that the relocatable programs do not overlay any of the absolute
programs.
The Foreground Linking Loader is also responsible for loading the system program
Plp l in the Foreground.
The Foreground version of PIP exists in the system as
the relocatable file PIP BIN.

It is loaded by typing PIP as a command to the

Non-resident Monitor2.
4.4

BACKGROUND LINKING LOADER

Lxternally, the Background Linking Loader (BFLOAD)
user as the Foreground Linking Loader.

looks nearly the same to the

When it has been loaded, it prints the

following message on the Background control Teletype:
BGLOAD V2A
>

The command string processing is identical with that of the Foreground Linking
Loader (see 4.2).
If the Load command was $DDT or $DDTNS, the system program DDTl
file)

(a relocatable

has already been loaded into the top of core via .DATB -1, prior to

reading in the command string.
Once the command string has been accepted, the Loader will perform the following
sequence of operations:
a.

Load to end of file all user programs l
string from .DATB -4.
of core down.

specified in the command

These programs are loaded from the top

Calls to external library routines via .GLOBL,

common block definitions, and .IODEV requests are saved in the
Loader's symbol table, built from the top of the Loader upwards
in core.

Programs containing executable code

(which excludes

BLOCKDATA subprograms) are relocated such that they do not overlap
page boundaries.
b.

Same action as described in 4.2.3b, using .DATB -5.

Same action as described in 4.2.3c, using .DATB -7.

If any I/O handlers must be loaded, the Loader searches through
.IOLIB BIN via .DATB -7.

The handlers are relocated to run in

lower core, that is, as if they were being loaded upwards in

lOperate(s) in page mode; operates in bank mode only when using bank mode system.
20perates in bank mode.

4-5

core,

st~~~ing

be loader
e.

just above the Foreground job.

~bove

They may, however,

the Loader if the Loader is in the way.

Same act_·., as described in 4.2 e, f, g.

Common blocks are

assigned space in upper corej I/O buffers, in lower core.
f.

The hardware memory protect bound is established above the I/O
handlers and buffers.

Common blocks may go below the hardware

protect bound.
g.

If DDT was loaded and a symbol table was requested (not
$DDTNS),

the symbol table is compacted to delete entries

not needed by DDT.

The Loader determines where the symbol

table should be movedj and, along with the I/O handlers which
were loac",d into upper core, builds a special .EXIT list which
tells the Resident Monitor where to block transfer each segment.
The DDT symbol table may be loaded below the hardware protect
bound.
h.

The Loadrr then exits to the Resident Monitor, which performs
the block transfers, sets the new hardware memory protect bound,
and transfers control to DDT (via .SCOM+S) or to the user
program (via .SCOM+6), pausing to print

and waitinq for the

user to type CTRL S if the Load command was $LOAD.
4.5

LOADING XCT FILES

XCT files are overlay programs i built by the system program CHAIN and run by
1

the system program EXECUTE.

Loading of an XCT file in either the Foreground

or the Background is initiated by typing E...,.xXX or EXECUTEuXXX to the Monitor
{where XXX is the file name without the extension XCTI.
The Non-resident Monitor,
.SCOM+l,7, 11"
Background.

BFKM15, stores the filename

(.SIXB'I' format)

and 111 for the Foreground, or .SCOM+112, 113, and 114 for the

If EXECUTE's .DAT slot requests the resident system device

handler 2 , the Monitor stores "XCS" as the extension.

If EXECUTE's handler is

different from the resident handler, the Monitor stores the extension "XCT".
The System Loader is then called in, overlaying the Non-resident Monitor in
upper core.
4.5.1

EXECUTE in the Foreground

The following operations are carried out when EXECUTE is used in the Foreground:
1

These programs will operate in page mode and must not execute the EBA instruction which would change operation to bank mode. All program5 in bank mode
system operate in bank mode only.
Runs in bank mode, unlike most I/O handlersj in the bank mode system, all I/O
handlers run in bank mode only.
4-6

EXECUTE'S handler, if different from the resident handler, is
loaded immediately above the Monitor.

The System Loader, which must open the XCT file, checks the
extension.

If "XCS", meaning EXECUTE's handler is the

resident handler, the file is loaded via .DAT -7.
it is loaded via .DAT -4.
c.

If "XCT",

The extension is then set to "XCT".

The XCT file is read and checked that it was indeed built to be run
in the Foreground of a PDP-IS in page mode.

In the bank mode system,

The XCT file is checked to ensure that it was built to run in bank mode.
d.

The upper and lower core limits of the overlay structure are
saved and a check is made that it does not overlay the
Resident Monitor.

The .IODEV bit map in the XCT file is decoded.

The loading

bound is set immediately above the area of core to be
occupied by the overlay structure and then all I/O handlers
required by the XCT file are loaded.

Also, another copy of

EXECUTE's handler is loaded (the first copy will be overlayed).
f.

EXECUTE is loaded.

Same action as described in 4.3.4g and h.

The Loader exits to the Resident Monitor.

The Monitor gives

control to EXECUTE, whose start address is stored in .SCOM+6
by the Loader.
4.S.2

EXECUTE in the Background

The following operations are carried out when EXECUTE is used in the Background:
a.

EXECUTE's handler, if different from the resident handler, is
loaded irrmediately above the Foreground job.

Same action as described in 4.S.lb.

The XCT file is read and checked that it was built to be run in the
Background of a PDP-IS in page mode.

In the bank mode system, the

XCT file is checked to ensure that it was built to run in the bank
mode.
d.

The lower core limit of the overlay structure is saved and,
when EXECUTE has been loaded, a test is made to ensure that
they do not overlap.

The .IODEV bit map in the XCT file is decoded and then any
I/O handlers needed by the file are loaded.

4-7

Same action as described in 4.3.4g.

The hardware memory protect bound is set above the I/O buffers
and EXECUTE is loaded starting above this bound.

4.6

Same action as described in 4.3e.

ERROR CONDITIONS

The number of differe~t error messages in the Loaders has been expanded in Background/Foreground.

These are tabulated in Appendix II.

The error number is passed on to the Resident Monitor by a special
error .EXIT macro (CAL sequence).

Loader errors are non-recoverable

After the error message is printed, the Monitor will automatically be
reloaded to start another job.

4-8

4.7

SYSTEM MEMORY MAPS
Memory Map A
16K

8K -----------

o
The System Bootstrap is loaded at the top of
core via the paper tape reader in HRM format.

4-9

Memory Map B

~~-L-L-L~+--System

Bootstrap

---------

.SCOM +
.SCOM +
(--Resident Monitor including the multi-unit
Teletype handler and
the system device handler,
(DTA. or DKA.)

o
The System Bootstrap automatically loads the
Resident Monitor from the system device into lower
core.

4-10

Memory Map C
• SCaM--~)16K

~Non-resident

Monitor

.scaM +
.scaM +

~Resident

Monitor

o
The Resident Monitor loads the Non-resident Monitor
(via the resident system device handler) into upper
core, overlaying the System Bootstrap.
within
itself the Resident Monitor contains a simpler copy
of the bootstrap which is used whenever the Resident
Monitor is to be reloaded. The bootstrap restart
address is location IllS"

4-11

Memory Map D

~__~Foreground

Linking
Loader (. SY SLD)

.SCOM + ~3----~r~~~~~

.SCOM +
.SCOM +

l+-____ Resident Monitor

o
To load a user FOREGROUND program, the Non-resident
Monitor brings in the Foreground Linking Loader
(.SYSLD), overlaying itself.

4-12

Memory Map E
• SCaM --~
~Foreground

Linking Loader

(. SYSLD)
~Loader's

I/O Handlers

+---Loader's Symbol Table
t-'-~~"--"--"--I

k-:1'T"7""':"""l"I~-rd ~ Hardware pro tect bound

.SCOM +
.SCOM +
.SCOM +
.SCOM +

iI-'......,....,.~....x......... .:::::::. Software protect bound

Foreground
Job

Foreground free core
+---User's I/O Handlers and
I/O Buffers
Foreground user programs
+-_____ and library routines

~Resident

Monitor

o
The Foreground Linking Loader first brings in any additional
I/O handlers required for loading.

Then it loads the user

program(s), library routines, user I/O handlers and I/O
buffers, and allocates Foreground free core.

The software

memory protect bound is established just above the Foreground
job.

The hardware memory protect bound, because it can be set

only in increments of 256 decimal, will leave some unused space
between it and the Foreground job.

The software protect bound

allows this space to be used for dynamic data storage by the
Background job.

On the PDP-9 the memory protect bound can only be

set at 1024 (10) word intervals, so the bank mode system sets
the bound at 1024 word increments, not 256, even on a PDP-IS.
For a description of loading of Foreground XCT files, see Memory
Map L.

4-13

Memory Map F
. SCOM --~)l6K

Hardware protect bound

.SCOM +
.SCOM +
.SCOM +
.SCOM + 25
.SCOM + 31

Software protect bound

E'oreground job

Monitor

o
When the FOREGROUND job becomes I/O bound. control is transferred to the BACKGROUND job.

The Resident MC:1itor loads the Non-

resident Monitor (via the resident system device handler) into
upper core.

It then gives control to the Keyboard Listener

(within the Non-resident Monitor) to await a BACKGROUN:J keyboard
command.

Memory protect is enabled while the

runni .1g.

4-14

Backgro~~d

job is

Memory Map G
.SCOM----~

Background System
(.SYSLD)

~----Loade~

.SCOM + 3 ____~~~~~~
.SCOM +
.SCOM +
.SCOM +
.SCOM +
.SCOM +

~____ Hardware

~Software

protect bound
protect bound

Foreground Job

____ Resident Monitor

When a BACKGROUND keyboard command requests loading
of a system or user program, the Non-resident Monitor
brings in the System Loader, overlaying itself.

Note

that the BACKGROUND System Loader and the FOREGROUND
Linking Loader are physically the same program, except
that SYSBLK is also read i.nto core when the BACKGROUND
system program to be loaded is other than the Linking
Loader or Execute.

4-15

Memory Map H
• SCOM

)16K
Background
+----System Program

.SCOM + 3

.SCOM +

~aCkgrOUnd Free Core
___ Hardware Protect Bound

10:-.,..,.-=-...,...,....,...-1 +--Software Protect Bound

.SCOM +
.SCOM +
.SCOM +
.SCOM +

I-"--""-",,:¥-"":;"""';:""f"'"--Background I/O Buffers

:r---:::::::::: ::: Handler'
~r-7--;l>--7-?--t

o
If the BACKGROUND request is for a system program, the
System Loader loads the system program I/O handlers up
from the top of the FOREGROUND job, allocates I/O buffer
space, and loads the system program at the top of core
(overlaying the System Loader). Control is returned to
the Resident Monitor, which sets the memory protect bound
above the buffer space and gives control to the system
program.

4-16

Memory Map I
.SCOM
i-----+16K
.SCOM + 3

~ Background

Sys tern
Loader (. SYSLD)

.SCOM + 2
4--- Background

Linking Loader

. SCOM + 312~~ .......-'--'--I-.L-'-..Lj ~ Hardware Protect Bound
• SCOM +
~Link Loader I s I/O Handlers
.SCOM + 25
Software Protect Bound
.SCOM + 31
Foreground Job

o
If the BACKGROUND program is a user prograffi l , the
System Loader loads the Linking Loader I/O handlers
up from the top of the FOREGROUND job and loads the
Linking Loader such that the memory protect bound
can be set just below it.
lUser programs may be loaded along with the system
program DDT.

4-17

Memory Map J
.SCOM
~ 16K
.SCOM + 3

~ Background

user Programs and
Library. Routines

4 - - - Background

User I/O

Handlers
. SCOM + 2 _ _ _ _ _-+} g~~;:;:~~ + - - Loader I s Symbol Table
4---Background Linking Loader
.SCOM + 32
.SCOM +
.SCOM +

Bound

~5J

------.,.) ~~~~~

Bound

Job

.SCOM + 31

~Resident

Monitor

o
The BACKGROUND Linking Loader overlays the System Loader
by loading user programs down from the top of core.

User

I/O handlers, presuming that they cannot fit in core
between the FOREGROUND job and the bottom of the Loader,
are loaded into upper core but relocated to run just above
the FOREGROUND job so that the memory protect bound can
be set above them.

Common blocks and I/O buffers are not

shown in this memory map.

Memory Map K
.SCOM--~

~ Background

User Programs
and Dibrary routines

.SCOM +

Background Free core

• SCaM +
.SCOM +

~~~---Hardware

.SCOM +
.SCOM +
.SCOM +

Protect Bound
Protect Bound

__~~~~~~~~~----Background User I/O handlers
Foreground ,Job

~----Resident

Monitor

The .EXIT from the Linking Loader causes the user program
I/O handlers to be block transferred to their running
position, the memory protect bound to be set just above
the I/O buffer space, and control given to the user program.
If DDT was also loaded, it resides at the top of core, above
the user programs.

Its symbol table, built by the Loader,

is block transferred by the Monitor to start at the software protect bound.
IIf DDT is loaded, .SCOM + 1 will be set to point at the start
of the DDT symbol table.

4-19

Memory Map L
.ScOM--------~

table
.SCOM + 32----~~ ________ ~Hardware protect bound
.SCOM + 25 and 31~
~Software protect bound
.SCOM + 3----____;
. SCOM + 2----4IOOro~~m

;-i

~~~~~~+----EXECUTE
~__~~~~

Foreground._____
Job

I/O Handlers + I/O buffers
including 2nd copy of
EXECUTE's handler
Core occupied by
Overlay structure

1st copy of EXECUTE's
I/O handler

~---RResident

Monitor

o
EXECUTE in the Foreground:
The System Loader first loads EXECUTE's I/O handler (if not
the resident handler) in order to read the XCT file.

The

core limits of the overlay structure are read from the file
as well as the request for I/O from its .IODEV bit map.
The requested handlers, including a second copy of EXECUTE's
handler, are loaded above the core area to be occupied by
the overlay structure.

Then I/O buffers are created, if

necessary, and EXECUTE is loaded above them.

Finally,

Foreground free core, the software protect bound, and the
hardware protect bound are established.

4-20

Memory Map M
· SCaM -----~
~----System

Loader

Core occupied by
Overlay structur
~----Loader's

.SCOM + 3

~----Free

.SCOM + 2

symbol table

core

~---.EXECUTE

· scm, + 32

bound

· SCaM + 31
Bound
.SCOM + 25

Background I/O handlers
and I/O buffers
Foreground job

~___ Resident

Monitor

o
EXECUTE in the Background:
The System Loader loads EXECUTE's I/O handler (if not in
core) in order to read the XCT file.

The core limits of

the overlay structure and the I/O requests in the .IODEV
bit map are read from the XCT file.

The user's I/O

handlers and I/O buffers are then loaded above EXECUTE's
handler, and the hardware protect bound is established
above them.

EXECUTE is loaded above the bound and Back-

ground free core is set up from the top of EXECUTE to the
bottom of the overlay area.

4-21

SECTION 5
EXAMPLES OF BACKGROUND/FOREGROUND OPERATIONS

5.1

INTRODUCTION

The initial system startup procedure and three examples of operating within the
Background/Foreground environment are described in this Section.

The procedure

and examples are intended to get the programmer "on the air" and to demonstrate
loading programs in the Foreground.
5.2

STARTUP PROCEDURES

During

ini~ial

system startup, the user normally loads the master system suppliea

(on DECtape) and utilizing system program BFSGEN generates a "working system".
The user may run using the master system, but it is usually more desirable to
generate a working system which is optimized to meet the user's needs and
particular equipment configuration.
5.2.1

Loading Master B/F Monitor System

The master system for both the DECtape and DECdisk B/F systems is supplied on
DECtape.

To load the master system into a PDP-IS/3D (DECtape system):

Mount the master DEC tape onto a transport (TU-55 or -56) and set
its unit number to that of the system device; that is, ~ on a
TU-56, 8 on a TU-55.

Load the paper tape Bootstrap; B/F V3A uses the multi-core bootstrap.

Set the console address switches as follows:
If you have a -

Set Switches to -

16K system
24K system
32K system
4.

37637
57637
77637

Check to ensure that the MEMORY PROTECT/RELOCATE switch is in the
PROTECT position.

This switch is located at the rear of the

memory protect cabinet.

P-mode and R-mode indicator lights are

mounted on a panel located at the top front of the cabinet.
PDP-9 does not have a MEMORY PROTECT/RELOCATE switch.

7.1~

A PDP-9 equip-

ped with the memory protect feature will always be in the protect
position.

Press and release, in sequence, the console STOP, RESET, and READIN
switches.

5-1

When loaded, the Monitor identifies itself and indicates its readiness ey outputting the following message on the Foreground control Teletype (normally unit 1) :
FKM15 V3A
$
To load the master system into a PDP-15/40 DECdisk system:

Mount the master disk system DECtape onto a transport and set its
unit number to that of the system device1 that is, {I on a TU-56;
8 on a TU-55.

Load the RFSAV paper tape (supplied with the system) into the paper
tape reader.

Set the console address switches to l772{1.

Set the DECdisk WRITE LOCKOUT switches for disk unit {I to the WRITE
ENABLE position.

Press and release, in sequence, the console STOP, RESET, and READIN
switches.

When loaded, the RFSAV program outputs the following

message:
RFSAV V2A
SET: ACS{I= {I DECTAPE TO DISK (LOAD)
ACS{I= 1 DISK TO DECTAPE (SAVE)
ACS15-l7= UNITi{l,1,2,3,4,5,6,7
6.

Set all console AC switches to the {I position.

Press and release the console CONTINUE switch.

This action causes

the disk system contained by the DECtape on unit {I to be copied onto
disk unit {I.
8.

Set the DECdisk WRITE LOCKOUT switches to the WRITE DISABLE position.

Load the disk multicore bootstrap, RF15BT, into the paper tape reader.

10.

Set the console address switches as follows:
Set Switches to -

If ::t0u Have a 16K system

37637

24K system

57637

system

77637

32K

5-2

11.

Press and release, in sequence, the console STOP, RESET, and READIN
switches.

When loaded, the Monitor identifies itself and

indicates its readiness by outputting the following message on the
Foreground control Teletype:
FKM15 V3A
$
5.2.2

System Generation

A step-by-step procedure for the generation of a working system from a master
system is given in Section 8 of this manual.
5.3

EXAMPLES

Three example procedures are described in paragraphs 5.3.1, 5.3.2, and 5.3.3.
These procedures are used to demonstrate the loading of IDLE, single-user FOCAL,
and two-user FOCAL in the Foreground.
The following conventions are used for the examples given:
1.

All user inputs are underlined.

Readiness to accept commands is indicated by the symbol $ for the Monitor
and the symbols > and

3.
5.3.1

* for system programs.

The entry of an ALTMODE character is indicated by the symbol

<!>.

IDLE Loaded as the Foreground Job

An Idle job is loaded in the Foreground to allow immediate use of the Background.
Refer to section 6.4 for a discussion of the .IDLE system macro.
FKM15 V3A
$A DTA~
or

DKA~

-4
-4

(DECtape) /The program "IDLE" is on unit
(DECdisk)

of the system device.

$GLOAD
FGLOAD V2A
>+-IDLE @

/The Loader is in core.
/Load "IDLE BIN".

When IDLE is loaded, no indication is given on the Foreground control Teletype.
Control passes to the Background and the Non-resident Monitor is then loaded into
core.

The Monitor identifies itself on the Background control Teletype as:
BKMl5 V3A
$

/The Monitor is now ready to
/accept Background commands.
5-3

5.3.2

Single-user FOCAL Loaded (Foreground)

The following illustrates a step-by-step procedure to load single-user FOCAL in
the Foreground:

FKM15 V3A
$A DTJl -4 (DECtape)
SA DK/8 -4 (DECdisk)
$A OTt 3,5
$A DT3 7,1J1
$FCORE 14/8/8
"fGLOAD

/FOCAL is on unit Jl of
/the system device.
/Library input-output to FOCAL.
/User's data input-output.
/Free core for FOCAL buffer.
/Call loader to LOAD-and-Go.

FGLOAD V~2
>+-FOCAL _
FOCAL

/Loader is in core.
/Load FOCAL.
/FOCAL is in core and is ready to
/accept commands.
/User can begin to run FOCAL commands.

5.3.3

Two-user FOCAL Loaded (Foreground)

FKM15 V3A
$A DTJI -4
$A DK/8 -4
SA TTl
$A DTI
$A TT2
SA DT2

(DECtape)
(DECdisk)

~FCORE

GLOAD

FGLOAD V2h
>+FOCAL2 ':dY
FOCAL V9A

/FOCAL is on unit Jl of
/the system device.
/Teletype for User #1.
/Library input-output for User #1.
/Teletype for User #2.
/Library input-output for User #2.
/Assign 14JlJl (octal) locations
/for each user.
/Call Loader to LOAD-and-Go.
/Loader is in core.
/Load two-user FOCAL'
/FOCAL is in core and will identify
/itself on each user's Teletype.
/User can begin to run FOCAL programs.

NOTE
Two-user FOCAL is not available on
the bank mode B/F V3B system.

5-4

SECTION 6
BACKGROUND/FOREGROUND MONITOR COMMANDS (SYSTEM MACROS)

6.1

INTRODUCTION

The system MACROS unique to the Background/Foreground Monitor are listed and
described briefly in Table 6-1.

The Monitor Macros listed below are available

in addition to those provided in the

PDP-ls/2~

Monitor System for use in

programs that are to be run in the Background/Foreground environment.

Detailed

descriptions of the macros are given in the remainder of this Section.
The .INIT macro has been altered for Background/Foreground to handle the CTRL P
restart address in a manner different from the Advanced Monitor.

Refer to

Section 3 for an explanation.
TABLE 6-1
Background/Foreground System Macros
Purpose

Name

6.2

.REALR

Real-time transfer of data from I/O device to line
buffer (real-time READ).

.REALW

Real-time transfer of data from line buffer to I/O
device (real-time WRITE).

.IDLE

Allows Foreground job to indicate that control can
be given to lower levels of the Foreground job or to
the Backqround job until completion of any Foreground
real-time transfer or clock interval.

.IDLEC

Allows Foreground Mainstream to give control to
Background job with Foreground continuing after the
.IDLEC on completion of any Foreground real-time
transfer or clock interval.

.TIMER

Calls and uses real-time clock and allows priority
level to be established.

.RLXIT

Accomplishes the exit from all real-time subroutines
that were entered via .REALR, .REALW, .TlMER, or
real-time CTRL p1requests.

.REALR
FORM:

.REALR A, M, L, W, ADDR, P

VARIABLES:

A = .DAT slot number (octal radix)

M2= Data Mode

ISee Section

~ =
{ 1 =
2 =
3 =
4 =

IOPS binary
Image binary
lOPS ASCII
Image Alphanumeric
Dump Mode

ls-bit buffer address (octal radix)

3.7.

2Data modes 5, 6, and 7 are passed to all I/O handlers.
6-1

W = Line buffer word count (decimal radix) ,
including the two-word header
ADDW= IS-bit address of closed subroutine that
is given control when the request made by
the .REALR is completed.
P

API priority level at which to go to ADDR
P

Prioritl Level

Mainstream
Level of .REALR
API software level S
API software level 6
API software level 7

S
6
7
EXPANSION:

LOC
LOC+l
LOC+2
LOC+3
LOC+4

CAL+I~~~~+M6_8+A9_17

l~
L

/Decimal Radix

.DEC
-W
.OCT
ADDR+P,0_2

/Octal Radix

DESCRIPTION: The .REALR command is used to transfer the next
line of data from the device assigned to .DAT slot A to the line
buffer in the user's program. In this operation, M defines the
mode of the data to be transferred, L is the address of the line
buffer (including the two-word header), and ADDR is the address
of a closed subroutine which should be constructed as shown in
the following example.
EXAMPLE 1:

STRUCTURE OF A REAL-TIME SUBROUTINE

ADDR

6.3

/Entry point
DAC

SAVEAC

/SAVE AC and all other
/live registers used.
/Any system Macro may be
/issued at this point.

LAC

SAVEAC

.RLXIT

ADDR

/Restore AC and all other
/registers saved.
/Return to interrupted
/point via Monitor CAL.

.REALW
FORM:

.REALW A, M, L, W, ADDR, P

VARIABLES:

A = .DAT slot number (octal radix)

IThe subroutine specified by a .REALR, .REALW, .TIMER, or real-time CTRL P
should not be used at more than one priority level. The subroutine is
entered via a JMS and normally cannot be protected against re-entry.

6-2

Ml= Data Mode

Image binary
{I2 == lOPS
ASCII
= lOPS binary

3 = Image Alphanumeric
4 = Dump Mode
L

15-bit Line buffer address (octal radix) .

Line buffer word count (decimal radix),
including the two-word header

ADDR2= 15-bit address of closed subroutine that is
given control when the request made by the
.REALW is completed.
P

API priority level at which to go to ADDR
P

Priority Level

Mainstream
Level of .REALW
API software level 5
API software level 6
API software level 7

4
5
6
7

EXPANSION:

LOC
LOC+I
LOC+2

LOC+3

.DEC
-W
.OCT

LOC+4

ADDR+P~_2

/Decimal Radix
/Octal Radix

DESCRIPTION: The .REALW command is used to transfer the next line
of data from the line buffer in the user's program to the device
assigned to .DAT slot A. In this operation, M defines the mode of
the data to be transferred, L is the address of the line buffer, W
is the count of the number of words in the line buffer (including
the two-word header), and ADDR is the address of a closed subroutine
which should be constructed as shown in EXAMPLE I above.
6.4

.IDLE
FORM:

• IDLE

EXPANSION:

LOC
LOC+I

CAL
17

DESCRIPTION: The Foreground job in a Background/Foreground environment can indicate that it wishes to relinquish control to lower levels
of the Foreground job or to the Background job by executing this
command. This is useful when the Foreground job is waiting for the
completion of real-time I/O from anyone of a number of I/O requests
that it has initiated or for completion of .TIMER requests.
The .IDLE is the logical end of the current level's processing;
IData modes 5, 6, and 7 are passed to all I/O handlers.
2The subroutine specified by a .REALR, .REALW, .TlMER, or real-time CTRL P
should not be used at more than one priority level. The subroutine is
entered via a JMS and normally cannot be protected against re-entry.

6-3

that is, control never returns to LOC+2. If the .IDLE is issued at
a Foreground API software level, it effects a debreak (DBR) from
that level so that pending real-time routines at that level will not
be executed until the level is requested again. If the .IDLE is
issued at Foreground Mainstream, control goes to the Background job.
If the .IDLE is issued at Background Mainstream, control is returned
to the .IDLE CAL.
6.5

.IDLEC
FORM:
EXPANSION:

.IDLEC
LOC
LOC+l

CAL+l~~~

DESCRIPTION:
.IDLEC is identical to .IDLE except when issued at
the Foreground Mainstream level. In this case, control goes to the
Background job, and LOC+2 is saved as the Foreground Mainstream
return pointer. The next time control returns to Foreground (at
any priority level), Foreground Mainstream processing will resume at
LOC+2 when Mainstream becomes the highest active Foreground level.
6.6

. TIMER
FORM:

.TIMER N, ADDR, P

VARIABLES:

N1 = Number of clock increments (decimal radix)
ADDR2= IS-bit address of closed real-time subroutine
to handle interrupt at end of interval
P = API priority level at which to go to ADDR
P

Prioritl Level

Mainstream
Level of . TIMER
API software level 5
API software level 6
API software level 7

5
6

7
EXPANSION:

LOC
LOC+l
LOC+2

CAL 3
14
ADDR+P~_2

LOC+3

.DEC
-N

/Decimal Radix

DESCRIPTION:
.TIMER is used to set the real-time clock to N increments
and to start it. Each clock increment represents 1/60 second for 60
Hz systems and 1/50 second for 50 Hz systems. When the Monitor services
the clock interrupt, it passes control to location ADDR+l with the
priority level set to P. The coding at ADDR should be in closed subroutine form, as in EXAMPLE 1.

ITO transfer control to subroutine ADDR at priority level P immediately, N
should be set equal to zero.
2The subroutine specified should not be used at more than one priority level.
The subroutine is entered via a JMS and normally cannot be protected against
re-entry.
3W
hen bit 8 of CAL is set to 1, an abort .TIMER is effected. All intervals
having the same address and priority level (LOC+2) will be aborted.
6-4

6.7

.RLXIT
FORM:

.RLXIT ADDR

VARIABLES:

ADDR = 12-bit 1 entry point address of the
real-time subroutine from which an exit
is to be made.

EXPANSION:

LOC
LOC+I

ADDR

DESCRIPTION:
.RLXIT is used to exit from all real-time subroutines
that were entered via .RE~R, .RE~W, .TlMER, or real-time CTRL P
requests.
The instruction just preceding the .RLXIT call should
restore the AC with the value of the AC on entrance to this subroutine.
.RLXIT will restore the link from bit ~ and page/bank mode
from bit I of the contents of ADDR .
. RLXIT protects against re-entrance to Background or Foreground Mainstream real-time subroutines. When the contents of ADDR is non-zero,
the subroutine is assumed active; .RLXIT sets the contents of ADDR
to ~, thus making it available again. Note:
Real-time subroutines
should initially have their entry point register set to ~; and
restart procedures, entered via CTRL P or after CTRL T, should reset
all entry points to ~.
6.8

MAINSTREAM RE~-TlME SUBROUTINES

Mainstream real-time subroutines in the Foreground are not equivalent to those
in the Background due to the manner in which I/O busy situations are handled.
If the Background becomes I/O busy, the Monitor "sits on" the Background CAL
instruction (while Background is in control) until it can be processed.
Therefore, Background Mainstream real-time routines can be executed despite
the fact that Background Mainstream is I/O busy.

If Foreground Mainstream is

I/O busy, Foreground Mainstream real-time routines cannot be executed until the
busy situation is terminated.

This is due to the fact that control is given to

the Background whenever Foreground Mainstream becomes I/O busy.

The device

handler responsible for the busy situation is remembered in the Foreground Mainstream busy flag.

Mainstream real-time routines cannot then be run because

they too could become busy.
This situation can be avoided either by using .REALR or .REALW in conjunction
with .IDLE or .IDLEC, or by using .WAITR to prevent Foreground Mainstream from
becoming I/O bound.
6.9

API SOFTWARE LEVELS -- PROGRAMMING NOTE

On configurations that have API, elements of the Foreground job may run at four

IThe Resident Monitor, which operates in bank addressing mode, uses .RLXIT
with a 13-bit entry point address.
In the bank mode system, all addresses
have 13-bit values.

6-5

priority levels (levels 5, 6, and 7 of the API and Mainstream).
to understand that as Foreground becomes

It is important

rio busy at a given level, the Monitor

drops to the Foreground's next highest active level.
The lower level may be dependent upon the completion of the I/O that caused the
higher level to become busy.

The following coding method is incorrect because

the lower level will receive control as a result of the I/O

~ being

done.

Level 5 Subroutine
.READ n,2,BUFFER,52
.WAIT n
When the Monitor processes the .READ and encounters the unsatisfied .WAIT, it
recognizes this as an I/O busy situation on level 5 and drops control to the
next lower active level.

Suppose at level 7 there is a user subroutine dependent

upon the contents of BUFFER.
Level 7 Subroutine
.WRITE x,2,BUFFER,52
In the above case, the .WRITE will be executed independent of whether the level
5 I/O call to fill BUFFER has been completed.
Two proper coding methods would be:
(1)

to perform the .WRITE within the levelS subroutine after
the .WAIT ni

(2)

to use a .REALR at levelS which would specify the level 7
subroutine to be called upon completion of the .REALR.
This would eliminate the need for .WAIT n in the levelS
subroutine.

6-6

SECTION 7
WRITING DEVICE HANDLERS FOR THE PDP-IS
BACKGROUND/FOREGROUND MONITOR SYSTEM

WARNING:
I/O device handlers and service routines
written according to this section will
operate on a PDP-IS in page mode or, with
the modifications noted, on a PDP-9 or
PDP-IS in bank mode. For further information, read section 7.13.
7.1

INTRODUCTION

The reader is assumed to be acquainted with the concept of an I/O device handler
from experience using the Keyboard Monitor system.

I/O handlers are a con-

venience because they interface to user programs by accepting-a small set of
standard commands (Monitor calls), e.g., .READ and .WRITE.

Within reason,

programs can be written to function without regard to specific I/O devices.
They refer to logical devices

(.DAT slots) and the assignment of real devices

is made at program load time.

Device handlers, because they interface with the

Monitor, must conform to certain established conventions (which differ from
those in the Keyboard Monitor environment) and are more difficult to write and
to understand than stand-alone I/O service routines.
An I/O service routine 1 , unlike a device handler, is coded into the user program
or is loaded as a user subprogram.

It interfaces directly with the user program

and does not use system macros (.READ, etc.), does not use .DAT slots, and is
not loaded from the system's I/O library.

Such a routine cannot normally2

operate in the Background because it employs lOT instructions.
7.2

I/O SERVICE ROUTINE

The coding of an I/O service routine is most easily explained by example.
sider a device which consists of two pushbuttons.

Con-

Each sets a hardware flag

which can be tested by skip lOT, and either flag being set requests a hardware
interrupt.

The device has the following lOT instructions:

lThe term I/O service routine is used in this section to distinguish a simple,
direct interface user I/O routine from a standard, full-blown I/O device handler.
2Re fer to the MPOFF command in Section 2.5.12.

7-1

PBSFI

/Skip if button I flag is set.

PBCF1

/Clear button 1 flag.

PBSF2

/Skip if button 2 flag is set.

PBCF2

/Clear Button 2 flag.

If the device were connected to the API assume that it would interrupt at API
level 3 and via API channel

(Register

6~).

If the device were connected to

the PIC it would interrupt at API level 3 2 and via Register ~ (as all PI devices
do) .
At system generation time one would have to add this as a new device to the
system.

The following illustrates the conversation with the System Generator

(read Section 8):
API CASE:
MORE I/O? Y
DEVICE NAME > PB)
NUMBER OF INTERRUPTS SETUP > 1)
API ? Y
SKIP lOT > fij6~1)
API CHNL > 2
PI CASE:
MORE I/O ? Y
DEVICE NAME-> ~
NUMBER OF INTERRUPTS SETUP >
API ? N
SKIP ICYT >
MNEMONIC >
SKIP lOT >
MNEMONIC

In the API case, note that both device flags interrupt via the same API channel;
hence, only one .SETUP call is needed.
Since PB is added as a new device, the System Generator assumes the existence
of a "PBA" handler.

To be safe, change the handler to "PBW" so that this non-

existent handler is not inadvertently assigned to some .DAT slot .

. TITLE FOREGROUND JOB

/THE PUSHBUTTON SERVICE ROUTINE COULD BE A SEPARATELY LOADED SUBPROGRAM;
/HOWEVER, HERE IT IS SHOWN AS IN-LINE CODE WITHIN A LARGER PROGRAM.
/IN THE NORMAL MODE OF SYSTEM OPERATION THIS CODE IS ILLEGAL IN THE
/BACKGROUND BECAUSE IT USES lOT INSTRUCTIONS~. SINCE THE MONITOR HAS NO

True only of the PDP-IS.
See Section 2.5.12.
7-2

/CONNECTION TO THIS SERVICE ROUTINE, THERE IS NO WAY TO GUARANTEE THAT THIS
/DEVICE HAS STOPPED I/O BEFORE RELOADING THE MONITOR 1 , E.G., FOLLOWING CTRL C.
/THIS IS MAIN PROGRAM CODE AND
/NEED HAVE NOTHING TO DO WITH
/THE "PB" SERVICE ROUTINE.

BEGIN •

/"PB" (PUSHBUTTON) SERVICE ROUTINE.
THE FOLLOWING IS ONCE-ONLY
/INITIALIZATION CODE.
THESE LOCATIONS MAY BE USED LATER ON FOR TEMPORARY
/STORAGE (AS SHOWN).
AC~

. SETUP
TEMP 1
REALTP

LAC *
DAC
LAC *
DAC

(. SCOM+55
. SETUP
( • SCOM+51
REALTP

/ADDRESS OF THE MONITOR'S
/.SETUP ROUTINE .
/ADDRESS OF THE MONITOR'S
/REALTP ROUTINE.

/RAISE TO API LEVEL 4 FROM THE MAINSTREAM LEVEL.
THE MONITOR'S .SETUP
/ROUTINE IS. CALLED FROM THE CAL LEVEL AND IS NOT REENTRANT CODE.
ACl
AC2

LAC

ISA

/CALL THE MONITOR'S .SETUP ROUTINE TO LINK HARDWARE INTERRUPTS FROM
/THE DEVICE TO THE SERVICE ROUTINE NOW THAT IT IS IN CORE2. AT SYSTEM
/GENERATION TIME, IT IS ASSUMED, BFSGEN RESERVED API CHANNEL 2~
/(REGISTER 6~) FOR THIS DEVICE BY PLACING THERE A "JMS* (ERROR"
THE .SETUP
/INSTRUCTION AND ASSOCIATING IT WITH THE SKIP lOT "PBSF1".
/ROUTINE WILL CHANGE THE INSTRUCTION TO "JMS* (PBINT".
JMS*
PBSFl
PBINT

• SETUP

/CALL .SETUP WITH 2 ARGUMENTS:
/THE SKIP lOT AND THE ADDRESS
/OF THE INTERRUPT SERVICE ROUTINE.

/IF THIS DEVICE IS ON PI, A SECOND .SETUP CALL IS NECESSARY BECAUSE
/THERE WILL BE TWO SKIP lOT'S IN THE SKIP CHAIN.
FOR PI DEVICES,
/THE ENTRY INSTRUCTIONS ARE "JMP* (PBINT".
JMS*
PBSF2
PBINT

. SETUP

/CALL .SETUP WITH 2 ARGUMENTS:
/SKIP lOT AND THE ADDRESS
/OF THE INTERRUPT SERVICE ROUTINE.

/DEBREAK FROM LEVEL 4 BACK TO MAINSTREAM.
DBK
/END OF ONCE-ONLY CODE.
/MAIN PROGRAM PROCESSING MAY NOW CONTINUE UNTIL IT IS INTERRUPTED BY ONE
/OF THE PUSHBUTTON FLAGS.

/THE FOLLOWING IS THE INTERRUPT SERVICE ROUTINE FOR THE PUSHBUTTONS.
/IS ENTERED AT API LEVEL 3.

/IN THE CASE WHERE THIS DEVICE IS ON API, THIS ROUTINE IS ENTERED VIA A
/JMS INSTRUCTION.
THE STATE OF THE PROGRAM INTERRUPT CONTROL (ION OR IOF)
/WILL NOT BE ALTERED.

ISee Section 7.8.
2See Section 8.3.4, Note 3.

7-3

PBINT

DBAl
DAC

AC~

/LINK + PAGE/BANK + MEM.PROT. + PC.
/ENTER PAGE MODE.
/SAVE THE ACCUMULATOR.

/IF, INSTEAD, THE DEVICE IS CONNECTED TO THE PIC, THE ROUTINE IS ENTERED
/BY A JMP INSTRUCTION AND THE FOLLOWING CODE SHOULD BE SUBSTITUTED FOR
/THE ABOVE. THE PIC IS OFF (IOF).
PBINT

DBA
DAC
LAC*
DAC
DZM*
ION 2

ACI'
(I'
PC
(I'

/ENTER PAGE MODE.
/SAVE THE ACCUMULATOR.
/SAVE THE INTERRUPT POINT:
/LINK + PAGE/BANK + MEM.PROT. + PC.
/NECESSARY ON THE PDP-9; GOOD
/PRACTICE ON THE PDP-IS.

/FROM HERE ON, THE CODE IS COMMON TO BOTH API AND PIC DEVICES.
PBSFI
JMP
PBCFl

PB2

/SKIP IF BUTTON 1 FLAG SET.
/NO. MUST BE BUTTON 2.
/CLEAR BUTTON 1 FLAG.

/BUTTON 1 IS INTERPRETED TO MEAN: REQUEST REAL-TIME SUBROUTINE "SUBRl"
/AT API SOFTWARE PRIORITY LEVEL 5.
LAC
JMP
/BUTTON 2 MEANS:
PB2

(SUBRl+S~~~~~

RUN. IT
REQUEST "SUBR2" AT API LEVEL 6.

PBCF2

/CLEAR BUTTON 2 FLAG.

LAC

/CALL THE MONITOR'S REALTP SUBROUTINE TO PLACE THE REAL-TIME REQUEST IN
/THE API QUEUE. AS SOON AS THE API LEVEL AT WHICH THE SUBROUTINE IS TO RUN
/BECOMES THE HIGHEST ACTIVE LEVEL, THAT SUBROUTINE WILL BE CALLED.
RUN. IT

DAC
LAC *
ISA
LAC
JMS*
DBK

TEMPI
(. SCOM+l~2
TEMPI
REALTP4

/RAISE TO API LEVEL I' OR LEVEL 1.

/SUBR+API LEVEL CODE.
/TO LEVEL 3.

/NOW THAT THE PUSHBUTTON HAS BEEN SERVICED AND A SPECIFIC ACTIVITY
/(SUBRl OR SUBR2) HAS BEEN SCHEDULED, EXIT FROM THE HARDWARE LEVEL TO
/THE API LEVEL 4 INTERRUPT HANDLER IN THE MONITOR. LEVEL 4 IS THE SYSTEM
/DISPATCHER WHICH DECIDES WHAT IS TO BE RUN NEXT BASED UPON CONDITIONS SET
/BY HARDWARE INTERRUPT ROUTINES.
1

Omit DBA instructions in background /foreground bank mode.

2 The ION instruction may precede the clearing of the device flags on the
PDP-IS so long as operation continues at API level 3. On a PDP-9, however,
the ION must come after the flags have been cleared; otherwise, an immediate
interrupt would occur, unless the ION was executed after a raise to API level 3.

3Refer to section 7.4 which explains why .SCOM+102 is used to protect common
Monitor routines from reentrancy.

4rf the highest Monitor API level is defined to be level one, according to
the contents of .SCOM+102, then REALTP must not be called at API level zero.
This statement holds true for all Monitor routines called at the highest
Monitor level.

7-4

/REQUEST AN API INTERRUPT
/AT SOFTWARE LEVEL 4.
/RESTORE THE ACCUMULATOR.
/OEBREAK AND RESTORE FROM LEVEL 3.

LAC
ISA
LAC
DBR

/IF THE DEVICE IS ON API, THE INTERRUPTED PC IS STORED IN "PBINT".
JMP*

PBINT

/IF THE DEVICE IS ON THE PIC, THE INTERRUPTED PC IS STORED IN "PC".
JMP*

/WHICHEVER JMP* IS USED, IT MUST IMMEDIATELY FOLLOW THE DBR. ONCE THE
/OBR HAS BEEN EXECUTED, THERE MUST BE NO POSSIBILITY OF INTERRUPTING BEFORE
/THE JMP* IS DONE. ALL DECISION MAKING MUST THEREFORE PRECEDE THE DBR.
/END OF PUSHBUTTON SERVICE ROUTINE.

/API LEVEL 5 REAL-TIME SUBROUTINE -- DOES SOMETHING AS A RESULT OF BUTTON 1
/HAVING BEEN PRESSED.
SUBRI

DAC

ACI

LAC
. RLXIT

ACl
SUBRI

/API LEVEL 6 REAL-TIME SUBROUTINE -- DOES SOMETHING AS A RESULT OF
/BUTTON 2 HAVING BEEN PRESSED.
SUBR2

DAC

AC2

LAC
. RLXIT

AC2
SUBR2

This is a very simple I/O service routine.

It does not perform data manipUla-

tion and does not issue any lOT's that could cause further interrupts.
7.3

I/O DEVICE HANDLER

A device handler written to operate in the Background/Foreground Monitor
environment must conform to the rules outlined in the remainder of this

,
7-5

section.

Handl

differ from I/O service routines in the following ways:

They L . .;.",.<:<.<:ace to user programs via Monitor calls, e.g., . READ.

Because they are referenced by .DAT slot number, they can be

Except for TTA. and the resident system device handler, all

used bv device independent Psograms.
handlers are part of the system's I/O library.
4.

Handlers can be used by the Background job when there is no
conflict with Foreground needs.

I/O handlers all have STOPIO routines which allow the Monitor
to shut down I/O in an orderly fashion.

This is absolutely

necessary when a handler is to be used by the Background .job.
7.3.1

Types of Device Handlers

There are three types of I/O device handlers that can operate within the
Background/Foreground Monitor System:
1.

Single user -- This handler can be used by either the Foreground
job or the Background job but not both during the same core load;
that is, it is dedicated to one job and the Monitor System will
not permit the other job to be connected to it.

Sequential Multi-user -- This handler can be connected to both
the

For~ground

and the Background job and both can utilize

it on a sequential first-come-first-served basis.
3.

Multi-user -- This handler can be connected to both the Foreground
and the Background jobs with the Foreground job having priority
on usaqo.

If the Background job is using the handler and Fore-

ground requires it, the Background I/O will be deferred until
the Foreground I/O has been completed.
This section is primarily devoted to describing the development of single-user
handlers.

Thereafter, the transition to a sequential multi-user handler is

described.
I/O handler type 3 (Multi-user)

is not described because it is unlikely that

a customer will need to write one and because the description would overly
complicate this section of the manual.

Should the need to write such a

handler arise, it is recommended that a listing be obtained of the Multi-user
DEC tape (DTA.) or Disk (DKA.) handler to be used as a guide.
All device handlers, except for TTA. and the resident system device handler,
are loaded to run in page mode and therefore may use indexed instructions.
Where they do so, however, they must save and restore the Index Register (and
7-6

Limit Register, if used).

All device handlers in the bank mode system run only

in bank mode; no indexed instructions are allowed in the bank mode system.
7.3.2

General Structure of Device Handlers

User program commands to device handlers are initiated by CAL instructions,
which trap to absolute location

octal in the Monitor.

The CAL handler in

the Monitor, operating at API level 4, transfers control to the CAL processing
section of the device handler at level 4.
All devices which perform I/O should be interrupt drivenl, i.e., should rely
on a hardware interrupt condition to signal I/O completion.

Without an interrupt,

the device would have to be polled after elapsed clock intervals

(which is pos-

sible for slow devices) or tested continuously (which defeats the purpose of a
real-time system).

Handlers which perform I/O will, in general, have an

interrupt service routine which operates at the API level of the hardware.
For some devices, all I/O must be solicited.

For example, no interrupt from the

papertape punch can occur until the handler, PPA., has initiated I/O as a result
of some Monitor call.

This fact allows the CAL and interrupt portions of PPA.

to share common storage registers and common code.
Some devices, such as Teletype, generate unsolicited interrupts which can occur
while the Teletype handler is processing a CAL command.

Therefore, the CAL and

interrupt portions of TTA. cannot use common code and common registers except
where the CAL code raises to API level 3 (the hardware level for Teletypes) to
prevent Teletype interrupts.
Besides CAL and interrupt processors, a handler must have subroutines for stopping I/O.

The STOPIO code is called at Mainstream (all API levels inactive) but

is guaranteed not to be called while CAL processing is in progress.
7.4

REENTRANCY PROTECTION

There are common routines in the Monitor which are called by all device handlers.
Since these routines cannot be reentered 2 , all calling programs must raise to
the highest commonly used API level in order to avoid being interrupted.
API level
level

Normally,

is the highest commonly used level; and the instructions to raise to

would be:
LAC
ISA

(4~~2~~

1 The core-to-core handler, COA., is an example of a handler which is not interrupt
driven; and therefore all its processing is done at the CAL level (API level 4).

2 Interrupted,

entered at a higher API level, and then resumed at the lower level.
7-7

However, some Monitor routines which operate at this highest commonly used level
may take nearly

2~~

microseconds to complete.

Some devices may require faster

service than this allows; hence, it is desirable to reserve API level
them.

for

The highest commonly used Monitor level would be defined to be API level

1, and devices on level

would only have to compete with one another.

They

could not, however, use common Monitor routines1due to the problem of reentrancy.
Such routines would best be I/O service routines rather than I/O device handlers.
The highest commonly used API level

or 1) is established during system gen-

eration and the value 4~~2~~ (for level ~) or 4~~10~ (for level 1) is placed
in .SCOM+102.
The instructions that must be executed to protect against
reentrancy are:
LAC*
ISA

(.SCOM+l~2

For devices which operate at the highest commonly used API level, a raise has
no effect.

Therefore, a check for this case must be made so that the corres-

ponding debreak (DBK) instruction is not executed.

Where a DBR (debreak and

restore) instruction would have been used, an RES (restore) should be executed
instead.

The PDP-9 does not have an RES instruction as does the PDP-lSi however,

there has never yet been a need for a user to replace a DBR with an RES.
As a side issue to reentrancy protection, the reader is cautioned not to share
subroutines within a handler at the CAL and interrupt levels unless CAL's and
interrupts cannot coincide.
7.5

DEVICE HANDLER'S CAL PROCESSOR

7.5.1

Arguments of the CAL

The first 37 (octal) words of an I/O handler must have the format described in
the following pages.

The CAL handler in the Monitor has been implemented to do

as much of the function processing as possible.

In giving control to the I/O

handler, the CAL handler will have set up registers in the I/O handler with all
pertinent information (arguments) of the CAL in the most accessible state, and
will then transfer control to the appropriate function processor via the JMP
table in the I/O handler which begins at word 208 relative to the first location
in the handler.

Since CAL is not a reentrant process, CAL instructions should

not be executed while at the CAL level or at a hardware interrupt level:
ISuch as, REALTP and IOBUSY.
2 As

a special case, the Monitor allows the MAGtape handler to do so.

7-8

WORD

JMS

SWAP

The SWAP subroutine is in the device handler.

The JMS instruction will be

simulated from within the Monitor so that the SWAP routine will return to the
Monitor and not to WORDI of the handler.

The SWAP subroutine must execute

WORDS which restores the state of the program interruptI and DBK from level ~
or 1 of the API.

The presence of this routine becomes functionally necessary

for type 3 (Multi-user) handlers to accomplish swapping from Background to
Foreground usage.

The I/O device independence of the system requires that all

handlers look alike to the outside world (namely, the Monitor's CAL handler).
WORD 1:

/Foreground Busy Register 2

WORD 2:

/Background Busy Register 2

For both busy registers:
~

= Not Busy

Non-~

= Busy

(the CAL handler in the Monitor places
the current .DAT slot number here
full 18 bit value if negative.)

When the Monitor's CAL handler receives an I/O call, it checks the validity of
the .DAT slot number for this job (Foreground or Background), checking for its
existence, whether or not a device has been assigned to it, and if the appropriate handler was loaded.
The CAL handler then checks the appropriate busy register 3 and proceeds as
follows:
1.

If the flag indicates that the handler is already busy, the job
becomes I/O bound at this level.

Foreground can become I/O

bound at 4 levels, which means it gives up control to lower levels
or to the Background until the I/O operation is completed.
2.

If the flag indicates not busy, it is set to busy' and the CAL
handler processes the function and passes the request on to the
device handler.

IThis is a vestige from PDP-~ code.
2 Must

be assembled with contents =~.

3 The

Teletype handler is an exception.

The Teletype handler is a special case.

4Actually, there is also a test on the CLOSE flag (Word 3 or 4) which is described on the next few pages. As a result, the function might not be passed
on to the handler.
7-9

Note that .WAIT's and .WAITR's are completely processed by the CAL handler and
1

are not passed on to the I/O handler .
If the corresponding busy register indicates busy:
1.

For .WAIT in the Foreground, control is given to a lower Foreground
level or to the Background.

The .WAIT command is not reexecutedj

instead, the WAIT condition is recorded for the specific Foreground
level in a .SCOM register.

When the I/O completes, the device

handler will call the IOBUSY routine in the Monitor, which will clear
the WAIT condition and prepare to resume processing at that level
following the .WAIT.
2.

For .WAIT in the Background, since there is no further processing

For .WAITR in either the Background or Foreground, control goes to

that can be done, control is returned to the .WAIT.
the address specified in LOC+2 (which must be above the hardware
memory protect bound if in the Background) 2.
If the corresponding busy register indicates not busy, the WAIT condition has
been satisfied and control is returned to LOC+2 (if .WAIT) or LOC+3 (if .WAITR).
WORD 3:

/Foreground .CLOSE register 3 •

WORD 4:

/Background .CLOSE register 3 •

For both .CLOSE registers:
~

= .CLOSE or .OPER not in progress

Non-~

= .CLOSE or .OPER in progress

.CLOSE and .OPER functions have a built-in WAIT condition.

When the .CLOSE or

.OPER is first executed, the busy register and .CLOSE register for the appropriate job contain zero.

The CAL handler in the Monitor sets the return PC so

that the function will be reexecuted.

The busy register is set with the .DAT

slot number and the .CLOSE register is set non-~ (-1).
At completion of the .CLOSE or .OPER function, the device handler must clear
only the appropriate busy register.

When the function is reexecuted with the

busy register cleared but the .CLOSE register set, the contents minus 1 of the
.CLOSE register are returned in the AC to the calling program following
the .CLOSE or .OPER command and the handler's .CLOSE flag is cleared by the
IThe Teletype handler is an exception.

The CAL handler validates Background arguments in Monitor calls. The test
based on the setting of the hardware memory protect bound uses the contents
of .SCOM+32, which is not set to zero by the $MPOFF command.
3Mus t

be assembled with contents

= S.
7-10

Monitor.

The handler is not entered a second time.

The contents minus 1 of the

.CLOSE register are returned in the AC specifically for .OPER functions
.RENAM, .DLETE).

(.FSTAT,

Device handlers that utilize this capability should set the

appropriate .CLOSE register (WORD 3 if Foreground; WORD 4 if Background) as
follows:
1

= File not present

INFORMATION +1 = File is present (where INFORMATION is the
device block number, which must not = -1)
Either ~ or INFORMATION is returned in the AC.
WORD 5:

ION

/The CAL handler will store an ION
/instruction here. This is vesti/gial code from the PDP-9.

WORD 6:

/The CAL handler will also store an
/ION here.

WORD 7: 1

/Return Pointer.
The CAL handler
/places the address of the Monitor's
/CALXIT routine in this register.

Words

through 17 are the BACKUP DATA REGISTERS.

The CAL handler sets up

these registers prior to entering the device handler.

For multi-user handlers,

a set of backup registers must be available to queue one Background I/O request when the handler is processing a Foreground request.

The handler's SWAP

routine is called to swap the contents of the backup registers with that of
the live registers (elsewhere in the handler).

For single user handlers, the

SWAP routine does not perform a swap since the backup registers are the live
registers.
WORD 10:

JMP FUNC

/After checking the validity of
/function and subfunction codes, the
/CAL handler places a JMP to the
/appropriate entry in the function
/JMP table (words 2~-32) of the I/O
/handler in this register.

WORD 11:

/The CAL handler sets this register
Ito indicate which job executed
/this CAL:
~
Foreground
/
1 = Background
/

WORD 12:

/.DAT slot number (IS-bits if
/negative). The CAL handler sets
/this register.

lIf it is guaranteed that the device cannot cause an interrupt while processing
is at the CAL level, then the handler's CAL and interrupt processors can use
common exit code as described in 7.6.
If so, the interrupt service routine
must store a DBR instruction in WORD6 and the interrupted PC (with Link,
Page/Bank Mode and Memory Protect bits) in WORD7.
7-11

WORD 13:

IUnit number for multi-unit devices
lin bits ~-2 with bits 3-17 containling the address of the CAL. The CAL
Ihandler sets this register.

The CAL handler makes a general check for validity on:
a.

File type

Data Mode

MAGtape subfunction code

Transfer directions

.OPER subfunction code

Addresses
Word counts

and will pass on what appears to be legitimate values.

Each handler must then

make its own validity determination with respect to the device it controls.
example,

the CAL handler will always accept data modes

For

through 7; however,

the device handler may only accept a subset of these.
The contents of words WORD 14 through WORD 17 vary with the function being
processed.

Adjacent to what will appear in each of these words are the limits

on the values that will be-accepted and passed on by the CAL handler.
WORD 14:

.INIT

File type

1
. READ

lOPS binary
Image binary
lOPS ASCII
2
Image ALPHA
3
4
DUMP
DUMP ALPHA
5
6 and 7 are undefined but are
passed on by the CAL handler.

Data mode

.REALR
.WRITE
· REALW

WORD 15:

input
output

.MTAPE

MAGtape function

~ thru 17 8

.TRAN

Transfer direction

.OPER

Sub function code

1 thru 3

.INIT 2

User restart address plus code bits

• READ 1
.REALR 1

Line buffer address

thru 3

- 2)

.WRITEI
· REALWI
lChecked for non-existent memory.
If this is a Background CAL and if the Background is operating in normal protect mode ($MPON) this address is also compared
with the contents of . SCOM+31 , the software boundary, to signal an error if the
address points below the bound.
2Same as for footnote 1, except that the check is made on .SCOM+32, the hardware
bound, and only if the function is to be executed by the Teletype handler.
7-12

• FSTAT I
.DLETE I

Address of the Directory entry block

.RENAM I
.ENTER 2
.SEEK 2
Core starting address.

. TRANI

Address of register which is to have standard
buffer size placed in it .

WORD 16:
• READ 3

Linebuffer word count (from the CAL argument list) .

. REALR 3
• TRAN 3
.WRITE3
.REALW 3

WORD 17:

. FSTAT I
• REALR"
.REALW

Line buffer word count (from the linebuffer word
pair count, except for dump mode and mode 5 which
use counts from the CAL argument list .

Address of the register which will have the device
code placed in bits ~ - 2 .
Address to which control will be passed on completion
of the real-time I/O request. Bits 0 - 2 will contain
the priority code:
~
Background Mainstream
1
Foreground Mainstream
5
Foreground API Level 5
6
Foreground API Level 6
7
Foreground API Level 7
The CAL handler always changes the Background code to
since Background cannot use the API software levels.

• TRAN

The device address (block number) •

Words 20 through 32 make up the Function JMP Table.

Those functions which are

ignored, those which are illegal, and those which do not issue rOT's at the CAL
level must prepare to have the Foreground or Background busy flag (WORD 1 and
WORD 2, respectively) cleared during the protected exit routine.

Because the CAL

handler in the Monitor has set the busy flag prior to entering the handler, the
handler must clear the busy register since no further processing will be done.

IChecked for non-existent memory.
If this is a Background CAL and if the Background is operating in normal protect mode ($MPON) this address is also compared
with the contents of .SCOM+31, the software boundary, to signal an error if
the address points below the bound.
2

No address check is made.

3Counts are validated for the Background job to ensure a negative value and
to ensure that the count added to the start address does not reference nonexistent memory.
"Same as for footnote 1, except that the check is made on .SCOM+32, the hardware
bound.

7-13

JMP INIT
JMP OPER
JMP SEEK
JMP ENTER
JMP CLEAR
JMP CLOSE
JMP MTAPE
JMP READl
JMP WRITE 2
XX 3
JMP TRAN

/Function 1
/Function 2
/Function 3
/Function 4
/Function 5
/Function 6
/Function 7
/Function l~
/Function 11
/Function 12
/Function 13

WORD 33:

/Storage for .SCOM+35, the "in an
/interrupt service" fl g -- set by
/the CAL handler. Thi is a vestige
/from the PDP-9.

WORD 34:

SUBRF

/Address of the
/subroutine.

WORD
WORD
WORD
WORD
WORD
WORD
WORD
WORD
WORD
WORD
WORD

2~:

21:
22:
23:
24:
25:
26:
27:
30:
31:
32:

STOP-F~REGROUND-I/O

When the Foreground job terminates as a result of a terminal

e~ror,

CTRL C, or

a .EXIT command, the Foreground STOPIO routine in every device handler
assigned to the Foreground job is called~ at the Mainstream level to effect
the controlled shutdown of the device (see 7.8).
WORD 35:

/Address of the STOP-BACKGROUND-I/O
/subroutine.

SUBRF

For single user device handlers (devices that cannot be shared by Foreground
and Background), the same subroutine can be used for Foreground and Background
STOPIO (as noted above).
WORD 36:

/Handler I.D. code (normally

~).

This word has other values

(non-~)

tion from the CAL handler.

The Monitor will not allow .INIT to force its way

for devices that require special considera-

into a busy handler unless the I.D. code is -1 and the .INIT is to the same .DAT
slot on which the handler is busy.
7. 5 . 2

. SETUP

If a device generates hardware interrupts they must be routed to the proper
interrupt service routines.

When the appropriate handler is not in core, the

interrupts are routed to an error processor which treats the interrupts as
illegal.
lIncludes .REALR.
2Includes .REALW.
3.WAIT and .WAITR never get to the handler: they are processed by the Monitor's
CAL handler. Word 31 can be used for data storage.
~The call is made only if the handler's Foreground busy register is set.

7-14

When a handler has been loaded in core it must call the Monitor's .SETUP routine
at the CAL level, API level 4)

to connect the interrupt line(s) to the handler's

interrupt service routine(s).

As a rule, this is executed as once-only code the

first time a .INIT call is processed.

To ensure that .SETUP has been done for a

device which has lOT's that can cause interrupts, all CAL functions that could
perform such lOT's must test that a .INIT was performed at least once.

If .INIT

was not performed, the offending job should be terminated with an .ERR ~6~ (.INIT
not executed).
The .SETUP routine is typically called only once for API devices; but, for devices on the Program Interrupt Control, one call per lOT in the Monitor's skip
chain is required.

Read section 8.3.4, Note 3, for a clearer explanation.

Calling sequence:
LAC *

(.SCOM+55
DAC
TEMP
JMS*
TEMP
SKPIOT
INTSVC
(return here)
7.5.3

/Get address of .SETUP
/Call .SETUP
/Argument 1: lOT skip
/Argument 2: Address of the
/interrupt service subroutine

Initiating I/O

For interrupt driven devices it is imperative that all lOT's that initiate
hardware operations be executed during the protected exit from the handler
to ensure that the exit takes place prior to the completion of the hardware
operation (which could cause re-entry to the handler at the interrupt level).
CAL function requests that require more than one hardware operation should
cause the 2nd through Nth operations to be initiated at the
during protected exit.

inter~upt

level

A handler should not cause an implicit .WAIT for the

duration of the function processing because this prevents optimum usage of the
central processor time.

The .CLOSE and .OPER functions are exceptions and the

implied .WAIT in those functions is handled automatically by the CAL handler.
7.6

DEVICE HANDLER'S INTERRUPT PROCESSOR

The following steps detail the logic necessary for interrupt processing in a
single-user handler.

References to a common exit routine for both CAL's and

interrupts presupposes that interrupts for the device cannot occur while CAL's
are being processed.
Both page mode and bank mode systems now require API hardware, consequently the
interrupt

serv~e

routine can rely on its existence.

7-15

If this ic

API interrupt, the PC, Link (bit ~), Page/Bank (bit 1),

and Memory Protect (bit 2) are stored at the entry point to this routine.
If this is a PIC interrupt, the PC et ale are stored in location zero
in memory.

This routine is entered at the API level of the device

(level 3 with PIC off if a PIC interrupt), with memory protect disabled.
2.

DBA -- Disable Bank (Enter Page) Address Mode.

Save the AC -- to be restored on exit from interrupt service.

Also,

save hardware registers such as XR, LR, if they are to be used herein.
4.

Save the PC, Link, Page/Bank Mode, and Memory Protect in WORD 7 of the
handler.

WORD 7 is so used if the CAL and interrupt code can use common

exit logic.
5.

Store a DBR instruction in WORD 6 of the handler.

This is done only

if the CAL and interrupt code can use common exit logic.
6.

Turn off

(~lear)

the device's hardware flag so that it will not cause

another interrupt unless reset.
7.

If this is a PIC interrupt, set location zero to zero and execute the
ION instruction to turn the Program Interrupt Control on.

Location

zero with non-zero contents indicates a PIC interrupt in progress
was significant in PDP-9 logic.

(this

On a PDP-9, the device flag(s) must

be cleared before the PIC is turned on again.)
8.

If this is the type of device for which I/O in progress cannot be
stopped, test if this is the last interrupt expected from the device. 1
If it is, clear (set to zero) the IOSTOP flag (read section 7.8
describing STOPIO procedures).

Only one lOS TOP flag is needed for

a single user or sequential multi-user handler.
9.

Is the busy flag (WORD 1 if Foreground; WORD 2 if Background) zero?
If it is (meaning that the handler was not busy and that the
interrupt was unsolicited, or that the STOPIO routine was called),
ignore the interrupt by going to step 13.

l~.

Process the interrupt, e.g., store data or prepare to transmit more
data.

11.

Is the I/O request (the I/O call issued by the user program) complete
as a result of this last interrupt?

If so, continue at step 14.

IThe CR~3B card reader handler must test if this is last interrupt since, for
one read operation, 8~ column interrupts will occur and there is no way to
prevent them.
7-16

12.

If more I/O must be done before the CAL request is satisfied, set up
the protected exit routine to issue the next IOT(s) to the device. Go
to step 22, the protected exit routine.

13.

If the interrupt was unsolicited, set up to have the Foreground or
Background busy flag (WORD 1 or 2 as appropriate) cleared during the
protected exit code.

Go to step 22, the protected exit routine.

Note

that WORD 11 in the handler indicates Background or Foreground ownership of the I/O request.
14.

I/O is complete as a result of this interrupti therefore, set up to
have the

Fo~eground

or Background busy flag (WORD 1 or 2 as appropriate)

cleared during the protected exit code.

Note that WORD 11 in the

handler indicates Background or Foreground ownership of the I/O request.
15.

LAC *
ISA

(. SCOM+l~2

This will raise to API level zero or one, depending upon the contents
of

.SCOM+l~2.

If this device interrupts at level one or zero, reread

section 7.4.
16.

LAC *
DAC
LAC
JMS*

(. SCOM+52
TEMP
(WORD ~
TEMP

.SCOM+s2 contains the address of the Monitor's IOBUSY subroutine,
which must be protected against reentrancy.

It is passed an argument

in the AC -- the address of WORD ~ of the device handler.

IOBUSY will

compare this with the contents of the Foreground busy registers
(.SCOM+42 through .SCOM+4s).

If a match is found, it indicates that

the Foreground level was waiting for I/O completion by this device.
Since I/O has completed, the Foreground level is made not busy and
is set up to resume operation when that level becomes the highest
active level in the system.

The level-busy .SCOM registers are set

originally by the Monitor's CAL handler.

Note that the call to IOBUSY

must be done for Background as well as Foreground I/O completion.
17.

DBK
Debreak from API level zero or one (reread section 7.4 if this device
interrupts at level zero or one).

This is done, as is step 19, simply

to allow interrupts to occur for higher level devices if their flags
come up while the IOBUSY code is being executed.
18.

The handler must check if this is a real-time I/O request.
WORD

It is if

contains a JMP to WORD 27 (.READ or .REALR) or to WORD
7-17

(.WRITE or .REALW) and WORD 17 is non-zero.

If this is not a real-time

request, go to step 22.
19.

LAC *
ISA

( . SCOM+l,,2

Raise to API level zero or one to protect the following Monitor
If this device operates at level ~ne

routine from being reentered.
or zero, reread section 7.4.

2fJ.

LAC *
DAC
LAC
JMS*

(. SCOM+51
TEMP
WORD 17
TEMP

.SCOM+51 contains the address of the Monitor's REALTP subroutine.

is passed an argument in the AC -- the contents of WORD 17 which is
the priority level code plus real-time subroutine address.

REALTP

will prime the Monitor to run the real-time subroutine.
21.

DBK
From API level zero or one, as in"step 17.

22.

This is the beginning of the protected exit routine.

Note that it

is coded as a common exit for both interrupt and CAL code.
explained in section 7.3.2.

This is

If I/O is to be performed now to the

device, check the device to ensure that it is ready to accept I/O
commands.

If the device is not ready, a message must be output to

denote this fact (see section 7.9) and the I/O must be deferred.
Therefore, set a program flag, call it IOTFLG,for example, so that
the IOT(s) will not be issued in step 27.

If the device is ready,

clear IOTFLG.
23.

LAC *
ISA
Raise to API level zero or one.

Reread section 7.4 for level zero

or level one devices.
24.

If WORD 6 contains a DBR instruction (recall step 6), this is an
interrupt service exit.

If so, request an API level 4 interrupt as

follows:
LAC
ISA
The API level 4 handler is the Monitor's dispatch routine.

It con-

trols transitions from Background to Foreground, real-time requests,
errors, and control character functions.

7-18

25.

If previously set up to do so, as in steps 13 and 14, clear the
Background and/or Foreground busy flags (WORDS 2 and 1, respectively).
The busy flag is cleared on ignored functions, completed functions,
and aborted functions.

26.

Is I/O supposed to be done now? If IOTFLG (set or cleared in step 22)
is non-zero, if the appropriate busy flag is zero, or if the IOSTQP
flag is non-zero (see step 8) go to step 28 to Qypass execution of
the IOT(s).

27.

Execute the IOT(s) to the device. This may involve several instructions. If this is an exit from the CAL level of the handler and if
no I/O is to be done (e.g., an ignored function), this code will be
bypassed since the busy flag was cleared.

28.

Restore the AC plus any other hardware registers used (refer to
step 3).

29.

DBK
Debreak from API level zero or one (reread section 7.4 if this is a
level zero or level one device).

3~.

XCT WORD 6
This will be a DBR instruction if this is an interrupt exit (recall
step 6) and ION if this is a CAL exit. This assumes that the device
handler can have common interrupt and CAL exit code.

31.

JMP* WORD 7
Again, this assumes common CAL and interrupt exit code.

The DBR in
step 3~ for an interrupt exit will debreak out of the device's hardware level and will prime the machine to restore the state of the Link,
Page/Bank Mode, and Memory Protect (in this case from bits ~ - 2 of
WORD 7). The ION instruction in step 3~ for a CAL exit is effectively
a NOP. Return will be at API level 4 to CALXIT, the common CAL exit
routine in the Monitor.
Note that once the DBK in step 29 is executed, the sequence of code leading to
step 31, the JMP*, must be non-interruptible, i.e., a string of lOT instructions.
If the exit is done with the device not ready, note that the device's busy
flags are still set. The job will continue execution without knowledge of the
not-ready situation. Of course, if the job attempts to perform more I/O to
the device
I/O bound.

(.INIT being a special case: see section 7.9.2), it will become
7-19

7.7

ERROR PROCESSING

All device handler error conditions should be terminal; that is, they should
terminate the operation of user programs.

Whether errors are detected during

CAL processing or during interrupt processing the following coding sequence
will set up an error condition and cause an error message to be printed on the
appropriate job control Teletype.

This coding sequence cannot be common to

both the CAL and interrupt levels unless it is known that the device cannot
cause interrupts while the handler is processing a CAL.

(.SCOM+66
TEMP

LAC *
DAC

/This TEMP cannot be common.
/(See preceding paragraph.)

.SCOM+66 contains the address of the error queuer subroutine in the
Monitor.
2.

LAC *
ISA

(.SCOM+l~2

Raise to API level zero or one to protect the error queuer from being
reentered.
3.

Reread section 7.4 for level zero and level one devices.

LAW code or LAC (code
JMS* TEMP
auxarg
Go to the error queuer with one argument in the AC and one following
the JMS instruction.

The argument in the AC, loaded either by LAW

code or LAC (code, is formatted as follows:
Bits ~ - 5 are ignored
Bit 6

1 means a terminal error

Bit 7

1 means a Background error

Bit 8

1 means a Foreground error

Bits 9 - 17 form a 3-digit error code
If the error pertains to both jobs then both bits 7 and 8 may be set.
The auxiliary argument, auxarg, is simply a 6-digit quantity to be
printed with the error message, which is of the form:
.ERR NNN XXXXXX)
NNN is a 3-digit error code

XXXXXX is a 6-digit auxiliary argument

7-20

DBK
Debreak from API level zero or one.

Reread section 7.4 if this is a

level zero or level one device.
5.

If no further interrupts are expected, set up to have the appropriate
job busy flag (WORD 1 or WORD 2) cleared during protected exit from
the handler.

However, if more interrupts are expected, the busy flag

must remain set to signal the STOPIO routine that interrupts are
pending.

Instead, set the IOSTOP flag so that I/O set up to be

executed in the protected exit routine will be bypassed.

The actual printing of the error message will not be done until all interrupt
and CAL processing is complete.

Background error messages are not printed until

the Background job is given control.
As a result of a terminal error, the handler can be certain that its STOPIO
routine will be called by the Monitor if the handler's busy flag is set for the
job in error.
7.8

STOP I/O ROUTINES

In Background/Foreground it is necessary to have some orderly means of stopping
I/O that is in progress.

When a job terminates (.EXIT, terminal error, etc.),

the Monitor must ensure that all I/O for that job is shut down.

This is

particularly necessary in the Background where I/O must be stopped before the
associated device handlers are removed from core.
WORD 34 of each handler must contain the address of its Foreground STOPIO subroutine.
WORD 35 of each handler must contain the address of its Background STOPIO subroutine, which for single-user handlers can be the same as the Foreground STOPIO
routine.
Whenever a job terminates execution, the Monitor calls the appropriate STOPIO
subroutine at the Mainstream level.
1.

The following steps should be followed:

Is this the type of device for which I/O can be terminated by
issuing an rOT instruction?

Terminating I/O means ensuring that no

further interrupts will occur.

If so, do so, and continue at step 6.

7-21

(. SCOM+l0'2
ISA
Raise to API level zero or one to protect against getting interrupted
in mid-decision.

LAC*

If this device does not generate Not-Ready conditions (read section
7.9), go to step 5.

Check the "CTRL R in progress" flag (see CTRLR in section 7.9). If it
is set, clear the STOPIO flag (which is tested in step 11) and go to
step 6. This is done because I/O cannot be under way if the handler
is waiting for tR.

Otherwise, go to step 5.

Check the appropriate job busy flag (WORD 1 or WORD 2). If it is set,
set the IOSTOP flag (a flag internal to the handler) non-zero. Otherwise, clear it. This flag is tested in step 11.

Clear the appropriate job busy register (WORD 1 or WORD 2).

Clear the appropriate .CLOSE register (WORD 3 or WORD 4).

If the handler has one, clear the "CTRL R in progress" flag (see
step 18 in section 7.9).

If this is the type of device which can terminate I/O by lOT (refer
back to step 1), go to step 12.

lfJ.

DBK
Debreak from API level zero or one back to Mainstream to allow hardware flags that may have or will occur to be serviced.

11.

LAC
SZA
JMP

IOSTOP
.-2

If the appropriate busy register had been set and I/O is under way,
control will stay here until the IOSTOP flag is set to zero. That
will happen only when the device's final interrupt occurs (refer to
section 7.6, step 8). This loop is executed at Mainstream, in case
the handler is being used by Background, so that the Foreground job
may resume execution when ready.
12.

STOPIO
Exit back to the Monitor.
JMP*

I/O by the device has stopped and, if the

job is restarted, the handler flags have been reset so that the
handler can accept more I/O commands.
7-22

7.9

RECOVERY FROM I/O DEVICE NOT READY CONDITION

7.9.1

CTRL R

Mechanism

The Background/Foreground Monitor system is designed to handle simultaneously
one not-ready condition per job.

This is a limitation but a reasonable one

based on Keyboard Monitor (single user) experience.
I/O handlers that can encounter and detect not-ready conditions must adhere to
the following ground rules in their announcement of the not-ready condition and
in their continuation once the condition has been corrected.
Some devices are designed so that they can be tested at any time for a state of
readiness; therefore, the test can be made at the CAL level prior to starting
I/O.

Other devices will not generate a not-ready condition until after an lOT

has been issued and an error flag results.

In such cases, the not-ready condi-

tion is detected at the interrupt level.
The reader is assumed to understand the mechanism whereby a device interrupt
transfers control to a handler's interrupt service routine at a hardware API
level and the process called .SETUP whereby the handler connects itself to the
device's interrupt line(s).

When the handler is not in memory, interrupts from

the device are shunted to the illegal interrupt handler.

When the handler is in

core and has performed the • SETUP , device interrupts will transfer control to
the handler.

The processing of a device-not-ready condition involves a pseudo-

.SETUP and a simulated API interrupt, which will be explained at the end of this
section.
It is best to check for device ready in only one location, the beginning of the
protected exit routine in the handler.

This starts at step 22 in section 7.6,

where it is assumed that the CAL and interrupt portions of the handler share a
common exit logic.
1.

Test for device ready or not.
7.6.

This is the same as step 22 in section

If the device is ready, set IOTFLG to zero so that the IOT(s) in

step 27 may be executed, and go to step 23 in section 7.6.
2.

With the device not ready, it is necessary to defer the IOT(s), announce
the not-ready condition, and exit from the handler set up to continue
after CTRL R is typed on the user's control Teletype.

For a single-user

or sequential multi-user handler, the IOT(s) that were to be executed
may remain where they are.

Set IOTFLG non-zero so that they will not

be executed in step 27 of the protected exit logic (section 7.6).

(For

multi-user handlers, the IOT(s) must be physically moved in case I/O
7-23

for the other job is started up.)
3.

JMS

NRMSG

Call a subroutine to initiate the printing of the not-ready message.
Then go to step 23 in the protected exit routine (section 7.6).
Steps 4 through 11 contain the code for subroutine NRMSG.

NRMSG

/Entry point.
LAC
CTRLR
SZA!CLC
JMP* NRMSG
DAC
CTRLR
Register CTRLR is a program flag internal to the handler. If it
contains zero, the handler has not already initiated a not-ready
request. If it is non-zero, exit from the subroutine, since a notready condition has been announced. If CTRLR was zero, set it non-zero.

WORD 11
LAC
ARGI
DAC
WORD 11 in the handler contains zero if Foreground and one if Background. This is passed on as argument one in the call to the Monitor's
CTRL R setup routine.

LAC
UNITNO
DAC
ARG3
Bits ~-2 of argument three are considered to be the device unit number,
which is printed as part of the device-not-ready message. Some devices
have only one unit, for example, the papertape punch; and this code is,
therefore, unnecessary. The card reader handler uses the unit number in
the printout to indicate the cause of the not-ready condition.

LAC *
DAC

(. SCOM+64
TEMP

/Beware -- TEMP probably cannot be used
/by both the CAL and interrupt levels .
• SCOM+64 contains the address of the CTRL R setup subroutine, which
is part of the Teletype handler in the Monitor. Store this address in
a temporary register.

LAC *
(. SCOM+l~2
ISA
Raise to API level zero or one. Reread section 7.4 if this device is
already operating at level one or zero.

7-24

JMS*

9.
ARGI
ARG2

TEMP

XX
.ASCII /DV/
. LaC
.-1
XX

ARG3
ARG4
ARG5

F.CTLR+?~~~~~
B.CTLR+?~~~~~

Call the CTRL R subroutine in the Monitor.

Argument 1 contains

zero if Foreground and one if Background.

Argument 2 is the two-

letter device name in .ASCII, e.g., LP for Line Printer.
3 is the device's unit number, in bits

~-2.

Argument

Argument 4 is the

address (F.CTLR) and API level code (?~~~~~) of the subroutine which
is to be entered when a Foreground not-ready condition for this
device exists and CTRL R is typed on the Foreground control Teletype.
Argument 5 is similar to argument 4, but is used for Background.
(?~~~~~)
~,

for API level 2 would be
1, 2, or 3 are allowed.

2~~~~~,

for example.

Only levels

For device DV with unit number ~, the not-ready message would be
printed as follows:
DV~ NOT READY)

Return from the CTRL R subroutine will either be normal (step

l~)

skip one location (to step 11).
l~.

DZM

CTRLR

If the Monitor's CTRL R subroutine does not skip on return (returns
here), it is because the request to set up a not-ready condition was
not honored.

This would happen if, for this job, a not-ready condi-

tion had been established for some other device.

No queueing

mechanism exists; thus, two simultaneous not-ready conditions for a
job will result in a job terminal error, .ERR ~~4.
to step
quest.
11.

DBK
JMP*

l~,

When return is

the Monitor has already posted the .ERR ~~4 printout re-

NRMSG

If the Monitor has honored the request to set up a device-not-ready
condition, step l~ will have been bypassed.
zero or one.

Debreak from API level

Reread section 7.4 if this device operates at level

zero or one.
Steps 12 through 18 contain the code for subroutine F.CTLR and B.CTLR.
7-25

12.

F.CTLR
~
B.CTLR=F.CTLR

/Entry point

For a single-user handler, the same subroutine can be used for Foreground and Background, as indicated by the equivalence statement.
Prior to entering this routine, the Monitor was called by the handler
to set up a not-ready condition for this device.

A not-ready message

was printed on the appropriate job control Teletype and the CTRL R
function for that job was primed by storing ARG4 or ARG5, as appropriate,
(see step 9), in the Monitor's Foreground CTRL R or Background CTRL R
register.
Note that this has the effect of a pseudo-.SETUP call.

If CTRL R is

now typed on the appropriate job control Teletype (the user's way of
posting a "done" flag), the corresponding CTRL R register in the Monitor acts like an API channel register.
The Teletype handler raises
to the designated API priority level and then performs a JMS to this
subroutine.

The subroutine must be entered at API level zero, one,

two, or three.

Prior to entering this subroutine, the Teletype handler

will clear the relevant Monitor CTRL R register to disable CTRL R
until another not-ready condition is established.
13.

DZM

CTRLR

Clear the handler's not-ready-condition-in-progress flag.
14.

Test for device ready or not.

15.

JMS

If ready, go to step 16.

NRMSG

The device still isn't ready.

Reestablish the not-ready condition

and then exit by going to step 17.
16.

Execute the IOT(s) that were deferred for this device, i.e., start
I/O up again.

17.

DBR
JMP*

F.CTLR

Debreak and return to the Teletype handler.

Note that the AC need

not be restored.
18.

CTRLR

The "CTRL R in progress" flag must initially be cleared.

It must

also be cleared in the STOPIO subroutine and in the .INIT code. For a
single-user handler, only one CTRLR register is needed.

7-26

7.9.2

.INIT Consideration

WORD 36 of the I/O handler is an identification code which is zero for most
handlers.

Only if the code is -1 (777777)1 will the Monitor allow .INIT to be

processed by a busy handler.
In the latter case, the handler must test its CTRLR flag (and then clear it) to
see if a not-ready condition existed for the device.

If so, the handler must

also clear the appropriate CTRL R register in the Monitor as follows:

OVER

UC
SNA

CTRLR

OVER
(.SCOM+67
WORDll
TEMP

LAC
TAD
DAC
UC*
TAD
DAC
DZM*
DZM

TE~

/~ = FGD; 1 = BGD.
/.SCOM+67 = FGD; .SCOM+7~
BGD.
/Address of FGD or BGD CTRL char. table.

TE~

TEMP
CTRLR

/~
/~

Monitor's B or F CTRL R.
Handler's own CTRL R.

Note that .SCOM+67 points to the Foreground control character table in the Teletype handler and that .SCOM+7~ points to the Background control character table.
WORD 11 in the handler contains zero if Foreground and one if Background. The
CTRL R register for each job is the fifth entry in each of these tables.
7.10

THE .INIT FUNCTION

In order to satisfy the requirements of the disk and DECtape handlers, the FlOPS
routine in the FORTRAN Object Time System operates somewhat differently in
Background/Foreground from the way it does in the Keyboard Monitor.

In Background/

Foreground, FlOPS will perform a .INIT to a given .DAT slot only the first time
the slot is referenced, not each time the direction of data transfer changes.
The .INIT-only-once change is necessary because DTA. and DKA. can perform nonfile-oriented I/C,

that is, treat the DECtape or Disk as if it were MAGtape •

. INIT always resets the device to file-oriented mode and is, therefore, avoided.
This change has ramifications for user-written device handlers, even if they are
strictly file-oriented handlers.

.INIT can no longer be relied upon to signal

a change in the direction of data transfer.

However, if .CLOSE is followed by

.SEEK, .ENTER, . FSTAT, .DLETE, .RENAM, • CLEAR, or REWIND (.MTAPE
fer direction is obvious anyway.

~),

the trans-

Therefore, .INIT need only be used to tie the

IThis is a necessary but not sufficient condition.
7-27

handler to its interrupt lines (.SETUP) and to abort I/O (after CTRL P, for
example) •
7.11

SEQUENTIAL MULTI-USER DEVICE HANDLER

7.11.1

Transition from Single-user Handler

To accomplish the transition from a single-user device handler to a sequential
multi-user device handler, the following procedures must be adhered to:
1.

The device handler must be the "A" version; that is, LPA., MTA., etc.,
as the Background/Foreground Monitor System will only allow "A" versions
to be connected to both jobs simultaneously. Also, this shareability
must be specified to the B/F System Generator.

The SWAP subroutine (pointed to by WORD~ of the handler) ~ set
both busy registers (WORDI and WORD2) to prevent the Foreground job
from forcing itself in before the Background job has completed its
operation. This is in addition to and prior to its normal duties as
outlined in 7.5.1.

The handler's identification code, WORD36, should not be -1. If it
were, it would be possible for one job to abort the I/O operation of
the other.

There must be two unique STOP I/O subroutines, one for Foreground
(pointed to by WORD34) and one for Background (pointed to by WORD35).
Before executing the STOP I/O procedures, both subroutines must first
determine if the I/O belongs to their respective jobs. This is done
by testing WORDll, (~=Foreground I/O, l=Background I/O). They should
do nothing if the other job is in control.
In step 8 of the STOPIO routine, section 7.8, check the CTRLR flag
before clearing it. If the flag was set, call the I/O BUSY routine
in the Monitor (as in steps 15, 16, 17 of section 7.6) in case some
level of the Foreground iob is I/O bound on this device.

Because the SWAP subroutine sets both busy registers (WORDI and WORD2),
the CLEAR BUSY FLAG routine that sets up to have the flags cleared
during protected exit from the device handler (refer to steps 13 and
14 in section 7.6) must always setup to have both flags cleared.
The STOP I/O subroutines should also clear both busy registers.

7-28

7.11.2

Peculiarities

It is understood that in multi-user handlers, such as DTA., the Foreground has
a built-in priority.

Therefore, it comes as no surprise that the Foreground job

can completely prevent the Background from performing DECtape I/O.

For

sequential multi-user handlers, one might assume that Foreground and Background
I/O operations would compete on an equal basis.

This may not be the case.

It is possible, given the right set of circumstances, that Foreground never gets
a chance to manipulate the device, that Background never gets a chance to manipulate the device, or that one program (not necessarily Foreground) does more
actual I/O to the device than an identical program running as the other job.
This situation should only become a problem when one or both jobs attempt continuous operation of the device.

The "right set of circumstances" depends upon

where processing is in the Monitor's CAL handler when the current I/O operation
for the device completes (interrupts).
7.11.3

Use of the .WAITR Function

When a sequential multi-user device handler is being used by the Background job,
the Foreground job will become I/O bound if it attempts to use the same handler.
The .WAITR monitor function affords both the Foreground job and the Background
job a means of determining that the handler is available before requesting I/O
from and to it.

This feature is only useful when the job has other things which

can be performed while it is waiting for the handler to free up.
The use of .WAITR in this manner is foolproof when executed in the Foreground.
This is not so in the Background because the Foreground job can regain control
after the Background .WAITR has been executed and before the ensuing Background
I/O command.
7.12

EXTERNAL I/O BUFFERS

Device handlers which might require a great deal of buffer space may do well
to use the system's capability of setting aside I/O buffers at load time.

Only

multi-user or sequential multi-user handlers (the shareable "A" versions) may
utilize external buffers.
Buffer sizes required by each shareable handler are specified during system
generation.

Buffers are set aside at load time by the Loaders either as a result

of a $FILES Keyboard command or, in lieu thereof, one per .OAT slot which
references the multi-user device handler.
7-29

Typically, the handler would test to see if it had a buffer for a given .OAT
slot before performing the I/O request.

If not, it would call the GETBUF routine

in the Monitor to scan the buffer table, .BFTAB, for a usable free buffer.

the end of the I/O sequence, usually .CLOSE, the handler must relinquish the
buffer so that other handlers might use it.
7.12.1

Calling for a Buffer

At run time, the handler may obtain an external I/O buffer as follows:

LAC *
OAC

(.SCOM+56
TEMP

/Beware -- TEMP probably cannot be
fused by both the CAL and interrupt
/levels.

The address of the GETBUF subroutine in the Resident Monitor is in
.SCOM+56.
2.

LAC *
ISA

(.SCOM+l~2

Raise to API level zero or one.

Reread section 7.4 if the handler

is already at level zero or one.
3.

JMS*
TEMP
argument
Call GETBUF with one argument:
Bit ~ = ~ if Foreground
Bit ~ = 1 if Background
Bits 1-5 = ~
Bits 6-17 = Buffer size.
GETBUF will search .BFTAB for a free Foreground or Background buffer,
as specified, of a size equal to (or greater than, if necessary)
that indicated in the argument.

If a buffer is found, the address of the first word of the .BFTAB
entry is returned in the AC and the entry is flagged busy by the
GETBUF routine.
If no buffer can be found, zero is returned in the
AC and GETBUF initiates a terminal error (.ERR ~55) for the
job.

OBK
Oebreak -- Reread section 7.4 if this is an API level one or zero
device.

7-30

7.12.2

Releasing a Buffer

The format of .BFTAB is given in Appendix IV.

When the handler wishes to

relinquish a buffer, it does so by clearing the busy bit of the entry in .BFTAB.
Note that the address of the first word of this entry in .BFTAB is returned in
the AC by the Monitor subroutine GETBUF.
7.13

PDP-9/PDP-IS COMPATIBILITY

7.13.1

Page Mode

The I/O handler description in this manual was written for page-mode operation,
which is vilid only on the PDP-IS.
Two coding requirements which are necessary for PDP-9 hardware may be omitted
for handlers that are to run in page-mode-only systems:

(1) raising to API

level 3 and (2) double XCT .+1 following DBR (see 7.13.2).

For page mode opera-

tion on a PDP-IS, add a DBA (Disable Bank Addressing = Enter Page Mode) instruction as the first instruction in the handler's interrupt service routine.
7.13.2

Bank Mode

Since handlers that operate in the bank mode system must be able to run on both
a PDP-9 and a PDP-IS (assuming that the device exists on both machines), the
following PDP-9 requirements must be followed:
1.

Do not insert a DBA instruction at the beginning of the interrupt
service routine.

If a device on the PDP-9 is connected to the PIC (Program Interrupt
Control) but not to API, then the interrupt service routine must raise
to API level 3 before executing the ION instruction. On the PDP-IS,
this raise to level 3 is done automatically by the hardware.
Formerly,
when API hardware was optional on PDP-9 Background/Foreground, an "in
interrupt service routine" flag (.SCOM 3S) was needed to signal that
state ~fter the ION instruction was executed.

To allow API synchronization following a DBR instruction on a PDP-9,
the following exit sequence must be used:
DBR
XCT .+1
XCT .+1
JMP*

7.14

DEVICE HANDLER LISTING

The following pages contain the assembly listing of a paper tape reader handler
(PRA.) for PDP-IS Background/Foreground operation.

7-31

PAGE
1
2
3
4
5

6
7

8
9

-..I

12
13
14
15
16
17
18

19
2(21
21
22
23
24
25
26
27
28
29

P~A.

(21(218

-- PRA,
.TITLE -- PRA.
/COPYRIGHT 197(21, DIGITAL EQUIPMENT CORPORATION. MAYNARD,
/PAPER TAPE READER I/O DEVICE HANDLER rOR THE
/PDP-15 BACKGROUND/FOREGROUND MONITOR SYST£M.
/THIS IS NOT T~E VERSION or PRA. SUPPLIED WITH
/THE BAC~GOUND/FoREGROUNO SYSTEMS, IT IS AOAPTED
/(8y C, PROTEAU) fROM PRA. (WRITTEN BY O. LENEY
lAND M, SIFNAS) TO CONFORM TO THE DESCRIPTION
10F A DEVICE HANnLER IN SECTION 7 OF THE POP-15/30
lAND PDP-15/40 MONITOR MANUAL. THE MAJOR OlrFERENCE
IBETWEEN THESE TwO VERSIONS IS T~AT THIS ONE IS
/NOT PARTICULARLV AMENABLE TO CONVERSION rOR
/OPERATION IN PDP·9 BACKGROUND/fOREGROUND,
/CHARACTERISTICS'
/
I

2. NON-fiLE-ORIENTED (A TERM SOMETIMES

/
I
I

/
/

~INGLE-USER

(NONpSHAREABLE) HANOLER

TAKEN TO MEAN NONwRANOOM-ACCESS)
3. HANDLrs DATA ~oOES " THROUGH.
4, CAN USE CODE AND REGISTERS IN COMMON
BY CAL AND INTERRUPT SERVICE
5, OPERATES ENTIRELY IN PAGE ADDRESSING MODE
.EJECT

MASS~

PAGE

-..J
I

w
w

30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

f'" A •

008

PRA.

700101 A
70::'112 A

RRR=7fi"!1112

RSA=7rl10H/4

700144 A

RSB=700144

0001<J0 A

.SCO~=10{1

44[7:000 A

IOX=IS2

70~li?14

RSF=70~1i211

.EJ~CT

ISKIP Ir READER F~AG IS SET,
IREAD READER BUFFER IN~O THE AC
lAND CLEAR THE READER fLAG,
ISELECT READER IN ALPHANUMERIC MODE,
ICLEAR THE READER FLAG AND THEN
IREAD ONE 8-BIT CHARACTER (RIGHT
IJUSTIFIED) INTO THE READER BUFFER,
ISELECT READER IN BINARy MODE,
ICLEAR READER FLAG AND THEN READ
ITHREE 6-81T CHARACTERS AND ASSEMBLE
ITHEM INTO THE READER BUFFER TO rORM
lONE 18-BIT BINARY WORD, IN THIS MODE.
18IT 7 or A TAPE ~INE IS IGNOR£DJ AND
ITHE LINE IS IGNORED IF 8IT 8 IS
INOT SET,
IBASE ADDRESS OF THE MONITOR'S
ISYSTEM COMMUNICATION REGISTERS,
IIDX IS USED INSTEAD or IS~ WHEN THE
IINTENT IS TO ADD 1 TO A REGISTER BUT
INDT TO SKIP,

"AGE

PRA.

PRA,

008

52
53
54

ITHIS AND THE NEXT PAGE CONTAIN THE PIRST 37 OCTAL WORDS WHICH
IARE STRUCTURED ACCORDING TO BGO/fGD HANDLER CONVENTION,

,GLOBL PRA,

56
57
58

59
60
61
62
63

64
-..J

65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81

INOTE -- A HANOLrR MAY HAVE ONLy 1 GLOBAL SYMBOL~
R 1002137 R
R 00001321 A
00.:'02 R 000.000 A
("0:'~0,3 R 00~0j2lf21 A
e:N,V) 4 f~ 00Ql0OJ0 A
0V~'('" R 74~1Z4'" A
2Z?~-

pRA,

0~,\\;1.

~N~~"
0~":1<" 1

JMS PRSWAP
0
~

0
0

rl 74004i1l A
R 74!i'!i2i40 A

XX
XX

ISTART OF
0001} R 740040 A

e: e ~. 11 R 74 " 111 4 0 A

QH'h'12 R 740040
00~13 R 740040
('10214 R 740040
00<'lS R 7400421
0071b R 74021421
0.10717 R 7400421

A
A
A
A
A
A

PR8CT
PARER
PTRDM
PRL8HP
PTRwC

LlvE/BAC~UP

xx
xx
xx
xx
XX
xx
XX
XX

lEND or DATA REGtSTERS
.EJECT

JMS TO SWAP SUBROUTINE
rGO BUSY REGISTER
eGo BUSY REGISTER
rGD CLOSE REGIST£R
4 - eGO CLOSE REGISTER
5 - ION (SET BY CA~ HANDLER)
I
THIS IS AN UNUSED VESTIGE PROM PDP.9~
11010 6 • ION oR 10F OR DBR
11010 7 - RETURN POINTER
11010
11010
11010
11010
11010
11010

0 1 •
2 •
3 ~

DATA 'REGISTERS
11010 10 11010 11 11010 12 11010 13 -

11010 14 -

11010 15 11010 16 -

11010 17 -

JMP TO FUNCTION
WHOSE CAL (0.FGD.1.SGO)
,OAT SLOTt ~ 8TH BIT COUNT
UNIT # AND CAL ADDRESS ~ PARITY COUNT
DATA MOOE
LINE BUFPER ADDRESS
~wc OR BuFFER SIlE POINTER
REAL TIME REQUEST .

PAGE

Pt:lA,

rlItZlB

PRA,

1ST ART OF FUNCTI~~ DISPATCH TABLE

/,;4

r~ r-,r;. i
R M004~~ R
00021 R 6130517 R
rlIrl1~22 R 6~~517 R
00~23 R 6~tZl621 R
00Z24 R 6rl1Ql621 R
007125 R 6Ql:1l517 R
rlI0'2J26 R 6210517 R
130027 R 6002165 R
00~30 R 600621 R
et0ii13l. R 000000 A

J'
'

--.J
I

86
87
88
89
90
91
92
93
94
95
96
97
98
99
11210
101
11112
1ftlJ3
104

PAGE
1135
11216
107
108
109
110
111
112
113
114
115
116

pRJIGN
pRE AD
pTR57

00032 R 600621 R
(lIrlIr.l3~~ R rlIeJ0Ql0Ql A
00~34

q 000644 R

(lI01il3~

R 000644 R

PRA,

01218

tWO 2" - l-,INIT
IWO 21 - 2-,OPER-IGNORED
IWD 22 - J.,SEEK-IGNORED
IWO 23 - 4=,ENTER~ERROR
IwO 24 - 5.,C~EAR~ERROR
IwD 25 - 6.,C~OSE~IGNORED
IWD 26 - 7=,MTApE-IGNORED
IWO 27 - 10 •• READ,.REA~R
IWD 3" - 11.~WRITE"REA~W - ERROR
IWO 31 - 12.;WAIT •• WAITR
I
SINCE T~IS FUNCTION IS pROCESSED
I
ENTIRE~Y BY THE MONITOR, PRA. USES
I
THIS REGISTER AS A VAAIAB~E STORI
AGE -. 5/7 ASCII CHARACTER positION;
IWO 32 - 13 •• TRAN~ERROR
IWO 33 - SAVEO .SCOM.J5 (SET BY CA~ ~ANOLER)
I
THIS IS AN UNUSED V£STIGE rROM POP-9.
IWO 34 - STOP rGO 110
IwD 35 - STOP BGO 1/0
IWO 36 - HANDLER 10 • III

J'1P PRER6
0
PRSTOP
PRSTOP

0.0036 R 0Ql000Ql A

.I~:f' PRIN
JMP PR r G~I
JMP PRIGN
JMP PRER6
JMP PRER6
JMP PRIGN
JMP PRIGN
JMP PRREn
JMP pRER6
Ql

-- SWAP SUBROUTINE
.TITlE

API lEVEL 0 OR 1
-

SWAP SUBROUTINE ~- API

~EVE~

0 OR 1

ITHIS SUBROUTI~E IS ENTERED BY T~E
ICAl HANDLER VIA WORD 0 OF THIS 1/0
IHAND~ER JUST PRiOR TO GIVING CONTROL
ITO TME HANULER AT THE APpROPRIATE
lEN TRY IN THE fUNCTION DISPATCH TABLE,
0121037 R 0"I1lI1l~rIJ A
0212140 R 4111011105 R
00041 R 71213304 A
P.l0Ql42 R 620037 R

PRSWAP

XCT pRA •• 5
OBK
JI'1P* PRSWAP

lION,
IFROM ~EvEL " OR 1 TO ~EVE~ 4.
IRE TURN TO CA~ HANOlER.

FlAGE

pRA,

008

-- CAL PROCESSING -- API LEVEL 4
,TITLE -: CAL PROCESSING ~- API LEVEL 4

117

119
119

I.INlT -- CAL FU~CTldN

1221

121

INOTE -- SI~CE THE HANDLER 1.0. CODE (WORD 36) IS NOT 81 • • INtT
ICANNOT OVERRIDE A BUSY CONDITIO~. THEREFORE. NO CAL WILL BE
IALLOWEO INTO PRA. UNTIL pRA. HAS CONCLUDED ITS INtERRUPT PROCrSSING~

122
123

124
125
126

00;;4~
0~'W44

R 20f.ll673 R

127
128

-...J

I
W
0'1

129
130
131
132
133

134
135
136

137
138
139

14 .~

141
142
143
144

PRIN

R 060016 R

LAC (64
DACII PRA,+16

ISTANDARD BUFfER

INOTE -- ThE TEST ON .SETUP ~AVING BEEN DONE AND, CONS[QUENTLV~
IAT LEAST ONE .I~IT, lS BASED ON PRNlT BEING SET TO "JMP FlRIeN".
ITHE FOLLO~ING Is ONCE-ONLY CODE! HENCE. THESE REGISTERS ARE USEO
ILATER ON TO STORE DATA VARIABLES,
00~4~
00~4~
e0~47
00~~~

R 22~674 R
R

040~12

R 120~12 R
R 70e101 A

R 000160
000051
00"~2 R 200054
00753 R 040045
~02~4 R 600517
00~51

R
R
R

PRNIT
LAC* (.SCO M+55
PRDTCT DAC PRBCT
pRCCT
JMS* PR8rT
pRDBP
RSF·
pRCKSM PTRI!\:T
PRDVS2=PRCKSM
pRCNT
LAC ,+2
PTRAC
CAC PR~IT
PRCHAR JMP PRIG~

IADDRESS 0, MONITORIS .S£TUP ROUTINE~
IDAT. WORD COUNT
I,SETUP - CHAR COUNT
ILATER DATA wORO POINTER
ICHECKSUM (lOPS ASCII)
ITEMPORARY STORAGE FOR PRDVS SUBROUTiNr~
IpARITY CHECK COUNTER
ISAVED Ae
ICHARACTER PROCESSED

lEND OF O~CE-O~Lv CODE.
ITABLE OF IOTIS llSEQ WITH THE VARIOUS DATA MODES. NOTE THAT
15, 6 AND 7, BEING POSITIvE VALUES, INDICATE ILLEGAL DATA MOOES.

145
146

147

14 8
149
152
151
152
153
154
155

SI~E.52(10)

I'e;,?:> R 7001<)4 A
0 ...','it- r~ 7C:~144 A
"r~:>7 M 70(')11'4 A
r'(" 5, R 700H14 A
~ (: :, (', 1 R 7 217 1 4 4 A
Zt' '6;' R V1~?J617 R
70,'b3 R 000617 R
'l8"~', K 00~1617 R

PTRIaT

RSA
R:;d

RSA
RSA

RSH

PRER7
PRErt7
PRER7
,EJECT

IIOPS BINARy
IIMAGE BINARY
IIOPS ASCII
IIMAGE ALPHA
IDuMP MODE
IILLEGAL MODE
IILLEGAL MODE
III..LEGAL MODE

IHODE ""
IMODE l.
IHODE 2
IHODE 3
IHODE 4
IMODE 5
IHODE 6
IMODE 1

PAGE
156
1';7
158
159
16~

161
162
163
164
165
166

P"A.

CAL

~fOe

PROCESSI~G

-- API LEVEL 4

I,READ OR ,REALR
v(:6, R 2ZV'Z~5 R
.' e :; 6 i) R '54 Zi 226 R
72"67 R 74H1l0 A
r077~ R 600615 R

pRRED

LAG PRIloIT
pRJIr.N

S~J

CAL FUNCTION
IIF PRNIT HASN'T BEEN CHANGED
ITO "JMp PRIGN", THEN ,INIT

5~P

J"1P PRER6e1

IWAS I\JEVER DONE,

ITHE PRECEJING TEST WAS MADE TO INSURE THAT THE HANDLER IS
ICONNECTED TO IT~ INTERRUPT LINE BEFORE IT ISSUES lOT'S,
10THERWISE, AN ILLEGAL INTERRUPT MIGHT RESULT THAT WOULD ABO~T
IBOTH BGO AND FGr OPERATION,

1~7

168
169
17~

-J

171

172
173
174
175
176
177
178
179
18e!
181
18 2
183
184
185
186
187
188
189

e~"71 R 777777
('v,!'12 " e40663
2e7'7~1 R 2e~!'l!15
~el74 R 'l4~~50
'Iv?7; H 1 4 7246

A
R
R
R
R

LAW
CAe
LAC
DAC

-1
PRIO:.oC
PRLB;.;P
pRDBp
U'i PRDTcT

IIOPS BINARY WORD COUNT
IUNE BtlFFER HEADER
IDAH

ICLEAR DATA COUNT

/THE DATA POINTER IS NOW pOINTING TO THE LINE BUFFER HEADER ADORrSS,
/FOR DUMP ~OCE (~ODE 4) THERE IS NO HEADER, SO DON'T CHANGE TH£ DATA
IPOINTER, FOR lOpS BINARY MODE (~ODE 0) THE HEADER WORD pAIR MUST
IFIRST 9E READ 1\ FROM THE TAPE, So cON'T CHANGE T~E DATA POiNTE~.
IFOR IMAGE MODES AND FOR lOPS AScII THERE IS NO HEADER ON THE TAPE.
/THEREFO"lE. THE ~ATA POINTER MUST BE MOVED PAST THE HEADER WORO PAIR~
R 2<1:.'l2l14
0r('77 R ~e~675
Cl'r,HZ R 741230
0E1~1 R 60~104

N"n6

rrt0~
P~1~3

R
R
A
R

R 1e0562 R
R 1e1~562 R

LAC PTRD~
A\lO (3

IDAH MOr.E
ICHECK FoR DUMP AND lOPS BINARV MODES.

S,\JA

J:1P

PR~XRl

J~S

PRNX\fiD

JMS

PRNX~;D

,EJECT

IIOPS BINARY AND DUMP MODES ~. DO NOT
IINDEX DATA AREA POINTER,
IINDEX PAST LINE BUFFER HEADER
IFOR lOPS AscII OR IMAGE MODES.

PAGE

190
191
192
193
194
195
196
197
198
199
200
2211
2Pl2
203

PAGE
-...I

w
(Xl

204
205
UJ6
207
208
209
210
211
212
213
214
215
216
217
218
219
2221
221
222
223
224
225
226

PRA,

CAL PROCESSING -- API LEVEL 4

008

R 200014 R
R 340676 R
Z?106 R 040107 R
0fl~7 R 740040 A
0,z,11;" R 040153 R
00111 R 7401021 A
ee112 R 60'11617 R
00113 R 777773 A
~0114 R ~4~031 R
00115 R 14'11047 R
0e1l6 R 140051 R
~0117 R 140012 R
0C'120 R 14~HH3 R
~e121 R 14e>672 R

001~4

PRNXR1

7Z1:J,

pI'< A,

III III 8

IDATA MODE
LAC PTRoM
TAD (LAC PTRf{lT
DAe • +1
XX
DAG PRIOT
SMA
J'~p
PRER7
II~LEGAL DATA MODE.
LAW -5
1517 CHARACTER
DAG PTR5,
ICOUNTER.
Di!M PRCCi'
ICLEAR c~ARACT[A COUNT~
Di!t1 PRCKSM
ICL.EAR c~ECJ<SUM
ICL.EAR ASCII 8T~ BIT S~T COUNTER
Ob-' PR8CT
Di!M PARER
ICL.EAR PARITy ERROR SWITCH
Di!M PRXCrS
ICLEAR "£XCESS lOPS BINARY DATA" rLA~~

-- COMMON EXIT -- APr LEVEL 4 OR 2
.TITLE -: COMMON EXIT -- API LEVEL 4 OR 2
ITHE lOPS BINARY INTERRUPT SERVICE ROUTINE MAY ENT£R HERE .~
ICODE IN COMMON WITH THE READ CAL.

00122 R 160050 R
1210123 R 777775 A
012'124 R 040664 R

pRI086
pRIOB'

Di!M* PRoBP
UW -3
DAC PRIOBN

ICLEAR NEXT DATA wORD.
IIOPS BINARY 3 BYTE COUNT.

IIF THIS wE~t THr TYPE OF DEVICE THAT CAN BECOME NOT R£AOY, THE
IRECOMMENDED CHECK POINT WOULD BE HERE. T~E ENO-or.MEDIUM TEST BELOW
lIS LIKE A NOT Rr.ADy CHECK. WHEN A DEVICE IS DETECTED NOT RE~OY,
ITHE HANDLEH REMAINS BUSY AND THE CAL FUNCTION IS NOT COMPLETED, ON
IEND-OF-MEDIUM, HOWEVER, THE NOT READY INrORMATION IS RETURNrO TO TH~
ICALLER AND THE CAL fUNCTION IS COMPLETED. END-or.MEDIUM IS ALSO
ICHECKED IN THE INTERRUPT SERVICE CODE,
0U25 R 7~0314 A
012'126 R 5021677 R
1210127 R 740200 A
1?J013:J R 600441 R

pROUT2

IORS
AND C1~0"

181T 8 • 1 IN THE IORS
ISTATUS WORD MEANS

JMP PREOM
,EJECT

INO-TAPE~IN~READER,

PAGE

--.J

227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
246
249
250
251
252
253
254
255

PRA.

elfli8

COHMON EXIT -- API LEVEL 4 OR 2
ICOMMON PRoTECTEn EXIT rOR CAL LEVEL (API LEVEL 4)
lAND INTERRUPT LFVEL ~API LEVEL 2).

(IIk::i31
00132
00133
("0134
00135

R 22070121 R
R 71215504 A
q 200006 R
R 540701 R
R 74101210 A
~013~ R 600141 R
0e137 R 221121702 R
001421 R 71215504 A
00141 R 600144 R
00142 R 140001 R
20143 R 14i1lel02 R
1210144 R 200703 R
00145 R 040141 R
00146 R 2e0001 R
00147 R 34001212 R
00150 R 75120121 A
01(l151 R 600154 R
210152 R 54067f2J R
2e:153 R 741i1f2J411l A
21e154 R 200053 R
210155 R 703304 A
00156 R 411l0vH:l6 R
00157 R 62121007 R

PRNOR

PRCFLG

PRIOT

LAC* (,SCOM+102 IRAISE TO ~IGHEST LEVEL ALLOWED
ISA
I(API 0 OR 1),
LAC PRA.+6
IDOES WORD 6 CONTAIN A DBR?
SAO (DBR
SKP
lyES, THIS IS AN INTERRUPT EXIT,
,JMP • +3
INC, THIS IS A CAL EXIT,
LAC (404(1!12I121
IREQUEST A LEVEL 4 INTERRU~T TO
ISA
IACTIVATE THE MONITORIS DISPATOH£R,
JMP ,+3
ISET TO "NOP" Ir rLACS ARE TO BE CLEiRED;
DlM PRA,+1
ICLEAR BOTH THE rCD AND BGO
Orr., PRA, +2
IBUSY REGISTERS .~ ONLY 1 WAS SET,
LAC (JMP ,
IRESET PRCFLG TO SKIP THE O~MIS,
OAe PRCFLG
LAC PRA. +1
lIt THE APPROPRIATE BUSY FLAG
TAD PRA,+2
115 121 (THE OTHER ALWAYS IS (21)
SlI.JAlCL,A
lOR IF THE STOP 1/0 rLAG IS
JMP ,+3
ISET (NON-0), BYPASS THE lOT;
SAD pRSTpS
XX
IREADER lOT.
LAC PTRAc
IRESTORE AC,
OBK
IFROM LEVEL 0 OR 1,
XCT pRA •• 6
liON elr CAL EXIT) OR
IDBR (IF INTERRUPT EXIT),
J MP* PRA" +7
IRETURN POINTER, rOR CAL EXITS,
ITHIS WILL R£TURN TO A POINT.
ICALLED "CALXIT" IN THE MONITOR,

PAGE

......
I

256
257
256
259
26[21
261
262
263
264
265
266
267
266
269
2721
271
272
273
274
275
276
277
27ll
279
280
281
282
2~3

284
285
286
287
288

01218

P::,A.

INTERRUPT SERVICE -- API LEVEL 2
.TITLE -- INTERRUpT SERVICE _w API LEVEL 2
IREADER INT~RRUPT SERVICE SUBROUTINE .~ ENTERED AT A~I LEVEL 2
IBV THE JMS INSTRUCTION SET UP IN API CHANNEL 1~ (CORE REGISTER '0).
:J

IL+P/S+MP+RETURN ADDRESS.

;7,["166 R 121412112106 R

DBA
DAC PTRAr;
LAC PTR I ~IT
DAC PRA •• 7
LAC (DBR
OAC pRA.+6

00167

RRB

IENABLE PAGE MODE ADORESSING~
ISAVE THE AC.
ISAVE THE L.P/B.Mp.PC IN
'WORD 7 (THE COMMON EXIT REGISTER).
ISTORE A DBR INSTRUCTION
lIN WORD 6.
IREAD READER BurrER INTO THE
lAC AND CLEAR THE READER rLAG.
ISAVE THE CHARACTER CSITS 10;11),

0k';16,1 R V'12I0iHHl A

PTRINT

707762 A
e"H62 R 1214Z!1I53 R
00163 R 21210'1160 R

0e161 f1

1210164 R [J412112107 R
r016<; R
R

200701 R

700112 A

e01 7'! R 0 4121121 :; 4 R

DAC pRCHAR

ITHIS IS THE rlNAL INTERRUPT EXPECTED rROM THE READER rOR THIS
OPERATlo~. THER[rORE, 1/0 HAS STOPPED. IN CASE IT WAS srT. CLrAR
ITHE STOP 110 rLAG TO SIGNAL THE STOP 1/0 ROUTINE THAT NO rURTH[R
IINTERRUPTS wILL OCcuR.

1110

0(>'1/1 :1

140670 R

OlM PRSTpS

ICLEAR STOP SWITCH.

IIr THE APpROPRIATE BUSY rLAG IS lERD (THE OTHER ONE MUST BE O),
ITHEN THE STOP 1/0 ROUTINE CLEARED IT. Ir so, IGNORE T~E INTrRRUPT,
0017? n 200001 R
" 3 40 iH! 2 R
1?C17~ R 7412010 A
0;117' ~ 6;);.1517 R

Ii' Ii' 1 7,~

LAC PRA.+1
TAO PRA.+2
S'~A
JMP PR I G~.
.EJECT

ICHECK t~R STOP SINCE LAST SE~ECT,
10K?
IND. IGNoRt LAST READ.

PAGE

PRA,

INTERRUPT SERVICE .- API

0i!R

289

-.J

I
01>0

I-'

7i'ilh
('?j 77
;I??/_~--

V0211

72r'314
R 512"'677
p. 74(2:-2'
>l 627441
fi

A
R
A
R

laRS
A'n

J ~1 P PRE OM

r: k' 2 "i 2 R 20 01H 4 R
702Z3 ~ 34:'7iJ4 R
7(;::>,j4

LAC
TAD
CAe
LAC

R 04021'6 R

R 22'£1054
"~2;;:6 R 74??l40
C0:?t7 R 602'216
e,,21: R 6~Z213
e0211 R 60~)327
i2i(;21? R 74;'200
0~225

R
A
R
R
R
A

PROIS1

IPROCESS
['C'215

R e6~~50 R

0?214 ~ 1~e562 R
2!0?13 R 6"0125 R

/READ 10RS STATUS INTO THE AC.
IREADER oUT of TAPE? ( IORS6"1l

(10012

Stb.

IDISPATCH aN

31~

311
312
313
314
315
316
317

IPROCESS THE I~TrR~UPT, IF AFTER DOING SQ, T~E I/O CA~L IS CnMPL[T[,
ICONTROL ~ILL GO TO THE 1/0 DONE LOGIC. IF NOT. MORE I/O WILL BE
IINITIATEJ ~y lOT IN THE COMMON EXIT ROUTINE.

29~

291
292
293
294
295
296
297
298
299
31'1?l
3211
302
303
304
3?l5
306
3127
308
309

LEVE~

PPIM8

T~E

ISET EOM IN OATA BUFFER AND STOP
OATA MODE AND PROCESS THE INTERRUPT,

PTRO",
(JMP PRO I Sl
,+2
PRCHAR

J,'1P PR I 08
JMP PR I Mfl
JMP PRIOA
r-.;OP
I~AGE

BT~ARY

GAC* PRDAP
J''1S PRI\,X'.'D
PROUr2

J'1fl

,EJECT

ISERVICE ACCORDING TO DATA MODE.
/IOPS Blt>JARY
/IMAGE BINARY
IIOPS AscI I
IIMAGE ASCII
OR IMAGE ASCI! OR DUMP MODE,

1ST ORE CHARACTER OR BINARV
'WORD IN DATA BUrFER,
IwORD COMPLETE SUBROUTINE
INEXT CHARACTER

REA~ING~

~AGE.

318
319
327
321
322
323
324
325
326
327
323
329
330
331
332
333
334
335
-...J
I
~

I\J

33e-

337
338
339
3 42
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356

.. h A.

e,;;J 8

I~TERRUPT

SERVICE -- API lEVEL 2

IRRDCES') lOPS
rl21~ R 10~312
('r:?17 R 7444Hi
~~22"
R 6kjC125
ve~21 R 242054

R
A
R
R

PRIDB

EI~ARy.

j;1S FRPAR
S\JL!RAllr"LL
JMP PROUT2
CAe PRCHAR

ICOMPUTE PARITY AND EXIT Ir NULL
181T 8=1 (BINARy rRAME7)
INON·SINARy fRAME (IGNORE)
ICHARACTER t~ 1"5

INEXT 6-8IT BVTE ROUTINE
('r222 R 200672 R

LAC PRXCrS

t:e223 R 74e2(10 A

StA

R 6003~15 R
00223 R 220"'50 R
70?2f- R 744020 A
7~227 R 24l~54 R
0e:;37 R 742010 A
7~"31 R 7420H'] A
2!Z?32 R 742010 A
VV233 R 743010 A
H;234 R ~6~050 R
7~23'5 R 207665 R
;'7236 ~ 74U']20 A
72237 R 7424100 A
P24? R 44~H"13 R
re2 41 R 447J~112 R
,.'0242 R 440664 R
(00243 R 62111'125 R
rZ244 R 447663 R
0Q'245 R 621Z264 R
(7;;246 R 2270521 R
CC'?47 R 7422321 A
0rnS? R 740~Hl A
02251. R 50en5 R
2'0252 R 040663 R
vHP~3 R 34?!2!16 R
rl'254 R 74132121 A
~'0255 R 6003~0 R
?f!224

lIS THIs EXCESS DATA?
IVES, IGNORE IT,
ISHIrT EARLIER CHARACTERS LErT

J'1R PRIORS
LACII RRDgp
RARlCLL
XOR PRCHAR
RTL
RTl
'iTL
RAL
:JACII PRD8~
LAC PRCtl:T1
RAR

ICHECK CHARACTER PARITY
1000 IF" sIT 17-1

S:~L

10 I K,

I ;)X PARER
lOX PR8Cr
IS2 PRI08N
J.'1P PRQui'2
IS2 PRIO.,C
J'1P PRIOB4
LAC· PRDBP

IPARITY ERRORNSAVE BUT PASS CHARACT~R
ITO rORcr A PARITY CHECK.
IINDEX 3 BYTE lOPS BINARy COUNT,
ISTILL WORKING ON CURRENT DATA WORD,
IIND~X ~EAOER WORD ~ COUNT,
IcURRENT DATA WORD COM~LETE,
IC~ECK Ir THE WORD PAIR COUNT IWPC)
lIS LESS THAN THE WORD COUNT (WC),

S~HA

RI\L
AND (776
DAC PRIOHC
TAD PTRWC
SPA!SNA
JMP PRIDB9
,EJECT

IADD THIS CHARACTER TO OTHER 1 OR 2

ITEMPORARILY STORE THE WPC,
IWPC > we. SHORT LINE,
IWPC INTO PTRWC, NO S~ORT LINE~

PAGE

.....
I

357
3513
359
360
361
362
363
364
365
366
367
368
369
37/'1
371
372
373
374
375
376
377
376
379
380
381
382
383
384
385
386
387
388

389
390
391

PRA,

008

R 2007V6 R
7r?!:l7 R 1120606 R
'C?6" R 777776 A
r'l?61 R 340663 R
01Z262 f~ 742,(:101 A
!i'026,~ R 040663 R
[6J{1?64 R 220050 R

INTERRUPT SERVICE -- API LEVEL 2

'~[256

H?6'S R 342!e51 R
2!vI26~ R 040051 R
N'?67 R 440050 R
N:27/ R 44("Ll46 R
0;:271 R 440016 R
0(£272 R 6120122 R
710273 R 22121663 R
~~274 R 75g1~1 A
00275 R 61210452 R
00276 R 1214121672 R
0f!277 R 600123 R
'" 23 ~H' R 77 77 77 A
003~1 R 340663 R
00302 R 740001 A
003e3 R 04012116 R
ee3Z4 R 0121121264 R

LAC

(60

J"iS PRDVS
LAw -2
HD PRIO~C

IWC STAyS IN PTRWC.
ISET DATA VALIDITV 8ITS-SHORT LINE.
ISET UP

pRIO~C

pRIOB4

PRIOS9

DAC PRIO~C
LAC" PRDBP
TAD PRCK5M
CAC PRCK!;M
IDX PRDBp
lOX PRDTrT
IS2 PTRWC
J"IP PRIOR6
LAC PRIOOJC
SMA!CLC
J'1P PRIOBE
[JAC PRXCrS
JMP PRIOR?
LAW .. 1
TAD PRIOHC
CMA
DAC PTRWC
JMP PRIOA4

IOATA WORD-THIS INSTRUCTION IS USED
lAS A LITERAL.
IADD TO CHECKSUM
IINDEX DATA WORD POINTER
IINDEX DATA WORD COUNT
IINDEX WORD COUNT
INEXT DA U WORD
IEXCESS DATA?

INO,
ISET "EXCESS DATA" FLAQ.
IRESET 3 BVTE COUNT.
IWPC INTO F'TRwC

ICOME ~ERE TO BYPASS EXOESS BINARY DATA
IBUffER IS SHORT~
0e3~,:j

01213:36
00307
0031.)
00311

R 44Z664 R
R 6013125 R
R 440663 R
R 600123 R
R 600452 R

TO SKIP EXCrSS DATA

C;>1A

PRIOSS

IS2 PRIOSN
JMP PROUi'2
lSi! PR!O~C
J'1P PRIOg7
Ji'1P PR I Os E
.EJECT

W~EN

THE USER

IINDEX 3 BVTE COUNT
IINDEX EXCESS DATA WORD COUNT.
lEND or 8INARV BLOCK

LIN~'

PAGE

PRA.

12108

392
393
394
395
396
397
398
399

INTERRUPT SERVICE -- API LEVEL 2
ISUBROUTI:,E PRPAR .. - EXIT TO PROUT2 Ir THE a-BIT CHARACT£R PRCI'W~ IS
INULL (rERO). IF NOT, COUNT THE ~UMBER Or 1 8ITS, THE SIGNIricANt
IRESULT IS T~E EvEN OR ODD PARITY tBIT 11) pJ PRCNTl',
I

ICALLING SEQuENCrl
I
I
I

40(!'

......
I

~
~

401
4f2.!2
4i2!3
4!il4
405
4~6

407
4218
409

4H)
411
412
4U
414
415

R 02'e'000 A
R 77777'1; A
R ~4e052 R
R 14e665 R
~'?31~ R 200e54 R
V'~~17 R 7412~10 A
~j~ 32 J R 61:1121125 R
,1~"321 R 74012120 A
?322 R 741421~ A
Z32.3 r' 44~665 R
~:324 R 44~e"2 R
;;3<2::' ~ 60;.J321 R
:'3?'l R 62"312 R

0Z312
Z,;;313
0e314
vW'31 S

PRPAR

JMS PRPAR
(RETURN iF CHARACTER IS

~'ON.eI)

,..

LA .... 10
DAC PRCNT
Di!i'1 PRCNTl
LAC PRCHAR

/pARITY COUNTER (.8)

S ~J A

J'IP PRCUT2
RAR
SlL
lr;x PRCNTl
lSi! PRCNT
J''1P ,-4
J'1P* PRPAR
.EJl:.cT

INULL
11 BIT COUNTER

PAGE

-..J

I
~

416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
45,,1

PRA,

01218

•• INTERRUPT SERVICE

API LEVEL 2

IPROCESS lOPS ASCII
00327

2121012116 R
R 740HH3 A
;)0331 R 600405 R
021332 R 212112112154 R
03333 R 512112170; R
r0334 R 540il0 R
121'-"335 R 60121125 R
e'0336 R 54121711 R
0121337 R 6121121125 R
P'034C1 R 540712 R
00341 R 6121121125 R
01'342 R 11210312 R
~',0343 ~ 74141210 A
00344 R 44121012 R
00345 R 44121047 R
:"0346 R 2121121665 R
2Ie:347 R 7401320 A
0e35'1 R 7414121121 A
?!e~:>l R 440[(H3 R
00352 R 1121121425 R
0(1'353 R 512107<'l7 R
0'-"354 R 54121707 R
70355 R 600125 R
00356 R 100522 R
02357 R Hl0425 R
:' e3 6 '1 R 7 4 0 H~ 0 A
Q'Z361 R 61210125 R
0(:,362 R 200047 R
W.-~63 Ii 54;J713 R
(;'2364 R 600124 R
~n6', R H1057121 R

0~33'~

i=l

PRIOA

LAC PTRWC
S'1A
JMP pRASF.:3
LAC PRCHAR
AND (177
SAD (12
JMP PROUT2
SAD (13
JMP PROUT2
SAO (14
JMP pROUT2
JMS pRPAR
Si!L
IDX PRBCT
lOX PRCCi'
LAC PRCNT1
RAR

ISEE Ir rXCESS DATA
lyES

IIGNORE LINE rEED
IIGNORE VERTICAL TAB
IIGNORE rORM rEED
ICOMPUTE PARITY AND EXIT I' NULL
18TH BIT-l. ADO TO COUNT
IPARITY COUNT·SHOULD 8E EVEN

Si!L

lOX
J"1S
A"iD
SAD

PARER
PRENnT
(177
(177
Ji>1P PROUT2
JMS pRPK57
J~S PRPH'li
SMA
JMP PROUT2
LAC PRCCr
SA J (1
JMP PRt-.iXR1
JMS PRPAD
,EJECT

INOT EVEN PARITY
ICONVERT ALTMOOES
IDROP ALL BUT 7 BITS
IDELETE cOOE (RUBOUT)-IGNORE
IPACK INTO LINE BUrrER IN 5/7
INEXT AscII CHARACTER
IIGNORE SINGLE CARRIAGE RETURN LINE
IpAD LAST DATA WORD PAIR

PAGE

2tj8

r'lA.

451

INTEqRUPT SERVICE -- API LEVEL 2
lEND OF I~PS ASCII. IMAGE ASCII.
IDU~p MQC'E LINE.

452

IM~GE

~INARY.

AND

45~

454
455
456

......
I
~

0'1

457
458
459
46li
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
48121
481
482
483
484
485
486
487
488
489

20il014 R
R
R
n",~7t R H"~1517 R
""~·37? R 222'li'l12 R
V',z;H3 ~ 542047 R
r~r314 :1 6204~1 R
('("375 R 2iZi~1/l13 R
r'P7,., 'i 7402!Z!~ A
:'0377 R 2(2)0715 R
/v:4V'!' R Ul0606 R
:~'366

PRASE

?V367 ~ 540714
;lv37:" r.: 60V'472

7P'4C:l, R 200014 R

rr412
:' !i 4 .~ ,~
V:04(}4

pRASE4

R 240716 R
>l 7 4 e: 2 e r2J A
R 6erz47'2 R

LA~ PTRDf-'
SAD (4
JMP PRIOBS
JMS PRt-t£AD
LAC pR8CT
SAl) pRCCT
JMP FRASF4
LAC PARER
SlA
LAC (20
JMS pRrlV~
LAC PTROM
XQR (2
SlA
J'-1P PRIORB

IIOPS ASCII
'-;Hc4~" ~ 19.!~425 R
;'024"6 R 751101 A
004'''' R 60~4 72 R
i7041~ R 34N151Z1 R
0~411 R 04005ril R
0('412 R 7774021 A
C'Je4u R 5202150 R
00414 R 240717 R
?!PH15 q 0601215121 R
00416 R 44005121 R
210417 R 22e015 R
0042'-' R 50e:706 R
(~0421 R 2407k116 R
0121422 R 5407136 R
00423 R 101i'J6~6 R
erlJ424 R 6121121125 R

pRASE3

£XCE~S

JMS pRENQT
SPA!CLA!r.MA
J~p PRIOPB
TAD PRDB"
DAC pRDBp
LAlol 1741210
fiNO· PROep
XOR (33
DAC. PR09P
I:JX pROBp
LAC· PRL8j.jP
ANI,) (621
XOR (6;')
SAD (60
JMS PRDVS
JMP PROUT2
,EJECT

10UMP MODE.
ISET UP L,B.H 0, ~.P.C,.O,M.
1010 ALL CHAR'S HAVE 81T 8
INO • lOPS ASCII CHECK PARITY
lyES • ASSUME ~ON topS ASCII
IPARITY rRROR
INO
lyES
IPARITY rRROR SET VALIDITY 8ITS
II OPS AscII
lEND LINE
04TA TO BE ICNOREC,
ISKIP TO END

~I~E

IpOINTS TO LAST eHARACTER
IPUT CARRIAG£ RETURN IN LAST WORO'PAiR
lIN CASE MORE BrrORE CARRIAG[ RETURN
lIP OATA VALIDITY BITS HAVEN'T ALREADY
ISEEN SET, srT TO INDICATE SHORT ~INr.

F'AGE

PRA.

000

49~

""
""

olio

491
492
493
494
495
496
497
498
499
500
501
512'2
503
5k'J4
5"'5
5i2!6
5k'J7
51'18
509

510
511

!512

INTERRUPT SEHVICE -- 41'1 LEVEL 2
ISUBROUTI\E PRENnT ~. CALLED rOR 10~S ASCII, Ir AN ALTMOO£ IS IN
IPRCI-IAR, IT IS C~ANG~O <IN T~E AC) rROH 33 O~ 176 TO THE STANDARD
1175, IN ADDITIO~, IF THE CHARACTER IS CARRIAGE RETURN OR ALtMoOr.
180T~ LI~E TER~I'ATORS, THE NUMBrR IS SET NEGATIVE SO THAT IT CAN
IBE TESTED O~ RETURN,
I

ICALLING SEQUENCrl

I
I
I

re42'3 R Z0Z:2!0" A
kJil426 R 200054 R
r'iC:'427 R 52J0707 R
~043[ R 54Z720 R
"I?-431 R 760015 A
ZIZJ432 R 54'-"1721 R
00433 R 760175 A
r0434 R 540722 R
00435 R 760175 A
i?l0436 R 5421717 R
~;e437 H 76QJ175 A
"'044.' ~ 62el425 R

PRE NOT

J"1S PRENrT
CRETURt\!)
~

LAC PRCHAR
AND (177

SAD (15
LAW 15
SAD (175
LAw 175
SAD (176
LAioI 175
SAO (33
LAW 175
J~P*

PRE~IOT

IRE TURN
IAL-THODE
IAL-THODE
IESCAPE

PAGE
!513
514
515
!516
!517
518
519
520

.,.J

.,.co
I

521
522
523
524
525
526
527
528
529
5321
531
532
533
534
535
536
537
538

539

PRAt

i:'J08

•• 1/0

DONE LOGIC •• API LEVEL 4 OR 2
,TITLE w~ 1/0 DONE LOGIC •• API LEVEL. OR 2

lEND or p~PER TAPE ROUTINE,
012441 R 221eih4 R
0e1442 R 5421714 R
22144 3 f~ 6eJ0472 R
"0444 f./ 540716 R
2'0445 R 10'15721 R
~0446 R 12!?J577 R
~0447 R 500723 R
?12'45e R 2412724 R
~1IJ451 R 216V1015 R
0~4~2 >1 2~H12l12 R
e:2' 45 3 I~ 5 4 ~ ill 4 '7 R
?C454 f\ 62104621 R
<0 4 55 P 2~HlZ13 R
2i~456 R 75e2e10 A
(~04~7 R 61Z1Z47e1 R
[,V46'1 R 2212''-''15 R
!~12'461 11 500706 R
:;·04 6/2 ~ 74~:2'H" A
?Z46~ R 6eJ472 R
:'f!464 >l 2Z1v,~51 R
~~J46~ R 741200 A
"0461' R 60121472 R
72467 R 200715 R

PREOH

r- 34Q1715 R

PRIOBP

pRIOBE

pRIDe5

L~C PTRDM
SAD C4
JMP PRIoeR
SAD (2
JMS PRPAQ
JMS PRHEAD
AND (7777621
XOR (6
DAC· PRLBHP
LAC PR8CT
SAD PRCCT
JMP PRIDSS
LAC PARER
StAICLA
JMP FRIDBP
LAC· PRL!='HP
A\JD (6~

StA
JMP PRIDBS
LAC PRCK"M

"'~47:'
,.~

471 R 1~Hl606 R

IIOPS AscII.PAD LAST WORD PAIR.
IsET UP WORD ~ or HEADER.
IMASK ALL BUT MODE BITS,
lAND SET THE MOOE BITS To
IINDICATE ENO-O'-MEDIUM,
IIOPS BI~ARY WILL
IALwAYS CIot[CK
IF'ARITV,
IPARITY ERROR(S)
IWORD 21 o~ LINE BUrrER IotEAOER.
IVALIDITV BITS ALREAOY SET

5 ~~A

JMP PRIDBS
LAC (20

54e

;41
542
543
544
545

ICHECK DATA MODE
IDUMP MODE HAS NO HEADER,
ITHEQErOqt. IGNORE END~O'.MEDIUM~

TAD (2V.
J~1S

PRDVS

,EJECT

INORMA~ END or LINE
ICHECKSU~ ERROR •• SET

DATA
IVALIDITY BITS (12-13) • la,
IpARITY ERROR -. SET DATA
IVALIDITV BITS (12-13) • al.
IsET DATA VALIDITY BITS.

~AGE

-..I

""\0

546
547
548
549
550
551
552
553
554
555
556
557
558
559
5621
561
562
563
564
565
566
567
568
569
57e
571
572
573

PRA,

008

110 DONE LOGIC

API LEVEL 4 OR 2

115 THIS DEVICE iNVOLVED IN AN 1/0 BUSY SITUATION' T~E IOBUS~
IRDUT HE I'i THE "-',ON I TOR WI1.L ANswER THAT QUESTl ON AND WILL CLEAR

ITHE CONDITION Bv REACTIVATING THE rOREGROUND LEVELS THAT WERE BUSY.

~ 22~725 R
R 12412671 R
J~474 R 2207210 R
"~475 R 705504 A
7'12476 R 200726 R
:~e477 R 120671 R
?0502' R 703304 A

e:e472

PRIOBS

il~473

LAC· (, SrOM+52
DAC PRTM?l
LAC· (,SCOM+1QJ2
ISA
LAC (PRA,
J'1S· PRhP1

IADDRESs or THE MONITOR'S
11/0 BUSV TESTER,
IRAISE TO LEVEL ~ OR 1,

08K

IrROM LEVEL

I(WORD 0,
~

OR 1,

ICHECK IF THE COMPLETED 1/0 CAL rS A REAL.TIME
LAC PRA,+11
S\JA
JMP PRIG~
LAC (Jt-'P PREAD
SAC) PRA,.lJ
SKP
J'1P PRIG~
LAC· (, Sr,OM+S1
DAC pRTMFl1
LAC· (.SCO M+102
ISA
L.,AC PRA.+11
J'1S· PRTMP1

'~~501 R 20~HH 7 R
(' 0 :; 0 2 ;( 7 4 1 2 0 0 A
" eo;", 3 R 6 0 e 5 1 7 R
325Z4 R 2012727 R
72'525 R 54201i1l R
2 ? 0 6 R 7 4 H! 0 :iI A
~05n R 600517 R
/0<;1\ R 22<l730 R
'7~511 q ~4~671 R
/0512 R 22;17~~ R
'J<;l~ ~ 705504 A
;,~ 51 4 rt 2 IJ 0 01 7 R
['C51'? R 12Vl671 R
ry:~51fl R 703374 A
'J

REQUEST~

INON-0 rr REAL-TIME,
INOT ,REAL,R,

IJMP F'UNcTION
I,REAL,R,
/tIlOT • RE AL,R,
IADDRESS Or THE MONITOR'S
IREAL TINE PROC~SSOR,
IRAISE TO LEvEL ~ OR 1,
ICAL,L, REALTP TO QUEUE THE
IREAL-TIME SuBROUTINE.

D3K

574

ISET UP TJ CLEAR T~E BUSV rLAG DU~ING PROTECTED [XIT~ THIS IS
IDONE 8ECAUSE I/~ HAS COMPL,ETED, BECAUSE 1/0 HAS BEEN ABORTED
I(STOPIOI, ~ECAUSE THIS IS AN IGNORED CAL rUNCTION, OR BECAUS[
ITHIS CAL FUNCTI~N WAS IGNORED DuE TO AN ERROR,

575
576
577
571'

579
58~

581

582
5f!3

,~ 0: 5 1 7 R 2 21 ill 7 31 R
,.. " 5 2 ~ f. G4 01 41 R

"z,21 R 6eJ131 R

PRIG ~J

LAC (NOP
GAC PRCrl G
J1 P PR~I 0 R

PAGE

<'I

F' ,. A •

Z:!lb

MISCELLANEJUS SUBROUTINES -- API LEVEL 4 OR 2

584
585

.TITLE •• MISCELLANEOUS SUBROUTINES .- API LEVEL 4 OR 2

5il~

587

ISUBROUTINE PRPKS7 -. PACKS 5/7 lOPS ASCII DATA, PRIOR TO THE 'IRST
ICALL, PT~51 MUST RE INITIALJ~ED TO .5,

5118

5A9

ICALLING

590

I
I
I
I
I
I

59:1

59?
593

59.:
595

596
597
598
599
6~0
-...J

I
VI
0

6ClJl
612'2
6213
61214
60~

6Ql6
607
608

6Y'19
610
611
612
613
614
615
616
617
618
619
620
621
622

IRE TURN
;'2522 R 0~Z0(iHJ A
7f('52~ R 74203121 A
'ZC524 R 742121121 A
~?'325 R 0421052 R
00'526 R 77777 ... A
'1(.'527 R 04e!665 R
r~0530 i1 20012152 R
?,0531 Ii 7412lh21 A
1'0532 R 04~12l52 R
'/0533 R 200667 R
('0534 R 7400121 A
0:;'1535 Fl 040667 R
(' 0 536 R 2"? 6 6 6 R
20537 q 740eJ1f('1 A
0054C R 042666 R
',10'541 R 2Q1Q1665 R
0!il542 R 745200 A
n0543 i~ 60V"551 R
V'0544 q 440665 R
~'054? R 6005~0 R
')0546 R 443031 R
0C547 H 6221522 R
0V15~~1 R 60<"533 R

PRPK57

SEQuE~C~1
CHA~ACTER IN TH~ AC
I~ ~ITS 11 T~ROUGH 17
J,>1S PRF'K57

(CONCITlnNAL RETURN)
~ILL

NOT OCCUR lr THE WORD COUNT IS EXHAUSTEO.

SiliHA

RTL

PRPK8K
PR8CK2

DAC pRTM?
LAW .. 7
DAe pRLPCT
LAC PRTMP
RAL
DAC pRTMP
LAC PRRTloIr
"AL
DAC PRRTloir
LAC PRLrkF'
I, AL
DAC pRl,.rlolr
UC PRLPcT
S~A: CI.I.
J"1P PRPD~E
lSi! pRLPcT
J"'p PRFKRK
lSi! pTR57
J'1P* PRPK57
J~~p PR8CK2
.EJECT

ICHARACTER IN AC 81TS 11-17,
IMOVE TO AC BITS 0-6

IROTATE CHAR LE,T
17 BITS THROUGH

ITHE DOURLE WORD
I ACCUMULA TOR
IpRLF'HF" IPRRTHF',

12 WORDS ALL SET,
lIS 7 TIMES COUNT EXHAUSTED?

INO,

100 WE HAVE 5 CHARACTERS?
INO, EXIT
lyES, SHIrT LEFT ONCE MORE.

PAGE
623
624
625
626
627
628
629
630
631
632

'-J .

I-'

633

PRA,

008

,"e,";51

R 20QJ666 R

'~0552
v2'>:)~
'~~54

H ""6~IilS2! R

R 12'21562 R
K 2zr667 R

Ji'55:; R 216210513 R
r'~556 R 10~562 R
,';1557 R 777773 A
r.05bC" R ~40031 R
:.'10561 R 620522 R

MISCELLANEOUS SUB~OUTINES
PRPDNE

~ • • ~I

LEVEL 4 OR 2

LAC FRLF'.-F'
DAC. F'RD8P
JMS PRNXwD
LA.C PRRT~F"
DAC. PROap
,J~S PRNXJ,,!O

IPLACE AcCU~ULATEO
12 WC'ROS h'Te
IUSERS LINE eUFrER,
IUPDATING ~OINTERS.

LA.,J .. 5

IRESET 5 C~ARACTER COUNTER.

OA.C PTR5?
JMP· ~RPK5?
.EJECT

PAGE
634
635
636
637
638
639
64kl
641
642
643
644
645
646
647
-..J

I
U1

64b

649
6%
651
652
653
654
655
6'56
657

PRA.

008

ISUBROUTI~E PR~x~D
I
ICALLING SEQUE~Crl

I
I
I

•• INDEXES DATA ~OINTER AND WORD COUNtS~

PRNXwD
(CONDITlnN_L RETURN)

J~S

IRETURN WILL NOT OCCUR tr THE WORD COUNT IS EXHAUSTED.

l,j V' <;

~0563

6 2 R "HH" ::1 0 V'l
R 440050
'?i?i564 R 44ZI-l46
:1 0 5 6 5 R 4 4 [~ 21 16
?(\566 R 620562
010567 R 6~tl366

pRNXwD

R
R
R

I,)X PRDB!='
I i)X PRDUT
IS2 pTRWr
J~~P* PRNXWD
J~1P PHAS"

ISUBROUTI~E

1(2ERO)

IINDEX TC NEXT DATA WORD~
IADD TO DATA WORD COUNT,
IWORD COUNT EXHAUSTED?
INO, EXIT rOR NEXT CHARACTrR~
..
IEXIT TO END 0, IO~S ASCII LIN£ RDUTIN[,

PRPAC -- PADS LAST WORD PAIR (IN lOPS ASCII) WITH NuLL

Crl"RACTE~S,

ICALLING SEQuENCrl
I
I
I

f,)"iR

y','5r

R ?iZ~e::J0 "

Z571

666

p. API LEVEL 4 OR 2

659

660
661
662
663
664
665

MISCELLANEOuS SUBROUTINES

777773 A

pRPAD
pRPAGN

JMS PRPAn
(RETURN)
Y.

LAW .. 5

C'57? ;; 54;'10:51 R
';''37) R 620,570 R
'7,[:574 "75~0?0 A

SAD PTR57

",1,37'" R li2'!?522 R
Il;:576 R 621Q1S71 R

,J"IS

PRPK57

J'1P

PRPAGN

J'1P*

eLA

PRPAD

.EJECT

lIS LAST WORD
IpAIR FUll.'
lyES, EXIT,
INO, INSERT ANOTHER
INULL CHARACTER,

PAGE

...,J

I
IJl

667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
69(1

PRA.

.- MISCELLANEOUS SUBROUTINES .- API LEVEL 4 OR 2

008

ISUBROUTI~E
IWIT~

ICALLING SEQUE~C~I
I
I
I
~0577 R 01,Hl0[ll0
7:21601 q 20~H'46
;"0601 .~ 742030
'~e602 R 744020
"'0603 '1 240014
[ll[ll604 R 06el,115
006,'5 R 620577

A
R
A
A
R
R
R

69b
697
69&
699

PRHE:AD

PRHEAD
(RETURN)

j~S

LAC PRDTrT
SWHA
RCR
XOR PTRDM
JAC* PRLI1HP
JMP* PRH~AD

IWORD COUNT (INCLUDES L.B.H,)
IWORO PAIR CoUNT (BITS 1-S'.
IDATA MODE,

ISUBROUTINE PRDVS •• SETS DATA VALIDITY (C.V,) BITS IN
ILINE 8U~FER HEADER WORD 0.

T~[

SEQUENC£I

ICALLI~G

I
I
I
I
I

/)91
692

693
694
690;

pRHEAD •• SETS UP THE LINE BUFFER HEADER (L.B.H,) WORD 0
THE wORD PAIR COUNT AND THE DATA MOD~,

""0621' R 021~0021 A
7Z5n R 1640051 R

A
~c1;1i11
R
;1'61? ~ 241lB51 R
C(613 ~ ;060(115 R
7[:614 R 62?'6vi6 R
'~061.'

R 777717
-l 520015

PRDVS

JAiA VALIDITY BIiS (12.13)
SET TO DrSIR£O VALUE IN TH£ AC
JMS PRDVS
(RETURN)
k.'

(lAC PRDVs2
LAW 17717
A~JD* PRLRHP
XOR PRDV~2
LJAC* PRL~HP
Jr1P* PROvS

ISAVE DATA VALIDITY BITS~
IMASK ALL BITS IN THE LINE BUrrER ~EAD[R WORO
10, EXCEPT IGNO~E CH£CKSUM BiT (~, A~D O~V.
IBITS (12.13), ADO IN ~ARITY ERROR, ~H[CKSUM
IERROR, DR S~ORT LINE.

PHE

PRA,

008

ERQORS

7'<.: 'l

1 III 1
'''2
703
704
10:)
7~6

7"'7
7kl8
7219
71:.')

711

-..J'

I
VI

712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727

API LEVrL 4

,TITLE -. ERRORS "- API LEVEL 4

;1061'5 R 766060 A
(;106:1.6 R 74H'00 A
d'H7 R 766007 A
'1' v' 6 V
R 7 410 fiH'l A
CfZ621 R 766006 A
C"f622 R 040637 R
9:12162.3 R 2012!011 R
~0b24 R 7416"'20 A
:1e;62r, R 20063' R
70626 ~ 74:114 " A
7'((;627 R 24e732 R
:'PI'l3(: R ~4063' R
':0631 R 20fiHH3 R
r.(?632 R 04~'641 R
7-0633 ~ 220733 R
Z~634 R t?40671 R
n;635 R 2201VH'J R
00636 R 7055;.14 A
(1;0637 R 740040 A
~;064'J R 120671 R
0(1'641 R 740040 A
00642 R 7033~4 A
2'0643 ~ 60:!1517 R

I[RROR

ROUTl~E

PRER62'

LA" 606~
SKP
LAw 6007

pRER7

-. ALL READER ERR~RS ARE OETECT{D AT THE CAL ~£VEL,
I,INIT NOT PERFORMED,
IILLEGAL DATA MODE,

SKP

PPER6

Uloi 6006

pREROR

ILAW ERRoR

IAUXILIARY ARGUMENT,
IBACK To L~VEL 4,
IIGNORE THE CAL BY CLEARINC
IT~E BUSy REGISTER.

IILLEGAL CAL FUNCTION.
GAC PRER('IR
ITEMPORARY SAVE.
LAC PRA. +11
IWHOSE CAL. 0.'GO. i-aGO.
RAR
LAC PRERnR
SNL
IrS IT FCo,
XOR (3rt00
lyES, CHANGE aGO ERROR To 'GO [RROR~
CAe PREReR
LAC PARER
IPUT CAL ADDRESS IN THE AUXILIARY
CAC PRAUx
IARGUMENT rOR PRINTOUT,
LAC· (.SCOM+66 IADDRESs or THE MONITOR'S
OAC PRTM!=>1
IERROR QuEUE'l,
LAC· (, SCOM+102
IS ,iI

JMS. PRTM!'1

!'RAUx

[1BJ<

JMP PRIG'-i

* + JOB AT 'AULT.

PAGE

PRA.

008

-- STOPIO SUBROUTINE -- MAINSTREAM
.TITLE ~~ STOPIO SUBROUTINE -- MAINSTREAM

728
729

ISTOP 111i SU8ROufINE .~ OPERATING AT MAINSTREAM BY VIRTUE 0, A CALL
IFROM WIT~IN THE FOR[GROUND OR BACKGROUND ERROR ROUTINE IN T~E
IMONITOR. THE ~ONITOR WILL CALL THIS ROUTINE ONLY IF THE APPRO~
IPRIATE JUB BUSY FLAG (WORD 1 OR 2) INDICATES THAT 1/0 IS UNOER
IwAY, J/0 CANNOT BE STOPPED BY ISSUING AN lOT' TH£RErORE, A WAit
ILOOP MAY NEED Tn BE EXECUTED UNTIL THE rINAL INTERRUPT HAS OCCURRED~

73~

731
732
733
734
735
736
737
138
739

..j

I
U1
U1

r'0644 R ~00'H'l0 A.
[i!~645 R 22121700 R
20"46 R 71215504 A

740
741

910647 R 2t(J00:::l1 R

742
743
744
145
746
747
748

(1'0651 R 040670
00652 R 142'001
k1 0653 R 140002
1;H'654 R 140003
NJ655 R 140004

r.06~h'

R 3400~2 R
R

R
R

r0656 R 7033r214 A
rf2!657 R 200672 R

749

9'066(' R 74022)(6 A

.750
751
752
753
754

00~61

755
756
757
758

(/)0663 R 000000 A
21~664 R 00Q!000 A
21"665 ~ 001iH?J00 A.
0~0052 R
000665 R
7?666 R 000000 A
~12'667 R 000000 A
2'e670 R 00000!21 A
00671 R 000000 A
20672 R 000000 A

759
760
761
762
763

764
765

PRSTQP

R 600657 R
210662 R 620644 R

"LAC· (.SCOM.102 IRAISE TO LEVEL 0 OR 1.
ISA
LAC PRA •• 1
TAO PRA •• 2
DAC pRSTpS
ISET STop SWITCH ACCORDING TO BUSY REG!STER,
DlM PRA •• 1
ICLEAR BUSy rLAGS.
DeM PRA •• 2
DeM PRA,.3
IC~EAR CLOSE SWITCHES,
OeM PRA •• 4
ORK
IDEBREAK BACK TO MAINSTREAM.
LAC PRSTPS
IwAIT LOoP, FALL THROUGH
SH
IWHEN NO FURTHER INTERRUPTS
JMP ,·2
IWILL OCCUR.
J-1p. PRSTOP
IRE TURN TO THE MONITOR'S ERROR ROUTINE~

ITEMPORARY REGISfERS,
PRIO~C

PRIOBN 0
PRCNT1 e'
PRTMP-PRCNT
PRLPChPRCi\iT1
PRI.F'f.lF ~
PRRT~"
0
PRSTPS 0
PRTMP1 (1
PRXCES e

IIOPS BIN, WD1 COUNT
1101'S BIN 3 BYTE COUNT
11 BIT COUNTER rOR PARITy CHECK
ITEMP. STORAGE rOR '17 CHAR,
IROTATE , BITS COUNT[R~
12 WORD ACCUMULATOR rOR
15/7 WORD PAIR.
ISTOI' UNDERWAY SWITCH
IGENERAL TEMPORARy REGISTER.
IIOPS BINARY EXCESS OATA rLAG. 0 • OAT.A
IO.K,1 NoN.0 - IGNORE EXCESS DATA.

'AGE

PRA,

a08

.- L lTERALS

.TITLE -~ LITERALS

166
167
168

0PJ~00~

.ENO

R ~g0a64 A -L
2067. R 000155 A -L

~Z673

A -L
R 2~0055 R -L
~ 0~le00 A -L
107Z70 R 0002~2 A -L
007tl R 703344 A -L
~e7~2 R 404000 A -L
Z07~J ~ 6~0144 R -L
~r124 R 600207 R .L
~07d~ R 000776 A -L
~e706 ~ 000060 A -L
~~7~7 R 000177 A -L
~~11?- ~ 0Z0012 A .L
~G711 R ~e2013 A -L
~e112 R 000014 A -L
~0713 R r0~001 A -L
~0714 R ~0~~Z4 A -L
~071? R ~0Z020 A -L
?~716 Q 0Z0002 A -L
?~717 R ~~0a33 A -L
~C72~ R 0Z0015 A -L
:r721 R 0~0175 A .L
~?722 Q ~00176 A -L
l~723 R 777760 A -L
)~724 R 00~006 A -L
~~72? R 003152 A -L
~~72A R 000~~0 R -L
~?727 R 600027 R -L
:07J.' l' Z~et51 A -L
~?'73t ~ 74~030 A -L
~e732 R 2e3~~0 A -L
l~7J3 R 000166 A -L
e,0675 R 0~e0@3
~~676
~~677

.....I
us

CJ\

sI~E"00734

NO £RROR LI"IES

PAGE

PRAt

44000;1 A
lOX
"RASE4 "Ie401 R
PRCCT
('I~"'47 R
('11012152 p
PRC'H
PRDTCT 021("4/\ R
PRE NOT 21042<; R
PRER6121 00615 R
0121213 R
F'RIME!
PRIOB8 00472 R
PRI08S ::112131215 R
PRIOB7 iZ'0123 p
....:J

I
U1

....:J

PRJIGN

I'RNIT
PROUT2
PRPO~JE

PRRTHF
PRTMP
PTRAC
PTR~;C

RS8

Ct02/\ R
0121~45

021123 R

'10551 R
r<0667 R
lV'00:>? ~
00 v5:t ;:

c:z,ep

7:,1144 A

008
PARER
FRAUX
FRC~LG

PRCNH
PRDVS
PRE OM
PRER7
PRW
PRIOBE
PRIOS4
PRIC89
PRL8HP
PRNOR
PRPAD
PRPK8K
pRSTnp
PRH1Pl

PTROt-',
PB57
R'H"

.. - LITERALS
12112112113 R
006041 R
121121141 R
2121665 R
0121606 R
1210441 R
00617 R
121121043 R
"0452 R
13121264 R
1210313121 R
130015 R
~Hl131 R
12111'57121 R
J1!12153121 R
l2IeJ644 R
1210671 R
J1!(/)el14 R
J1!(/)031 Q
70011111 A

!"RASE
1210366 R
00 r1I(IHl R
PRA.
F'RCHAR 12102154 R
0021521 R
PRDBP
PRDVS2 I:H!2112151 R
PREROR 0~637 R
F'RHEAU 013!)77 R
PRIOA
1313327 R
PRIOBN fZfIl664 R
PRIO~!:I
~1346121 R
F'RIOHC 0121663 R
PRU"HF 1210666 R
PR,'JXRl 012111214 R
PRPAGN ~12!571 ~
PRP~57
el2l522 ~
PRSTPS e0670 R
F'RXCES 01216'2 R
PT'lINT 11'12116~ R
RR8
70121112 A
• SCOt1

(/)0e1H'l0 •

F'RASE3 0214215 R
pRBCK2 1210533 R
pRCKSM 1212112151 R
pRDlS1 121021217 R
pREAD
12112112127 R
pRER6
121121621 R
pRIGN
1210517 R
pRIOB
12121216 R
pRIOBP 12112147121 R
pRIOB6 021122 R
pRIOT
121121153 R
pRLPCT 211210665 R
FRNXWO 1210562 R
pRPAR
1210312 R
pRRE:O
121121065 R
pRSWAP 12112112137 R
12102112 R
"RBeT
"TRIOT 02112155 R
RSA
7111121104 A

PAGE

...;
I
UI
CD

PR.\.

t101!ee R
PRA.
PRLBHP :1""'15 ;;p
PTRS7
~a"31 iC
PRDTCT !'lll!fl46 R
PROYS2 lI~fI~51 R
PRCHAR I'!U54 R
PRr4XRl :12'104 q
PRNQA
~'lJl R
PROIS1 ~"J207 R
PRIOB9 ~e3e£' R
PRASE
i1e366 P.
P-1(I441 R
PREO"
PRIOBS "'1472 P
PR9CI(2 00533 R
PRP"" ~0571 R
PRER7
l'IS617 R
PRSTO' S864At R
PRLPeT 1109665 p
PRTMP1 a0671 ~
RSA
7P0184 A

pReeT

.. - LITERALS

'la12 p
"8116 R
PRSWAP .1.37 R
.l1li47 q
PRcer
88152 R
PRCNT
PTRIOT 1111155 R
PRIOB6 11122 R
pRCF'Le 81141 R
pRIf'le
1110213 II
pRIOS" 81305 R
PRASt:4 1.401 R
PRIOBE .,452 R
PRIGN
l1li'17 R
PRPD~E
8.'51 R
PflHEAD 8.577 R
PRER6
18621 R
PRIOHe 1111663 R
PRV'HF' 81666 R
PAXCES 111672 R
RR8
718112 A
PTRlle

el313 A
PqJIGN n,26 ~
paU:"4
1UJ1'4J A
PROilP
' •• 5111 A
PRT"!P 8.8.52 R
PRRED
iIl8165 A
PRIOSl irJ8123 R
PRIOT
08153 R
PRlOB
0121' A
PRP4R
88312 R
PRASE3 nd5 R
PRIOS' 88468 It
PRP!(5l 08'22 A
PRNlCWO e8562 A
PROVS
'.686 R
P~EROR
.8637 R
PRIDaN 18664 R
PRRTHf" 88667 R
448ell 1
lOX
RSB
71'1" 1
P4~ER

pTRDM
88114 R
pREAD
.,11127 R
pRNIT
11111'45 R
pRCI(SM ""051 ~
pTRAC
.'853 R
.SCOM a0111U0 A
pROUT2 1111125 R
pTRIt.lT 111111160 R
pRI094 1118264 R
pRIO! . 0U27 R
pAENDT '1425 R
pRIOBP .,470 R
pRPIC91C 81530 R
pRPAD
.157. R
pRER6' 8111615 R
pRAUX
'111641 R
pACNT1 11166' R
pRSTPS IIfI,,8 ..
RSF'
78111101 A

PAr;E

lOX

4 4 CH~ l'i,'

PARER
PRASE
PRASE3
PRASt:4
PRAUX
PRA,

'-J

VI
ID

"R8CK2
"RceT
"RC'FLG
PRCHi\R
PRCKSM
PRCNT

CROSS REFERENCE

c:> '" A •

0036:'\

,,7*
451
74.
4,,4.

r";:J4f1">

4;?r:1

r:~~13

C"04~1

4f,:c

('I(~64t

717
5:;

0~~!J~~1

kW53·~

410

431

436

46l

529

716

126
268
741

232
283
743

239
284
744

445

459

527

323
365
758
433
312
4813

332
366

368
486
691

432

436

2'U
554
745

243
5621
746

244
564

4215
536

421

5iZJ2

757"
332
481

759
337
624

347
627

363
644

367

645
543

676
693-

699

472
511_
715
93

5211*

512

708-

154
675_
90

196
681
91

7i1l6*
562

566

5elZJ ..

'571
60.17.

710

7421

141·

~3g*

1~7.

U9-

PRC~JT1

:?W66 '5

pRnnp

.Ba

03050

13647~

F'RDtS1 I'102Vl7
F'RDTCT 1'121~4~
0!C 60~,
F'RDVS
PRDVS2 000051
PREAD
l"M27

3.01
134.
3::'8

F'RE~I')T

0e42~

PRE OM
PREROR
PRER6
F'RER60
PRE:R7
"RHEAD
I'RIGN

00441
021637
00621
021615

4'37
224
7'19
S8
161
152
457

00577
00517

368

114
266

(1e'~54

00617

367

59.
253

13S-

V'l0~5'

222
648
472*
465.
724.

342
645
341

2 'j 1.

:;10047
;10141
!'I0 i?l51

341
644

ue-

92-

80S

199
242
271
138
4213

432
581

4(1)4

41121
209
478

171
476
305.
172
464
694
563
442
296
712
89

3213

20!?J
411

722_

7~4 ..

153
522
87

141

266

continued on next page.

PAGE

m
0

PRIM8
00213
PRIN
00043
PRloA
00327
PRIOS
00216
PRIOSS 0~472
PRIOBE 210452
PRloeN 00664
PRI08P 0047("
PRIORS 210305
PRIOS4 00264
PRIOS5 071467,
PRIOB6 00122
PRI087 i'l(~ 12 ~
PRI089 0213~W
PRloHe 21121663
PRIOT
00153
PRJIGN 00026
PRL8HP "110~1r;
PRLFHF r:HH6f.
PRLPCT 000665
PRN IT
2I0el45
PR"JQR
00131

PRA.

CROSS REFERENCE (Cont.)

726
3~16

85
327

305
45~

373
211
531
329
346
'2~

209*
21:1.
354

169
1144

91*

76.

612
6"3

133.
2,~ 21.

312.
125.
418*
320*
468
389
343
541*
385 ..
363*
532i1
370
375
376*
345
24P.
159
17'"
612
613
140
583

474
526.
385

519

535

538

55"*

75611

380
388
351

360

362

371

377

387

482
623
616
158

525
76 QIII
759*

532

680

696

698

75511

PAGE
F'RNXRl
ItRNXWO
ItROUT2

-...I

I
0'1

I-'

PRA.
MUI4
00562
00125
((I057~

F'RPAD
F'RPAGN
PRPAR
PRPONE
F'RPK8K
F'RPK57

00571
:')0312
"'0551
00530
('10522

F'R~ED

"'0 rII{) 5

I'RRTI-1F' 00667
PRSTOP f'l0644
PRSTFS 00670
PRSWAP "1.,037
PRTMP 017J~e52
PFHHPl ~0671
PRXCES 00672
0~H~12
PR8eT
r0(~53
PTRAC
PTHDM
C'~~14
PTR I '!T 7Ikl16'';
PTRIOT ~i2I~5?
(lI?t~l(,
PTRwC
PTR57
30031
RRH
7?1~11?
RSA
700104
RSR
700144
70!H(H
RSF"
,SCOM o"I 01VF'

CROSS REF'£RENCE

184
186
221*
440
448
65~*

320
615

604441
92
6':'7
1712
247
">9

19th
187

315
444
521
664
40111
623.
617
598_
158.
609
1~3

278
113.

6~' 1

6~4

55t

3337*

555
327
134
249
181
261191
352
198
269
147
148

~0*

136

4:;*

133

2k:3

7314J_
751.37

147.
77*
'14-

31-

73d

447

314
322
487
658.

625
344

628
386

643.
407

647
424

426

428

661

413

429

619

631

663

626
73'*
742
116
61;,6
568
374
135
264
190
265

761*
751
748

762-

758_
572
764_
201

719

723

763-

342

431

458

526

3021

454

465

517

679

369
618

379
630

418
660

646

149
151

150

230

5513

5~2

567

569

718

72 III

SECTION 8
SYSTEM GENERATION
8.1

INTRODUCTION

Master PDP-IS Background/Foreground Monitor systems are supplied to customers in
an executable binary form on a single DECtape.

The Master system represents an

immediately usable system: however, it is recommended that the user perform a
system generation procedure using the Master system, a system generator prograIn,
and command inputs to produce a working Background/Foreground Monitor system
conforming to the user's specific equipment and software needs.

The required

system generator program is listed on the Master system under the file name
"BFSGEN SYS".
8.1.1

BFSGEN, Generation and Update Features

The program BFSGEN can perform two optional functions:
1)

SYSTEM GENERATION. - This function enables the transfer of a system
of selected software from the Master system to some intermediate,
file structured, mass storage device (DECtape or Disk). Normally,
the transferred system will not conform to the requirements of the
installation on which it is to be used; however, it is in a form
which is easily modified (i.e., updated).

SYSTEM UPDATE. - The update function of BFSGEN enables the user to
modify both hardware and software parameters of a generated system.
This feature must be used when building the initial system.

Update

may also be used to modify a previously generated system to meet
new hardware or software requirements.

8.2

BFSGEN DEVICE REQUIREMENTS

System generation operations must be performed between two similar I/O devices
(e.g., DECtape to DECtape) i dissimilar devices (e.g., DECtape to DISK) cannot
be used.
8.2.1

DECtape Masters

Both Disk and DECtape system Masters are supplied on DECtape.

For both types

of Masters, system generation may be performed directly from the Master DECtape
to a system DECtape.
For an installation with a Disk, the user may first transfer the Master system
from DEC tape onto a Disk unit, using utility program PIP or RFSAV (refer to
PDP-lS Utility Manual DEC-IS-YWZA-D).
string fOllows:

An example of the required PIP command
8-1

C DK4 +-DT3 (H»)
System generation is then performed between Disk units.

The resulting system

should be copied onto DECtape for backup purposes, using either PIP or RFSAV
(refer to utility manual) .
8.2.2

Loading BFSGEN

BFSGEN uses the following .DAT slots:
. DAT slot

Used for .••

-14

Input from Master tape

-15

a) Output of a generated system
b) Input/Output of system to be
updated.

-3

Teletype output

-2

Teletype input

Initially, one must run the system supplied on the Master tape since this is the
only way the System Generator program can be loaded and run.

The following two

steps must first be performed:
1.

If the tape is a Disk Master, the system must be installed onto
Disk unit zero from the Master tape by using the utility program
RFSAV (refer to the PDP-IS Utility Manual, DEC-lS-YWZA-D) or by
performing a COpy using PIP running under the Advanced Monitor
System.

Then, whether the operating system resides on DECtape or on
Disk, follow the procedures in paragraphs 5.2.1 and 5.3.1 to
bring in the Monitor and to load IDLE in the Foreground.

The remaining steps indicate how to load the System Generator in the Background.
This is similar to Advanced Monitor System operation.
3.

When the Monitor is ready to accept commands on the Background
control Teletype, it prints:
BKMlS V3A
$

If the Master tape is on DECtape transport 4 and a scratch tape
(onto which a generated system is to be output) is on DECtape
transport 5, for example, perform the following:
$ASSIGN DT4
$ASSIGN DTS
$BFSGEN

-14
-15

When the System Generator is loaded and running, it will print out:
B/F-lS SGEN Vxx
8-2

8.3

SYSTEM GENERATION PROCEDURES

The System Generator consists of modular sections of code.

The operation of each

is discussed individually in the following paragraphs.
8.3.1

Section A -- Initialization
Summary:

The user is asked if he would like to run in brief mode.
If he answers no, a summary of System Generator rules is
typed out.

Operation:

When the System Generator has been loaded into core and
is started, it will type:

BF-lS SGEN Vnn
BRIEF MODE? (YIN)
In the brief mode the System Generator will abridge the
messages it types out.

The user must respond by typing

(meaning YES) or ~ (meaning NO).

If YES, the remainder

of Section A is bypassed and processing goes to Section B.
If NO, the System Generator types out a summary of
operating rules and from then on all messages are printed
in expanded form.
The summary of operating rules is typed out as follows:
.DAT SLOT ASSIGNMENTS:
WHEN GENERATING A NEW SYSTEM, A BIF MASTER MUST BE ON
THE DEVICE ASSIGNED TO .DAT SLOT -14. A NEW SYSTEM WILL
BE BUILT ON THE DEVICE ASSIGNED TO .DAT SLOT -15.
WHEN UPDATING AN OLD SYSTEM, THAT SYSTEM MUST BE ON THE
DEVICE ASSIGNED TO .DAT SLOT -15.
KEY-IN CONVENTIONS:
STATEMENTS THAT REQUIRE A RESPONSE END IN EITHER A
QUESTION MARK (?), AN ANGLE BRACKET (», OR A SQUARE
BRACKET (]).
QUESTION MARK (?)-- A YES OR NO ANSWER IS REQUIRED. TYPE
'Y' FOR YES OR 'N' FOR NO.
IN BRIEF MODE, A QUESTION MARK
MAY BE TYPED TO CAUSE THE QUESTION TO BE RESTATED IN AN
EXPANDED FORM.
ANGLE BRACKET (»-- A PARAMETER (NAME, SET OF NAMES,
OR A VALUE) IS REQUIRED. TYPE THE PARAMETER AND TERMINATE
WITH A CARRIAGE RETURN. **
SQUARE BRACKET (l) --A PARAMETER HAS BEEN TYPED OUT
ENCLOSED IN SQUARE BRACKETS ([ ]). THE PARAMETER MAY BE
ACCEPTED AS IS BY TYPING A CARRIAGE RETURN, OR IT MAY BE
ALTERED BY RETYPING THE ENTIRE PARAMETER TERMINATED BY A
CARRIAGE RETURN. **
8-3

RESTART:
TYPING A tP WILL RESTART THE SYSTEM GENERATOR. THIS SHOULD
ONLY BE DONE WHILE BFSGEN IS WAITING FOR A TYPE IN.

** THE PARAMETER IS READ IN lOPS ASCII. I.E., RUB OUT & tu
EDITING AND ALTMODE TERMINATION ARE POSSIBLE.
8.3.2

Section B -- System Selection & Read-in
Summary:

The user is asked if this is to be a system generation
or an update of a previously generated system.

If a

new system (generation) is wanted, the requested
system is transferred to the output device from the
Master system.
Operation:

The following question is typed:

IS THIS AN UPDATE OF A PREVIOUSLY GENERATED SYSTEM?
If the user types! (for YES), most of Section B is
bypassed and processing continues with the reading
of information from a previously generated tape (see
below) •
If the user types

(for NO), the System Generator

copies the Master system onto the output device.

this is being done, the System Generator informs the
user
SYSTEM BEING TRANSFERRED
When the transfer is complete, BFSGEN reads selected
blocks of information from the generated system and
enters its update

~:'ase.

While this is being done,

BFSGEN types:
SYSTEM INFORMATION BEING READ
This information is then presented to the user during
the update process as assumed parameter values.

For

instance, if the system was built for a machine with
three Teletypes, one of the parameters will be:

NUMBER OF TTY'S

[3]

which the user may either accept or change.
8-4

Once the system parameters have been read in, BFSGEN will type:
A tP TYPEIN WILL RETURN CONTROL AT THIS POINT
8,3.3

Section C -- System Parameters
Sununary:

The user is asked if he would like t9 change or see
the system parameters.

If he answers yes, each

parameter is typed out with the parameter value
enclosed in square brackets.

The user may accept or

retype each value.
Operation:

At the start of Section C, BFSGEN types:

DO YOU WISH TO CHANGE (OR SEE) SYSTEM PARAMETERS?
expecting the user to type! (if YES) or ~ (if NO) .
If NO, the old parameter values are retained and
operation continues at Section D.
If YES, each parameter is listed with its assumed
value and a response of acceptance (carriage return)
or correction (typing new value) is expected.

The

following table lists the parameters in the order in
which they are typed out and also the legal values
that may be typed in.
NOTE
System core size information is obtained from the
" mu lticore" paper tape bootstrap.
PARAMETER

ACCEPTED VALUES

... , N

(Note 1)

TTY #N IS A MODEL KSR[XX]

33 or 35

(Note 2)

BCONTROL [XX]

~,!,

NUMBER OF TTY'S

[XX]

FCONTROL [XX]

... ,N-l (Note 3)
~,!, ... ,N-l (Note 4)

RAISE TO LEVEL [X]

~,!

(Note 5)

$ SHARE

!,~

(Note 6)

[X]

FCORE [XXXXX]
FGD tc CONFIRMER [X]

~'1.
!,~

8-5

... , core size (Note 7)
(Note 8)

NOTE 1:
The maximum number of Teletypes the system will allow is a
function of a parameter assignment made during assembly of
the Resident Monitor. For the initial system generation, the
maximum number is assumed and will appear within the brackets.
NOTE 2:
Teletypes are logically numbered ~ to N-l, where N is the value
of the first parameter (number of Teletypes). For each
Teletype, the parameter is printed in order to verify or
determine that it is a model KSR33 or a model KSR35. ASR33
Teletypes are considered to be KSR33 and ASR35 to be KSR35.
NOTE 3:
The Background control Teletype may be any logical unit from
~ to N-l, where N is the value of the first parameter
(number of Teletypes).
NOTE 4:
The Foreground control Teletype may be any logical unit from
to N-I, excluding the unit number assigned to the Background
control Teletype.

NOTE 5:
All system software will raise to API level ~ for reentrancy
protection 1 unless the user wants complete control over
level~.
If such is the case, he must specify that all system
software will RAISE TO LEVEL 1.
NOTE 6:
The initial setting of the SHARE flag is determined at
system generation time.
NOTE 7:
The initial setting of FREE CORE is determined at system
generation time.
2 is the lowest value required.
NOTE 8:
One of the two jobs, Background or Foreground, can cause the
Monitor to be reloaded once CTRL C has been typed the first
time on the Foreground control Teletype. That job is
designated as the tc Confirmer 2 . This parameter is phrased in
the form of a question and asks is the Foreground job the
tc Confirmer.
8.3.4

Section D -- Existing I/O Devices
Summary:

The user is asked if he would like to change or see the
known I/O devices.

If he answers yes, the devices

which must exist are listed followed by the devices
which exist but may be deleted from the system.
A question mark is typed following the listing of
ISee section 7.4.
2See section 3.4.
8-6

each device which may be deleted, and the user must
indicate whether or not each shall be kept by typing
ny" or "N".

Operation:

BFSGEN begins Section D

by typing:

DO YOU WISH TO CHANGE (OR SEE) KNOWN I/O DEVICES?
expecting the user to respond with Y (if YES) or N
(if NO).

If NO, the existing devices are retained and

operation continues at Section E.

If YES, the following

question is typed out:
DO YOU WISH TO SEE MANDATORY I/O DEVICES?
expecting a response of

r or

If NO, operation continues with the expendable devices
(see below).
If YES, the mandatory devices are listed along with
relevant information:
(CLOCK)
API

(Note 1)
(Note 2)

SKIP lOT

7{J{J{J{Jl

(Note 3)

API CHNL

(Note 4)

(MEMORY PROTECT)
PI
SKIP lOT

7{J17{Jl

MNEMONIC

MPSK

(TTY CONTROL)

(Note

(Note 2)

API
SKIP lOT

7{J{J4{Jl

MNEMONIC

TSF{J

SKIP lOT

7{J{J3{Jl

MNEMONIC

KSF{J

(CORE-CORE)

(NONE)

DT
(SYSTEM DEV)
API

(Note 5)
8-7

SKIP lOT

7~76~1

API CHNL

SKIP lOT

7~7561

API CHNL

(Note 6)

NOTE 1:
The system clock and the memory protect hardware must exist and
are, therefore, listed. They are devices which do not have
assignable handlers and do not have device names.
Their names,
therefore, are shown as

NOTE 2:
The designation API or PI is printed to indicate how the device
is attached to the interrupt hardware of the machine.
The
Teletype device (TT) always includes the console Teletype which
is not attached to the LT19 and operates always on PI.
Teletype is the only device in the system which is allowed to
receive interrupts on both PI (console) and API (LT19 Teletypes):
The core to core device (CO) and the device NONE (NO) do not
utilize lOT instructions and do not generate interrupts.

NOTE 3:
SKIP lOT's for each device are listed, whether the device is on
PI or API, for two reasons:
First, if the device is on PI, the
skip lOT's must be placed in the lOT skip chain located in the
Resident Monitor so that interrupts for that device can be detected.
That, however, is insufficient because the Monitor must
then transfer to some core location where the interrupt will be
processed.
Since all but the resident device handlers are loaded
re1ocatab1y from the system's I/O library, the linkage between
the device handler and its interrupt lines must be made after
the handler has been loaded into core. The handler does this by
calling the .SETUP routine in the Resident Monitor. For each
call it passes on two arguments:
a skip lOT and the entry point
address of the routine to service the interrupt.
Figure 8-1 illustrates how the linkage is made.
If the device is
on API, the System Generator ry1aces a JMS* TV instruction in the
channel register for the devic~.
The address, TV, is some
fixed slot in the Monitor's tran3fer vector table.
In the same
relative position as the transfer vector, the System Generator
places the associated skip lOT in a register in the SKIP lOT
table.
If the device is on PI, the skip lOT is placed in the
skip chain (as well as the skip lOT table) and is followed by the
instructions SKP and JMP* TV.
When the .SETUP routine in the Monitor is called, it searches
the skip lOT table for the first argument (the skip lOT) and then
stores the second argument (the address of the entry point of the
interrupt service routine) in the corresponding transfer vector.
Transfer vectors initially contain the address of an error routine
which traps illegal (unserviceable) interrupts.

l~he LT15 Teletype control is equivalent, from a software point of view, to
the LT19.

8-8

NOTE 4:
If a device operates on API, the API channel number (channel
address-40) is given following the skip lOT. If the device
operates on PI, the skip lOT mnemonic is printed, later to be
used to reorder the skip chain.

NOTE 5:
In a DISK system, the system device is DK (instead of DT for
DECtape) .

NOTE 6:
Sometimes more than one skip lOT is listed for a given API channel
because DEC-supplied handlers are written to operate with or
without API.
If two skips must appear in the skip chain, the
handler makes two calls to .SETUP. This sets up two transfer
vectors, only one of which is referenced by the instruction in
the channel register.
8.3.4.1

EXPENDABLE (DELETABLE) DEVICES - Once the mandatory devices have been

(optionally) listed, a check is made to see if any other devices exist.

If not,

the following is typed out:
ALL EXISTING DEVICES ARE MANDATORY
and then processing goes on to Section E.
lf deletable devices exist, the following is typed out:
THE FOLLOWING DEVICES EXIST.

INDICATE (YIN) TO KEEP

Then, for each expendable device, BFSGEN types a 2-letter device mnemonic
followed by a question mark, e.g.,
LP?
The user must then type
NO) to delete it.

(meaning YES) in order to keep the device or ~ (meaning

If YES, then the device parameters are typed out in the same

format as the mandatory devices, e.g.,
LP? Y
API
SKIP lOT

7~65~1

API CHNL

8-9

TRANSFER VECTORS

API CHANNELS

4 I JMS*

DTDFTV

ERR

one or the other

SKIP CHAIN

SKIP lOT TABLE

(skip if DECtape

DTDF
SKP

bTDF

done) / '

JMP* DTDFTV

MONITOR
HANDLER
.INIT ROUTINE

INTERRUPT SERVICE
INTSVC

FIGURE 8-1

JMS*

(. SETUP

DTDF
INTSVC

INTERRUPT LINKAGES FOR I/O DEVICES

8-10

It is possible that a user may want to keep an existing device but change its
parameters (e.g., the skip lOT).

In such a case, the existing device should be

deleted and then reentered as a new device (refer to 8.3.5).
8.3.5

Section E -- Additional I/O Devices
The user is asked if I/O devices are to be added to

Summary:

the system.

If he answers yes, the device name,

skip lOT's,

and skip mnemonics (or API channel

numbers) are requested.
Section E starts with the following typeout:

Operation:

ARE I/O DEVICES TO BE ADDED TO THE SYSTEM?
to which the user must respond !
(for NO).

(for YES) or N

If NO, processing continues at Section F.

If YES, the following instruction is typed:
PROVIDE PARAMETERS AND ANSWER SPECIFIC QUESTIONS
A series of requests are then made to obtain information about each new device.
The requests will include several of the following typeouts:
a.

DEVICE NAME >

NUMBER OF INTERRUPTS SETUP>

API?

SKIP lOT >

APT CHNL >

MNEMONIC >

The requests and
a.

~ypes

of responses required are as follows:

First, the device name is requested.

The user must type a 2-letter

name followed by a carriage return.

The name must be unique; that is,

it must not be identical to that of an existing device.
b.

The number of interrupt lines that will be set up is asked.

This,

(referring to Note 3, Section D)is the number of calls the device
handler(s) will make to the .SETUP routine in the Monitor; this
is also the number of transfer vector table slots which must be
reserved, the number of skips which will appear in the skip
chain (for a PI device) and the number of skip lOT's for which
slots must be reserved in the skip table.

8-11

Specifying zero interrupts setup is legitimate: this indicates
that the device is not interrupt driven,
to-core, device).

(e.g., the CO, core-

If the reply is 0, no more parameters are

requested for such a device.
c.

The user is asked if the device is connected to the API.
reply must be either y) (for YES) or N)

The

(for NO).

A pair of questions are asked pertaining to skip rOT's and are
repeated for as many lOT's as were specified.

The user is first

requested to type in the octal value of the skip lOT instruction.
Six digits are required in the answer and the lOT must be one
not previously used.
e.

The second request, if an API device, is the API channel number
associated with the preceding skip lOT.

The channel number may

be any number from 4 through 37 (octal) but it must not belong
to another existing device.
The same channel number may be used several times for a given
device in order to accommodate device handlers which set up
several skip lOT's and which are written to operate with or
without API l .
f.

The second request, for a PI device, is to type in a mnemonic for
the skip lOT, to be used later if reordering the skip chain.
The mnemonic may be 1 to 6 printing characters and must be unique.
The mnemonic may be preceded by a minus sign to indicate a
negative skip lOT (skip if device flag is not set) and will
result in only a 2-word entry in the skip chain as opposed to
the normal entry of 3 (for a positive skip).

When all the parameters have been entered for a new device, the following
question is typed:
DO YOU WISH TO ADD ANOTHER DEVICE?
If the user replies

(for NO), BFSGEN will go on to Section F. If !

(for YES),

requests for parameters, as above, will be made for another device.

lA hold-over from the PDP-9 where systems without API were supported at one time.

8-12

8.3.6

Section F -- PI Skip Chain
The user is asked if he would like to see or change the

Summary:

skip chain.

If yes, the old skip chain order is typed

out and then the user may retype the skip lOT's in
whatever order he chooses.
Operation:

BFSGEN types the following question:

DO YOU WISH TO SEE OR CHANGE THE SKIP CHAIN ORDER?
If N (for NO), operation proceeds to Section G. I f ! (for YES), the skip lOT
mnemonics are listed in the old order, minus those skips for deleted devices and
with new device skips appended to the end of the list.

Then the user is asked:

DO YOU WISH TO CHANGE THE SKIP CHAIN ORDER?
If ~, operation will continue at Section G.

If!, BFSGEN types:

RETYPE MNEMONICS IN DESIRED ORDER
>

The angle bracket (»
carriage return.

signals the user to type a skip mnemonic followed by a

If he types an ALTMODE instead, the first unused skip in the

old skip chain will be typed out.

BFSGEN will continue to type an angle

bracket until all the skips have been retyped.
8.3.7

Section G -- .IOTAB
Summary:

The user is asked if he wishes to change (or see) the
parameters for I/O device handlers.

These are stored

in the I/O table, .IOTAB, within the Non-resident
Monitor.

If he answers YES, the name of each existing

device is typed out and the user is requested to
provide information about available device handlers.
Operation:

The user is asked:

DO YOU WISH TO CHANGE (OR SEE) I/O HANDLER PARAMETERS?
If N is the reply, processing will continue at Section H. If !, the following
is typed:
ACCEPT OR RETYPE THE FOLLOWING HANDLER PARAMETERS

8-13

Then, for each existing device l

excluding NO (the null dev:lce), CO (core),

TT (Teletype), and the System Device (DT or OK), some of the following information will be typed out for acceptance or revision:
a.

DEVICE -- ZZ
HANDLER NAME(S)

[ZZA,ZZB,ZZC]

DEVICE-SHAREABLE ZZA? [Y]

EXT BUF SIZE [XXXX]

MAX OPEN FILES [XX]

UNIT-SHAREABLE ZZA? [N]

In the preceding list, the characters ZZ represent the 2-letter device name and
XX and XXXX represent octal quantities.
The order of requests and the type of responses required are as follows:
a.

First, the device name is typed out with the existing handler names
enclosed in brackets.

For a new device BFSGEN assumes at first

that there exists an "A" handler.

The user may accept the list

of handlers by typing a carriage return.

Otherwise, he must type

in a new list of names-, each separated by a comma, and terminate
the list by a carriage return.
letters long.
b.

Each handler name must be three

The first two letters must be the device name.

If ZZA, namely, the "A" version of the handler, is present, it is
asked if it is a multi-user (shareable) handler.
enclosed in brackets.

assumption is

The user must either type a carriage return

to confirm the assumption or type Y) (for YES) or r:!}

(for NO).

shareable ZZA handler is one that may be used by both the Foreground
and the Background jobs simultaneously.
c.

If ZZA is shareable, the external buffer size must be specified.
The old value or a default value will be enclosed in brackets.
Typing carriage return signals acceptance. Otherwise, the user must
type in a buffer size (in octal) ranging in value from 0 to 7777.
A zero buffer size is legal because some multi-user handlers may
not require external I/O buffers.

If ZZA is shareable, the open file capacity of the handler must
also be established.

The value may range from I to 77 octal.

For

certain I/O handlers, particularly the ones which do not require
external buffers, this count is meaningless.
at least I must be entered.

8-14

However, a value of

Finally, if ZZA is device-shareable, it is asked if it is also
unit-shareable (with an assumption in brackets).
for example, DEC tape , is unit-shareable.

The system device,

This means that if the

keyboard command $SHARE is typed to the Monitor, Background will be
allowed to assign and use any DECtape units which the Foreground
may be using.

The responses which the user may give are the same

as for the question "DEVICE-SHAREABLE ZZA?"
Once all the device handlers have been specified, the System
Generator will check if the devices MT (MagTape) or LP (Line
Printer) are present.

If so, it will type out a system parameter

related to the device and wait for the user to accept the parameter
or retype it as follows:
DEFAULT MT TRACKS [7]
#LP COLUMNS

[XXX]

The Magtape is assumed to operate either as 7-track or 9-track
so the user may type

'!..1

or 9).

This "default" assumption is

entered in one bit in .SCOM+4 in the Resident Monitor, and that
bit is interrogated by the Magtape handlers in the absence of a
command from the user's program specifying the mode of operation.
The number of columns on the Line Printer can be 80, 120, or 132.
Two bits in .SCOM+4 can be interrogated to determine the above
information.
8.3.8

Section H -- .DAT Slots
Summary:

The user is asked if he would like to change (or see)
the permanent .DAT table assignments for Background
(.DATB) and Foreground (.DATF).

If he answers yes, he

must accept or retype the contents of each reassignable
slot.
Operation:

The following question is typed:

DO YOU WISH TO CHANGE (OR SEE) BGD .DAT SLOTS?
After the Background .DAT table has been disposed of, similar questions will
be posed for the Foreground .DAT table.

If the user answers N (NO) for the

Background table, processing continues with the Foreground table.

If he

doesn't wish to see or modify the Foreground table, operation continues at
8-15

Section I.

In eac:. case, if the answer is Y (YES), the following is typed:

ACCEPT OR

T;l~TYPE

.DAT SLOT CONTENTS

The number and the contents of each .DAT slot will be typed out in the following
form:
-10

[DTA3)

The assignment (DECtape "A" handler-unit 3) is enclosed in brackets to indicate
that it may be accepted or changed.

The assignments in .DAT slots -7, -3,

and -2 will not be enclosed in brackets because reassignment is not permitted.
Typing

carriag~

return indicates acceptance of the assignment.

Otherwise, a new

handler/unit must be typed using the same rules as for the Background/Foreground
Monitor.

For example,
-13

[DTA2)

DT)

(meaning DTA.'J)

-12

[LPA,0]

TTS)

(meaning TTA5)

-11

[DTAl)

CDB)

(meaning CDB~)

[PRA.'Jl

TTA2)

-l.'J

The System Generator will initially assign NONE to Foreground .DAT slots which
refer to the Background control Teletype and vice versa and will reject usertyped assignments of the same nature.
8.3.9

Section I -- Re-write System Information

At this point, all system modifications have been made in core.

BFSGEN thus

informs the user:
SYSTEM INFORMATION BEING WRITTEN
and proceeds to transfer the modifications to the output device.

When this has

been done, the message:
SYSTEM UPDATE COMPLETED
DON'T FORGET POST-GENERATION PROCEDURES
is typed and then the System Generator exits to the Monitor.
8.4

POST-GENERATION PROCEDURES

Once the System Generator has completed its task, the user may need to modify
the new system depending upon his particular hardware configuration:
8-16

50 Cycle Machines
Customers whose hardware operates on a line frequency of 50 Hz
should replace the 60 Hz versions of the subroutines TIME and
TlMElO in the library,

.F4LIB BIN, with the 50 Hz versions .

• F4LIB BIN as well as the 50 Hz versions of TIME BIN and TIMEIO
BIN are on the generated Background/Foreground System.

To do

this, return to the Monitor and assign .DAT slots -10 and -14
to access files from the generated Background/Foreground system.
Also, assign a scratch device to .DAT slot -15 and call in the
system program UPDATE.

When UPDATE is ready for a command, type

the following:
> U +

.F4LIB)

TIME)

> R

TlMElO)

CLOSE (ALTMQDE)

When UPDATE has returned to the Monitor, call in PIP.

Using PIP,

delete the old .F4LIB BIN on the generated system and then transfer to it the new .F4LIB BIN from the scratch device.
Note that the versions of TIME and TlMElO distributed with the
Background/Foreground System will not operate properly in any
other Monitor System nor will the other Monitor versions of TIME
and TlMElO work in Background/Foreground.

This is also true of

the FORTRAN OTS routine called FlOPS, the Background/Foreground
version of which is in the library .F4LIB BIN.
b.

Card Reader
The device handler CDB. BIN which is supplied in the system's I/O
library,

.IOLIB BIN,

has been assembled for the CR03B card

reader using the DEC029 character set.

For customers who wish

to use the DEC026 character set, the source file of the card
reader handler, CDB. SRC, is present both on the Master system
and on the generated system.

The source file may be conditionally

assembled by defining at assembly time the following parameters:
No parameters
DEC026

CR03B and DEC029
CR03B and DEC026

The new binary of the card reader handler should replace the old
one in .lOLIB BIN on the generated tape.
system program UPDATE are as follows:

8-17

The commands to the

Note, the

command is a feature available in UPDATE V6A which

strips the internal symbol definitions from binary files and
thereby shortens the library.

If an earlier version of UPDATE

is used, omit the S in the first command.

The library may be

shortened at some later date.
After UPDATE has created the new I/O library, use PIP, as in
part ~ to replace the old library on the generated system.
c.

Line Printers
The device handler LPA. BIN which is supplied in the system's I/O
library, .IOLIB BIN, is for the LPl5 line printer on the DECtape
and RF/RS disk systems and for the 647 line printer on the RB09
system. The following binary files appear on the system tapes in
case the library does not have the desired handler:
LP.l5 BIN
LP.$49 BIN
LP.647 BIN

(for the LPl5)
(for the LP$49)
(for the 647)

The commands to the system program UPDATE to replace the line
printer handler are equivalent to those shown in section 8.4b
above, with the appropriate line printer handler used in place
of the card reader handler.
d.

The I/O Library
In the process of updating a Background/Foreground System, the
user mqy have deleted some previously existing devices and
device handlers and also added new ones.

Since the System

Generator does not modify the I/O Library, .IOLIB BIN, in the
generated or updated system, the user should use the system
program UPDATE to delete unwanted device handlers and to insert
new ones.
e.

Recouping Tape Space
Provided that the user never modifies the Master of the Background/
Foreground System, space may be retrieved on the system "tape"
by deleting the following files using the Delete command in PIP:
(50 Hz version)
TIME BIN
(50 Hz version)
TIMElO BIN
(Card Reader Handler)
CDB.
SRC
These files are all present on the Master "tape".

8-18

Disk Systems
Once a system generation and update has been performed and a
useable Background/Foreground System has been built onto some
unit on the Disk, that Disk unit should be copied onto a DECtape
(or paper tapes) to provide a backup medium for restoring the
system.

To dump a disk unit onto DECtape, use the Copy command

in PIP:
>C DTx+-DKy (H»)
The paper tape utility program RFSAV 1 may also be used to perform
the same function.
g.

All Systems
To avoid possible grief due to loss or damage of tapes, the user
is urged to copy Master tapes and generated tapes to be kept as
backups.

8.5

ERROR DETECTION

The System Generator is a locative program, and any mistakes made by the user in
answering queries will result in a descriptive error message.

The incorrect

answer will be ignored and the question will be repeated.
Within the System Generator there is a safeguard function which should never be
noticed by the user.

If a malfunction is detected, which could be the result

of a bad system tape or of a programming bug in the System Generator itself, the
following will be printed on the console Teletype:
SYSTEM CRASH
PLEASE to &
SAVE TTY LOG
nnnnnn
000000

pppppp
If such a message should occur, the user is requested to perform a dump of core
memory by executing a CTRL a
purposes.

(to).

The dump can then be printed for diagnostic

The TTY Log is simply the entire printout that led to the error.

six-digit octal numbers that are printed in the preceding message are:
nnnnnn

unrelocated address within BFSGEN where the error
was detected.

000000

runtime (relocated) address within BFSGEN where the
error was detected. Bits ~-2 indicate the state of
the Link, Page/Bank Mode, and Memory Protect.

pppppp

the contents of the accumulator when the error was
detected.

This information would be an aid in tracking down the cause of the error.
lSee PDP-IS utility Programs Manual, DEC-15-YWZA-D
8-19

The

APPENDIX I
.SCOM REGISTERS

The function of the .SCOM (~ystem COMmunication) Registers is to provide, among
the various program elements of the Background/Foregrounq Monitor System, an
easily accessible set of registers which contain communication pointers, data
words, and program flags indicating the state of the system.
The .SCOM table begins at location

1~~8

within the Resident Monitor.

Location

l~~ is referred to as .SCOM or .SCOM+~ and theW+~th register is referred to
as .SCOM+N.
Each .SCOM register has a special meaning and format.

At present, there are

1178 such registers.
as needed.

Slots at the end will be allotted for future expansion

The following list indicates the contents of each .SCOM

Those which are fixed at assembly or system generation time and

never changed are marked by (F).
value and a Background value.

Some .SCOM registers must have a Foreground

Therefore, their contents must be swapped from

one to the other, depending upon which job has control.
(S).

Some .SCOM registers have been

They are flagged by

reserved for future software.

If their

contents (format) are as yet unspecified, they will be flagged with (U).
.SCOM + ~

(F)

Pointer to the highest register in core
(37777, 57777, or 77777). This value is
established from the location of the
bootstrap loader the first time the system
is loaded.

.SCOM + 1

(S)

(a)
Address just above the Resident Monitor
when the Non-resident Monitor has been loaded
for Foreground.
(b)
Address just above the Foreground job
when the Resident Monitor has loaded the Nonresident Monitor in the Background.
If the
system program PIP is called, this will be
the first location of its .DEV table.
(c)
For DDT in the Background this points
to the start of its symbol table.

.SCOM + 2

(S)

(a)

Same as (a)

for .SCOM + 1.

(b)
Normally used by user and system programs
to indicate the first (lowest) location in
free core.
(cl

For DDT in the Background this points to

the first location after the symbol table,
which is also the first location of free core.
I-I

.SCOM + 3

(S)

Normally used by user and system programs
to indicate the last (highest) location in
free core. For the Foreground, this is also
the highest location allocated to the Foreground job.

.SCOM + 4

(S)

Bits indicate machine configuration:

(F)

Bit ~
Bit 11
Bits 2-5
Bit 6 2

(F)

(S)

Bit 7

(F)
(U)
(F)
(F)

Bit 8
Bit 9

(F)
(F)

Bit 14
Bits 15-17

.SCOM + 5

Bits 1~-11
Bits 12-13

~=NO API;
l=API
~=No EAE;
l=EAE
~
(Reserved and unused)
~ = 7-channe1 MAGtape

1 = 9-channel MAGtape
Mode Addressing
l=Page Mode Addressing
1 = no tQ area on system tape unit ~
Unassigned
~
(Reserved and unused)
~
No Line Printer
1
8~ column printer
2 = 12~ column printer
3
132 column printer
1
Background/Foreground System
~
(Reserved and unused)
~=Bank

(a)
Initially this points to RESINT, the
address of the initialization section in
RESMON. The paper tape bootstrac loader
transfers control indirectly through this
location.
(b) When calling the System Loader to
bring in a system program, the Non-resident
Monitor stores here the code number of the
program to be loaded.
(c) When running a system program, its
start address is stored here.

.SCOM + 6

(a) When the Non-resident Monitor calls
the System Loader to load user programs,
bits ~ - 2 indicate which command was
given to the Monitor:
$LOAD, $GLOAD, $DDT, or $DDTNS.
Bit ~
1 if $DDT or $DDTNS (DDT load)
Bit 1 = ~ if $LOAD: Bit 1 = 1 if $GLOAD
Bit 2 = ~ if $DDT; Bit 2 = 1 if $DDTNS
(b) When the user programs have been loaded,
the start address of the main program is
stored here. The load command code bits
(~ - 2) remain as in (a).

.SCOM + 7

The interrupted PC plus L,P/B,MP are saved
here for DDT in the Background when CTRL T
has been typed •

. SCOM + l~

(S)

The interrupted PC plus L,P/B,MP are saved
here after a NORMAL CTRL P has been typed
and honored.

.SCOM + 11

(F)

Bootstrap restart instruction.

•seOM + 12

(F)

(Reserved for PDP-9 use) .

IThe presence or lack of EAE is determined dynamically by the Resident Monitor.
27/9-channel default operation may be set by Foreground Keyboard command.
I-2

.SCOM + 13

(F)

Pointer to the .IOIN 1 table in the Resident
Monitor.

.SCOM + 14

(F)

Pointer to the .MUD 2 table in the Resident
Monitor.

.SCOM + 15

(F)

Pointer to the .BFTAB 3 table in RESMON.

.SCOM + 16

(F)

Pointer to .DATF~, Foreground .DAT slot {J
in the Resident Monitor.

.SCOM + 17

(F)

Pointer to .DATB~, Background .DAT slot {J
in the Resident Monitor.

.SCOM + 2{J

(F)

{J indicates that the computer does not
have an extra 4K page segment (which rules out
20K and 28K).

.SCOM + 21

(F)

Default value of $FCORE (Foreground free core)
established at system generation.

.SCOM + 22

Reserved for MAGtape handler

.SCOM + 23

(F)

TWo's complement size of the Monitor's transfer
vector table (used by System Generator) .

.SCOM + 24

(F)

Pointer to the Monitor's transfer vector table
(used by System Generator) .

.SCOM + 25

(a)
Prior to loading the Foreground job,
the amount of free core requested by the $FCORE
command is stored here. If no $FCORE command
is given, the default assumption is taken from
.SCOM + 21.
(b) After the Foreground job has been loaded,
this register contains a pointer to the register
immediately above the Foreground cote area.

.SCOM + 26

(S)

Contains {J if Foreground is in control and 1
if Background is in control.

.SCOM + 27

(F)

Pointer to lOT Skip literal table in the
Monitor (used by System Generator) •

.SCOM + 3{J

(F)

Pointer to PI Skip Chain.

".IOIN is the table which indicates which I/O devices are in core, which units on
each device are spoken for, and which job (Background or Foreground) owns them.
2. MUD is a table
listing all available multi-user device handlers, with
pertinent information about those handlers.

3. BFTAB is a buffer table containing pointers to and the sizes of all external
I/O buffers that were set up QY the loaders.

\ D:AT.F is the Device Assignment Table for Foreground .
• DATB is the Device ~ssignment Table for ~ackground.

1-3

.scm~

+ 31

Software Memory Protect Bound
(a) Set from .SCOM + 25 after the System
Loader has loaded the Foreground job.
(b)
Set to point just above the Background
I/O handlers and I/O buffers after the Background job has been loaded.

.SCOM + 32

(a) Pointer to the Hardware Memory Protect
Bound (or where it should be set). Contents
(SCOM + 32)~ contents (.SCOM + 31).

. SCOM + 33

Background Program Counter, including L,P/B,MP •

• SCOM + 34

(F)

Address of the resident Teletype handler (TTA) •
Interrupt Service Flag. Non-~ indicates that
control is in some interrupt service routine.

.SCOM + 35
.SCOM + 36

(F)

Bits to tell the Teletype handler which units
are model 33 (specific bit = ~) and which
model 35 (specific bit = 1). Bit ~ corresponds
to unit ~, bit 1 to unit 1; etc.

.SCOM "" 37

(F)

Pointer to CALER. Used to detect attempt
to re~enter CAL handler and to trap CAL*
instructions.

.SCOM + 4~

CAL flag. Non-~ if control is in the CAL
handler (indication necessary for interrupt
servicing) •

• SCOM + 41

"Who's running in the Background" Flag.
Bit ~ = 1 if a Loader is running.
Bits 1-17:
17777 = Non-resident Monitor
~ = user program or DDT
1 = EDIT
2 = MACRO
3 = PIP
4
F4
5 = SRCCOM
6 = DUMP
7
UPDATE
unused
l~
11 = MACROA
12 = F4A
EXECUTE
13
14 = CHr.~N
15
PATCH
DTCOPY
16

• SCOM + 42

LevelS (API,Foreground) busy register •
Zero indicates levelS non-busy. Non-Zero
indicates that Foreground level 5 is idle
waiting for some I/O to complete. Set non-~
with the initial address of the device handler
doing the I/O. If the device is Teletype,
the unit number + 4~999~ is stored here instead.

. SCOM + 43

Same as .SCOM + 42 for Foreground level 6 •

• SCOM + 44

Same as .SCOM + 42 for Foreground level 7 •

1-4

.SCOM + 45

Same as .SCOM + 42 for Foreground Mainstream
level.

.SCOM + 46

Foreground level 5 I/O satisfied flag.
Zero indicates that level 5, which was I/O
bound, can be started up again.

.SCOM + 47

Same as .SCOM + 46 for level 6.

.SCOM + 5~

Same as .SCOM + 46 for level 7.

.SCOM + 51

(F)

Pointer to REALTP 1 in the Resident Monitor.

.SCOM + 52

(F)

Pointer to IOBUSy 2 in the Resident Monitor.

.SCOM + 53

(F)

Pointer to LV4Q3 in the Resident Monitor.

.SCOM + 54

(F)

Pointer to CALL4"

.SCOM + 55

(F)

Pointer to • SETUP 5 in the Resident Monitor.

.SCOM + 56

(F)

Pointer to GETBUF 6 in the Resident Monitor.

in the Resident Monitor.

.SCOM + 57

If non-~, a pointer to the entry point of
the last Mainstream Foreground real-time
subroutine in the chain of subroutines to
be run when Foreground Mainstream gets control.

.SCOM + 6~

Pointer to the entry point +1 of the first
subroutine in the chain of Foreground Mainstream real-time routines to be run when
Foreground Mainstream gets control.

. SCOM + 61

Same as .SCOM + 57 for Background •

. SCOM + 62

Same as .SCOM + 6~ for Background •

.SCOM + 63

Argument for API instruction ISA when interrupts
at API software levels are to be requested.

.SCOM + 64

(F)

Pointer to CR.QR 7 in the Resident Monitor.

lREALTP is a subroutine to process real-time requests.
2IOBUSY is a subroutine to check for I/O busy termination.
3 LV4Q queue is a list of I/O handlers which are waiting to complete their
interrupt service processing at API level 4.
"CALL4 is a subroutine to initiate an API level 4 request.
;SETUP is the routine initially called by all I/O handlers to set up skips in
the PI skip chain or API channel registers.
6GETBUF is a routine called by the I/O handlers Which assigns buffer areas
to the handlers via .BFTAB.
7 CR . QR is a routine called by I/O handlers to initiate a device-not-ready
request.

1-5

.SCOM + 65

Set non-~, while a Foreground user program is
running, to indicate that the resident buffer
may not be used by the Foreground. The resident
buffer must be available to the Background,
which presumably changes jobs more often, for
use by the Monitor and the Loaders.

.SCOM + 66

(F)

Pointer to ERRORQl in the Resident Monitor.

.SCOM + 67

(F)

Pointer to Foreground control character table
in TTA •

. SCOM +

(F)

Pointer to Background control character table
in TTA .

. SCOM + 71

Error flag.
The following conditions exist
if the respective bit = 1:
~ - Background error
1 - Foreground error
2 - Background terminal error
3 - Foreground terminal error

.SCOM + 72

(F)

Pointer to the Foreground error processing
subroutine plus the 2~~~~~ bit to enter bank
mode.

.SCOM + 73

(F)

Same as .SCOM + 72 for Background error
subroutine •

. SCOM + 74

Saved argument for Foreground error routine
ISA instruction.

.SCOM + 75

(F)

Contains JMS IGNORE, a call to a dummy interrupt service routine, used during error processing.

.SCOM + 76

(F)

Two's complement count of the number of Teletypes
on the machine.

.SCOM + 77

.SCOM +

l~~

$SHARE Flag (to allow Background to share
Foreground I/O bulk storage units). Non-zero
indicates that SHARING is allowed. Initial
value is set at System Generation.
(F)

Pointer to ENTERQ2 in the Resident Monitor.
Will contain ~, instead, if ENTERQ routine
not assembled into the Monitor.

lERRvRQ is a routine called to enter information in the Foreground and/or
Background error queues and to set the error flags in .SCOM + 71.
2ENTERQ is a subroutine which makes entries in the API queue.

I-6

.SCOM + I,m

If set non-zero by the Foreground keyboard
command, $MPOFF, Background enters EXEC mode.
The memory protect boundary register is
zeroed to allow Background to modify and
transfer to any location in core. Background
IOT's will still trap to the Monitor but the
IOT's will be executed.

.SCOM + 1~2

(F)

Argument for ISA instructions which will raise
either to API level ~ or level 1 (as the
highest used Monitor level) to protect common
Monitor routines from being reentered. Value
established at System Generation •

• SCOM + 1~3

(F)

Monitor version number. For FKM15 V3A printout,
for example, this register will contain:
.ASCII "3A".

.SCOM + 1~4

(F)

Flag to indicate which job (~ = Foreground;
1 = Background) confirms Foreground CTRL C
see Section 3.4).

.SCOM + 1~5

(F)

Two's complement size of the PI ship chain.
(Used by System Generator) •

.SCOM + 1~6

(F)

Pointer to the register immediately above
the Resident Monitor (set by the Non-resident
Monitor after it has built the .MUD table).
(Used by CHAIN program.)

.SCOM + 107
.SCOM + 11~
.SCOM + III

Used to store the file directory entry
block of the XCT file to be EXECUTEd in
the Foreground.

.SCOM + 112
.SCOM + 113
.SCOM + 114

Used to store the file directory entry block
of the XCT file to be EXECUTEd in the
Background.

.SCOM + 115

(F)

Maximum number of Teletypes allowed, which
is a function of an assembly parameter in
the Monitor (Used by System Generator) •

• SCOM + 116

Foreground MAGtape status •

• SCOM + 117

Background MAGtape status .

I-7

APPENDIX II
ERRORS

ERROR HANDLING IN BACKGROUND/FOREGROUND
The processing of errors detected by the Resident Monitor, I/O handlers, the
Linking Loader, and the System Loader in the Background/Foreground System has
been changed from the manner of error processing in the ADVANCED and I/O Monitor
Systems.
The most significant change is the introduction of terminal and non-terminal
errors.

A terminal error stops execution of the job associated with the error.

This causes all I/O handlers assigned to that job to be called to stop I/O that
may be in progress and all Monitor queues to be cleared of entries for that job
(Background, Foreground, or both) .
A non-terminal error does not necessarily warrant aborting the operation of the
offending job.

A non-terminal error message is entered into a queue for the

appropriate job and is printed on the appropriate control Teletype when that
unit is free.

While the printing of non-terminal error messages is pending or

in progress, operation of the offending job is suspended.

This restriction does

not apply to I/O handlers, which may continue interrupt processing.
The format for error messages generated by the Resident Monitor, I/O handlers,
and the Loaders is:
.ERR

NNN

XXXXXX

where NNN = error code
XXXXXX = auxiliary information
These errors are tabulated on pages 11-3, -4, and -5.
Errors detected by the FORTRAN Object Time System (OTS) are formatted as follows:
OTS NN
where NN

error code.

OTS errors are listed on page 11-6.

11-1

CONTINUATION AFTER ERROR
All .OTS errors, except 7 and IS (see list on page 1I-6), are terminal errors.
After OTS has printed the error message, it exits to the Monitor. Therefore, after
a terminal .OTS error the user does not have the option of restarting his program.
Terminal .ERR errors terminate the operation of user programs. After the printing of the error message, the user has the option of typing CTRL P (to restart
his program at the CTRL P restart address), CTRL T (to return to DDT), CTRL Q (to
take a dump of memory), or CTRL C (to return to the Monitor to load another job).
If the error occurs while control is in the Non-resident Monitor or in a Loader,
the user does not have the options indicated above. The Monitor will automatically
be reloaded.
Non-terminal .ERR errors do not terminate the operation of user programs.
tinuation, following the printing of the error message, is automatic.

Con-

ERROR CALL
Routines that wish to set up an error condition, I/O device handlers for
example, should use the following coding sequence:
LAC *
DAC
LAC *
ISA
LAW
JMS*
AUXARG XX
DBK

( .SCOM+66
TEMP
(.SCOM+l,02

/POINTER TO ERRORQ
/SUBROUTINE.
/RAISE TO API
/LEVEL {J (OR 1) .1

CODE
TEMP

/SEE BELOW.
/CALL ERRORQ.
/AUXILIARY ARGUMENT.
/RETURN HERE:

The calling program must be operating with memory protect disabled in order to
be able to issue lOT's.
The first argument, given in the AC to ERRORQ, may be loaded either by LAW code
or by LAC (code in the following format:

Code

Bits {J-S are ignored
Bit 6 = .0 means non-terminal error
Bit 6 = 1 means terminal error
Bit 7 = 1 means Background error
Bit 8 = 1 means Foreground error
Bits 9-17 is a 3-digit error code

Both bits (7 and 8)
may be set to 1

I For a routine that operates at API level 1 or {J, read the discussion on
Reentrancy Protection, 7.4.

1I-2

To avoid the possibility of future conflicts, user programs and device handlers
should utilize codes

6~~

- 777.

The auxiliary argument, following the JMS to ERRORQ, will be printed in the error
message as a 6-digit octal number.
.ERR

NNN

The error message will be printed in the form:

XXXXXX

where NNN = the 3 digit error code
XXXXXX = the 6-digit auxiliary information
The actual printing of the error message and processing of the error will be
done only after all interrupt processing has ceased and when control is no longer

in the CAL handler.
BACKGROUND/FOREGROUND MONITOR ERRORS (.ERR)
The following abbreviations are used below in describing the auxiliary information:
L - bit ~ is the status of the link
PB - bit 1 is the status of page/bank addressing mode
MP - bit 2 is the status of memory protect
CAL ADDR - bits 3-17 contain the address of the CAL in error.
ERROR NO.

ERROR

AUXILIARY
INFORMATION

TERMINAL

~~~

ILLEGAL CAL FUNCTION

YES

~~l

CAL * ILLEGAL

L, PB, MP, CAL ADDR
L, PB, MP, CAL ADDRI

~~2

.DAT SLOT ERROR
(erroneous .DAT slot
number or .DAT slot not
tied to an I/O handler)

L, PB, MP, CAL ADDR

YES

~~3

ILLEGAL INTERRUPT

L, PB, MP, PC

YES

~~4