Digital PDFs

MISC-68409AEF

January 1983

64 pages

Original

8.7MB

Document:	Software Specification for KA630-A Console Program
Order Number:	MISC-68409AEF
Revision:
Pages:	64
Original Filename:

OCR Text

DATE: 31 January 19
SOFTWARE SPECIFICATION
for

KA630-A CONSOLE PROGRAM
REVISION 2.2
Written By:

A. Randall Heap

Issued By:

A. Randall Heap

Reviewed By:

Jesse Lipcon

ML05-5/E71

Jay Nichols

ML05-5/E71

Kathy Morse

ZK01-l/D42

COM PAN Y

ML05-5/E71

CON F IDE N T I A L

DATE: 31 January 19E
SOFTWARE SPECIFICATION
for
KA630-A CONSOLE PROGRAM
REVISION 2.2
ML05-5/E71

Written By:

A. Randall Heap

Issued By:

A. Randall Heap

Reviewed By:

Jesse Lipcon

ML05-5/E71

Jay Nichols

ML05-5/E71

Kathy Morse

ZK01-l/D42

COM PAN Y

CON F IDE N T I A L

Digital Equipment'Corporation - Software Specification

PREFACE
This is a Software Product Specification.
It is the definit~~
description in measurable terms of the goals, capabilities, and exter~a
characteristics of the KA630 console program.
It is the commitment ~
WHAT IS TO BE BUILT as agreed by the Product Team.
No changes are to be made to the product as described here,
approved and documented as an amendment to this Specification.

unles

Associated Documents:
1.

The KA630 Processor Specification which describes the process~
board of which this software product (in ROM) is a component.

The KA630 System Development Plan, which
describes
development project to design, build, test, evaluate,
deliver this product.

c.._

The KA630 ROM Diagnostic Specification which describes the
based diagnostics which are part of this program.

DEC Standard 32, the VAX Architecture Standard, which
includes the definition of the VAX console system (13-Sep-82 -,
Rev 3) .

The VIDEO SYSTEM STANDARDS Reference Manual which
video terminal architecture for DEC terminals.

DEC Standard 138, "Registry of Control Functions for
Imaging Devices".

RC:

defines
Charac~e

Change History:
Date:

25-July-1983

Revision 1.0
Date:

Original KA630 phase zero version.

22-February-1984

Revision 1.15

Revisions for phase 1
VMB details and figures defined according to "MicroVAX : :
CPU Technical Description", second draft, October 1983
This revision brings the specification up to phase
status.
All subsequent revisions will be tracked bchange bars in the left margin.

Revision 1.16

Revisions for phase 1 - continued
Spelling corrections, deleted vestigial
ii

text

fragmen~~

Digital Equipment Corporation - Software

Specifica~~:

remaining from previous versions, a correct.ion to 1::_
discussion of national replacement characters was made
powerup
mode
was
simplified,
QVSS location wa
described, boot flag bits 0 and 7 were dropped.
Revision 1.17

Revisions for phase 1 - continued
Power-up modes redefined,
section
on
diagnost~=
enlarged, number of console languages enlarged from 5 ~
10, documentation of all TOY registers strictly inter~a
to the console program was removed, console flag bi~
moved to CPMBX TOY register,
CPFLG
TOY
regis'tE
eliminated, power-up figures revised.

Revision 1.18

Revisions for phase 1 - continued
Revision of appendix a, LED and console output codes
halt message texts converted to abbreviation so as ~
avoid requirements for translation.

Date:

22-Jun-1984

Revision 1.19

Revisions for delayed phase 1 - continued
Discussion of the power-up sequence and the overa:
organization
of
the
beginning
of
the Softwa.:Capabilities section was revised. Wording around d!::
boot was modified.
Cleanup for a pre-phase-l release.

Date:

18-Jul-1984

Revision 1.20

Date:

adde

2-Aug-1984

Revision 1.21

Date:

Converted processor name from KDQ32 to KA630,
Portuguese to the list of supported languages.

Changed spec name from
vestigial
documentation
console memory.

KA630 to KA630-A.
Dele'te
of "interrupt pagel! base-

10-Sept-84

Revision 2.0

Text of
reduced.

user-friendly console
Post Phase 1 copy.

iii

messages

revised

an~

Digital Equipment Corporation - Software Specification

Date:

2-Nov-84

Revision 2.1

Date:

Rearrange test sequence, add
screen displays.

QxSS

information,

cha~~

31 January 1985

Revision 2.2

Correct PROM boot definition.
alg. displays.

Correct language

defau':'.

Digital Equipment Corporation - Software

Specificatic~

CONTENTS
PRODUCT SUMMARY
ENVIRONMENT . . .
2
Users
2.1
Hardware
2.2
Software
. . . .
2.3
Services
...
....
. .
2.4
SOFTWARE CAPABILITIES
. . .
. .
3
Power-up
.........
. .
3.1
3.1.1
Power-up Mode
. ..
...
. .
Power Stabilization And ROM Checksum Checks
3.1.2
Console Program Initialization . . . . . . .
3.1.3
Battery Backup Check . . . . . . . . . . .
3.1. 4
Test Interprocessor Communication Register
3.1.5
Determining The Console Terminal Type
3.1. 6
QxSS Determination . . . . . .
3.1.6.1
3.1.6.2
Console Terminal Determination . . .
3.1. 7
Console Message Language Check . . . .
3.2
Entry/Dispatch
. . . . .
3.3
Diagnostics
. . . . . . .
3.4
Restart
. . . . . . .
Bootstrap . .
3.5
Primary Bootstrap Program (VMB)
3.5.1
3.5.1.1
Bootstrap Devices
3.5.1.2
Bootstrap Command FI
3.5.1.3
Booting From Disk
3.5.1.4
Booting From Tape
3.5.1.5
Booting From PROM
. . .
3.5.1.6
Booting From DEQNA . . . .
...
3.5.1.7
Booting An Auxiliary Processor
3.5.2
Secondary Bootstrap Program
...
Console I/O Mode (System Halted)
3.6
3.6.1
Console Control Characters
3.6.2
Console Command Syntax . . . .
...
Console Command Keywords . . . . . . . . . .
3.6.3
3.6.4
References To Processor Registers And Memory
3.6.5
Console Commands
....
3.6.5.1
BOOT . .
. . .
3.6.5.2
CONTINUE .
3.6.5.3
DEPOSIT
. . .
EXAMINE
. . .
3.6.5.4
FIND . .
3.6.5.5
3.6.5.6
INITIALIZE
3.6.5.7
HALT . .
3.6.5.8
REPEAT
3.6.5.9
START
3.6.5.10
... .
TEST . . .
3.6.5.11
UNJAM . . . .
... .
Binary Load And Unload Command
3.6.5.12
3.6.5.13
Comment
. . . . . . . . .
3.6.6
Console Errors And Error Messages
3.6.7
Halts And Halt Messages
. . . . .
1

.
.
.
.

. -

. 9
10
1 ~

16
16
.L !

.
.

28
20
21
22
25
25
27
27
28
28
28
29
29

31
32
~~

32
33
33
33
33
34
35
35
36

Digital Equipment Corporation - Softwa:re Specification

3.7
4

5
6

7
8
9

10
11
12
12.1
12.2
12.3
13
14
15
16

Program I/O Mode (System Running)
PUBLICATIONS . .
PACKAGING
. . . . .
...
INSTALLABILITY
EASE OF USE . . .
PERFORMANCE
RELIABILITY . . . . . .
MAINTAINABILITY
MAINTENANCE
COMPATIBILITY . . . . . . .
Product Compatibility . . .
Standards Conformance
Internationalization .
EVOLVABILITY . . . . . . .
COSTS

•

TIMELINESS . . . . . . .
CONSTRAINTS AND TRADEOFFS

•

....

37
38

38
38
38

•

....... .
. . .

40
40
41
41
4:
42
42
42
43
43
43
44

APPENDIX A

INTERPRETATION OF KA630 LED AND CONSOLE DISPLAY CODES

APPENDIX B

SUMMARY OF I/O REGISTERS USED BY CONSOLE PROGRAM

B.1
B.2
B.2.1
B.3
B.4
B.5

BOOT AND DIAGNOSTIC CONFIGURATION REGISTER (BDR)
B-1
TIME OF YEAR (TOY) CLOCK REGISTERS . . . . . . .
B-2
Console Program Mailbox (CPMBX)
...... .
B-2
SYSTEM IDENTIFICATION EXTENSION REGISTER (SIDEX) · B-3
CONSOLE TERMINAL REGISTERS . . . . . . . . .
· B-4
INTERPROCESSOR COMMUNICATION REGISTER (IPCR) . . · B-4

APPENDIX C

QXSS AND APT

APPENDIX D

OUTSTANDING ISSUES

FIGURES
1
2
3
4
5
6
7
8
9
10

Console Memory Map . . .
· . 5
User Language Prompt . .
...
. 8
QxSS Keyboard prompts
. . . . . .
. 9
RPB Format . . . . . . . . . .
12
Bootblock Format . . . .
...
18
Extended RPB . . . . . . . . . . .
23
Secondary Bootstrap Argument list
24
Secondary Bootstrap Memory Map .' .
. . . 24
Console Display on Successful Power-Up . . . .
39
Console Display on Power-Up with Hard Errors .
40

Digital Equipment Corporation - Software

Specificat~~~

TABLES
I
2

3
4

5
6
A-I

Power-up Modes . . . . .
Console Entry Decision Table
VMB Register Usage . .
...
VMB Bootstrap Command Flags
Console Error Messages .
KA630 Halt Messages
...
KA630 LED Interpretation

vii

-'. -r..
_

Digital Equipment Corporation - Software Specifica~~
PRODUCT sm·~:.:...:.
1

PRODUCT SUMMARY

This document describes the KA630 console program.
This program
conjunction with KA630 hardware implements the KA630 console sys~,
which gains control whenever KA630 "halts". For the KA63 a 1
"hal ti::-._
means only that control is transferred to this program, not that processor stops executing instructions.
When the console program is running, it provides services expected of
VAX-li console system.
In particular, the following services a:
available:
o

Automatic restart or bootstrap
initial power-up.

following

processor

Diagnostic tests executed on power up that check out
the memory system and the Q22-bus map.

Support of video or hardcopy terminals as the console termi~=,
as well as support of QVSS or QDSS based bitmapped terminals.

interactive command language allowing the
and alter the state of the processor.

ENVIRONMENT

2.1

Users

user

halts
exaIl:
the

C-':;C-

Engineering, Manufacturing, Field Service and customers will use th~
program to test, configure and boot their system. This program ~
needed by these users both to provide an easy means to bootstrap a ~_6~
system and to detect and isolate system malfunctions.
Of these users, all but customers are assumed to
be
compu~E
"sophisticates". While this will often be true of customers as well, ~
such assumption is made. Target customers include both sophistica~E
users who can use and understand all the features provided by ~~
console program as well as unsophisticated users who know next ~
nothing about computers.
Users axe not assumed to speak English.
The console program may i:::
directed to output all console messages in either English, Frenc~
German, Spanish, Italian, Norwegian, Dutch, Swedish, Finish, Danish c
Portuguese.
If when the system powers up there is no languag
specified, it prompts the user for the language to use.
The USE
language is recorded in battery backed up RAM so the preferred languag
is retained when the system is shut off.

Digital Equipment Corporation - Software Specification
ENVIRONMENT
2.2

Hardware

