Trailing-Edge
-
PDP-10 Archives
-
BB-FI04A-DD_1986
-
6,10/dfrpn.hlp
Click 6,10/dfrpn.hlp to
see without markup as text/plain
There are 2 other files named dfrpn.hlp in the archive. Click here to see a list.
IDENTIFICATION
--------------
PRODUCT CODE: AH-T102C-DD
DIAGNOSTIC CODE: DFRPN
PRODUCT NAME: DFRPNC0 RP07 BASIC DEVICE DIAGNOSTIC
VERSION: 0.3
DATE RELEASED: APRIL 1984
MAINTAINED BY: 36-BIT DIAGNOSTIC ENGINEERING
AUTHOR: MARSHALL SMITH
COPYRIGHT (C) 1982, 1984
DIGITAL EQUIPMENT CORPORATION, MAYNARD, MASS.
THIS SOFTWARE IS FURNISHED UNDER A LICENSE FOR USE ONLY ON A
SINGLE COMPUTER SYSTEM AND MAY BE COPIED ONLY WITH THE INCLUSION
OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE, OR ANY OTHER
COPIES THEREOF, MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE
TO ANY OTHER PERSON EXCEPT FOR USE ON SUCH SYSTEM AND TO ONE WHO
AGREES TO THESE LICENSE TERMS. TITLE TO AND OWNERSHIP OF THE
SOFTWARE SHALL AT ALL TIMES REMAIN IN DIGITAL EQUIPMENT
CORPORATION.
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 THE
USE OR RELIABILITY OF ITS SOFTWARE IN EQUIPMENT WHICH IS NOT
SUPPLIED BY DIGITAL EQUIPMENT CORPORATION.
Page ii
Program Documentation for
RP07 Basic Functional Diagnostic Program (DFRPN)
Page
----
Page 1
1.0 Program Abstract
1.1 Scope of this documentation
This is the documentation for the RP07 Basic Diagnostic which is
named DFRPN. To clarify the descriptions of user interfaces and
error reporting, this document makes references to examples
contained in appendix-A
1.2 General program description
DFRPN functions as the the basic diagnostic for single and
multi-drive confidence testing, and assures that no solid faults
exist for RP07's attached to RH20 Massbus controllers on KL10
family of computers. DFRPN will run in EXEC and USER mode under
both TOPS10 and TOPS20 and unless specifically stated, will
provide identical functionality in both EXEC and USER mode. The
program is designed with adequate functionality and safeguards to
allow its operation on the fixed media RP07 disk drive in both
exec and user mode without loss of customer data that may be on
the media. DFRPN along with the standard diagnostic subroutine
package and monitor will load and execute in 64k of memory for (1)
drive, and will expand 1K for each additional drive configured.
1.3 Pre-requisite software
DFRPN assumes no solid faults exist in the CPU/Memory/RH20
hardware for it to operate predictably. The following diagnostics
must be run prior to DFRPN:
o CPU and Memory diagnostics (all)
o RH20 fault isolation diagnostic (DFRHB)
1.4 Program size
In the majority of system configurations DFRPN will load and
execute in less than 64k of memory. Approximately 16k of that
memory is dedicated to standard diagnostic software (Subrtn,
Diamon,Klddt) so the actual diagnostic segment will be less than
48k. The program may exceed 64k on systems containing many drives
as it will require approximately 1k additional core for each drive
that the user selects for testing. The additional space is
required for storage of data buffers and status tables particular
to each drive. The program is optimum in the respect that it
dynamically expands only as required by the system configuration.
Page 2
1.5 Program run time
Program runtime varies according to the test or script that is
chosen, the iteration count (if in manual mode), and the number of
drives being tested. The reference to script apples to
prepackaged test strings (i.e., TSTA, DIAA, DATAA or DUAL). In
default mode, all tests but TST1, TST30, microdiagnostic DIA46
(tachometer calibration utility), and the scripts mentioned above
are run, the average run time in default mode is less than 3
minutes per drive in exec, and 9 minutes per drive user mode with
a very light system load.
1.6 User mode capability
DFRPN will run in user mode (timesharing) under TOPS10(7.01) and
TOPS20(4.0). Both of these monitors must contain RP20 support.
Without RP20 support the DIAG JSYS/UUO has insufficient capability
to support this software. User mode capability under older
versions of the monitor is not supported. The user mode
diagnostic capability of this program is accomplished entirely
through the use of the DIAG JSYS/UUO (program performs its own I/O
in a real time privileged environment). There are some
restrictions imposed upon the diagnostic in user mode that are
listed in the appropriate section.
1.7 Fault detection and isolation
The purpose of DFRPN is to preform the following functional
testing;
o Insure that the RP07 responds only when it should.
o That the control bus section of the Massbus is working
properly, and that the drive registers respond correctly.
o That the internal ISS microdiagnostics run and report no
errors.
o That the data path section of the Massbus performs correctly
and that we may read and write the microdiagnostic cylinder
(631.).
o That Dual Port arbitration logic functions correctly, (manual
mode MAN> in EXEC only).
o Report errors encountered in testing and callout the suspect
module or modules, as well as supply pertinent information to
the failure.
Page 3
o Upon successful completion of DFRPN the Reliability diagnostic
DFRPM should run free of solid faults.
1.8 General user interface philosophy
All OUTPUT messages are clear and concise. Decimal numbers are
always followed by a point. Numbers without the point are octal
with the exception of the dumping of RP07 maintenance register and
error log (TST30). Error codes which are 2 digit hexadecimal, are
in hexadecimal to be consistent with RP07 documentation and
manuals. Many of the numbers output will be dumped in both octal
and and decimal as it is often desirable in disk diagnostics to
work in both bases when analyzing error printouts.
The notation for outputting in both octal and decimal is, the
octal value first followed by the decimal equivalent in
parenthesis (e.g., 144(100.).
All INPUT is preceded with a prompt.
All input is checked for legality and incorrect responses will be
followed by a reprompt and in some cases an additional error
message.
All numerical input may be in either octal or decimal where a
period following the number indicates decimal.
Any point in the program allowing multiple input options supports
a help message to further explain the options.
The program requests only 3 types of input, numerical, yes or no,
and sixbit.
When an error is detected on a yes or no input, the user is merely
reprompted.
When an error is detected on sixbit input the prompt is re-issued.
The dispatchers, (Default (DEF), Manual (MAN), Variable (VAR) and
Mode) also issue the message "- INVALID RESPONSE -", then the user
is reprompted. The user can then query the program for further
information by asking for help.
The design goal was to make the user interface so simple and
complete that the user can run the program without any
pre-requisite reading. The program will "LEAD".
Page 4
1.9 Compatibility goals
1.9.1 CPU family
DFRPN is compatible with all DECsystem 10/20 systems, having the
RH20 as the system Massbus controller.
1.9.2 Standard diagnostic support software
DFRPN is compatible with all of the standard diagnostic loaders,
monitors, subroutines.
1.9.3 Operating systems
DFRPN is fully supported in user mode under the following
monitors:
o TOPS10 release 7.01 (with RP20 support) or newer
o TOPS20 release 4.0 (with RP20 support) or newer
The program will not be supported on older versions of the monitor
since it requires the enhancements to the DIAG JSYS/UUO which do
not exist in earlier monitors.
The program determines if it is running under TOPS20 (rel-4), and
if this is the case a flag is set, This flag is tested by the
microdiagnostic dispatcher and if set, disallows running of any
microdiagnostic that exceeds the guaranteed 5.0 seconds that the
monitor allows with out causing a keepalive cease. There are
three microdiagnostics that exceed this TOPS20 (rel 4) time limit.
They are:
DIA-39 DIA19 DIA1A
Under all other supported monitors these microdiagnostics will be
run if selected, and in all cases they will be run in exec mode.
1.10 CPU/Memory failures
Most CPU and Memory faults are FATAL errors to the program and it
will not be able to continue. The program may survive some memory
parity errors. If the parity error is in the program data buffer,
the program will be allowed to continue. If the error is in the
program area itself, the error is considered FATAL.
Page 5
1.11 Power fail/restart
Not Supported
1.12 Disk drive failure
The program will run on any RH20/Disk Drive selected during
configuration regardless of the type, this is to allow for the
possibility of a drive responding to other than the correct drive
type or logical number. Of course the user could select a drive
of the incorrect type or a nonexistent drive, and the information
and errors reported would be without meaning. This feature has
been supplied for the diagnosing of Massbus and drive type
register problems. All errors reported will include the suspect
module or modules by their circuit symbol (i.e., A1A10).
1.13 Restrictions
Under TOPS20 a user must have at least MAINTENANCE privileges to
run the program. WHEEL's and OPERATORS also have sufficient
privileges to run the program in user mode.
1.14 User mode transfer sizes
In user mode, all transfers are restricted to being multiples of
full sectors of data since zero fill cannot be programmed with the
DIAG JSYS/UUO. This restriction is of little consequence in the
basic functional because we are restricted to the microdiagnostic
cylinder and is mentioned only to make the point that the program
will enforce the restriction automatically.
1.15 User mode timing tests
There are no user mode timing test made, however under EXEC mode
the Dual Port test do preform timing test for port arbitration.
1.16 User mode priority interrupts
The diagnostic is not allowed to use the priority interrupt system
in user mode. The program will pole the hardware registers for
interrupt conditions.
Page 6
1.17 Non-Goals
Diagnostic Engineering does not support or respond to problems in
the 8080 or 2901 microcode, this type of problem should be
addressed by Disk Engineering.
1.18 Support of the ISS CE cylinder for RP07
Cylinder 631. is the innermost cylinder on the drive and is used
by the drive microdiagnostics. This program uses this cylinder
(631.) for all of the data path testing. In the event that the
format is not in 18 bit mode, the program has the ability to
reformat it in 18 bit mode. Formating this cylinder is not a user
option and the decision is made during the data path testing.
Data path test DATA8 is realy a utility to format this cylinder,
this is done to insure that the cylinder is left in good condition
at the completion of default testing. This cylinder was selected
for use by this program to insure that the FE cylinders (629. and
630.) are not altered and the Formatter/Exerciser DFRPM will run
without the user having to reformat them if the format was correct
prior to running the Basic Diagnostic (DFRPN).
2.0 Hardware Requirements
2.1 CPU family
DFRPN will run on any KL10 processor with a RH20 Massbus
controller.
2.2 Memory
DFRPN requires at least 64K of memory of any type to run in EXEC
mode.
Memory may be configured in any manner (i.e., internal, external,
interleaved in any manner). The key point is that the programs
performance will not be effected by memory and cache options other
than an overall program run time.
In user mode more memory is required due to the monitor
requirements, there must be at least 64K of memory available to
the user.
Page 7
2.3 Load device
DFRPN will load from any standard load device. Program loading is
is a function of the standard diagnostic loaders and monitors
(i.e., Diamon, D20mon, Magmon, Kldcp etc.).
2.4 User interface to the program
User interface to the program is through dialogue at the terminal.
In exec mode, the console switches on the KL (left side switches
are 11/40 front end console switches) will be used directly. In
user mode, software sense switches are used as standard procedure.
All operator/program dialogue is done through the standard
diagnostic subroutine package. Sense switch options are described
in section-3.
2.5 Operating systems
DFRPN runs in user mode under monitors supporting the DIAG
JSYS/UUO. This monitor feature is supported in the following
monitors:
o TOPS10 (7.01) (With RP20 support) or newer.
o TOPS20 (4.0) (With RP20 support) or newer.
The program is not be supported on older versions of the monitor
since it requires the enhancements to the DIAG JSYS/UUO which do
not exist in earlier monitors.
3.0 Functional Description
This section provides a description of the functionality that is
provided by DFRPN at various program levels (start-up,
configuration, test level, etc).
3.1 Philosophical overview
The functionality provided in this diagnostic was determined after
examining the needs for the RP07 and a close look at the
functionality provided by existing basic disk diagnostics.
This software is similiar in functionality to DFRPH and DFRPK.
The RP04/06 Basic diagnostics. This program has improved test
dispatching and user interface dialogue.
Page 8
o DFRPN provides nearly identical functionality in exec mode and
under both TOPS10 and TOPS20 by using the DIAG JSYS/UUO
features. Briefly put, DFRPN does all of its own I/O in real
time using DIAG features and is not restricted to limitations
particular to either of the operating systems. There is only
1 I/O interface module for EXEC, TOPS10, TOPS20 and from the
point of view of the user, functionality of the program will
be nearly identical in all three cases. DFRPN fully
implements loop on error so scope looping and trouble shooting
is possible in any test.
o DFRPN provides the ability to reconfigure the program at any
time. This is done by entering manual or variable mode and
selecting 'CONFIG' as if it were a test.
3.2 Console sense switch options
The only switches used by the program are a subset of the standard
(left hand) sense switch options and are listed here.
400000 If set: abort program at end of this pass
200000 Not used
100000 Not used
040000 Inhibit all but FORCED printouts
020000 Output to LPT in exec mode, DFRPN.PNT in user mode
010000 Ring bell on error (bell is force printed)
004000 If set: loop upon first occurrence of error
002000 Halt on error (switch is ignored in user mode)
001000 If set: print all repetitions of errors in a scope loop
If reset: print only on first occurrence of error in loop
000400 Not used
000200 If set: use abbreviated printouts where possible
000100 If set: inhibit operation of KL paging hardware
000040 Not used
000020 If set (at startup): inhibit operation of cache
000010 Not used
000004 Not used
000002 Not used
000001 Not used
There are no right hand switch options in this program. All other
program options are selected through dialogue at the terminal.
Page 9
3.3 Program start and restart philosophy
DFRPN provides an alternate starting address that allows you to
get gracefully back into the program following hardware or
software malfunctions or in many cases after a power down/up
sequence if the program is in core memory.
3.4 Initial program start up
The inital starting address is at 30000. Starting the program at
30000 (the normal address) causes the program to be completely
reset along with the reinitialization of the diagnostic subroutine
package. This step actually needs to be done only once after
initial program load. Starting at 30000 is identical to typing
the STD command to KLDCP and results in maximum dialogue at the
terminal.
3.5 Optional restart address
The optional starting address at 30004 gives you ability to
restart, reconfigure if desired. In addition, dialogue is very
brief if you choose to keep the same configuration. If you choose
not to reconfigure, you will have to enter only minimum dialogue
to get the program running again.
3.6 Control-C capability (Ctrl-C)
The program supports the CTRL-C and CONTINUE commands in user mode
only, for both TOPS10 and TOPS20. The CTRL-C intercept is honored
by the program at the completion of its next I/O operation. The
program honors the CTRL-C by cleanly terminating the program and
returning to monitor level. If a CONTINUE command is issued from
monitor level, the program will resume execution as if it were not
interrupted.
3.7 Configuration of program and subsystem
This section outlines the operations of configuring the program to
the system at run time. There is a whole section of the program
dedicated to configuration. Several functional steps are executed
in configuring the program:
o The program goes out and poles the system in an attempt to
determine which Massbus controllers and drives are attached to
the system (this step is also performed in user mode).
Page 10
o The program then reports the configuration on the terminal.
By now the program has built tables that identify the hardware
configuration.
o The program then allows the user to select the controllers to
be used during the diagnostic.
o The program will then allow the user to run down the list of
selected controllers and pick the drives to be tested on each
controller.
o If the user responds with "A" (all) only RP07 disk drives will
be selected.
o The program then goes to each of the selected drives and does
a status check of the hardware, and reports some properties of
the device. When the dialogue is complete, the programs data
base and options will be complete.
3.8 Finding RH20's and Drives
In user mode the program reads the CONI status for each of the 8
RH's and if NON-0, assumes the controller exists. The responding
device is also tested to see if bit 0 is set. In this case the
device is not believed to be an RH20 and therefore not selected.
In exec mode the program looks for any of the 8 possible RH20's.
The existence of a particular RH20 is tested for by first clearing
it and then setting its PIA bits and checking for proper response.
The program will allow an RH20 to be used if the following
conditions are met:
o The PIA bits can be set to 7 and cleared with an RHCLR.
o No RH20 error conditions exist following the RHCLR.
o Bit 0 is not set.
There are several criteria that must be met for the program to
recognize the existence of a drive on any of the Massbus
controllers. Drives are only looked for on controllers that
passed the controller criteria mentioned in the previous step.
The following criteria is then used for finding RP07 drives:
o The drive must handshake properly when the drive type register
is read.
o The drive type must match that of an RP07. At this point the
user could select a drive other than an RP07, causing
erroneous error reporting.
Page 11
The program is capable of detecting and reporting the fact that
there are RP04, RP06 and RP20's on the system but that's the
extent of the support. The program will allow you attempt to test
them even though they will not respond correctly and report errors
that are not consistent. The responsibility of proper selection
of drives rests on the user, this allows testing of drives that
are failing in the area that indicates drive type, logical number,
ect.
3.9 Reconfiguration capability
The entire configuration package is constructed so it looks like a
test within DFRPN. This provides the capability to reconfigure
from the manual 'MAN>', or variable 'VAR>' mode and change the
configuration and/or modify your run time options without
re-initializing the program.
3.10 Handling of user data on the media
1. This program preforms all write operations to the maintenance
area. Reading and positioning will be allowed anywhere on the
media.
3.11 Modes of program operation
There are 3 major operational modes of test control in DFRPN. The
modes of operation are called default (DEF), manual (MAN) and,
variable (VAR). The manual (MAN) and variable (VAR) mode allow
the user to select the test to be performed. In default mode
(DEF) mode the tests and iteration count are supplied by the
program. The prompts for manual and variable mode are:
o WHAT TEST (OR HELP) ? MAN> (implies manual mode)
o WHAT TEST (OR HELP) ? VAR> (implies variable mode)
3.11.1 Default mode DEF>
In default (DEF) mode the test sequencing and parameter choice are
entirely under control of the program. The only user options are:
o 'PRINT LOW PROBAILITY OF FAILURE - Y OR N <CR>', this will
only be asked once after program startup and will be asked
form the first mode entered.
Page 12
o 'SINGLE OR MULTIPLE PASSES (S OR M)? ', this will be asked
each time the default mode is entered.
The program merely executes a predetermined set of tests on each
of the drives that have been selected for test. The operator
intervention test TST1, dump of the 8080 error log TST30, and Dual
port test are not run in default mode. Also microdiagnostic
DIA46, the tachometer calibration utility and TD631, a utility for
reading and writing TD's on cylinder 631 are not run. After
completion of all default testing the program will return to the
prompt 'WHAT MODE (MAN,DEF,VAR OR HELP)? ' this is also true if
the default mode is aborted by the user by typing an altmode.
3.11.2 Manual mode MAN>
Manual mode provides the user a greater degree of test control.
If entering manual mode (MAN) from program startup the first
prompt asks 'DO YOU WISH TO PRINT LOW PROBILITY MODULE CALLOUTS (y
or n) ?', if this question has been previously answered it will
not be asked again. Then the prompt is 'DEFAULT ITERATION COUNT
IS 1, DO YOU WISH TO CHANGE IT (y or n) ?', this allows the user
to select how many times each test is to be run before moving to
the next drive or test, then the prompt is 'What test (or help) ?
MAN>', which allows the user to select the test to be run. The
user selects from the list of all possible tests that are
implemented. There are four prepackaged test scripts available
under (MAN) mode, They are strings of the test groups, TSTA runs
all the control bus tests in sequence, DIAA runs all the
microdiagnostics tests in sequence, DATAA runs all the data bus
tests in a sequence and DUAL runs all the dual port test in a
sequence, (dual port testing is restricted to EXEC mode only,
because it requires reconfiguring the Massbus).
3.11.3 Variable mode VAR>
The variable (VAR) mode of operation allows the user to select
tests from prompt level just as he does in manual mode. In
variable mode however, the test will loop indefinitely on the
first drive selected and the first test run, in the case a
pre-packaged script was selected (TSTA, DIAA, or DATAA), DUAL port
testing does not run in variable mode VAR>. This mode is realy
meant for long term scope looping. Because of this it is best to
select one only drive if running in variable VAR> mode, and then
run the test which will loop until interrupted with an altmode.
The altmode will cause return to variable mode VAR>.
Page 13
3.12 Test dispatching
The program has 3 test dispatchers, one for default mode, one for
manual and variable mode and the dual port test dispatcher. The
dual port tests must be run in EXEC mode and in sequence for
timing tests on port arbitration and time-outs with automatic
release of the port.
The dual port dispatcher is not available to the user directly but
is called from manual mode dispatcher MAN> to preform the testing
of dual port functions, this will run in EXEC mode only.
The dispatcher used in manual and variable modes provides the
additional dialogue, control, and parsing that is required when
the user is picking and choosing the tests.
The function of the dispatcher (regardless of which) is to
properly get you from command level to one of the implemented
tests. The dispatcher merely scans a series of tables to
determine things like legality of test name, starting address, and
iteration counts. The dispatcher knows nothing about the
particulars of the test. By separating the functions of
dispatching and testing it is very easy to add, delete, or modify
tests without changing the control structure of the program. The
handling of all test dependent operations is done at the test
level.
The microdiagnostics are always run from a microdiagnostic
dispatcher. This dispatcher is actually called by the afore
mentioned dispatchers, after the test has been determined to be a
microdiagnostic. In user mode this dispatcher assures that at
least 12 seconds (by the wall clock) has expired since the finish
of the last microdiagnostic prior to starting the next
microdiagnostic. The purpose of this timer is to insure that
other users of the resources used in testing will be allowed
access to the drives on this RH20.
3.13 General test philosophy
o Provide a level of test control that allows the program to go
out and test the drives with a minimum of user dialogue. This
is the default mode DEF>.
o Provide a level of test control which allows the user to
selectively choose a test from the programs repertoire of
tests and utilities. This is the manual mode MAN>.
o Provide another level of manual test control that allows the
user to loop indefinitely on a test. This is a loop of the
complete test and will be shortened if the loop on error
switch is set and an error occures. This is the variable mode
VAR>.
Page 14
o Report errors that are detected during the running of the
basic diagnostic, and read the drive error log containing the
last twenty (20) errors that the drive has seen and corrected
through retries or other means.
o To isolate failures to the field replaceable unit (FRU).
3.14 Test specification and terminology
This is an introduction to some of the terminology used to
describe tests both in this specification and in the actual
program (through dialogue at the terminal). Each test has a name
of up to 6 characters in length. These names are recognized by
the program as being valid tests.
3.15 Test flow (cycling through devices)
o In default mode, a drive is chosen and then the test is run
until the iteration count is exhausted. At present the
default iteration count is set at one. Then the next drive is
chosen and the test is then run on that drive until the
iteration count is exhausted. This continues until the test
has been performed the correct number of iterations on all of
the selected drives. The test then returns control to the
dispatcher who will determine what to do next (usually
dispatch to next test). While in default mode, any parameters
required by the test will be supplied by the program (i.e.,
sect, surface for formatting).
o In manual mode, you supply the iteration count when you first
enter the mode, it will remain the same for all tests. You
may change the iteration count by running the iteration test
(ITRSET), which allows you to change the count, if you run
"ITRSET" and your response is no, the iteration count will be
set to 1. If you exit manual mode and enter default mode the
iteration count will be set to 1. And upon reenter manual
mode you will be asked if you wish to change the iteration
count.
The test dispatcher gets you to a particular test, a drive is
chosen and then the test is run on that drive until the
iteration count is exhausted. The next drive is chosen and
the process continues until the test has been run the proper
number of iterations on all the drives selected for test.
After running on all the selected drives, the test returns
control to the manual mode test dispatcher which asks the user
again to select another test.
Page 15
o Variable mode is some what different. Built into the design
of the program is the assumption that we need a variable mode
in order to recreate some failing condition that we observed
on a particular drive so that it may be investigated and
repaired. The first effect of this assumption is that when
you enter a test, you do not want to get out when an iteration
count is exhausted. Unless specifically stated in the test
description, tests entered in variable mode never return back
to the dispatcher until the user types an altmode (escape) to
the program, this will return the user to the mode prompt.
The second consideration in variable mode is determining which
drive to use, keeping in mind the fact that once it starts it
never stops. When running in variable mode DFRPN choses the
first drive of those selected for test and runs the test only
on that drive. The cleanest way to use the program in
variable mode is to first run CONFIG choosing only the drive
you wish to test and then proceed. The variable mode is
provided mainly for the purpose of scoping a drive that is
suspect of malfunction and for some reason the diagnostic has
not provided all the information the user feels is needed,
therefore the assumption that you are fixing one drive at a
time and are using some form of test equipment which would not
lend to moving from drive to drive trying to keep up with the
dispatcher.
3.16 Starting the test
All tests are started automatically when arrived at from the test
dispatcher. All tests are self initializing and no particular
test order is mandatory.
3.17 Stopping the test
Tests can be stopped in several ways:
o In default mode the test dispatcher sits in a loop cycling
through a list of tests that are pre-determined by the
diagnostic. The user can get back into control by typing an
altmode (escape) to the program. The altmode will be
recognized immediately if no printing is taking place and at
the end of the current error report if the program is in the
middle of an error report. The test in progress will be
allowed to finish then command will return to the prompt 'WHAT
TEST (OR HELP) ? MAN>'. There is an exception if the altmode
is type during a microdiagnostic a delay up to eighteen (18)
seconds is possible, in user mode and six (6) seconds in exec
mode, (see Section 3, Test Dispatching).
Page 16
o In manual mode, control will come back to the user when either
the iteration count is exhausted or he types an altmode. The
altmode will be recognized immediately if no printing is
taking place and at the end of the current error report if the
program is in the middle of an error report, the current test
will be completed but the iterations remaining will be ignored
and command will return to mode selection. There is an
exception if the altmode is type during a microdiagnostic a
delay up to eighteen (18) seconds is possible, in user mode
and six (6) seconds in exec mode,(see Section 3, Test
Dispatching).
o If the tests are being run in variable mode, the only way for
the user to get back into control is to type the altmode. The
altmode will be recognized immediately if no printing is
taking place and at the end of the current error report if the
program is in the middle of an error report. There is an
exception if the altmode is type during a microdiagnostic a
delay up to eighteen (18) seconds is possible, in user mode
and six (6) seconds in exec mode, (see Section 3, Test
Dispatching). As in MAN mode the current pass of the test
will be completed and the iteration count (in this case
infinite) will be ignored and command will be returned to the
prompt 'WHAT TEST (OR HELP) ? VAR>'.
3.18 Obtaining run time status (S) in user mode.
The (S) function has been implemented as a method of determining
if the program is still running or stuck in a loop of some sort.
Typing the character (S) while the program is running will return
the following information as a way to insure that the program is
actively running.
o Program run time (HH:MM:SS)
o Name of current test
o RH and DRIVE under test
o The request count is the number of times the ".reqa" routine
has been called since startup, this will constantly change
indicating that the program is running, not stuck in a loop.
This request (.reqa) counter is 36 bits and can overflow if the
program is run for a long enough period. This function is merely
to show that activity is going on. The value is of no practical
use, and only indicates activity.
The program services the (S) in a synchronous manner so there may
be a 1 or 2 second delay before response takes place. Like the
altmode response, you may have to wait for the current error
printout to complete before the (S) is honored. There may be a
delay of up to 6 seconds due to the microdiagnostic execution
time, and possible further delays due to monitor load.
Page 17
Due to some minor differences in the way the various operating
systems and diagnostic support programs operate, it may be
necessary to type S<CR> in some configurations to obtain the
runtime status.
3.19 Obtaining run time status (S) in exec mode.
The ctrlS (S) function has been implemented as a method of
determining if the program is still running or stuck in a loop of
some sort. Typing the ctrlS (S) while the program is running will
return the same information as in user mode except the time will
be the total time the program has been running in hours, minutes
and seconds. Also in exec mode typing S ctrl T (ST) will return
the run time status. There may be a delay of up to 6 seconds
because of the microdiagnostic execution time.
3.20 Restarting the test
There is no way to jump back into the middle of a test once it has
been aborted with an altmode.
Typing an altmode in default mode has the same basic effect as
reaching the end of a pass.
In manual or variable mode you merely need to execute the test
once more.
3.21 Scope looping
DFRPN supports the ability to loop on error in all modes if the
appropriate sense switch is set and an error occurs. The loop
uses only the controller/drive pair that was in effect at the time
the error occurred. Once a scope loop is entered it can be
interrupted by either clearing the loop on error switch or typing
an altmode to the program. Note that the altmode abort takes you
all the way back to dispatch level while the resetting of the
switch allows you to proceed from wherever you were looping.
When running in variable mode the loop on error switch has the
effect of tightening the scope loop to the first failure in the
test. The other effect of the loop on error switch in this mode
is a subtle effect on the printing. With the loop on error switch
set, only the first occurrence of an error is printed which is
standard procedure with this switch.
Page 18
3.22 Error printouts
Error printouts closely resemble the error printouts provided with
existing disk diagnostics. There are 4 basic parts:
o The header of each message contains cosmetic information such
as test name, type of interrupt condition, program run time
etc.
o RH20 CONI status and registers are dumped (as appropriate)
o DRIVE registers are dumped (as appropriate)
o All additional information will be printed pertinent to the
test running.
o Module callout by circuit symbol (i.e., A1A10).
In all of the error printouts, the registers and status data is
dumped as a combination of ascii, sixbit, hex, and numerical data
by default. The TXTINH sense switch (If set) will force all of
the status to be dumped in raw octal as it appears in the various
hardware registers.
3.23 Maintenance areas on the media
The maintenance area of any disk (pack or fixed media) is the
innermost cylinder. This is the innermost cylinder of the media
that is accessible without having to set any diagnostic bits or
issue special commands to gain access.
In addition, the RP07 has 3 maintenance cylinders that can be
accessed by setting the diagnostic mode bit. The first two of
these cylinders will be used by the reliability diagnostic and the
third cylinder 631 will be used by this diagnostic, this is to
insure that the format is not lost, this is the ISS
microdiagnostic cylinder, it will be formatted by this test upon
completion of data bus testing, but there is a possibility of
losing the skip words, this will not have a marked affect on this
diagnostic, the ISS microdiagnostics, or cause any other known
problems.
3.23.1 Write track descriptor (write TD)
Only the inner most cylinder will be formatted by this diagnostic,
DATA8 will automatically reformat using any available skip
information. This will not require any user control, and is run
in default or manual mode.
Page 19
4.0 Program retry of commands
There will be no retry commands in this program.
5.0 Test and Utility descriptions
This section describes the functions, parameters, restrictions of
each test contained in the diagnostic. The descriptions in this
section cover all of those operations that may be input in
response to the 'WHAT TEST (OR HELP) ? MAN> (or VAR>)' prompt
even though some of the operations are not device tests. The
default test sequence is listed with it's default parameters, and
the four (4) prepackaged sequences for running control bus,
microdiagnostic, data path, and dual port test sequences are
covered in this section.
6.0 Test-1 Basic drive select test
Description
This test verifies that no other device on the massbus will
respond to the device select code of the drive under test. In
this test all devices on the massbus are powered up but the drive
under test. The test will read the drive type register of the
drive under test, that is, it will read the register using the
device select code for the drive under test. No response to this
read should occur. If the test is unsuccessful, the drive type
and serial number registers of the responding device will be
printed in order to aid in the isolation of the fault.
Additional
In this particular test, the drive being tested is not the faulty
device. If the offending device can't be identified from the
information provided in the error printout, it may be necessary to
power down the other devices on this massbus one at a time and
rerun the test until the offending device is isolated. The
problem involves device selection, that is, a device responded and
there wasn't supposed to be any response. At this point, several
things could be wrong. Some possible reasons for failure are:
o The controller may not be sending the correct device
select code.
o The wrong drive is being selected because of a cable
problem, faulty device select receivers in the drive, or
failing device select circuits in the drive.
o The logic that looks for a match between the device select
code and the device select switches is malfunctioning.
Page 20
o A remote possibility is that there are two devices on this
massbus with the same device select switch setting.
o If the drive under test has been 'disabled' with the
disable switch, the switch itself could be bad.
This test only verifies that another device does not respond to
the device select code of the drive under test. We will not know
if the drive under test responds to any other device select code
until we have successfully run test 13.
7.0 Test-2 Demand transfer test
Description
This test verifies the correct operation of the demand/transfer
handshake of the control bus. The drive being tested is now
powered up. The test reads the drive type register of the drive
under test looking only for proper operation of demand and
transfer over the massbus. Improper operation would result in a
control bus timeout. Data and parity errors are ignored at this
point.
Additional
A failure in this test is indicated by a control bus timeout.
Some possible reasons for failure are:
o Demand is not getting to the drive because of a cable
problem or faulty demand receiver in the drive.
o The drive is not being selected because of a cable
problem, faulty device select receivers in the drive, or
failing device select circuits.
o A non-existent register is being selected because of a
cable problem, faulty register select receivers in the
drive, or failing register select circuits.
o Faulty disable switch or on-line switch in the drive.
o The handshake logic in the drive is malfunctioning and
transfer is not being generated in the drive.
o Transfer is not getting back over the massbus because of a
faulty transfer transmitter in the drive or a cable
problem.
o The power monitor signal at the input to the transmitter
carrying transfer is incorrect and disabling the
transmitter. This could involve checking power supplies,
etc.
Page 21
8.0 Test-3 Transceiver enable test
Test Description
This test is a preliminary check of the control bus read cycle.
This test reads the drive type register looking for a legal RP07
device type. It is the first time we are trying to read known
data from the drive. This test is a partial guarantee that the
transceivers are enabled during a control bus read cycle and that
the CTOD line (controller to drive), which determines the
direction of the transfer, is not stuck at one (indicating a
control bus write) during the control bus read cycle. Successful
operation indicates that we can select a register and perform a
control bus read cycle.
Additional
If this test fails some possible reasons are:
o A register select problem due to cables, faulty register
select receivers in the drive, or failing register select
circuits.
o An invalid drive type detected due faulty or disabled data
transmitters.
o The CTOD line is stuck at one meaning we are trying to
write a register rather than read a register.
9.0 Test-4 DA reg loaded with ones and zeroes
Description
This test verifies that the desired address register can be
written with ones and zeroes. The test sequence is:
o Issue a master clear.
o Write ones to desired address register.
o Read desired address register and verify that all bits are
ones (ignore parity errors).
o Write zeroes to desired address register.
o Read desired address register and verify that all bits are
zeroes ignore parity errors).
Additional
If this test fails some reasons are:
o A register select problem might be causing us to access
the wrong register.
Page 22
o Stuck bits in the DA register or faulty data transmitters.
o The CTOD line is stuck at zero meaning we are trying to
read a register rather than write a register.
10.0 Test-5 For cross-coupled bits with DA reg
Description
This test checks for cross-coupled bits on the control bus using
the desired address register. The test uses the data in table
CBDAT for test patterns. It starts with all ones and all zeroes
(as in test 4), then floating ones, and then floating zeroes.
The test sequence is:
o Select a data pattern to be written.
o Write desired address register with selected pattern.
o Read desired address register and verify that it got
written with the selected pattern.
o Increment to next pattern and test if we are done with
patterns. If not done, go to step 1. If done, go select
next drive.
Additional
None.
11.0 Test-6 Parity network can generate a 1 or 0
Description
This test verifies that the parity network in the drive can
generate odd parity, i.e.,, it checks that the parity bit is not
stuck at zero or one. The test sequence is:
o Write desired address register with zeroes.
o Read desired address register and verify that the parity
generated was odd, i.e.,, the parity bit was a one.
o Write desired address register with a one.
o Read desired address register and verify that the parity
generated was odd, i.e.,, the parity bit was zero.
Additional
If this test fails, the parity network in the drive is probably
broken.
Page 23
12.0 Test-7 Check faulty parity error detection
Description
This test verifies that the parity error detection in the drive is
functioning correctly. The test is almost the same as test 5,
except that here we add a test to see if the parity error flag
gets set after each pattern. The test sequence is:
o Select a pattern to be written.
o Write desired address register with selected pattern.
o Read error register 1 and verify that the parity error bit
did not set.
o Increment to the next pattern and test if we are done. If
not done, go to step 1. If done, go select next drive.
Additional
This test partially checks the parity chips and assumes that test
5 has been run successfully, i.e.,, we assume that the desired
address register is getting written properly. @@
13.0 Test-8 Register select test 1
Description
This test is a check that writable registers can be selected and
written. The writable registers used are the control register,
desired address register, offset register, and desired cylinder
register. The test sequence is:
o Select a register to be written.
o Write the register with a data pattern of 70 (arbitrary
choice).
o Read the register and verify that it got written
correctly.
o If all writable registers have been selected, go select
next drive.
Additional
This test separates register select problems between read-only and
read/write registers.
Page 24
14.0 Test-9 Register select test 2
Description
This test verifies that each writable register on the massbus has
a unique address. That is, we will try to verify that a write to
one register does not cause some other register to be written due
to a register selection problem. The writable registers are the
control, desired address, offset, and desired cylinder registers.
These registers will be referred to as 'X' registers and will be
written with a data pattern of 70. All the other registers,
including the writable registers not currently selected, will be
referred to as 'Y' registers and will be written with a data field
of 0. The following algorithm is used:
1. Select a writable register and call it reg-X.
2. Check if all the writable registers have been selected.
If they have, we start the test over if another drive is
available, or the test is done if another drive isn't
available. If they haven't all been selected go to step
3.
3. Select another register and call it reg-Y.
4. Check that reg-Y is not greater than 37. If it is, we
have checked reg-X against all values of reg-Y and go back
to step 1 and select a new reg-X. If it isn't, we go to
step 5.
5. Check that reg-Y does not equal reg-X. If it does, we go
back to step 3 and select a new reg-Y. If it doesn't, we
go to step 6.
6. Write reg-X with a data field of 70.
7. Write reg-Y with a data field of 0.
8. Read reg-X and check that the data field is still 70. If
it is, go back to step 3 and select a new reg-Y. If it
isn't, we will loop on error if the loop on error switch
is set or go back to step 3 and select a new reg-Y if the
loop on error switch isn't set.
The loop is completed when all writable registers in all available
drives have been tested.
Additional
This test by default guarantees that no two readable registers are
mixed up because of a register select problem.
15.0 Test-10 Test maintenance register selection
Description
This test verifies that we can select the maintenance register.
Page 25
The test writes a data pattern of 70 into the maintenance register
and reads it back and verifies it.
Additional
This is the first time the maintenance register is used.
16.0 Test-11 Test maint reg with data patterns
Description
This test verifies that the maintenance register doesn't have any
stuck data bits. The test uses the data from table CBDAT. The
test sequence is:
o Select a pattern to be written.
o Write maintenance register with selected pattern.
o Read maintenance register and verify that pattern is
correct.
o Increment the byte pointer and test if we have used all
data patterns.
Additional
None.
17.0 Test-12 Test massbus init and drv clr cmd
Description
This test checks that massbus init (RHCLR) and drive clear work by
checking the state of the diagnostic mode bit (bit-15) of the
maintenance register after each operation. The test sequence is:
o Write a one to the DMD bit in maintenance register.
o Issue an RHCLR.
o Read maintenance register and verify that the DMD bit
cleared. If it did not clear, set RHCLRF (RHCLR failed).
o Write a one to the DMD bit in maintenance register again.
o Issue a drive clear command to the control register.
o Read maintenance register and verify that the DMD bit
cleared with the drive clear command. If it did not
clear, and RHCLRF is set, then both RHCLR and drive clear
failed. If it did not not clear, and RHCLRF is clear,
then only the drive clear failed. If it did clear, and
RHCLRF is set, then only the RHCLR failed. If it did
clear, and RHCLRF is clear, then both RHCLR and drive
clear worked and there is no error.
Page 26
Additional
We know from test 11 that the DMD bit in the maintenance register
is not stuck at zero or one. Therefore, if we set the bit and it
clears with the drive clear command, we know that the command
decoder and go bit are at least partially functioning the way they
should.
18.0 Test-13 Test for multi-drive response
Description
This test is effectively the complement of test 1. This test
insures that the drive being tested does not respond to any other
drive's device select code but its own. The test sequence is:
1. Write control register of drive under test with a data
pattern of 70. Call this drive-X.
2. Select some other drive (whether present or not), and call
this drive-Y.
3. Write control register of drive-Y with zeroes.
4. Read control register of drive-X and verify that it has
not been modified (still 70).
5. If step 4 fails, report error and loop if loop on error is
set. If step 4 doesn't fail repeat all steps letting Y
range from 0 to 7 but not equal to X.
Additional
If this test fails, it means the drive being tested is responding
to some other drive's device select code and the same items
outlined in test 1 should be checked.
19.0 Test-14 Test parity error detection
Description
This test verifies the correct operation of the parity error flag
(PAR) and illegal function flag (ILF) when an illegal command is
issued to the drive and the drive detects a parity error. We
accomplish this by issuing the command with bad parity. In this
case the drive should only set the parity error flag, since it
isn't possible for the drive to tell if the command was a legal
command or not (because of the parity error). The test first uses
an illegal command with an odd number of bits (fc=25) and then
uses an illegal command with an even number of bits (fc=27) to be
sure that the test works for both cases. The test sequence is:
Page 27
1. Read error register 1 and check to see if both PAR and ILF
clear. If they are, go to step 3, if not, go to step 2.
2. Issue an RHCLR and read error register 1 again. If both
PAR and ILF are clear go, to step 3. If either one isn't
clear, set the error flag and loop if enabled.
3. Initialize first time flag.
4. If this is the first time through, issue an illegal
function with an odd number of bits (fc=25) and force bad
parity. If it is not the first time through, issue an
illegal function with an even number of bits (fc=27) and
force bad parity.
5. Read error register 1 and determine state of PAR and ILF.
o If both are clear, set error flag and loop on steps
4
and 5. If both aren't clear, go to step b.
o If both are set, set error flag and loop on steps 4
and
5. If both aren't set, go to step c.
o If only ILF is set, set error flag and loop on steps
4
and 5. If ILF is not set and we got this far, it
means that only PAR was set, which is correct, and
we go to step 6.
6. Issue an RHCLR.
7. Read error register 1 and verify that PAR is clear. If it
isn't, set error flag and loop on steps 4 through 7. If
it is, go to step 8.
8. If this is first time through, set first time flag to -1
and go to step 4. If this is not first through, we are
done.
Additional
We are not specifically testing the ILF bit in this test, i.e.,,
we don't check it for all illegal commands. However, we are using
a double fault condition (illegal function and bad parity) in
order to isolate the problem to the 2901. If both PAR and ILF are
set or cleared, there is a good chance the 2901 is broken.
20.0 Test-15 Check drv for correct parity to RH20
Description
This test verifies that the drive sends correct parity to the RH20
controller. The desired address register is used again with the
patterns in table CBDAT, but this time we enable checking for a
control bus parity error. The test sequence is:
Page 28
o Select a pattern to be written.
o Write desired address with pattern.
o Read desired address register with control bus parity
checking enabled.
o Increment byte pointer and test if we are done with all
patterns.
Additional
After this test the parity network and detection logic is
completely tested.
21.0 Test-16 Verify that ERR is not stuck at one
Description
This test verifies that composite error (ERR) is not stuck at one.
The test sequence is:
o Issue a drive clear command to control register.
o Read status register and verify that ERR is clear.
Additional
None.
22.0 Test-17 Verify that ERR will set and clear
Description
This test verifies that composite error (ERR) will set and clear.
The test sequence is:
o Cause composite error by writing desired address register
with bad parity.
o Read error register 1 and verify that parity error (PAR)
is set.
o Read status register and verify that ERR is set.
o Issue a drive clear command.
o Read error register 1 and verify that PAR is clear. read
status register and verify that ERR is clear.
Additional
The parity circuits were completely tested in tests 14 and 15.
Page 29
23.0 Test-18 Verify that ATA is not stuck at one
Description
This test verifies that attention active (ATA) is not stuck at
one. The test sequence is:
o Issue a drive clear command to control register.
o Read status register and verify that ATA is clear.
Additional
None.
24.0 Test-19 Verify that ATA will set and clear
Description
This test verifies that attention active (ATA) will set and clear.
The test sequence is:
1. Cause composite error by writing desired address register
with bad parity.
2. Read status register and verify that ATA and ERR are set.
3. Issue a drive clear command.
4. Read status register and verify that ATA and ERR are
clear.
5. Repeat steps 1 and 2.
6. Issue an RHCLR.
7. Repeat step 4.
Additional
The parity circuits were completely tested in tests 14 and 15.
25.0 Test-20 First check of ATA position decode
Description
This test verifies that the attention summary register can be
cleared by issuing a massbus init. The test sequence is:
o Issue an RHCLR.
o Read attention summary register and verify that it is
cleared.
Page 30
Additional
If the test fails the attention summary register will be printed
and the status registers of all drives on the massbus will be
printed (if TXTINH isn't set). if it is some other drive that is
causing the problem, you may have to power down the drives one at
a time to isolate which drive is causing the problem.
26.0 Test-21 Correct position decode of ATA
Description
This test is a check of the correct operation of the position
decode of the attention summary register. The sequence is:
o Issue an RHCLR.
o Cause composite error by writing desired address register
with bad parity.
o Read status register and verify that ATA and ERR are set.
(this worked in test 17).
o Read attention summary register and verify correct
position for this drive.
o Write attention summary register with the correct bit for
this drive.
o Read status register and verify that ATA is clear and ERR
is set.
o Read attention summary register and verify that it is
cleared.
Additional
None.
27.0 Test-22 Unique position decode of ATTN
summary register
Description
This test verifies that the position decode of the attention
summary register is unique. The idea is to cause an attention and
then write all bits of the attention summary register except the
bit for the drive asserting attention. If position decoder is
working properly, check ATA in the drive under test will still be
set. The following sequence is used:
1. Issue an RHCLR.
Page 31
2. Cause composite error by writing the desired address
register with bad parity.
3. Read status register and verify that ATA and ERR are set.
4. Read attention summary register and verify that position
is correct for drive being tested.
5. Write attention summary register with bits for all drives
not under test.
6. Read status register and verify that ATA and ERR are still
set.
7. Read attention summary register and verify that position
is correct for drive being tested.
Additional
Steps 3 and 4 worked in test 21.
28.0 Test-23 Massbus ATTN line is not stuck at 1
Description
This test will verify that the massbus ATTN line is not stuck at
one. The test sequence is:
o Issue an RHCLR.
o Read attention summary register and save for possible
error report.
o Read RH controller status register and verify that massbus
ATTN is not asserted.
Additional
If this test fails the contents of the status registers of all
drives on this massbus will be printed (if TXTINH isn't set) in
order to see which drive is asserting ATTN. If you can't see an
obvious problem you may have to power down each drive one at a
time to isolate the faulty drive.
29.0 Test-24 Massbus ATTN can be set and cleared
Description
This test verifies that the massbus ATTN line can be asserted and
non-asserted. The test sequence is:
o Issue an RHCLR.
Page 32
o Cause ATTN by writing the desired address register with
bad parity.
o Read attention summary register and save for possible
error report.
o Read RH controller status register and verify that ATTN is
asserted.
o Issue a drive clear command.
o Read attention summary register and save for possible
error report.
o Read RH controller status register and verify that ATTN is
non-asserted.
Additional
None.
30.0 Test-25 Basic test of readin preset command
Description
This test is a basic test of the command decoder and uses a readin
preset command to check the response of the drive. The test
sequence is:
o Issue an RHCLR.
o Issue readin preset command.
o Read status register and verify that composite error
didn't set.
Additional
We could also get an "ILF" or other strange failure. we are
assuming that the command decoder is broken.
31.0 Test-26 Readin preset command test
Description
This test verifies the correct response to a readin preset
command. The test sequence is:
o Issue an RHCLR.
o Load desired address register with a 7 (arbitrary value).
o Load desired cylinder register with a 7 (arbitrary value).
o Write a one to the "FMT" bit (12) in the offset register.
Page 33
o Issue a readin preset command.
o Read desired address register and verify that it is
cleared.
o Read offset register and verify that it is cleared.
o Read desired cylinder register and verify that it is
cleared.
Additional
None.
32.0 Test-27 Verify correct response to CMD issued
with ERR set
Description
This test verifies that when a command is issued while composite
error is set, that the drive rejects the command. The test
sequence is:
o Issue an RHCLR.
o Cause composite error by writing desired address register
with all ones and bad parity.
o Write 377 to attention summary register to clear all
ATA's.
o Issue a readin preset command.
o Read drive status register and verify that ATA is set.
o Read desired address register and verify that it is
unchanged (all ones).
Additional
None.
33.0 Test-28 Verify correct response to CMD issued
with ATA set
Description
This test verifies that when a command is issued while attention
active (ATA) is set and no errors are left outstanding in the
drive (ERR is clear), that the drive accepts the command. The
drive should reset ata and execute the command. To verify this,
we will set the FMT bit in the offset register (just so there is
something there), then issue an offset command, and then issue a
readin preset command. The offset command is a NO-OP in the RP07
(it is there to provide compatibility with older drives) and
Page 34
should set ATA upon completion . The readin preset command should
clear the offset register (already verified in test 26) and should
not set ATA upon completion. Therefore, we have the sequence of a
command completing and setting ATA and another command completing
and not setting ATA. The test sequence is:
o Issue an RHCLR.
o Set the format bit in the offset register.
o Issue an offset command to the control register.
o Read status register and verify that ATA set and no error
occurred.
o Issue a readin preset command.
o Read status register and verify that ATA is clear and no
error occurred.
o Read offset register and verify that it is clear.
34.0 Test-29 Verify error register 2
Description
This test is run in preparation for running the microdiagnostic
routines resident in the RP07. It will verify that all
combinations of error codes are recognizable. This test utilizes
the communication wrapback feature.
35.0 Test-30 routine to read RP07 error log
Description
This routine will read and print the error log that is kept
updated by the RP07 microcontroller. The procedure is to select
the RDRAM routine (DIA17) which is loaded into the high byte of
the maintenance register. The hex address of the location in the
error log is loaded into the low byte of the maintenance register.
Additional
The information contained in the ERROR LOG is as follows:
o Number of times drive detected 'SEEK TOO LONG ERRORS'.
o Number of times drive detected 'SEEK OVERSHOOT ERRORS'.
o Number of times drive detected 'SOFT SEEK OVERSHOOT
ERRORS'.
Page 35
o Number of times drive detected 'SEEK INCOMPLETE ERRORS'.
o Number of times drive detected 'INDEX ERRORS', presently
inactive.
o Number of times drive detected 'PLO UNSAFE ERRORS'.
o The latest error code detected, also entered in unique
error code list with count.
o The oldest unique error code, in a list of up to ten (10)
.
o The number of times in decimal that the above error
occured.
o Up to nine (9) more unique error codes and there number of
occurences.
o The release level of the 8080 microcode.
o The release level of the 2901 microcode.
NOTE
All of the counters are printed in decimal, they count up
to 255 and if additional errors occur they will remain at
255. The counters do not recycle. There is only room for
ten (10) unique error codes and their count., If
additional unique error codes occur, the top entry
(oldest), and count will be lost. The nine error codes
below it in the list will be moved up the list with their
counts and the newest unique error code will be placed on
the bottom of the list with it's count.
When an error code is detected the list is scanned, if
already in the list, only the counter will be incremented.
The end result is the list will contain up to ten (10)
unique error codes and their counts. If more than ten
(10) unique error codes have occurred since
initialization, the list will contain the latest ten (10).
Therefore it is possible to lose some unique error codes
encountered, due to list over flow. But if these error
codes are occurring frequently, they will most likely be
on the list again as new unique error code entrys.
Page 36
36.0 TSTA Prepackaged control bus test script
Description
This is a package of tests for the control bus portion of the
massbus. It runs TST2 through TST29 in sequence, this is similar
to default mode with respect to the test dispatching, and is for
isolating problems in the control bus portion of the massbus. It
runs under manual mode MAN> and reduces test time if the problem
is known to be in this section of the massbus. TST1 the operator
intervention tests and TST30 are not run.
Page 37
37.0 Microdiagnostics chart by sequence
THIS LIST OF TESTS WAS GENERATED FROM uCODE LISTING DATED 05/27/80
SEQ. ROUT DESCRIPTION TEST NOTE
NUM. NUM. NAME
===============================================================
1 | 24 | PROM CHECK | ROMTST |
2 | 26 | INTERRUPT CHECK | INTTST |
3 | 27 | CPU UNSAFE | CPUSTS |
4 | 28 | TIMER TEST | TIMTST |
5 | 29 | BUS CHECK | BUSTST |
6 | 2A | ANALOG C | AATST |
7 | 2B | A/D | ADTST |
8 | 2C | A/D-D/A | DATST |
9 | 2D | OSCILLATOR | OSCTST |
10 | 2E | DIFFERENCE COUNTER | DCTST |
11 | 2F | LINEAR MODE | SRTST |
12 | 30 | CYLINDER DETECTOR | CDTST |
13 | 31 | POISTION CHANNEL | PCTST |
14 | 32 | SERVO AMPLIFIER | SEATST |
15 | 33 | CURVE GENERATOR | CGTST |
16 | 34 | COMM/MAINT REGISTER | CISTS |
17 | 23 | CROM PARITY (DCL) | CRPTST | 1
18 | 35 | CROM CHECKSUM | CRMCK | 1
19 | 36 | DCL1 | DCL1TS | 1
20 | 37 | DCL2 | DCL2TS | 1
21 | 38 | I/O WRAP | ICTST | 1
22 | 39 | FULL CHECK ON J12 | INTFT | 1
23 | 3A | SERDES WRAP | SRDTS | 1
24 | 3B | R/W BASIC | RWSTS | 1
25 | 18 | PLO UNSAFE | UNSTST |
26 | 19 | EMA CURRENT REPORTING | PDRTST |
27 | 14 | TACHOMETER DIAGNOSTIC | TACTST |
28 | 1A | SECT/L.A. REG/UNSAFE | INSC | 1
29 | 1B | R/W SAFTY EXT | RWSFX | 1
30 | 1C | SERDES | SDEXL | 1
31 | 1D | DATA ENCODE/DECODE | DECLX |
32 | 1E | READ TRACK DESCRIPTOR | CERTD | 2
33 | 1F | WRITE NULL | WRTNL | 2
34 | 20 | WRITE/READ | WRRTN | 2
35 | 21 | READ DATA | RDDTA | 2
36 | 22 | AM TEST | WAMCK | 2
-- | 46 | TACH. CAL. UTILITY | TCALA |
NOTES: 1. ONE PARAMETER IS USED IN FE MODE:
RUN OPTION (00 - DF) = DELAY TIME
FE = STOP ON ERROR
FF = SINGLE CYCLE
2. TWO PARAMETERS ARE USED IN THE FE MODE
(a) HEADER # (00 - 31) AND RIPPLE BIT 5
(b) RUN OPTION (00 - DF) = DELAY TIME
FE = STOP ON ERROR
Page 38
FF = SINGLE CYCLE
38.0 DIA-24 PROM check routine
This routine checks all the PROM's on the CPU card (A1A7) board.
There are 7 PROM"s that are checked by this test, if any PROM
besides the first one fails, the likely problem is with the PROM
itself (a less likely possibility is the IC that decodes select
for that PROM). If the first PROM fails the cause of the failure
are likely to be, the PROM itself, faulty address or data lines,
or a bad chip select decoder. The PROM test operates in the
following way:
o The sum (mod 255) of all the locations in the PROM should be
zero. When the PROM is burned in the last location of each
PROM is the 2's complement of the sum (mod 255) of all the
previous data in the PROM.
o The next to last location in the PROM should be all ones.
o The second to last (one prior to next to last) should be all
zeros.
o The error codes for this test are 10 through 12 and 14 through
17, they are as follows:
o 10 -- Error in CPU PROM 0, 0 - 2K address area.
o 11 -- Error in CPU PROM 1, 2 - 4K address area.
o 12 -- Error in CPU PROM 1, 4 - 6K address area.
o 14 -- Error in CPU PROM 2, 6 - 8K address area.
o 15 -- Error in CPU PROM 3, 8 - 10K address area.
o 16 -- Error in CPU PROM 4, 10 - 12K address area.
o 17 -- Error in CPU PROM 5, 12 - 14K address area.
Note: Error code 13 is used in a RAM test DIA0001 and not here.
39.0 DIA-26 Interrupt test
This routine checks the interrupt structure on the drive CPU
(A1A07) board. The interrupt service address for all interrupt
levels except the one being tested are set to an error handler.
The service address for the one tested is set to the normal
return. An interrupt is then sent out to the level being tested.
If an interrupt to the wrong level or no interrupt occures then
the error return is taken. Otherwise, the next level is checked
and the loop repeated until all interrupt levels have been tested.
The only error code for this test is 3E and follows:
Page 39
o 3E -- Interrupt test failed.
40.0 DIA-27 CPU unsafe circuit test routine
This routine checks the functioning of the 8080 unsafe circuit.
The test is in two parts, it first checks to see that no interrupt
is received from the circuit within 4 microseconds after the
circuit has been refreshed, then checks to see if an interrupt is
received within the next 4 microseconds. The error codes for this
test are 3C and 3D and follow:
o 3C -- No interrupt received.
o 3D -- Interrupt was too soon.
41.0 DIA-28 Timer 1,2, 3 of 8080 CPU, test
This routine tests the 8253 timer and it's associated circuitry.
It checks each timer in the chip by loading a timeout and then
jumping to a software timing loop until interrupted. It then
checks the amount of time it took to get the interrupt against the
software timeout and gives an error if they don't compare. If the
test fails, the problem could be the 8253 chip itself, the clock
interrupts, the latches associated with the timer or the interrupt
structure. The error codes for this test are 18, 19 and 1A and
follow:
o 18 -- Timer 1 circuitry failed.
o 19 -- Timer 2 circuitry failed.
o 1A -- Timer 3 circuitry failed.
42.0 DIA-29 Bus check routine
This routine verifies that the data bus is working. The test
first sends out all 0's to two different registers that are
capable of being both written and read, then reads back what was
sent out, if it doesn't compare on either of the registers, then
the test fails, the test is repeated using all 1's. If the test
fails, some possible causes of the error are:
o A bus driver getting on the bus when not enabled.
o Shorted input on a bus receiver.
Page 40
o Bus driver on the CPU card not working.
o Bus receiver on the CPU card not working.
o I/O read or write pulse not working.
o Short or open backplane wiring.
o This is a test of a bus and any of the following boards could
be hanging the bus, (A1A4 through A1A16 and A1A20). The error
code for this test is 1F and follows:
o 1F -- 8080 external bus test, this bus is across the
backplane and any of the above 14 boards could be
hanging the bus.
43.0 DIA-2A Analog "C" RAM test
This routine checks the Analog "A" RAM to insure proper operation
of the Analog "A" board. This check tests all bits of each RAM
location by using a test pattern that is rotated through the RAM
memory in such a fashion that all possible four bit patterns are
exercised for both the high and low order four bit groups of each
RAM location. At the same time faulty or shorted address lines
are tested for. An error in this test will indicate that a
problem exists with either the RAM, data lines or address lines.
The error code for this test is 60 and follows:
o 60 -- RAM failure to compare after a write then read
sequence.
44.0 DIA-2B Analog/Digital test routine
This routine checks the limits of conversion of the A/D converter.
It also performes the zeroing of the A/D converter. This is done
by inputing +15 Volts into the A/D and then checking the output to
see if it returns a value of 7F Hex. Then an input of - 15 Volts
is inputed and the resulting value is checked to ensure that it is
80 Hex. The offset is then checked by inputing 0 Volts to the A/D
and then checking to be sure that the value is +/- 0.75 Volts. An
error in this section will indicate a error in the A/D converter
on the Analog "C" card or in the multiplexor on the Analog "C"
card. The error codes for this test are 70 through 73 and follow:
o 70 -- Failure to saturate to 7F (hex) with +15 Volts
reference channel.
o 71 -- Failure to saturate to 80 (hex) with -15 Volts
reference channel.
Page 41
o 72 -- A/D failure to calibrate (A/D calibration offset
too positive).
o 73 -- A/D failure to calibrate (A/D calibration offset
too negative).
NOTE: If this test fails it may cause other tests to also fail.
45.0 DIA-2C A/D and D/A wrapback circuitry test.
This routine makes a basic check on the A/D and the D/A converts
on A1A04 board, this is done by setting the D/A to a specific
value and then wraping the channel around to the A/D, and then
checking if the proper voltage was produced. All MUX's data
selectors are involved in this test in such a way that all basic
parts of the A/D and D/A system are involved in some way. The
error codes for this test are 28 and 29 and follow:
o 28 -- D/A - A/D test (positive offset).
o 29 -- D/A - A/D (curve D/A reference) circuitry.
46.0 DIA-2D Analog "A" diff posi offset and cal
This test will automatically zero the differential position
offset. This series of tests requires the proper operation of the
test oscillator. The differential position offset is checked to
see if it is within specified limits, and referenced to the on
track signal. The AGC is checked to ensure that the AGC has
sufficient gain. This is accomplished by setting a normal AGC
value and then changing the AGC value by Epsilon, the change that
results in the AGC data is checked to make sure it is within
specified limits. The even and odd off track signals of the
differential position is checked to ensure that differential
position signal will supply sufficient amplitude to allow proper
operation. Any error in these routines will indicate a problem in
the Analog "A" circuits. The error codes for this test are 61,
62, and 64 through 66 and follow:
o 61 -- Difference position offset failure to calibrate.
o 62 -- AGC response to a positive change in gain.
o 64 -- Insufficient negative amplitude of difference
position.
o 65 -- Insufficient positive amplitude of difference
position.
o 66 -- Difference position offset was too large,
(test oscillator was on track).
Page 42
NOTE: This test makes use of the A/D and D/A on the Analog "C"
card.
47.0 DIA-2E Difference counter test
This routine tests the difference counter for all possible bit
combinations by rotating a test pattern through it. The counter
is then read back and checked for missing or added bits. An error
in this part will indicate that the counter register or the data
bus is bad. The difference counter clock is also checked for
proper operation. This is accomplished by repetitively setting
and resetting the difference counter clock enable line and then
checking the counter clock to verify that the clock is indeed
clocking the counter properly. The difference greater than 255
bit is also checked by this routine. This is done by setting the
difference counter to values greater than 255, first 256 then 512
and checking the greater than 255 bit to be sure that it has been
set. An error in this section will indicate that the difference
greater than 255 decoders are not operating properly. The error
codes for this test are 74 through 7B and follow:
o 74 -- Low difference counter test.
o 75 -- Difference greater than 255 set, (difference
= 0080 hex) test. Here we loaded 128 decimal into
difference counter, difference greater than 255 should
not have set.
o 76 -- Difference greater than 255 failed to set,
(difference = 0100 hex) test. Here we loaded 256
decimal into difference counter, now bit should set.
o 77 -- High difference counter failed on a read back,
(difference = 0100 hex). After the 256 decimal is
loaded into the difference counter to check the greater
than 255 bit, the counter is read to insure proper
operation.
o 78 -- Difference greater than 255 failed to set,
(difference = 200 hex) test. Here we loaded 512
decimal into difference counter, again the greater than
255 bit should set.
o 79 -- High difference counter failed on a read back,
(difference = 0200 hex). After the 512 decimal is
loaded into the difference counter to check the greater
than 255 bit, the counter is read to insure proper
operation.
o 7A -- Low difference counter clock test. The enable is
toggled on and off, and counter is checked for proper
operation.
o 7B -- High difference counter clock test. The enable is
toggled on and off, and counter is checked for proper
operation.
Page 43
48.0 DIA-2F Linear mode test - Status reg
This routine checks the linear mode status. This is done by
clearing linear mode and then checking to see if the linear mode
is low. Then linear mode is set and the linear mode set is
verified. The error codes are 7C and 7D and follow:
o 7C -- Linear mode reset test, reset linear mode then check
that it is low.
o 7D -- Linear mode set test, set linear mode then check
that is set.
49.0 DIA-30 Cylinder detector test
This routine checks the fine and coarse cylinders detectors. This
is done by simulating a on track signal and then testing both fine
and coarse cylinder detectors to ensure that they are set. Then
the position signal is set to it's maximum positive value and then
to it's maximum negative value. Then fine and course cylinder
detectors are checked to verify that they are low. The error
codes for this test are 6C through 6F and follow:
o 6C -- Fine cylinder detector bit, a logical AND is
preformed with register 32 and a mask of 01, testing
the fine cylinder detect bit. The (test oscillator on
track).
o 6D -- Coarse cylinder detector bit, a logical AND is
preformed with register 32 and a mask of 02, testing
the coarse cylinder detect bit. The (test oscillator
on track).
o 6E -- Fine or coarse cylinder set, the differential
position is set to = +6 Volts then both coarse and fine
cylinder detect bits are tested by a logical AND of
register 32 with a mask of 03. With (test oscillator
on track) and (+ odd defeat is true).
o 6F -- Fine or coarse cylinder set, the differential
position is set to = -6 Volts then both coarse and fine
cylinder detect bits are tested by a logical AND of
register 32 with a mask of 03. With (test oscillator
on track) and (+ even defeat is true).
50.0 DIA-31 Position and differential position
channel test, (EMA disabled)
The position and differential position channel are tested. This
is done by simulating on track signals as well as off track
Page 44
signals and then testing the resulting responses via the position
and differential position channels. Proper operation is verified
by testing the resulting output and comparing it to a expected
value. The error codes for this test are 2A through 2F and
follow:
o 2A -- Filtered differential position channel more negative
than -4.5 Volts,(C4 hex), (-test oscillator PLO
unsafe-1 and +even defeat set).
o 2B -- Position channel is more positive than + 4.5
Volts, (3C HEX), (-test oscillator PLO unsafe -1 and
+even defeat set).
o 2C -- Filtered difference position channel is more
positive than +0.5 Volt, (07 hex), (-test oscillator
PLO unsafe-1 set).
o 2D -- Filtered difference position channel is more
negative that minus 0.5 Volt, (F9 hex), (-test
oscillator PLO unsafe-1 set).
o 2E -- Position channel is more positive than +0.5 Volts,
(07 hex. (-test oscillator PLO unsafe-1 set).
o 2F -- Position channel is more negative than minus 0.5
Volts, (F9 hex), (-test oscillator PLO unsafe-1 set).
51.0 DIA-32 Servo Error Amplifier (EMA Disabled)
This routine verifies that the servo error amplifier offset is
within the specified 0.5 Volt window. This is accomplished by
simulating an on-track signal and then testing the servo error
test point to verify that the offset is within limits. An error
code for this test are 48 and 49 and follow:
o 48 -- Servo Error Offset Greater than 0.05 Volts
o 49 -- Servo Error Offset More Negative than minus 0.5 Volts
52.0 DIA-33 Curve generator test (EMA disabled)
Tests the curve generator to be sure that references are operating
properly. This routine checks the curve for proper operation.
This is done by loading the difference counter with specific
values. Then testing the curve generator TP and the curve
generator D/A to ensure that the curve generator is producing the
proper values. The curve is checked at three points, the upper
limit, lower limit and at the center of it's range. The error
codes for this test are 57 through 5F and follow:
o 57 -- Testing curve A/D converter output, difference
counter = 0, (0 hex), failure if output is more
positive than +300 Mvolts (05 hex).
Page 45
o 58 -- Testing curve generator output, difference counter
= 0, (0 hex), failure if output is more negative than
minus 300 Mvolts (FC hex).
o 59 -- Testing curve generator output, difference counter
= 10 (0A hex), failure if output is more negative than
minus 2.2 Volts (E4 hex).
o 5A -- Testing curve generator output, difference counter
= 10, (0A hex), failure if output is less than minus
1.2 Volts (F1 hex).
o 5B -- Testing curve A/D converter output, difference
counter = 10 (0A hex), failure if more than +1 Volt (0D
hex).
o 5C -- Testing curve A/D converter output, difference
counter = 10 (0A hex), failure if less than plus 500
Mvolts (07 hex).
o 5D -- Testing curve A/D converter output, difference
counter = 127 (7F hex), failure if more than plus 9.75
Volts (7D hex).
o 5E -- Testing curve generator output, difference counter
= 127 (7F hex), failure if less than minus 7 Volts (A4
hex).
o 5F -- Testing servo error output, difference counter
= 127 (7F hex), failure if less than minus 5 Volts (BE
hex).
53.0 DIA-34 Comm and Maint register test
This routine checks the functioning of the CIS board A1A08. The
communications register is checked by sending one bit high at a
time to the "S" bus and then wrapping it back through the "Y" bus.
The 2901 "Y" bus and the "S" bus are tri-stated during this test.
The errors codes for this test are 7E and 7F and follow:
o 7E Communications register self wrap test, this test is
internal to the A1A8 board but A1A9, A1A10, A1A12 and
A1A14 may load the "Y" and/or "S" bus.
o 7F Maintenance register, this test is internal to the
A1A8 board but A1A11, A1A12 or A1A13 may load the "T"
bus.
54.0 DIA-23 DCL CROM parity test.
This test checks for parity errors in the CROM of the DCL A1A09
and A1A10. All locations from 0000 to 0DFF will be checked
excluding 01F7 through 01FF, these are reserved for checksum
storage. The error code for this test is 8F and follows.
Page 46
o 8F -- DCL CROM parity error
55.0 DIA-35 CROM checksum on DCL1 and DCL2 test
This routine will verify the CROM checksum by generating a sum
based on the data read from the CROM's and compare this sum with
pre-stored sums in CROM 0. The test for CROM 0 itself is
different in that it only checks itself to be zero. The following
locations in CROM 0, are used for storage of checksums.
ADDRESS CONTENTS ADDRESS CONTENTS
1FF Revision Level 1FB CROM #3 Checksum
1FE CROM #0 Adjustment 1FA CROM #4 Checksum
1FD CROM #1 Checksum 1F9 CROM #5 Checksum
1FC CROM #2 Checksum 1F8 CROM #6 Checksum
The error codes for this test are 30 through 36 and follow:
o 30 -- Testing first 512 words (0000 to 01FF hex) of CROM
for proper checksum.
o 31 -- Testing second 512 words (0200 to 03FF hex) of CROM
for proper checksum.
o 32 -- Testing third 512 words (0400 to 05FF hex) of CROM
for proper checksum.
o 33 -- Testing fourth 512 words (0600 to 07FF hex) of CROM
for proper checksum.
o 34 -- Testing fifth 512 words (0800 to 09FF hex) of CROM
for proper checksum.
o 35 -- Testing sixth 512 words (0A00 to 0BFF hex) of CROM
for proper checksum.
o 36 -- Testing seventh 512 words (0C00 to 0DFF hex) of CROM
for proper checksum.
56.0 DIA-36 DCL1 check routine
External bus, Pattern exchange (8080 to DCL and return, DCL1
unsafe, diagnostic timeout, diagnostic timeout, and diagnostic
response or handshaking (from DCL) tests. The error codes for
this test are 69, 81 through 86 and D0 and follow.
o 69 -- CROM parity bit test.
o 81 -- Communications register wrap test and external bus
test.
o 82 -- Handshaking failure, wrong code received from DCL.
Page 47
o 83 -- Pattern exchange, from 8080 to DCL and back, testing
pattern transmission and reception circuitry.
o 84 -- DCL1 unsafe test.
o 85 -- DCL2 timeout test.
o 86 -- DCL2 diagnostic response test.
o D0 -- DCL2 "OP" register test.
57.0 DIA-37 DCL2 check routine
This routine checks the functioning of the DCL2 board (A1A10). It
tests the operation register, external branch in force mode, state
branch register, sync register, "S" clock control function, vector
interrupt, interrupt at vector address 00 and 1F, wrap test
byte/word register, byte/word counter and DCL status register.
The error codes for this test are 85, 86, D0 through D6 and D8 and
follow:
o 85 -- DCL2 handshaking timeout test.
o 86 -- DCL2 diagnostic reply from DCL1 (high byte)
incorrectly returned.
o D0 -- DCL2 "OP" register test, external branch failed in
force mode or "OP" register failed in bit test
capability.
o D1 -- DCL2 status register test.
o D2 -- Sync register and it's branch test failed in
diagnostic clear mode and it's associated branch
conditions, the branch conditions are:
DCL2BR INDEX AM DETECT EXE IN
RWGOOD DEVCK ECCOK ENDBR
o D3 -- DCL2 Interrupt in force mode-1 at vector 00 failed.
o D4 -- DCL2 byte count and word count register, compare
o D5 -- DCL2 status register failed.
o D6 -- DCL2 "S clock" control test failed.
o D8 -- External register failed on DCL2 board, there are
two read/write DCL registers on the DCL2 board, the
"OP" and "BC" registers, either one failed in the wrap
check with DCL1.
58.0 DIA-38 Interface control check routine
This routine checks the functioning of the interface control board
A1A12. The following DCL external registers are wrap checked, ECC
pattern and position registers A1A14, error register 1 and 3,
desired address and cylinder registers, current cylinder register
and offset register. The error code for this test is DA and
Page 48
follows:
o DA -- Communication register wrap test via external
registers. There are eight DCL read/write registers on
the I/O control board, the test sequence is RPEC2,
RPEC1, RPER3, RPDA, RPCC, RPDC, RPOF and RPER1. Any
one can cause this failure.
59.0 DIA-39 Interface control test
General
This test will check out the A1A12 board. It can be called by the
CE when in CE local mode or from the system through the diagnostic
mode. This routine starts on Prom 2. The routine takes one
parameter when running from the local mode and it is described as
follows:
00 = Execute partial test.
01-FD = Execute the full test with the delay timer
defined by the parameter.
FE = Execute the fill test and stop if an error
is detected.
FF = Execute the full test in single cycle mode.
Full and partial as referred to above describe how the test will
exercise the parity checker on the TBUSC interface lines. When
full is invoked, the entire range of patterns will be used to
verify proper operation of the parity checker which will cause
test 1 to take about 25 seconds to complete. If partial is
selected, only one pattern will be used to check out the parity
checker. This capability is provided to allow the user to scope
failures in other parts of the test with a better (higher
repetition rate) environment. When in the online mode, full
testing is forced.
o Test 1 Parity/Maintenance register test. This test will check
out the TBUS parity checker and the maintenance register on
the TBUS. High and low pair contains the pattern of the
parity checking starting with all 0's and insertion of 1's
each time, so it is 16 times to loop through the whole
pattern. Error codes 90, 91 and 92 are posted by this test.
o Test 2 RPDS test. This test will check out the DS register by
loading it through the 2901 and then reading it back through
the maintenance register. The patterns that are checked are
0's, then an alternating pattern of 1's and 0's. The
alternating pattern is not a true test as some bits are not
throughly tested due to their effect in the hardware.
Page 49
o Test 3 ER2/CTLF register check. This test is designed to
check out the ER2 register and the gating controls for the
error presentation. Also the CTLF register on A1A08 board is
checked out here. This test supply the error codes 94, 95, 96
and 97 as planned errors.
o Test 4 File test. This test will check out all registers in
the file. The inhibit function of error signal for registers
ER1, ER3, EC1 and EC2 is also verifyed by this test. On entry
this test expects error to be set and high/low to be zero.
Error codes 98 and 99 provided as primary errors for this
section.
o Test 5 Massbus write. This test is for massbus write of OF,
DC and DA registers. This test starts using the massbus write
capability. It checks out writting into OF, DA and DC
registers, then reading them back and also testing the errors
on A1A12, and the valid bits for the registers. Error codes
9A, 9B, 9C and 9D are used as primary errors for this test.
o Test 6 Command register test. This test checks out some parts
of the command register and the NOP1 and NOP2 commands.
o Test 7 Preset command test. This test issues the preset
command and checks out the invaliditity and validation of the
DA, DC and OF register
o Test 8 Invalid command test. This test will issue some
invalid commands with good and bad parity to check out of GO
and RMR.
o Test 9 Illegal register test. This test checks out illegal
register detection logic for reads and writes, and that
registers do not get modified when illegal address is
detected.
o Test 10 Special attention and inhibit test. This test checks
out special attention and the inhibit write function when
error is asserted.
o Test 11 Diagnostic command and drive clear test. This test
checks out the functions of the diagnostic command interrupt
and drive clear on the A1A07, A1A08 and A1A12 boards. The
routine will supply one error code B9.
o Test 12 DMD bit test. This test checks out the DMD bit on the
A1A08 board. It uses the error code of BA.
The error codes for this test are 90 through 9F, A0 through AF, B0
through BA, BE and BF and follow:
o 90 -- Floating "T BUSC" checks, maintenance register and
accumulator circuits. With the "T BUSC" floating (all
high). The accumulator checks for any pulled down or
Page 50
low bits.
o 91 -- "T BUSC" patery generator circuit and the CPA line
for either partial (only one pattern) or all patterns
with normal CPA line and CPA set to zero.
o 92 -- Testing the maintenance register read function,
this is done by writing different patterns into the
maintenance register and reading them through the D BUS
and the 8080 and making a comparison.
o 93 -- RPDS register test, testing the "DS" register by
loading different patterns through the 2901 and reading
it back through "T BUSC", maintenance register, D BUS
and the 8080. This data path has been checked by an
earlier tests.
o 94 -- Testing output control of the RPER2 register with
8080 SETER signal not set. The ER2 register which has
it's low byte on A1A8 and high byte on A1A12 is tested
by not setting 8080 SETER the output of the register
ER2 is in the high impedance state. This verifies that
the control functions properly on both A1A8 and A1A12.
o 95 -- Testing output control of the RPER2 register with
8080 SETER signal active. The ER2 register which has
it's low byte on A1A8 and high byte on A1A12 by not
setting the signal 8080 SETER the ER2 register is read.
This verifies that the output is zero with zero input.
o 96 -- Testing RPER2 register, low byte. This test is
performed with 256 different patterns, ER2 low byte is
on A1A8.
o 97 -- Testing RPER2 register, high byte. This test is
performed with 256 different patterns, ER2 high byte is
on A1A12.
o 98 -- Testing register file. All eight registers RPER1,
RPDA, RPOF, RPLDC, RPCC, RPER3, RPEC1 and RPEC2 in the
register file are tested by loading 16 different
patterns and reading them through the maintenance
register and the 8080 accumulator, then comparing the
results.
o 99 -- Testing inhibit function of the register file.
When the "-ERR" signal is active the register file
cannot be read.
o 9A -- Massbus write and read of the "DA" register.
Sixteen different patterns are written into the "DA"
register through the maintenance register, and read
back into the maintenance register and compared.
o 9B -- Massbus write and read of the "DC" register.
Sixteen different patterns are written into the "DC"
register through the maintenance register and read back
into the maintenance register and compared.
o 9C -- Massbus write and read of the "OF" register.
Sixteen different patterns are written into the "OF"
register through the maintenance register and read back
into the maintenance register and compared.
o 9D -- Testing the "DA", "DC" and "OF" register. Massbus
write of "DA", "DC" and "OF" registers. Incorrect
status has been reported from the A1A12 board.
Page 51
o 9E -- Testing massbus write of "CS1" register. Command
register test is done by setting one command bit at a
time and doing a massbus write into "CS1" register
through the maintenance register and then reading back
through the maintenance register.
o 9F -- Testing command register preset command. When
preset is set the invalid signals "-RPOFINV",
"-RPDCINV" and "-RPDAINV" should be true (low).
o A0 -- Inhibiting the "DA" register with preset command.
This command should inhibit any output from the "DA"
register when it is read.
o A1 -- Inhibiting the "DC" register with preset command.
This command should inhibit any output from the "DC"
register when it is read.
o A2 -- Inhibiting the "OF" register with preset command.
This command should inhibit any output from the "OF"
register when it is read.
o A3 -- Preset command test, validation of the "DA", "DC"
and "OF" registers with a massbus write command. With
the preset command set, a massbus write into these
registers should validate them. The validate flags
should be set.
o A4 -- Preset command test test, validation of the "DA",
"DC" and "OF" registers with a 2901 write command.
With the preset command set, a command to the 2901 to
write these registers should validate them.
o A5 -- Invalid command test, write parity error. Testing
that a parity error will set when an invalid command
with bad parity is sent to the "CS1" register.
o A6 -- Invalid command, device check and A1A12 unsafe.
Test that device check and A1A12 unsafe set when a
invalid command with bad parity is issued.
o A7 -- Invalid command, massbus write to "CS1". Testing
to see if "GO" bit will set when an invalid command is
issued to the "CS1" register. The "GO" bit should set.
o A8 -- Massbus write command with "GO" bit set. The "RMR"
bit should be set when attempting to write "CS1" with a
NOP command, and the "GO" bit is set. If "RMR" should
set.
o A9 -- Massbus write "CS1" command with "RMR" bit set.
Device check and unsafe should set when attempting to
write "CS1" with a NOP command while "RMR" is set.
o AA -- Massbus write of the "CS" register with "GO" bit
set. If "GO" bit is set it should inhibit writting
into the "CS" register.
o AB -- Massbus write of the "OF" register with "GO" bit
set. If "GO" bit is set it should inhibit writting
into the "OF" register.
o AC -- "GO" reset test. Testing to see if the 2901 command
to reset the "GO" signal functions correctly.
o AD -- Illegal register test, register 11. Testing to see
if "ILR" bit will set when attempting a massbus read of
an illegal register 11. If "ILR" should be set.
Page 52
o AE -- Illegal register test, changes in maintenance
register. Checking if the contents of the maintenance
register are modified when an illegal register is
addressed, no modification should occur.
o AF -- Illegal register test, device check and A1A12
unsafe. Checking that device check and A1A12 unsafe
bits are active when an illegal register is addressed.
o B0 -- Illegal register test, register 12. Checking to see
if the contents of the maintenance register are changed
when an illegal register command "MBR12" is issued.
Maintenance register should not be modified.
o B1 -- Illegal register test, register 13. Checking to see
if the contents of the maintenance register are changed
when an illegal register command "MBR13" is issued.
Maintenance register should not be modified.
o B2 -- Illegal register test, write command. Testing
that "ILR" bit sets when attempting to write an illegal
register.
o B3 -- Massbus write to an illegal register, test for
"CS1" modification. Attempting to write to an illegal
register with a massbus write command, and checking
"CS1" for any modification, none should occur.
o B4 -- Illegal register write command, test for "ILR"
bit. "ILR" must set when a massbus write to an illegal
register is attempted.
o B5 -- Illegal register write command, validation of the
"OF" register. The "OF" register should not get
validated by an illegal register write command.
o B6 -- Testing for "ATTN" bit with the massbus write
command and "ERR" set. Checking to see if the
attention bit gets set when attempting to write into
the "ER1" register with the massbus write command while
the "ERR" bit is set.
o B7 -- Inhibiting the massbus write command with error
set. Any massbus command to write into the "ER1"
register with "ERR" set should not write into that
register.
o B8 -- Inhibiting the massbus write commands of the read
only registers, "CC", "ER3", "EC1" and "EC2" while
"ERR" is set. Verifying that massbus write commands
into the "CC", "ER3", "EC1" and "EC2" registers will
not change their contents if "ERR" is set.
o B9 -- Testing the diagnostic command interrupt and
drive clear. These functions are on A1A07, A1A08 and
A1A12. The A1A07 and A1A08 boards have been tested
earlier.
o BA -- "DMD" bit check.Testing the "DMD" bit of status
register on A1A08, this signal is also on A1A12.
o BE -- Testing error logic of A1A12 board. Testing three
error signals, "TCBUSPARER", "+ILR" AND "+RMR", all
three should be inactive. "TCBUSPARER" is (T and/or C
bus parity error).
o BF -- Command register test, "GO" and "ATTENTION" bits
reset. Testing the command register with a NOP
command, the "ATTENTION" and "GO" bits should not set
Page 53
under this condition.
60.0 DIA-3A Serdes wrap check routine
This routine checks the functioning of the SERDES board A1A14 It
is entered at SRDCK from initialization routine or system
diagnostic and at SRDTS from CE monitor. The error code for this
test is E2 and follows:
o E2 -- External register wrap test via DCL1, testing wrap
circuitry.
61.0 DIA-3B Read/Write safty wrap check
This routine checks the functioning of the read/write safty board
A1A16. It is entered at RWSCK from initialization or system
diagnostic and at RWSTS from CE monitor. The error code for this
test is F0 and follows:
o F0 -- External register wrap via the read/write safty
board. Testing read/write safty circuitry A1A16.
62.0 DIA-18 Phase lock osc, unsafe
This routine tests the unsafe circuitry and the index timing.
This unsafe check is accomplished by simulating a unsafe condition
and then testing to be sure that the unsafe has occurred. Index
timing is tested before measuring the time interval between index
pulses and then testing to see if the time interval is within 3%
of the specified limit. If an error results then the pack is not
up to speed or a fault exists with the PLO unsafe or the index
timing circuits. The error codes for this test are 67 and 68 and
follow:
o 67 -- PLO unsafe-1 test failure. Testing the unsafe-1
circuitry.
o 68 -- PLO unsafe-2 test failure. Testing the unsafe-2
circuitry.
Page 54
63.0 DIA-19 EMA current, Pulser/Driver test
The Pulser/Driver PROM is tested for no active outputs, forward
outputs and reverse outputs. Then the Pulser/Driver is tested for
maximum reverse drive, offset current, calibration circuits, pulse
and drive current forward and reverse and error detection while
driving to the forward and reverse stops. The error codes for
this test are 4B through 4F, 54, 56, 63 and 8B through 8D, they
follow:
o 4B -- Analog "B" test. Testing the Pulser/Driver
PROM and associated circuitry for no active outputs.
o 4C -- Analog "B" test. Testing the Pulser/Driver
PROM and associated circuitry for pulse forward and
drive forward outputs. Does not respond to difference
counter bit 256 in forward.
o 4D -- Analog "B" test. Testing the Pulser/Driver
PROM and associated circuitry for pulse reverse and
drive reverse outputs. Does not respond to difference
counter bit 256 in in reverse.
o 4E -- EMA current sample. Testing the (maximum
reverse drive) circuitry. Insufficient EMA current.
o 4F -- EMA current sample. Testing the (maximum
forward drive) circuitry. Insufficient EMA current.
o 54 -- EMA current offset calibration. Testing
the offset calibration circuitry, error is negative.
o 56 -- EMA current offset calibration. Testing
the offset calibration circuitry, error is positive.
o 63 -- Test pulse forward and drive forward. Fails if
Pulser/Driver does not respond in forward mode.
o 8B -- Testing servo error reverse mode. Servo error
not greater than 4.0 Volts in reverse mode, by driving
carriage to rear stop.
o 8C -- Test pulse reverse and drive reverse. Fails if
Pulser/Driver does not respond in reverse mode.
o 8D -- Testing servo error forward mode. Servo error not
less than 4.0 Volts in forward mode, by driving
carriage to forward stop.
64.0 DIA-14 Tachometer diagnostic testing
The tachometer circuits are tested for output between zero and 250
Mvolts low and high bandwidth, output greater than 10 Volts with
high slew rate and bandwidth and output between 4.5 and 6.5 Volts
high slew rate and low bandwidth. Also tachometer integration
positive forward and reverse are tested. The following error
codes will be reported, C0 through C6 as follows:
Page 55
o C0 -- Tachometer on track test, low bandwidth. Testing
the tachometer output to be between zero and 250 Mvolts
with low bandwidth while on track.
o C1 -- Tachometer on track test, high bandwidth. Testing
the tachometer output to be between zero and 250 Mvolts
with high bandwidth while on track.
o C2 -- Tachometer integration test, positive and forward.
Testing tachometer while test oscillator is set to
maximum positive value and EMA current offset is set to
maximum positive value in forward direction.
o C3 -- Tachometer integration test, positive and reverse.
Testing tachometer while test oscillator is set to
maximum positive value and EMA current offset is set to
maximum positive value in reverse direction.
o C4 -- Tachometer integration test, negative and forward.
Testing tachomete