|
DataMuseum.dkPresents historical artifacts from the history of: CP/M |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about CP/M Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - download
Length: 37376 (0x9200)
Types: RcTekst
Names: »99110092.WP«
└─⟦7fab0c8ae⟧ Bits:30005866/disk3.imd Dokumenter i RcTekst format (RCSL 99-1-*)
└─⟦this⟧ »99110092.WP«
╱0400274e0c0006000000000301483160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
════════════════════════════════════════════════════════════════════════
↓
┆14┆┆b3┆↲
↲
╞ __________________________↲
╞ RCSL No.:╞ 991 10092↲
╞ Edition:╞ ┆84┆April 1985↲
╞ Author: ╞ Peter Lundbo↲
↲
↲
↲
↲
↲
INTERNAL DOCUMENT↲
↲
↲
↲
↲
↲
________________________________________________________________________↲
↲
Title:↲
↲
╞ ╞ ╞ ╞ ╞ ┆06┆┆84┆The RC39 Selftest Concept↲
╞ User's Manual↲
↲
↲
________________________________________________________________________↲
════════════════════════════════════════════════════════════════════════
↓
Keywords:↲
╞ ╞ RC39, INTEL MULTIBUS, XENIX, SBC Selftest, "test-master",↲
╞ ╞ "test-slave", Remote Diagnostic.↲
↲
↲
Abstract:↲
╞ ╞ This manual documents the RC 39 SBC hardware selftest system.↲
↲
↲
╞ ╞ ( xx printed pages)↲
════════════════════════════════════════════════════════════════════════
↓
╱0400274e0a00060000000003013c3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
╱0400274e0c0006000000000301483160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
↓
┆06┆i↲
↲
┆a1┆┆e1┆┆a1┆TABLE OF CONTENTS┆05┆PAGE↲
↲
1. INTRODUCTION ........................................ 1↲
↲
2. THE OBJECT OF THE TEST .............................. 2↲
↲
3. HARDWARE CONFIGURATION .............................. 3↲
↲
4. THE "TEST-MASTER" ................................... 4↲
4.1 Hardware Prerequisites .......................... 6↲
4.2 Interactive CPU 610 Test Stimulation ............ 6↲
4.2.1 Baud Rate Determination ................... 6↲
4.2.2 Commands .................................. 7↲
4.2.3 Change Parameters ......................... 8↲
4.3 Automatic Configuration ......................... 9↲
4.4 Request Multibus Monitoring ..................... 11↲
↲
5. THE "TEST-SLAVE" .................................... 17↲
5.1 Hardware Prerequisites .......................... 19↲
5.2 Interactive Selftest Stimulation ................ 20↲
╞ 5.2.1 Baud Rate Determination ................... 20↲
╞ 5.2.2 Commands .................................. 21↲
5.2.3 Change Parameters ......................... 22↲
↲
6. SELFTEST ADMINISTRATION PROGRAM ..................... 23↲
6.1 Test Parameters ................................. 24↲
↲
7. TEST RESULTS ........................................ 26↲
↲
8. REMOTE DIAGNOSTICS .................................. 27↲
════════════════════════════════════════════════════════════════════════
↓
┆06┆ii↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆14┆┆b3┆┆06┆┆0b┆┆b0┆↓
┆a1┆↓
┆a1┆┆b0┆1. INTRODUCTION↲
↲
The RC 39 product is an INTEL Multibus based processor ↓
system specially designed to support the XENIX (MICROSOFT ↓
trade mark) or other UNIX alike (BELL LABS trade mark) ↓
operating systems.↲
↲
The system is composed of a set of single board computers ↓
(SBC) each considered as an intelligent unit, some with the ↓
role as potential Multibus masters and others with the role ↓
as potential slaves.↲
↲
Every RC-manufactured intelligent Multibus SBC will be ↓
equipped with extensive selftest facilities, which may be ↓
considered as an integrated part of the system bootload ↓
facility, where the bootloading is inhibited if a serious ↓
hardware malfunction is detected during the default selftest ↓
execution.↲
↲
In the test phase a RC 39 system must be considered as ↓
consisting of one and only one "test-master", and a number ↓
of "test-slaves". After power-on all the intelligent ↓
Multibus cards will execute their built-in selftests ↓
concurrently. When the "test-master" has completed its own ↓
selftest succesfully, it will be able to monitor the test ↓
results from all other SBC's and to make a system ↓
configuration schedule.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆2. THE OBJECTS OF THE TEST↲
↲
It is the intention of the system of SBC-selftests to cover ↓
three in the nature different needs.↲
↲
a) ┆84┆The RC 3922 system is equipped with a power-on ↓
┆19┆┆83┆┄┄verification of the hardware functionality. A set of test ↓
┆19┆┆83┆┄┄programs are run in sequence after power-on. The programs ↓
┆19┆┆83┆┄┄are organized with rising complexity, so that as far as ↓
┆19┆┆83┆┄┄possible no part of the hardware is used before it is ↓
┆19┆┆83┆┄┄tested. The power-on test require no interaction from an ↓
┆19┆┆83┆┄┄operator, but if a hardware failure is discovered during ↓
┆19┆┆83┆┄┄the selftest the normal system start-up procedure is ↓
┆19┆┆83┆┄┄inhibited.↲
↲
b) ┆84┆It gives the Production Department the possibility of ↓
┆19┆┆83┆┄┄using the same test programs as a ┆b0┆burn in ┆f0┆facility. This ↓
┆19┆┆83┆┆81┆┄is uptained by the fact that the test programs may be ↓
┆19┆┆83┆┆81┆┄controlled from a connected console. The test programs in ↓
┆19┆┆83┆┆81┆┄the RC 39 system may be directed to run either in loop-↓
┆19┆┆83┆┆81┆┄mode, or in a big sequential loop including all the tests ↓
┆19┆┆83┆┆81┆┄run by default in the power-on situation plus some ↓
┆19┆┆83┆┆81┆┄special tests (┆b0┆extended tests┆f0┆), which may require ↓
┆19┆┆83┆┆82┆┄additional test-hardware installed. These tests may be ↓
┆19┆┆83┆┆82┆┄repeated in the infinite, or at least until an error ↓
┆19┆┆83┆┆82┆┄occur. Moreover a possibility of running special ┆b0┆seperate ↓
┆19┆┆83┆┆83┆┆82┆tests┆f0┆, which cannot get included in any sequential test, ↓
┆19┆┆83┆┆83┆┄exists.↲
↲
c) ┆84┆It provides the Technical Service Department with a ↓
┆19┆┆83┆┄┄diagnostic tool that helps both to evaluate the hardware ↓
┆19┆┆83┆┄┄functionality and to locate errors. There is no garanty ↓
┆19┆┆83┆┄┄at all of debugging down to the chip level, this may be ↓
┆19┆┆83┆┄┄done with the help of additional tracing equipment.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆3. HARDWARE CONFIGURATION↲
↲
The first system covered by this specification is equipped ↓
with a mixture of the cards mentioned below.↲
↲
CPU 691╞ ╞ - ┆84┆INTEL manufactured iAPX 286 CPU board. This ↓
┆19┆┆90┆┄┄is the "test-master" card, and a maximum of ↓
┆19┆┆90┆┄┄one CPU 691 will be present in the RC 39 ↓
┆19┆┆90┆┄┄system.↲
↲
CPU 610╞ ╞ - ┆84┆RC manufactured iAPX 286 CPU Card. A maximum ↓
┆19┆┆90┆┄┄of two CPU 610 cards will be present in the ↓
┆19┆┆90┆┄┄RC 39 system, one with the role as a "test-↓
┆19┆┆90┆┄┄master".↲
↲
iSBC 012X╞ - ┆84┆INTEL manufactured 512 K-Byte / 2 M-Byte RAM ↓
┆19┆┆90┆┄┄boards.↲
↲
MEM 602/603╞ - ┆84┆RC manufactured INTEL compatible 512 K-Byte ↓
┆19┆┆90┆┄┄/ 2 M-Byte RAM boards.↲
↲
MSA 690╞ ╞ - ┆84┆Unintelligent Winchester and floppy ↓
┆19┆┆90┆┄┄controller.↲
↲
ETC 611╞ ╞ - ┆84┆Ethernet/Teletex Controller Card.↲
↲
COM 601╞ ╞ - BSC/SDLC/CIRCUIT I Communication Controller.↲
↲
ITC╞ 602╞ ╞ - ┆84┆V.24/CIRCUIT II Intelligent Terminal ↓
┆19┆┆90┆┄┄Controller.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆4. THE "TEST-MASTER"↲
↲
The "test-master" software will be installed on one CPU 691 ↓
or CPU 610 card. When the CPU has finished its default ↓
selftest without discovering errors it makes a Multibus ↓
configuration and then it will be possible to inhibit the ↓
bootloading and instead stress the "test-slaves" connected ↓
to the Multibus. The communication between the "test-master" ↓
and the "test-slaves" is accomplished by means of a polling ↓
strategy, the interrupt system is not used at all. The ↓
"test-master" program structure is shown on the next page.↓
════════════════════════════════════════════════════════════════════════
↓
╱0400274e0a00060000000002013c3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
╱0400274e0a00060000000003013c3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
↓
╞ ╞ ╞ ╞ ---------------------↲
╞ ╞ ╞ ╞ ! Power-on╞ ╞ !↲
╞ ╞ ╞ ╞ ---------------------↲
╞ ╞ ╞ ╞ ╞ ╞ !↲
╞ ╞ ╞ ╞ ---------------------↲
╞ ╞ ╞ ╞ ! Memory Test╞ !↲
╞ ╞ ╞ ╞ ! (ROM/RAM)╞ !↲
╞ ╞ ╞ ╞ ---------------------↲
╞ ╞ --------------------!↲
╞ ╞ ^╞ ╞ ---------------------↲
╞ ╞ ^╞ ╞ ! Test Administrator!↲
╞ ╞ ^╞ ╞ !╞ ╞ ╞ ╞ !↲
╞ ╞ ^╞ ╞ ! Select next test╞ !╞ ------------↲
╞ ╞ ^╞ ╞ !╞ ╞ ╞ ╞ !-------! Test 1 !↲
╞ ╞ ^╞ ╞ ! Write error/ok ╞ !╞ ------------↲
╞ ╞ ^╞ ╞ ! messages╞ ╞ !╞ ╞ !↲
╞ ╞ ^╞ ╞ !╞ ╞ ╞ ╞ !╞ ------------↲
╞ ╞ ^╞ ╞ ! Monitor Operator !-------! Test 2 !↲
╞ ╞ ^╞ ╞ ! entrys, and chan-╞ !╞ ------------↲
╞ ╞ ^╞ ╞ ! ge test mode.╞ !╞ ╞ !↲
╞ ╞ ^╞ ╞ !╞ ╞ ╞ ╞ !╞ ------------↲
╞ ╞ ^╞ ╞ ! Halt on error╞ !-------! Test n !↲
╞ ╞ ^╞ ╞ ! Loop in test╞ ╞ !╞ ------------↲
╞ ╞ ^╞ ╞ ! Burn in mode╞ ╞ !╞ ╞ !↲
╞ ╞ ^╞ ╞ ! Suppress data/╞ !╞ ╞ !↲
╞ ╞ ^╞ ╞ ! status check╞ ╞ !╞ ╞ !↲
╞ ╞ ^ !╞ ╞ ╞ ╞ !╞ ╞ !↲
╞ ╞ ^ ╞ ╞ ! ┆b0┆Default Tests╞ ┆f0┆!╞ ╞ !↲
╞ ╞ ^╞ ╞ ! ┆b0┆Extended Tests╞ ┆f0┆!╞ ╞ !↲
╞ ╞ ^ ╞ ╞ ! ┆b0┆Seperate Tests╞ ┆f0┆!╞ ╞ !↲
╞ ╞ ^╞ ╞ ---------------------╞ !↲
╞ ╞ ^╞ ╞ ╞ ╞ ╞ ╞ ╞ ╞ !↲
╞ ╞ ^╞ ╞ ╞ ╞ !-----------------------!↲
╞ ╞ ^╞ no╞ ---------------------↲
╞ ╞ ^---------! End of Test ?╞ !↲
╞ ╞ ^╞ ╞ !-------------------!↲
╞ ╞ ^╞ ╞ ╞ ! yes↲
╞ ╞ ^╞ ╞ ---------------------↲
╞ ╞ ^╞ ╞ ! Multibus Configu- !↲
╞ ╞ ^╞ ╞ ! ration.╞ ╞ ╞ !↲
╞ ╞ ^╞ ╞ ---------------------↲
╞ ╞ ^╞ ╞ ╞ ╞ !↲
╞ ╞ ^╞ ╞ ---------------------↲
╞ ╞ ^╞ ╞ ! Multibus Monito-╞ ! no↲
╞ ╞ ^╞ ╞ ! ring ?╞ ╞ ╞ !------------!↲
╞ ╞ ^╞ ╞ ---------------------╞ ╞ !↲
╞ ╞ ^╞ ╞ ╞ ╞ ! yes╞ ╞ ╞ !↲
╞ ╞ ^╞ ╞ ---------------------╞ ╞ !↲
╞ ╞ ^╞ ╞ ! Control "test- ╞ !╞ ╞ !↲
╞ ╞ ^╞ ╞ ! slaves"╞ ╞ ╞ !-----^╞ !↲
╞ ╞ ^╞ ╞ --------------------- ^╞ !↲
╞ ╞ ^╞ ╞ ╞ ╞ !╞ ╞ ^╞ !↲
╞ ╞ ^╞ ╞ --------------------- ^╞ !↲
╞ ╞ ^╞ ╞ ! Return to Test╞ ! no ^╞ !↲
╞ ╞ ^╞ ╞ ! Administrator ?╞ !-----^╞ !↲
╞ ╞ ^╞ ╞ ---------------------╞ ╞ !↲
╞ ╞ ^╞ ╞ ╞ ╞ ! yes╞ ╞ ╞ !↲
╞ ╞ ---------------------╞ ╞ ----------------↲
╞ ╞ ╞ ╞ ╞ ╞ ╞ ╞ ╞ ! BOOTLOAD╞ !↲
╞ ╞ ╞ ╞ ╞ ╞ ╞ ╞ ╞ ----------------↲
════════════════════════════════════════════════════════════════════════
↓
╱0400274e0a00060000000003013c3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
╱0400274e0a00060000000002013c3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
↓
┆a1┆┆b0┆4.1 Hardware Prerequisites.↲
↲
The selftest system makes a few assumptions about the "test-↓
master" hardware .↲
↲
a) ┆84┆The "test-master" card is designed with a V.24 interface ↓
┆19┆┆83┆┄┄equal the one on the "test-slaves". In the CPU 691 case ↓
┆19┆┆83┆┄┄no test-output switch is nescessary here, as long as the ↓
┆19┆┆83┆┄┄system is a single CPU system. But the CPU 610 card must ↓
┆19┆┆83┆┄┄be equipped with a master/slave strap and a "test-output" ↓
┆19┆┆83┆┄┄strap as well (see chapter 5).↲
↲
↲
┆a1┆┆b0┆4.2 Interactive "test-master" Stimulation.↲
↲
While the "test-master" is executing its own selftest it is ↓
sensitive to several commands entered from the tty-console ↓
connected to the on-board USART. These commands are primary ↓
issued by an operator who wants to inhibit the normal ↓
bootloading procedure and instead execute more selftest ↓
programs than are run in the default power-on situation.↲
↲
↲
┆a1┆┆b0┆4.2.1 Baud Rate Determination.↲
↲
The on-board "test-master" USART is not meant to be ↓
connected to a terminal running XENIX, it is only present ↓
for test and debugging purposes.↲
↲
When a terminal is present and the test-output switch is in ↓
V.24 position, then the selftest enters a Baud Rate ↓
determination mode.↲
↲
┆8c┆┆83┆┆8c┆↓
In this mode the USART is at first initialized to 9600 Baud, ↓
and * (stars) written to the console output. The selftest ↓
now awaits for the user to type 1 or 2 upper case U. If the ↓
connected console is operating at 9600, 4800 or 2400 Baud ↓
one upper case U is enough. If the connected console is ↓
operating at 1200, 600 or 300 Baud two upper case U must be ↓
typed. Other characters typed may easily cause the selftest ↓
to assume a wrong Baud Rate. The stars initially written to ↓
the console at 9600 Baud may be seen as stars, various other ↓
characters or not seen at all depending on the Baud Rate of ↓
the connected consol┆e1┆e┆a1┆┆e1┆. When the Baud Rate is determined the ↓
selftest is started.↲
↲
↲
┆a1┆┆b0┆4.2.2 Commands.↲
↲
The "test-master" is sensitive to the following commands.↲
↲
<esc>╞ ╞ - ┆84┆enables interactive change of test program ↓
┆19┆┆90┆┄┄flow and parameters ("test-master" menu ↓
┆19┆┆90┆┄┄request).↲
↲
<cntrl><A>╞ - ┆84┆Interrupt into Debug Monitor/Loader program.↲
↲
<cntrl><S>╞ - ┆84┆request test-monitoring of the "test-slaves" ↓
┆19┆┆90┆┄┄at the end of the execution of the "test-↓
┆19┆┆90┆┄┄master" selftest. if another <cntrl><S> is ↓
┆19┆┆90┆┄┄typed the program returns to the "test-↓
┆19┆┆90┆┄┄master" selftest again.↲
↲
<cntrl><G>╞ - ┆84┆Go command. If the test is halted it will ↓
┆19┆┆90┆┄┄continue.↲
↲
════════════════════════════════════════════════════════════════════════
↓
If any other character is typed the "test-master" responds ↓
with the following menu and waits for yet another character ↓
to continue.↲
↲
┆b0┆-------- CPU 6XX Selftest Menu -----------------------------↲
┆b0┆<esc>╞ ╞ : Change parameters↲
┆b0┆<cntrl><A>╞ : Enter Debug Monitor/Loader↲
┆b0┆┆b0┆<cntrl><S>╞ : Request Slave Debugging↲
┆b0┆<cntrl><G>╞ : Go command↲
┆b0┆↲
┆b0┆test no.:↲
┆b0┆0000n = test n (name)↲
┆b0┆0000? = test n-1 (name)↲
┆b0┆!↲
┆b0┆!↲
┆b0┆00000 = RAM test↲
↲
┆b0┆Selftest HALTED ! --- Select from menu↲
↲
↲
┆a1┆┆b0┆4.2.3 Change Parameters.↲
↲
When an operator enters <esc> while the "test-master" is ↓
still executing its own selftest program the following menu ↓
appears on the screen.↲
↲
┆b0┆┆b0┆============================== Selftest Parameter Menu↲
┆b0┆halt on error╞ ╞ ╞ ? <Y/N>, Y/↲
┆b0┆loop╞ ╞ ╞ ╞ ? <Y/N>, N/↲
┆b0┆boot after test╞ ╞ ? <Y/N>, N/↲
┆b0┆suppress status check╞ ? <Y/N>, N/↲
┆b0┆suppress data check╞ ? <Y/N>, N/↲
┆b0┆test no.:╞ 00000/↲
↲
════════════════════════════════════════════════════════════════════════
↓
The questions must be answered one by one. Valid answers to ↓
the "<Y/N>" questions are "Y", "N" or a carriage return. The ↓
answer to the test number question must be either a legal ↓
test number plus a carriage return or a carriage return ↓
only.↲
↲
↲
┆b0┆┆a1┆4.3 Automatic Configuration.↲
↲
When the "test-master" has finished its own selftest it will ↓
make a Multibus configuration. Every RC-manufactured SBC ↓
card is located with its Dual-Ported RAM ending on a 64 KB ↓
boundary address. When a RC 39 SBC starts the execution of ↓
its selftest program it immediately initializes the last ↓
word in its Dual-Ported RAM with a special pattern ↓
corresponding to "not-ready". When the test is terminated ↓
with or without an error the pattern is changed to "ready". ↓
Ready indicates to the "test-master" that the SBC is ready ↓
to communicate. Both the "not-ready" pattern and the "ready" ↓
pattern must of course be different from the pattern which ↓
is read by the "test-master" when reading from a Multibus ↓
address with non-existing RAM (bus acknowledge timeout ↓
assumed).↲
↲
The hardware configuration process is possible due to the ↓
fact that all the "test-slaves" communicates with the "test-↓
master" trough DP-RAM located to end on 64 K boundaries. ↓
This minimizes the configuration attempts to a maximum of 32 ↓
entries (controllers are placed between Multibus addresses ↓
800000-A00000 hexedecimal). During the configuration process ↓
the "test-master" starts reading from the top of the ↓
controller address space (address 9FFFFF hexadecimal). If a ↓
pattern equal to "not-ready" or "ready" is found the ↓
════════════════════════════════════════════════════════════════════════
↓
selftest assumes that an intelligent SBC card is present, ↓
and reads som further parameters such as card-type, RAM-size ↓
and selftest execution time in seconds. If the card is ↓
marked "not-ready" the "test-master" may use the selftest ↓
execution time to decide how long to wait for that card to ↓
become "ready". Also a handshake protocol is executed to ↓
reassure that the "ready" pattern was not read by random. ↓
From the knowledge to the RAM-size the "test-master" ↓
calculates the address where to continue the Multibus ↓
configuration. If no "ready" or "not-ready" pattern is ↓
received then the "test-master" configuration writes to and ↓
reads back from the RAM cell to find out if some RAM really ↓
exists on that Multibus address. The configuration program ↓
ends with writing a configuration schedule to the console. ↓
The schedule might look like this:↲
↲
╱0400274e0c0006000000000301473160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
╱0400274e0a00060000000003013c3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
↓
┆b0┆┆b0┆Multibus Configuration:↲
┆b0┆======================================================================↲
┆b0┆┆b0┆MB entry - MB address - Card State - Card ID - MB RAM size - error no.↲
┆b0┆======================================================================↲
┆b0┆00000╞ 000000╞ ╞ master╞ CPU 691 02048 00000↲
┆b0┆┆b0┆00001╞ 9E0000╞ ready╞ ITC 602 00064╞ ╞ 00000↲
┆b0┆00002 8E0000╞ ╞ ready╞ COM 601 00064 00000↲
┆b0┆00003 800000╞ ╞ ready ETC 611 00512 00000↲
╱0400274e0a00060000000003013c3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
╱0400274e0c0006000000000301473160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
↓
↲
The configuration data is stored in a specific data ↓
structure where it may be accessed by the system software.↲
↲
The bootload is not inhibited if a "test-slave" has found an ↓
error during its default selftest, but a message is written ↓
to the console. The reason for this is that an incremental ↓
part of the system may still be running, and this maybe ↓
sufficient for many users.↲
↲
════════════════════════════════════════════════════════════════════════
↓
There also exists the possibility that the "test-master" ↓
hands ower one configuration parameter to the "test-slaves", ↓
their Multibus address. This address parameter may then be ↓
passed along to the system software on the "test-slaves". ↓
This parameter may eliminate some static configuration, and ↓
is convenient in a message passing system where messages ↓
with pointers to other messages are transferred across the ↓
Multibus.↲
↲
If some "dead" Multibus memory is found during the ↓
configuration process it may be presented like this in the ↓
configuration schedule.↲
↲
╱0400274e0c0006000000000301473160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
╱0400274e0a00060000000003013c3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
↓
┆b0┆Multibus Configuration:↲
┆b0┆======================================================================↲
┆b0┆MB entry - MB address - Card State - Card ID - MB RAM size - error no.↲
┆b0┆======================================================================↲
┆b0┆00000 900000↲
╱0400274e0a00060000000003013c3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
╱0400274e0c0006000000000301473160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
↓
↲
Such a configuration result should be a warning about an SBC ↓
card that is totally "dead" or has no built in selftest.↲
↲
↲
┆b0┆┆a2┆┆e2┆┆a1┆4.4 Request Multibus Monitoring.↲
↲
When an operator enters <cntrl><S> while the "test-master" ↓
is still executing its own selftest program the following ↓
menu appears on the screen, when the CPU selftest terminates ↓
the Multibus configuration test.↲
↲
════════════════════════════════════════════════════════════════════════
↓
╱0400274e0c0006000000000301473160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
╱0400274e0a00060000000003013c3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
↓
┆b0┆Multibus Configuration:↲
┆b0┆======================================================================↲
┆b0┆┆b0┆MB entry - MB address - Card State - Card ID - MB RAM size - error no.↲
┆b0┆======================================================================↲
┆b0┆00000╞ 000000╞ ╞ master╞ CPU 691 02048 00000↲
┆b0┆┆b0┆00001╞ 9E0000╞ ready╞ ITC 602 00064╞ ╞ 00000↲
┆b0┆00002 8E0000╞ ╞ ready╞ COM 601 00064 00000↲
┆b0┆00003 800000╞ ╞ ready ETC 611 00512 00000↲
┆b0┆OK↲
╱0400274e0a00060000000003013c3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
╱0400274e0c0006000000000301473160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
↓
┆b0┆Selftest Complete: OK ********** Pass-counter = 00001↲
┆b0┆↲
┆b0┆-------- Multibus Monitoring Menu ----------------------↲
┆b0┆<esc>╞ ╞ : Change Parameters↲
┆b0┆<cntrl><S>╞ : Return to CPU 6XX Selftest↲
┆b0┆<cntrl><G>╞ : Go command↲
┆b0┆<cntrl><A>╞ : Enter Debug Monitor↲
↲
╱0400274e0c0006000000000301423160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
╱0400274e0a00060000000003013c3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
↓
┆b0┆<00001> LCP loopback test: Selftest Complete: *** Pass 00001 : OK↲
┆b0┆<00002> 8274 chA test: Selftest Complete: *** Pass 00001 : OK↲
┆b0┆<00003> RAM refresh test: Selftest Complete: *** Pass 00001 : OK↲
╱0400274e0a00060000000003013c3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
╱0400274e0c0006000000000301423160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
↓
↲
If en escape is entered the Multibus configuration is ↓
written again like this:↲
↲
╱0400274e0c0006000000000301473160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
╱0400274e0a00060000000003013c3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
↓
┆b0┆Multibus Configuration:↲
┆b0┆======================================================================↲
┆b0┆┆b0┆MB entry - MB address - Card State - Card ID - MB RAM size - error no.↲
┆b0┆======================================================================↲
┆b0┆00000╞ 000000╞ ╞ master╞ CPU 691 02048 00000↲
┆b0┆┆b0┆00001╞ 9E0000╞ ready╞ ITC 602 00064╞ ╞ 00000↲
┆b0┆00002 8E0000╞ ╞ ready╞ COM 601 00064 00000↲
┆b0┆00003 800000╞ ╞ ready ETC 611 00512 00000↲
↲
════════════════════════════════════════════════════════════════════════
↓
╱0400274e0a00060000000003013c3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
╱0400274e0c0006000000000301473160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
↓
┆b0┆SLAVE DEBUGGING -- Enter MB entry: 00000/↲
↲
The MB entry number question must be answered with either a ↓
valid entry number (see configuration table) plus a carriage ↓
return or with a carriage return only. If entry number 1 is ↓
selected the ITC 602 writes its selftest menu to the test ↓
master like this:↲
↲
┆b0┆---- ITC 602 SELFTEST MENU ----↲
┆b0┆test no.:↲
┆b0┆00009 = Line 3 test↲
┆b0┆00008 = Line 2 test↲
┆b0┆00007 = Line 1 test↲
┆b0┆00006 = LCP loopback test↲
┆b0┆00005 = LCP data test↲
┆b0┆00004 = PPI test↲
┆b0┆00003 = DMA test↲
┆b0┆00002 = iAPX 186 Timer test↲
┆b0┆00001 = CS test↲
┆b0┆00000 = RAM test↲
┆b0┆======================= Selftest Parameter Menu↲
┆b0┆halt on error╞ ╞ ╞ ? <Y/N>, Y/↲
┆b0┆loop╞ ╞ ╞ ╞ ? <Y/N>, N/↲
┆b0┆boot after test ╞ ╞ ? <Y/N>, N/↲
┆b0┆suppress status check╞ ? <Y/N>, N/↲
┆b0┆suppress data check╞ ? <Y/N>, N/↲
┆b0┆test no.: 00000/↲
↲
The questions must be answered one by one. Valid answers to ↓
the "<Y/N>" questions are "Y", "N" or a carriage return. The ↓
answer to the test number question must be either a legal ↓
test number plus a carriage return or a carriage return ↓
only. If the loop question is answered Y and test number 5 ↓
is selected then this happens:↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆<00001> LCP loopback test: *** Pass 00001 : OK↲
┆b0┆<00001> LCP loopback test: *** Pass 00002 : OK↲
┆b0┆<00001> LCP loopback test: *** Pass 00003 : OK↲
┆b0┆<00001> LCP loopback test: *** Pass 00004 : OK↲
┆b0┆<00001> LCP loopback test: *** Pass 00005 : OK↲
┆b0┆<00001> LCP loopback test: *** Pass 00006 : OK↲
┆b0┆<00001> LCP loopback test: *** Pass 00007 : OK↲
┆b0┆┆81┆↲
If you hit the space button now the menu is written to the ↓
console once again.↲
↲
┆b0┆-------- Multibus Monitoring Menu ----------------------↲
┆b0┆<esc>╞ ╞ : Change Parameters↲
┆b0┆<cntrl><S>╞ : Return to CPU 6XX Selftest↲
┆b0┆<cntrl><G>╞ : Go command↲
┆b0┆<cntrl><A>╞ : Enter Debug Monitor↲
↲
If you hit the escape button again you will get another ↓
chance to change "test-slave" parameters.↲
┆a1┆↲
╱0400274e0c0006000000000301473160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
╱0400274e0a00060000000003013c3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
↓
┆b0┆Multibus Configuration:↲
┆b0┆======================================================================↲
┆b0┆┆b0┆MB entry - MB address - Card State - Card ID - MB RAM size - error no.↲
┆b0┆======================================================================↲
┆b0┆00000╞ 000000╞ ╞ master╞ CPU 691 02048 00000↲
┆b0┆┆b0┆00001╞ 9E0000╞ ready╞ ITC 602 00064╞ ╞ 00000↲
┆b0┆00002 8E0000╞ ╞ ready╞ COM 601 00064 00000↲
┆b0┆00003 800000╞ ╞ ready ETC 611 00512 00000↲
↲
╱0400274e0a00060000000003013c3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
╱0400274e0c0006000000000301473160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
↓
┆b0┆SLAVE DEBUGGING -- Enter MB entry: 00000/↲
↲
┆b0┆┆f0┆I assume you select entry number 2 this time.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆---- COM 601 SELFTEST MENU ----↲
┆b0┆test no.:↲
┆b0┆┆b0┆00007 = 8273 chC test↲
┆b0┆00006 = 8274 chB test↲
┆b0┆00005 = 8274 chA test↲
┆b0┆00004 = DMA test↲
┆b0┆00003 = PIT test↲
┆b0┆00002 = PPI test↲
┆b0┆00001 = CS test↲
┆b0┆00000 = RAM test↲
┆b0┆======================= Selftest Parameter Menu↲
┆b0┆halt on error╞ ╞ ╞ ? <Y/N>, Y/↲
┆b0┆loop╞ ╞ ╞ ╞ ? <Y/N>, N/↲
┆b0┆boot after test ╞ ╞ ? <Y/N>, N/↲
┆b0┆suppress status check╞ ? <Y/N>, N/↲
┆b0┆suppress data check╞ ? <Y/N>, N/↲
┆b0┆test no.: 00000/↲
↲
If you select to loop in test no 4 this happens.↲
↲
┆b0┆<00001> LCP loopback test: *** Pass 00008 : OK↲
┆b0┆<00001> LCP loopback test: *** Pass 00009 : OK↲
┆b0┆┆81┆<00002> DMA test: *** Pass 00001 : OK↲
┆b0┆<00001> LCP loopback test: *** Pass 00010 : OK↲
┆b0┆<00001> LCP loopback test: *** Pass 00011 : OK↲
┆b0┆┆81┆<00002> DMA test: *** Pass 00002 : OK↲
↲
This pattern continues until an error is found or until the ↓
operator enters a command from the keyboard.↲
↲
The test slave will not be able to answer with it's test ↓
menu if it has discovered a checksum or a RAM error (error ↓
number 1 and 2). Theseerrors are considered to be on a very ↓
════════════════════════════════════════════════════════════════════════
↓
low level, where no RAM is used by the selftest. This also ↓
means that no STACK is used and thereby procedure calls ↓
disabeled.↲
↲
The "test-master" selftest terminates with sending all ↓
"test-slaves" to their bootload state. The "test-master" ↓
writes a message to the console for every "test-slave" that ↓
is sent to bootload.↲
↲
┆b0┆<00001> Sent to bootload↲
┆b0┆<00002> Sent to bootload↲
┆b0┆<00003> Sent to bootload↲
↲
┆b0┆RC 39 Monitor release 1.0↲
┆b0┆.↲
↲
When the selftest is complete the "test-master" enters its ↓
monitor/loader program. The monitor commands are documented ↓
in another manual and only a few commands are mentioned ↓
here. The "L" command is used to bootload the XENIX ↓
operating system and the syntax is like this:↲
↲
┆b0┆L(W/F)(G)(:string)↲
↲
All items in brackets are optional. The / should be ↓
translated to OR. W means Winchester and is default (not ↓
necessary). F means floppy. G means execute after loading. ↓
The string, if present, gives the name of the XENIX kernel ↓
to be loaded, default is /xenix. The monitor forces the ↓
string to lower case. This command loads the second stage of ↓
the bootload from track 0 on either winchester or floppy ↓
disk. The second stage boot "knows" the XENIX file system ↓
and loads and executes the kernel.↲
↲
Another usefull monitor command is the (H/?) command, which ↓
displays a menu with all possible monitor commands.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆5. THE "TEST-SLAVE"↲
↲
When the "test-master" has finished its own selftest, it ↓
will be able to monitor messages from the "test-slaves", and ↓
to influence these to i.e. loop in a specific test several ↓
times. This means, that the "test-master" acts as an ↓
intelligent monitor for a debugging procedure on the "test-↓
slaves". One disadvantage with this approach may be, that a ↓
great deal of the hardware (RAM and Multibus interface ↓
logic) definitely must work to carry this debugging ↓
technique out succesfully. An advantage may be that this ↓
method effectively checks the same Multibus logic.↲
↲
If however the RAM or Multibus arbitration logic fails, it ↓
will be natural to switch the test communication over to the ↓
on-board V.24 channel (test-output switch). Then a special ↓
seperately run test that exercises the Multibus interface ↓
logic may be started from the console. The dual test ↓
communication channel approach makes the RC 39 selftest a ↓
very flexible tool.↲
↲
The "test-slave" software will be installed on the ETC 611, ↓
the COM 601 and the ITC 602 cards. The structure of the ↓
"test-slave" selftest is shown on the next page.↲
════════════════════════════════════════════════════════════════════════
↓
╱0400274e0a00060000000002013d3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
╱0400274e0a00060000000003013c3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
↓
╞ ╞ ╞ ╞ ---------------------↲
╞ ╞ ╞ ╞ ! Power-on╞ ╞ !↲
╞ ╞ ╞ ╞ ---------------------↲
╞ ╞ ╞ ╞ ╞ ╞ !↲
╞ ╞ ╞ ╞ ---------------------↲
╞ ╞ ╞ ╞ ! Memory Test╞ !↲
╞ ╞ ╞ ╞ ! (ROM/RAM)╞ !↲
╞ ╞ ╞ ╞ ---------------------↲
╞ ╞ --------------------!↲
╞ ╞ ^╞ ╞ ---------------------↲
╞ ╞ ^╞ ╞ ! Test Administrator!↲
╞ ╞ ^╞ ╞ !╞ ╞ ╞ ╞ !↲
╞ ╞ ^╞ ╞ ! Select next test╞ !╞ ------------↲
╞ ╞ ^╞ ╞ !╞ ╞ ╞ ╞ !-------! Test 1 !↲
╞ ╞ ^╞ ╞ ! Write error/ok ╞ !╞ ------------↲
╞ ╞ ^╞ ╞ ! messages╞ ╞ !╞ ╞ !↲
╞ ╞ ^╞ ╞ !╞ ╞ ╞ ╞ !╞ ------------↲
╞ ╞ ^╞ ╞ ! Monitor Operator !-------! Test 2 !↲
╞ ╞ ^╞ ╞ ! entrys, and chan-╞ !╞ ------------↲
╞ ╞ ^╞ ╞ ! ge test mode.╞ !╞ ╞ !↲
╞ ╞ ^╞ ╞ !╞ ╞ ╞ ╞ !╞ ------------↲
╞ ╞ ^╞ ╞ ! Halt on error╞ !-------! Test n !↲
╞ ╞ ^╞ ╞ ! Loop in test╞ ╞ !╞ ------------↲
╞ ╞ ^╞ ╞ ! Burn in mode╞ ╞ !╞ ╞ !↲
╞ ╞ ^╞ ╞ ! Suppress data/╞ !╞ ╞ !↲
╞ ╞ ^╞ ╞ ! status check╞ ╞ !╞ ╞ !↲
╞ ╞ ^ !╞ ╞ ╞ ╞ !╞ ╞ !↲
╞ ╞ ^ ! Select Communica-╞ !╞ ╞ !↲
╞ ╞ ^╞ ╞ ! tion channel╞ ╞ !╞ ╞ !↲
╞ ╞ ^╞ ╞ ! (Multibus or on-╞ !╞ ╞ !↲
╞ ╞ ^ ! board console)╞ !╞ ╞ !↲
╞ ╞ ^╞ ╞ !╞ ╞ ╞ ╞ !╞ ╞ !↲
╞ ╞ ^ ╞ ╞ ! ┆b0┆Default Tests╞ ┆f0┆!╞ ╞ !↲
╞ ╞ ^╞ ╞ ! ┆b0┆Extended Tests╞ ┆f0┆!╞ ╞ !↲
╞ ╞ ^ ╞ ╞ ! ┆b0┆Seperate Tests╞ ┆f0┆!╞ ╞ !↲
╞ ╞ ^╞ ╞ ---------------------╞ !↲
╞ ╞ ^╞ ╞ ╞ ╞ ╞ ╞ ╞ ╞ !↲
╞ ╞ ^╞ ╞ ╞ ╞ ╞ ╞ ╞ ╞ !↲
╞ ╞ ^╞ ╞ ╞ ╞ !-----------------------!↲
╞ ╞ ^╞ no╞ ---------------------↲
╞ ╞ ^---------! End of Test ?╞ !↲
╞ ╞ ╞ ╞ !-------------------!↲
╞ ╞ ╞ ╞ ╞ ! yes↲
╞ ╞ ╞ ╞ ╞ ┆1f┆ !↲
╞ ╞ ╞ ╞ ---------------------↲
╞ ╞ ╞ ╞ ! BOOTLOAD !↲
╞ ╞ ╞ ╞ ---------------------↲
↲
↲
╱0400274e0a00060000000003013d3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
╱0400274e0a00060000000002013d3160000000000000000000000000000000000000000000000000050a0f14191e23282d32373c41464bff04╱
↓
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆5.1 Hardware Prerequisites.↲
↲
The selftest system assumes several things about the ↓
intelligent SBC hardware ("test-slaves").↲
↲
a) ┆84┆Every intelligent RC 39 SBC card communicates with the ↓
┆19┆┆83┆┄┄"test-master" through a Dual-Port RAM area. The DP-RAM ↓
┆19┆┆83┆┄┄Multibus address must be strapable, and it must be ↓
┆19┆┆83┆┄┄possible to locate the RAM to end at a 64K boundary. If ↓
┆19┆┆83┆┄┄the DP-RAM size is variable it should be possible for the ↓
┆19┆┆83┆┄┄selftest program to determine the size of the Dual-Ported ↓
┆19┆┆83┆┄┄RAM. Also if the on-board RAM size is variable it should ↓
┆19┆┆83┆┄┄be possible for the test program to determine the RAM ↓
┆19┆┆83┆┄┄size.↲
↲
b) ┆84┆Every intelligent RC 39 SBC card must be designed with an ↓
┆19┆┆83┆┄┄asynchronous V.24 interface to a tty-compatible console. ↲
↲
c) ┆84┆Every intelligent RC 39 SBC card must be equipped with a ↓
┆19┆┆83┆┄┄test-output switch. The logical level of the strap must be ↓
┆19┆┆83┆┄┄easily read by the selftest program. When this switch is ↓
┆19┆┆83┆┄┄strapped to logic "high" the selftest communicates with ↓
┆19┆┆83┆┄┄the "test-master" across the Multibus via DP-RAM. When the ↓
┆19┆┆83┆┄┄switch is strapped to logic "low" the selftest ↓
┆19┆┆83┆┄┄communicates with the on-board USART interface. One might ↓
┆19┆┆83┆┄┄say that this switch is unnescessary because the V.24 ↓
┆19┆┆83┆┄┄signal DSR (Data Set Ready) tells if a terminal is ↓
┆19┆┆83┆┄┄present. But, at least during the selftest development, it ↓
┆19┆┆83┆┄┄may be practical to run the test under the RC debugger ↓
┆19┆┆83┆┄┄which uses the same V.24 interface as a debug terminal.↲
↲
One exception to the things mentioned above is the COM 601 ↓
board, which is an old board designed without an asynchronous ↓
V.24 interface.↲
↲
════════════════════════════════════════════════════════════════════════
↓
It is strongly recommended that the hardware engineers do ↓
their SBC card design with maximum testability in mind. ↓
Especially a programmable loop-back facility as close to the ↓
edge connector as possible on serial communication channels ↓
is useful.↲
↲
↲
┆b0┆┆a1┆5.2 Interactive Selftest Stimulation.↲
↲
While the "test-slave" is executing its selftest it is ↓
sensitive to several commands entered either from the tty-↓
console connected to the on-board USART or from the "test-↓
master" console (test-output switch). These commands are ↓
primary issued by an operator who wants to inhibit the normal ↓
bootloading procedure and instead execute more selftest ↓
programs than are run in the default power-on situation. The ↓
situation where commands are entered from the "test-master" ↓
is described in chapter 4.4, whereas the other is described ↓
in the following chapters.↲
↲
↲
┆a1┆┆b0┆5.2.1 Baud Rate Determination.↲
↲
When a terminal is present (DSR activ) and the test-output ↓
switch is in V.24 position, then the selftest enters a Baud ↓
Rate determination mode.↲
↲
In this mode the USART is at first initialized to 9600 Baud, ↓
and * (stars) written to the console output. The selftest now ↓
awaits for the user to type 1 or 2 upper case U. If the ↓
connected console is operating at 9600, 4800 or 2400 Baud one ↓
upper case U is enough. If the connected console is operating ↓
at 1200, 600 or 300 Baud two upper case U must be typed. ↓
════════════════════════════════════════════════════════════════════════
↓
Other characters typed may easily cause the selftest to ↓
assume a wrong Baud Rate. The stars initially written to the ↓
console at 9600 Baud may be seen as stars, various other ↓
characters or not seen at all depending on the Baud Rate of ↓
the connected consol┆e1┆e┆a1┆┆e1┆. When the Baud Rate is determined the ↓
selftest is started.↲
↲
↲
┆b0┆┆a1┆5.2.2 Commands.↲
↲
The "test-master" is sensitive to the following commands.↲
↲
<esc>╞ ╞ - ┆84┆enables interactive change of test program ↓
┆19┆┆90┆┄┄flow and parameters ("test-slave" menu ↓
┆19┆┆90┆┄┄request).↲
↲
<cntrl><A>╞ - ┆84┆Interrupt into Debug Monitor/Loader program.↲
↲
<cntrl><G>╞ - ┆84┆Go command. If the test is halted it will ↓
┆19┆┆90┆┄┄continue.↲
↲
If any other character is typed the "test-slave" responds ↓
with the following menu and waits for yet another character ↓
to continue.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆-------- ITC 601 Selftest Menu ----------------------------↲
┆b0┆<esc>╞ ╞ : Change parameters↲
┆b0┆<cntrl><A>╞ : Enter Debug Monitor/Loader↲
┆b0┆┆b0┆<cntrl><G>╞ : Go command↲
┆b0┆↲
┆b0┆ITC 601 Included Tests:↲
┆b0┆0 = test 0 (name)↲
┆b0┆1 = test 1 (name)↲
┆b0┆!↲
┆b0┆!↲
┆b0┆n = test n (name↲
↲
┆b0┆Selftest HALTED ! -------- Select from menu↲
↲
↲
┆a1┆┆b0┆5.2.3 Change Parameters.↲
↲
When an operator enters <esc> while the "test-slave" is still ↓
executing its own selftest program the following menu appears ↓
on the screen.↲
↲
┆b0┆┆b0┆============================== Change Selftest Parameters↲
┆b0┆halt on error╞ ╞ ╞ ? <Y/N>, Y/↲
┆b0┆loop╞ ╞ ╞ ╞ ? <Y/N>, N/↲
┆b0┆boot after test╞ ╞ ? <Y/N>, N/↲
┆b0┆suppress status check╞ ? <Y/N>, N/↲
┆b0┆suppress data check╞ ? <Y/N>, N/↲
┆b0┆test no.: 0/↲
↲
The questions must be answered one by one. Valid answers to ↓
the "<Y/N>" questions are "Y", "N" or a carriage return. The ↓
answer to the test number question must be either a legal ↓
test number plus a carriage return or a carriage return only.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆6. SELFTEST ADMINISTRATOR PROGRAM↲
↲
In every RC 39 SBC selftest program is included a test ↓
administrator program, that administers the mode in which a ↓
particular test is run. The main purpose of the ↓
testadministrator is to calculate the address of the next ↓
test to be run, and to control communication with the tty-↓
terminal or the "test-master".↲
↲
The testadministrator is tied closely to a test configuration ↓
program and it is the intention to standardize the ↓
testadministrator program so that the same testadministrator ↓
program and configuration program can be used by all RC 39 ↓
SBC's in common. The test administration program ↓
"administers" three types of tests.↲
↲
a) Default tests╞ ╞ - ┆84┆The default test programs are run ↓
┆19┆┆9a┆┄┄in sequence after power on.↲
↲
b) Extended tests ╞ ╞ - ┆84┆The extended test programs may be ↓
┆19┆┆9a┆┄┄appended to the default set and ↓
┆19┆┆9a┆┄┄then run in sequence.↲
↲
c) Seperate tests╞ ╞ - ┆84┆A seperate test must be requested ↓
┆19┆┆9a┆┄┄explicit by an operator and cannot ↓
┆19┆┆9a┆┄┄be run in sequence with other ↓
┆19┆┆9a┆┄┄programs.↲
↲
The order in which the tests are run is strictly defined by ↓
the confi-guration program and cannot be altered by the ↓
operator. This is fair because many test in fact relies on ↓
hardware tested in an earlier test.↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆6.1 Test Parameters.↲
↲
The flow of the RC 39 SBC selftests are based upon the fact ↓
that each test program receives a set of parameters as input ↓
and delivers a buffer of error information as outputs.↲
↲
The parameters are contained in a 16 bit word variable, a ↓
socalled switch variable, which survives the memory test in ↓
an internal CPU register. This variable contains the ↓
information nescessary for the test administrator to manage ↓
the flow of the test program.↲
↲
┆a1┆name╞ initial value╞ ╞ ╞ ╞ comments╞ ╞ ╞ ↲
↲
halt bit╞ ╞ 1╞ ╞ ╞ 1: ┆84┆halts execution when an error ↓
┆19┆┆a0┆┄┄is dis-covered.↲
╞ ╞ ╞ ╞ ╞ ╞ 0: bypasses errors.↲
↲
loop bit╞ ╞ 0╞ ╞ ╞ 1: ┆84┆repeat the selection of the ↓
┆19┆┆a0┆┄┄test spe-cified.↲
╞ ╞ ╞ ╞ ╞ ╞ 0: sequential test flow.↲
↲
wait bit╞ ╞ 0╞ ╞ ╞ 1: ┆84┆slave wait flag. Internal use ↓
┆19┆┆a0┆┄┄only.↲
╞ ╞ ╞ ╞ ╞ ╞ 0: ┆84┆release slave. Internal use ↓
┆19┆┆a0┆┄┄only.↲
↲
burn in bit╞ 0╞ ╞ ╞ 1: ┆84┆burn in mode (default tests ↓
┆19┆┆a0┆┄┄plus ex-tended test in ↓
┆19┆┆a0┆┄┄sequence.↲
╞ ╞ ╞ ╞ ╞ ╞ 0: bootload after test.↲
↲
status bit 0 ╞ ╞ 1: suppress status check.↲
╞ ╞ ╞ ╞ ╞ ╞ 0: perform status check.↲
↲
════════════════════════════════════════════════════════════════════════
↓
data bit╞ ╞ 0╞ ╞ ╞ 1: suppress data check.↲
╞ ╞ ╞ ╞ ╞ ╞ 0: perform data check.↲
↲
reserved for internal use↲
↲
reserved for internal use↲
┆19┆┄┄┆84┆╞ ╞ ╞ ╞ ╞ ╞ ╞ ╞ ╞ ╞ ╞ ╞ ╞ ╞ -↲
┆a1┆test no. byte╞ 00╞ ╞ identification of test program ↲
════════════════════════════════════════════════════════════════════════
↓
┆b0┆┆a1┆7. TEST RESULTS↲
↲
The selftest execution results will generally be of the form.↲
↲
┆b0┆Test Name: <primary error text> <secondary error text>↲
↲
Primary error text is a litteral explanation of the reason of ↓
the error.↲
↲
Secondary error text is a detailed description of the data ↓
that made the test fail example = segm.: 0040, addr.: 12FB, ↓
exp.: 0000, rec.: 0001.↲
↲
Although this is the usual way to decode the outcome of a ↓
test nothing will inhibit special tests to violate the rule, ↓
and write longer messages i.e. configuration data via the ↓
communication buffer.↲
↲
════════════════════════════════════════════════════════════════════════
↓
┆a1┆┆b0┆8. REMOTE DIAGNOSTICS↲
↲
The V.24 interface on the "test-master", which usually is ↓
connected to a test output console, may instead be connected ↓
to a modem. The modem may then be switched to another modem ↓
at the RC Computer Technical Service Department where ↓
Technicians may run remote diagnostics on the RC 39 ↓
equipment.↲
↲
The remote diagnostic mode is selected when a special cable ↓
and modem is connected to the RC 39 diagnostic V.24 output. ↓
This cable forces the selftest to enter the baud-rate ↓
determination mode, and there will be no difference between ↓
remote or local diagnostics at all.↲
↲
The "test-slaves" may only be tested if their Multibus ↓
interface is functionable. But when RC knows the hardware ↓
configuration it will be possible to compare it with the ↓
Multibus configuration schedule in order to discover totally ↓
dead cards.↲
↲
It is not possible to connect a modem to the intelligent ↓
"test-slaves", because this would demand that the RC 39 ↓
cabinet be opened and the "test-output" redirected.↲
↲
The procedure for remote diagnostics will be like this:↲
↲
1.╞ ┆84┆The operator at the remote destination connects the modem ↓
┆19┆┆84┆┄┄with the modified cable to the RC 39 computer.↲
↲
2.╞ ┆84┆The RC 39 computer is reset or powered up. Now the RC 39 ↓
┆19┆┆84┆┄┄computer, if running, is in the baud rate determination ↓
┆19┆┆84┆┄┄mode.↲
↲
════════════════════════════════════════════════════════════════════════
↓
3.╞ ┆84┆┆84┆The remote operator calls the RC Tecnical Service ↓
┆19┆┆84┆┄┄Department to get the telefone number of the RC ↓
┆19┆┆84┆┄┄diagnostic terminal.↲
↲
4.╞ ┆84┆The remote operator dials the RC diagnostic terminal and ↓
┆19┆┆84┆┄┄switches the modem to DATA.↲
↲
Now the RC Technician must enter 1 or 2 upper case U to make ↓
the RC 39 computer determine the baud rate. There may be a ↓
problem with noise on the line in the baud rate determination ↓
phase ?↲
↲
The diagnostic line might evt. get enabeled to run XENIX. ↓
This means that the remote operator may boot XENIX, enter ↓
single user mode, execute file system consistency check ↓
commands or special reliability programs running under XENIX ↓
and finally go multi user and watch the computer running.↲
↲
The modification that has to be done the modem cable is like ↓
this:↲
↲
-; DTR ->---- n.c ╞ n.c╞ -------->- -; DTR↲
╞ ╞ !╞ ╞ ╞ ╞ !↲
╞ ╞ !╞ ╞ ╞ ╞ !↲
-; CTS -<---- n.c╞ n.c╞ --------<- -; CTS↲
╞ ╞ !↲
╞ ╞ !↲
-; DSR -<---- n.c↲
↲
↲
RC 39 --------------- KABLE ------------- Modem↲
┆1a┆┆1a┆a check.↲
↲
ral ↓
bootloading procedure and instead execute more selftest ↓
programs