The console program is located in ROM on the KA630 processor board.
ROM address range is located in the KA630's local 1/0 space.
program uses the KA630 processor LEDs and console terminal outout
communicate diagnostic progress and error reports to the user.
A console terminal is not required for operation but halts should no~ enabled on a system without a console terminal. A QxSS (either QVS2 QDSS) based display can be substituted for the console terminal.
In order for the console program to operate, the processor must functioning to the point of executing instructions from the COr.S2:
program ROM.
The KA630 decodes the ROM addresses so that the same ROM appears .... -~
than once in the address space.
The console program is writ~e~ :
position independent code so that it may be executed from any add~25
range and the KA630 uses this feature to selectively enable and disa::::
the external halt circuitry. If the console program is executing in ~~
range of 20040000 to 2004FFFF
(hex), external halt conditions a~
ignored.
If the console program is executing in the range of 20050~:
to 2005FFFF
(hex) external halt conditions are honored and the canso:
program may be "halted" (whereupon it will immediately reenter at -beginning to process the halt).
The console program normally executes from the first address range wh~:
the diagnostics software normally executes from the second add~2~
range.
consult the Kr.~~
For more information on the processor hardware,
Processor Specification.
See also appendix B for a summary of ~~
hardware registers used by the console program.

2.3

Software

None - the console program runs standalone, it uses
products.

2.4

other

softwa~

Services

None - the console program requires no support services.

SOFTWARE CAPABILITIES

The console program is divided into six major components
diagnostics. These components and their responsibilities are
2

plus

tL-

documen~e

Digital Equipment Corporation - Software Specifica::.:':
SOFTWARE CAPABIL:T:~
in the sections that follow.
Diagnostic Specification".

Diagnostics are documented in

Note that throughout this document,
referred to simply as the "console".

the

console

"KA630

program

o~-~

The console program receives control whenever the processor hal::.~
whether becasue of an external halt signal, the execution of aha:
instruction, a serious system error or because of power-up. On any ha:
condition,
the processor switches to physical addressing, saves the ?:
PSL and the ISP internally, encodes and saves the cause of the halt i~
halt code and then branches to the start of the console program RC~
Upon entry, the console program always outputs the hex value "E" to ::.~
console LED's to indicate that at least one instruction has be~
executed.
It then waits for power to stabilize by looping until BDR<:5
is set.
When these common preliminaries are completed, the console prog=a
checks to see if the halt is a power-up halt or a halt for some oth~
reason.
If it is a power-up halt,
it begins the power-up seque~=
described in section 3.1. If it is not a power-up halt, control passe
to the entry and dispatch code described in section 3.2.

3.1

Power-up

Upon power-up, the console automatically performs a variety of one t:'~
operations.
These operations initialize the processor and are need~
only on power-up.

3.1.1

Power-up Mode -

On power-up, BDR<lO:9> is interpreted as a power-up mode field.
..., ...
interpretation of the power-up mode field is shown in table 1. ~
discussed in the sections that follow, several power-up operations a=
dependent on the power-up mode.
Table 1:

Power-up Modes

Mode

Language Prompt

Prompt for language only if
TOY battery backup failed.

Run full diagnostics.

Prompt for language on every
power-up.

Run full diagnostics.

Diagnostics

Digital Equipment Corporation - Software Specification
SOFTWARE CAPABILITIES
Table 1 (cont.)
Mode

Diagnostics

Language Prompt

Set language to English.

Run console
back tests.

Set language to English.

Run abbreviated diagnostics.

3.1.2

terminal

loo~

Power Stabilization And ROM Checksum Checks -

Following the application of power, the processor first perfor:
hardware initialization and then control is transfered to the conso~
program ROM code. The common console startup functions were descric~
previously in section 3.
Following their completion, on power-~F
control passes to the code described here.
Beginning the power-up processing, the console code outputs the he
value of "0" to the LED's indicating that the power stabilization wa~
is over. It then calculates a checksum of the console program ROM a:checks it against the valid checksum stored in the ROM itself. If ~r
computed checksum differs from the stored checksum, the code "hangs"
a loop. If the checksum is the same, the power-up code proceeds to tt
next step.

3.1.3

Console Program Initialization -

The next step of the power-up initialization
is
location
a~
initialization of the memory needed for the console program itself. Tt
hex value of "C" is output to the LED's at the beginning of this step.
During this step, the console ROM code searches top down throng
available memory for a small contiguous block that will be used by t~
console program for writeable storage. This block consists of two page
for the console's direct use and additional pages for use to store
bitmap of available memory. The amount of memory allocated to ~t
bitmap varies according to the amount of memory available.
Following initialization, memory appears as shown in figure 1.

Digital Equipment Corporation - Software Specifica~~:
SOFTWARE CAPABIL:~:~
Figure 1:
000000

Console Memory Map

+-------+

I
I Low
IMemory
!
!
!
I

I
I
I
I
I
I
I

This memory is not tested during
console initialization. It is tested
later by the power-up memory
diagnostics.

"1--------+

IMemory I
!Bitmap I

Set by the memory diagnostics to
map all good low memory.

+-------+

IConsolel
IMemory !

Used by the console program.

+-------+

XXOOOO

I
IHigh
IMemory
!
I
I
I

I
I
I
I
!
I
I

Bad memory skipped over during console
memory initialization.

+-------+

The console program memory is used by the console program for its
and other data structures.

sta=~

The bitmap is filled in later with a map of valid memory pages by -~
power-up memory diagnostics and this bitmap is passed to the bootstra~ .
as a map of valid memory. Beginning from the base of the bitmap, t~~
first bit corresponds to the first page of low memory, the second bit t~ i
the second page and so on.
If the bit is set, the page is good, if t~~
bit is clear, the page failed the memory test. The bitmap does not ma~
itself nor any other memory that follows the bitmap.
Since sys~e~
software is expected to use only pages marked as good in the bitmaFr
system software is not expected to modify the bitmap or the consol€
program memory. However, both the console program memory pages and t~~
bitmap are checksumed by the console program to guard against accidenta:
modification by the system software.
If the console cannot locate enough memory
bitmap, it "hangs".

for

its

own

use

and

Following initialization of its memory, the console program clear~.
CPMBX<l:O> (halt action), CPMBX<2> (bootstrap in progress flag) anc
CPMBX<3> (restart in progress flag).

Digital Equipment Corporation - Software Specification
SOFTWARE CAPABILITIES
3.1.4

Battery Backup Check -

The next thing done by the power-up operations is to check the TOY cloe
to see if the battery backup has failed.
If this has happened, time c
year has been lost along with the contents of all the TOY clock RAM.
I
the battery backup has failed, the console stops the TOY clock, zerc
the time and all TOY RAM and then initializes the TOY clock control a~
status registers. The operating system must check TOY clock control a~
status register B and determine if the clock is stopped to know if tt
TOY clock contains a valid time.
No change is made to the LED's during this operation.

3.1.5

Test Interprocessor Communication Register -

Next, the interprocessor communication register is
value fiB" is output to the LEDls during this test.

tested.

The

This test is performed at this point as in addition to testing tb
register itself, this tests whether or not the Q22-bus is arbitratin
properly.
If it is not arbitrating, the processor will hang here
Hanging here is preferable to hanging in the next step where we chec
for QxSS video hardware on the bus. Were we to hang in the next ste
without first checking the Q22-bus, the resulting LED display would b
ambiguous as to which failed, the Q22-bus or the QxSS.

3.1.6

3.1.6.1

Determining The Console Terminal Type -

QxSS Determination -

Next, if the processor is an arbiter processor, the console progra:
checks for the presence or absence of a QxSS video display as thconsole device. Either a QVSS or a QDSS will be detected.
If th·
processor is an auxiliary processor, this test is skipped. The he:
value flA" is output to the LED's during this test.
The QxSS is determined by testing for the presence of its CSR address atbs.
(Both QVSS and QDSS use the same CSR address.) If there is n,
response, no QxSS is assumed present and the console program moves t:
the console terminal determination code which follows.
If a QxSS i:
detected, it is initialized and a short diagnostic is executed.
If th~
initialization and diagnostics succeed, the console will use the QxSS a.
its console terminal (however, see appendix C) and skips the next ste~
and moves directly to the step described in section 3.1.7. If eithe~
the initialization or the diagnostic fails, the system hangs.

Digital Equipment Corporation - Software Specifica~~:
SOFTWARE CAPABILI~:~
3.1.6.2

Console Terminal Determination -

If no QxSS is detected, it is assumed that normal a console terminal
connected to the console port or that NO terminal is connected. ~~
console program then next attempts to determined the type of termiL~
connected. The value of "9" is output to the LED's during this test.
This determination is done by sending the terminal a device attrib~~
request escape sequence.
If the device responds with a recognizab:
response, the terminal is classified as a video terminal versus a ha=
copy terminal based on that response. This information is used when ~
console I/O mode to govern how command line editing is performed.
T~
terminal must respond in 1 second to the device query. If no respc~s
or the response is not recognized, the test is repeated two more time
or until the response is understood.
If the device never responds c
the response isn't recognized, the terminal is classified as a hard c~~
terminal.
Terminal response will be recognized in either eight bit
mode.

seven

In addition to determining the presence or absence of a recognizable C:.
console, this information is also used to determine if the termi~~
supports the DEC multinational character set (MCS). The console progr~
assumes that all new terminals, VT2xx and beyond support MCS.
If t~
terminal does not support MCS, CPMBX<7:4> is set to 2, forcing Englis
as the console display language.

3.1.7

Console Message Language Check -

The console next outputs a hex value of "8" to the LED's and the:
determines the appropriate language to use for all console messages
The algorithim used to determine the language appears below.
T~
console language is stored in CPMBX<7:4> (see appendix B).
1.

If power-up mode (see table 1) is
language to English and exit.

set

the

consol,

If power-up mode is 0 or if the value of CPMBX<7:4> is zerc
solici t
the language from the user.
I f the user doesn '-:
respond within 30 seconds, set the language to English (3)
an
exit.

Remember that when the terminal is queried, if it isn't recognized a~
one that supports MCS, CPMBX<7:4> is set to 2, forcing English as t~~
console language. English messages use the 7 bit subset of MCS.
Also,
if a loss of power for the TOY clock is detected, the contents of the
TOY RAM is zeroed meaning that step 2 of the algorithm above will caus~
the user to be prompted.
7

---_. - - - . - - - -..----...--- --.---.-----.. - ..-...------•...------.-..
..

Digital Equipment Corporation - Software Specification
SOFTWARE CAPABILITIES
The format of the user query issued in step 2 is shown in Figure 2.
Figure 2:

User Language Prompt
1)
2)
3)
4)
5)
6)

Danish
German
English
Spanish
French
Italian

7)
8)
9)
10)
11)

Dutch
Norwegian
Portuguese
Finish
Swedish

(I-II) :

The text will be displayed using the
extension.

DEC

Multinational

Character

The user must respond by entering a value of 1 through 11 following ~~
question mark prompt,
any other input will be rejected and the prc~;
line will be issued again. Normal console input line editing feat~=~
(see section 3.6.1) will be available during input.
If the console program has determined that a QxSS video display sys~s
is being used as the console, an additional step is required. The Q~S
display system uses the DEC LK201 keyboard which comes in 16 naticna
variants.
The keyboard variant cannot be determined by querying ~~
keyboard itself, it must be determined either from the language selec~e
or by means of an additiona menu selection. If French, German c
English is specified as the language, the keyboard variant is ambig~o~
and the appropriate menu from figure 3 is displayed and the use= ~
prompted to specify the which national keyboard variant is in use.
the user does not respond in 30 seconds, the last selection is assumed.

Digital Equipment Corporation - Software Specifica~i:
SOFTWARE CAPABILIT::
Figure 3:

QxSS Keyboard prompts

-----------French-----------1) Canada
2) France/Belgium
3) Switzerland
(1 .. 3):

-----------German-----------1) Germany/Austria
2) Switzerland
(1 •. 2):

-----------English----------1) United Kingdom
2) United States/Canada
(1 .. 2):

3.2

Entry/Dispatch

