top - download
⟦0a8dde36b⟧ Wang Wps File
Length: 26990 (0x696e)
Types: Wang Wps File
Notes: CPS/SDS/001
Names: »1384A «
Derivation
└─⟦b58ce20e9⟧ Bits:30006060 8" Wang WCS floppy, CR 0092A
└─ ⟦this⟧ »1384A «
WangText
…02…CPS/SDS/001
…02…HKI/811020…02……02…
CAMPS SYSTEM DESIGN SPECIFICATION
…02…ISSUE 1.1…02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
5.19 SUPPORT SOFTWARE PACKAGE ................
704
5.19.1 Summary of Requirements .............
704
5.19.1.1 Package Description .............
704
5.19.1.2 Package Functions ...............
704
5.19.1.2.1 Software Development and
Test Functions ..............
704
5.19.1.2.2 Software System Support .....
713
5.19.1.2.3 Diagnostics Software ........
720
5.19.1.3 Package Control .................
725
5.19.1.4 Characteristics .................
725
5.19.1.5 Design and Construction .........
725
5.19.1.6 Documentation ...................
725
5.19.2 Environment .........................
726
5.19.2.1 Standard Hardware, Firmware
and Software ....................
726
5.19.2.3 Package Interfaces ..............
726
5.19 S̲U̲P̲P̲O̲R̲T̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲ ̲P̲A̲C̲K̲A̲G̲E̲
5.19.1 S̲u̲m̲m̲a̲r̲y̲ ̲o̲f̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
5.19.1.1 P̲a̲c̲k̲a̲g̲e̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The support software is such CR80D general software
that is independent of the actual use of the CR80D
(CAMPS), but used for software development, test and
diagnostics and used for diagnostics of hardware.
The support software may be grouped in three:
Software Development and Test
Software System Support
Hardware Diagnostic Software
Figure 5.19.1.1-1 presents the breakdown.
5.19.1.2 P̲a̲c̲k̲a̲g̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
5.19.1.2.1 S̲o̲f̲t̲w̲a̲r̲e̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲a̲n̲d̲ ̲T̲e̲s̲t̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
Software Development and Test is performed supported
by:
Language Processors
Text Processors
Development and Test Tools,
and controlled supported by
Librarian tools.
An overview is presented in figure 5.19.1.2.1-1.
T̲h̲e̲ ̲L̲a̲n̲g̲u̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲o̲r̲s̲ ̲a̲r̲e̲:
Pascal Compiler, Swell Compiler and the Assembler.
The Pascal Compiler generates loadable code for
execution by the Pascal runtime system. It allows
inclusion of a standard Prefix with Pascal interfaces
to low level machine functions.
Figure 5.19.1.1.-1…01…Support Software Structure
Figure 5.19.1.2.1-1…01…Support Software…01…Software Development and Test
The Swell Compiler generates linkable modules from
source. By use of Swell Linker and system generation
facilities, loadable system and application software
may be generated.
The Assembler generates executeable code from source.
T̲h̲e̲ ̲t̲e̲x̲t̲ ̲p̲r̲o̲c̲e̲s̲s̲o̲r̲s̲ ̲a̲r̲e̲:
Editor, General text formatter, Text file merge program.
E̲d̲i̲t̲o̲r̲
The Editor is an interactive program which reads
commands from current input and displays messages
and verifications on current output.
The Editor is line-oriented; all commands concern
one or more lines. The Editor keeps track of a
current line position.
Line numbers are denoted by means of:
- a numeric value
- a text string, which is part of the line
- a symbol ( . means current line; # means last
line)
- one of the above +/- a displacement
Below is given a short list of commands to the
Editor.
Functions supported are:
- Append text after line (text follows)
- Change line
- Delete line(s) with pattern
- Enter file, discard all previous text
- Insert text before line (text follows)
- Copy line(s) to after current
- Loop
- Move line(s) to after current
- Display line(s)
- Quit
- Read file, appending after line
- Substitute pattern2 for first occurrence of
pattern1 in each line. (G implies all occurrences)
(P implies, display or result)
- Write line(s) into file
- Split line before pattern (D implies deletion
of second line)
G̲e̲n̲e̲r̲a̲l̲ ̲T̲e̲x̲t̲ ̲F̲o̲r̲m̲a̲t̲t̲e̲r̲
The Formatter transforms an input file with inbedded
commands to an output file.
The formatting consists of:
- Margin justification
- Underlining key words
- Addition of page headings
F̲i̲l̲e̲ ̲M̲e̲r̲g̲e̲ ̲P̲r̲o̲g̲r̲a̲m̲
The program merges text files together onto an
output file.
The input file may contain commands to the merge
program. A command is a dollar sign ($, <, ASCII
36) followed by a file-id.
The input file is copied onto the output file until
a command (or end of file) is reached.
If a command is encountered, the command itself
and the rest of that line is skipped and the specified
file is merged to the output file. (The specified
file is, in turn, scanned for commands where new
files can be merged. This process may continue
to a maximum level of 10).
When the specified file is merged the copying is
resumed, and continued until another command (or
end of file) is reached.
D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲a̲n̲d̲ ̲T̲e̲s̲t̲ ̲T̲o̲o̲l̲s̲.
Development and Test Tools are:
Linker,
Debugger,
Test Monitor,
System Generator.
L̲i̲n̲k̲e̲r̲
The Linker generates an object module from one
or more compiled Swell modules.
The modules for link are specified as files, the
Linker makes the final resolution of addresses
and references.
It is possible to specify to the Linker that a
module or a group of modules shall start on a specified
address (i.e. page) in the logical address space
facilitating generation of share procedures. Refer
fig. 5.19.1.2.1-2.
D̲e̲b̲u̲g̲g̲e̲r̲
The Debugger exist in two versions.
Swell Debugger, and
General Debugger
The Swell Debugger operates with symbolic names
whereas the General Debugger operates on relative
program addresses.
Both facilitate:
Insertion, removal and listing of breakpoints
Listing of current values of variables
(i.e. by Symbolic name/by process data offset)
Assigning new values to variables
Access to registers
Further both may create or remove synchronization
elements in the basic DAMOS synchronization mechanism.
The debuggers may be operated interactively or
from another process (test driver).
T̲e̲s̲t̲ ̲M̲o̲n̲i̲t̲o̲r̲
The general Test Monitor (refer also section 4.5.4)
controls execution of test drivers - so called
TESTERS.
Figure 5.19.1.2.1-2…01…Linker…01…Shared Procedures
The Test Monitor is started from TOS interactively
(for TOS see 5.19.1.2.2).
First step is to specify the test.
After the test has been specified the user has
the capability to either interactively execute
steps of each TESTER, interactively execute predefined
sequences or activate the test as a whole.
The test definition is a high level definition
of the order of execution of sequences.
Automatic executeable commands are:
LOAD Definition of a TESTER
START Definition of a TESTER
STOP Definition of a TESTER
REMOVE Definition of a TESTER
INITIATE Definition of sequence. Sequence
is initiated
PERFORM Sequence is initiated and termination
awaited
AWAIT Sequence. Await completion of sequence
HALT With no parameter whole of test
HALT With parameter sequence. Halt sequence
after completion of current step
RESTART As for HALT
Sequences define steps in execution for a single tester.
Sequences may be synchronized.
DEF TESTER. The tester to which the sequence
applies
EXECUTE i Execute step i
EXECUTE i, j Execute step i through j
EXECUTE Execute all steps
SIGNAL SEQ. Signal to another sequence
WAIT SEQ. Wait for signal from other sequence
DELAY N Delay N seconds
OPERATOR Wait for operator giving continue
The execution of test is logged step by step.
S̲y̲s̲t̲e̲m̲ ̲G̲e̲n̲e̲r̲a̲t̲o̲r̲
The system generator is a program which reads its
commands from current input and outputs messages
on current output. The program creates a system
load module from a number of individual program
modules. The system module is output to the output
file, which must be specified and exist before
program invocation.
L̲i̲b̲r̲a̲r̲i̲a̲n̲
The Librarian organizes all information pertinent to
systems development and as such it covers the areas
of program development, systems generation and documentation.
It acts as an umbrella over the following development
utilities:
1) Editor
2) Assembler
3) SWELL compiler
4) PASCAL compiler
5) Linker
6) Systems generator
directing and recording their activities.
Programs
- It allows two levels of issue numbering and version
number within latest issue. Attach date of latest
change.
- It recognizes the various disguises of the program
as source module, link module, loadable module.
Systems
Systems are built up of programs, and the librarian
includes tools to describe how systems are structured
and which programs in which versions they consist of.
The description is hierarchical and allows a number
of levels such as SYSTEM, SUBSYSTEM, PACKAGE, MODULE.
This description directs systems generation. Systems
have a two level version number.
Installations
Installations run systems. The librarian includes tools
to describe the history of each installation in terms
of the systems running at the installation. A patch
history record for each installation is maintained
too.
Documents
Documentation key with reference to the systems covered
by the document and a description of document state.
Test data sets
Data sets to be used for mandatory tests of new versions
of programs and systems. Each data set must contain
a reference to the system which will use the set.
Cross Reference Tool
Given a program name and a version identification (either
a specific version or all versions) together with a
set of systems/installation the cross reference tool
identifies all programs/systems/installation where
from the program is called/wherein the program is incorporated.
5.19.1.2.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲y̲s̲t̲e̲m̲ ̲S̲u̲p̲p̲o̲r̲t̲
The Software System Support functions are:
File Manipulation Programs
Directory Maintenance Programs
High Level Operating Systems
Disk Manipulation
An overview is presented in figure 5.19.1.2.2-1.
Figure 5.19.1.2.2-1…01…Support Software…01…Software System Support
F̲i̲l̲e̲ ̲M̲a̲n̲i̲p̲u̲l̲a̲t̲i̲o̲n̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
The CR80D File Manipulation Programs include:
- A file copy program
- A file display program
- A file compare program
- File conversion programs
F̲i̲l̲e̲ ̲C̲o̲p̲y̲ ̲P̲r̲o̲g̲r̲a̲m̲
The program makes a data transparent copy of the
input file into the output file.
F̲i̲l̲e̲ ̲D̲i̲s̲p̲l̲a̲y̲ ̲P̲r̲o̲g̲r̲a̲m̲
The program displays the contents of the file one
page at a time.
F̲i̲l̲e̲ ̲C̲o̲m̲p̲a̲r̲i̲s̲o̲n̲ ̲P̲r̲o̲g̲r̲a̲m̲
The program compares two files for equality. The
result is output on the current output file.
F̲i̲l̲e̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
The file conversion programs are used to change
the format and/or representation of a file.
B̲i̲n̲a̲r̲y̲ ̲t̲o̲ ̲H̲e̲x̲a̲d̲e̲c̲i̲m̲a̲l̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲ ̲P̲r̲o̲g̲r̲a̲m̲
The program BINHEX converts a binary input file
into a hexadecimal output file.
From the input file is read 16 bit words which
are converted to four digit hexadecimal numbers
and written onto the output file. The conversion
continues until the input file is exhausted.
H̲e̲x̲a̲d̲e̲c̲i̲m̲a̲l̲ ̲t̲o̲ ̲B̲i̲n̲a̲r̲y̲ ̲C̲o̲n̲v̲e̲r̲s̲i̲o̲n̲ ̲P̲r̲o̲g̲r̲a̲m̲
The program HEXBIN converts a hexadecimal input
file into a binary object file.
D̲i̲r̲e̲c̲t̲o̲r̲y̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲
The CR80D directory maintenance utility programs are
a suite of programs for inspecting and modifying the
contents of backing store file structures.
Programs for the following directory operations are
available:
- Create a file
- Delete a file
- Rename a file
- Enter an existing file into a directory
- List the contents of a directory
- List the attributes of a file
- Change the protection of a file
F̲i̲l̲e̲ ̲C̲r̲e̲a̲t̲i̲o̲n̲ ̲P̲r̲o̲g̲r̲a̲m̲
Creates a new file on the volume specified and
enters the file with the name specified in the
directory identified. The directory must be an
existing file. If the directory is not specified
current directory is used.
The organization of the file is stated as well.
If the organization of the file is DIRECTORY or
RANDOM, the area size of the file extension is
specified in sectors, else the number of sectors
to be allocated is specified.
F̲i̲l̲e̲ ̲D̲e̲l̲e̲t̲i̲o̲n̲ ̲P̲r̲o̲g̲r̲a̲m̲
The program REMOVE clears the entry with the specified
file name in the directory specified. If the directory
is not specified current directory will be used.
F̲i̲l̲e̲ ̲R̲e̲n̲a̲m̲i̲n̲g̲ ̲P̲r̲o̲g̲r̲a̲m̲
The program RENAME clears the entry with the old
file name in the directory specified. An entry
with the new file name is inserted instead. If
directory is not specified, current directory will
be used.
F̲i̲l̲e̲ ̲I̲n̲c̲l̲u̲d̲e̲ ̲P̲r̲o̲g̲r̲a̲m̲
Creates a new entry in a directory, which maps
the file name into a reference to the file in question.
If a directory is not specified current directory
will be used. The directory must be an existing
file.
…02… D̲i̲r̲e̲c̲t̲o̲r̲y̲ ̲L̲i̲s̲t̲ ̲P̲r̲o̲g̲r̲a̲m̲
…02… The program list lists the directory entries for all
files entered in the directory stated as parameter.
For each entry is listed:
…02… Name
…02… Type
…02… Size in bytes
…02… Number of allocated areas
…02… Area size
If a directory is not specified the current directory
will be used as default.
F̲i̲l̲e̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲ ̲D̲i̲s̲p̲l̲a̲y̲ ̲P̲r̲o̲g̲r̲a̲m̲
The program ATTR lists the directory entry of the
file specified as parameter. In addition to the
attributes obtained using the LIST utility program
this program will also provide information on the
processes having access to the file and their access
rights.
F̲i̲l̲e̲ ̲P̲r̲o̲t̲e̲c̲t̲ ̲P̲r̲o̲g̲r̲a̲m̲
The specified process is allowed to access the
file as defined by the access types stated. The
access rights of the calling user must include
the right to protect the file.
H̲i̲g̲h̲ ̲L̲e̲v̲e̲l̲ ̲O̲p̲e̲r̲a̲t̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲
The CR80D standard high level operating system (TOS)
is an operating system for use in a software development
environment.
T̲e̲r̲m̲i̲n̲a̲l̲ ̲O̲p̲e̲r̲a̲t̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲ ̲(̲T̲O̲S̲)̲
TOS is an operating system which supports interactive
terminal users in a program development environment.
The functions performed by TOS are invoked by two
types of requests:
O̲p̲e̲r̲a̲t̲o̲r̲ ̲c̲o̲m̲m̲a̲n̲d̲s̲, which are messages typed at
terminals and sent to TOS. The functions which
may be performed in response to these requests
are:
Assign/deassign disk devices
Mount/dismount volumes on disk drives
Include terminals in the system/remove terminals
from the system
Log on to the system
Remove processes from the system
Broadcast messages to terminals
Manipulate a "news" message facility
Present status information
Run a task
Close the system
P̲r̲o̲g̲r̲a̲m̲m̲e̲d̲ ̲r̲e̲q̲u̲e̲s̲t̲s̲ are sent from processes to
TOS. The functions which may be performed in response
to these requests are:
Allocate resources (memory) for a task, load a
program, and create a process to execute the program
Start a process
Stop a process
Restart a process
Logout from the system
Reserve a print queue file
Release a print queue file
Start a printer task
TOS operates in two phases: A system initialization
phase where parameters like the identity of the system
disk may be (re)defined - and a production phase where
users may log on to the system and have tasks executed.
When a user logs on to the system, a Command Interpreter
process is created to handle his commands.
C̲o̲m̲m̲a̲n̲d̲ ̲I̲n̲t̲e̲r̲p̲r̲e̲t̲e̲r̲ ̲(̲C̲M̲I̲)̲
The CMI reads input lines from the current input file
and scans the line for commands.
When a non-recognized command is found it is assumed
to be a filename for a program to be loaded and the
remaining portion of the command line is assumed to
be parameters to be passed on to that program. The
file is looked up, and if found, a request is sent
to the TOS for loading the program and for creating
and starting a process to execute the program. This
process is hereafter referred to as a t̲a̲s̲k̲.
If the program file cannot be found, the remaining
portion of the line is skipped.
The CMI will repeatedly process command lines as long
as it has no active tasks. When one or more tasks are
active, the CMI stops processing command lines unless
an attention is sent to it (by pressing the break key
of a terminal and typing the name of the CMI process).
When an attention signal is received by the CMI, the
CMI will read and process one more command line.
The reading and processing of command lines is resumed
when the last active task invoked by the CMI terminates.
D̲i̲s̲k̲ ̲M̲a̲n̲i̲p̲u̲l̲a̲t̲i̲o̲n̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
D̲i̲s̲k̲ ̲I̲n̲i̲t̲i̲a̲l̲i̲z̲a̲t̲i̲o̲n̲
The functions performed by the disk initialization
program make a disk suitable for storage of information
under the regime of the CR80D File Management System.
The program will format the specified volume according
to parameters and handle bad sectors. An initial "empty"
file structure will be created.
D̲i̲s̲k̲ ̲S̲a̲l̲v̲a̲t̲i̲o̲n̲ ̲P̲r̲o̲g̲r̲a̲m̲
For a file structured volume the disk salvation program
is able to check the readability and validity and to
rebuild the external file system data structures. The
program also provides the ability to list all entries
in the basic file directory and other directories on
the volume.
When started SALV reads commands from current input
and writes messages on current output.
5.19.1.2.3 D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The off-line Maintenance and Diagnostic (M&D) package
is a collection of standard test programs which is
used to verify proper operation of the CR80D system
and to detect and isolate faults to replaceable modules.
The off-line M&D software package contains the following
programs.
CPU CACHE Test Program
Memory Map Test Program
RAM Test Program
CIA Test Program
LTU Test Program
Disk System Test Program
TDX-HOST I/F Test Program
C̲P̲U̲ ̲C̲A̲C̲H̲E̲ ̲T̲e̲s̲t̲ ̲P̲r̲o̲g̲r̲a̲m̲
The Central Processing Unit is tested as a CPU without
CACHE.
CPU test:
The Central Processing Unit Test Program tests proper
operation of a CPU with a standard CR80D instruction
set. The control logic of the CPU is tested by the
special test instruction and by verification of all
possible instructions in the instruction set, except
for some very few I/O instructions. The different addressing
schemes are tested for each instruction.
Execution in user and system mode is tried to test
mode switch and privileged instructions. Memory protect
and page fault are tested if a memory MAP module is
available. The single step facility is tested.
All registers, data busses, arithmetic circuits, and
data transfer ways are tested by the program.
CACHE test:
The CACHE is tested by special test instructions (microprogrammed
built in test routine), by checking the CACHE status
registers, and by automatic time measurement during
execution of program parts with high and low hit rate,
using fast timer interrupt.
M̲e̲m̲o̲r̲y̲ ̲M̲A̲P̲ ̲T̲e̲s̲t̲ ̲P̲r̲o̲g̲r̲a̲m̲
The Memory MAP Test Program verifies proper operation
of the memory MAP - and the MAP Interface Adaptor -
(MIA) module.
The control logic of the MAP is tested by activation
of the Built In Test (BIT) routine, and by verification
of the specified function.
The test contains the following subtests:
M̲e̲m̲o̲r̲y̲ ̲M̲A̲P̲ ̲S̲u̲b̲t̲e̲s̲t̲
The MAP function is tested by change of the segment
registers and segment tables such that all 64 segment
tables are tested. Memory absent and protect are
also tested in this subtest.
D̲M̲A̲ ̲S̲u̲b̲t̲e̲s̲t̲
Memory to memory DMA transfers are checked in this
subtest.
I̲n̲t̲e̲r̲r̲u̲p̲t̲ ̲S̲u̲b̲t̲e̲s̲t̲
Write and read in the RAM memory associated with
interrupt handling are tested (interrupt vectors,
CPU pool, and CPU priority). Interrupt on different
levels (from MAP-DMA) is tested.
V̲2̲4̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲P̲o̲r̲t̲
The communication port is tested by output and
input of a special test pattern.
This subtest requires manual input and visual inspection
by the operator at the console.
R̲A̲M̲ ̲T̲e̲s̲t̲ ̲P̲r̲o̲g̲r̲a̲m̲
The Random Access Memory Test Program verifies proper
operation of RAM memory modules.
The RAM test program is capable of testing all RAM
modules in a CR80D System, both in the PU's and on
the I/O channel.
The following elements are tested: Main Bus interface,
RAM internal addressing circuitry and storage circuitry.
The test contains the following subtests:
a) C̲h̲e̲c̲k̲e̲r̲ ̲B̲o̲a̲r̲d̲ ̲P̲a̲t̲t̲e̲r̲n̲ ̲T̲e̲s̲t̲
A checkboard pattern (hex 5555, AAAA, 5555, AAAA,
....) is generated and stored in the RAM module
under test. Verification of the stored pattern
is performed.
b) The possibility of changing single bits independently
is tested by setting and clearing each bit in any
storage location while keeping remaining bits in
the location cleared, i.e. the hexadecimal patterns
0001, 0002, 0004, ...., 8000 are stored and verified
in all locations, one location at a time.
c) The internal RAM addressing circuitry (word address
mode) is tested by storing the internal address
of each RAM location in the location and subsequently
verifying the simultaneous presence of all relevant
address combinations. I. e. for a 64K word RAM,
the following pattern is generated stored and verified:
hex 0000, 0001, 0002, 0003, ...., FFFE, FFFF.
d) The byte address mode is tested by storing and
reading bytewise in all locations of the RAM module
under test.
e) Long term stability (refresh) is tested by storing
a pattern and verifying the pattern after 1 sec.
f) Move multiple. The lower half of the RAM section
under test is filled with a checker-board pattern
and then tranferred to the remaining portion of
the RAM by using the MOVM machine instruction.
C̲I̲A̲ ̲T̲e̲s̲t̲ ̲P̲r̲o̲g̲r̲a̲m̲
The CIA test program verifies proper operation of an
I/O crate interface module and the connected I/O bus.
The test program is able to test either a CIAA or a
CIAB version of the module. The CIAA module interfaces
an I/O channel and an I/O bus A. The CIAB module interfaces
an IO channel and an I/O bus B.
The test of a CIA module and its I/O bus is performed
implicitly by verification of proper operation of all
or some of the I/O modules connected to the I/O bus
under test.
Failures common to such I/O modules are interpreted
as a CIA module and/or an I/O bus fault.
L̲T̲U̲ ̲T̲e̲s̲t̲ ̲P̲r̲o̲g̲r̲a̲m̲
The LTU test program verifies proper operation of the
Line Terminating Unit, LTU CR8066D.
The LTU test includes test of all command instructions,
interrupt control, DMA control, RAM's, PROM, the serial
interface part, and the Z80-processor.
The test of the Z80-processor parts of the LTU module
is performed by transmitting a Z80-program to the shared
RAM. The Z80-processor is commanded to execute this
program as a self test. The Z80-program stores a test
result code in the shared RAM. Test result code is
interpreted by the LTU test program in the CR80D processor
and a test response is produced.
D̲i̲s̲k̲ ̲S̲y̲s̲t̲e̲m̲ ̲T̲e̲s̲t̲ ̲P̲r̲o̲g̲r̲a̲m̲
The Disk System Test Program verifies proper operation
of the Disk System:
Disk Controller and RAM, Disk Controller Adaptor, and
Disk Drive.
The test is based on prerecorded data and special "work
track" on a reserved disk area. The complete Disk System
test requires mounting of a special test disk pack
and manipulation of the write protect switch on the
disk drive by the operator.
The program includes facility for generating and writing
of test pattern for later use in tests.
The following elements are tested:
I/O bus interface, Disk Addressing, RAM Addressing,
Cyclic Redundancy Code (CRC) Generator and Checker,
Interrupt Circuit, Unit Selection (where possible),
Write Protect, Bad Marking and all Specified Commands
and Status Codes.
The test contains the following subtest:
V̲e̲r̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲T̲e̲s̲t̲ ̲P̲a̲t̲t̲e̲r̲n̲ ̲D̲i̲r̲e̲c̲t̲o̲r̲y̲
The test pattern directory is inspected and checked
to ensure that the patterns which are necessary
for the following subtests are available.
D̲a̲t̲a̲ ̲P̲a̲t̲t̲e̲r̲n̲ ̲R̲e̲a̲d̲
A set of different data patterns are read from
the disk and checked to ensure proper function
of disk and RAM addressing, data transfers, CRC
code checker, status word and interrupt. Seek time
and data transfer rate are controlled in this subtest.
D̲a̲t̲a̲ ̲P̲a̲t̲t̲e̲r̲n̲ ̲W̲r̲i̲t̲e̲ ̲a̲n̲d̲ ̲F̲o̲r̲m̲a̲t̲
A set of different data patterns are written and
checked. Track and sector format are checked. This
subtest uses tracks reserved specially for this
purpose to protect other data patterns.
The RAM memory on the controller board is part of the
CR80D bulk memory and may be tested separately by the
RAM test program.
T̲D̲X̲-̲H̲O̲S̲T̲ ̲I̲/̲F̲ ̲T̲e̲s̲t̲ ̲P̲r̲o̲g̲r̲a̲m̲
The TDX-HOST I/F Test Program verifies proper operation
of a TDX-HOST I/F module. The program performs the
test by establishing a communication channel loop defined
by the TDX-HOST I/F, the TDX-Cable and the TDX-controller.
The TDX-HOST module will in this way operate as both
a transmitting and a receiving module. Data frames
(TDX frames) are sent through the established communication
channel and test responses are produced as results
of comparisons of sent and received data frames.
5.19.1.3 P̲a̲c̲k̲a̲g̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
The Support Software is controlled from the Watchdog
console. Except for special low level test programs
(e.g. MAP test) they are governed by the TOS operating
system.
The Support Software is loaded from either floppy disk
or main disk.
5.19.1.4 C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲
There is no specific requirement to the Support Software
except for offline diagnostics, where details are TBD.
5.19.1.5 D̲e̲s̲i̲g̲n̲ ̲a̲n̲d̲ ̲C̲o̲n̲s̲t̲r̲u̲c̲t̲i̲o̲n̲
Refer section 2.5.
5.19.1.6 D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
Refer section 2.6.
5.19.2 E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲
5.19.2.1 S̲t̲a̲n̲d̲a̲r̲d̲ ̲H̲a̲r̲d̲w̲a̲r̲e̲,̲ ̲F̲i̲r̲m̲w̲a̲r̲e̲ ̲a̲n̲d̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
N.A.
5.19.2.3 P̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
As standard software for CR80D the Support Software
has no defined interface to other packages.
