AC F053C MC_X11Usr Man Apr82 MC X11Usr
AC-F053C-MC_X11UsrManApr82 AC-F053C-MC_X11UsrManApr82
User Manual: AC-F053C-MC_X11UsrManApr82
Open the PDF directly: View PDF 
.
Page Count: 142
| Download | |
| Open PDF In Browser | View PDF |
Page 1
IDENTIFICATION
-------------'PRODUCT CODE:
AC-F053C-MC
PRODUCT NAME:
CXQUACO DEC/XII USER'S MANUAL
PRODUCT DATE:
APRIL 1982
MAINTAINER:
DEC/XII Support Group
AUTHOR:
D. Butenhof
THE INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE
WITHOUT NOTICE AND SHOULD NOT BE CONSTRUED AS A COMMITMENT
BY DIGITAL EQUIPMENT
CORPORATION.
DIGITAL
EQUIPMENT
CORPORATION ASSUMES NO RESPONSIBILITY FOR ANY ERRORS THAT
MAY APPEAR IN THIS MANUAL.
THE SOFTWARE DESCRIBED IN THIS DOCUMENT IS FURNISHED TO THE
PURCHASER UNDER A LICENSE FOR USE ON A SINGLE COMPUTER
SYSTEM AND CAN BE COPIED (WITH INCLUSION OF DIGITALS
COPYRIGHT NOTICE) ONLY FOR .USE IN SUCH SYSTEM, EXCEPT AS MAY
OTHERWISE BE PROVIDED IN WRITING BY DIGITAL.
DIGITAL EQUIPMENT CORPORATION ASSUMES NO RESPONSIBILITY FOR
THE USE OR RELIABILITY OF ITS SOFTWARE ON EQUIPMENT THAT IS
NOT SUPPLIED BY DIGITAL.
COPYRIGHT (C)
1973,1982 DIGITAL EQUIPMENT CORPORATION
Page 2
~6
PREFACE. . • • . • . • • • . . • • . . • • • . • . . • • • • • . • • • • . . • . • • . . . . . • • . • • • . •
CHAPTER 1..................................................
1.1 DEC/XII SYSTEM EXERCISER MONITOR ..••••.••..••••••••
1.1.1 System Exerciser Programs.....................
1.1.2 New DEC/XII Monitor •••.•.•••.••••.....•..•••••
1.1.3 New DEC/XII RTE Programs •••••••••••..••.••••••
1 • 2 REFERENCE DOCUMENTS................................
CHAPTER
2.0 DEC/XII SYSTEM OVERVIEW •••••••••••••.••••••••••••••
2.1 Option/Device Modules ••••••••••••••••••••••••••••••
2.1.1 Background Module (BKMOD) •••••••••••••••••••••
2.1.2 Special Background Module (SBKMOD) ••••••••••.•
2.1.3 Non-Restartable Background Module (NBKMOD) ••.•
2.1.4 I/O Module (IOMOD) •.••••.•••.•..•.....••••••••
2.1.5 I/O Module Restricted (IOMODR) ........••.•••.•
2.1.6 I/O Module Extended (IOMODX) ..•.......•..•••.•
2.1.7
I/O Module Partially Restricted (IOMOD?) ..••.•
2.2 DEC/XII Monitors .•••.••••......•...........•.••••.•
2.2.1 System Initialization ....•................•...
2.2.2 Operator Interfacing ......................•...
2.2.3 Option Module Control .........................
2.2.3.1 Priority Scheduling ......................
2.2.3.2 Module Communications ....................
2.2.4 Memory Usage Control ..........................
2.2.4.1 Memory Options Control ...................
2.2.4.2 Write Buffer Control .............•.......
2.2.4.3 Exerciser Relocation .................•...
2.2.4.4 Memory-Worst-Case-Pattern Generation .....
2.2.5 Trap Processlng ...•.......................•...
2.3 Configurator/Linker Program .....................•..
2.3.1 The Configuration Process .....................
2.3.2 The Linking Process ......................••...
2.4 DEC/XII Distribution ...............................
CHAPTER 3..................................................
3 . 1 GENERAL I NFORMAT I ON . . . . . . . . . . . . • . . . . . . . . . . . . . . • . . . .
3 . 2 EXERC I SER BU I LD PROCEDURES.........................
3.2.1 Procedural Guide ...•..........................
3.2.2 Pre-Build Planning ................•...........
3.2.3 Build Requirements ............................
3.2.3.1 Required Hardware ...•....................
3.2.3.2 Required Software ........................
3.2.3.3 Required Documentation ...................
3.2.4 Configurator/Linker Programs..................
3.2.4.1 Load and Start Procedures................
3.2.4.1.1 Loading Via Absolute Loader .........
3.2.4.1.2 Loading Via XXDP+ Monitor ...........
3.2.4.1.3 Starting Procedures .................
3.2.4.2 Operating Procedures .....................
3.2.4.2.1 Configure ,Mode Commands .............
3.2.4.2.2 Linking Process Command ........•....
3.2.4.2.3 I/O Control Commands ....•...•...••..
3.2.4.2.4 General Utility Command .....•....•..
3.2.4.2.5 Command Error Messages ..•.....••..•.
3s2.5 Generating A Run-Time Exerciser Module ••.••...
3.2.5.1 The Configuration Table (C-Table) •••••..•
5
6
7
7
7
7
9
2.................................................. 10
12
14
14
15
16
16
16
16
17
17
18
19
22
22
23
30
30
31
34
36
36
38
39
39
39
40
42
42
42
43
46
46
47
48
48
52
52
52
52
53
58
65
69
76
78
82
82
76
Page 3
3.2.5.2 The Linking Process (LINK Command) •••••••
3.2.3.3 The Run-Time Exerciser (RTE) •••••••••••••
3.3 RUN-TIME EXERCISER PROCEDURES •.••••••••••••••••••••
3.3.1 Hardware And Software Requirements ••••••••••••
3.3.2 Load And Start Procedures .• ·•••••••••••••••••••
3.3.2.1 Load/Start Via Absolute Loader ••••••••.••
3.3.2.2 Loading Via XXDP+ Monitor ••••••••••••••••
3.3.2.3 Starting Via XXDP+ Monitor •••••.•••.••••.
3e3e3 Operating Procedures ••.•••••••••••••.•••••••••
3.3.3.1 Switch Register Options ••••••••••••••••••
3.3.3.2 Keyboard Commands........................
3.3.3.2.1 Keyboard Character Usage ••••••••••••
3.3.3.2.2 Keyboard Error Messages .....•••••.••
3.3.3.2.3 Keyboard Command Analysis ..•••••••••
3.3.3.3 Operator Modifications...................
3.3.3.3.1 Monitor Modifications ••..•.••••••••.
3.3.3.3.2 Option Module Modifications .••.••.•.
3.3.3.4 Message Print-Outs •..•••.••..•....•••••••
3.3.3.4.1 Normal Run-Time Messages •...•.•.•••.
3.3.3.4.2 RTE Run-Time -Error Messages.........
3.3.3.4.3 Debug Recommendations ..•.•..•...•...
APPEND I X A.................................................
83
85
85
85
86
87
87
89
89
90
93
93
94
96
131
131
131
133
133
136
142
145
Page 4
76
PREFACE
Scope and Purpose
The 'material in this manual is arranged to initially provide the
reader with an introduction to the new DEC/XII System Exerciser. This
is followed by an overview of the system and procedural information
pertaining to both the loading and control of the software, in
relation to the generation of user-designed Run-Time Exerciser (RTE)
programs.
The manual concludes with separate detailed procedures for
both loading and controlling the user-designed programs.
The information is formally arranged as follows:
Chapter 1 provides an introduction to the new DEC/XII monitor
in
regard to general improvements in both design and
functionality.
Chapter 2 provides an overview of the entire DEC/XII
defining the various software elements.
system,
Chapter 3 provides the user with all of the procedural
information required to load, start, and operate the DEC/XII
RTE build programs and the resultant user-designed RTE
modules.
APPENDIX A provides the user with a sample build from
pre-build
planning through the actual build under the
Configurator/Linker program.
Page 5
76
CHAPTER 1
INTRODUCTION
1.1
DEC/XII SYSTEM EXERCISER MONITOR
1.1.1
System Exerciser Programs
1.1.2
New DEC/XII Monitor
1. 1. 3
New DEC/XII RTE Programs
1.2
REFERENCE DOCuMENTS
76
1.1
Page 6
DEC/XII SYSTEM EXERCISER MONITOR
Run-Time Exerciser (RTE) programs provide confidence and reliability
testing for PDP-II hardware by generally providing for the detection,
as opposed to the isolation, of a wide range of hardware problems.
There are three classes of exerciser program:
subsystem exercisers,
unit
exercisers,
and
system
interaction
exercisers.
System
interaction exercisers are the most complex, and the main concern of
thlS manual, since they are both designed and generated using DEC/XII
software.
1.1.1
System Exerciser Programs
System interaction exerciser programs drive associated systems at
maXImum activity rates in order to provoke noise, timing, and logical
interaction failures. The programs exercise systems hardware at the
limits of design in order to ensure reliability. Such programs
require a high degree of parameterization and operator interaction and
are generally large in both size and scope although problem isolation
and fault resolution only occur at a subsystem level.
The system activity stress provided by this class of exerciser
program, as opposed to normal customer usage, makes these programs
ideally suited for (I) prototype acceptance testing, (2) customer
installation
testing,
and (3) preventive and corrective field
maintenance usage.
1.1.2
New DEC/XII Monitor
The new DEC/XII Monitor-is a modularized program which incorporates
both structured design and programming techniques. The nature of this
design enhances maintainability by providing extensive documentation,
at
a
modular level, as an inherent by-product of structured
programming and simplification of flow as a by-product of top-down
implementation.
As a result, the new DEC/XII software lends itself
more readily to the support of future hardware options and/or
enhancements.
1.1.3
New DEC/XII RTE Programs
Run-time system exerciser programs, created via the new DEC/XII
software, are a combination of user selected DEC/XII monitor modules
and exerciser option modules. Enhancements to the monitor portions of
the final programs improve both the operation and control of the RTEs
in the following areas.
Operator/user interface
Page 7
76
System interactions
Management of memory
Error reporting and recovery
Operator/User Interface
The operator/user interface has been improved to provide:
1.
Increased Console Interaction:
Many of the keyboard commands and control characters may now
be entered dynamically as well as statically, i.e., in Busy
Mode (BSY» as well as Command Mode (CMD».
2.
Increased Operator Control:
An expanded set of keyboard commands and control characters
now provides increased report generation capabilities (e.g.,
summaries of module header information), access to user
specified locations, and expanded editing abilities.
System Interactions
Improved system interaction and, as a by-product, increased throughput
has been achieved as follows:
1.
By asynchronous-parallel processing of:
Keyboard input and command decoding: where interrupt
servicing, and decoding, will occur as fast as the
operator can enter the input.
Message dequeuing and terminal output: where processing
and printout will occur as fast as the terminal device can
accept the data.
Job scheduling and multiprogramming: where option
and monitor module processes are serviced on a First-In
First-Out (FIFO) basis.
2.
By an increased degree of mUltiprogramming:
Made possible by minimizing the amount of overhead required
to service the option modules (Control Queue) and console
device (Type Queue), thus increasing the amount of CPU time
available to run option modules.
Page 8
Management of Memory
Memory management has been improved in the following areas:
1.
Advanced Memory Utilization:
Through the use of optional keyboard commands, the
operator may initiate a systematic relocation of the
exerciser program through all of memory.
Through the use of optional bit settings in the Software
Switch Register, the operator may inititate sequential
movement of the exerciser program through memory.
2.
Write Buffer Control:
Rotation of the write buffer, through the l24K bank of
memory in which the exerciser currently resides, is both
continous and contiguous.
Periodically, worst-case UNIBUS data patterns are written
into all of the memory space not currently occupied by the
exerciser program.
Error Reporting and Recovery
Error reporting and recovery have been improved in the following ways:
A run summary now lists both hard and soft
within a module.
errors
occurring
If a system error is caused by an option module, the name of
the module is now listed along with the offset value of the
Program Counter.
1.2
REFERENCE DOCUMENTS
The following reference documents are currently available:
DEC/XII USER'S MANUAL (MD-ZZ-CXQUA)
DEC/XII CROSS REFERENCE MANUAL (MD-ZZ-CXQUB)
XXDP+ USER'S MANUAL (MD-ZZ-CHQUS)
DEC/XII REFERENCE CARD
76
Page 9
CHAPTER 2
GENERAL DESCRIPTION
2.
DEC/XII SYSTEM OVERVIEW
2.1
Option/Device Modules
2.1.1
Background Module (BKMOD)
2.1.2
Non-Restartable Background Module (NBKMOD)
2.1.3
Special Background Module (SBKMOO)
2 •1 •4
I/O Module (rOMOD)
2.1.5
I/O Module Restricted (IOMOOR)
2.1.6
I/O Module Extended (IOMOOX)
2.1.7
I/O Module Partially Restricted (IOMODP)
2.2
DEC/XII Monitors
2.2.1
System Initialization
2. 2. 2
Operator Interfacing
2.2.3
Option Module Control
2.2.3.1
Priority
2.2.3.2
Module Communications
2.2.4
Memory Usage Control
2.2.4.1
Memory Options Control
2.2.4.2
Write Buffer Control
2.2.4.3
Exerciser Relocation
2.2.4.4
Memory-Worst Case Pattern Generation
2. 2.
Trap processing
2.3
Configurator/Linker Program
2.3.1
The Configuration Process
Scheduli~g
Page 10
76
2.3.2
The Linking Process
2.4
DEC/XII Distribution
76
2.0
Page 11
DEC/XII SYSTEM OVERVIEW
DEC/XII system software 1S used to create independent Run-Time
Exerciser (RTE) programs from monitor and device/option modules that
are selected by the user from the DEC/XII CROSS REFERENCE MANUAL.
In Figure 2-1, an overview of the basic DEC/XII system is depicted,
along with a general representation of the layout of a typical RTE
program. The DEC/XII system consists of three fundamental parts:
DEC/XII Monitor Library
DEC/XII Device/Option Test Modules
DEC/XII Configurator/Linker Programs
From these the user selects a particular monitor, required test
modules, and an applicable configurator/linker program in order to
generate an RTE program for a particular hardware system.
Once the
RTE program is linked, it may be independently loaded via a standard
ABS loader or an XXDP+ Monitor, depending on whether the load module
is
contained
on
paper tape or on a non-paper tape medium,
respectively.
Whenever an RTE program is loaded into memory, an unrelocatable
portion of the monitor always resides in the lowest 4K of memory. The
area directly above may then contain a maximum of 39 test modules plus
the remaining portion of the monitor (if the standard linker is used)
or 19 test modules plus the remaining portion of the monitor (if the
short linker is used). In either case, the remaining free memory area
satisfies the need for write buffer space and monitor/test module
relocation.
Page 12
76
/IDEC/XII !
!MONITORS!\
!---I \
MONITOR /
!---I
LIBRARY-!---I
!---I
\
!---I /
\ !---II
/
\!-1--
DEC/XII
-->! CONFIG/LINKER
--1
--!
!
!-->
PROGRAM
DEC/XII
RUN-TIME
EXERCISER
(LOAD
MODULE)
!
DEC/XII
!
!OPTION/DEVICE !
! TEST MODULES !\
!--------------!
!-!-!-!--
--I
--I
--I
1
--!
--II
SYSTEM OVERVIEW
WRITE
BUFFER
AREA
!-------------------!
/!---I
/!
OPTION/DEVICE
!
!-TEST
--I
MODULES
*39/19----!
MAX.
,---I
!
-------------------!
MONITOR!
-------------------!\
*39 for Standard Linker
19 for Short Linker
\
MONITOR
! !
(NON-RELOCATABLE)! -----Lowest 4K
\---------------------/
RTE PROGRAM
FIG. 2-1 DEC/XII SYSTEM OVERVIEW
76
2.1
Page 13
Option/Device Modules
Each option/de~ice module is a program, that is dedicated to the
testing of a single option or device-controller within the confines of
a system configuration. Thus, unlike a stand-alone diagnostic program
that is used to isolate a static problem within an individual device,
a system exerciser module is used to isolate an individual device only
as it relates to a system problem.
In fact, prior to running a
collective group of exerciser modules for a given system, it is
preswued that stand-alone diagnostics have been individually, and
successfully, run for each device.
Each option/device module communicates with its resident monitor via
software hooks that are contained in both the body of each module and
a module's header-statement. In addition, there are seven basic types
into
which
all
modules
are grouped.
With this arrangement
(interfacing with the monitor by type) a module may gain access to
those support and/or utility routines that the monitor provides and
the module requires.
The following subsections describe the seven
currently available and the purpose of each.
2.1.1
basic
module
types
Background Module (BKMOD)
The BKMOD-type only runs-in a background mode (i.e.~ via non-interrupt
driven devices) and at the lowest module run-time priority. A module
of this type is used to exercise non-interrupt hardware options or
functions.
Examples of BKMon usage are:
Exercising a floating point hardware option.
(Module FPA)
Testing the basic PDP-ll Instruction Set.
In addition, all modules of this type are run separately and
consecutively.
When relocation occurs, a pointer to the next module
to be run ensures that although all the modules may not be run in each
bank, they will be run consecutively.
NOTE
When the "RUN" command is entered or
after relocation' BKMODS will do a 1
iteration pass by taking on the identity
of a TMPIO (Temporary rOMOD). This is
done to insure BKMODs are run in a high
I/O activity system.
76
2.1.2
Page 14
Special Background Module (SBKMOO)
, The SBKMOD-type-module only runs in a background mode and is the first
type of module to be run (i.e., before any resident NBKMOD). Once
this module is initially run, it will, following every relocation, be
run once again. The latter allows the special function of this module
type (i.e., to set-up a special system condition) to be initially
executed when the exerciser is relocated to another memory bank.
Examples of SB~~OD usage are:
To set-up the run-time sequencing of other
modules or peripheral devices.
To switch the DT03
modules are run.
2.1.3
Buss
Switch
before
resident
the
other
Non-Restartable Background Module (NBKMOO)
The NBKMOD-type-module only runs in a background mode, is the second
type of module to be run, and is non-restartable. Once this type of
module has been initially run successfully, it is never run again;
unless, of course, an exercise is both aborted and restarted.
Examples of NBKMOD usage are:
Checking system timing before other modules are run.
Checking system parity before other modules are run.
2.1.4
I/O Module (lOMOD)
The IOMOD-type-module only runs in Input/Output mode (i.e., via
interrupt-driven devices), depending on expected interrupts in order
to run continuously. These modules generally service buffer-driven
devices (i.e., devices that do not generate NPRs or contain word-count
registers). This type of module can be relocated without restriction.
Examples of IOMOD usage are:
For exercising TA-11 Cassettes, and floppy disks.
For exercising a paper tape reader/punch or a line
printer.
Exercising a floating point hardware option (module
FPB)
2.1.5
I/O Module Restricted (IOMOOR)
The IOMODR-type-module is an rOMOD that cannot be relocated, due to
hardware restrictions, and is only run in the lowest bank of memory.
Page 15
76
\n example of IOMODR usage is:
2~1.6
the exercising of a UNIBUS Tester.
r/o Module Extended (IOMODX)
The rOMODX-type-module is an rOMOD with extended capabilities that
serVlces NPR devices. The capabilities of this module type include:
use of a monitor supplied write buffer, the ability to change the size
of read and write buffers, the ability to access a monitor's check
data utility routine, and the ability to convert 16-bit addresses to
18-bit addresses or IS-bit addresses to 22-bit addresses.
Examples of IOMODX usage are:
2.1.7
Exercising the RKll Controller and up
(types RK02-RK05).
to
Exercising
drives.
density
the
RPII
high
and
low
8
drives
disk
I/O Module Partially Restricted (IOMODP)
The IOMODP-type-module is an IOMODX that is partially relocatable.
rhis means that due to hardware restrictions the module is only
relocated to certain fixed boundaries' (e.g., 32K).,
2.2
DEC/XII Monitors
Since there are several DEC/XII monitor programs that are available to
the user, the selectfon of an appropriate monitor depends on the
configuration of the hardware system to be tested.
However, the
monitor programs are not separate entities. A desired monitor must be
constructed, via the configurator/linker process; from pre-assembled
monitor modules that are contained in a DEC/XII Monitor Library.
Therefore, to provide for both convenient selection and adaptation to
the
configurator/linker
process"
DEC/XII monitor programs are
classified by type and named (i.e., A,B,C, etc.) as described in the
DEC/XII CROSS REFERENCE MANUAL.
Such monitor classification in the reference manual not only allows
the user to apply an appropriate monitor program to a given hardware
configuration, but to select a monitor that most nearly meets the
needs of the hardware system in relation to (1) the functional
requirements of the resultant RTE and (2) the more efficient use of
assigned monitor space.
Moreover, in the same manner that the linking of the basic software
components of an RTE program (monitor and option modules) depends on
the total configuration of the hardware system, the linking of the
basic
software
components of the monitor portion of the RTE
76
Page 16
{pre-assembled monitor modules} depends on the type of processor to be
serviced and its available options.
Finally, since in all probability additional monitors will
be
designed, the following material is not intended to describe monitor
concepts in terms of specific monitor differences but rather in terms
of common functionality.
Monitor Operations
Basically, the monitor portion of an RTE program is responsible for
starting
the
RTE
(via Initialization)~
establishing operator
communications (via Command Decoding)~
establishing communications
with its resident option modules (via Trap Interpretation): providing
for option module control (via Queue Priority Servicing);
and
providing for memory usage control (via RTE Relocation and Write
Buffer Rotation).
2.2.1
System Initialization
When an RTE program is loaded, the monitor portion of the program
provides for the initialization of certain software and hardware
components of the system via the execution of two routines:
the
Start-Up and Initialization routines.
Start-up Routine
This routine sets-up required software components of the monitor and
determines the operating environment by performing the following
functions:
Set-up the Power Failure Vector.
Set-up the software and hardware trap handlers.
Set-up the Software Switch Register (SWR)
and
certain Status Indicator Words (for option status).
Size and Poll the system to determine:
(a)
Processor type (11/70, 11/60, etc.)
(b)
Processor Options (KT, CACHE, etc.).
(c)
Memory size (size of RTE is in Loc.
(d)
If good parity
must
be
written
Zero).
in
memory
Page 17
76
(only if PARITY or ECC option).
(e)
Software environment (APT, ACT/SLIDE/XXDP+)
Output RTE identity message.
Output System Size message.
Output Keyboard Prompt (CMD».
Initialization Routine
This routine Initializes certain software and hardware components (and
starts the monitor running) as follows:
Initialize both the Control and Type Queues.
Initialize error logging function (if available).
Initialize the option module servicing mechanisms
(i.e., set-up the various pointers and flags).
Enable the keyboard for operator input.
2.2.2
Operator Interfacing
Once an RTE program is Initialized, the fact that the monitor portion
of the program is running (and the keyboard enabled for command input)
is indicated by the printing of the Command Mode (CMD» prompt. Thus,
at this point the monitor is available to provide service to the more
than twenty keyboard commands available to the user.
Some of the
commands (such as module start, option disable/re-enable commands, and
the module parameter modification command) are restricted to entry in
Command Mode only. The remaining commands, that are generally related
to the deselection/reselection of modules and the disposition of
printout data, may be entered in either the Command Mode or (following
a module start command) the Run Mode (BSY».
In any case, as the operator enters a command format, each character
is stored in the Keyboard Input Buffer until a Carriage Return (CR) is
both entered and recognized by the Monitor.
When this occurs, the
Monitor (via its Task Scheduler) dispatches control to its Keyboard
Input Processing Routine to execute the following 5 monitor modules:
The Process Command Routine (CMDPRC)
The Copy Command Routine (CMDCPY)
The Decode Command Routine (CMDDEC)
Page 18
76
The Service Command Routine (CMDSRV)
The Reset Command Routine (CMDRST)
Process Command Routine (CMDPRC)
CMDPRC is the control module for the entire Keyboard Input Processing
Routine.
As such, the module is responsible for initially clearing
all local storage locations required by the process and ultimately
calling for the execution of each of the subordinate routines as
follows:
1.
2.
CMDPRC initially calls the Copy-Command-Routine (CMDCPY) to
allow the contents of the Keyboard Input Buffer to be
transferred to the Decode Buffer.
Following the transfer,
CMDCPY then returns control to CMDPRC. However, there are
two possible results of the transfer:
(a)
If CMDCPY does not detect an abnormal condition in
Decode
Buffer,
CMDPRC
is
directed to call
Decode-Command-Routine (CMDDEC) to
check
for
validity of the command.
(b)
If CMDCPY detects an abnormal condition in the Decode
Buffer, an Abort Flag is set and CMDPRC is directed to
call the Reset-Command-Routine (CMDRST), to allow a
correction to be made following the issuance of an
appropriate prompt (CMD> or BSY».
the
the
the
Whenever a command is checked for validity by CMDDEC, control
is always returned to CMDPRC to continue process control.
However, there_~re two possible results of the check:
(a)
If the command in the Decode Buffer is valid, CMDPRC is
directed to call the Service-Command-Routine (CMDSRV) in
order to execute the function prescribed by the command.
(b)
If an Invalid Command is detected in the Decode Buffer,
CMDDEC loads an error message into the Type Queues and
CMDPRC is directed to call the Reset-Command Routine
(CMDRST) in order for a correction to be made. The
message is then output, followed by the issuance of an
appropriate prompt (CMD> or BSY».
3.
When the prescribed function is executed, CMDSRV always
returns control to CMDPRC which, in turn, always calls CMDRST
to enable the issuance of the appropriate prompt (CMD> or
BSY»~
Thus, keyboard interrupts and the possible entry of
another command are both re-enabled.
4.
Finally, whenever the appropriate prompt has been output via
CMDRST, a return is always made to CMDPRC in order to effect
Page 19
76
a return to the Task Scheduler.
Copy Command Routine (CMDCPY)
The CMDCPY routine allows the command string that is originally
contained in the Input Buffer to be copied into the Decode Buffer, one
character at a time, up to (and including) the Carriage Return (CR) or
Line Feed (LF).
Moreover, since the Input Buffer may contain both
Rubout (\) and replacement characters, the routine will delete the
unwanted characters.
Following the receipt of a command string, the routine always returns
control to the Process-Command-Routine (CMDPRC). However, prior to
the return, an Abort Flag will be set (allowing for re-direction in
Process Control) if anyone of the following abnormal conditions
occurs:
A Control U(AU) character is detected (See CMDPRC Step lb)
The first character detected is a Rubout, Carriage Return,
Line Feed (See CMDPRC Step lb).
or
Decode Command Routine «(MDDEC)
The CMDDEC rouiine scans the D~cod~ Buffer and compar~s the 'command
entry with entries contained in a Valid Command Table. There are two
possible results:
If a match is found, the command is validated and its code is
obtained from the table as a return is made to Process Control
(See CMDPRC Step-2a).
If a match cannot be made, an Invalid Command indicator is
set, an appropriate error message is loaded into the Type
Queue, and control is returned to Process Control (See CMDPRC
Step 2b).
It may be noted that following a comparison a return to CMDPRC is
always made.
However, if a match cannot be made, the setting of the
Invalid Command indicator provides for a redirection in Process
Control.
Service Command Routine (CMDSRV)
The CMDSRV Routine provides for the execution of all valid commands.
Once its function is performed, a return is made to Process Control
(See CMDPRC Step 2a and Step 3).
Reset Command Routine (CMDRST)
Page 20
76
Th·e CMDRST Routine o~Ptuts an appropriate prompt and re-enables
keyboard interrupts 1n order to accomodate additional or corrective
operator input. To output the proper prompt message, the routine
determines if the system is currently in a Command (CMD» or a Run
However, if an error
(BSY» Mode by examining a status indicator.
message is in the Type Queue, it will be output prior to loading and
outputting a prompt message.
Once the routine's
function
is
completed, a return is always made to Process Control (See CMDPRC
Steps: lb, 2b, 3 and 4).
2.2.3
Option Module Control
Monitor control of an RTE program's resident modules is basically
concerned
with the implementation of two tasks:
(1) Priority
scheduling for module execution and (2) establishing
effective
communications with each module.
2.2.3.1
Priority Scheduling
As part of an RTE, each option/device module performs a unique test,
which must be properly sequenced during run-time. However, in regard
to module functionality and processing modes of operation (i.e.,
Background Mode and Input/Output Mode), many of the modules are
similar. For these reasons all modules are divided, by common
functionality and processing mode, into the following seven types:
Background Modules (SBKMOD, NBKMOD, B~~OD) which do not service
interrupt-driven devices:
and Input/Output Modules (rOMOD, IOMODX,
IOMODP, rOMODR) which do service interrupt-driven devices.
In
addition, each module--is defined by type via status word bits
contained in the module's header.
With this arrangement, the monitor during Initialization uses the
status word bits to construct a Priority Schedule by listing each
resident module in a pre-determined manner, thus defining the order of
execution by type.
With the system in Command Mode (CMD», the typing-in
Start Command, with or without relocation specified
RUNL), initiates the execution of the option modules (as
the Priority Schedule) and outputs a Run Mode (BSY»
module is then conditionally sequenced as follows:
1.
of a Module
(i.e., RUN or
prescribed in
prompt. Each
SBKMODs
The SBKMODs are the first type to be run.
Each module is
separately run once prior to relocation and once again
following each relocation (i.e., if relocation is enabled.)
76
Page 21
2.
NBKMODs
The NBKMODs are the next type to be run.
separately run once, and never again.
3•
Each
module
is
IOMOD , X, P , R
All the I/O Modules are the next types to be run.
They run
simultaneously and continuously (i.e., as long as there are
interrupts to drive them).
4.
BKMODs
The BKMODs are started last and each module
is
run
separately.
However, since these modules have the lowest
priority, they can only be run when none of the other types
are running.
2.2.3.2
Module Communications
When the option modules are running, co~munication is established with
the monitor via software hooks that are contained in the body of each".
module (i.e., Trap Calls) and also, in some cases, in the header
(i.e., parameter locations)-.
These elements, therefore, comprise a
module's interface with the monitor.
Currently there are 19 calls collectively available to the option
modules.
Some calls are used by all of the modules, others are only
used with certain module~types, while others are function-related and
are, therefore, only used by specific modules, regardless of type.
Basically, when a module call is trapped to the monitor, the monitor
responds with a service and/or parameters such as: buffer services
including parameters, an error reporting routine, or a message output
service.
I/O Module Buffer Service Calls:
GWBUFS
GETPA$
MAP22S
CDATAS
DATCKS
;Get Write Buffer information call.
;Get IS-bit Physical Address call.
;Map 22-bit Physical Address call.
;Check Data call.
;Provide Check Data error count
call
Output Message Calls:
Monitor-Defined Error Messages:
DATER$
;Data Error message call.
Page 22
76
HRDER$
SOFER$
;Hard Error message call.
;Soft Error message call.
Module-Defined Messages:
MSG$
MSGS$
MSGN$
;Output single ASCII message call.
;Output all ASCII messages in table
call.
;Output all ASCII messages in table
with header call.
Return Control To Monitor Calls:
EXIT$
PIRQS
BREAK$
;Module awaltlng interrupt call.
;Put Interrupt Request in Queue
call.
;Temporarily return to monitor
call.
Ending Calls:
ENDITS
ENDS
;End of iteration call.
;Drop module from exercise call.
Utility Calls:
OTOA$
BTOD$
RANDS
;Octal to ASCII conversion call.
;Binary to Decimal conversion call.
;Random Number request call.
I/O Module Buffer Service Calls
To process data transfers for certain I/O modules (IOMODX and IOMODP),
the monitor, on request (GWBUF$), provides a write buffer area in free
core from which data is sent to the device. In addition, the monitor
provides the module interface
to equivalent ASCII
characters (max. 6 characters). When the call is issued,
the module provides the monitor with both the module location
of the number to be converted and the module location of the
starting address to which the result will be directed.
As an example of usage: the call may be issued prior to
issuance of an MSG$ call to define the ASCII message.
2.
the
The BTOD$ Call:
The BTOD$ call traps to the monitor to request the conversion
of a binary number (max. 16 bits) to decimally equivalent
ASCII characters (max. 5 characters).
When the call is
issued, the module provides the monitor with both the module
location of the number to be converted and the module
location of the starting address to which the result will be
directed.
As an example of usage: the call may be issued prior to
issuance of an MSG$ call to define the ASCII message.
3.
the
The RAND$ Call:
The RAND$ call traps to the monitor to request the generation
of a new random number (max. 16 bits). Once the number is
generated, it is directed to a random nlliuber location in the
module's header.
As an example of usage: a new random number may be used to
alter the sector address for a disk, thus allowing random
instead of contiguous SEEKs to occur.
2.2.4
Memory Usage Control
When the RTE is running, one of the monitor's major
is to exercise an efficient control of memory
includes:
responsibilities
resources. This
Control of the available memory hardware
(i.e., KT, CACHE, PARITY, ECC, etc.)
options
Page 28
76
The sizing and designation of write buffer space for
requesting modules within a pre-defined write buffer
area.
Control over the relocation of the moveable portion
of both the RTE and the monitor (i.e., if the option
is enabled).
The generation of memory-worst-case patterns in free
core for a more comprehensive exercise of available
memory resources.
2e2e4el
Memory Options Control
The monitor is responsible for establishing control over all memory
hardware options that may be available to the system. This includes:
(1) Memory Management (KT): (2) Parity Memory, ECC, and Cache Memory:
and (3) the 22-Bit Addressing option.
Memory Management (KT) Control
Initially, the monitor determines if a KT unit is available.
is, the following control functions will be performed:
If
it
The KT may be turned On or Off via keyboard command.
All Page Address
Registers
(PARs)
and
Descriptor Registers (PDRs) will be set up.
Page
If a CDATA$ or DATCK$ call is trapped to the
monitor, the processor will be switched from KERNEL
to USER Mode.
Parity, ECC, and Cache Memory Control
Monitor control of Parity, ECC, and Cache Memory consists of turning
these options On or Off via keyboard commands and accommodating
associated error traps. However, in regard to parity Memory and the
ECC option, common On/Off commands are currently in use. Thus,
turning Parity Memory On will also turn the ECC option On, if it is
available.
22-Bit Addressing Control
Monitor control of 22-Bit Addressing consists of turning the option On
or Off via keyboard command and loading the Mapping Registers.
Initiation of the latter provides pointers to the write buffer area.
76
2.2.4.2
Page 29
Write Buffer Control
certain DEC/XII test modules (i.e., IOMODX, rOMODP) have the ability
to request that the monitor provide write buffer space for the
transfer of output data to an associated device.
In this regard,
monitor control of the write buffer area concerns (1) the designation
of such space on request and (2) the "rotation" of write buffer spaces
(via the RTON Command) during successive requests, to provide a device
with more comprehensive testing in relation to its ability to access
all of free core. Write Buffer Area
For systems having only 128K of memory or less, all of the memory
space not currently occupied by the RTE is defined as the write buffer
area from which write buffer space is assigned.
However, for system~ greater than 128K
which
require
22-bit
addressing, memory IS divided into contiguous segments consisting of
the 124K locations. The write buffer area is then limited to that
124K segment of memory in which the moveable portion of the RTE
currently resides.
Segmentation is necessary due
to
hardware
addressing restrictions in which the UNIBUS Mapping Registers, fully
loaded, can only accommodate a maXImum addressing range of 124K
locations.
In Figure 2-2, three examples of segmentation depict the relationships
existent between the current location of the RTE and the location and
limits of the write buffer area:
In example 2a, the limits of the write buffer area are shown when the
moveable portion of the RTE is in the lowest 124K segment. Note that
the RTE is not relocated within the segment and,
if it were, the
limits of the write buffer would remain the same.
In example 2b, the limits of the write buffer area are shown when the
moveable portion of the RTE is relocated to another 124K segment.
Note that if the RTE is again relocated but remains within the
segment, the limits of the write buffer will remain the same.
In example 2c, the limits of the write buffer area are shown when the
moveable portion of the RTE has been relocated to straddle the
boundary of a 124K segment. Note, in this instance, that the lower
limit of the write buffer area starts at the base of the moveable
portion of the RTE and ends 124K locations above the base.
Write Buffer Rotation
Briefly, write buffer rotation (if enabled) allows an initial write
~uffer
assignment to be made from a pre-defined starting position:
that is, the first free location above the top of the moveable portion
of the RTE. Subsequently, assignments are advanced through the write
buffer area until the top of the area is reached, whereupon the
Page 30
76
monitor returns to the bottom of the area to continue the process.
However, if rotation is not enabled, all assignments are made from the
pre-defined starting point (i.e., top of the RTE).
SOME EXAMPLES OF WRITE BUFFER LIMITS
------------
------------
I
1
1
I
1
1
I
I
1
1
1
I
-248K
------------
-248K
-248K
\
\
I
IWRITE
I BUFFER
---------RTE
----------
/
/
-124K
\
\
1---------1
RTE
IWRITE
I
I BUFFER
1---------I
I RTE LOW
4K
/
1
------------/
2a
-124K
\
\
1
IWRITE
---------I BUFFER
RTE
-/--124K
---------- /
r..:----------I
I RTE LOW I
4K
I
I
----------
------------
------------
2b
2c
RTE LOW
4K
FIGURE 2-2
Write Buffer Segmentation
(For Systems Greater Than 128K)
Before describing the rotation process, recall that whenever an
Extended I/O Module requests write buffer space, the monitor will
initially determine if the area contains sufficient space to satisfy
Page 31
76
the request.
Once this determination is made, the monitor either
grants the requesting module the desired buffer size or provides the
module with whatever space is available. The monitor then delivers
the start address of the assigned buffer space to the module.
To accommodate such requests, and also the requirements of both the
Exerciser Relocation option and the Write Buffer Rotation option, the
monitor uses a write buffer area as the first free location above the
moveable portion of the RTE, thus defining a start address which
equates with the base address of the write buffer area (i.e., the top
of the RTE).
This is accomplished via pointer initialization which
occurs under two conditions: (1) prior to the issuance of an initial
request and (2) following any relocation of the RTE. Moreover, since
the pointer can only be advanced when Write Buffer Rotation is
enabled, all subsequent requests, made with rotation disabled, will
effectively use the base address of the area as a start address.
In any case, with the initial start address appropriately defined and
rotation enabled, the pointer will be advanced to define the first
free location above the top of the first requested buffer space.
At
this point, if sufficient core is available, the pointer will assume
an address-value which equates with the requested buffer size plus
one. Otherwise, the pointer will assume an address which equates with
available space.
In this manner, every subsequent request will
advance the pointer through the buffer area until the top of the area
is reached, whereupon the pointer will be returned to the bottom of
the write buffer area, where the advancement process will continue.
However, as shown in Figure 2-2, depending on relocation, the bottom
of the buffer area may again be at the top df the RTE (Examples 2a and
2c) or below the RTE (Example 2b). If the latter is true, advancement
will continue until the last free location, at the bottom of the
moveable portion of the RTE, is eventually reached.
At this point,
since the RTE itself cannot ~e used as write buffer space, the address
pointer will skip to th~-top of the RTE and the rotation process will
continue.
2.2.4.3
Exerciser Relocation
Before describing the Relocation Process, recall that when an RTE
program is loaded into memory the program is effectively divided into
two sections: (1) a fixed monitor portion which must reside 1n the
lowest 4K of memory and is not relocatable and (2) a moveable portion,
consisting of the remainder of the monitor and all of the test
modules, which initially resides above the fixed portion and can be
continuously relocated through the remainder of memory (See Figure
1-1).
In addition, continuous relocatio'n is only possible if:
(1)
the
system contains a Memory Management (KT) unit, (2) the KT unit is
enabled via the KTON Command, and (3) the Relocation Process is not
locked out (i.e., the RTE is started by a RUN Command as opposed to a
RUNL.
Page 32
76
Relocation Process
The Relocation Process is a monitor controlled option which allows the
moveable portion of the RTE to be continuously relocated through main
memory via a series of relocation operations to provide for a complete
test of all available core (the lowest 4K excepted).
During the process, each new relocation operation is initiated by the
monitor when all of the liO type modules have completed a -single pass
or when any BKMOD (if no I/O modules exist) has completed a pass.
However, since the modules have varying run-times, some of the modules
will have completed a pass and restarted.
Therefore, all of the
modules will be stopped at their next iteration point, at which point
they will be restarted when relocation is completed.
When a relocation operation is completed, a RELOCATED TO XXXXXX
message is output, indicating the new physical start address (XXXXXX)
of the RTE.
However, there are two separate types of relocation operations that
may
sequence during a Relocation Process:
Constant Relocation
operations or Random Relocation operations. Moreover, by setting a
bit (SW08 = 1) in the RTE's Software Switch Register, the execution of
the series of random relocation operations may be disabled.
If both
types of relocation are permitted (SW08 = 0), constant relocation
operations will first cycle the RTE· completely through memory, but
only once. The Relocation Process will then be continuously effected
by random relocation operations until the program is stopped and
restarted.
However, if Random Relocation is disabled (SWOB = 1),
constant relocation operations will run continuously.
Constant Relocation
Ope~dtions
Starting at a base address defined by the user, or the original base
address defined by default, the moveable portion of the RTE is
advanced to a new base address via an incremental constant (normally
4K).
In this manner, constant relocations occur until an upper limit
of memory is eventually reached that can accomodate the program.
The
monitor then returns the RTE to its original base address and the
cycle is completed. At this point, if Random Relocation is enabled,
the process will never be re-cycled until the program is stopped.
Otherwise, it will recycle continuously.
Random Relocation Operations
Following the completion of a series of constant relocation operations
which return the RTE to its original base address, the Relocation
Process may be re-initiated by a series of random
relocation
operations.
During Random Relocation, the moveable portion of the RTE is relocated
76
Page 33
to randomly selected areas of memory, via random number generation,
until a pre-defined number of relocations (determined by total memory
size) has occurred.
At this point, the next relocation will return
the RTE to the lowest possible address (the original base address).
The next relocation will then direct the RTE to the highest possible
address that can accow~odate the program, which completes the cycle.
The entire process is then continuously repeated until the program is
stopped.
2.2.4.4
Memory-Worst-Case-Pattern Generation
As previously stated, all of the memory space not currently occupied
by the RTE is defined as free core and as such serves as the write
buffer area. With this consideration, when a Module Start Command
(i.ee; RUN or RUNL)
is entered
a memory worst-case pattern is
automatically written into the free core area in order to intensify
UNIBUS activity during I/O data transfers.
f
However, if relocation of the RTE is enabled, during each successive
relocation increasing portions of the worst-case pattern are overlaid.
Therefore, whenever the RTE is eventually relocated to lowest memory,
the worst-case pattern is completely re-written.
2.2.5' Trap Processing
Trap processing by the monitor is concerned with the handling of both
software and hardware traps.
Software traps are used to provide
access to special handling routines via a Trap Instruction when an
option/device module requires external services that the monitor
provides such as buffer services or error reporting services (refer to
Module Communications -2.2.3.2).
Hardware traps are used to provide
access to special handling routines following the execution of an
instruction when an internal error condition is detected by the cpu.
Thus, hardware traps are caused by internal failures as opposed to
external failures occuring within a device.
Software Traps
When a module issues a trap call (e.g., GWBUF$, GETPA$, etc.), the
trap instruction is vectored via Location 34(TRAP instruction} to the
monitor's Trap Service routine. The trap code is identified and the
module's register contents and offset PC address are saved. The
monitor then dispatches to the appropriate routine(s) where, depending
on both the type of call and the complexity of the requested service,
one or more of the following operations will occur:
The request is executed and control is returned
the requesting module (e.g., OTOA$, RANDS, etc).
The request is executed and/or an entry is
to
provided
Page 34
76
to the
etc.).
Type
Queue
(e.g.,
CDATA$,
DATER$, MSG$,
An entry is provided to the Control Queue
subsequent service (e.g., PIRQ$, BREAKS, etc.).
for
The request is executed and control is returned to
the monitor's Priority Scheduler routine (e.g.,
END$; EXIT$)e
Hardware Traps
Hardware trap handling concerns the· processing of internally produced
errors associated with the CPU and memory options that are classified
as follows:
(1) System Errors;
(2) Parity Errors (main or cache
memory) and ECC Errors; (3) Memory Management (KT) Errors.
1.
System Errors:
When a Bus Error (e.g., non-existent memory, odd address,
etc.)
is
trapped
through location 04 or a Reserved
Instruction Error (i.e., an illegal instruction) is trapped
through location 10, the monitor saves the contents of the
updated PC, PSW, and SP. The monitor then initializes the
system and outputs a System Error message. However, at this
point any or all of the following may occur:
If error logging is available to the CPU, it
performed.
1S
If an optioQ~odule is responsible for four
system errors, it is dropped.
If the entire RTE program has accumulated excessive
system errors, the run is terminated and the system
is returned to Command Mode (CMD». With the exception of
the latter possibility (i.e., return to CMD», following the
processing of a system error the RTE is restarted as follows:
All modules that have completed an End-Of-Pass will be
re-initiated from the beginning (i.e., RESTART address) while
the remaining modules will be re-initiated from a pre-defined
location (i.e., START address).
2.
Parity Errors and Ece Double-Bit Errors:
If a Memory Parity Error, a Cache Parity Error, or an ECC
Memory Double-Bit Error is trapped through location 114, the
system is initialized and the contents of the appropriate
registers
are output, along with an appropriate error
message. However, if ten of these errors occur, the run is
terminated
and
the system is returned to CMD> mode.
Otherwise, the RTE is restarted as previously described.
76
Page 35
3.
Memory Management (KT) Errors:
If a KT Error is trapped through location 250, the system is
initialized
and the contents of the available general
registers (SRO and SR2, SRl and SR3) are output, along with
an appropriate error message. HOwever, if a KT error occurs,
the run is terminated and the system is returned to CMD>
mode.
2.3
Configurator/Linker Program
The DEC/XII configurator/linker program is used to create Run-Time
Exerciser
(RTE)
programs.
The
initial
implementation of a
configuration process (via construction of a Configuration Table) is
followed by the implementation of a linking process (via execution of
a LINK Command), which results in the creation of an individualized
RTE module. A user specified monitor and user specified test modules
are selected, entered in the Configuration Table (C-Table), and linked
by command to derive an RTE module. 2.3.1 The Configuration Process
The configuration process facilitates the execution of the linking
process, by providing an accessible area for required monitor and test
module information.
Following the loading of a configurator/linker program, the user
implements the configuration process by initiating a Configure Mode of
operation and constructing a Configuration Table (C-Table).
During
construction, the name of the desired monitor is entered in the table.
The name of each desired test module is then separately entered along
with
certain associated parameters, such as device and vector
addresses and priority t~vels. The C-Table will accommodate a maximum
of 40, II-word entries (i.e., 1 monitor entry and 39 test module
entries).
When the construction of the C-Table is completed, the information
required for the linking process is available and the user provides
for an exit to the Non-Configure Mode of operation to initiate the
link.
2.3.2
The Linking Process
With the construction of the C-Table completed, the user initiates the
linking process via the formatting and execution of a Link Command.
Basically, the linking process effects the building of an RTE by
examining the C-Table and selecting, or informing the user to select
(i.e., if the input medium is paper tape), the appropriate monitor
modules (from the monitor library) and the appropriate test module
input. However as each module is selected, it is individually
processed and output, a block at a time, as a portion of the RTE. In
Page 36
76
this manner, the RTE is created as a single executable binary file.
2.4
DEC/XII Distribution
DEC/XII software is packaged for usage over a wide media range.
Therefore, the elements of a software package are associated with a
narticu1a
m~diurn
uia
...
_ .r. . ..".
..
..t"
~
.....
MAT~~r
..........
..." ... ......
nAsinnator
(alnhanumer;~
'..
••
..,
.... t:'
~
~
A ......
,
...... '""
~nne)
'-'A
""'" ' "
~hat
'- • ~
both listed and described in the DEC/XII CROSS REFERENCE MANUAL.
is
-
Page 37
76
CHAPTER 3
USER'S SECTION
3.1
GENERAL I NFORMAT I ON
3.2
EXERCISER BUILD PROCEDURES
3.2.1
Procedural Guide
3.2.2
Pre-Build Planning
3.2.3
Build Requirements
3.2.3.1
Required Hardware
3.2.3.2
Required Software
3.2.3.3
Required Documentation
3.2.4
Configurator/Linker Programs
3.2.4.1
Load and Start Procedures
3.2.4.1.1
Loading Via Absolute Loader
3.2.4.1.2
Loading Via XXDP+ Monitor
3.2.4.1.3
Starting Prucedures
3.2.4.2
Operating Procedures
3.2.4.2.1
Configure Mode Commands
3.2.4.2.2
Linking Process Command
3.2.4.2.3
I/O Control Commands
3.2.4.2.4
General Utility Command
3.2.4.2.5
Command Error Messages
3.2.5
Generating a Run-Time, Exerciser Module
3.2.5.1
The Configuration Table (C-Table)
3.2.5.2
The Linking Process (LINK Command)
3.2.5.3
The Run-Time Exerciser (RTE)
Page 38
76
3.3
EXERCISER RUN PROCEDURES
3.3.1
Hardware and Software Requirements
3.3.2
Load and Start Procedures
3.3.2.1
Load/Start Via ABS Loader
3.3.2.2
Loading Via XXDP+ Monitor
3.3.2.3
Starting Via XXDP+ Monitor
3.3.3
Operating Procedures
3.3.3.1
Switch Register Options
3.3.3.2
Keyboard Commands
3.3.3.2.1
Keyboard Character Usage
3.3.3.2.2
Keyboard Error Messages
3.3.3.2.3
Keyboard Command Analysis
3.3.3.3
Operator Modifications
3.3.3.3.1
Monitor Modifications
3.3.3.3.2
Option Module Modifications
3.3.3.4
Message
3.3.3.4.1
Normal Run-Time Messages
3.3.3.4.2
Run-Time Error Messages
3.3.4
Debug Recommendations
Print~outs
76
1.1
Page 39
GENERAL INFORMATION
This chapter provides all of the reference and procedural information
the
user
needs
to
(I)
load,
start,
and
run a DEC/XII
Configurator/Linker program and (2) effectively create a run-time
exerciser (RTE) module for a specified device.
To accomplish the above, the user must have an adequate knowledge of
the PDP-II system for which the RTE module ~is intended (i.e.,
processor type, core size, device and vector addresses, priority
levels, etc.). Such information is necessary prior to initiating the
configuration process in order to both determine and specify which
device/option modules and monitor program are needed to satisfy device
test requirements.
3.2
EXERCISER BUILD PROCEDURES
The following material initially provides a procedural guide (with a
ore-build check list) to the use of the build information contained in
this section. The build information first defines the hardware,
software,
and
reference documentation required to successfully
construct a run-time exerciser program to user specifications.
This
is followed by descriptions of load, start, and run procedures as they
relate to the DEC/Xll Configurator/Linker program and those PDP-li
levices currently available. The section concludes with a description
of the keyboard commands and their procedural application to the
configuration process.
3.2.1
Procedural Guide
In order to successfuTly construct an RTE program, a carefully
evaluated pre-build planning phase must be initiated that is followed
by a systematic application of the exerciser build procedures that are
described in this section~
In this regard and as an aid to
software, the following material
the
planning
and
building
subsection-by-subsection guide
procedures as they are contained
Step Orie:
the inexperienced user of DEC/Xll
provides both a step-by-step guide to
of
an
RTE
program
and
a
to the systematic use of the build
in this section.
Initiate a Pre-Build Plan
In the pre-build planning phase, major elements of the hardware
configuration to be tested are cross-referenced with appropriate
DEC/XII software elements {i.e., monitor and test modules} in order to
prepare a formal listing of build requirements. This is done prior to
selecting, loading, starting, and running the configurator/linker
Page 40
76
program.
For details: refer to PRE-BUILD
subsections 3.2.2 and 3.2.3.
Step Two:
PLANNING
and
BUILD
REQUIREMENTS,
Build a Configuration Table (C-Table)
This step is entered with the configurator/linker program running and
its repetoire of run-time commands available to the user. Under these
conditions and to facilitate the next step in the build (i.e., the RTE
linking process), the name of the monitor, each test module, and
certain parameters that have all been derived from pre-build notations
are entered in the Configuration Table (C-Table).
For details: refer to OPERATING PROCEDURES, CONFIGURE MODE COMMANDS,
and THE CONFIGURATION TABLE (C-TABLE); subsections 3.2.4.2, 3.2.4.2.1
and 3.2.5.1.
Step Three:
Initiate The Linking Process
In this, the last step of the build, the Link Command is formatted and
executed to create an RTE file named by the user.
For details: refer to OPERATING PROCEDURES, LINKING PROCESS COMMAND,
and THE LINKING PROCESS (LINK COMMAND), subsections 3.2.4.2, 3.2.4.2.2
and 3.2.5.2.
3.2.2
Pre-Build Planning
Pre-build planning consists of a careful determination of the elements
required to properly test a given hardware system. This involves
noting all of the major hardware components, options, and required
parameters and cross-referencing these elements (via the DEC/XII CROSS
REFERENCE MANUAL) to derive a list that will associate the appropriate
software with the hardware configuration. An example of such a list
is shown in Figure 3-1.
Notice in figure 3-1 that a particular monitor (C) has been derived
for a given processor (PDP-11/34) and its options while specific test
modules have been derived no extension), allowing the selected program to load and
self-start
(refer
to XXDP+ User's Manual for monitor loading
procedures).
3.2.4.1.3
Starting Procedures
When the selected configurator/linker program is successfully loaded,
the program identifies itself to the user and then outputs a restart
address and a Help query. In this regard, the following provides an
example
in which program requests are underlined and operator
responses are not:
.R DXCL
;load/start program DXCL
CHUXC-? XXDP+ DECXll CNF/LNK
RESTART: 006620
;program identity
;restart address
DO YOU WANT HELP? (Y OR JUST
;do not
*
;prompt character for command.
prin~
Help list.
In the example, the operator has chosen to ignore the Help query (by
typing a
Map-To-Console Switch (IMP):
For any version of the linker program, the IMP switch may be
added to the LINK Command format to direct the output of a map to
the console device.
Example:
*LINK PT:
Page 53
76
No-Prompt Switch (/NP):
If the standard configurator program is used, the /NP switch may
be added to the CNF Command to disable the output of operator
~rornpts during the building of the C-Table.
Example:
*CNF/NP
Page 54
76
!
!<------------WORD----------->!
!
!<--HI BYTE--->!<--LO BYTE--->!
.!
o
2
4
6
10
12
14
16
20
22
24
!-----------------------------!
MODULENAME
!-----------------------------!
"
!-----------------------------!
"
!
!-----------------------------!
DEVICE ADDRESS
!
!-----------------------------!
VECTOR ADDRESS
!
!-----------------------------!
BRI
BR2
!-----------------------------!
DEVICE COUNT
!
!-----------------------------!
SPECIAL OPTIONS REG. 1
!-----------------------------!
n
2
"
"
!-----------------------------!
3
"
!-----------------------------!
4
"
!-----------------------------!
n
n
n
n
CONFIGURATOR TABLE
ENTRY
FIGURE 3-1
76
Page 55
3.2.4.2.1
Configure Mode Commands
using typical examples of program requests and operator responses, the
following material describes both the formatting and usage of the CNF
and Configure Mode Commands.
Notice that the command descriptions are arranged in the same order
(i.e., CNF, MON, MDL, etc.) presented in the Operating Procedures
(3.2.4.2). Also, to clarify usage, all program requests including the
prompt character (*) are underlined while user responses are not.
Finally, following operator input, if an
invalid
command
or
inappropriate response is detected an error message will be output
(Refer to Command Error Messages. 3.2.4.2.5).
Enter Configure Mode (CNF)
The CNF Command is used to initiate a Configure Mode of operation. If
the C-Table is empty when CNF is entered the program will request a
monitor name and if the name is accepted the program will issue a
next-command prompt (*).
At this point subsequent program requests
will depend on whether the CNF Command was entered with or without a
No-Prompt Switch (/NP).
If CNF is entered without the switch, a subsequent Enter Modulename
Command (MDL name) will evoke nine successive requests for header
parameters for the named module.
When the prompting sequence IS
ended, the program will then output a summary. An example follows:
CNF without /NP:
*CNF
*MONITOR:
A
---------
*MDL
WXYZ
DVA-
177540
VCT-
203
BRl-
5
BR2-
5
DVC-
2
SRl-
SR2-
4000
SR3-
SR4-
Page 56
76
WXYZ DVA-177540 VCT-000230 BRI-000240 BR2-000240 DVC-000003
SRI-OOOOOO SR2-004000 SR3-000000 SR4-000000
Finally, if at any point the operator desires to discontinue the
prompt, a Control C(AC) may be typed and prompting for the current
module will end. However, any values already entered-will be stored.
Following this, a next-command prompt (*) will be printed and the
operator may enter the next module name.
However, if CNF is entered with a No-Prompt Switch (/NP) added, the
subsequent entry of a module name (MDL name) will not invoke a
prompting sequence. An example follows:
*CNF/NP
CNF with /NP:
*MONITOR:
B
*MDL
QRST
*DVA
I77530
*VCT
230
(etc.)
However, if at any time the operator desires to re-initiate a
prompting sequence, the operator can simply type a CNF without leaving
Configure Mode and prompting will begin when the next MOL Command is
entered.
Monitor Change Command (MON)
The MON Command may be used to change the monitor entry as follows:
*MON name
Output Current Module Entry (MOL)
The MDL Command (no name argument) allows a
module entry to be output as follows:
*MDL
WXYZ
summary
of
the
CR
DVA-OOOOOO VCT-OOOOOO BRI-OOOOOD BR2-000000 DVC-OOOOOO
current
76
Page 57
SRI-000000 SR2-oooooo SR3-000000 SR4-000000
The above indicates that
parameters are zeros.
Module
WXYZ
has
been
entered
and
its
Enter Module Name (MDL name)
The MDL Command (with name argument) is used to enter a specified
module name in the first available slot in the C-Table, as follows:
*MDL WXYZ
The name entered must
defines the following:
WX:
be
a
valid four-character modulename which
A two-character device/option name
Y:
A specific module (since others may exist for
the same device/option).
Z:
The version level of the module specified.
NOTE:
If the version level is unknown, a "?" may be used as the
fourth character of the module name when entering a module into
the C-table. During the execution of the "LINK" command all
?'s in the C-table will be replaced by the proper version
letters.
Since, under certain conditions, the MDL name Command can invoke a
prompting sequence (for the entry of module-header paramters), refer
to the information contained in the Enter Configure Mode (CNF)
description.
Enter Device Address (DVA)
The DVA Command is used to enter a device address parameter
current module entry. Only an even address may be entered:
into
*MDL WXYZ
;WXYZ is current module entry
*DVA 177600
;Enter DVA parameter (177600)
*MDL
;Output current module entry
WXYZ
DVA-177600 VCT-000200 BRI-000000 BR2-000000 DVC-OOOOOO
the
76
Page 58
In the example, the summary is incomplete (SRI-SR4 is omitted).
However, it shows that the DVA parameter has been filled.
In general, a DVA Command must be used whenever the DEC/XII CROSS
REFERENCE MANUAL indicates that a desired module does not provide a
device address (by default) or that the address
provided
is
non-standard in relation to the actual device employed (e.g., a second
RPII Disk or TMII Magtape Controller).
Enter Vector Address (VCT)
The VCT Command is used to enter a device vector address parameter
into the current module entry. Only an even octal address (774 max.)
may be entered.
*VCT 200
iEnter VCT address of 200
*MDL
:Output current module entry
WXYZ
DVA-177600 VCT-000200 BRI-OOOOOO BR2-000000 DVC-OOOOOO
In the example, the summary is incomplete. However, it shows that a
vector address has been added to the current module entry.
In general, a VCT Command must be used whenever the DEC/XII CROSS
REFERENCE MANUAL indicates that a desired module does not provide a
vector address (by default) or that the vector provided is at a
non-standard address.
Enter Priority Levels (BRI, BR2)
The BRI and BR2 Commands are used to enter high-order byte (BRI) and
low-order byte (BR2) priority level parameters into the current module
entry. Only an octal value (7 max.) may be entered.
WXYZ
*BRI 6
;Enter PRTY6 parameter
*BR2 4
;Enter PRTY4 parameter
*MDL
:Output current module entry
DVA-177600 VCT-000200 BRI-000300 BR2-000200 DVC-OOOOOO
In the example, the summary is incomplete.
However, it shows that the
76
Page 59
BRI and BR2 levels have been converted by the program into Processor
Status Word (PSW) equivalents.
In general, BRI and BR2 Commands must be used whenever the DEC/XII
CROSS REFERENCE MANUAL lnOlcates that a desired module does not
provide priority levels (by default) or that the levels provided are
non-standard in relation to the device employed.
Enter Device Count (DVC)
The DVC Command is used to enter a decimal number (16 max.) to define
the number of sub-devices (e.g., drives) or mUltiple devices (e.g.,
8DLlls) to be tested by the module.
It should be noted that the
number entered must equal the actual number of devices to be
consecutively tested:
WXYZ
*DVC 5
;Enter device count of five
*MDL
;Output current module entry
DVA-177600 VCT-000200 BRI-000300 BR2-000200 Dve-000037
In the example, the summary is not complete. However, it shows that
the decimal device count (5) has been converted to an octal number
(37) which, in turn, represents a binary-bit-map. The weight of each
consecutive One-bit contained in the map (all III binary) then
effectively represents the logical number of each device (i.e., 0-4)
consecutively arranged for testing:
0
a
a
0
a
3
7
000 000 000 all I I I Binary B~~ Map
!!
!!
\
! !---O
!!
!!
! ! !----1
!!
\ 5-Devices
-----2 /
!!
!!
!!-------3
~
~
!--------4
/
Moreover, consecutive testing of multiple devices is mandatory. Thus
the bit-map must have consecutive One-bits which equate with the
number of devices on a one-for-one basis. In the same vein, multiples
must be accessed by consecutive device addresses (whether ascending or
descending) following the first device-address. Thus, no addressing
Page 60
76
holes are permitted.
Software Switch Registers (SRI-SR4)
The SRI through SR4 Commands are used separately to enter individual
octal values into the Software Switch Registers for the current module
entry. Values must be entered as directed by the DEC/XII CROSS
REFERENCE
MANUAL
to
modify the execution of a module, thus
accommodating any standard, optional, and/or special features that may
be available to a device.
*SR2 4000
;Set Bit 11 in Sft. Sw. Reg. 2.
*MDL
;Output current module entry.
WXYZ
DVA-177600 VCT-000200 BRI-000300 BR2-000200 DVC-000037
SRI-OOOOOO SR2-004000 SR3-000000 SR4-000000
In the example, Bit 11 in Software Switch Register 2 has been set to
provide a flag for a device feature: the line printer to be used has
132 columns (instead of 80> and Bit 11 (set) is the indicator.
Delete Current Entry (KI)
The KI Command is used to delete the current module entry
all its associated parameter values) from the C-Table:
*KI
(including
;Kill the last entry referenced
When a module entry is deleted in this manner, subsequent requests for
a summary of the C-Table (via a TYPEC or PRINTC Command) will cause
the output of an Empty Indicator «EMPTY»
message for the deleted
entry. Search and Output Specified Entry (POINT)
The POINT Command is used to initiate a search through the C-Table
from the current module entry position for a specified module.
*POINT WXYZ
If
the
desired
;Search, from last referenced entry,
;for Module WXYZ. If found, output
;content.
module
name
is found, the contents of the entry is
76
Page 61
output. Conversely, if the desired entry is not found, a
INVALID NAME) is output.
message
(?
Output Next Module Entry (NXT)
The NEXT Command is used to output the contents of the module entry
that directly follows the last referenced entry (i.e., the current
entry). If a next-entry does not exist, an asterisk (*) will be
output.
;Output contents of next module entry
;(if existent).
*NXT
Clear C-Table (CL)
The CL Command is used to initiate a clear of the entire Configuration
Table.
When the C-Table is cleared, a monitor prompt request is
issued by the program (as in the CNF Command).
*CL
*MONITOR:
;Clear entire C-Table
name
;Enter monitor name
Exit Configure Mode (EXrThe EX Command is used to exit from the Configure Mode of operation
when the construction of a C-Table is completed. Re-entry is via a
CNF Command. If re-entry is made, the availability of a valid monitor
entry negates the need for a monitor request. Thus, the program
merely points to the first module entry in the C-Table and outputs a
command prompt (*).
*EX
;Exit Configure Mode
*CNF
;Re-enter Configure Mode
*
;Enter Command prompt
3.2.4.2.2
Linking Process Command
Page 62
76
Following an exit from the Configure Mode, the linking process (as
briefly described in the Operating Procedures subsection, 3.2.4.2) may
be initiated via the formatting of the LINK Command. From a general
format, the command may be applied in one of two ways: (1) for
non-directory devices (e.g., paper tape" magtape, etc.) or (2) for
directory devices (e.g., disk, dectape, etc.) as follows:
General Format:
LINK devo:[filnam.ext] OR JUST
:Link Command format
SYS SIZE:
:RTE memory requirement
160000
MAKE OUTPUT READY. WRITE ENABLE
;enable output device
TYPE(CR) WHEN READY
;acknowledge enable
PASS 1
;scan all modules
ANYMORE MONITOR PAPER TAPES, CASSETTES, ETC.? (YES,NO)
;monitor tape request
YES
;acknowledge tape
RELOAD INPUT WITH NEXT PAPER TAPE, CASSETTE, ETC.
TYPE(CR) WHEN READY
WXYZ SHOULD BE NEXT!
;acknowledge tape
;acknowledge tape
;Mod. WXYZ tape request
TYPE(CR) WHEN READY
;ack. test module tape
TRANSFER ADDRESS:
;start address for RTE
0.02200
LOW LIMIT:
000000
;RTE base address
HIGH LIMIT
045302
;RTE end address
PASS 2
:link and output RTE module
INPUT TAPES, CASSETTES, ETC. IN SAME SEQUENCE AS IN PASS 1
TYPE(CR) WHEN READY
:tape requests
:acknowlege tape
ANYMORE MONITOR PAPER TAPES, CASSETTES, ETC.? (YES,NO)
:monitor tape request
YES
;acknowlege tape
RELOAD INPUT WITH NEXT PAPER TAPE, CASSETTE, ~TC.
TYPE(CR) WHEN READY
:next monitor tape request
:acknowlege tape
Page 64
76
WXYZ SHOULD BE NEXT!
:Mod. WXYZ tape request
TYPE(CR) WHEN READY
:ack. test module tape
LINK DONE
:link process completed
Once the LINK Command is entered, the program initially requests the
memory size of the target system (i.e., the size of the actual system
on which the resultant RTE will be run). In response, the operator
must enter one of the following octal numbers:
If size is:
-----------
Enter:
------
20000
40000
60000
100000
120000
140000
160000
4K
8K
12K
16K
20K
24K
28K and greater
-'
The program then enters the first phase (PASS 1) of the linking
process In which the monitor and test module tapes are requested in
the same order defined in the C-Table. In pass 1 the program performs
a partial read of the requested tapes, to ascertain the final
structure of the RTE module. In the second phase (PASS 2) the same
tapes are again requested and read in their entirety to cause the
actual linking and output of the RTE module.
Finally, if either the Load Map To console (IMP) or Load Map To Line
Printer (/MLP) switch is used with the LINK Command, the address
limits of the RTE (i.e., TRANSFER ADDRESS, LOW LIMIT, HIGH LIMIT) will
not be printed during the first phase (PASS 1).
Directory Device Format
In the following example, the object modules are automatically
selected as input from an RK11 (Disk Drive Zero), linked as defined by
the C-Table, and output as an RTE module to the same drive.
*LINK DKO.TESTl.BIN
;Link Command entry
:RTE memory requirement
MAKE OUTPUT READY. WRITE ENABLE
:enable output device
TYPE ( CR) WHEN READY
:acknowlege enable
PASS 1
TRANSFER ADDRESS:
:scan for all modules
002200
:start address for RTE
76
Page 65
LOW LIMIT:
HIGH LIMIT:
000000
;RTE base address
063514
;RTE end address
PASS 2
;output RTE module
LINK DONE
;link process completed
As previously stated, if a Load Map To Console Switch (/MP) or Load
Map To Line Printer Switch (/MLP) is included with the LINK Command.
the address limits of the RTE will not be printed during the first
phase (PASS 1).
3.2.4.2.3
I/O Control Commands
As stated in the Oper"'ling Procedures (subsection 3.2.4.2), the I/O
Control Conunands may be used in or out of Configure Mode to allow:
(1) certain information to be listed, stored, and retrieved (e.g.,
C-Table and Load Map data);
(2) control to be returned to the XXDP+
monitor (the monitor i~ not reloaded); or (3) the XXDP+ Monitor to be
reloaded.
Examples of the formatting and usage of these commands
follow, with program response being underlined for clarity.
Jutput C-Table On Console (TYPEC)
The TYPEC Command is used to list the entire contents of
on the console.
*TYPEC
the
C-Table
;Output C-Table on console
Output C-Table On Line Printer (PRINTC)
The PRINTC Command is used to list the entire contents of the
on the line printer.
*PRINTC
;Output
C-Table
on
C-Table
line
printer.
- Save The C-Table (SAVC)
The SAVC Command is used to store a copy of the current C-Table on
either a non-directory (e.g., paper tape) or directory (e.g., disk)
medium for subsequent modification or reuse. To serve these ends, the
command utilizes a general format in which the filename argument is
only required for directory devices.
General Format:
SAve devO:[filnam.ext]
(If devo is omitted, the default is the system device.)
Page 66
76
Non-directory device example: In the following example, the
will be output on paper tape via a High-Speed Punch (pp).
*SAVC PP:
paper tape.
:Store
current
C-Table
C-Table
on
Directory device example: In the following example, the C-Table will
be output on Disk Drive Zero (DKO) under a file name specified by the
user (CNFl.CNF).
. *SAVC DKO:CNFl.CNF
:Store current C-Table on Disk
;Zero as file CNFl.CNF.
If, during the processing of a SAVC Command, the output file already
exists on the specified medium, the program will query the operator as
to whether or not the old file should be deleted, with the following
message:
DELETE OLD?(Y OR JUST
If an affirmative answer is entered(Y ), the old file will be
deleted, the command processed, and the new file output. If the
operator enters a negative response ( ), the old file will not be
deleted and the command will not be processed. Instead, a message (?
USE NEW FILE NAME) will be output and a new prompt will be typed.
Get the C-Table (GETC)
The GETC Command is used to retrieve a previously stored copy of the
C-Table, from either a non-directory (e.g., paper tape) or directory
(e.g., disk) medium, for modification via the Configure Mode Commands
(refer to subsection 3.2.4.2.1) for reuse. The command utilizes a
general format in which the filename argument is only used for
directory devices.
Moreover the command restores the table to the
proper memory space regardless of format.
General Format:
GETC devi:[filnam.ext]
(If devi is omitted, the default is the system
device.)
Non-directory device example: In the following example, the C-Table
is returned to memory from paper tape via the High-Speed Reader (PR).
*GETC PR:
:Return C-Table via High-Speed
Reader
Directory device example: In the following example, the C-Table is
located on Disk Drive Zero (DKO) under the specified file name
Page 67
76
(CNFl.CNF) and returned to memory.
*GETC DKO:CNFl.CNF
:Return C-Table file
CNFl.CNF
to
;memory from Disk Zero.
Save The Load Map (SAVM)
The SAVM Command is used to store a copy of the Load Map, generated
during a LINK Command, on either a non-directory (e.g., paper tape) or
directory (e.g., disk) medium. If used, this command must be entered
directly following the LINK DONE message. The command utilizes a
general format in which the filename argument is only required for
directory devices.
General Format:
SAVM devo:[filnam.ext]
(If devo is omitted, the default is the system device.)
Non-directory device example: In the following example, the Load
will be output on paper tape via a TTY-punch (PT).
SAVM PT:
Map
:Store Load Map on paper tape
Directory device example: In the following example, the Load Map will
be output on Disk Drive One (DKl) under a file name specified by the
user (LMPl.MAP).
*SAVM DKl:LMPl.MAP
;Store Load Map on Disk One
;as file LMPl.MAP.
If, during the processing of a SAVM Command, the output file already
exists on the specified medium, the program will query the operator as
to whether or not the old file should be deleted, with the following
message:
DELETE OLD?(Y OR JUST )
If an affirmative answer is entered(Y ), the old file will be
deleted, the command processed, and the new file output. If the
operator enters a negative response «CR», the old file will not be
deleted and the command will not be processed. Instead, a message (?
USE NEW FILE NAME) will be output, and a new prompt will be typed.
Retrieve Map and Output On Console (TYPEM)
The TYPEM Command is used to retrieve a previously stored copy of the
Load Map, from either a non-directory (e.g., paper tape) or directory
Page 68
76
(e.g., disk) medium, for output on the console. The command utilizes
a general format in which the filename argument is only required for
directory devices.
General Format:
TYPEM devi:[filnam.ext]
(If devi is omitted, the default is the system device.)
Non-directory device example: In the following example, the Load Map
is returned to memory from paper tape, via a TTY-reader (KB), and
output on the console.
*TYPEM KB:
;Return Load Map and output. on
;console
Directory device example: In the following example, the Load Map file
(LMPl.MAP) is returned to memory from RKll Disk Drive One (DKl) and
output on the line printer.
*TYPEM DK1:LMPl.MAP
;Return Load Map from Disk
;One and output on console.
Retrieve Map and Output On Line Printer (PRINTM)
The PRINTM Command is used to retrieve a previously stored copy of the
Load Map, from either a non-directory (e.g., paper tape) or directory
(e.g., disk) medium, for output on the line printer.
The command
utilizes a general format in which the filename argument is only
required for directory devices.
General Format:
PRINTM devi:[filnam.ext]
(If devi is omitted, the default is the system device.)
Non-directory device example: In the following example, the Load Map
is returned to memory from paper tape via a High-Speed Reader (PR) and
output on the line printer.
*PRINTM PR:
;Return Load Map and output on
;line printer.
Directory device example: In the following example, the Load Map file
(LMPl.MAP) is returned to memory from Floppy Disk Drive Zero (DXO) and
output on the line printer.
*PRINTM DXO:LMPl.MAP
;Return
Load
Map
from
Disk
Zero
;and output on
Check Object Module (CHECK)
line
printer.
76
Page 69
The CHECK Command is used to examine an object module, from either a
non-directory (e.g., paper tape) or directory (e.g., disk) device, for
proper formatting and/or a Checksum error.
The command utilizes a
general format in which the filename argument is only required for
directory devices.
General Format:
CHECK devi:(filnam.ext]
(if devi is omitted, the default is the system device.)
Non-directory device example:
High-Speed Reader (PR).
Input module for check from paper
*CHECK PR:
;Check
object
module
tape
format
and
;Checksum
Directory device example: Input module file
from RKll Disk Drive Zero (DKO).
*CHECK DKO:XRKAGO.OBJ
(XRKAGO.OBJ)
for
check
;Check object module file for
;proper format and checksum.
Return to XXDP+ Monitor (EXIT)
The EXIT command is used to leave the configurator/linker program and
return to the XXDP+ monitor.
This command does not clear the
configurator/linker program from memory and does not reload the XXDP+
monitor.
_.*EXIT
,
;Return to the
;currently-loaded
;XXDP+ monitor
Reload XXDP+ Monitor (BOOT)
The BOOT Command is used to reload the XXDP+ Monitor
the system.
*BOOT MTO:
associated
with
;Load the TMDP Monitor from
:Magtape Drive Zero.
3.2.4.2.4
General Utility Command
The Modify Command (MOD addr) may be used in or out of the Configure
Mode for the examination and/or modification of a specified location
within the configurator/linker program. The format is as follows:
76
Page 70
MOD addr
:Output the contents of the location
;specified by the absolute address
;argument (addr).
The following provides an example of the use of the Modify Command:
*MOD 4000
;open location 4000
- Program response:
004000/123456
;location 4000 contains value
:123456
Operator response:
1.
Close location 4000 by typing .
2.
Insert new value and close location 4000 by typing .
3.
Insert new value and open next word by typing .
4.
Close location 4000 and open next word by typing .
3.2.4.2.5
Command Error Messages
The Configurator/Linker program will generate error messages to
indicate that an error has occurred during the RTE build procedure.
Some examples of these errors are:
(1) the improper formatting and/or
use of a command; (2) improper C-Table construction; (3) possible
file errors;
(4) possible device errors (5) memory range and
allocation errors;
(6) programming and/or program errors.
The
following provides a li~~ing of each error message and its purpose:
? INVALID COMMAND
An invalid command has been entered;
correct and re-enter.
? INVALID NAME
An invalid name has been used in a command format or as a response to
a program request (e.g., special characters are not allowed); correct
and re-enter.
? NUMBER TOO BIG
Page 71
76
rhe number· typed in response to a program request is larger than is
allowed for the requested parameter. For example, the device count in
the C-Table must not exceed decimal 16;
vector addresses must not
exceed octal 774, etc.; correct and re-enter.
?
INVALID SWITCH
An invalid switch has been used with a command (if command will
accomodate a valid switch) or a switch has been included with a
command that does not accomodate switches.
?
CHECKSL~
ERROR
A Checksum error has occurred during the reading of a binary formatted
block.
FILNAMEXT? NON-EXISTANT FILE
THE file named FILNAM.EXT, which has been specified in the
format which does not in fact exist on the employed medium;
and re-enter.
command
correct
? END-OF-MEDIUM
This messaqe indicates that the end of an input medlum has been
reached (e.g., EOT), and can occur as the result of an unsuccessful
block search within a file (e.g., EOF).
? PROGRAM OVERFLOW
This message indicates that the block size
greater than the size of the input buffer.
?
of
the
input
file
is
NOT IN CNF MODE
This message indicates that a Configure Mode Command (e.g., DVA, veT,
BRl, etc.) has been illegally entered in non-configure mode; re-enter
Page 72
76
Configure Mode (i.e., CNF MD-XX-XXXXX-X
;Identity of RTE program
Page 79
76
MONITOR:
:Monitor Identity
C
SYSTEM SIZE:
00016 K
WRITE BUFFER ROTATION ON
:Write Buffer Rotation is On
KT ON
:Memory Management is On
LD MEDIA TSTING CLR LOC.
40
40 if load
;device is to be tested.
;RTE keyboard command prompt
CMD>
3.3.2.2
:Clear loc.
Loading Via XXDP+ Monitor
When an RTE program resides on an XXDP+ supported medium,
it resides
as a named file with a .BIN or a .BIC extension. As such, the RTE
file is loaded from the device by the associated XXDP+ monitor that is
itself booted from the device (refer to XXDP+ User's Manual).
However, if the configurator/linker program used to configure the RTE
load module is still active, a BOOT Command (refer to 3.2.2.2.3, I/O
Control Commands) may be used to return the XXDP+ monitor to memory,
effectively overlaying the configurator program. An example follows:
*BOOT DKO:
;reload and start RKDP Monitor.
In any case, when the XXDP+ monitor is successfully loaded, it will
identify itself and type a Help message. which can be terminated by
entering a Control C (AC), followed by a Filler Count option and a
monitor command prompt (.), as shown in the following example:
CHMDKBO XXDP+ DK MONITOR
BOOTED VIA UNIT#:
0
28K UNIBUS SYSTEM
ENTER DATE (DD-MMM-YY):,
RESTART ADDR:152010
THIS IS XXDP+.
TYPE "H" OR "H/L" FOR HELP.
Page 80
76
The RTE program may now be loaded by typing a LOAD Command (.L yyyyyy)
along with the appropriate file name which simply loads the program or
a RUN Command (.R yyyyyy) which both loads and starts the program.
For example:
• L DECXl
;load program;
to start type S •
.R DECXl
;load program and start at 0200=
At this point, before describing start conditions and procedures, it
should be understood that it is always best to load the RTE via the
XXDP+ monitor as opposed to loading via an XXDP+ update program. This
is due to the fact that unlike the monitor the update program does not
reveal (to the exerciser) the type of load device employed. With the
device unidentified it would be possible for data on the load medium
to be destroyed if the exerciser tested the load device.
3.3.2.3 Starting Via XXDP+ Monitor
Following the output of the XXDP+ monitor command prompt (.), the
self-starting RUN Command (.R) may be used to load and automatically
start the RTE program at the appropriate address.
However, if the
LOAD Command (.L) is used, the starting address (0200) must be
manually inserted prior to either typIng a START Command (S> or
manually depressing the START switch. In either case a restart will
necessitate both the manual insertion of the restart address (1000)
and depression of the START switch.
An example of a RUN Command
load/start follows:
;Load and start RTE program .
. R DECX70
DEC/XII EXERCISER
(MONITOR VOO.O) MD-XX-XXXXX-X
MONITOR:
E
SYSTEM SIZE:
;Monitor Identity
00384 K
WRITE BUFFER ROTATION ON
KT
;Memory capacity of system
"*"'"'
;Write Buffer Rotation is
;On.
;Memory Management Unit is
ON
PARITY
;Identity of RTE program.
MEMORY ON
CACHE ON
;On.
;Parity Memory Check is
;Cache Memory is On.
Page 81
MAP BOX ON
:UNIBUS Map Box is On.
LD MEDIA TSTING CLR LOC.
40
;Clear loc.
40 if load
;device is to be testede
;RTE keyboard command prompt
CMD>
Operating Procedures
3.3.3
The execution of DEC/XII Exerciser Programs is externally controlled
by the use of 22 types of keyboard commands (refer to Table 3-2),
while certain run-time features,
including accompanying print-outs,
may be either enabled or disabled by the optional configuration of a
Switch Register (SR).
All commands may be initiated in Command Mode (CMD». Most may also
be initiated while in Run Mode (BSY». However, some commands (e.g.,
RUN, MOD, etc.) can only be initiated in Command Mode.
Switch Register Options
3.3.3.1
The DEC/XII Monitor provides a Software Switch Register for system
usage.
Therefore the use of Hardware Switch Registers (if it occurs)
will be ignored.
The Software Switch Register bits may be
following run-time features:
BIT
SROO
co~ditioned
to
provide
the
OPERATION
=
0
SROO = 1
:Disable printing of the one-character "Null"
;message.
;Enable printing of the one-character "Null"
;message.
SRoa
=
0
;Cycle the exerciser once, through all of memory,
;then allow random relocation.
SRoa
=
1
:Cycle the exerciser through memory by the
;constant offset value, while inhibiting
:random relocation.
SR09 = 0
SR09
=1
SRIO = 0
;Enable the "RELOCATED TO" printout.
;Inhihit the "RELOCATED TO" printout.
;Report only the first three data errors occurring
:within a transferred block.
Page 82
76
SRIO
=
1
;Report all data errors.
SR12
=
1
:Permit the "END OF PASS" printouts.
SR13
=
1
:Inhibit the error and module printouts.
SR14
=
0
;After the 20th error, and following a "MODULE
:DROPPED" printout, drop the module.
SR14
=
1
:After the 20th error, inhibit the dropping of the
:module.
SR15
=
1
;After one error (hard or soft), and following a
; "MODULE DROPPED" printout, drop the module.
TABLE 3-2
LIST OF KEYBOARD COMMANDS
*Command Mode (CMD) Only
COMMAND
OPERATION
*RUN
Execute exerciser
*RUN addr
Execute exerciser at specified address
*RUNL
Lock and execute exerciser
*RUNL addr
Relocate to specified
execute exerciser
*MOD
Output contents of last modified location
*MOD addr
Output contents of address specified
*MOD modulename addr
Output contents of address specified in named
module
*KTON
Enable Memory Management
*KTOFF
Disable Memory Management
*MON
Enable Map Box
*MOFF
Disable Map Box
address,
MAP
Output maps for all modules
MAP modulename
Output map for named module
SEL
Select all modules
SEL modulename
Select named module
lock
and
Page 83
76
DES
Deselect all modules
DES modulename
Deselect named module
FILL
Output contents
location
FILL number number
Replace contents of FC/FC location and output
same
PON
Enable Parity Memory
POFF
Disable Parity Memory
ROTON
Enable Write Buffer Rotation
ROTOFF
Disable Write Buffer Rotation
LPON
Enable console output to Line Printer
LPOFF
Disable console output to Line Printer
CON
Enable Cache Memory
COFF
Disable Cache Memory
EXAM
Output last examined location
EXAM addr
Output specified location for examination
EXAM rnodulename addr
Output specified location in named module for
examination
SUM
of
FILL
CHAR/FILL
CNT
__ Output summary message for all module
SUM modulenarne
Output summary message for the named module
SWR
Output contents of Software Switch Register
SWR number
Replace contents of SWR and output same
3.3.3.2
Keyboard Commands
Basically, there are only 22 different types of keyboard commands.
However, a variety of entry formats expands the listing of Table 3-2
to 34.
A command is composed, entered, and edited by the use of certain
if characters other than those
keyboard
characters.
However,
described in this subsection are entered they will be considered
invalid by the DEC/XII Monitor and will be ignored by the command
interpreter.
Page 84
76
The following material initially describes those keyboard characters
recognized by the DEC/XII Monitor. This is followed by descriptions
of the keyboard error messages.
The subsection concludes with a
detailed analysis of each of the commands, arranged alphabetically by
command name.
3.3.3.2.1
Keyboard Character Usage
Where it applies to a given command format, any standard alphabetic (A
through Z) or numeric (0 through 9) keyboard character may be used.
However, only the following special characters (i.e., SP;
LF;
CR;
DEL;
CTRL C, U or 0) may be used to format, control, and/or edit
command entries.
SPACE Key (SP):
Depression of the Space Key generates a space code
pointer one character position to the right.
and
LINE FEED Key (LF):
Depression of the Line Feed Key advances the pointer
print line.
moves
to
the
the
next
CARRIAGE RETURN Key (CR):
Depression of the Carriage Return Key terminates command entry,
returns the pointer to the left margin, and advances to the next
print line.
RUBOUT or DELETE Key (DEL):
Depression of the Rubout Key deletes the last typed character.
Depressing the key n times deletes the last n characters. All
deleted characters are echoed at the terminal and bordered by
backslashes (\).
CONTROL Key (CTRL):
Holding the Control Key down in conjunction with a momentary
depression of either the C, U or 0 Key allows one of the following
three functions to be performed.
Initiation of Control C (AC) aborts the exerciser and returns
to Command Mode (CMD».
Initiation of Control U (AU) deletes the current line of
input back to the last CR/LF, while the current mode of
operation (i.e., CMD> or BSY» is not interrupted.
Initiation of Control
output to the terminal.
a
(AO)
suppresses
current
message
Initiation of Control S (AS) sends XOFF to the host, suspending data transmission to the terminal.
Some terminals
however, may continue printing data until their internal
character buffers or silos are empty.
76
Page 85
Initiation of Control Q (AQ) sends XON to the host,
data transmission from the host to the terminal.
3.3.3.2.2
resuming
Keyboard Error Messages
There are eight general keyboard
error
messages
related
to
inappropriate entry procedures and three additional messages which
pertain to the use of the RUN RUNL Commands only.
The general error messages are as follows:
1.
Invalid Address Message
The INVALID ADDRESS message is printed if a non-existent
address is entered, that is non-existent, greater than 16
bits, or otherwise not allowed by the monitor.
2.
Invalid Command Message
The INVALID COMMAND message is printed if a command, other
than those listed in Table 3-2, is used.
In addition, the
message includes the invalid command entry ( e . g • , I NV AL I D
COMMAND- - MAPP) .
3.
Invalid Command In Run Mode Message
The INVALID COMMAND IN RUN MODE message is prinfed if a
command (e.g., RUN, RUNL, MOD, etc.) is entered while in Run
Mode (BSY) which is restricted to being entered in Command
Mode (CMD) only.
4.
Invalid Module Name Message
The INVALID MODULE NAME message is printed if the name is not
five characters in length or is otherwise unrecognizable to
the monitor.
5.
Invalid Or Missing Argument Message
The INVALID OR MISSING ARGUMENT message is printed if an
argument is either improperly included in a command format or
is missing (e.g., MOD modulename with addr missing).
6.
Must Be Even Address Message
The MUST BE EVEN ADDRESS message is
printed
if
an
odd-numbered address is entered for the address argument
(addr).
7.
Not An Octal Number Message
The NOT AN OCTAL NUMBER message is printed if the number
argument entered is other than an octal number (i.e., 0-7) or
Page 86
76
contains an alphabetic.
8.
Number Too Large Message
The NUMBER TOO LARGE message
argument entered exceeds the
(i.e., 177777 octal).
is printed if the number
allowable maximum of 16 bits
The RUN and RUNL error messages are as follows:
1.
Address-OK-But-Exerciser-Won't-Fit Message
The ADDRESS OK BUT EXERCISER WON'T FIT message is printed if
there is not enough room to contain the exerciser between the
address specified, by either command, and the top of memory.
2.
Must-Have-KT-On Message
The MUST HAVE KT ON message is printed if an address argument
is specified with either command and the Memory Management
Unit (KTl1) is Off.
3.
No-Modules-Selected Message
The NO MODULES SELECTED message is printed if the user enters
either command with all modules deselected.
4.
Map Box Must Be On Message
The MAP BOX MUST BE ON message is printed if the user
specifies an address argument greater than 96K(600000) and
22-bit mapping is disabled(MOFF Command).
3.3.3.2.3
Keyboard Command Analysis
The following material provides a detailed analysis of each of the
keyboard commands.
The commands are alphabetically arranged and a
detailed description of the command is provided.
COFF Command
CON Command
DES Command
EXAM Command
FILL Command
KTOFF Command
KTON Command
LPOFF Command
LPON Command
MAP Command
MOD Command
MOFF Corrunand
MON Command
POFF Command
PON Command
ROTOFF Command
;Cache-Off Command
;Cache-On Command
;Deselect Command
;Exarnine Command
;Filler Word Command
;KT-Off Command
;KT-On Command
;Line Printer off Command
;Line Printer on Command
;Mapping Command
;Modify Command
;UNIBUS Map-Off Co~~and
;UNIBUS Map-On Command
;Parity-Off Command
;Parity-On Command
;Rotation-Off Command
Page 87
76
RaTON Command
RUN Command
RUNL Command
SEL Command
SUM Command
SWR Command
;Rotation-On Command
;Run Mode Command
;Run Locked Command
;Select Command
;Surnmary Command
;Switch Register Command
! COFF Command !
Function
The Cache Off Command (COFF) is used to disable a system's
Memory.
Cache
Format
COFF
;turn off cache memory.
Characteristics
A system's Cache Memory is automatically enabled when
an
exerciser program is started.
However, the memory may be
disabled via the COFF Command and re-enabled by executing a Cache
On Command (CON).
Associated Messages
Refer to subsection
Example
.COFF ;disable cache memory.
Page 88
76
! CON Command !
Function
The Cache On Command (CON) is used to re-enable a system's
Memory.
Cache
Format
CON
;turn on cache memory.
Characteristics
A system's Cache Memory is automatically enabled when
an
exerciser program is started.
However, the memory may be
disabled by executing a Cache Off Command (COFF) and re-enabled
via the CON Command.
Associated Messages
Refer to subsection
Example
.CON
;re-enable cache memory.
Page 89
76
! DES Command !
Function
The Deselect Command (DES) allows
specified module to be deselected.
all
modules
or
a
single
Format
General:
DES [modulename]
1.
DES
Deselect all modules.
2.
DES modulename
Deselect the specified (modulename) module.
Characteristics
When the exerciser is initially loaded, all
modules
are
automatically selected for execution;
this is the default
condition. However, if the user desires to run a single module,
the remaining modules must be deselected;
and if the user
desires to run all modules except one, the exception must be
deselected.
Thus, the Deselect Command (DES) is generally used
in conjunction with a Select Command (SEL).
The latter allows
all modules, or a specified module, to be selected.
Example: To deselect one module:
SEL
DES modulename
;select all modules
;deselect named module
Example: To deselect all but one module
DES
SEL modulename
;deselect all modules
;select named module
Restrictions
The modulename argument must be five
Associated Messages
Refer to subsection
Examples
c~aracters
in length.
Page 90
76
Format 1:
.DES
:deselect all modules
Format 2:
.DES DCAAO
:deselect Module DCAAO
Page 91
76
! EXAM Command !
Function
The examine Command (EXAM) is used to output the contents of the
location specified by either the last EXAM Command or the current
command.
Format
General:
EXAM[[modulenarne]addr]
1.
EXAM
Output the contents of the last examined location.
2.
EXAM addr
Output the contents of the location specified by the
argument (addr).
3.
address
EXAM modulename addr
Output the contents of the location, specified by a relative
address (addr) within the named module (modulename).
Characteristics
The EXAM Command makes it possible to examine the contents of a
location while the system is operating in the Run Mode (BSY».
When Format 1 is used, the contents of the last location accessed by
an EXAM Command will be output.
When Format 2 is used,--the address argument specifies a virtual
address.
When Format 3 is used, the address argument specifies the offset value
for a word, within a named module, relative to the virtual base
address of the module. However, the Monitor response defines the word
address relative to the virtual base address of the exerciser.
Restrictions
The address argument has a maximum length of 16 bits.
The modulename argument must be five characters in length.
Associated Messages
Refer to subsection
Examples
Page 92
76
Format 1:
. EXAM
;output contents of last EXAM location •
Monitor response:
053772/002345
;002345 is the contents of location
;053772
Format 2:
• EXAM 053776
;output contents of location 053776 •
Monitor response:
053776/000005
;000005 is the contents of location
;053776.
Format 3:
. EXAM LPAEO 36
Monitor response:
053774/000004
;output word 36 from Module LPAEO .
;000004 is word 36 (in Module LPAEO)
;from location 053774.
Page 93
76
! FILL Command !
Function
The Fill Command (FILL) is used to output a combination Fill Character
and Filler Count word for examination and/or complete alteration.
Format
General:
FILL[number number]
1.
FILL
Output the FILL CHAR/FILL CNT word.
2.
FILL number number
Replace the FILL CHAR (number)/FILL
output same.
CNT
(number)
word
and
Characteristics
In relation to a particular console device (e.g., LA30S, VT05B, etc.),
the detection of an associated Fill character (e.g., Carriage Return,
Line Feed, etc.) allows an optional number of Filler Characters (i.e.,
non-printable null characters) to be recognized in order to delay
message output while mechanical adjustments are made to the pointer.
For example:
following detection of a Carriage Return Code (158), a
number of Filler Characters, defined by the Filler Count, provide an
appropriate delay while the pointer is being returned to the left
margin, thus eliminating-garbled output.
The Fill argument (number number) consists of a maximum of 16 bits (2
bytes):
The low-order byte contains the Filler Count (FILL CNT),
while the high-order byt~ contains the Fill Character (FILL CHAR)
required by the console (i.e., CR, LF, etc.).
012
014
!----------FILLER COUNT BYTE
!-----------------FILL CHARACTER BYTE
Restriction
The Fill argument (number number) must consist of octal digits.
If the entire argument is replaced, a space must be inserted
between the numbers (i.e., character and count).
Associated Messages
Page 94
76
Refer to subsection
Examples
Format 1:
• FILL
Monitor response:
FILL/006401
Format 2:
.FILL 15 14
Monitor response:
FILL/006414
;output current Fill Word •
;FILL CHAR is CR with FILL COUNT of One,
;right justified (0 000 110 100 000
;001).
;rep1ace character with CR and
;count with 14, output same.
;replacement right justified.
Page 95
76
!
KTOFF Command !
Function
The Memory-Management-Off Command (KTOFF) is used to disable the
Memory Management Unit (KT) and clear its status indicator (KTSTAT)0
Format
KTOFF
;Disable the Memory Management Unit
Characteristics
If a Memory Management Unit (KT) is available to a system, the unit is
automatically enabled when a DEC/XII Exerciser Program is loaded and
started. The KT Status (KTSTAT) indicator is then set and mapping
occurs as required.
The user now has the option in Command Mode
(CMD» of disabling (KTOFF) the unit or re-enabling (KTON) the unit,
as the case may be.
Restrictions
The KTOFF command must be entered in Command Mode (CMD»
only.
Associated Messages
Refer to subsection
Example
. KTOFF
;Disable KT Unit and clear KTSTAT flag .
Page 96
76
! KTON Command !
Function
The Memory-Management-On Command
Memory Management Unit (KT).
(KTON)
is
used
to
re-enable
the
Format
KTON
;Re-enable the Memory Management Unit
Characteristics
If a Memory Management Unit (KT) is available to a system, the unit is
automatically enabled when the DEC/XII Exerciser Program is loaded and
started. The KT Status (KTSTAT) indicator is then set and mapping
occurs as required.
The user now has the option in Command Mode
(CMD» of disabling (KTOFF) the unit or re-enabling (KTON) the unit,
as the case may be.
Restriction
The KTON Command must be entered in Command Mode (CMD»
only.
Associated Messages
Refer to subsection
Example
. KTON
;Re-enable KT Unit and setKTSTAT flag .
Page 97
76
LPOFF
Function
The Line Printer Off Co~mand(LPOFF) is used to redirect
the line printer back to the console.
... , 1
Q.L.L
output for
Format
LPOFF
;turn off line printer
Characteristics
When the LPOFF Command is entered, all subsequent output(i.e.,
prompts, messages, summaries etc.) and operator input(i.e., program
querIes and request responses) are re-directed from the line printer
back to the console.
Associated Messages
Refer to subsection
Example
.LPOFF
;disable line printer
Page 98
76
LPON Command !
Function
The Line Printer On command(LPON) is used to redirect all
the console to the line printer.
output
for
Format
LPON
;turn on line printer
Characteristics
When the LPON Command is entered, all subsequent output (i.e.,
prompts, messages, summaries, etc.) and operator input (i.e., program
query and request response) are re-directed from the console(default
condition) to the line printer. Thus console echoing is effectively
disabled.
Associated Messages
Refer to subsection
Example
.LPON
;enable line printer
Page 99
76
! MAP Command !
Function
The Mapping Command (MAP) is used to output a message from the monitor
concerning the identity and current status of all of the resident
modules, or single specified modulee
Format
General: MAP [modulenarne]
1.
MAP
Output Map message information for all modules.
2.
MAP modulename
Output Map message information for the named module.
Characteristics
Each line of a Map message
1S
formatted as follows:
{modulenarne} AT VA: (address) STAT:
(status word)
Modulename:
The five-character modulename indicates the following:
R K A D
a
!------Copy Number (0-7)
!--------Version Letter
!-------------Identifier Letters
Address:
The virtual address defines the first word of the module
zero of the header).
(i.e.,
word
Status Word:
With the exception of bits 11, 13 and 14, the remaining bits of the
16-bit status word (00-15) are used to define the module type (i.,e.,
Input/Output, Background, etc.); while bits 11, 13, and 14 are used
to define the current status of the module (i.e., Active, Dropped, or
Selected), as follows:
Excepting bits 11, 13 and
14:
all
bits
cleared
(000000)
76
Page 100
indicates a Special Background Module (SBKMOO).
Excepting bits 11, 13 and 14:
a Background Module (BKMOD).
bit 04 set (000020)
indicates
Bit 11 set indicates the module is Active.
Excepting bits 11, 13 and 14: bit 09 set (001000)
a Non-Background Module (NBKMOD).
indicates
Excepting bits 11, 13 and 14:
an I/O Module (IOMOD).
indicates
bit 15 set (100000)
Excepting bits 11, 13 and 14: bits 10 and 15 set (102000)
indicates a Partially Restricted I/O Module (IOMODP).
Excepting bits 11, 13 and 14:
bits 10, 12 and
(112000) indicates a Restricted I/O Module (IOMODR).
Excepting bits 11, 13 and 14: bits 12 and
indicates an Extended I/O Module (IOMODX).
15
set
15
(110000)
Bit 13 set indicates that the module has been Dropped.
Bit 14 set indicates that the module has been Selected.
Restrictions
The modulename argument must be five characters in length.
Associated Messages
Refer to subsection
Examples
Format 1:
• MAP
:Map all modules •
Monitor response:
RKADO AT VA: 021544 STAT: 150000
TCADO AT VA: 034700 STAT: 130000
CPADO AT VA: 042346 STAT: 40020
: IOMODX Module RKADO is
selected.
: IOMODX Module TCADO is
dropped.
:BKMOD Module CPADO is
selected.
Format 2:
.MAP TAACO
:Map Module TAACO
set
76
Monitor response:
TAACO AT VA: 037460 STAT: 140000
Page 101
: IOMOD Module TAACO
is selected.
Page 102
76
! MOD Command !
Function
The Modifv Command (MOD) is used to examine and/or modify the contents
of selected storage locations.
Format
General: MOD [[modulenarne] addr]
1.
MOD
Output the contents of the last modified location.
2.
MOD addr
Output the contents of the location specified by the absolute
address argument (addr).
3.
MOD modulename addr
Output the contents of the location specified by both the
module name and its associated relative address argument
(modulename addr).
Characteristics
The MOD Command makes it-possible to open and/or modify absolute as
well as relative addresses (i.e., relative to the starting address of
the specified module).
In addition, when a relative address is
specified, the monitor will respond by printing the equivalent
absolute address.
Restrictions
The MOD Command must be entered in Command Mode (CMD»
only.
All specified addresses must be less than 32k words or the
available address, whichever is smaller.
All specified addresses must be even.
Associated Messages
Refer to subsection
largest
Page 103
76
Examples
Format 1:
• MOD
;open last modified location •
Format 2:
• MOD 4000
;open location 4000 .
Monitor response:
004000/123456
:location 4000 contains value 123456.
Operator response:
1.
Close location 4000 by typing .
2.
Insert new value and close location 4000 by typing .
3.
Insert new value and open next word by typing .
4.
Close location 4000 and open next word by typing .
Format 3:
.MOD DCAAO 20
;open relative location 20 in Module
;DCAAO (10TH OCTAL word).
Monitor response:
012020/140000
:absolute address of 10th octal word
:012020 and contents of location are
140000.
Operator response:
Operator has the same four options described for Format 2.
IS
Page 104
76
! MOFF Command !
Function
The UNIBUS-Map-Off
mapping logic.
Cow~and
(MOFF) is used to disable a system's UNIBUS
Format
MOFF
;turn off the UNIBUS Map Logic.
Characteristics
The UNIBUS mapping hardware is automatically enabled when
the
exerciser is started. The logic may be disabled via the MOFF Command
and re-enabled by executing, in Command Mode (CMD»
only,
a
UNIBUS-Map-On Command (MON).
Restrictions
The MOFF Command may be entered in Command Mode (CMD»
only.
Associated Messages
Refer to subsection
Example
• MOFF
;disable the UNIBUS Map Logic .
Page 105
76
! MON Command !
Function
The UNIBUS-Map-On Command (MON) is
UNIBUS mapping logic.
used
to
re-enable
the
system's
Format
MON
;turn on UNIBUS Map Logic
Characteristics
The UNIBUS mapping hardware is automatically enabled when
the
exerciser is initializede The logic may be disabled by executing, in
Command Mode (CMD» only, a UNIBUS-Map-Off Command (MOFF). The logic
may then be re-enabled via the MON Command.
Restrictions
The MON Command may be entered in Command Mode (CMD»
only.
Associated Messages
Refer to subsection
Example
• MON
;re-enable the UNIBUS Map Logic .
Page 106
76
! POFF Command !
Function
The Parity-Off Command (POFF) is used to disable the
Check Logic.
system's
Parity
Format
POFF
;disable parity checking logic.
Characteristics
The parity checking hardware is automatically enabled when the
execiser program is initialized. The logic may be disabled via the
POFF Command and re-enabled by executing a Parity-On command (PON).
Associated Messages
Refer to subsection
Example
. POFF
~disable
parity checking logic .
76
Page 107
! PON Command !
The Parity-On Command (PON) is used to re-enable a system's Parity
Check Logic.
The logic is used to verify the integrity of data
transfered from Main Memory or Cache Memory.
Format
PON
;turn on parity checking logic
Characteristics
The parity checking hardware is automatically enabled when the
exerciser program is initialized.
The logic may be disabled by
executing a Parity-Off Command (POFF) and re-enabled via the PON
Command.
Associated Messages
Refer to subsection
Example
.PON
;re-enable parity checking logic
Page 108
76
! ROTOFF Command !
Function
The Rotation-Off Command (ROTOFF) is
Rotation.
used
to
disable
Write
Buffer
Format
ROTOFF
:turn off Write Buffer Rotation.
Characteristics
Write Buffer Rotation is automatically enabled when an exerciser
program is initialized.
The feature may be disabled via a ROTOFF
Command and re-enabled by executing a Rotation-On Command (ROTON).
Associated Messages
Refer to subsection
Example
. ROTOFF
;disable Write Buffer Rotation .
Page 109
76
----------------! ROTON Command !
Function
The Rotation-On Command (ROTON) is
Rotation.
used
to
re-enable
Write
Buffer
Format
ROTON
:turn on Write Buffer Rotation.
Characteristics
Write Buffer Rotation is automatically enabled when an exerciser
program is initialized.
The feature may be disabled by executing a
Rotation Off Command (ROTOFF) and re-enabled via a ROTaN Command.
Associated Messages
Refer to subsection
Example
. ROTON
;re-enable Write Buffer Rotation .
Page 110
76
! RUN command !
Function
The Run Co~~and (Run) is used to initiate the Run Mode (BSY»
and
start the option modules. Only those modules selected for execution
will be run.
The Run Command is identical to the RUNL Command with one exception:
The RUN Command allows the periodic relocation of the exerciser
program* if an adequate amount of core is available for relocation and
a Memory Management Unit (KT) is available and enabled.
Format
General:
1.
RUN [addr]
RUN
Initiate Run Mode (BSY»
2.
and execute option modules.
RUN addr
Initiate Run Mode (BSY» and, following an initial relocation
to the address specified, execute the option modules.
Characteristics
Module Execution Sequence:
When a RUN Command is entered, Run Mode (BSY» is initiated and the
Selected modules are executed as follows: First, single passes are
separately made through the Special Background Modules (SBKMOD).
Second, passes are separately made through the Non-Back-ground Modules
(NBKMOD). Third, the Background Modules (BKMOD) will execute a I
iteration pass. Fourth, the interrupt-driven I/O Modules (IOMOD,X,P,
AND R) are enabled.
Finally, single passes are separately made
through the Background Modules (BKMOD).
Write nuffer Rotation:
Write Buffer Rotation will occur if the operation
rotation is initially enabled by default, disabled
Command, and re-enabled by a ROTON Command.
is enabled:
via a ROTOFF
Initial Program Relocation:
As stated, if both adequate core and a KT Unit are avilable and the KT
Page I I I
76
is enabled (i.e., by default or a KTON Command), the movable* portion
of the exerciser program will be periodically relocated; however, an
initial relocation address may be specified by the user (Format 2).
If an initial relocation address is specified by the user, care must
be taken to ensure that the address chosen satisfies the memory
requirements of the movable portion of the execiser in relation to the
availability of usable core. With this assurance, initial relocation
to the nearest 32-word boundary of the address will occur prior to the
execution of the modules.
Aborting The Exerciser:
Once started, the option modules will continue to run until aborted by
one or more of the following occurrences (at which a SUM Command may
be used to provide a run-time summary of module activity):
A Control C (AC) i i entered: causing the Monitor to cease
execution of the option modules, return the program to its
original memory space (if necessary) and return the system to
Command Mode (CMD».
All modules are dropped due to module errors:
causing the
Monitor to return the program to its original memory space
(if necessary) and return the system to Command Mode (CMD».
The occurrence of a fatal error (e.g., too many system errors
occur): causing the Monitor to cease execution of the option
modules, return the program to its original memory space (if
necessary), and return the system to Command Mode (CMD».
Restrictions
The RUN Command mustJ5e entered
1n
The address argument (addr) has
20,000*
a
Command Mode (CMD».
minimum
restriction
of
octal
the address argument (addr) must satisfy both the core requirements
of the exerciser and the core availability of the system.
Associated Messages
Refer to subsection
Examples
*A portion of the execiser program always resides in the lowest 4K
words of memory, within a range of 0-17776(8), and is never relocated.
Page 112
76
Format 1:
.RUN
;start with a relocation offset of zero
Format 2:
.RUN 360000
;re1ocate to 360000 and start
Monitor response:
RELOCATED TO 360000
~response
to valid address.
Page 113
76
! RUNL Command !
Function
The Run-Locked Command (RUNL) is used to initiate the Run Mode (BSY»
and start the option modules.
Only those modules selected for
execution will be run.
The RUNL Command is identical to the RUN Command with one exception:
The RUNL Command inhibits periodic relocation of the movable* portion
of the execiser program by locking in the load address or the initial
relocation address that may be defined by the user.
Format
General:
1.
RUNL [addr]
RUNL
Initiate Run Mode (BSY», lock, and start option modules.
2.
RUNL addr
Initiate Run Mode (BSY», relocate to user specified
(addr), lock and start option modules.
address
Characteristics
Module Execution
Sequen~~:
When a RUNL Command is entered, Run Mode (BSY» is initiated, and the
Selected modules are executed as follows: First, single passes are
separately made through the Special Background Modules (SBKMOO);
second, single passes are separately made through the Non-Background
Modules (NBKMOD); third, the Background modules (BKMOn) will execute
a
1 iteration pass;
fourth, the interrupt-driven I/O Modules
(IOMOD,X,P and R) are enabled: finally, single passes are separately
made through the Background Modules (BKMOO).
Write Buffer Rotation:
Write Buffer Rotation will occur, for initial relocation, if the
operation is enabled.
Rotation is initially enabled by default,
disabled via a ROTOFF Command, and re-enabled by a ROTaN Command.
Initial Program Relocation:
If both adequate core and a KT Unit are available, and the KT is
enabled
;start with a relocation offset of
;Zero locked.
Format 2:
.RUNL 360000
;relocate to 360000, lock and start.
RELOCATED TO 360000
;response to valid address.
Page 116
76
! SEL Command !
Function
The Select Command (SEL) allows all modules,
module, to be selected for execution.
or
a
single
specified
Format
General: SEL [modulename]
1.
SEL
Select all modules for execution.
2.
SEL modulename
Select the specified (modulename) module for execution.
Characteristics
When the exerciser is initially loaded, all modules are automatically
selected for execution; this is the default condition. However, if
the user desires to run a single module, the remaining modules must be
deselected and, if the user desires to run all modules except one, the
exception must be deselected.
Thus, the Select Command (SEL) is
generally used in conjunction with a Deselect Command (DES). The
latter allows all modules, or a specified module, to be deselected.
Example: To select one module:
DES
;deselect all modules
SEL modulename ;select named module
Example: To select all but one module.
SEL
;select all modules
DES modulename ;deselect named module
Restrictions
The modulename argument must be five characters in length.
Associated Messages
Page 117
76
Examples
Format 1:
.SEL
;select all modules
Format 2:
.SEL DCAAO
;select Module DCAAO
76
Page 118
! SUM Command !
Function
The Summary Corr~and (SUM) is used to output a summary message for each
resident module, or a specified module, concerning: module identity;
current status; the decimal number of passes, hard errors, soft
errors, system errors and power failures. The last two items will not
be output if only a single module is specified.
Format
General:
1.
SUM [modulename]
SUM
Output summary message for each resident module.
2.
SUM modulename
Output summary message line for
module.
the
specified
(modulename)
Characteristics
SUM Command may be entered in the Run Mode
summary message that is formatted as follows:
(BSY»
A
(mod name) AT VA:
SFTERRS (nurn)
SYSTEM ERRORS:
(addrJ STAT (stat wd)
(num)
PASS
POWER FAILS:
(#num)
providing
HRDERRS
a
(num)
(num)
Modulename:
The five-character modulename inidcates the following:
R K ADO
!-------Copy Number <0-7)
!
!---------Version Letter
!-------------Identifier Letters
Address:
The virtual address defines the first word of the module
zero of the header).
(i.e.,
word
Page 119
76
~tatus
Word:
with the exception of bits 11, 13 and 14, the remaInlng bits of the
16-bit status word (00-15) are used to define the module type (i.e.,
Input/Output, Background, etc.). Bits 11, 13 and 14 are used to
define the current status of the module (i.e., Active, Dropped, or
Selected), as follows:
Exceotinq bits 11, 13 and 14:
all bits cleared
indicates a Special Background Module (SBKMOn).
Excepting bits 11, 13 and 14:
a Background Module (BKMOD).
bit 04 set (000020)
(OOOOOO)
indicates
Bit 11 set indicates the module is active.
Excepting bits 11, 13 and 14: bit 09 set (001000)
a Non-Background Module (NBKMOD).
indicates
Excepting bits 11, 13 and 14: bits 10 and 15 set (102000)
indicates a Partially Restricted I/O Module (IOMODP).
Excepting bits 11, 13 and 14:
bits 10, 12 and
(104000) indicates a Restricted I/O Module (IOMODR).
Excepting bits II, 13 and 14: bits 12 and
indicates an Extended I/O Module (IOMODX).
15
set
15
set
(110000)
Bit 13 set indicates that the module has been Dropped.
Bit 14 set indicates that the module has been Selected.
Number:
All number items that are output have a maximum range of five
digits.
Restrictions
The modu1ename argument must be five characters in length.
Associated Messages
Refer to subsection Examples
Format 1:
.SUM
Monitor response:
;summarize all modules
decimal
76
Page 120
SUMMARY AT RUNTIME:
000:02:52*
LPAEO AT VA: 053734 STAT 150000 PASS #00000 HRDERRS 00000
SFTERRS 00000
TCAFO AT VA: 055310 STAT 150000 PASS #00000 HRDERRS 00000
SFTERRS 00000
SYSTEM ERRORS:
00000
POWER FAILS:
00000
Format 2:
• SUM
RKAFO
;summarize Module RKAFO.
Monitor response:
RKAFO AT VA:
054524 STAT 150000 PASS #00000 HRDERRS 00000
SFTERRS 00000
*Time entry will only occur if a Real-Time Clock is available
system.
to
the
Page 121
76
! SWR Command !
Function
The Switch-Register Command (SWR) is used to output the contents of
the Software Switch Register (SR), for analysis and/or replacement.
Format
General:
1.
SWR [number]
SWR
Output the current contents of the Software Switch Register.
2.
SWR number
Replace (number) the contents of the Software Switch Register
and output the same.
Characteristics
The SWR Command conditions the l6-bit Software Switch Register to
provide a combination of the run-time features described in subsection
3.3.3.1.
Associated Messages
Refer to subsection
Examples
Format 1:
. SWR
;output contents of SWR .
Monitor response:
SWR/ 112000
;refer to subsection 3.3.3.1 for decode.
Format 2:
.SWR 053401
;place 053401 in SWR and output same
Monitor response:
SWR/ 053401
;replacement verfication.
76
Page 122
3.3.3.3
Operator Modifications
Necessary modifications to Monitor and/or Option Module locations are
initiated in Command Mode (CMD» and accomplished via the use of the
Modify Command (MOD).
3.3.3.3.1
Monitor Modifications
3.3.3.3.2
Option Module Modifications
Although a user may modify any location within an option module via
the MOD Command, the most common modifications are related to changes
desired in test criteria MOD WXYZO 6
52346/006000
l72460
;lst device address.
CMD>
Word 10 (VECTOR):
Device/Option Vector Address
Module Header Word 10 (VECTOR) must specify the vector address for the
first device or option to be tested. If more than one address is
required, VECrOR will specify the first of a contiguous grouping.
Header Word 10 (VECTOR) Example:
CMD> MOD WXYZO lO
52350/000000
CMD>
230
:lst device
vector~
76
Page 123
lord 12 (BR1,BR2):
Bus Priority Levels
Module Header Word 12 (BRI,BR2) specifies, via the high order (BRI)
~nd low orde: (BR2) brte respectively, the priority levels required by
lnterrupt-drlven devlces.
Normally, only BRl will be required.
However, BR2 must be specified if the device is capable of separate
levels of interrupt.
Header Word 12 (BRI,BR2) Example:
CMD> MOD WXYZO 12
52352/000000 300
;lst BR level is PRTY6.
CMD>
;2nd BR level is unused.
Word 14 (DVIDl):
Device Indicator Count
Module HEader Word 14 (DVID1) indicates the total number of active
devices to be tested (up to 16) via the number of bits that are set
(1) in the word.
The word also specifies the device(s) selected
(0-15) via the corresponding weight of the bit positions.
Header Word 14 (DVIDl) Example:
CMD> MOD WXYZO 14
52354/000000
;Device Indicator One specifies that
;Device 0 and Device 1 (0 000 000 000
;000 011) are to be tested.
3 MOD WXYZO 16
52356/000000
100000
;Software Switch Register One is open.
CMD>
Word 36 (ICONT):
Iteration Constant
76
Page 124
Module Header Word 36 (ICONT) indicates the number of times that a
module will be run prior to an End-Of-Pass and may be configured at
the user's discretion.
Header Word 36 (ICONT) Example:
CMD> MOD WXYZO 36
52376/004000 100
;count provides 64 decimal passes.
CMD>
3.3.3.4
Message Print-Outs
Message print-outs may be divided into the following three categories:
Keyboard Error Messages: which indicate an inappropriate
of the Keyboard Commands (refer to subsection 3.3.3.2.2).
use
Normal Run-Time Messages: which indicate the occurrence and/or
completion of normal functions of the program.
Run-Time Error Messages: which indicate abnormal
within the program and/or its associated devices.
3.3.3.4.1
occurrences
Normal Run-Time Messages
There are five normal run-time messages that can be generated
RTE program:
by
any
End Of Pass PrintoutModule Dropped Printout
ASCII Message Printout
Relocated To Printout
Power Failure Printout
End Of Pass Printout
End Of Pass is an optional message, the generation of which when
enabled by the setting of bit twelve in the Software Switch Register
(SR12 = 1) indicates that a complete pass through a specific module
has been completed.
However, due to the possibility that the
generation of the printout may significantly decrease throughput, the
message is normally inhibited (SR12 = 0). In any case, following the
generation of an End Of Pass printout, a reexecution of the specified
Page 125
76
nodule will occur except when the pass is completed for a background
module, in which case the monitor will start executing the next
background module.
The End Of Pass Printout is as follows:
CPAFO END PASS #00034.
RUNTIME:
000:11:37 PSTIME:
000:00:37
Where:
CPAFO identifies the module and END PASS #NNNNN defines the decimal
number
of
completed
passes.
RUNTIME!PSTIME
HRS:MINS:SECS
respectively define the total run and pass times (zeroed if a
system clock is not available).
Module Dropped Printout
A Module Dropped printout may be initiated by a module for itself via
an END Call or may be generated by the monitor as a conditioned
response (e.g., via switch reglster settings) to errors occuring
within a module.
In either case, following the printout, a module
that has been dropped cannot be reexecuted until Command Mode(CMD» is
re-entered via AC and Run Mode(BSY» is reinitiated via RUN or RUNL
command. available to the program.
The Module Dropped message is conditionally generated as follows:
Via an END Call, following the occurrence of a condition that
the module defines as abnormal (e.g., no drives available).
Via the monitor, if the total number of allowable
errors (i.e., four) for the modules is exceeded.
systems
Via the monitor, in conjunction with the setting of Software
Switch Register bit 15 {SR15 = l}, following the occurrence of
an error (whether acknowledged by printout or not).
Via the monitor, if Software Switch Register bit 14 is reset
(SR14 = O) and the 20th hard or 40th soft error has occurred
(whether acknowledged by printout or not).
If bit 14 is set
(SR14 = 1), the message will not be printed and the module will
not be dropped.
The Module Dropped Printout is as follows:
CPAFO DROPPED AT APC XXXXXX
Where:
CPAFO identifies the dropped module and APC XXXXXX defines the
Assembled Program Counter address (as opposed to the physical
address) where the drop occurred.
Page 126
76
ASCII Message Printout
In addition to standard message generation, the monitor provides each
module with an ASCII message capability which may be used to report
conditions and/or statistics. Typical ASCII message printouts are as
follows:
LPAAO PA XXXXXXXX APe YYYYYY PASS# NNNNN
;defining:
22-bit
Physical Address (PA of
;module LPAAO, IS-bit
Assembled Program
;Counter (APC) address,
and decimal number
;of completed passes.
RKAAO PA XXXXXXXX APC YYYYYY PASS# NNNNN
;sarne data as
above
with test information:
;decimal number of I/O
transfers
;decimal
number
of
recoverable errors
;decimal
number
of
unrecoverable errors
DATA TRANSFERS:
XXX XXX
SOFT ERRORS:
YYYYYY
HARD ERRORS:
ZZZZZZ
LP IS OFF LINE
;line printer status
Relocated To Printout
When the entire exerciser program is relocated in memory, as described
in the RUN and RUNL Command analysis, a Relocated To message is
generated which includes_the physical address to which relocation has
occurred:
RELOCATED TO XXXXXXOO
Where: XXXXXXOO implies a 22-bit
relocation has occured.
octal
physical
address
to
which
Power Failure Printout
Following a power failure, when a restart is initiated, the original
mode of operation is reactivated (i.e., BSY> or CMD> mode) and the
Power Failure message is output, as follows:
POWER FAILURE OCCURRED
Although this printout provides an awareness of a malfunction, it is a
normal message as opposed to an RTE error message which would indicate
an error by RTE software.
76
Page 127
3.3.3.4.2
RTE Run-Time Error Messages
There are ten RTE run-time error messages that can be generated by
RTE program:
an
System Error Printout
Soft Error Printout
Hard Error Printout
Extended Soft Error Printout
Extended Hard Error Printout
Data Error Printout
Monitor Data Error Printout
Memory Management Error Printout
Memory Parity Error Printout
BAD Vector Printout
System Error Printout
A System Error message is output whenever a Bus
location four, or a Reserved Instruction Trap,
occurs. The message printout is as follows:
Error Trap, to
to location ten,
**** SYSTEM ERROR ****
VECTOR
PC+
ADDR
PSW
SP
ERCT
AAAAAA BBBBBB CCCCCC DDDDDD EEEEEE FFFFFF
AT GGGGG HHHHHH
Where:
AAAAAA
BBBBBB
CCCCCC
DDDDDD
EEEEEE
FFFFFF
GGGGGG
HHHHHH
- is 000004 if Bus Error Trap and 000010 if Reserved
Instruction Trap.
- is Program Counter address pushed on stack at time
of failure.
- is actual physical address of error. If no relocation,
CCCCCC = BBBBBB.
- is Processor Status Word at time of failure.
- is contents (virtual addr.) of Stack Pointer Register
at time of failure.
- is the System Error count in decimal.
- is module name, if error occurred within an
option module.
- is Assembled Program Counter (APC) address, if error
occurred in option module.
76
Page 128
Once the system error message has been output, the monitor will
the following:
If, when the error occurred, tqe system was in
(CMD», it will remain in Command Mode.
Command
cause
Mode
If, when the error occured, the system was in Run Mode
(BSY», or in Chain Mode, Run Mode will be reinitiated.
Moreover, pass count and error count data will not be
cleared.
For additional message possibilities
Special System Error Printouts.
refer
to
section
entitled:
Soft and Hard Error Printouts
In regard to an operating system, Soft Errors are recoverable and Hard
Errors are not.
In regard to an exerciser program, soft and hard
error message information is identical, with an exception only to type
(i.e., SOFT or HARD).
The following is an example of a Hard Error printout:
ABCDO PA XXXXXXXX APC YYYYYY PASS# NNNNN HARD ERR# NNNNN
CSRA AAAAAA eSRe ccecce STATe SSSSSS ERRTYP NNNNN
Where:
ABCDO
PA XXXXXXXX
APC YYYYYY
PASS # NNNNN
HARD ERR#NNNNN
CSRA AAAAAA
CSRA ceccce
STATC SSSSSS
ERRTYP NNNNN
- 1S name of failing module
- is actual 22-bit physical address of
error calls
- is Assembled PC of error call
- is decimal pass number during which
error occurred.
- is total decimal number of hard errors
encountered.
- is address of Control Status Register
for failing device (if any).
- is contents of device CSR (if any).
- is contents of Device Status Register
(if any).
- is octal code which defines the type of
error (for meaning of code refer to
DEC/Xll Cross Reference Manual).
Locating the error call that evoked the message:
Referring to the listing the user may locate the call
error message, by referencing the address defined
Program Counter (APe yyyyyy) printout. To facilitate
error calls are clearly emphasized within the listing
asterisks(*).
Extended Soft and Hard Error Printouts
which evoked the
by the Assembled
this task, all
by a boundary of
76
Page 129.
xtended Soft and Hard Error messages contain the same information
described for Soft and Hard Error Printouts.
With an extended
printout, one or more additional lines of error information are
provided which may consist of up to eight octal values per line. The
meaning of this additional data, for the module specified, may be
found in the DEC/XII Cross Reference Manual.
The following is an example of an Extended Hard Error printout:
ABCDO PA XXXXXXXX APe YYYYYY PASS# NNNNNHARD ERR' NNNNN
CSRA AAAAAA CSRC CCCCCC STATe SSSSSS ERRTYP NNNNN
XXX XXX
XXXXXX
XXX XXX
XXXXXX
XXXXXX
XXX XXX
XXXXXX
XXXXXX
Locating the error call that evoked the message is accomplished in the
manner described in Soft and Hard Error Printouts.
Data Error Printout
with the exception of Extended I/O Modules (IOMODX), all test modules
report data transfer errors via a Data Error printout, that is invoked
by a DATERS Call. The message is as follows:
DCAAO PA XXXXXXXX APC YYYYYY PASS# MMMMM ERR# NNNNN DATA ERROR
CSRA AAAAAA S/B BBBBBB WAS WWWWWW WRADR DDDDDD RDADR EEEEEE
Ihe re:
DCAAO
PA XXXXXXXX
APC YYYYYY
PASS NNNNN
ERR
NNNNN
CSRA AAAAAA
SIB BBBBBB
WAS WWWWWW
WRADR DDDDDD
RDADR EEEEEE
- is name of failing module.
- is 22-bit physical address of DaterS
Call
- is Assembled PC address of DATERS Call.
- is decimal pass number during which
error occurred.
- is total decimal error count for current
test run.
- is address of Control Status Register
for failing device.
- is good expected data.
- is bad obtained data.
- is write address of good and expected
data.
- is read address of bad and obtained
data.
Locating the DATERS Call that evoked the error message:
Referring to the listing, the user may locate the call that evoked the
error message by referencing -the address defined by the Assembled
Program Counter (APC yyyyyy) printout. To facilitate this task, all
DATERS Calls are clearly emphasized within the listing by a boundary
)f asterisks(*).
Page 130
76
Monitor Data Error Printout
---------------------------
Data transfer errors associated with Extended I/O Modules (IOMODX) are
detected by the monitor via a Check Data Call (CDATA$) request. This
is necessary because the modules are not mapped contiguously with
their write buffers. Thus, the data cannot be checked directly~ In
any case, a Monitor Data Error message is similar to a Data Error
printout except for the following, interpretations and additions:
All errors detected within a given transfer (e.g., a 256 word
block) will be counted as a single error (i.e., ERR# 00001).
The count will not be indicated until each error has been
reported by a separate printout. The reporting of all errors
depends on the setting of SRI0 (SRI0 = 1). If the switch is
cleared (SRI0 = 0), only three such errors will be reported.
An additional summary message is provided which defines the
total "decimal number of errors that have occurred during the
transfer.
The Monitor Check Data Error Printout is as follows:
RKAFO PA XXXXXXXX APC YYYYYY PASS# NNNNN ERR# NNNNN DATA ERROR
CSRA AAAAAA SIB BBBBBB WAS WWWWWW WRADR DDDDDD RDADR EEEEEE
RKAAO HAD NNNNN ERRORS OUT OF 256 WORDS READ
Memory Management Error Printout
Aborts and traps generated by the Memory Management Unit (KT1l) are
vectored through virtual location 250. The Memory Management Status
Registers (SRO through SR3) are used to differentiate an abort from a
trap, determine why one or the other ocurred, and allow for a program
restart.
The following printout accompanies a Memory Management abort or trap:
***
***
ececcc
SR3
ccccce eccccc
KT
SRO
CCCCCC
SRI
TRAP
SR2
iidentifies SRO and SR2
icontents Of SRO and SR2
;if SRI and SR3 are available,
icontents of SRI and SR3
Memory Parity Error Printout
Aborts and traps generated by Main or Cache Memory parity errors or
Main Memory Eee errors are vectored through virtual location 114. The
Control Status Register (CSR) will contain the failure information.
The following printout accompanies a memory parity or Eee error:
**** TRAP THROUGH VECTOR 114 ****
CSR
AAAAAA
CONTENTS ;AAAAAA
BBBBBB
:BBBBBB
= address of eSR(parity
= contents of CSR
or ECe)
Page 131
76
ad Vector Printout
The Bad Vector message indicates that the address pointer is invalid
since an Interrupt Service Routine cannot be located. This error will
not interfere with the operation of the RTE HOwever, the module
containing the faulty pointer will not output on End-Of-Pass and will
therefore eventually be dropped if a system clock is available.
The
message is as follows:
BAD VECTOR:
200
:vector 200 is invalid for device
When the faulty module is found, Word 10 of the module header may
corrected via hardware documentation or module abstract analysis.
be
Special System Error Printouts
If a system error occurs in a PDP-ll/60 or 11/70 Processor (with an
associated DEC/XII Monitor), related Error Log messages are output in
addition to the standard System Error printout previously described.
For a PDP-Il/60, the following
printout:
is
included
with
the
System
Error
11/60 ERROR LOG
JAM/XXXXXX SRV/XXXXXX PBA/XXXXXX CUA/XXXXXX
FLG-INT/XXXXXX WHAMI/XXXXXX CDATA/XXXXXX CTAG-CPU/XXXXXX
Where:
JAM
SRV
PBA
I'""T T J\
~Ul"\
FLG/INT
WHAM!
CDATA
CTAG/CPU
is JAM Register status
is Service Register of status
is Physical Bus Address Register
(bits 16,17)
is Microprogram Address
is Flag Request Register of status/last
interrupt vector serviced
is various Processor Option Status bits
is Cache Memory data word
is Cache memory Tag Data/Hit Register
For a PDP-11/70, the following is
printout:
included
with
the
System
11/70 ERROR LOG
MEMERREG/XXXXXX CPUERREG/XXXXXX
ADDR/XXXXXXXX
;only output if parity error
Where:
MEMERREG
is Memory System Error Register
Errror
Page 132
76
CPUERREG
ADDR
3.3.3.4.3
is CPU Error Register
is 22-bit address of parity error location
Debug Recommendations
The following material is intended to initially provide a general,
common=sense check list for analyzing and isolating faults that may
occur during the debugging of a newly created RTE program.
This is
followed by several examples of both problems that can occur and
debugging procedures that may be applied.
If errors occur during the testing of a newly created RTE program, one
of the following may prove helpful in isolating the problem:
• Check Software parameter such as VCT, BRl, SRI, etc •..
. Eliminate the possibility of a peripheral error
tapes, cleaning heads, changing disk packs, etc.
If a device failure
diagnostic.
is
indicated,
try
running
by
a
changing
stand-alone
If hardware system failures are persistent and/or varied,
running the program on another system (if practical).
try
If mUltiple module failures occur, try running the program locked
in different banks, via a Run Lock Command (RUNL).
If a specific module fails, try running it alone or
in varied combinations.
Two examples of possibl~
procedures follow:
failures
and
suggested
with
others
trouble-shooting
Problem 1
A total of five modules are running when a specific module fails.
;Trouble-shoot as follows:
The goal of this procedure is to cause the failure to reoccur with the
least number of modules running, being aware that certain combinations
of hardware running at the same time can cause such failure.
With this in mind, run the failing module first by itself.
This can
be done by deselecting all of the modules while the RTE is running
(BSY» and then s~lecting the failing module, as follows:
.DES
.SEL MODXO
;deselect all modules
;select failing module first
If the failure reoccurs, isolate the problem within the module or run
a
device/option
diagnostic.
If the fault does not reoccur,
selectively add each of the remaining modules one at a time until the
Page 133
76
failure is repeated.
Problem 2
Altnough Software Switch Register Bit 12 is set (SR12 = 1) to cause an
END OF PASS printout, a module (other than a Background Module) has
not output such a message, or any message, since the run began.
Trouble-shoot as follows:
The goal of this procedure is to determine if the module in question
is indeed runnIng; and if it is not (and should be), to determine the
reason by tracing the execution of the module's code.
As stated, it is assumed that the module
Background Module (BKMOn).
Therefore it
following:
in question
may be any
is not a
one of the
· Non-Restartable Background Module (NBKMOn)
· Special Background Module (SBKMOn)
· r/o Module (IOMOD)
· I/O Module Extended (IOMODX)
· r/o Module Restricted (IOMODR)
· r/o Module Partially Restricted (rOMODP)
The first step is to determine if the module has been selected.
This
may be accomplished, -while the RTE is running (BSY», by invoking a
summary printout for the specified module (SUM modulename) and
examining the Status Word to see if the Select Bit (14) is set. If
the Select Bit is set, the Active Bit (11) must also be set for the
module to run while the Dropped Bit (13) must be clear. However,
although a cleared Active Bit (bit 11 = 0) in the summary indicates
that the associated module is not running, it does not necessarily
indicate an error condition. Whether an error exists or not depends
on which of the six module types is being analyzed. For example,
under certain relocation conditions where boundary restrictions exist,
four of the module types (NBKMOD, SBKMOD, rOMODR, rOMODP) are not
permitted to run (i.e., the Active Bit will not be set until a
favorable relocation occurs). However, if the Active Bit is clear and
the module in question is a type unaffected by such restrictions
(rOMOD and IOMODX), and should be running, a software problem exists.
If the Select Bit is set (bit 14 = 1), the Active Bit is set (bit 11 =
1), and the Dropped Bit is clear (bit 13 = 0), ~he defined module
types should be running. To make such a determination under these
conditions, the user may dynamically examine the Iteration Count
(Location 40) for periodic increases (via an EXAM mdoulename addr
I
76
~ommand).
Page 134
If no increase is detected, the user may then stop the
program and selectively insert (via a MOD modulename addr Command) a
Halt Instruction in the module code in order to isolate the error.
For example, in the case of the I/O modul~ types (IOMOD, X,R,P,), a
Halt is placed in the module's Interrupt Routine and, if the device
interrupt is working, a halt will occur when the program is restarted.
If a halt does not occur, it may be assumed that the device is
defective.
Page 135
76
APPENDIX A
Following is a sample build of a RTE from pre-build planning thru
linking process.
System configuration consists of the following:
11/70
256K of Memory
Extended Instruction Set
Cache
Floating Point Hardware
1-RM03 Single Port Disk
M9312
2-TM03/TE16
l-LPll
l-RS04
I-DHl1
SHEET 1 of 1
DEC/XII System Configuration Worksheet
Selected DEC/XII Monitor For Listed
CPU and CPU options: E
FILE:
ESAMCO.BIN
DATE:
20 SEPT 78
SRI SR2 DVC
MOD
R
OVA
VCT
3
R~D
A
176700*
254* 5*
0*
..L.~
LPll
LPA
A
177514*
200* 4*
0*
1*
TM03/TE16
TMB
A
172440*
224* 5*
0*
2
RS04
RSA
A
172040*
204* 5*
0*
1*
DHll
DHA
A
160200
300
5*
1*
EIS
CPB
A
11/34 Instr.
CPA
A
FP11-C
FPB
A
M9312
BMH
A
DEVICE
SRI
-----~J-iO
5*
' ....
77000
SR2 SR3 SR4
the
76
*
Page 136
DENOTES SOFTWARE DEFAULTS PARAMETERS
At this time we are ready to start building the Configuration
This is done by running the Configurator!Linker.
$DKO
Table.
;Boot the Load Medium
CHMDKBO XXDP+ DK MONITOR
BOOTED VIA UNIT#:
0
28K UNIBUS MEMORY
ENTER DATE (DD-MMM-YY):
RESTART ADDR:152010
THIS IS XXDP+.
TYPE:
TYPE "H" OR "H/L" FOR HELP.
<"C>
.R DXCL
;Abort XXDP+ Header Message
;Run the Configurator/Linker
;Program
CHUXCCO XXDP+ DEC/XII CNF/LNK
RESTART:
006472
DO YOU WANT HELP?{Y OR JUST
MONITOR:
;Enter CNF mode
E
MDL RMDA
DVA-
VCT-
BRI-
BR2-
DVC-
SRl-
SR2-
;Inhibit help message
;Enter Monitor name
;Enter Module RMDA
76
Page 137
SR3-
SR4-
RMAA
DVA-OOOOOO veT-OOOOOO BRl-OOOOOO BR2-000000 Dvc-oooaao
SRl-OOOOOO SR2-000000 SR3-000000 SR4-000000
MDL LPAA
DVA-
;Enter Module LPAA
VCT-
BRl-
BR2-
DVC-
SRl-77000
;Change LPAA SRI value
SR2-
SR3-
SR4-
LPAA
DVA-OOOOOO VeT-OOOOOO BRl-OOOOOO BR2-000000 DVC-OOOOOO
SRI-077000 SR2-0000QO SR3-000000 SR4-000000
MDL TMBA
DVA-
;Enter Module TMBA
VCT-
BRI-
BR2-
DVC-2
;Change TMBA Dve value
SRI-40
;Change TMBA SRI value
SR2-
SR3-
SR4-
TMBA
DVA-OOOOOO VeT-OOOOOO BRI-OOOOOO BR2-000000 DVC-000003
SRI-000040 SR2-000000 SR3-000000 SR4-QOOOOO
MDL RSAA
DVA-
;Enter Module RSAA
76
Page 138
VCT-
BRl-
BR2-
DVC-
SRl-
SR2-
SR3-
SR4-
RSAA
DVA-OOOOOO VCT-OOOOOO BRI-OOOOOO BR2-000000 DVC-OOOOOO
SRI-OOOOOO SR2-000000 SR3-000000 SR4-000000
MDL DHAA
DVA-160200
;Enter Module DHAA
;Change DHAA DVA value
VCT-300
:Change DHAA veT value
BRI-
BR2-
DVC-
SRI-
SR2-
SR3-
SR4-
DHAA
DVA-160200 VCT-000300 BRI-OOOOOO BR2-000000 DVC-OOOOOO
SRI-OOOOOO SR2-000000 SR3-000000 SR4-000000
MDL CPBA
DVA-
VCT-
BRI-
BR2-
DVC-
SRI-
SR2-
:Enter Module CPBA
76
Page 139
SR3-
SR4-
CPBA
DVA-OOOaao veT-OOOOOO BRI-ooeoee BR2=OOOOOO DVC-OOOOOO
SRI-OOOOOO SR2-000000 SR3-000000 SR4-000000
MDL CPAA
;Enter Module CPAA
DVA-
VCT-
BR1-
BR2-
DVC-
SRl-77000
SR2-
SR3-
SR4-
CPAA
DVA-OOOOOO VCT-OOOOOO BRI-OOOOOO BR2-000000 DVC-OOOOOO
SRI-077000 SR2-000000 SR3-000000 SR4-000000
*MDL FPBD
;Enter Module FPBD
DVA-
VCT-
BR1-
BR2-
DVC-2
SRl-40
SR2-
SR3-
SR4-
FPBA
DVA-OOOOOO VCT-OOOOOO BRI-OOOOOO BR2-000000 DVC-000003
SRI-000040 SR2-000000 SR3-000000 SR4-000000
*MDL BMHA
;Enter Module BMHA
76
Page 140
DVA-
VCT-
BRI-
BR2-
DVC-
SRI-
SR2-
SR3-
SR4-
BMRA
DVA-OOOOOO VCT-OOOOOO BRI-OOOOOO BR2-000000 DVC-OOOOOO
SRI-OOOOOO SR2-000000 SR3-000000 SR4-000000
*EX
*LINK
;Leave CNF mode
DKO:ESAMCO.BIN~DKO:XMONDO.LIB
;Enter the LINK Command
Device not on system
SYS SIZE:160000
MAKE OUTPUT READY.
;Enter System Size
WRITE ENABLE
TYPE WHEN READY.
PASS I
TRANSFER ADDRESS: 02200
LOW LIMIT: 000000
HIGH LIMIT: 122660
PASS 2·
LINK DONE
*SAVC DKO:CSAMCO.CNF
DONE
;Save the Configuration table
Page 141
76
*SAVM DKO:MSAMCO.MAP
;Save the exerciser load map
DONE
*EXIT
FOLLOWING IS AN EXAMPLE USING CNF/NP:
*CNF/NP
;Enter CNF mode with prompting
; inhibited
MONITOR: E
;Enter Monitor name
--------
*MDL RMAA
;Enter module RMAA
*MDL LPAA
;Enter module LPAA
*SRI 77000
;Change LPAA SRI value
*MDL TMBA
;Enter module TMBA
*DVC 2
;Change TMBA DVC value
*SRI 40
;Change TMBA SRI value
*MDL RSAA
;Enter module RSAA
*MDL DHAA
;Enter module DHAA
*DVA 160200
;Change DHAA DVA value
*VCT 300
;Change DHAA VCT value
*MDL CPBA
;Enter module CPBA
*MDL CPAA