Following the determination of the console language on power-up,
c
directly on entry from any other halt condition, the console dispatche
to the appropriate code to service the halt.
To determine what actions to take, the console program examines the ha:
code,
the halt enable bit
(BDR<14»,
the console program mailbc
register (CPMBX) and then acts in accordance with decision table shoK
in table 2.

Digital Equipment Corporation - Software Specification
SOFTWARE CAPABILITIES
Table 2:

Console Entry Decision Table

BDR (14)

Power-up

CPMBX(l:O)

T
F
F
F
F

X
0

F
F
F
F

T
T
T
T
T

Actions
Diagnostics, bootstrap, halt.
Restart, bootstrap, halt
Restart, halt.
Bootstrap, halt.
Halt
Diagnostics, halt.
Halt.
Restart, halt.
Bootstrap, halt.
Halt.

3
X
0
1

T
F
F
F
F

2
3

A power-up entry is one where the processor halt code is 3.
fiX" mea:-.
"don't care" and the meanings of the other CPMBX codes are defined :.
appendix B, section B.2.1.
Multiple actions in table 1 mean that the first action is taken and
and only if it fails,
the next action is taken. Diagnostics are a
exception.
If diagnostics fail the console will "hang"
withe"":
attempting to bootstrap the processor.
If they succeed, then the ne:·:
action is taken.
Note that because the KA630 does not support battery backup, it exami~e
the halt code and does not attempt to perform restart operatio~
following power-up.

3.3

Diagnostics

On power-up, the Entry/Dispatch code dispatches first to the diagnostic
to check out the processor and memory before proceeding. Before doi~ i
this, the console outputs the message "Performing normal system tests.
to the console terminal. As each test is run, a code is displayed c
the processor LED's and output to the console terminal as well, causi~
a "countdown" to be displayed on both.
The first diagnostic LED code is 8 so executing the diagnostic
continues the LED countdown.
The diagnostic codes are documented L,
table A-I along with all other codes. See figures 9 and 10 in section
for console display formats.
At the conclusion of all tests, the message "Tests completed." is outpu
to the console terminal.
If a diagnostic test detects a fatal error, an error message i
displayed on the console, a summary message is displayed indicating thothe continued operation is not possible and then the system "hangs"
leaving the test code in the LED's. If halts are disabled, the only wa~
10

~--

-----~--------------------.---------.

---

Digital Equipment Corporation - Software Specifica~~~
SOFTWARE CAPABILI~:~
to clear the hung system is to turn the system off and then on aga~:
If halts are enabled, the hung system may be cleared by manually halt~:
it, causing it to enter console command mode.
Diagnostic software
Specification".

3.4

fully

documented

ROM

nKA630

Diagnost:.

Restart

The console can restart a halted operating system.
To do so, t~
console searches system memory for the Restart Parameter Block (RPB),
data structure constructed for this purpose by the operating system.
a valid RPB is found, the console restarts the operating system at c
address specified in the RPB.
The console keeps a "restart in progress" flag in the CPMBX registE
which it uses to avoid repeated attempts to restart a failing operatl~
system. An additional "restart in progress" flag may be maintained t
software in the RPB.
The console uses
system:

the

following

algorithm

restart

the

operati:-.

Check to see if the "restart in progress" flag in CPMBX is set
If so, restart fails.

Print the message "Restarting the
console terminal.

Set the restart in progress flag.

Look for a Restart Parameter Block (RPB), left in memory by th
operating system. If none is found, restart fails.

Read the software restart in progress flag from bit<O> of
fourth longword of the RPB.
If it is set, restart fails.

Load SP with the address of the RPB plus 512.

Load AP with the halt code.

Display

Start the processor at the restart address, which is read
the second 10ngword in the RPB.

operating

system."

tr.

"0" in the console LED's.
fro:

If restart fails, the console prints "Attempt to restart operatin
system failed. 1f on the console terminal.
If the restart is successful
the operating system must clear the restart in progress flag in CPMB:
(see appendix B for information on the CPMBX register) .
11

Digital Equipment Corporation - Software Specification
SOFTWARE CAPABILITIES
The Restart Parameter Block is a page aligned control block, createc
the operating system. Its format is shown in figure 4.
Figure 4:

RPB Format

+----------------------------------------------------- ----------~

physical address of the RPB

+---------------------------------------------------------------!

physical address of the restart routine

+----------------------------------------------------- ----------~

checksum of the first 31 longwords of the restart routine

+----------------------------------------------------- ----------~

software restart in progress flag (bit 0)

+----------------------------------------------------- ----------~

Restart Parameter Block
(RPB)
The console uses the following algorithm to
Block:

find

Restart

Parame~~

Search for a page of memory that contains its address in
first longword.
If none is found, the search for an RPB
failed.

Read the second longword in the page (the physical address :
the restart routine). If it is not a valid physical address
or if it is zero, return to step 1.
The check for zero
necessary to ensure that a page of zeros does not pass the ~esfor a valid RPB.

Calculate the 32 bit twos-complement sum (ignoring overflo'/ls
of the first 31 longwords of the restart routine.
If the s~:
does not match the third longword of the RPB, return to step :

A valid RPB has been found.

The same algorithm is used for both arbiter and auxiliary processors.

3.5

Bootstrap

The console can load and start (bootstrap) an operating system.
To d
so, it searches for a 64 kilobyte segment of correctly functionin,
system memory, sets SP equal to the base address of the segment plus 51:
and then copies the primary bootstrap, called VMB, from the consol~
program ROM to the segment starting at the location specified by S?
The console program then branches to the first location in VMB whic~
then loads and starts the operating system.
12

Digital Equipment Corporation - Software Specificat~c
SOFTWARE CAPABILIT:~
To prevent a situation from occurring in which the console repeated:
tries and fails to bootstrap the operating system, it maintains
"bootstrap in progress" flag in CPMBX.
If a system bootstrap wo-...::
occur automatically but the flag is already set, the console assuw€
that an attempt has already been made and has failed, so it does not t=
again.
The console uses the following
system:

algorithm

bootstrap

operati~

the

If this bootstrap is the result of a console BOOT command,
to step 4.

Check to see if the "bootstrap in progress " flag
so, the bootstrap fails.

Print the message "Starting the operating system."
terminal.

Set the bootstrap in progress flag.

Locate a page-aligned 64 kilobyte segment of good memory.
such a segment cannot be found, the bootstrap fails.

Initialize the Q22-bus

Load the general registers for the
(VMB) as shown in table 3.

Copy VMB from the console ROM to 512 bytes past the base of tt
good segment.

Invoke VMB.

sk~

set.
on

conse:'

Ilo map as described below.
primary

bootstrap

progra

If VMB fails, the bootstrap fails.

If bootstrap fails, the console prints
system failed." on the console terminal.

"Attempt

start

operatin

If the bootstrap is successful, the operating system must clear th~
bootstrap and restart in progress flags in the CPMBX register and clea
the LED display by depositing a value of 0 in the BDR register
(seappendix B) .

Digital Equipment Corporation - Software Specification
SOFTWARE CAPABILITIES
Table 3:

VMB Register Usage

Description

ASCII device name (from BOOT command) or zero.

Contents of KA630 Boot and Diagnostic Register

Memory bitmap size in bytes.

Address of memory bitmap.

Unused.

Software boot control flags (from BOOT command only) .

RIO

halt PC value.

Rll

halt PSL value.

halt code.

512 bytes past base of 64 Kb of good memory.

During step 6 of the bootstrap process the Q22-bus Ilo map i
initialized using the algorithm shown below. The main function of thL
initialization is to preset the arbiter processor Ilo map so that a~_
unoccupied pages of the Q22-bus are mapped to the corresponding pages i:
the first 4 Mb of local memory.
(This is a MicroVAX I compatibili~:
feature) .
Note that this is not done for auxiliary processors, an~
auxiliary Q22-bus 1/0 mapping must be coordinated with all othe:
processors so all auxiliary processor Ilo map registers are marke:
invalid.
1.

Turn on IPCR<8>, the halt flag.

Disable the. Ilo map by clearing IPCR<5>.

If the arbiter processor, do the following
register:
a.
b.
c.

for

each

1/0

ma~

Set the map register address bits to map the Q22-bus pagE
to the corresponding local memory page.
If the corresponding Q22-bus page is unoccupied, turn or
the valid bit.
If the page is occupied, turn off the valid bit.

If an auxiliary processor, turn off the valid bit
registers.

all

ma~

Digital Equipment Corporation - Software Specificatic
SOFTWARE CAPABILITI~
4.

Enable the I/O map by setting IPCR<5>.

If an auxiliary
cleared.

processor,

loop

until

the

IPCR<8>

bit

Steps 1 and 5 are present to perform a secondary function while tr.
Q22-bus I/O map is initialized, namely to synchronize an auxilia=
processor with its bootstrap host. See section 3.5.1.7 for additiona
information.

3.5.1

Primary Bootstrap Program (VMB) -

VMB is the KA630 primary bootstrap.

It is executed as the first part c
a two part system bootstrap operation. VMB contains the code that:
1.

initializes the system control block (SCB),

initializes an extended restart parameter block (RPB),

initializes a PFN (page frame number) bit map and the
extended RPB fields,

selects a bootstrap device, and

performs a Files-II ODS2, boot block, ROM or down-line load
the secondary bootstrap.

relevar.

The secondary bootstrap continues the bootstrap operation.
For K~63
systems, primary bootstrap operations are defined by VMB, secondarbootstrap are defined by the operating system being booted.
VMB finds the bootstrap device in one of three ways:
1.

If the bootstrap is the result of a console bootstrap cornman
and a device name is specified in the command, that device i~
searched for the secondary bootstrap.

If not the result of a console bootstrap command or if n':
device name is specified, VMB searches first for a bootabl
disk, then for a TK50 (Maya) tape unit, then for MRVl1 PROM,
and finally for a DEQNA for a down-line bootstrap.

If the bootstrap is the result of a halt with CPMBX<1:0> equa_
to 2 - a request from the operating system to reboot the syster
the bootstrap device used to previously bootstrap thE
operating system is used (as well as the same command flags) .

Digital Equipment Corporation - Software Specification
SOFTWARE CAPABILITIES
When a VMB bootstrap attempt fails, it halts.

3.5.1.1

Bootstrap Devices -

The following bootstrap devices are supported:
1.

RQDX, QDA and Aztec MSCP disk controllers. VMB can boot fre
any disk unit supported by a MSCP QD or Aztec disk controlle:
Units supported by RQDX are RXsO, RD51, RDs2 and RDs3.
Uni~
supported by QDA are tbs.
For purposes of the BOOTSTR::
command, units are designated DUAO, DUAl, and so on.
The fir~
controller must be configured at the Q22-bus address of 17721:
(octal)
and Q22-bus interrupt
vector
of
154
(octal)
Additional controllers are located in floating CSR and vec~c
space.

DEQNA Ethernet adapter.
This controller connects to
2
Ethernet cable.
For purposes of the BOOTSTRAP command, th~
device is designated XQAO. The controller must be configurE
at Q22-bus address 1774440 (octal) and Q22-bus vector of tbs.

MRV11 PROM.
This is a Programmable Read Only Memory boarc
For purposes of the BOOTSTRAP command it is designated PRAO.

TMSCP tape controller (TKsO). VMS can boot from any tape uni
supported by the the TKsO TMSCP tape controller. For purposE
of the BOOTSTRAP command it is deSignated tbs. The controllE
must be configured at Q22-bus address tbs and Q22-bus interruF
vector tbs. Additional controllers are not be supported.

3.5.1.2 Bootstrap Command Fl - When a bootstrap is invoked via
BOOTSTRAP command, the user can specify several boot command flags t .
bit encoding the flags in a flag word specified with the "IRS:
qualifier. These command flags are described in table 4.
Table 4:

VMB Bootstrap Command Flags

Bit
Number

Value
(Hex)

Flag Name

00000001

CONVERSATION

Description

Conversational bootstrap.

Digital Equipment Corporation - Software Specificati~
SOFTWARE CAPABILIT!~
Table 4 (cont.)
Description

Flag Name

Bit
Number

Value
(Hex)

00000008

BOOT BLOCK

Secondary
bootstrap
from
bc~
block. When this bit is set, V~·
reads logical block number 0 of t:
boot device and tests
it
f(
conformance with the boot blo:
format.
If in conformance, -block is executed to continue t:
bootstrap. No attempt to perform
Files-II bootstrap is made.

00000010

DIAGNOSTIC

Diagnostic bootstrap. When this b~
is set the secondary bootstrap called [SYSO.SYSMAINTJDIAGBOOT.EX~

00000040

HEADER

Image header.
If this bit is r.c
set, VMB transfers control to :::.
first location of the seconda~
bootstrap. If this bit is set, ~
transfers control to the addre5
specified
by
the file's ima~.
header.

00000100

SOLICIT

File name solicit. When this bit ~
set, VMB prompts the operator fc
the name of the secondary bootst~c
file.

00000200

HALT

Halt before transfer. When this b~ .
is
set,
VMB
halts
befor
transfering
control
to
t~
secondary bootstrap.

<31:28>

XOOOOOOO

TOPSYS

X can be any value from 0 through
(hex). This flag changes the tc
level directory name for syste
disks
with
multiple
operati~
systems. For example, if X=l, t~
top level directory name is
(SYS1.

-----------------------------------------------------------------------

. . .] .

3.5.1.3

Booting From Disk -

For VMB to boot using a MSCP disk controller, the first controller mus
be configured at 772150 (octal) and subsequent controllers must b
properly configured in their appropriate floating CSR and vector slots
17

Digital Equipment Corporation - Software Specifica::.:'
SOFTWARE CAPABILI':::
Table 4 (cont.)
Description

Flag Name

Bit
Number

Value
(Hex)

00000008

BOOTBLaCK

Secondary
bootstrap
from
bc~
block. When this bit is set, ~~
reads logical block number 0 of ::.~
boot device and tests
it
~
conformance with the boot ble:
format.
If in conformance,
-.
block is executed to continue -.
bootstrap. No attempt to perform
Files-II bootstrap is made.

00000010

DIAGNOSTIC

Diagnostic bootstrap. When this ~~
is set the secondary bootstrap
called [SYSO.SYSMAINT]DIAGBOOT.EX~

00000040

HEADER

Image header.
If this bit is ~:
set, VMB transfers control to -.
first location of the seconda:
bootstrap.
If this bit is set, :
transfers control to the addrs5
specified
by
the file's
ima:
header.

00000100

SOLICIT

File name solicit. When this bit _
set, VMB prompts the operator - ,.
the name of the secondary boots::.rE
file.

00000200

HALT

Halt before transfer. When this c:
is
set,
VMB
halts
befe:
transfering
control
to
::.~
secondary bootstrap.

<31:28>

XOOOOOOO

TOPSYS

X can be anv value from 0 throug~
(hex). This-flag changes the
~~
level directory name for systs
disks
with
multiple
operati~
systems. For example, if X=I,
t~
top level directory name is
(SYS:

... ] .

3.5.1.3

Booting From Disk -

For VMB to boot using a MSCP disk controller, the first controller mUE
be configured at 772150(octal)
and subsequent controllers must t
properly configured in their appropriate floating CSR and vector slots
17

Digital Equipment Corporation - Software Specification
SOFTWARE CAPABILITIES
When VMB determines that a controller is present, it searchs in orde= :
increasing unit number for an accessible unit with a
removable volk~~
If it finds such a unit with a volume present, VMB proceeds as descr~b~
below.
If it finds no such volume, it repeats the search but this -:it checks for non-removable volumes.
If by this time no accessib:
volume is found, it checks for the next controller and repeats ~~
checks described.
If no more controllers are found, the disk ~C~
fails.
If an accessible volume is located, VMB then determines if it ~s
Files-II volume.
If it is, it searches the volume for Il[SYSO.SYS~X~
SYSBOOT.EXE Il which contains the secondary bootstrap.
If this file
found, VMB loads and executes it (performs a secondary bootstrap) .
If the volume is not a Files-II volume, VMB then checks logical b:o:
number zero of the volume for a valid bootblock (see figure 5).
If t~
bootblock is a valid bootblock VMB loads and executes the seconda~
bootstrap specified in the bootblock.
If there is not a valid bootblo:
present, the search resumes for the next accessible disk.
Note that the bootstrap process can be altered by boot command flags
Information on the effect of boot command flags is given in table 4.
Figure 5:
BB + 0:

Bootblock Format

+---------------+---------------+-----------------------------1

+---------------+---------------+------------------------------

+
+ 4:

BB + 2*n

+
+

high LBN

+---------------+---------------+---------------+-------------check byte

18 (hex)

+---------------+---------------+---------------+-------------any value
1 or 81
o
+-------------------------------+---------------+---------------

size in blocks of the image

+---------------------------------------------------------------

+
+ 12:

low LBN

+--------------------------------------------------------------

any value

load offset from default load address

+--------------------------------------------------------------+ 16:

offset into image to start execution

+-------------------------------------------------------------+

+ 20:
+

sum of previous three longwords

+-------------------------------------------------------------BB+O:

These two bytes can have any value.

BB+2:

This value is the word offset from the

s~ar~

,------~------------------,.------,.

Digital Equipment Corporation - Software
SOFTWARE

the
bootblock
described below.

the

CAP~~IL:=:::

a=~

identification

BB+3:

This byte must be one.

BB+4:

This longword contains the logical block
(word swapped) of the secondary image.

"",.-~
.1."'~i.....---::

BB+(2*n)+O:

This byte defines the expected instruction
18(hex) means VAX.

BB+(2*n)+1:

This byte defines the expected controller
o means unknown.

BB+{2*n)+2:

This byte defines the file
volume, it may be any value.

BB+(2*n)+3:

This byte must be the ones complement of the __
of the previous three bytes.

BB+{2*n)+4:

This byte must be zero.

BB+{2*n)+5:

This byte must be 1 or 81
Thi s '::;-.''":
(hex).
defines
the
version number of the fo:::::::::.
standard and the type of disk. The version
1, the high bit is 0 for single sided, 1 ::::
double sided.

BB+(2*n)+6:

These two bytes must be zero.

BB+(2*n)+8:

This entry is a longword containing the size
blocks of the secondary bootstrap image.

BB+(2*n)+12:

This entry is a longword containing a
offset
(usually zero)
from the default
address of the secondary bootstrap.

BB+(2*n)+16:

This entry is a longword containing the
offset
into
the secondary bootstrap
execution is to begin.

BB+(2*n)+20:

3.5.1.4

Specificc~~:

structure

This entry is a longword containing the
the previous three longwords.

1_ '-'
~
c:.

by'":
t .. ::..:?:::- -

sum

Booting From Tape -

If no bootable disk is found, VMB attempts to bootstrap from a TK5
tape.
The TK50 must be configured at <tbs> octal to be recognized o'
VMB.

Digital Equipment Corporation - Software Specification
SOFTWARE CAPABILITIES
If a TK50 is present, VMB determines if a tape is loaded and the uni~
online.
If so, VMB rewinds the tape and searches for the =i~
TAPEBOOT.EXE.
(The user may specify an alternative file name by se~~i~
the SOLICIT bit in the software command register [see table 4]).
this file is found, VMB loads and executes it. Normally this file W~~~
contain a program to load an operating system from tape onto a sys~~
disk.
Note that a TAPEBOOT.EXE program to load a disk from tape is not a
of this project.

~~=

If a user has both disks and tape, and a disk is bootable, to boot -~
tape the user must either take all bootable disks offline or explici~~
boot the TK50 via the console boot command.

3.5.1.5

Booting From PROM -

If neither disk nor tape is bootable, VMB checks for a PROM bootstra~.
To locate a PROM bootstrap, VMB searches the Q22-bus address range -~
low to high addresses in 16 page chuncks looking for readable memcr~
If the first six longwords of any such page contains a valid "signa~~=
block" (identical to the second part of the bootblock format, see fi:;-.:.=
5), VMB copies the PROM image to main memory and then transfers con~r~
to it.
Note that while defined as a MRVll PROM or equivalent bootstrap,
doesn't actually require that the signature block or the bootstrap 0::':::'
be in PROM, it could be in ROM, nonvolatile RAM or, as described
section 3.5.1.7, it could be loaded into another KA630's RAM and ma~~s
to the Q22-bus.

3.5.1.6

Booting From DEQNA -

If no other bootstrap device is found, VMB attempts to bootstrap ::ro:
the DEQNA ethernet controller.
In this case, the secondary bootstraf ic
downline loaded from a host on the Ethernet using DECNET Low-levs
Maintenance Protocol
(MOP) Version 3.0.
The DEQNA module must ;:
configured at Q22-bus address 774440 (octal).
The downline load process consists of the following steps:
1.

VMB performs local testing of the DEQNA.
If the tests fai:.·
the bootstrap attempt fails and the three LED 1 S on the DEQ:::·
The LED setting_
are set according to the problem detected.
and their interpretations are:
o

3 LED's on:

DEQNA initialization failure.
20

Digital Equipment Corporation - Software Specifica=i:.
SOFTWARE CAPABIL:T:;·
o
o

2 LED's on:
internal loopback failure.
1 LED on: external loopback failure.

VMB transmits a Program Request MOP message over the Ether~e:
The message destination is the Load Assistant Multicast addre:
AB-OO-OO-OI-OO-OO.
The message source address is the DEQNA'
The MOP program type ~
station address
(from DEQNA PROM)
operating system.

VMB waits approximately 30 seconds to receive a response.
it does not receive a response it retransmits the request eve:
thirty seconds for a total of 2 minutes.
If a response is ..
received in two minutes, the bootstrap fails.
h

3.5.1.7

VMB accepts MOP Load Messages and loads the data into memor:
terminating when the final message is received as indicated :...
the MOP message protocol.
If the interval between Icc
messages exceeds 30 seconds, VMB restarts the DEQNA bootst=~
at step 2.

Booting An Auxiliary Processor -

VMB bootstraps an auxiliary processor via the ROM bootstrap
Recall from section 3.5 the Q22-bus initialization algorithm:
1.

Turn on IPCR<8>, the halt flag.

Disable the I/O map by clearing IPCR<5>.

Initialize the I/O map.

Enable the I/O map by setting IPCR<5>.

If an auxiliary
cleared.

processor,

loop

until

the

IPCR<8>

protocc:

bit

(Note that whenever the console program is entered,
it turns of
IPCR<8>.)
Steps 1 and 5 ensure that an auxiliary will loop until scrr
other processor clears IPCR<8>. When another processor, the bootstra
host,
clears IPCR<8>, the auxiliary proceeds with the bootstrap. Thi
synchronization gives the
arbiter
processor
control
over
th
bootstrapping of all auxiliary processors.
An auxiliary processor cannot directly bootstrap itself from any of th
normal bootstrap devices so VMB on an auxiliary checks only for the RO:
bootstrap described in section previously. The ROM bootstrap may b
either a block of nonvolatile memory on the Q22-bus bus or the bootstrahost can construct an equivalent bootstrap in RAM.
In either case th:
21

Digital Equipment Corporation - Software Specification
SOFTWARE CAPABILITIES
auxiliary will not proceed with the bootstrap until the bootst~ao
clears IPCR<8>.
The bootstrap host in turn should not clea~
auxiliary's IPCR<8> unless IPCR<5> is clear.

3.5.2

Secondary Bootstrap Program -

The secondary bootstrap program is invoked as the second part 0=
system
bootstrap.
Following successful execution of the p~l=a~
bootstrap, the secondary bootstrap has either been loaded into memo~~ located in ROM.
It is the responsibility of the secondary bootst~a~ ~
complete the bootstrap of the processor.
VMB calls the secondary bootstrap with the processor
state:

follo~\':'.::-.

the

S -;:;
........-

The processor is running in kernel mode on the interrupt
at IPL 31 (hex) .

R11 contains the base address of the extended
built by VMB.

AP contains the address of
list (figure 7).

SP contains the address of the top of the stack plus
4,
WL':'C
is also the address of the beginning of the secondary boots~ra
(figure 8 for a map of memory) .

SCBB (internal processor register) contains the address of
SCB built by VMB.

the

Note that the first four longwords of
not be recognized as a valid RPB by
is up to the secondary bootstrap or
complete the RPB if automatic restart

secondary

RPB

(figure

bootstrap

argur.~e:-.

the VMB built extended RPB wo~:
the console restart algorithm.
the operating system itself ~
is desired.

Digital Equipment Corporation - Software Specif~c~~~
SOFTWARE CAPABI~:~:=
Figure 6:

Extended RPB

Offset (hex) :
00:
04:
08:
OC:
10:
14:
18:
1C:
20:
24:
28:
2C:
30:
34:
3C:
40:
44:
48:
4C:
50:
54:
68:
90:
BO:

+-----------------------------------------------+
I
address of the extended RPB
I
+-----------------------------------------------+
I
0
I
+-----------------------------------------------+
I
0
!
+-----------------------------------------------+
I
0
I
+-----------------------------------------------+
I
PC at restart/halt
I
+-----------------------------------------------+
PSL at restart/halt
+-----------------------------------------------+
I
halt code
I
+-----------------------------------------------+
I
VMB input register RO
I
+-----------------------------------------------+
I
VMB input register R1
I
+-----------------------------------------------+
VMB input register R2
+-----------------------------------------------+
I
VMB input register R3
I
+-----------------------------------------------+
I
VMB input register R4
I
+-----------------------------------------------+
I
VMB input register R5
I
+-----------------------------------------------+
I
two longwords reserved
I
+-----------------------------------------------+
I
disk block address of secondary bootstrap
I
+-----------------------------------------------+
I size of secondary bootstrap file in blocks
I
+-----------------------------------------------+
I
descriptor of PFN bitmap (two longwords)
!
+-----------------------------------------------+
!
number of good physical pages
I
+-----------------------------------------------+
I
reserved
I
+-----------------------------------------------+
I
physical CSR address of boot device
I
+-----------------------------------------------+
I
four longwords reserved
I
+-----------------------------------------------+
I secondary bootstrap file name (40 characters)
!
+-----------------------------------------------+
I
eight longwords reserved
I
+-----------------------------------------------+
I
system control block base address
!
+-----------------------------------------------+
23

Digital Equipment Corporation - Software Specification
SOFTWARE CAPABILITIES
Figure 7:

Secondary Bootstrap Argument list

+-----------------------------------------------+
12

{AP)+OO:

+-----------------------------------------------+

{AP)+04:
{AP)+08:

reserved

lowest valid PFN

highest valid PFN

PFN map size in bytes

address of PFN bitmap

reserved

processor ID (8????)

reserved

+-----------------------------------------------+

(AP)+12:

+-----------------------------------------------+

(AP) +16:

+-----------------------------------------------+

{AP)+24:

+-----------------------------------------------+

(AP)+28:

+-----------.------------------------------------+

(AP)+32:

+-----------------------------------------------+

{AP)+36:

+-----------------------------------------------+

(AP)+40:

+-----------------------------------------------+

(AP)+44:

+-----------------------------------------------+

(AP)+48:

Figure 8:

+-----------------------------------------------+

+-----------------------------------------------+
Secondary Bootstrap Memory Map

+-----------------------------------------------+
R11:
+

200 (hex) :

+ ???? (hex) :

+ ???? (hex) :
+ ???? (hex) :

+ ????(hex):

+10000(hex) :

Extended RPB built by VMB

VMB

2 page SCB used by VMB

8 page PFN bitmap

+-----------------------------------------------+
+-----------------------------------------------+

I :SCEi:

+-----------------------------------------------+
I

4 page stack for Secondary Bootstrap

+-----------------------------------------------+
I
I
I
I
I

Secondary Bootstrap

I :SP
!
I
!
!

+-----------------------------------------------+

Digital Equipment Corporation - Software Specifica~~:
SOFTWARE CAPABIL:r:~
3.6

Console I/O Mode (System Halted)

When the KA630 is "halted", the operator controls the system through -'-console terminal using the console command language.
The conse:
terminal is in "Console I/O Mode". The console prompts the operator ::::
input with the string "»>".

3.6.1

Console Control Characters -

In console I/O mode, several characters have special meanings.
o

carriage return - ends a command line. No action is taken on
command until after it is terminated by a carriage return.
null line terminated by a carriage return is treated as
valid, null command.
No action is taken, and the conso:
re-prompts for input. Carriage return is echoed as carria=
return, line feed.

rubout - when the operator types rubout, the console dele~e
the character that the operator previously typed. What appear
on the console terminal depends on whether the terminal is
video terminal or a hardcopy terminal.
For hard copy terminals, when a rubout is typed, the conso:
echoes with a backs lash (\), followed by the character be~~
deleted.
If the operator types additional rubouts,
-additional characters deleted are echoed. When the opera~;:
types a non-rubout character, the console echoes anot~e
backslash,
followed by the character typed. The result is ~
echo the characters deleted, surrounding them with backslashes
For example:
The operator types: EXAMI;E<rubout><rubout>NE<CR>
The console echoes: EXAMI;E\E;\NE<CR>
The console sees the command line: EXAMINE<CR>
For video terminals, when rubout is typed the
previou
character is erased from the screen and the cursor is restore
to its previous position.
The console does not delete characters past the beginning of
command line.
If the operator types more rubouts than ther
are characters on the line, the extra rubouts are ignored.
T
a rubout is typed on a blank line, it is ignored.

control-U - the console echoes fll'U<CR>" t and deletes the entir
line.
If control-U is typed on an empty line, it is echoed
and otherwise ignored.
The console prompts for
anothe
25

.------------~-.-

...

--... ----.---.-..-

.•...•.- ...----_.__ •.. __.....•• __.

Digital Equipment Corporation - Software Specification
SOFTWARE CAPABILITIES
command.
o

control-S
stops output to the console terminal
unt~
control-Q is typed.
Control-S and control-Q are not echoec
Control-C, control-O, and BREAK also clear control-So

control-Q - resumes output to the console terminal. Addition.::
control-Q's are ignored.
Control-S and control-Q are nc
echoed.

control-O - causes the console to throwaway transmissions the console terminal until the next control-O is enterec
Control-O is echoed as fI"Ou<CR> when it disables output, but
not echoed when it reenables output. Output is reenabled ~
the console prints an error message, or if it prompts for
command from the terminal. Displaying a REPEAT command dOE
not reenable output. When output is reenabled for reading
command, the console prompt is displayed.
Output is alE
enabled by entering program I/O mode, by BREAK and
t
control-C. Control-O clears control-So

control-R - causes the console to echo <CR><LF> followed by tr
current command line. This function can be used to improve tr
readability of a command line that has been heavily edited.

control-C - causes the console to echo "AC" and to abo:
processing of a command. Control-C has no effect as part of
binary load data stream.
Control-C clears control-S ,
ar
reenables output stopped by control-O. When control-C is tYPE
as part of a command line, the console deletes the line as
"
does with control-U.

BREAK - If the console is in console I/O mode,
BREAK i
equivalent to control-C, but is echoed as IIAplr,
If the conso.l
is in program 1/0 mode and halt is disabled, BREAK is ignoree
If the console is in program I/o mode and halt is not disablee
BREAK causes the processor to halt and enter console I/O mode.

Control characters are typed by pressing
simultaneously holding down the control key.

the

character

key

whil

If an unrecognized control character is typed (a control character her
means a character with an ASCII code less than 32 decimal [CO) c
between 128 and 159 decimal [Cl]) it is echoed as up arrow followed t
the character with ASCII code 64 greater.
For example, BEL (ASCII coe
7) is echoed as "AG", since capital G is ASCII code 7+64=71.
When
control character is deleted with rubout, it is echoed the same way
After echoing the control character, the console processes it like
normal character.
Unless the control character is part of a comment
the command will be invalid, and the console will respond with an errc
message.
Note that control codes from 128 to 159, the C1 control codes
cannot be entered by any present Digital terminal.
The fact that bot
26

Digital Equipment Corporation - Software Specifica~~
SOFTWARE CAPABILI~::
the character with code 7 and the character with code 135 will both e-:
as "AG" is not expected to have any practical consequences.

3.6.2

Console Command Syntax -

The console accepts commands of lengths up to 80 characters.
LonOf
commands are responded to with an error message.
The count does ;include rubouts, rubbed out characters,
or the terminating carria:
return.
Commands may be abbreviated.
Abbreviations are formed by dropp~:
characters from the end of a keyword. All commands are recognized =~:
their first character.
Multiple adjacent spaces and tabs are treated as a single space
console.
Leading and trailing spaces and tabs are ignored.
Command qualifiers can appear after the command keyword,
symbol or number in the command.

after

a:-.

All numbers
(addresses,
data,
counts)
are in hexadecimal.
(Nc~~
though, that symbolic register names include decimal digits.) Hex dig~~
are 0 through 9, and A through F.
The console does not distingu~~
between upper and lower case either in numbers or in commands.
Both a=
accepted.

3.6.3

Console Command Keywords -

Processor control commands:
o

INITIALIZE

START <address>

CONTINUE

HALT

BOOT <device>

UNJAM

Data transfer commands:
o

EXAMINE <address>

DEPOSIT <address> <data>
27

_.._--_.

__ ..•..•_------_.._.._._--------------_._-_..--------------.

Digital Equipment Corporation - Software Specification
SOFTWARE CAPABILITIES
o

X <address> <count>

Console control commands:
o

FIND

REPEAT <command>

TEST

! <comment>

3.6.4

References To Processor Registers And Memory -

The KA630 console is implemented by macrocode executing from ROM.
==
this reason,
the actual processor registers may not be modified by ~~
command interpreter.
When the console is entered, the console saves - ,processor registers in console memory and all command references to tc~
are directed to the corresponding scratch page locations,
not to -~
registers themselves.
When the console reenters program mode, the sa~~
registers are restored and any changes become operative only the~
References to processor memory are handled normally except where no::-::below.
The console uses memory at the top of the available system memory f:
its own use (see figure 1). References to the console memory pages ~
EXAMINE and DEPOSIT commands must be qualified by the "/U" qualifie::
(Access is primarily to simplify debugging of the console program.) Tr.
binary load and unload command may not reference the console memc::
pages.

3.6.5

3.6.5.1

Console Commands -

BOOT-

BOOT [<qualifier list>]

[<device>]

The device specification is of the format ' ddcu', where I dd'
is a
t\·;
letter device mnemonic, 'c' is an optional one digit controller numbe::
and 'u ' is a one digit unit number.
The console initializes the processor and starts VMB running.
(See th
section on System Bootstrapping.) VMB boots the operating system fro:
the specified device.
The default bootstrap device is determined a
described in the section on system bootstrapping.

Digital Equipment Corporation - Software Specificat~:
SOFTWARE CAPABILrT:~
Qualifiers:
o

3.6.5.2

/R5:<data>
After initializing the processor and befc=
starting VMB, R5 is loaded with the specified data. TL~
allows a console user to pass a parameter to VMB.
(To rerr:a~!
compatible with previous processors,
/<data> will also ~
recognized to have the same result.)

CONTINUE-

CONTINUE
The processor begins instruction execution at the address curren~:
contained in the program counter.
Processor initialization is ~c
performed. The console enters program I/O mode.
If upon entry the console program is unable to preserve the mach:"::
state, either because it was a power-up or because it was unable ::
locate a scratch page on the interrupt stack, the CONTINUE command ~.."..:..:
be rejected.

3.6.5.3

DEPOSIT-

DEPOSIT [<qualifier list>] <address> <data>
Deposits the data into the address specified. If no address space c
data size qualifiers are specified, the defaults are the last addre5
space and data size used in a DEPOSIT or EXAMINE command.
Af~e
processor initialization, the default address space is physical memc=:the default data size is long, and the default address is zero.
If the specified data is too large to fit in the data size to b
deposited, the console ignores the command and issues an error response
If the specified data is smaller that the data size to be deposited,
,is extended on the left with zeros.
The address may also be one of the following symbolic addresses:
o

PSL
the processor status longword.
No address
spac
qualifier is legal. When PSL is examined, the address space
identified as "M" (machine dependent).

PC
the program counter (general register
space is set to /G.

SF
tl1.e stack pointer
space is /G.

(general

15) .

The

addres:

14) .

The

addres:

---.-.---------_.

Digital Equipment Corporation - Software Specification
SOFTWARE CAPABILITIES
o

Rn - general register 'n'.
The register number is in
The address space is IG.
For example:

dec~~a:

D R5 1234 is equivalent to DIG 5 1234
D RIO 6FFOO is equivalent to DIG A 6FFOO
o

'+' - the location immediately following the last loca~~:
For references
referenced in an exam~ne or deposit.
physical or virtual memory spaces, the location referenced
plus the size of the last reference (: -the last address,
byte, 2 for word, 4 for long).
For other address spaces,
address is the last address referenced, plus one.

'-' - the location immediately preceding the last loca~~:
referenced in an examine or deposit.
For references
physical or virtual memory spaces, the location referenced
the last address minus the size of this reference (I for by~~
2 for word, 4 for long).
For other address spaces, the add~e5
is the last addressed referenced minus one.

, *,

'@' - the location addressed by the last location referenced
an examine or deposit.

the location last referenced in an examine or depos:'t:.

Qualifiers:
o

IB - The data size is byte.

Iw - The data size is word.

IL - The data size is longword.

Iv - The address space is virtual memory.
All access c ..
protection checking occur.
If the access would not be allo~~
to a program running with the current PSL, the console iss~~
an error message. Virtual space DEPOSITs cause the PTE<M> b~
to be set.
If memory mapping is not enabled, virtual address~
are equal to physical addresses.

Ip - The address space is physical memory.

II - The address space is internal processor registers.
Thes
are the registers addressed by the MTPR and MFPR instructions.

IG - The address space is the general register set, RO

thrcu;

PC.
o

Iu - Access to the console scratch page is allowed.
qualifier also disables virtual address protection checks.
30

Digital Equipment Corporation - Software Specificat~:
SOFTWARE CAPABILIT:=
o

/N:<count> - The address is the first of a range.
The conse:
deposits to the first address, then to the specified numbe~ :
succeeding addresses. Even if the address is the symbo::
address "-", the succeeding addresses are at larger addressa~
The symbolic address specifies only the starting address,
the direction of succession.
For repeated references
preceding addresses, use flREPEAT DEPOSIT - <data>".
For example:
D/P/B/N:1FF 0 0

Clears the first 512 bytes
memory.

D/V/L/N:3 1234 5

Deposits 5 into 4 longwords starting
virtual address 1234.

D/N:8 RO FFFFFFFF

Loads general registers
with -1.

D/N:200 - 0

Starting at previous address, clear
bytes.

If conflicting address space or data sizes are specified,
ignores the command and issues an error response.

3.6.5.4

physicE

through

the

conse:

EXAMINE-

EXAMINE [<qualifier list>]

[<address>]

Examines the contents of the specified address.
If no address
specified,
n+" is assumed.
The address may also be one of the symbo2-:'
addresses described under DEPOSIT.
Qualifiers:
The same qualifiers may be used on EXAMINE as may be used on DEPOSIT.
RESPONSE:

The address space identifier can be:

P
physical memory.
Note that when virtual memory
examined, the address space and address in the response are
translated physical address.
.

G - general register.

M - machine dependent (used only for display of the PSL) .

internal processor register.

Digital Equipment Corporation - Software Specification
SOFTWARE CAPABILITIES
3.6.5.5

FIND-

FIND [<qualifier list>]
The console searches main memory starting at address zero for
page-aligned 64 kilobyte segment of good memory, or a restart parame:.""
block (RPB).
If the segment or block is found, its address plus 512 :
left in SP.
If the segment or block is not found, an error message
issued, and the contents of SP are UNPREDICTABLE.
If no qualifier
specified, /RPB is assumed.
Qualifiers:
o

/MEMORY - search memory for a page aligned segment of ac~
memory,
64 kilobytes in length.
The search includes
read/write test of memory and leaves the contents of memc=
UNPREDICTABLE.

/RPB - search memory for a restart parameter block.
See
section 3.4 for the search algorithm. The search leaves
contents of memory unChanged.

3.6.5.6

INITIALIZE-

INITIALIZE
A processor initialization is performed.
set (all values are hexadecimal):
PSL
IPL
ASTLVL
SISR
ICCS
RXCS
TXCS
MAP EN

The

following

registers

041FOOOO
IF
4

a
o
o
80
o

All other registers are UNPREDICTABLE.
The previous console reference defaults (the defaults used to fill
unsupplied qualifiers for DEPOSIT and EXAMINE commands) are set t
physical address, longword size and address O.

3.6.5.7

HALT-

HALT
32

Digital Equipment Corporation - Software Specifica~~:
SOFTWARE CAPABILI~:~
The HALT command has no affect, the processor is already halted when
console I/O mode.
RESPONSE:

3.6.5.8

Already halted

REPEAT-

REPEAT <command>
The console repeatedly displays and executes the specified command. m~
repeating is stopped by the operator typing control-C. Any va:~
console command may be specified for the command with the exception c
the REPEAT command.
RESPONSE:

3.6.5.9

START-

START [<address>]
The console starts instruction execution at the specified address.
no address is given, the current PC is used.
If no qualifier ~
present, macroinstruction execution is started.
If memory mapping enabled, macroinstructions are executed from virtual memory. The STA?
command is equivalent to a DEPOSIT to PC, followed by a CONTINUE.
K
INITIALIZE is performed.

3.6.5.10

TEST-

TEST «test number>]
The console invokes a diagnostic test program denoted by <test
Valid test numbers are 3 through 7 and hexidecmal B.
See "KA630 ROM Diagnostic Specification" for information
tests and their corresponding test number codes.

3.6.5.11

UNJAM-

An I/O bus reset is performed.

__ ._.. -

.. ~---.--. . -.-~.~~-----------~-- ..

-.--..----.--.--.- , - - - - - - - - -

number>
diagnosti

Digital Equipment Corporation - Software Specification
SOFTWARE CAPABILITIES
3.6.5.12

Binary Load And Unload Command -

X <address> <count> <CR> <checksum>
The X command is for use by automatic systems communicating with _.console.
It is not intended for use by operators. The console loads ~
unloads (that is, writes to memory, or reads from memory) the spec':"::':"-=
number of data bytes, starting at the specified address.
If bit 31 of the count is clear, data is to be received by the consc:~
and deposited into memory.
If bit 31 of the count is set, data is ~c ~
read from memory and sent by the console.
The remaining bits in -count are a positive number indicating the number of bytes to lo:::.d ::
unload.
The console accepts the command upon receiving the carriage return.
next byte the console receives is the command checksum, which is
echoed.
The command checksum is verified by adding all cor.:.,:::.::-.
characters,
including the checksum, (but not including the termina~':"~
carriage return or rubouts or characters deleted by rubout), into a~
bit register initially set to zero.
If no errors occur, the resu:~ ~
zero. If the command checksum is correct, the console responds with ~~
input prompt and either sends data to the requester or prepares ~
receive data.
If the command checksum is in error t the console respc:,,_=
with an error message.
The intent is to prevent inadvertent opera~:
entry into a mode where the console is accepting characters from -keyboard as data, with no escape sequence possible.
If the command is a load (bit 31 of the count is clear), the cons~_
responds with the input prompt, then accepts the specified number ::
bytes of data for depositing to memory,
and an additional byte ~
received data checksum.
The data is verified by adding all da~
characters and the checksum character into an 8 bit register initia::
set to zero.
If the final contents of the register is non-zero, ~~
data or checksum are in error, and the console responds with an err:
message.
If the command is a binary unload (bit 31 of the count is set), -console responds with the input prompt, followed by the specified nU2~~
of bytes of binary data. As each byte is sent it is added to a check3~:
register initially set to zero. At the end of the transmission, the 2'
complement of the low byte of the register is sent.
If the data checksum is incorrect on a load, or if memory errors or "~
errors occur during the transmission of data, the entire transmission ~
completed, and then the console issues an error message.
If an errc
occurs during loading,
the contents of the memory being loaded ar
UNPREDICTABLE.
Echo is suppressed
checksums.

during

the

receiving

the

data

string

~ •.

Digital Equipment Corporation - Software Specificat~.
SOFTWARE CAPABILIT::
It is possible to control the console through the use of the consc~
control characters
(control-C, control-Sf control-O, etc.) durinc
binary unload.
It is not possible during a binary load, as all recei v,
characters are valid binary data.
Data being loaded with a binary load command must be received by t~
console at a rate of at least one byte per second. The command checks:
that precedes the data must be received by the console within 10 secon~
of the <CR> that terminates the command line. The data checksum must ~
received within 10 seconds of the last data byte.
If any of the~
timing requirements are not met the console aborts the transmission ~
issuing an error message and prompting for input.
The entire command, including the checksum, may be sent to the consc~
as a single burst of characters at the console's specified charactE
rate. The console is able to receive at least 4K bytes of data in
single 'X, command.

3.6.5.13

Comment-

! <comment>

The comment command is ignored.
command sequences.

3.6.6

It is

used

annotate

console

T
-I

Console Errors And Error Messages -

The console can issue error messages in
error messages are listed in table 5.
Table 5:

Console Error Messages

Code

Message

response

commands.

The~

Description

?15

CORRPTN

The
console
program
database
has
been
corrupted, the console program does a powerup
initialization to rebuild its database.

?16

ILL REF

The requested reference would violate virtual
memory protection, the address is not mapped,
the reference is invalid in the specified
address space, or the value is invalid in the
specified destination.

?17

ILL CMD

The command string cannot be parsed.

?18

INV DGT

A number has an invalid digit.
35

Digital Equipment Corporation - Software Specification
SOFTWARE CAPABILITIES
Table 5 (cont.)
Code

Message

Description

?19

LTL

The command was too large for the console ~2
buffer.
The message is issued only a~~e=
receipt of the terminating carriage return.

?lA

ILL ADR

The address specified falls outside the
of the address space.

?lB

VAL TOO LRG

The value specified
destination.

?lC

SW CONF

For example, two different data
specified with an EXAMINE command.

?lD

UNK SW

The switch is unrecognized.

?lE

UNK SYM

The symbolic address in an EXAMINE
is unrecognized.

?IF

CHKSM

The command or data checksum of an X command is
incorrect.
If the data checksum is incorrec~,
this message is issued, and is not abbreviated
to "Illegal command".

?20

HLTED

The operator entered a HALT command.

?21

FND ERR

A FIND command failed either to find the RPB '"'v_
64 kb of good memory.

722

TMOUT

During an X command, data failed to arrive
the time expected.

?23

MEM ERR

Parity error detected.

does

not

fit

limi~s

in
sizes

are

DEPOSIT

"'l

......

"':"'_-L

Some console commands may result in errors. For example,
if a meIT;8r:
error occurs as the result of a console command, the console w~:
respond with an error message.

3.6.7

Halts And Halt Messages -

Whenever the processor halts, the console
<PC>", For example:
?06 HLT INST
PC = B00050D3
36

prints

the

response

"PC

Digital Equipment Corporation - Software Specifica~~:
SOFTWARE C~~ABIL:~:~
The number preceding the halt message is the halt code, and is passed ~
the operating system on a restart. The halt messages are shown in tab:
6.
Table 6:

KA630 Halt Messages

Code

Message

Description

?02

EXT HLT

BREAK was typed on
QBHALT was asserted.

?04

ISP ERR

In attempting to push state onto the interrupt
stack during an interrupt or exception, the
processor discovered that the interrupt stack
was mapped NO ACCESS or NOT VALID.

?OS

DBL ERR

The processor attempted to report a machine
check to the operating system,
and a second
machine check occurred.

?06

HLT INST

The processor
kernel mode.

?07

SCB ERR3

The vector had bits <1:0> equal to 3.

?08

SCB ERR2

The vector had bits <1:0> equal to 2.

?OA

CHM FR ISTK

A change mode instruction
PSL<IS> was set.

?OB

CHM TO ISTK

The exception vector for a change mode had bit
<0> set.

?OC

SCB RD ERR

A
hard
memory
error occurred while the
processor was trying to read an exception or
interrupt vector.

?10

MCHK AV

An access violation or an invalid translation
occured
during
machine
check
exception
processing.

?11

KSP AV

An access violation or an invalid translation
occured during processing of of an invalid
kernel stack pointer exception.

3.7

the

executed

console,

QBINIT

a HALT instruction

c::-

~r:

was executed wher:

Program I/O Mode (System Running)

When the processor is not executing instructions from
program ROM,
it is in "program I/O mode" in which
37

the consol·
all termina.

Digital Equipment Corporation - Software Specification
SOFTWARE CAPABILITIES
interaction is handled by the operating system. In program I/O modE
the console terminal behaves like any other operating system termina~
If halts are enabled, BRE;
If halts are disabled, BREAK is ignored.
causes the processor to "halt", that is the KA630 enters console I,
mode.

PUBLICATIONS

tbd

PACKAGING

NOT APPLICABLE - This product resides in ROM and is shipped as
the processor board.

part

INSTALLABILITY

NOT APPLICABLE - This product resides in ROM and is shipped as
the processor board.

part

EASE OF USE

The users of the KA630 console program include
many
who
ar
sophisticated in their use and understanding of computers. These user
are Engineering, Manufacturing and Field Service personnel as well a
many customers. These users are not intimidated by the console cornman
language and its messages nor by the messages generated by the consol
diagnostics. The relative complexity of these components of the consol
system are perceived as worth the diagnostic power that they provide
It is for these users that these features are provided.
Indeed thes
features have evolved over time to satisfy these users and therefore
for this user group, the KA630 console program is regarded as "easy t
use".
Another class of users however are those users who know little abou
computers and who may be intimidated by them. These users would like t
simply flip a switch and know that the computer will turn on and the
can proceed with their work. These users are not expected to use th
console command language, nor are they expected to understand an
diagnostic messages.
If a KA630 is to be used by a user from the latter group, halts must b
disabled, the appropriate bootstrap device configured, and the prope
baud rate must be set.
Establishing this configuration for th
unsophisticated user may be done in manufacturing (the preferre
38

Digital Equipment Corporation - Software Specificatic
EASE OF tIE
approach), by Field Service personnel, by a sophisticated user, or by c
unsophisticated
user
following
a
well designed and document~
installation procedure.
Once properly configured, assuming no hardware problems are detected
the diagnostics on power up,
figure 9 shows what the user will se
displayed.
Figure 9:

Console Display on Successful Power-Up

KA630.xx
Performing normal system tests.
7 •• 6 •• 5 •• 4 •• 3 ••

Tests completed.
Loading system software.
2 .. 1 .• 0

<Operating system specific output>
The first line identifies the processor and the version number
(xx)
c
the console program ROM.
The next line explains that the system '
performing NORMAL tests.
The count-down sequence reassures the use
that the system is progressing through its tests, that the system hasn'
"gone away", and documents which tests are executed.
When diagnosti-::·
are completed, the console notifies the user that the diagnostic
sucessfully completed. The "Loading system software." message indicate
the beginning of the bootstrap sequence.
The execution of the bootstra
sequence causes the remaining digits of the countdown to be displayec
Because successful completion of a bootstrap occurs in the context c
the operating system bootstrapped, a confirming message indicating tha
the system startup has completed can only be issued by the bootstrappe
operating system.
Figure 10 shows the display generated if any hard
during any test (test 7 for example) .

errors

are

detecte·

Digital Equipment Corporation - Software Specification
EASE OF USE
Figure 10:

Console Display on Power-Up with Hard Errors

KA630.xx
Performing normal system tests.
7 ..

?<subtest> <pI> <p2> <p3>
Failure.
Normal operation not possible.
In the case of fatal problems detected by the diagnostics, the count~=~
sequence is interrupted and a diagnostic message is displayed.
diagnostic message is composed of a question mark l a subtest code n~~=~
and up to three parameters for use by diagnostic personel. More ~~=
one such error message is possible but unlikely.
The summary mess~;
which follows indicates that the test failed and that normal operG~~:
is not possible. The console program then hangs.

PERFORMANCE

All diagnostic checks will be performed in less than tbd.
Diagncs~~
coverage of the processor itself will be tbd percent;-Coverage of ~~
memory system will be tbd percent, and coverage of the Q22-bus map ~~_
be tbd.
----The console responds to all commands within 1 second.
When the console power-up display is displayed, no more than 5 secc~~
shall pass without some output to the screen (additional periods ma~- t
displayed during the c6untdown if necessary) .

RELIABILITY

~ ....
Errors detected by this program are classified as user errors, ---::::.errors, or catastrophic errors.
User errors are errors arising
invalid input from the user. All user errors are diagnosed and the
is notified by a diagnostic message on the console terminal. All
errors are recoverable.

Hard

errors

are errors detected
by
the
program
which
w~i~~
do not prevent the continuation of the program.
~:
example of a hard error is the detection of an unexpected non-existe~
memory error when in console I/O mode. The console program notifies ~n"
user of all hard errors with a diagnostic message on the console.
unrecoverable,

Digital Equipment Corporation - Software

Specifica~~:

RELIAE::"::
Catastrophic errors are errors of such a severe magnitude that ~~
program cannot continue, When a catastrophic error is detected, -program attempts to display an error message on the console term~::a::'
Following that, the processor goes into a infinite loop at IPL 31 (t~e=
is no halt state for MicroVAX). An example of a catastrophic error ~
when the console program is unable to locate any working memory.
It is possible to bypass all diagnostic tasks.
This may done enabling halts and by manually halting the processor following power-~
or reset.
The diagnostics will be halted and the processor will e::~2
console 1/0 mode. This option allows a field service engineer to by;~s
a failing test and enter console I/O mode where the console commands =3.
be used to further diagnose the problem.
As part of each diagnostic subtest, a test code is displayed on -console and on the LEDs, making it possible to monitor the progress :
the diagnostics.
The two display mechanisms use unrelated lo;~:
providing a high probability that at least one will be operative.
T~
hard error is detected by a test, a diagnostic message is displayed the console.
If a catastrophic error occurs, it may not be possible ~
display a diagnostic message on the console but the most recent ~es
code will be left in the LEDs.

MAINTAINABILITY

The console program is located in two socketed
processor.
If necessary, they can be replaced.
of maintenance possible.

ROM's

the

K~62

This is the only

::::)=:

The console program displays the version number of the console pro;r3.,
ROM when the power up messages are displayed. This can be used, easily determine which version of the console program is present.
Upon completion of development, the source .£9.EY of the
will be preserved for ECO purposes £y the VMS group.

progr3.:.

MAINTENANCE

The console program is located in two socketed
processor.
If necessary, they can be replaced.
of maintenance possible.

console

COMPATIBILITY

ROM'S on the K?_63
This is the only for'

Digital Equipment Corporation - Software Specification
COMPATIBILITY
12.1

Product Compatibility

This program is a new product developed for the first time for -KA630.
Even though other MicroVAX based processors might be able ~
utilize parts of this product, no effort is planned to facilitate S~:
sharing beyond that which arises naturally from sound modular design.

12.2

Standards Conformance

Although not required, the command language accepted by the console
intended to be as compatible as possible with that defined in
Standard 32. However, the following significant console features
defined in the standard but omitted by the KA630 console program:
o

MICROSTEP command - not supported by the MicroVAX chip.

LOAD command - no console storage device is supported.

SET command - no set options are defined.

NEXT command - not supported by the MicroVAX chip.

@ command - no console storage device is supported.

The console program recognizes terminal device attributes
device attribute responses registered in DEC Standard 138.

based

Escape sequence parsing (used to identify terminals and to cause c_
escape sequences to act as line terminators) is based on the algorit~~
defined in the "Video System Standards Reference Manual".

12.3

Internationalization

All console program message texts are either multilingual or lang~cg
independent.
The message texts displayed on power-up (shown in fig~=e
9 and 10) are multilingual. All other texts are language independe~~
they incorporate short language insensitive abreviations rather tha:
readable sentences. Depending on the user preference, the message te~~_
are output in either English, French, German r Italian, Portuguese
Spanish, Dutch, Danish, Finnish, Norwegian or Swedish.
Numeric status displays on the processor LEDs facilitate
of failing processors in a language independent manner.

the

The operation of the console is independent of the user's
or frequency_

line

diagnos~_

voltaq-

Digital Equipment Corporation - Software

Specifica~~:

COMPJ._TI3:::.o:-:
The console supports the Digital Multinational Character Set
(}~CS
This support extends to displaying foreign language messages with ~·!c.:
accepting and echoing MCS characters and accepting a device attribu't:'::
report
(the console queries the terminal to determine if it is a CRT::
not) using the Cl control characters of MCS.
However,
all consc~
commands must be entered using the ANSI subset.
If the terminal does not support MCS, the console uses
texts.

English

messa=

The console program uses four characters that are national replace~e~
characters, the caret
(A),
the backslash (\) and the right and 1e=
square brackets ([,). The caret is used by the console to de~c~
control characters.
The backslash is used to delimit text deletic~
when editing console input. The square brackets are used to de~c~
directory specifications when the user directs the bootstrap to soli=~
a secondary bootstrap file name.
No provision is made for termi~a:
which replace any of these characters.

EVOLVABILITY

Because the console program is in ROM and cannot be easily chan'ge:'
there is little likelihood of significant evolution over its lifeti!!le
An exception is support for additional bootstrap devices.
Support for new types of disk and tape units is provided not by
console program itself but by the console's support for MSCP and T:~S::
disks and tapes. Any new disk or tape supported by the MSCP and
controllers will be supported by the console program.
-;::,Another possible need is support for a new Ethernet controller. Any -<
controller compatible with the old will be supported. Any new a::
incompatible controller could not be supported except by an ECO of console ROM.
~

The console terminal recognition code relies on compliance with D:::
video terminal architecture standards to insure proper recognition 0
future terminals.

COSTS

NOT APPLICABLE

TIMELINESS

This product must be available for the first release of
processor which is gated by availability of this product.
43

the

KA63

Digital Equipment Corporation - Software Specification
TIMELINESS
In order to insu're that this goal is met, every effort will be made
minimize the interdependence of the KA630 development project_.
others. For this reason, the KA630 development group will maln~a_
complete responsibility for the entry/dispatch code and the diagnos~:
code. These sections are very processor implementation specific and
done outside the group, schedule risk would be raised.
The command language interpreter is less implementation specific ~.
because it will be needed early in the development phase of the K;E~
it will be done within the development group as well.
The restart code will be done by the KA630 development group as well :::-_
the bootstrap code will be written by the VMS development group.
"..,--,
the VMS supplied code will be available on schedule is insured by
fact that the code is essentially the same as that in SEAHORSE, w~~_
will be completed previously.

CONSTRAINTS AND TRADEOFFS

The following list reflects the priority ordering of the goals for
product (1 is highest):
1.

Time to market - must be available for the KA630 first

Reliability - cost of field
errors should ship.

repairs

Bootstraps supported (DECNET) .

support

RQDXl

disks

Diagnostic coverage - within available
coverage should be maximized.

ROM

space,

Memory consumption - ROM is available in 16, 32 and 64 _
amounts.
The console program should attempt to meet its goa:
within 32 Kb.

Support of QxSS based bitmapped terminals.

Console I/O language complexity
reduction
of
comrr.a,_
verbosity and editing capabilities will be considered to rr,e""
space and schedule goals.

must

If necessary, to meet the highest priority goals
will be compromised.

high,

lower

releas~

therefore,
and

n-,-....- ..

J...}.:..~_

diagnos~:'

priority

gca~

APPENDIX A
INTERPRETATION OF KA630 LED AND CONSOLE DISPLAY CODES

There are four red LEDs on the KA630 (echoed off the processor board _
well) .
These four LEDs, interpreted as a four bit hexadecimal digi~
have the meanings described in table A-l. All LED codes are displaYE
during power-up.
A problem is indicated only if the LED code i
continuously displayed.
Each LED is illuminated if its control bit in the boot and
register (BDR) is one and is dark if its control bit is zero.

diagnos~i

It is possible for privileged code to output to the LEDs when
processor is in program mode.
Because this may cause confusion in
interpretation of the LEDs, this use of the LEDs in program mode
discouraged.
When executing the power-up sequence, the codes f9' through
output to the console terminal.
See figures 9 and 10.
Table A-I:

'a' are a~E

KA630 LED Interpretation

Code

Activity

Exit Criteria

Electrical power-up.

MicroVAX starts execution from
console program ROM.

Wait for PWR-OK.

BDR<15> set.

Perform ROM checksum and TOY
tests. (1)

Test success.

Initialize
memory.

Console memory and bitmap initialized, registers saved.

Run IPCR tests.

Test for and check out QxSS
video
console
display
if
present. (1)

RAM

console

program

(1)

Test success.
QxSS
operational
present.

not

A-l

~ -----.----~-------.------

------------------------------------

INTERPRETATION OF KA630 LED AND CONSOLE DISPLAY CODES

Table A-I (cont.)
Exit Criteria

Code

Activity

Perform console port tests and
terminal identification. (1)

Console
determined.

Query console language
(1),
then enter console
command
mode.

Exits
automatically
power-up, otherwise exits C~
console CONTINUE, START,
BOe-:::or TEST command.

Run memory pattern tests.

(2)

At least 64 kb of
good memory found.

Run memory address tests.

(1)

All address tests passed.

Run I/O map tests.

Run CPU tests.

Run Interrupt tests.

Search for

(1)

terminal

contiguc~5

Test success.

(1)

Test success.
(I)

bootstrap

Test success.

device.

(3 )

(3)

Valid bootstrap device
ed.

Load bootstrap.

Program mode.

(1)

Performed only on power-up entry into console program.

(2)

Performed on
bootstrap.

(3)

Performed only during bootstrap.

loca~

Bootstrap successfully loadec.
Not applicable.

power-up

entry

A-2

and

operator

requeste:i

APPENDIX B
SUMMARY OF 1/0 REGISTERS USED BY CONSOLE PROGRAM

E.1

BOOT AND DIAGNOSTIC CONFIGURATION REGISTER (BDR)

The BDR register is used to read the values of the KA630
switches and to output to the processor LED display.
15

configura~~:

+---+---+---+-------+-------+-----------------------+-----------+
IPWRIHLTI
I OK ! ENE I

I
I

CPU

I
I

BDG

I
I

DSPL

+---+---+---+-------+-------+-----------------------+-----------+
Boot and Diagnostic Register
Hex addr: 20080000 (hex)

BDR<15>

PWR OK

Power OK - set when power is stable.

BDR<14>

HLT ENB

Halt enable - A read only bit that enable
recognition of the BHALT(L) bus signal as a h~l
condition and enables recognition of a BR~~
condition from the console terminal as a h~l
condition. If not set, neither condition W l ;
result in a processor halt. This bit is set £
a switch external to the KA630.
If CPMBX<1:0> is zero, this bit also contrJl
the actions of the console program in respo~s.
to any halt condition.
If set the consol
program will enter console I/O mode followi~
any halt.
If not set the console program wil
attempt to restart the processor and if tha
fails, it will attempt to reboot the processor.
If that fails as well, the console program wil
then enter console I/O mode. If CPMBX<1:0> i
non-zero, the console program uses that field t
determine its actions on processor halt.
B-1

SUMMARY OF I/O REGISTERS USED BY CONSOLE PROGRAM
BOOT AND DIAGNOSTIC CONFIGURATION REGISTER (BDR)
BDR<12:11>

CPU

CPU designation

Arbiter CPU
Auxiliary CPU number 1
Auxiliary CPU number 2
Auxiliary CPU number 3

2
3

BDR<10:9>

MODE

Power-up mode control bits.
These two bits a:
combined with the liLT ENB to generate a th~~
bit power-up mode field.
The interpretation ~
this three bit field is given in table 1.

BDR<3: 0>

DSPL

-,
LED display bits - these write-only bits c._
used to load the LED status display. A t~
value of one causes the associated LED to
illuminated,
a bit value of zero causes the ~~
to be dark.

B.2

TIME OF YEAR (TOY) CLOCK REGISTERS

The TOY registers contain the time of year clock registers as well as =
bytes of battery backed-up RAM.
The console program references ~~
clock registers only to check for battery backup failure.
See-KA630-A Processor Specification for information on the TOY cle:::.
registers.
The console program reserves all of the RAM registe~~
There are a total of 64 eight bit registers, word aligned.
They may t
accessed either as bytes or as words.
When accessed as words, bi~
<15:8> are ignored on writes and return zeros on reads.
The bas
address of the TOY registers is 200B8000 (hex).

B.2.1

Console Program Mailbox (CPMBX)

The console program and the operating system communicate with each ot~e
via this register.
15

+-------------------------------+---------------+---+---+-------+
I
I

I
I

LNG

IRIP!BIPI
!
I
I

liLT
ACT

I
!

+-------------------------------+---------------+---+---+-------+
Console Program Mailbox Register (CPMBX)
TOY register 14, Hex addr: 200B801C
CPl-ffiX<7 : 4>

LNG

Console

Message
B-2

Text

Language.

This

fiel

SUMMARY OF I/O REGISTERS USED BY CONSOLE PRO,::;:?_:
TIME OF YEAR (TOY) CLOCK REGIST~:
controls the output of message texts to -.
console terminal.
If the field is set to ze~=
the console program will prompt the user to s~
this field on power up.
0
1

2
3

4
5

Prompt for language.
German
English
Spanish
French
Italian

6
7

8
9

Danish
Dutch
Finnish
Norwegian
Swedish

Portuguese

CPMBX<3>

RIP

If set, a restart attempt is in progress.
Tc
flag must be cleared by the operating syste~
the restart succeeds.

CPMBX<2>

BIP

If set, a bootstrap attempt is
This flag must be cleared by
system if the bootstrap succeeds.

CPMBX<1:0>

HLT ACT

Processor halt action - this field is used control
the
automatic
restart/bootst~~
procedure. This mailbox allows operating sys~e
software to override the BDR HLT ENB fie:t
Both bits are cleared on power up and when tt
console program exits.

o
1
2
3

B.3

in progres5
the ope ra-:.':" !"_

Use HLT ENB
(BDR<14»
to
action.
Restart! if that fails, halt.
Reboot, if that fails, halt.
Halt.

deterrr':"~

SYSTEM IDENTIFICATION EXTENSION REGISTER (SIDEX)

Any MicroVAX based system must implement a longword at physical locatic
20040004
(hex) to distinguish it from other MicroVAX based system. T~
MicroVAX implements the system identification IPR but this register onl
identifies the processor implementation, not the system itself. Thi
longword exists in the physical address range of the KA630-A consol
program ROM.

B-3

SUMMARY OF Ilo REGISTERS USED BY CONSOLE PROGRAM
SYSTEM IDENTIFICATION EXTENSION REGISTER (SIDEX)

2 2
4 3

3
1

1 1

6 5

+---------------+---------------+-------------------------------I

SYSCODE

VERSION

reserved

+---------------+---------------+--------------------- ----------~

System Identification Extension {SIDEX)
SIDEX<3l:24>

SYSCODE

System code.

SIDEX<23:l6>

VERSION

Version number of console program ROM.

SIDEX<15:0>

B.4

This field is 1 for the KA630-J._.

Reserved.

CONSOLE TERMINAL REGISTERS

The console program accesses the console terminal through four inte~~~
processor registers,
the Console Receive Control and Status Regis~~
(RXCS) , the Console Receive Data Buffer Register
(RXDB) ,
the Cons:)':'
Transmit Control and Status Register (TXCS), and the Console TransI~
Data Buffer Register (TXDB). See the KA630-A Processor Specifica~i:
for their definition.

B.5

INTERPROCESSOR COMMUNICATION REGISTER (IPCR)

The IPCR register is used to support communication between arbiter a~
auxiliary processors.
It controls the visibility of auxiliary memory c
the Q-22 bus, it allows an auxiliary processor to be halted by anot~e
processor,
and it provides for an interprocessor interrupt capabili~:
The location of the IPCR in the Q-22 bus address range depends on ~~
CPU identification code of the processor.

B-4

SUMMARY OF I/O REGISTERS USED BY CONSOLE PROG~
INTERPROCESSOR COMMUNICATION REGISTER (IPC~

+---+-----------------------+---+---+---+---+---------------+---+
I DMA!
I QPE I

I AUX I
I HLT I

I IE I LM I
I
I EAE I

I IRQ I
I
I

+---+-----------------------+---+---+---+---+---------------+---+
Interprocessor Communication Register

Hex address:

20001F40
20001F42
20001F44
20001F46

Arbiter
Auxiliary #1
Auxiliary #2
Auxiliary #3

ICR<15>

DMA QPE

DMA Q-22 address space parity error.

ICR<8>

AUX HLT

Auxiliary halt. A read/write bit which when SE
on
an
auxiliary processor,
it causes tt
processor to halt. This bit has no effect i
the auxiliary is in console I/O mode and i
ignored all together by arbiter processors
This bit is always cleared upon entry int
console I/O mode.
It is also used by auxiliar
processors as part of its bootstrap process (se
section 3.5.1.7).

ICR<6>

Interrupt enable.
If set, an interrupt will t
generated if IPCR<O> is set.
To the loca
processor this is a read/write bit. To ext erne
processors this is a read only bit.

ICR<5>

LM EAE

Local memory external access enable. When thi
bit is set, local memory can be accessed via th"
Q-22 bus map. To the local processor this is
read/write bit.
To external processors this i
a read only bit.

ICR<O>

IRQ

Interrupt request.
When set,
a
processo
interrupt is requested. This bit is enabled bICR<6>. If ICR<6> is not set, writes to thi
bit are ignored and the bit is not set.

This ree
only bit is set whenever a parity error i
CPU
or
devic
detected when an external
(Not used by tr.
references KA630 local memory.
console program) .

B-5

APPENDIX C
QXSS AND APT

When a KA630 system powers up for the first time it determines WL~
console device is present.
If the console device is a QxSS v~=~
However,
during manufacturi~:
display, it uses it as the console.
systems are tested by APT which relies on the console program using -~
console port rather than the QxSS.
To continue to support APT testing, the KA630 console program allows ~~
to force the console program to revert to using the console port inste~.
of the QxSS. To do this, APT must wait until the system has comple~~
its power-up.
APT then asserts break and the system halts. When t~
console program halts, it checks for the existance of a break condit~:
on the console port. If break is being asserted, the console progr=
resets itself to assume that the console port is connected to a hardcc;
terminal and the console language is English. APT can now use ~~
system normally.
Once this is done, there is no way short of powering the system off a~
turning it back on again to cause the console program to resume use c
the QxSS as the console display device.

C-l

APPENDIX D
OUTSTANDING ISSUES

Section 1, page 1 - QVSS support needs to be further def:'nE i
within this specification.
The intent to support is defin~
but the exact definition of that support is TBS.
This
important as QVSS is considerably more complicated to sup;:c::
than a console terminal.

Section 3.5.1.1, page 16
descriptions
are
needed,
designations, etc.

More details on MAYA and Q:
planned controller names, ~n~

Section 4, page
section?

should

Section 8, page
diagnostics.

Section 10, page 41 - Need agreement from VMS that they Wl_
take the console program sources as part of VMS source kit.

What
40

Need

performance

[End of file]
D-1

.-~---.----~~-~-----.----

...- ..

~----.----

..----.-.--.----_._._.

__ __ _ - - - - - - - - _.._- - - - .
.

•..

the

publicatic~.

indications

---

-----_._._-----_._-------_._--