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 ', 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 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 tachometer while test oscillator is set to maximum negative value and EMA current offset is set to maximum negative value in forward direction. o C5 -- Tachometer differentiator test, high bandwidth. Testing tachometer differentiator output to be greater than positive 10 Volts during high slew simulation and