Digital PDFs

XX-EEF70-73

2000

405 pages

Original

15MB

Document:	OEM MicroNotes
Order Number:	XX-EEF70-73
Revision:
Pages:	405
Original Filename:	oemMicronotes.pdf

OCR Text

OEM MICRONOTES

mamDDma

mamaala

Enclosed is the new set of MicroNotes.
This set consists of
twenty-one
new documents relating to some of the latest
component products from Digital.
The original set of 111 MicroNotes has been superseded by this
new edition.
The titles in the original set can be found in
Appendix A of the enclosed document.
The original MicroNotes
(if- you do not have them) can still be obtained by wri ting to
the OEM Technical Support Group at:
OEM Micros Technical Support Group
Digital Equipment Corporation
2 Iron Way MR03-3/G20
Marlboro, MA
01752
Attn: Cindy Dorval
Be sure to ask for the original MicroNotes.
If there is someone you know that would like to be added to the
MicroNote Distribution List have them fill out the enclosed
MicroNote Reservation Form and return it to the address listed
above.
The group would appreciate any feedback or suggestions on future
MicroNotes these comments can also directed to the above
address.

Sincerely,

OEM Micros Technical Support Group

DIGITAL EQUIPMENT CORPORATION, TWO IRON WAY, BOX 1003, MARLBORO, MASSACHUSETIS, 01752
(617) 467·5111

Digital Equipment Corporation
.
Two Iron Way
Box 1003
Marlboro, Massachusetts 01752-9103
617.467.5111

Your name is on our mailing list. Enclosed is an updated set
of MicroNotes which consists of the twenty-one previously
published documents plus
twenty
NEW
MicroNotes.
The
information contained in this set relates to some of the
latest component and small system products from Digital.
If someone would like to be added
to
the
MicroNote
Distribution List, have them fill out the enclosed MicroNote
Reservation Form and return it to the address listed below;
attention Cindy Dorval.
This form can also be used to make
address corrections, noting the date your location changed.
The group would appreciate any feedback or suggestions for
future MicroNotes. These comments can also be directed to the
address below.
Thank you for your continuing interest.
OEM Technical Support Group
Digital Equipment Corporation
2 Iron Way (MR03-3/G20)
Marlboro, MA. 01752-9103

MicroNote Reservation Form
_______

~------------------- _ _ _ _ _ _ I _ _ _ _ _ _ - - - - - - - - - - - - - - _ _ _ _ _ _ _ _ _

Please fill out this form and return it to:
OEM Micros Technical Support Group
Digital Equipment Corporation
2 Iron Way MR03-3/G20
Marlboro, MA 0172
Attn: Cindy Dorval
This will add you to the
MicroNote
Di~tribution
List.
MicroNotes are short technical articles written about Digital's
component level products.
Product
highlights,
technical
descriptions, technical hints-and-kinks not found in the regular
documentation, and recent product changes and announcements are
discussed in the MicroNotes.
Name:
Company:
Title:
Address:
City:
Zip:

State:

Questionnaire
1.

I am:
o
o
o
o

an OEM
a Distributor
an End-User
Other

2.
The Industry I Service
Instrumentation, Education):

(e.g.

Medical,

3.
The Application(s)
within that Industry is/are
machine control, IC testers, general purpose computing):

I'd like future MicroNotes to Discuss:

Control,

(e.g.

TABLE OF CONTENTS

uNOTE NO.

TITLE

DATE

PAGE NO.

001

MUL, DIV, & ASH Instruction for the
FALCON and the FALCON-PLUS

13-Apr-82

002

Block Mode DMA

01-Jun-83

003

Compatible Bootstrap for the LSI-11/73

28-Nov-83

004

LSI-11/73 Upgrade Paths

28-Nov-83

005

Q22 Compatible Options

23-Apr-84

006

Differences Between the LSI-ll/73
and LSI-11/23

23-Apr-84

007

User Defined Memory Maps for the FALCON
and the FALCON-PLUS

01-May-84

008

Memory Management and the LSI-l1/73

22-Jun-84

009

Cache Concepts and the LSI-l1/73

02-Jul-84

010

MicroVAX I/O Programming

27-Jul-84

011

LSI-11/73 Advanced Memory Management

04-0ct-84

012

OMA on the Q-bus

09-0ct-84

013

Run-time System Performance Evaluation
Using MicroPower/Pascal V 1.5

09-0ct-84

101

014

Using Fortran Routines In A
VAXELN/pascal Environment

16-0ct-84

107

015

Q-bus Hardware Bootstrap

16-0ct-84

111

016

KXTI1-CA Software Development Tools

16-0ct-84

115

017

LSI-11/23 ECO History

19-Nov-84

123

018

Programming the KXTII-CA DM.~ Controller

28-Dec-84

131

019

Disabling RAM on the MXV11-iBF

10-Jan-85

155

uNOTE NO.

DATE

TITLE

PAGE NO.

020

Differences between the Mxv11-A
and MXV11-B

10-Jan-85

159

021

Floating Point Consideration
on MicroVAX I

10-Jan-85

161

022

Differences Between the MicroVAX I and
MicroVAX II CPUs

28-Apr-85

163

023

MicroVAX I to MicroVAX II Upgrade Issues

28-Apr-85

177

024

MicroVAX Instruction Set Differences

28-Apr-85

183

025

FPJ11-AA Compatibility with the
LSI-11/73 (KDJ11-A)

28-Jun-85

195

026

The MicroVAX Multicomputing Capability

28-Jun-85

197

027

Using Messages with VAXELN

28-Jun-85

211

028

MSV11-Q/M/J Memory Comparisons

28-Jun-85

217

029

Q-bus Expansion Concepts

28-Jun-85

221

030

The Private Memory Interconnect between
the KDJ11-B and the MSV11-J

28-Jun-85

227

031

MSV11-QA Revision Differences

28-Jun-85

237

032

KXT11-C Parallel I/O Programming

28-Jun-85

247

033

System Configuration of DL-type Devices

28-Jun-85

289

034

Programming the KXT11-C Multiprotocal SLU

19-Jul-85

303

035

Backplane Expansion/Termination

19-Jul-85

327

036

MicroVMS Revealed

19-Jul-85

335

037

In Search of NanoVMS

19-Jul-85

361

038

DECnet Downline Loading

26-Jul-85

369

039

Differences between KDJ11-A and KDJ11-B

08-Aug-85

379

040

FPJ11 Theory of Operation

17-Sep-85

385

041

Device Ordering Chart for Q-bus Systems

17-Sep-85

389

APPENDIX A
ORIGINAL MICRONOTES - TABLE OF CONTENTS

APPENDIX B
SUBJECT INDEX

III

·I

uNOTE # 001

Title: MUL,DIV and ASH Instruction for the FALCON
and the FALCON-PLUS

Date: 13-APR-82

Originator: Charlie Giorgetti

Page 1 of 4

There is no hardware support for the EIS, FIS, or FPP instruction sets.
For FALCON SBC-ll/21 applications that need the ability to perform the
EIS instructions MUL, DIV, and ASH, equivalent software routines can be
substituted. These callable routines do not do any form of error
checking.
A user should be aWarE! that extensive use of these software
routines for hardware instructi()ns will have
impact
on
system
performance. These routines can bE! incorporated into an application and
called as a subroutine. The calling sequence for the subroutines can be
set-up in a macro. The followin9 is a list of each of the subroutines
and the macros that are used to set-up and call the software MUL, DIV,
and ASH routines.

uNOTE # 001
Page 2 of 4
The following macro and subroutine can be
instruction in software:
• MACRO

SMUL

MOV
MOV
JSR
MOV

A,-(SP)
B,-(SP)
PC,$MUL
(SP)+,HI

MOV

(SP)+,LO

used

perform

the

MUL

A,B,HI,LO
Push a multiplier onto the stack
Push the other multiplier as well
Call the MUL subroutine
Get the most significant part of
the result
Get the least significant part of
the result

.ENDM
$MUL: : MOV
MOV
MOV
MOV
CLR
10$: ROR
ROR
BCC
ADD
CLC
20$: DEC
BNE
TST
MOV
MOV
MOV
MOV
RTS

RO,-(SP)
R1,-(SP)
10(SP),R1
#21,-(SP)
RO
RO
Rl
20$
10(SP),RO

Save some work registers
Obtain the value of A from the stack
Initialize the shift counter
; Initialize the high 16-bit accumulator
Perform multiplication

(SP)
10$
(SP)+
R1,10(SP)
RO,6(SP)
(SP)+,Rl
(SP)+,RO
PC

Bump the shift counter
Not done ?
Romove the counter from the stack
Save the low 16-bit value on the stack
Save the high 16-bit value on the stack
Restore the work registers
Return

uNOTE # 001
page 3 of 4
The following macro and subroutine can be
instruction in software:

used

perform

the

DIVSOR,DIVHI,DIVLO,REM,QUO

.MACRO

SDIV

MOV
MOV
MOV
JSR
MOV
MOV

DIVSOR,-(SP);
DIVHI ,-( SP) i
DIVLO ;-( SP) i
PC,$DIV
;
(SP)+,REM
(SP)+,QUO

Push the divisor onto the stack
Push the upper 16-bits of the dividend
Push the lower 16-bits of the dividend
Call the DIV subroutine
Get the remainder
Get the quotient

.ENDM
$DIV:: MOV
MOV
MOV
MOV
MOV
MOV
MOV
CLR
MOV
1$: ASL
ROL
ROL
CMP
BLO
SUB
I~C

2$: DEC
BNE
TST
MOV
MOV
MOV
MOV
MOV
MOV
MOV
RTS

DIV

.RS ,-(SP)
R4,-(SP)
R3,-(SP)
RO,-(SP)
14.(SP),R3
12.(SP),R4
10. (SP) , RS
RO
#32.,-(SP)
RS
R4
RO
RO,R3
2$
R3,RO
RS
(SP)
1$
(SP)+
RO,12.(SP)
RS,14.(SP)
(SP)+,RO
(SP)+,R3
(SP)+,R4
(SP)+,RS
(SP)+,(SP)
PC

; Get some work registers

Get the divisor from the stack
i Get the high 16-bits of the dividend

as well as low 16-bits
i Clear an accumulator

; Shi :Et counte r
Perform the division

Not done ?
; Remove the counter from the stack
Store the remainder on the stack
; store the quotient as well
Restore the work registers

Update the return PC
Return

uNOTE .# 001
Page 4 of 4
The following macro and subroutine can be
instruction in software:

used

perform

. MACRO

SASH

MOV
MOV
JSR
MOV

COUNT,-(SP) ; Push the shift count
Push what is to be shifted
VAL,-(SP)
Call the ASH subroutine
PC,$ASH
Get the results of the shift
(SP)+,VAL

the

COUNT,VAL

.ENDM
$SASH: : MOV
MOV
MOV
MOV
BIC
BEQ
CMP
BGT
5$: ASL
DEC
BNE
BR
10$: NEG
BIC
11$: ASR
DEC
BNE
20$: MOV
MOV
MOV
MOV
RTS
~

RO,-(SP)
R1,-(SP)
6(SP),RO
8.(SP),R1
#"C<77>,R1
20$
R1,#31.
10$
RO
R1
5$
20$
R1
#"C<77>,R1
RO
R1
11$
RO,8.(SP)
(SP)+,R1
(SP)+,RO
(SP)+,(SP)
PC

Get a couple of work registers
RO - value to be shifted
R1 - direction and shift count
Get out if no shifting
; What direction is the shift
go to the corection direction shift

Store the shifted result on the stack
Restore the work registers
update the return PC
Return

ASH

uNOTE # 002

Title: Block Mode DMA

Date: 01-JUN-83

Originator: Scott Tincher and Mike Collins

Page 1 of 20

What is Block Mode DMA?
Block Mode DMA is a method of data transfer which increases throughput
due to the reduced handshaking necessary over the Q-bus.
In order to
implement Block Mode DMA both the master and slave devices must
understand the block Mode protocol.
If either device does not have
Block Mode capability the transfers proceed via standard DATI or DATO
cycles.
Conventional Direct Memory Access on the Q-bus
Under conventional DMA operations, after a DMA device has become bus
master, it begins the data transfers. This is accomplished by gating an
address onto the bus followed by the data being transferred to or from
the memory device.
If more than one transfer is performed by the
temporary bus master, the address portiort of the cycle must be repeated
for each data transfer.
Block Mode Direct Memory Access on the Q-bus
Under block Mode DMA operations an address cycle is followed by multiple
word transfers to sequential addresses. Therefore data throughput is
increased due to the elimination of the address portion of each transfer
after the initial transfer.

uNOTE :1 002
Page 2 of 20

There are two types of block Mode transfer, DATBI
(input) and DATBO
(output).
An overview of what occurs during each type of block Mode
transfer is outlined in figures 1 (DATBI, Block Mode input.) and 2
(DATBO, block mode output).
indicates a
In the following discussion the signal prefix T(Transmit)
bus driver input and the signal prefix R(Receive) indicates a bus
receiver output.
DATBI Bus Cycle
Before a DATBI block mode transfer can occur the DMA bus master device
must request control of the bus. This occurs under conventional Q-bus
protocol ..
o REQUEST BUS
The bus master device requests control of the bus
TDMR ..

asserting

o GRANT BUS CONTROL
The bus arbitration logic in the CPU asserts the DMA grant
signal TDMGO 0 nsec minimum after TDMR is received and 0 nsec
minimum after RSACK negates (if a DMA device was previous bus
master) .
o ACKNOWLEDGE BUS MASTERSHIP
The DMA bus master device asserts TSACK 0 nsec minimum after
receivin~ ,RDMGI, 0 nsec minimum after the negation of RSYNC and
o nsec mlnlmum after the negation of RRPLY. The DMA bus master
device negates TDMR 0 nsec minimum after the assertion of TSACK.
o TERMINATE GRANT SEQUENCE
The bus arbitration logic in the CPU negates TDMGO 0 nsec
minimum after receiving RSACK. The bus arbitration logic will
also negate TDMGO if RDMR negates or if RSACK fails to assert
within 10 usec ('no SACK timeout').

uNOTE # 002
Page 3 of 20
o EXECUTE A BLOCK MODE DATBI

T~ANSFER

o ADDRESS DEVICE MEMORY
a) The address is asserted by the bus master on TADDR<21:00>
along with the negation of TWTBT.
b) The bus master asserts TSYNC
gating the address onto the bus.

150

nsec

minimum

after

that

must

o DECODE ADDRESS
The appropriate memory device recognizes
respond to the address on the bus.

o REQUEST DATA
a) The address is removed by the
bus
master
from
TADDR<21:00> 100 nsec minim,um after the assertion of TSYNC.
b) The bus master asserts the first TDIN
after asserting TSYNC.

100

nsec

minimum

c) The bus master asserts TBS7 50 nsec maximum after
asserting TDIN for the first time. TBS7 remains asserted
until 50 nsec maximum after the assertion of TDIN for the
last time.
In each case, TBS7 can be asserted or negated as
soon as the conditions for asserting TDIN are met.
The assertion of TBS7 indicates the bus master is requesting
another read cycle after the current read cycle.
o SEND DATA
a) The bus slave asserts TRPLY 0 nsec m~n~mum (8000
maximum to avoid a bus timeout) after receiving RDIN.

nsec

b) The bus slave asserts TREF concurrent with TRPLY if,
and
only if, it is a block mode device which can support another
RDIN after the current RDIN.
NOTE
Block mode
boundaries

transfers

must

not

cross

word

uNOTE # 002
Page 4 of 20

c) The bus slave gates TDATA<15:00> onto the bus 0 nsec
minimum after receiving RDIN and 125 nsec maximum after the
assertion of TRPLY.
o TERMINATE INPUT TRANSFER
a) The bus master receives stable RDATA<15:00> from 200 nsec
maximum after recelvlng RRPLY until 20 nsec minimum after
the negation of RDIN.
(The 20 nsec minimum represents total
minimum
receiver
delays
for RDIN at the slave and
RDATA<15:00> at the master.)
b) The bus master
receiving RRPLY.

negates

TDIN

200

nsec

minimum

after

nsec

minimum

after

o OPERATION COMPLETED
a)
The bus slave negates TRPLY
receiving the negation of RDIN.

b) If RBS7 and TREF are both asserted when TRPLY negates,
the bus slave prepares for another DIN cycle.
RBS7 is
stable from 125 nsec after RDIN is received until 150 nsec
after TRPLY negates.
c) If TBS7 and RREF were both asserted when TDIN neg~t~d,
the bus master asserts TDIN 150 nsec minimum after recelvlng
the negation of RRPLY and continues with timing relationship
'SEND DATA' above. RREF is stable from 75 nsec after RRPLY
asserts until 20 nsee minimum after TDIN negates.
(The 0
nsee mlnlmum represents total minimum receiver delays for
RDIN at the slave and RREF at the master.)
NOTE
The bus master must limit itself to not more than
eight transfers unless it monitors RDMR.
If it
monitors RDMR, it may perform up to 16 transfers as
long as RDMR is not asserted at the end of the
seventh transfer.

uNOTE # 002
Page 5 of 20

o TERMINATE BUS CYCLE
a) Ie RBS? and TREF were not both asserted when TRPLY
negated,
the bus slave removes TDATA<15:00> from the bus 0
nsec minimum and 100 nsec maximum after negating TRPLY.
b) If TBS? and RREF were not both asserted when TDIN negated
the
bus master negates TSYNC 250 nsec minimum after
receiving the last assertion of RRPLY and 0 nsec minimum
after the negation of that RRPLY.
o RELEASE THE BUS
a) The DMA bus master negates TSACK 0 nsec after negation of
the last RRPLY.
b) The DMA bus master negates TSYNC 300 nsec
it negates TSACK.

maximum

after

c) The DMA bus master must remove RDATA<15:00>,
TBS?, and
TWTBT from the bus 100 nsec maximum after clearing TSYNC.
o RESUME PROCESSOR OPERATION The bus arbitration logic in the CPU
enables processor-generated TSYNC or will issue another bus
grant (TDMGO) if RDMR is asserted.

uNOTE # 002
Page 6 of 20

Figure 1 - DATSI CYCLE
MEMORY

I/O DEVICE

PROCESSOR

Request Bus

Assert TDMR

Grant Bus Control <

. Near end of the current bus
cycle (RRPLY is negated) assert
TDMGO and inhibit new processor
generated TSYNC for the duration

ope~:

of the DMA

Acknowledge Bus Mastership
· Receive RDMGO
· Wait for negation of RSYNC and RRPLY
· Assert TSACK
Negate TDMR

Terminate Grant Sequence

DMA

(DATSI) Data Transfer

Address Device Memory
· Assert address on TADDR<21:00>
· Assert TSYNC
· Negate TWTBT ~

Decode Address
. Store "Device
Selected" operation

uNOTE # 002
Page 7 of 20

Figure 1 - DATSI CYCLE (continued)
I/O DEVICE

PROCESSOR
r--->

MEMORY

Request Data
· Remove address from TADDR<21:00>
· Assert TDIN
· Assert TBS7 (request for an
additional DIN cycle after
the curre!nt one

L _____ > Send Data

· Data on TDATA<15:00>
· Assert TRPLY
· Assert TREF (to
indicates block
mode capability)
Terminate' Input <--------'1
Transfer
· Accept data and respond
by nega,ting TDIN

L ______

> Operation Completed
. Negate TRPLY
1

yes

are
~----------------------~RBS7 & TREF
Asserted
?

,------'

I no

uNOTE # 002
Page 8 of 20
Figure 1 - DATBl CYCLE (continued)
I/O DEVICE

PROCESSOR

Terminate Bus Cycle
and Release the Bus

· Negate TSACK
· Negate TSYNC
· Remove TDAL, TBS?, and,
TWTBT from the Bus

Resume Processor Operation
. Enable processor generated TSYNC or
issue another grant if RDMR is asserted

MEMORY

uNOTE #002
Page 9 of 20

R DMG

....._--,-""""

T SAO:

T/R D.AL
__________- J
R/T
100 ns

T O:N

:15

'
I
~ ~-.~\ \\\)\\~
~

RE:

"-----'r

--------------~------~~ ~ ns ::tax

,.,. 35_7_ _

10 \ \ \ \ " \ \ \ \ \ \ \ \\\\\S\\S\\\\\\

~iminq at slave device.
- • bus driver input
~ • Bus rece~ver ou:~~~

DA,7SI

uNOTE #002
Page 10 of 20

THIS PAGE INTENTIONALLY LEFT BLANK

uNOTE #002
page 11 of 20

'!' DATA

R ADDR

ns :nax ____ 1

~----~--~--~----------------------~--~

R SYNC

R D!~

R 857

slave dev~ce.
7 • bus driver in~ut
~ • Sus rece~ver OU~?~:
~~:n~ng

D ATE

uNOTE #002
page 12 of 20

THIS PAGE INTENTIONALLY LEFT BLANK

uNOTE # 002
Page 13 of 20

DATBO Bus Cycle
DATBO Bus cycles Before a block mode transfer can occur the DMA bus
master device must request control of the bus. This occurs under
conventional Q-bus protocol.
o REQUEST BUS The bus master device requests control of the bus by
asserting TDMR.
o GRANT BUS CONTROL The bus arbItration logic in the CPU asserts
the DMA grant signal TDMGO 0 nsec minimum after RDMR is received
and 0 nsec minimum after TSACK negates (if a DMA device was
previous bus master).
o ACKNOWLEDGE BUS MASTERSHIP The DMA bus master device asserts
TSACK 0 nsec minimum after receiving RDMSI, 0 nsec minimum after
the negation of RSYNC and 0 nsec minimum after the negation of
RRPLY.,
The DMA bus master device negates TDMR 0 nsec minimum
after the assertion of TSACK.
o TERMINATE GRANT SEQUENCE The bus arbitration logic in the CPU
negates TDMGO 0 nsec minimum after receiving RSACK. The bus
arbitration logic will also ne9ate TDMGO if RDMR negates or if
RSACK fails to assert within 10 usec ('no SACK timeout').
o EXECUTE A BLOCK MODE DATBO TRANSFER
o ADDRESS DEVICE MEMORY
a) The address is asserted by the bus master on TADDR<21:00>
along wi th the assertion of T'WTBT.
b) The bus master asserts TSYNC
gating the address onto the bus.

150

nsec

minimum

after

o DECODE ADDRESS The appropriate memory device recognizes that
it must respond to the address on the bus.
o SEND DATA
a) The bus master gates TDATA<15:00> along with
nsee minimum after the assertion of TSYNC.
negated.
b) The bus master asserts the first TDOUT 100
after gating TDATA<15,: 00>.
NOTE
During DATBO cycles TBS7 is undefined

TWTBT 100
TWTBT is

nsec

minimum

uNOTE # 002
Page 14 of 20
o RECEIVE DATA
a) The bus slave receives stable data on RDATA<15:00> from
25 nsec minimum before receiving RDOUT until 25 nsec minimum
after receiving t~e negation of RDOUT.
b) The bus slave
receiving RDOUT.

asserts

TRPLY

nsec

minimum

after

c) The bus slave asserts TREF concurrent with TRPLY if,
and
only if, it is a block mode device which can support another
RDOUT after the current RDOUT.
NOTE
Blockmode transfers
boundaries

must

not

word

o TERMINATE OUTPUT TRANSFER The bus master negates
nsec minimum after receiving RRPLY.

TDOUT

cross

150

o OPERATION COMPLETED
a)
The bus slave negates TRPLY
receiving the negation of RDOUT.

nsec

minimum

after

b) If RREF was asserted when TDOUT negated and if the bus
master wants to transfer another word, the bus master gates
the new data on TDATA<15:00> 100 nsec minimum after negating
TDOUT.
RREF is stable from 75 nsec maximum afterRRPLY
asserts until 20 nsec minimum after RDOUT negates.
(The 20
nsee minimum represents minimum receiver delays for RDOUT at
the slave and RREF at the master).
c) The bus master asserts TDOUT 100 nsec minimum after
gating new data on TDATA<15:00> and 150 nsec minimum after
receiving the negation of RRPLY.
The cycle continues with
the timing relationship in 'RECEIVE DATA' above.
NOTE
The bus master must limit itself to not more than
eight transfers unless it monitors RDMR.
If it
monitors RDMR, it may perform up to 16 transfers, as
long as RDMR is not asserted at the end of the
seventh transfer.
o TERMINATE BUS CYCLE
a). If RREF was not asserted when RRPLY negated or if the bus
master has no additional data to transfer, the bus master
removes data on TDATA<15:00> from the bus 100 nsec minimum
after negating TDOUT.

uNOTE # 002
Page 15 of 20
b) If RREF was not asserted when TDOUT negated the bus
master negates TSYNC 275 nsec minimum after receiving the
last RRPLY and 0 nsec minimum after the the negation of the
last RRPLY.
o RELEASE THE BUS
a) The DMA bus master negates TSACK 0 nsec after negation of
the last RRPLY.
b) The DMA bus master negate!s TSYNC 300 nsec
it negates TSACK.

maximum

after

c) The DMA bus master must remove TDATA,
TBS7,
and
from the bus 100 nsec maximum after clearing TSYNC.

TWTBT

o RESUME PROCESSOR OPERATION The! bus arbitration logic in the CPU
enables processor-generated TSYNC or will issue another bus
grant (TDMGO) if RDMR is asserted.

uNOTE # 002
Page 16 of 20
Figure 2 - DATBO CYCLE
I/O DEVICE

PROCESSOR

MEMORY

Request Bus
. Assert TDMR
Grant Bus Control
. Near the end of the current bus
cycle (RRPLY is negated) assert
TDMGO and inhibit new processor
generated TSYNC for the duration
of the DMA operation.

~>
I

Acknowledge Bus Mastership
· Receive RDMG
· Wait for negation of RSYNC
and RRPLY
· Assert TSACK
Negate TDMR

Terminate Grant Sequence
. Negate TDMGO and wait for DMA
operation to be completed.

~I--------_> Execute A Block Mode DMA
(DATBO) Data Transfer

Address Memory
· Assert Address on TADDR<21:00>
· Assert TWTBT
· Assert TSYNC ~

L-> Decode Address
. Address match
selects device

uNOTE i 002
Page 17 of 20
Figure 2 - DATBO CYCLE (continued)
PROCESSOR

I/O DEVICE

MEMORY

r----> Send Da ta
· Assert TDATA <15:00>
· Negate TWTBT
· Assert TDOUT ~

L> Receive Data
· Accept data and
RWTBT
• Assert TRPLY
• Assert TREF
(Indicates block
mO<de carability)
Terminate Output Transfer
• Negate TDOUT

L>
Operation Completed
. Negate TRPLY

I
yes

Does Master
Wish to Transfer
More Data ?

Terminate Bus Cycle and

yes

is RREF
Asserted ?
no

<------~

Release the Bus

. Negate TSACK
. Negate TSYNC
Remove TDAL, TDAL,TBS7, and TWTBT
from the Bus

Resume Processor Operation
. Enable processor generated TSYNC
(processor is bus master) or issue
another grant if RDMR is asserted

uNOTE #002
Page 18 of 20

THIS PAGE INTENTIONALLY LEFT BLANK

uNOTE #002
Page 19 of 20

::::~~~-.r-'~-------------------------------------------rc~~~~~~~
~~~~~----------.---------------------------------_

T SACK

TD~

~ :~3 ~~-~-~~~7~A---~X~__-_:_A_T_A_ _~(~~~_ _

------------ ~5JnS~'1~J~O~ns~----·------------~--------------r_tt::J
R/T SYNC \'..\...\.....____-+_m.:.__
"
",,-n ~OOns
H\(,:

--.J1oons)

~
-----~r__-~~

T JOt~

~------------_t----------~----.

-t---__-t___•

?-':":.? _ _ _ _ _ _

\
' -_ _ _-

\L-__________________-

_ _ _ _ _ _ _1

T fITET

'---~\\~._________

)15~. ~~ I -,----- /

R R?:'Y

\loon'l

~~~ng

at master =eVl:e.
T • Sus driver in;:u": .
R a Bus receiver out;:u~

CArBO

uNOTE i002
Page 20 of 20

R ~R AJ:)OA

R SYNC

R DATA

A
\

R DOur

T RPLY
.....I. REF

- L
-/

R WTB~r

:""NDEFIm::J

R aS1

':'illlinq at slave devic:: ••
T n Bus driver input
R n Bus rec::eiver output

DATIO

uNOTE #003

Title: Compatible Bootstraps for the LSI-11/73

Date: 28-NOV-83

Originator: Mike Collins

Page 1 of 2

The LSI-l1/73 (KDJ11-AA) is a high performance CPU for the Q-Bus.
It is
a CPU only, which means that there is no boot capability on the module
itself. Therefore a boot module must be selected to work with the
LSI-11/73.
This uNOTE will discuss the bootstrap modules which can be used with the
11/73.
There are 4 possible modules which can be used for bootstrap.
They are : MXV11-BF w/MXV11-B2 boot ROMs
MRV11-D w/MXV11-B2 boot ROMs
MXV11-AA or -AC w/MXV11-A2 boot ROMs
BDV11
For an LSI-l1/73 based system to be Field Serviceable the bootstrap code
must execute a cache memory diagnostic on power-up.
The only boot code
which satisfies this requirement is found in the MXV11-B2 boot ROMs.
Therefore an LSI-11/73 based, Field Serviceable system must use either
the MXV11-BF w/MXVII-B2 ROMs or the MRVII-D w/MXVII-B2 ROMs.
NOTE
The MXVII-B2 ROMs will not work on the MXVII-A module.
MXVII-BF or MRVII-D w/MXVII-B2 ROft1:s
The Mxvl1-BF w/MXVI1-B2 ROMs is the preferred choice since this module
has 2 asynchronous serial lines as well as 128Kb of dynamic RAM in
addition to the boot capability. However, if your application does not
need the extra serial lines and RAM, an alternate choice would be the
MRV11-D w/MXV11-B2 ROMs.
The MXVI1-B2 ROMs will boot the following devices :
RL01 / RL02 (DL)
RX01 / RX02 (DX,DY)
TU58 (DD)
TSV05 (MS)
MSCP type Devices e.g. RD51, RXSO (DU)
DECnet via DPVll, DLV11-E, DLV11-F, DUVl1

uNOTE # 003
Page 2 of 2
NOTE
The MXV11-BF is not supported by RSTS due to its
non-parity memory.
An alternative configuration would
be to use the MRV11-D with the MXV11-B2 boot ROMs, and a
DLV11-J or other DLV11 serial line device.
The remaining 2 boot modules do NOT have the necessary cache
diagnostic code to make an 11/73 based system Field Serviceable.

memory

Below is a list of all of
remaining boot modules.

the

KNOWN

WORKING

bootstraps

for

MXV11-A w/MXV11-A2 ROMs
working bootstraps

RLOl
RX01
TUS8
TUS8

/ RL02
/ RX02
conventional boot
standalone boot
WARNING

If the MXV11-A is used in a 22 bit system the
RAM must be disabled. Refer to uNOTE #106.

on-board

BDV11
Working bootstraps

RL01 /
RX02
RKOS

RL02

WARNING
Disable the processor and memory tests since an odd
address trap does occur in each of them.
See NOTE
below.
To disable the CPU test,
set swit~h E1S-1 to
OFF.
To disable the memory test, set switch E1S-2 to
OFF.
(Refer to the Microcomputer
and
Interfaces
Handbook for complete configuration information.)
The 11/73 has an on-board Line Time Clock Register,
therefore the BDV11 BEVNT switch E21-S should be set to
the OPEN position. This disables software control of
the BEVNT signal via the BDV11 LTC register and allows
software control of this signal via the 11/73 LTC
register.
If the BDV11 is used in a 22 bit system, it must be CS
REV E or later or ECO M8012-MLOOOS must be installed.
NOTE
ODD ADDRESS TRAPS.
The 11/23 ignores an odd address
reference whereas the KDJ11-A will trap to address 4.

r= uNOTE 1004
Title: LSI-11/73 upgrade Paths

Date: 28-NOV-83

Originator: Mike Collins

Page 1 of 6

With the announcement of the KDJ11-A cpu module, there will be numerous
questions regarding configuring the module into a current system. The
purpose of this MicroNote is to address all possible configuration
upgrade paths (within reason).
Generally a KDJ11-A will be installed as an upgrade to
from components or DEC packaged system.

system

built

In the case of a component upgrade it is assumed the processor is a
KDF11-A and the boot mechanism is an MXV11-A with the MXV11-A2 Boot
ROMs.
System upgrades fall into 2 categories:
1. KDF11-A based systems and
2. KDF11-B based systems (11/23+ and Micro/PDP-11)
There are 3 issues which must be addressed when
upgrade.
They are:
1. The Boot mechanism
2. 18 or 22 bit system
3. Single or multiple box system

considering

KDJ11-A

NOTE
1. In the following upgrade scenarios, the systems have
been labeled as being Field Serviceable or not. A
system which is Field Serviceable has a bootstrap which
meets Field Service requirements. The requirement is
that the bootstrap must execute an 11/73 cache memory
diagnostic on power-up. There is no guarantee that the
overall system will be Field Serviceable or that it will
be FCC compliant.
2. Systems using cpu's other
KDF11-B (i.e.
11/03 systems)
upgrade.

than the KDF11-A or
are not considered for

CAUTION:
It is recommended that the AC and DC loading for the final
configuration be checked for conformance with the Q-BuS loading rules.

uNOTE # 004
Page 2 of 6
It is also recommended to check for.overloading on the +5 Volt
volt Power Supplies.

and

+12.

For each system upgrade the following parameters are listed for both the
'Current' system and the 'Upgraded' system:
1.
2.
3.
4.

CPU
Boot Mechanism
System Size
Number of Boxes
5. Field Serviceable or not
6. Special Conditions

COMPONENT UPGRADE PATHS:
1. Current System
KDF11-A
MXV11-A
18 Bit System
1 Box

Upgrade 1
KDJ11-A
MXV11-B/MRV11-D with MXV11-B2 Boot ROMs
18 Bit System
1 Box
Field Serviceable
Upgrade 2
KDJ11-A
MXV11-A
18 Bit System
1 Box
NOT Field Serviceable

2. Current System
KDF11-A
MXV11-A
18 Bit System
More than 1 box
3. Current System

KDF11-A
MXV11-A (Memory Disabled)
22 Bit System
1 Box

Upgrade
See upgrades for category #1

upgrade
See upgrades for category #1

uNOTE # 004
Page 3 of 6
UP9 rade

4. Current System

Not currently configureable with
KDF11-A
DEC equipment.
MXV11-A (Memory Disabled)
22 Bit System
More than 1 box
This system is not currently configureable with DEC equipment.
PDP 11/23A SYSTEM UPGRADE PATHS:
5. Current System

UP9rade 1

KDF11-A
BDV11
18 Bit System
1 Box

KD~Jl1-A

MXV11-B/MRV11-D with MXV11-B2 Boot ROMs
18 Bit System
1 130x

Field Serviceable
Upc;rade 2
KD,J11-A
BDV11
18 Bit System
1 160x

NOT Field Serviceable
Disable the Processor and Memory tests
and also the BEVNT register on the
BDV11.
Uptgrade 3
KDIJ11-A
MXV11-A (with MXV11-A2 boot ROMs)
18 Bit System
1 :Box System
NOT Field Serviceable
Check AC loading since termination was
removed when the BDV11 was removed from
th!e system.
6. Current System

UP'9rade 1
KD,J11-A
MXV11-B/MRV11-D with MXV11-B2 Boot ROMs
18 Bit System
More than 1 box
Field Serviceable
Use Bcv1A and BCV1B expansion cables.

KDF11-A
BDV11
18 Bit System
More than 1 Box

uNOTE # 004
:I?age 4 of 6
upgrade 2
KDJ11-A
BDV11
18 Bit System
More than 1 Box
NOT Field Serviceable
Disable the Processor and Memory tests
and also the BEVNT register on the
BDV11.
Use BCV1B cable set between 1st and 2nd
box and the BCV1A cable set between the
2nd and 3rd box. Note: If in a 3 box
system the expansion cable set lengths
must differ by 4 ft.
Upgrade 3
KDJ11-A
MXV11-A (with MXV11-A2 boot ROMs)
18 Bit System
More than 1 Box
NOT Field Serviceable
Use BCV1A and BCV1B expansion cables.
7. Current System
KDF11-A
BDV11
22 Bit System
1 Box
Systems with this configuration were never shipped by DEC.
PDP 11/23 PLUS SYSTEM UPGRADE PATHS:
8. Current System
KDF11-B
Boot is on CPU
22 Bit System
1 Box System

upgrade 1
KDJ11-A
MXV11-B/MRV11-D with MXV11-B2 Boot ROMs
22 Bit System
1 Box
Field Serviceable
Upgrade 2
KDJ11-A
MXV11-A (with MXV11-A2 boot ROMs)
22 Bit System
1 Box
NOT Field Serviceable
Must disable RAM on MXV11-A.

uNOTE # 004
Page 5 of 6
Upgrade 3
KDJII-A
BDVl1
22 Bit System
1 Box System
NOT Field Serviceable
Must have BDV11 ECO M8012-MLOOS
installed. Disable the Processor and
Memory tests and also the BEVNT register
on the BDV11.
9. ·Current System

Upgrade 1

KDFI1-B
Boot is on CPU
22 Bit System
More than 1 Box

Not currently configureable with
DEC equipment.

Upgrade 2
Not currently configureable with
DEC equipment.
upgrade 3
Not currently configureable with
DEC equipment.
MICRO/PDP-11 SYSTEM UPGRADE PATHS:
10. Current System

upgrade

Micro/PDP-11
KDF11-BE
Boot is on CPU
22 Bit System
1 Box system

Same as 11/23+ rules, see category
#8, Upgrade 1. upgrades 2 and
3 are not recommended since the
MXV11-A and BDV11 cannot boot the
5 1/4" media in the Micro/PDP-II.

11. Current System

Upgrade
Same as 11/23+ rules, see upgrades
for category #9.

Micro/PDP-11
KDF11-BE
Boot is on CPU
22 Bit System
More than 1 box

uNOTE # 004
Page 6 of 6
NOTE
It is not currently possible to expand out
Micro/PDP-11 while maintaining FCC compliance.

the

11/23 PLUS and Micro/PDP-11 system upgrades will require
an EXTRA backplane slot to accomodate the additional
boot module (i.e. MXV11-A,-B or BDV11).
11/23-S SYSTEM UPGRADE SOLUTIONS:
12. Current System
KDF11-BA
Boot is on CPU
18 Bit System
1 Box system
13. Current System
KDF11-BA
Boot is on CPU
18 Bit system
More than 1 box

upgrade
See upgrades for category #5.

Upgrade
See upgrades for category #6.

NOTE
It is not currently possible to expand
11/23-8 while maintainin9 FCC compliance.

out

the

uNOTE # 005

Title: Q22 Compatible Options

Date: 23-Apr-84

Originator: Charlie Giorgetti

page 1 of 6

This is a list of Q22 compatible options. A Q22 compatible option is
defined as a Q-bus option that will work without restriction in an
extended Q-bus system, that is a 22-bit Q-bus system.
This list also
includes options that are not compatible in Q22 systems and the reason
for the restriction.
The requirements for a device to be Q22 compatible are the following:
1. Processors, memories, and OM. devices must all be capable of
addressing.
2. Devices must use backplane pins BC1, BD1, BEl,
DEl, DF1, for BDAL18-21 only.

BF1

and

DC1,

22-bi t
001,

Processors, memories, or DMA devices which are not capable of 22-bit
may generate or decode erroneous addresses if they are used
ln
systems
which
implement
22-bit
addressing.
Memory
and
memory-addressing devices which implement only 16 or 18-bit addressing
may be used in a 22-bit backplane, but the size of the system memory
must be restricted to the address range of those devices (64 KB for
systems with 16-bit devices and 256 KB for systems with an lS-bit
devices).
~ddressing

Any device which uses backplane pins BC1, BD1, BEl, BF1 or DC1, 001,
DEl, OF!, for purposes other than BDAL18-21 is electrically incompatible
with the 22-bit bus and may not be used without modification.
NOTE
Eighteen or sixteen bit DMA devices can potenitially work in
Q22 systems by buffering I/O in the 18- or 16-bit address
space.
I.

Fully Compatible Options

Options in this category meet both of the requirements
and may be used in any Q-bus configuration.
A. Processors
KD32-A

M7135/M7136

MicroVAX I CPU Module

mentioned

above

uNOTE # 005
Page 2 of 6
KDFll-A

M8186

LSI-ll/23 CPU
(Etch Rev. C or later)

KDFll-B

M8l89

LSI-l1/23B CPU

KDJll-A

M8l92

LSI-l1/73 CPU

KDJll-B

M8l90

MicroPDP-ll/73 CPU

KXTll-C

M8377

Q-bus Perpherial I/O Processor

KMV11-A

M7500

Q-bus Perpherial Communication Processor

B. Backplanes/Boxes
H9270-Q

4 X 4 Q22/Q22 Backplane

H928l-QA
H9281-QB
H928l-QC

2 X 4 Q22 Dual-height Backplane
2 X 8 Q22 Dual-height Backplane
2 X 12 Q22 Dual-height Backplane

H9275

4 X 9 Q22/Q22 Backplane

BA11-S

H9276

4 X 9 Q22/CD Backplane

Micro/PDP-ll

H9278

4 X 3 Q22/CD and 4 X 5 Q22/Q22 Backplane

C. Memory
MCVll-D

M8631

CMOS Non-volatile Memory

MSV11-L

M8059

MOS Memory (either 128 KB or 256 KB)

MSVll-P

M8067

MOS Memory (either 256 KB or 512 KB)

MSVll-Q

M7551

MOS Memory ( 1 MB)

MXVll-B

M7195

Multifunction Module

MRVll-D

M8578

PROM/ROM Module

AAVll-C

A6006

D/A Converter

ADVll-C

ABOOO

A/D Converter

AXVll-C

A0026

D/A and A/D Combination Converter

BDVll

MB012

Bootstrap, Terminator, Diagnostic
(CS Rev. E or later, ECO M8012-ML005
installed)

D. options

uNOTE # 005
Page 3 of 6
DEQNA

M7504

Ethernet Controller

DLVll

M7940

Asynchronous Serial Line Interface

DLVll-E

M80l7

Asynchronous Serial Line Interface

DLVll-F

M8028

Asynchronous Serial Line Interface

DLVll-J

M8043

Four Asynchronous Serial Line Interfaces
(CS Rev. E or later, ECO M8043-MR002
installed)

DHVll

M3l04

8-line Asynchrono~s EIA Multiplexer

DMVll-AD

M8053-MA

Synchronous Communications Interface

DMVll-AF

M8064-MA

Synchronous Communications Interface

DPVll

M8020

programmable Synchronous EIA Line

DRVll

M794l

32 line Parallel Interface

DRVll-J

M8049

64 line Parallel Interface

DRVll-w

M765l

General Purpose DMA Interface (dual)

DUVll

M795l

programmable Synchronous EIA Line

DZQll

M3l06

4-line Asynchronous EIA Multiplexer (dual)

DZVll

M7957

4-line Asynchronous EIA Multiplexer (quad)

FPFll

M8l88

Floating Point Processor

IBV11-A

M7954

IEEE Instrument Bus Interface

IEQll

M8634

DMA IE:EE Instrument Bus Interface

KLESI-QA

M7740

LESI Bus Adaptor (RC25 Interface)

KPVll-A

M80l6

Power-fail and LTC Generator
(KPV11-B and -C are not compatible)

KWVll-C

A4002

Programmable Real-time Clock

LAVll

M7949

LA180 Line Printer Interface

LPVll

M8027

LA180/LP05 Printer Interface

RLV12

M806l

RL01/2 Controller

RQDXl

M8639

Controller for 5.25" Floppy and Winchester

uNOTE # 005
Page 4 of .6
RXVll

M7946

RXOl Floppy Disk Interface

TQK25

M7605

Streaming Cartridge Tape Controller

TSv05

M7l96

Magnetic Tape Controller

E. Bus Cable-Cards

II.

M9404

Cable Connector

M9404-YA

Cable Connector with 240-0hm Terminators

M9405

Cable Connector

M9405-YA

Cable Connector with l20-0hm Terminators

Restricted Compatibility Options

Options in this category do not meet one or both of the requirements for
use in a 22-bit system. These options are incompatible with some ~r all
22-bit systems.
A. Processors
KDFll-A

M8l86

LSI-ll/23 CPU
(Prior to etch rev. C, l8-bit addressing only,
and use of BC1,BD1,BE1,BFl for purposes other'
than BDAL18-2l)

KDll-HA

M7270

LSI-ll/2 CPU
(16-bit addressing only, and use of BC1,BD1,
BE1,BFl for purposes other than BDAL18-2l)

KDll-F

M7264

LSI-ll CPU
(16-bit addressing only, and use of DC1,DB1,
DE1,DFl for purposes other than BDAL18-2l)

KXTll-A

M8063

SBC-ll/2l CPU
(16-bit addressing only)

B. Backplanes/Boxes
6 X 9 Backplane
(18-bit addressing only)

DDVll-B
BAll-M

H9270

4 X 4 Backplane
(18-bit addressing only)

BAll-N

H9273-A

4 X~9 Backplane
(18-bit addressing only)

uNOTE # 005
Page 5 of 6
BAll-VA

H92S1-A,B,C

VT103

2 X n Dual-height Backplane n - 4, S, and 12
BAll-VA used the H92S1-A
(lS-bit addressing only)
4 X 4 Backplane (part number: 54-1400S)
(18-bit addressing only)

C. Memories
MMV11-A

G653

S KB Core Memory
(16-bit addressing only, Q-bus required on C/D
backplane connectors)

MRV11-AA

M7942

ROM Module
(16-bit addressing only)

MRV11-BA

MS021

UV PROM--RAM
(16-bit addressing only)

MRV11-C

MS04S

PROM/ROt1 Modul e
(lS-bit addressing only)

MSV11-B

M7944

S KB bus refreshed RAM
(16-bit addressing only)

MSV11-C

M7955

32 KB Rl\M
(lS-bit addressing only)

MSV11-D,E MS044/MS045

S KB, 16 KB, 32 KB, 64 KB RAM
(lS-bit addressing only)

MS047

Multifunction Module
(lS-bit addressing only on memory, the memory
can be disabled)

AAV11

A6001

D/A Converter
(Use of BC1 for purposes other than BDAL1S)

ADV11

A012

A/D Converter
(Use of BC1 for purposes other than BDAL1S)

BDV11

MS012

Bootstrap/Terminator
(CS Revision E or earlier lS bits only)

DLV11-J

MS043

Serial Line Interface
(CS Rev. E or earlier incompatible with
KDF11-A and KDF11-B)

DRV11-B

M7950

General Purpose DMA Interface (quad)
(lS-bit DMA only)

MXV11-A
D. Options

uNO'!'E # 005
page 6 of 6
KPVll-B,C M80l6-YB,YC

Power-fail/line-time clock/terminator
(Termination for l8-bits only)

KUVll

MS01S

writable Control Store
(For use with KDll-F processor only)

KWVll-A

M7952

Programmable real-time clock
(Use of BCl for purposes other than BDAL18)

REVll

M9400

Terminator, DMA refresh, bootstrap
(Bootstrap for use with KDll-F and KDll-HA
processors only.
Termination for l8-bits only.
DMA refresh may be used in any system.)

RKVll-D

M7269

RK05 Controller Interface
(l6-bit DMA only)

RLVll

M80l3
M80l4

RL01,2 Controller
(18-bit DMA only, use of BCl and BDl for
purposes other than BDALl8 and BDALl9)

RXV2l

M8029

RX02 Floppy Disk Interface
(lS-bit DMA only)

TEVll

M9400-YB

l20-0hm Bus Terminator
(Termination for l8-bits only)

VSVll

M7064

Graphics Display
(lS-bit DMA only)

E. Bus Cable-Cards
M9400-YD

Cable Connector
(lS-bit bus only)

M9400-YE

Cable Connector with 240-0hm Terminators
(18-bit bus only)

M940l

Cable Connector
(lS-bit bus only)

uNOTE #006

Differences Between
the LSI-11/73 and LSI-11/23

Title:

Originator: Mike Collins

Date: 23-APR-84
Page 1 of 8

This uNOTE identifies and discusses the differences between
the
LSI-11/23
(KDF11-AA) and the LSI-11/73 (KDJ11-AA). The following table
lists these differences.
Following the table are individual discussions
on these differences.
Some of these differences are discussed from the point
11/23 to 11/73 upgrade.
Table 1

view

LSI-11/73 versus LSI-11/23

FEATURE

11/73

11/23

Odd Address Traps

Yes

Micro ODT

22 Bit

18 Bit

Illegal Halt

Traps to 4

Traps to 10

Processor Modes

I & D Space

Yes

General Purpose Reg Sets

Floating Point Inst. Set

Standard

Option

Line Time Clock Reg.

Yes

On-board Cache Memory

Yes

Pipelined Processing

Yes

UBMap Signal on the Q-bus

Not Available

Available

Additional Instructions
Available

CSM, TSTSET,
WRTLCK

Not
Available
cont'd

uNOTE # 006
Page 2 of 8
Table 1 cont'd

LSI-11/73 versus LSI-11/23
11/73

FEATURE

11/23

CPU Error Register
Memory System Error Reg
Cache Control Reg
Hit/Miss Reg
Program Interrupt Req Reg
Line Time Clock Reg
Maintenance Reg

Additional CPU Registers

Not
Available

A discussion of processor speed can
be found in the respective user guides

Processor Speed

User Guide Part #
EK-KDJ1A-UG

User Guide Part #
EK-KDF11-UG

ODD ADDRESS TRAPS
The 11/73 processor will trap to 4 when it encounters an odd address
reference.
i.e.
whenever an address begins on an odd byte boundary
(least significant bit - 1). The 11/23 ignores odd address references
and simply treats the LSB as a zero, effectively 'forcing' all addresses
to begin on even byte boundaries.
Odd address traps do not occur
freque~tly,
however it is possible for code to run on an 11/23 and NOT
run on an 11/73 because of them.
Fixes for these errors
are
straightforward.
MICRO ODT (Octal Debugging Technique)
Both the 11/23 and the 11/73 implement ODT in their microcode.
The
11/23 can use ODT to examine main memory locations from 0 to 256 Kbytes,
but no further.
On the other hand, the 11/73 ODT can examine the full 4
Mbyte range of main memory. When accessing addresses in the I/O page
with an 11/73, a full 22 bit address must be specified.
Example: To look at the first instruction of the bootstrap code with
an 11/73 it is necessary to type:
@17773000/
or @7777777777773000/
NOT @773000/

This is NOT enough because only
18 bits have been specified.

uNOTE # 006
Page 3 of 8
ILLEGAL HALT
The 11/23 and the 11/73 respond differently when detecting a halt
instruction in user or supervisor mode.
The 11/23 traps to address 10
whereas the 11/73 traps to address 4. The 11/73 also sets the Illegal
Halt Bit in the CPU ERROR Register to indicate an Illegal Halt occurred.
PROCESSOR MODES
The 11/23 has two processor modes, KERNEL and USER.
KERNEL, SUPERVISOR and USER.

The 11/73 has three

I and D SPACE
The concept of I and D space is used in mapping information into
separate physical memory segments, depending on whether the information
is considered instructions (I) or data (D). The use of I
and D space
allows programs to exist in two virtual segments and effectively doubles
the address available to the user from 64 Kbytes to 128 Kbytes.
The 11/73 has the capability for I and D space whereas the 11/23 does
not.
To implement this feature, many more PAR/PDR pairs are necessary.
The 11/73 has 48 PAR/PDR pairs, the 11/23 has only 16 PAR/PDR pairs.
GENERAL PURPOSE REGISTER SETS
The 11/23 and all previous LSI-11 processors have 1 set of general
purpose registers,
RO thru R7.
Some of these are used for special
purposes.
R7 is used as the progri~m counter and R6 is used as the stack
pointer.
Internal to the 11/23 are 2 registers used for stack pointers,
one for each processor mode).
There are 5 additional registers RO thru
RS.
The 11/73 has two sets of general purpose registers, listed in the table
below. Only eight are visible to the user at any given time.
There are
two groups of six registers (RO thru RS and RO' thru RS').
The group
currently being used is selected by bit 11 in the Processor Status Word
(PSW).
Only one stack pointer is visible to the user at anyone time
and is determined by bits 14 and 15 in the PSW.
Designation
RO
RO'
R1
R1'
R2
R2'
R3
R3'

1
2
3
4
5

R4
RS
KS]?
PC

R4'
RS'
SSP

KSP - Kernel Stack Pointer
SSP - Supervisor Stack Pointer
USP = User Stack Pointer

USP

uNOTE # 006
Page 4 of 8
FLOATING POINT INSTRUCTION SET
Both the 11/23 and the 11/73 use the FP11 Floating Point Instruction
Set.,
The FP11 Instruction Set is an option for the 11/23 (choice of
either the KEF11 chip or the FPF11 floating point accelerator).
The
FP11 instruction set is part of the J11 microprocessor microcode and is
therefore a standard feature of the 11/73.
LINE TIME CLOCK REGISTER
The original dual height 11/23 CPU does not have an LTC (Line Time
Clock)
register on the board.
In 11/23 based systems the BDV11 boot
module contains the LTC reg.
In order to enable or disable LTC
interrupts under software control, the 11/23 must write to this register
over the Q-bus.

11/23

LTC
REG

7 546

Q-bus

The 11/73 has an LTC register on the CPU board.
This means that
whenever the 11/73 wants to enable or disable LTC interrupts under
software control it writes to this on-board register.
The address of
the LTC register (location 177546) is 'trapped' on the board and NEVER
goes out onto the Q-bus. When the 11/73 is used in a system with a
BDV11,
it is recommended that software control over the LTC interrupts
be disabled on the BDV11 (see uNOTE #114).

11/73
177546

I
Q-bus
ON-BOARD CACHE MEMORY
Cache memory systems are designed

increase

CPU

performance.

The

uNOTE # 006
Page 5 of 8
cache maintains copies of portions of main memory in very high-speed RAM
and thus reduces access times significantly.
The 11/73 is the first Q-bus processor to implement a cache memory
system.
The cache is automatically enabled on power-up and its
operation is transparent to software.
However software can enable or
disable the cache by writing to the Cache Control Register (CCR).
When the cache is enabled, any information fetched from main memory will
be
'cached'
i.e.
placed in the high-speed RAM.
Information fetched
from an I/O device will NOT be 'cached' (i.e.
information fetched from
an address in the I/O page).
CAUTION:
Digital Equipment Corporation does not support a system which
uses shared or dual-ported memory on the Q-bus.
However there are
applications and non-DEC add-on hardware which do
support
such
configurations.
Consider the following:
The system below uses an 11/73, has a certain amount of main memory as
well as dual-ported memory.
The cache is enabled and the following
sequence of events occur:
1.
The 11/73 reads a word
address A which contains
'cached'.

from the dual-ported RAM
the value X.
The value

EXTERNAL
DEVICE

11/73
A: X
A: X

at
is

<------I
RAM

Dual-Ported RAM

2. The external device writes a new value, Y, into location A.

11/73
A: Y

<-----------

EXTERNAL
DEVICE

A: X
RAM

The 11/73 references location A again, but finds that it

uNOTE # 006
Page 6 of 8
is in the cache and therefore uses the 'old' value of X.
But this is incorrect since the external device updated
location A with the new value Y.
This anomaly can be corrected in a number of ways.
Put the dual ported RAM somewhere in the I/O page since any I/O page
reference always bypasses cache. If the amount of dual-ported RAM is
large this may not be practical.

B.
The memory management unit contains several page
Descriptor
Registers (PDRs).
The PDRs contain information relative to page
expansion, page length and access control. Bit 15 of each PDR is the
Bypass Cache bit. If the PDR accessed during a relocation operation has
this bit set the reference will go directly to main memory.
Hits on
reads or writes will result in invalidation of the accessed cache
location.
Enabling this bit in each PDR associated with
will force these references to bypass cache.

the

dual-ported

memory

C. Whenever the processor reads from the dual-ported RAM, add extra
code which will simply turn off the cache prior to the read and turn the
cache back on after the read is complete. Turning the cache on and off
can be done by setting the appropriate bits in the Cache Control
Register.
PIPELINED PROCESSING
The 11/73 gets much of its performance by implementing a prefetch and
predecode
mechanism.
The major benefit of this is that memory
references are overlapped with internal operations which results in
faster
program execution.
The 11/23 does not implement such a
mechanism.
CAUTION
This implementation is completely compatible with DEC
hardware and software.
However there are applications and non-DEC
add-on hardware which may be confused.
Such situations are easily
corrected.
The prefetch mechanism assumes sequential program flow; one instruction
immediately follows the next.
Whenever the program flow is not
sequential (i.e. the PSW, CCR, PC or any memory management register is
written) the pipeline is 'flushed'. If a non-DEC device does its own
'macro' memory management, the instruction flow may be confused.
For example :
A non-DEC device utilizes 2 ROM sets for boot code. Both ROM sets map
over the same addresses but only 1 set is enabled at any instant in

uNOTE
006
Page 7 of 8
time.
This is done via a ROM set enable CSR. Assume the boot code
in
ROM set X is executing.
Instruction X + 1 is a MOV instruction to the
ROM enable CSR to transfer program control to ROM set Y.
The intent of
the ROM code is for statement Y + 2 in ROM set 2 to be executed next.
This will work OK with an 11/23.
However because of the prefetch
mechanism of the 11/73, the 11/73 '~ill execute instruction X + 2 of ROM
set 1, NOT ROM set 2.
This particular boot method effectively does its own memory mapping and
since it is done at the 'macro' level and external to the J11 cpu, the
pipeline is not 'flushed'. A simple solution is to include a NOP
instruction after the instruction which updates the ROM enable CSR, or
to use a branch instruction which effectively changes the PC and causes
the pipeline to be 'flushed'.
User Boot Device
ROM X

ROM Y

11/73

Sequence of events :
1. ROM X is enabled.
2. Instruction X + 1 enables
ROM Y.

X
X + 1
X + 2

Y
Y + 1
Y + 2

X + n

Y + n

~OM Enable CSR

3. Next instruction to be
executed is Y + 2.

MAP SIGNAL ON THE Q-BUS (UBMAP L)
The 11/23 outputs the signal UBMAP onto the Q-bus.
Some non-DEC add-on
equipment may use this signal for special purposes.
This signal is not
defined by the Q-bus specification and for design reasons was not
included on the 11/73.
Therefore, the 11/73 may not work with non-DEC
devices which expect to see this signal.
ADDITIONAL INSTRUCTIONS AVAILABLE
These 3 instructions are part of the 11/73 instruction set but
found in the 11/23:
CSM
TSTSET
WRTLCK

are

Call to Supervisor Mode
Test Destination and Set Low Bit
Read/Lock Destination Write/Unlock RO into
Destination

NOT

~NOTE

# 006
Page 8 of 8

ADDITIONAL CPU REGISTERS AVAILABLE
following CPU registers are part of the DCJ11 chip or implemented on
the 11/73 module and are not found on the 11/23.

ThE~

CPU Error Register
Memory System Error Register
Cache Control Register
Hit/Miss Register
Additional PAR/PDR's necessary to implement I & D Space
Program Interrupt Request Register
Line Time Clock Register (previously discussed)
Maintenance Register
PROCESSOR SPEED
The 11/73 executes instructions significantly faster than the 11/23.
So1:tware which bases delays on instruction loops may not work on the
11/73 because the instructions, and therefore the delay loop, are
completed much faster than they were when executed on the 11/23.
Software which uses this method of implementin9 delays produces code
which is not processor independent. However instances do appear every
so often and it is important to be aware of this possibility.

uNOTE

* 007

Title: User Defined Memory Maps For The Falcon
And The Falcon plus

Date: 01-MAY-84

Originator:

Page 1 of 13

Jack Toto

The memory maps on the Falcon, and E~alcon Plus are defined by the FPLA
(Field Programmable Logic Array)
that is located on board in socket
XE41.
This micronote explains how to redefine the existing maps.
The equipment needed to custom build the FPLA is as follows:
1.
2.
3.
4.

Signetics NS82S100N FPLA.
Signetics NS82S100N FPLA worksheet.
PROM programmer that supports Si9netics NS82S100N FPLA.
User written routine to convert binary into hex form,
needed for the PROM programmer.

The Falcon or Falcon Plus can be configured to anyone of four standard
memory maps.
When you custom build the memory map FPLA, you may keep
this ability to select anyone of four memory map schemes, however it is
not nessecary to build in the four maps, you may build an FPLA with only
one map for the Falcon.
Further thE! addresses of the SLUs and Parallel
I/O Port can be be changed to some other addresses on the module, or
they can be relocated off the modulE! to some other device such as an
MXV11-A/B, DLV11-J, DRV11-J, etc.
The memory map is defined by:
1. Selecting a range of addresses, for example addresses 077777 - 037777.
This includes selecting the addrE!SSeS of the boards SLUs and PIO.
2. Asserting or deasserting the bits which define that range.
3. Defining which one of four memor)' maps the selected range of
addresses will respond.
4. Selecting an enable bit (A7 -AO), which tells the T-11 where to
find that range of addresses: on the Q-bus, on board the Falcon plus
in one of the two sockets, or i.n the local RAM.
When mapping an FPLA to be used with the KXT11-A2 or KXT11-AS ODT ROMs,
you must map addresses 177600 - 1.77777 to the local RAM that comes on
board the Falcon or Falcon plus. This space is used for a scratch pad
area by Macro ODT.
If Macro CDT is not going to be used than this
address range can be left to be selected by the user.
Beyond this all
addresses and functions can be mapped off board.

uNOTE i 007
Page 2 of 13
Below is an example of an FPLA worksheet that was completed specifying
one map (map 0) which maps all of memory to the O-bus, and changes the
address of SLU2 from 176540 - 176547, to 176500 - 176507.
This format
is simalar to the Signetics FPLA worksheet. For each address range
shown, the combination of bits set (H), cleared (L), or in the don't
care state (-) define that range.
Further each address range has
associated with it an output enable bit (A) that identifies the location
of the memory containing that range. It is possible to define larger or
smaller ranges then the ones shown here, if needed. More examples are
provided in the Falcon Plus User's Guide Appendix H.
THIS IS AN FPLA MAP FOR
COMPANY: XYZ

ADDRESS
RANGE

177600-177777
177570-177577
.177560-177567
.177540-177557
177500-177537
.177400-177477
177000-177377
.176600-176777
.176560-176577
.176550-176557
176540-176547
.176510-176537
.176500-176507
.176400-176477
176300-176377
176240-176277
176220-176237
176210-176217
176200-176207
176000-176177
.174000-175777
170000-173777
160000-167777
140000-157777
100000-137777
000000-077777

RAM
OS
OLO
OS
OB
OB
OB
OB
OB
OS
OB
OS
OL1
OB
OB
OB
OB
OS
PIO
OS
OS
OS
OS
OS
OS
OB

I I I I I I I I I I I I I

I I

000 001 0 1 0 1 010
7 8 6 9 5 0 4 1 322 3 1

101
504

F F F F F F F

1 1 1 1 1 1 0 0 0 0 0 0 0
5 4 321 0 9 8 7 6 543

000
210

7 6 5 4 321 0

- - - H H H H H H - - - - L L
- - - H H H H H L H H H H L L
- - - H H H H H L H H H L L L
- H H H H H L H H L - L L
- - - H H H H H L H L
L L
L L
- - - H H H H H L L - - - H H H H L - - - - - L L
L L
- H H H L H H - - - - H H H L H L H H H - L L
- - - H H H L H L H H L H L L
- - - H H H L H L H H L L L L
- - - H H H L H L H L - H L L
- - - H H H L H L H L L L L L
L L
- - - H H H L H L L - - - H H H L L H H - - - L L
L L
- - - H H H L L H L H
- H H H L L H L L H - L L
- - - H H H L L H L L L H L L
- - - H H H L L H L L L L L L
- - - H H H L L L - - - - L L
- - - H H L

- - - - -

- H L
- - - L -- - - - - - - H H L - - - - - - -

H L - - - - L - - - - - - - - - - - -

L L
L L
L L
L L
L L
L L

H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
H
L
L
L

A
A

A
A
A
A
A
A
A
A
A

A
A
A
A
A
A
A
A

A
A
A
A
A

7 6 5 4 321 0

00
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

uNOTE # 007
Page 3 of 13
Once the address ranges have been coded, they need to be converted into
the formatted file shown directly below. This file will be used as the
input file to a program (see end of Micronote) that will output the FPLA
terms in a format that is usable by the PROM Programmer itself. When
converting the above worksheet to FPLA terms, the following should be
considered:
1. The area at the beginning of the file may be used as a comment area
as long as the word "START" is not used in the comments. "START" is
the key word to begin'the formatting process while the word "END" is
the key word used to signal the formatter that the processing must be
terminated. Both words MUST appear in capital letters.
2. The layout of the map must be as follows:
115 114 113 112 III 110 109 lOa 107 106 105 104 103 102 101 100
07 06 05 04 03 02 01 00
115 114 113 112 III 110 109 loa 107 106 105 104 103 102 101 100
07 06 05 04 03 02 01 00

TERM1

I TERM2

Where 115 is input 15 on the FPLA ,114 is input 14 on the PLA etc.
further 07 is output 7 on the FPLA and 06 is output 6 on the PLA.
3

indicates a "DON'T CARE ON 'I'HAT INPUT" AND
CARE ON THIS OUTPUT".
"-"

* indicates a "DON'T

The following is the formatted FPLP.. map for the worksheet shown above.
Notice that bus address bit 00 is translated to FPLA bit 114, that bus
address 01 is translated to FPLA bit 100, that is, the bus address bits
are not directly translated to the FPLA bits, however the worksheet
activity (output) bits F7 - FO translate directly to FPLA bits A7 - AO.
START
LH--HHH---HHH--L

A*******

LHHHHHH---HHLHHL

*****A**

LHHHHHH---HHLHLL

**A*****

LHLHHHH---HHLH-L

*****A**

LH-HHHH---HHLL-L

*****A**

LH-LHHH---HHL--L

*****A**

LH--LHH---HH---L

*****A**

LH--HHH---HLH-L

uNOTE ~~ 007
Page 4 of 13

* * *,~ *A* *
LHHlIHHH--HLLH-L

*****A**
LHLHHHH--HLLHHL

*****A**
LHLHHHH--HLLHLL

*****A**
I"H-HHHH--HLLLHL

*****A**
I"HLHHHH--HLL;LLL

******A*
I"H-I.,HHH--HLL-L

***"*A**
I"H-HLHH--HLH-L

*****A**
LH-LLHH--HLHH-L

*****A**
LHHLLHH---HLHL-L

*****A**
I"HLI,LHH--HLHLHL

*****A**
I"HLI~LHH--HLHLLL

***A·****
I"H--LHH--HLL-L
***'~*A**

LH--LH--H--L

***"*A**
LH---H---L-----L
***'~*A**

LH--L

*****A**
I"L---HHL

***"*A**
LL---LH

*****A**
LL

*****A**

Translation: The following is a translation of FPLA terms and FPLA
activity outputs, and the actual pin name on the FPAL chip.
115 ..... 015 (02 on worksheet above) used for high order bit of map decode.
114o ••• LBS7 (00 on worksheet above) asserted for all I/O page addresses.
113
AD04
112 ..... AD06
I l l ..... ADOS
110 ..... AD10
109" ••• AD12
lOS" ••• AD14
107 ..••• AD15
to

•••

uNOTE i 007
Page S of 13
I 06 .... AD13
lOS •..• AD11
I 04 •.•• AD09
I 03 .... AD07
I 02 •... ADOS
I 01 .•.. AD03
IOO ••.. DO(Ol on worksheet above) used for the low order bit of map decode.
A7 .••.. F7
A6 •...• F6
AS ••••• FS
A4 ••... F4
A3 .•..• F3
A2 ••..• F2
A1 ...•• F1
AO ....• FO

on worksheet
on worksheet
on worksheet
on worksheet
on worksheet
on worksheet
on worksheet
on worksheet

above,
above,
above,
above,
above,
above,
above,
above,

used for local RAM enable.
used for socket A enable.
used for DLO enable.
used for PIO enable.
not used.
used for all Q-bus enables.
used for DL1 enable.
used for socket B enable.

The output file shown below is an example of one that would be loadable
into a PROM Programmer in order to blast the FPLA chip. An example of a
program that will produce the formatted output file shown below can be
found at the end of this micronote.
START
$AOOOO,
FF
$A100,
FF
00
FD
FB
F1
EF
7E
C1

ADDRESS )
FIRST 8 BITS
ADDRESS )

80
7F
00
FF
FF
FF
FF
FF
FF
FF
OTHER TERMS IN HEX BYTES

$A200

NEXT ADDRESS BOUNDARY )
TERMS )

uNOTE # 007
Page 6 of 13
$.A300

ADDRESS )

TERMS )

$A400

ADRESSS
TERMS )

ETC.
Once the FPLA is built, it is placed into socket XE41, the memory will
be configured to whatever the FPLA terms look like. The Falcon plus
needs to be strapped for a start address, a memory map (1 of 4)
that
matches the one called out in the FPLA, and other user configurable
options.
FPLA FORMAT PROGRAM

**********

1 REM THIS PROGRAM IS FOR NORMAL PLA MAP INPUTS
2 PRINT "INPUT DEVICE AND FILE NAME";H1$
4 INPUT H1$
5 OPEN H1$ FOR INPUT AS FILE #1
7 PRINT "DO YOU WISH OUTPUT COMPARE FILE ON LINE PRINTER,DEVICE,BOTH OR
NONE ? "
8 PRINT "DEFAULT IS NONE (LP,DEV,B,N) ";N1$
10 INPUT N1$
12 IF N1$-"LP" THEN GO TO 30
16 IF N1$-"DEV" THEN GO TO 36
20 IF N1$-"B" THEN GO TO 42
22 LET N$-"N"
23 LET K1$-"N"
2·4 GO TO 50
30 OPEN "LP:" FOR OUTPUT AS FILE #2
33 LET N$-"Y"
3·4 LET K1$-"N"
3S GO TO 50
36 PRINT "WHAT IS DEVICE AND FILE NAME";U1$ \ INPUT U1$
37 OPEN U1$ FOR OUTPUT AS FILE #3
38 LET N$-"N"
39 LET K1$-"yn
40 GO TO 50
42 OPEN "LP:" FOR OUTPUT AS FILE #2
4!5 LET N$-"Y"
46 PRINT "WHAT IS DEVICE AND FILE NAME";U1$ \ INPUT U1$
47 OPEN U1$ FOR OUTPUT AS FILE #3
48 LET K1$-"Y"
50 PRINT "WHAT DEVICE AND FILE NAME FOR OUTPUT PROM PROGRAMMER FILE";W$
52 INPUT W$
55 OPEN W$ FOR OUTPUT AS FILE #4
60 LET Y1-1
62 LET H1$-CHR$(2)
64 LET H2$-CHR$(3)

uNOTEI: 007

Page 7 of 13
66 LET Z$-CHR$(10)+CHR$(13)
68 LET L1$-" "
70 INPUT #l,A$
71 IF N$- t1 N" THEN GO TO 73
72 PRINT #2,A$
73 IF K1$-"N tl THEN GO TO 76
74 PRINT #3,A$
75 PRINT #4,A$
76 IF A$-"5TART" THEN GO TO 80
78 GO TO 70
80 LET 51$-"$AOOOO,"
82 PRINT #4,H1$;51$
84 PRINT #4,"FF "
86 LET 51$-"$A100,"
88 PRINT #4,51$
90 GO TO 92
91 PRINT #4,51$
93 INPUT #1,11$
92 IF I1$-"END" THEN GO TO 120
94 INPUT #1,01$
95 INPUT #1,12$
96 IF I2$-"END" THEN GO TO 130
97 INPUT #1,02$
98 INPUT #1,13$
99 IF I3$- t1 END" THEN GO TO 140
100 INPUT #1,03$
101 INPUT #1,14$
102 IF I4$-nENDn THEN GO TO 150
103 INPUT #1,04$
104 INPUT #1,15$
105 IF I5$_nEND" THEN GO TO 160
106 INPUT #1,05$
107 INPUT #1,16$
108 IF I6$-"END" THEN GO TO 170
109 INPUT #1,06$
110 INPUT #1,17$
111 IF I7$-"END" THEN GO TO 180
112 INPUT #1,07$
113 INPUT #1,18$
114 IF I8$-"END" THEN GO TO 190
115 INPUT #1,08$
117 GO TO 200
120 LET 11$-"0000000000000000 \
121 LET 12$-"0000000000000000 \
122 LET 13$-"0000000000000000 \
123 LET 14$-"0000000000000000 \
124 LET 15$-"0000000000000000 \
125 LET 16$-"0000000000000000 \
126 LET 17$-"0000000000000000 \
127 LET 18$-"0000000000000000" \
128 LET E1-1
129 GO TO 200

LET 01$-"AAAAAAAA"
LET 02$-"AAAAAAAA"
LET 03$-"AAAAAAAA n
LET 04$-"AAAAAAAA"
LET 05 $-" AAAAAAAA "
LET 06$-"AAAAAAAA"
LET 07 $-" AAAAAAAA "
LET 08 $-" AAAAAAAA "

uNOTE
007
Page 8 of 13
130 LET 12$-"0000000000000000 \ LET 02$-"AAAAAAAA"
132 LET 13$-"0000000000000000 \ LET 03$-"AAAAAAAA"
133 LET 14$-"0000000000000000 \ LET 04 $-" AAAAAAAA"
134 LET 15$-"0000000000000000 \ LET 05 $-" AAAAAAAA "
135 LET 16$-"0000000000000000 \ LET 06 $-" AAAAAAAA"
136 LET 17$-"0000000000000000 \ LET 07 $-" AAAAAAAA"
137 LET 18$-"0000000000000000 \ LET 08 $-" AAAAAAAA "
138 LET E1-1
139 GO TO 200
140 LET 13$-"0000000000000000" \ LET 03 $-" AAAAAAAA "
143 LET 14$-"0000000000000000" \ LET 04 $-" AAAAAAAA ,t
144 LET 15$-"0000000000000000" \ LET 05 $-" AAAAAAAA "
145 LET 16$-"0000000000000000" \ LET 06 $-" AAAAAAAA "
146 LET 17$-"0000000000000000" \ LET 07 $-" AAAAAAAA"
147 LET 18$-"0000000000000000" \ LET 08 $- 'f AAAAAAAA"
148 LET E1-1
149 GO TO 200
150 LET 14$-"0000000000000000" \ LET 04$-"AAAAAAAA"
154 LET 15$-"0000000000000000" \ LET 05 $-"AAAAAAAA "
155 LET 16$-"0000000000000000" \ LET 06$-"AAAAAAAA"
156 LET 17$-"0000000000000000" \ LET 07$-"AAAAAAAA"
157 LET 18$-"0000000000000000" \ LET 08$-"AAAAAAAA"
158 LET E1-1
159 GO TO 200
160 LET 15$-"0000000000000000" \ LET 05$-"AAAAAAAA"
165 LET 16$-"0000000000000000" \ LET 06 $-" AAAAAAAA "
166 LET 17$-"0000000000000000" \ LET 07 $- ff AAAAAAAA "
167 LET 18$-"0000000000000000" \ LET 08 $-" AAAAAAAA"
168 LET E1-1
169 GO TO 200
170 LET 16$-"0000000000000000" \ LET 06 $-" AAAAAAAA "
176 LET 17$-"0000000000000000" \ LET 07 $- 'f AAAAAAAA f'
177 LET 18$-"0000000000000000" \ LET 08 $-" AAAAAAAA"
178 LET E1-1
179 GO TO 200
180 LET 17$-"0000000000000000" \ LET 07 $-" AAAAAAAA "
187 LET 18$-"0000000000000000" \ LET 08$-"AAAAAAAA"
188 LET E1-1
189 GO TO 200
190 LET 18$-"0000000000000000" \ LET 08 $-" AAAAAAAA "
198 LET E1-1
200 PRINT 11$,01$,Z$,I2$,02$,Z$,13$,03$,Z$,14$,04$
210 PRINT 15$,05$,Z$,I6$,06$,Z$,I7$,07$,Z$,18$,08$
215 IF N$-"N" THEN GO TO 218
216 PRINT #2,Il$,Ol$,Z$,I2$,02$,Z$,I3$,03$,Z$,I4$,04$
217 PRINT #2,I5$,05$,Z$,16$,06$,Z$,I7$,07$,Z$,18$,08$
218 IF K1$-"N" THEN GO TO 221
219 PRINT #3,I1$,01$,Z$,I2$,02$,z$,13$,03$,Z$,I4$,04$
220 PRINT #3,15$,05$,Z$,16$,06$,Z$,17$,07$,Z$,18$,08$
221 LET X-16
235 LET Dl$-SEG$(I1$,X~X)
240 IF D1$-"H" GO TO 260

uNOTE # 007
Page 9 of 13
245
250
252
255
256
257
260
265
270
275
280
285
290
300
305
306
307
309
310
315
320
325
3-30
335
340
345
350
355
357
358
359
360
365
370
375
380
385
390
400
405
410
412
413
414
415
420
425
430
435
440
445
450

IF 01$-"L" GO TO 270
IF 01$-"-" GO TO 280
IF 01$-"0" GO TO 256
GO TO 1340
LET A(1,0)-1 \ LET A(1,1)m1
GO TO 285
LET A(1,0)-1 \ LET A(1,1)mO
GO TO 285
LET A(1,0)-0 \ LET A(1,1)m1
GO TO 285
LET A(1,0)-0 \ LET A(1,1).0
LET 02$-SEG$(I2$,X,X)
IF 02$-"H" GO TO 315
IF 02$-"L" GO TO 325
IF 02$-"-" GO TO 335
IF 02$-"0" GO TO 309
GO TO 1340
LET A(1,2)-1 \ LET A(1,3)-1
GO TO 340
LET A(1,2)-1 \ LET A(1,3)-0
GO TO 340
LET A(1,2)-0 \ LET A(1,3)-1
GO TO 340
LET A(1,2)-0 \ LET A(1,3)-0
LET 03$-SEG$(I3$,X,X)
IF 03$-"H" GO TO 365
IF 03$-"L" GO TO 375
IF 03$-"-" GO TO 385
IF 03$-"0" GO TO 359
GO TO 1340
LET A(1,4)-1 \ LET A(1,5)-1
GO TO 390
LET A(1,4)-1 \ LET A(1,5)-0
GO TO 390
LET A(1,4)-0 \ LET A(1,5)-1
GO TO 390
LET A(1,4)-0 \ LET A(1,5)-O
LET 04$-SEG$(I4$,X,X)
IF 04$-"H" GO TO 420
IF 04$-"L" GO TO 430
IF 04$_"_" GO TO 440
IF 04$-"0" GO TO 414
GO TO 1340
LET A(1,6)-1 \ LET A(1,7)-1
GO TO 445
LET A(1,6)-1 \ LET A(1,7)-O
GO TO 445
LET A(1,6)-0 \ LET A(1,7)-1
GO TO 445
LET A(1,6)-0 \ LET A(1,7)-O
LET A8-A(1,0)*1+A(1,2)*2+A(1,4)*4+A(1,6)*8
LET A9-A(1,1)*1+A(1,3)*2+A(1,5)*4+A(1,7)*8

uNOTE # 007
Page 10 of 13
455 LET A8-15-A8 \ LET A9-15-A9
460 LET 05$-SEG$(I5$,X,X)
465 IF 05$-"H" GO TO 485
470 IF 05$-"L" GO TO 495
475 IF 05$-"-" GO TO 505
476 IF 05$-"0" GO TO 479
477 GO TO 1340
479 LET B(1,0)-1 \ LET B(1,1)=1
480 GO TO 510
485 LET B(1,0)-1 \ LET B(1,1)-0
490 GO TO 510
495 LET B(1,0)-0 \ LET B(1,1)-1
500 GO TO 510
505 LET B(1,0)-0 \ LE~ B(1,1)-0
510 LET 06$-SEG$(I6$,X,X)
515 IF 06$-"H" GO TO 535
520 IF 06$-"L" GO TO 545
525 IF 06$-"-" GO TO 555
526 IF 06$-"0" GO TO 529
527 GO TO 1340
529 LET B(1,2)-1 \ LET B(1,3)-1
530 GO TO 560
535 LET B(1,2)-1 \ LET B(1,3)-0
540 GO TO 560
545 LET B(1,2)-0 \ LET B(1,3)-1
550 GO TO 560
555 LET B(1,2)-0 \ LET B(1,3)-0
560 LET 07$-SEG$(I7$,X,X)
565 IF 07$-"H" GO TO 585
570 IF 07$-"L" GO TO 595
575 IF 07$-"-" GO TO 605
576 IF 07$-"0" GO TO 579
577 GO TO 1340
579 LET B(1,4)-1 \ LET B(1,5)-1
580 GO TO 610
585 LET B(1,4)-1 \ LET B(1,5)-0
590 GO TO 610
595 LET B(1,4)=0 \ LET B(1,5)=1
600 GO TO 610
605 LET B(1,4)-0 \ LET B(1,5)-0
610 LET 08$-SEG$(I8$,X,X)
615 IF 08$-"H" GO TO 635
620 IF 08$-"L" GO TO 645
625 IF 08$-"-" GO TO 655
626 IF 08$-"0" GO TO 629
627 GO TO 1340
629 LET B(1,6)-1 \ LET B(1,7)=1
630 GO TO 660
635 LET B(1,6)=1 \ LET B(1,7)=0
640 GO TO 660
645 LET B(1,6)-0 \ LET B(1,7)-1
650 GO TO 660

uUO!'E i 007
Page 11 of 13
655 LET B(1,6)-0 \ LET B(1,7)=0
660 LET B8-B(1,0)*1+B(1,2)*2+5(1,4)*4+B(1,6)*8
665 LET B9-B(1,1)*1+B(1,3)*2+5(1,5)*4+B(1,7)*8
670 LET B8-15-B8 \ LET B9-15-59
675 IF B8<10 THEN LET P1-0
680 IF B8<10 THEN GO TO 720
685 IF B8-10 THEN LET B8$-nAn
690 IF B8-11 THEN LET B8$-"B"
695 IF B8-12 THEN LET B8$-"C"
700 IF B8-13 THEN LET B8$-"0"
705 IF B8-14 THEN LET B8$-"E n
710 IF B8-15 THEN LET B8$-nFn
715 LET P1-1
720 IF A8<10 THEN LET PO-O
725 IF A8<10 THEN GO TO 765
730 IF A8-10 THEN LET A8$_nA n
735 IF A8-11 THEN LET A8$_nB n
740 IF A8-12 THEN LET A8$-"C"
745 IF A8-13 THEN LET A8$_nO"
750 IF A8-14 THEN LET A8$-"E"
755 IF A8-15 THEN LET A8$-"F"
760 LET PO-1
765 IF P1-0 THEN GO TO 780
770 IF PO-O THEN GO TO 805
775 GO TO 795
780 IF PO-1 THEN GO TO 815
785 PRINT #4,STR$(B8);STR$(A8);L1$
790 GO TO 820
795 PRINT #4,B8$iA8$;L1$
800 GO TO 820
805 PRINT #4,B8$;STR$(A8);L1$810 GO TO 820
815 PRINT #4,STR$(B8);A8$;L1$
820 IF B9<10 THEN LET P3-0
825 IF B9<10 THEN GO TO 865
830 IF B9-10 THEN LET B9$_nA"
835 IF B9-11 THEN LET B9$-"B"
840 IF B9-12 THEN LET B9$-"C~
845 IF B9-13 THEN LET B9$-"On
850 IF B9=14 THEN LET B9$-"E"
855 IF B9-15 THEN LET B9$-"F"
860 LET P3-1
865 IF A9<10 THEN LET P2=0
870 IF A9<10 THEN GO TO 910
875 IF A9-10 THEN LET A9$_nA"
880 IF A9-11 THEN LET A9$-"B"
885 IF A9-12 THEN LET A9$-"C"
890 IF A9-13 THEN LET A9$-"0"
895 IF A9-14 THEN LET A9$-nEn
900 IF A9-15 THEN LET A9$-"F"
905 LET P2-1
910 IF P3-0 THEN GO TO 925

uNOTE # 007
Page 12 of 13
915 IF P2-0 THEN GO TO 945
920 GO TO 937
925 IF P2-1 THEN GO TO 955
930 PRINT #4,STR$(B9);STR$(A9);L1$
935 GO TO 960
937 PRINT #4,B9$;A9$;L1$
940 GO TO 960
945 PRINT #4,B9$;STR$(A9);L1$
950 GO TO 960
955 PRINT #4,STR$(B9);A9$;L1$
960 LET X-X-1
965 IF X>O THEN GO TO 235
970 LET Y-B
975 LET C1$-SEG$(01$,Y,Y)
980 IF C1$-"A" THEN LET A1-1
985 IF C1$-"*" THEN LET A1-0
990 LET C2$-SEG$(02$,Y,Y)
995 IF C2$-"A" THEN LET A2-1
1000 IF C2$-"*" THEN LET A2-0
1005 LET C3$-SEG$(03$,Y,Y)
1010 IF C3$-"A" THEN LET A3-1
1015 IF C3$-"*" THEN LET A3-0
1020 LET C4$-SEG$(04$,Y,Y)
1025 IF C4$-"A" THEN LET A4-1
1030 IF C4$-"*" THEN LET A4-0
1035 LET C5$=SEG$(05$,Y,Y)
1040 IF C5$-"A" THEN LET A5-1
1045 IF C5$-"*" THEN LET A5-0
1050 LET C6$=SEG$(06$,Y,Y)
1055 IF C6$-"A" THEN LET A6-1
1060 IF C6$_n*n THEN LET A6-0
1065 LET C7$-SEG$(07$,Y,Y)
1070 IF C7$-nAn THEN LET A7-1
1075 IF C7$_n*n THEN LET A7-0
lOBO LET CB$-SEG$(OB$,Y,Y)
lOBS IF CB$_nA n THEN LET FB-1
1090 IF CB$_n*n THEN LET FB-O
1095 LET 09-(A1*1)+(A2*2)+(A3*4)+(A4*B)
1100 LET P9-(A5*1)+(A6*2)+(A7*4)+(FB*B)
1105 LET 09-15-09 \ LET P9-15-P9
1110 IF P9<10 THEN LET T1-0
1115 IF P9<10 THEN GO TO 1155
1120 IF P9-10 THEN LET P9$_nAn
1125 IF P9-11 THEN LET P9$_nBn
1130 IF P9-12 THEN LET P9$-nC n
1135 IF P9-13 THEN LET P9$_nDn
1140 IF P9-14 THEN LET P9$-nEn
1145 IF P9-15 THEN LET P9$-nFn
1150 LET T1-1
1155 IF 09<10 THEN LET TO-O
1160 IF 09<10 THEN GO TO 1200
1165 IF 09-10 THEN LET 09$-nAn

uNOTE i 007
Page 13 of 13
1170
1175
1180
1185
1190
1195
1200
1205
1210
1215
1220
1225
1230
1235
1240
1250
1255
1260
1265
1270
1275
1280
1285
1290
1295
1300
1305
1310
1315
1320
1330
1335
1340
1345

IF 09-11 THEN LET 09$-nBn
IF 09-12 THEN LET 09$-nC n
IF 09-13 THEN LET 09$-"0"
IF 09-14 THEN LET 09$-nEn
IF 09-15 THEN LET 09$-"F"
LET TO-1
IF T1=0 THEN GO TO 1215
IF TO=O THEN GO TO 1240
GO TO 1230
IF TO-1 THEN GO TO 1255
PRINT i4,STR$(P9);STR$(09);L1$
GO TO 1260
PRINT i4,P9$;09$;L1$
GO TO 1260
PRINT i4,P9$;STR$(09);L1$
GO TO 1260
PRINT i4,STR$(P9);09$;L1$
I,ET Y-Y-1
IF Y>O THEN GO TO 975
PRINT i4,Z$
LET Y1-Y1+1
IF Yl-2 THEN LET Sl$-n$A200,"
IF Yl-3 THEN LET Sl$-"$A300,"
IF Y1=4 THEN LET Sl$-n$A400,"
IF Y1=5 THEN LET Sl$-"$A500,"
IF Yl-6 THEN LET Sl$-"$A600,"
PRINT i4,Z$
IF Y1=7 THEN GO TO 1320
IF E1=0 THEN GO TO 91
PRINT i4,H2$
CLOSE
GO TO 1345
PRINT "INPUT LINE IN ERROR"
END

uNOTE # 008

Title: Memory Management and the LSI-11/73

Date: 22-Jun-84

Originator: Dave Smith

Page 1 of 11

This micronote explains memory management as it applies to
the
LSI-11/73.
It includes descriptions of what memory management is, what
it does, and how it works.
Simply stated, memory management is a method of mappi~g virtual
addresses to physical addresses. The virtual address space 1S the view
of memory as seen by a process running. The physical address space is
the actual physical memory as seen by the entire system. Since ALL
memory references must be mapped, this translation is done in hardware
by using a Memory Management Unit (MMU). Various schemes (dependent
upon the architecture) have been df~veloped to accomplish this, but most
memory management systems provide the following services:
1) Protection
2) Relocation
3) Segmentation
The first two are of great importance in a multiprogramming system since
memory management provides the mf~chanism for assigning memory areas to
user programs and for preventing users from accessing areas that have
been assigned to other users.
This protects the operating system
executive as well as users from accidental or willful memory accesses
outside of a user's assigned memory. Relocation is also important in a
multiprogramming environment since the executive must be able to
relocate the user's program to a free area in physical memory.
The LSI-11/73 Memory Management Unit provides the hardware for complete
memory management by providing all of the above services.
It is
software compatible with the largl~r UNIBUS PDP-11s and other Q-bus
processors.
Since the LSI-11/73 has the PDP-11 architecture and a
16-bit program counter, all 16-bit addresses access a 64Kb virtual
address space. On the LSI-11/73 this addressing limitation can be eased
by using separate sets of memory management registers for instructions
(I-space) and for data (D-space).
By utilizing separate I- and Dspace, the address space can be segmented into two 64Kb segments,
effectively doubling the virtual address space. The LSI-11/73 and the
Q-bus allow 4 Mb of memory to be rl~ferenced. The MMU is necessary to
provide the mapping from the 64Kb virtual address space to the 4 Mb
physical address space.

uNOTE # OOS
Page 2 of 11
When the MMU is activated, a 16-bit virtual address is mapped to an
lS-bit or 22-bit physical address.
Th~ MMU uses registers known as
Active Page Registers (APRs). An APR consists of two 16-bit registers
which are called the Page Address Register (PAR) and the Page Descriptor
Register (PDR).
PARs are used in the actual address translation while
PDRs contain access and other information.
Since the LSI-11/73 is
functionally equivalent to the PDP-11/70, it can operate in one of three
modes:
Kernel,
Supervisor, or User and it can use 1- and D- space.
This means that the MMU must provide separate sets of registers for each
mode and within each mode,
sets of registers for I-space and for
D-space. A set of registers consists of eight pairs of PDRs and PARs.
Thus the LSI-11/73 MMU has a total of three sets of 32 16-bit registers.
Mapping is always done in pages of 8Kb (4K words) in length or less.
In
order to map the largest possible virtual address space (64 Kb), the
address space is divided into eight pages of 8Kb each. One APR is used
fo[, each of the eight pages, numbered 0 to 7. The uppermost page in
physical memory is called the I/O page and is usually mapped by a Kernel
Mode APR since it is a privileged area.
PHYSICAL
ADDRESS
SPACE

4 Mb
I/O page

USER MODE

<-----

page 7

KERNEL MODE

APRs

PAR7

PAR6

PARS

PAR4

PAR3

<-----

PAR2
PAR1
PARO

PAR2
PAR1

PARO

uNOTE # 008
Page 3 of 11
The Page Address Register consists solely of the Page Address Field
(PAF).
If 22-bit addressing is enabled, then all 16 bits of the PAR are
used as the PAF.
If only 18-bit addressing is desired then the 12 lower
order bits are the PAF and the 4 higher order bits are unused.
It may
be thought of as a base register containing a base address or as a
relocation register containing a relocation constant.
PAGE ADDRESS REGISTER

(PAR)

[+--+-;~GE+AD;RE;;-;IE~~~PA;-)-+--+--+--+--+J
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The Page Descriptor Register contains
length, and expansion direction:

information

about

access,

PAGE DESCRIPTOR REGISTER (PDR)
15 14

08 07 06 05 04 03 02 01 00
+--+--+--+--+--+

Be PAGE LENGTH FIELD I 01 wi 01 olEol A~~
~
+--+--+--+--+--+
PDR <15>

(Bypass Cache)

Set if memory accessing is wished to be
without utilizing the cache. Useful with
dual-ported memories.
PDR <08:14>

PLF

(Page Length Field)

Specifies the authorized length of the page
in 32 word (or 64 byte) groups.

<-->

177 (8) <-->

32 word page
4096 word page

page

uNOTE # 008
Page 4 of 11
PDR <06>

(Written Into)

Useful in determining whether or not a page can
simply be erased or must be saved to be brought
back into memory.

PDR <03>

PDR <01:02>

Page has NOT been written into
Page has been written into

0
1

<->
<->

(Expansion Direction)

<->

ACF

(Access Control Field)

00
01
10
11

<->
<->
<->
<->

Expands to higher addresses
(Normally used)
Expands to lower address-es
(Can be used for stack segments)

Nonresident
Resident - Read Only
Not Used
Resident - Read/Write

The 16-bit virtual address is divided into three fields:
VIRTUAL ADDRESS (VA)
13 12

APF

6 5

DIB

<------DISPLACEMENT FIELD (DF)---->
o APF or Active Page Field
These three bits determine which of the eight
APRs are selected.
o BN or Block Number
The PAF determines an 8 Kb page in memory.
The BN is that offset that is added to the base
of ,the page determined by the PAF to obtain the
block within the page to map.

uNOTE # 008
Page 5 of 11
o DIB or Displacement In the Block
Tells exactly which one of the 32 words is being
mapped to. The low order 6 bits (DIB) are never
relocated.
The BN and DIB fields are collectively referred to as the
Displacement Field (OF).
If the MMU is not activated then 16-bit virtual addresses are also
16-bit physical addresses and linearly map the 64Kb address space. When
the MMU is activated the 16-bit virtual address (VA)
is no longer
interpreted as a physical address Instead, the physical address (PA) is
constructed using the VA and the PAF (Page Address Field) of the
selected PAR.
The translation of virtual addresses to
accomplished as follows:

22-bit

physical

addresses

1) A set of registers is selected. This is determined by
the space being referenced (Instructions or Data) and by
the mode bits of the Processor status Word (PSW <15:14».

2) The APF field of the virtual address determines which of the
eight pairs in the selected set will be used for the mapping.
3) The PAF of the selected register pair contains the starting
address of the currently active page as a block number.
4) The block number from the virtual address and the block number
from the PAF are added together. The block number from the PAF
is shifted left by six bits in order to perform this addition.
The result is the actual physical block number (bits <21:06>
of the physical address).
5) The DIB of the virtual address is carried along unchanged as
bits <05:00> of the translated address.

uNOTE # 008
Page 6 of 11
VIRTUAL TO PHYSICAL ADDRESS TRANSLATION
16-BIT VIRTUAL ADDRESS

15
[

+-+I+-+-+-+-+-+I+-+-+-+--+]
APF
BN
DIB
+-r--+
+-+-+ +-+-+
+-+_.+-+ +

Selects
APR

PAGE ADDRESS REGISTER

+--+--+--+--+-+-+-+--+-+-+-+-+-+-+]
[

+--+--+--+--+--+--+~+-+-+-+-:+-+--+<--+--------~

21
[

+--+--+-+-+-+-+
+-+-+-+-+-+-+]
BLOCK NUMBER IN PHYSICAL MEMORY
+--+--+--+-+--+--+--+--+--+-+-+-+-+-+

DIB
[
. +--+-+--+-+
+--+~+--+

<---------------- 22-BIT PHYSICAL ADDRESS (PA) ------------------------>

uNOTE # 008
Page 7 of 11
There are four memory management registers that are used for memory
fault recovery and abort and status information as well as control of
the MMU.
They are called MMRO, MMR1, MMR2, and MMR3.
Memory Management Register 0 (MMRO)
register.

the

main

control

and

status

MEMORY MANAGEMEN'T REGISTER 0 (MMRO)
15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00

1 1 1 1 01 01 01 01
MMRO <15>

o~: 1 1

:=:IJ

NONRESIDENT ABORT
Set if an attempt is made to access a page
with an ACF of 0 or 2 or if the PSW indicates
mode 2.

MMRO <14>

PAGE LENGTH ABORT
Set if an attempt is made to access a location
whose block numbE!r is outside the area authorized
by the PLF of the PDR for that page.

MMRO <13>

READ ONLY ABORT
Set if an attempt is made to write to a page with
an ACF of 1 (Read Only).

MMRO <06:05>

PROCESSOR MODE
Copy of the PSW <15:14> when abort occurred.

MMRO <04>

PAGE SPACE
1

MMRO <03:01>

<->
<->

I)-space
I-space

PAGE NUMBER
page Number of page causing the abort.
Copy of APF of virtual address.

uNOTE ~~ 008
Page 8 of 11
ENABLE RELOCATION

MMRO <00>

<->

ALL addresses are relocated
(MMU activated)
NO addresses are relocated
(MMU disabled)

Memory Management Register 1 (MMR1) is called the Instruction Backup
Register.
It records any autoincrement or autodecrement of any general
purpose register. The lower byte is used for source operands and the
destination
operand
may be in either byte, dependent upon the
instruction.
MEMORY MANAGEMENT REGISTER 1 (MMR1)
15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
+--+-+-+--r--+-+--r--+-+--+-+--r--+--+]
[

+-+--+-+~+--+~+--+--+--+~+-.-+

MMR1 <15:11>

AMOUNT CHANGED (2's complement)

MMR1 <10:08>

MMR1 <07:03>

AMOUNT CHANGED (2's complement)

MMR1 <02:01>

Memory Management Register 2 (MMR2) is known as the Last Virtual program
Counter.
It is loaded with the value of the program Counter at the
beginning of each instruction fetch and is used in instruction fault
recovery_

uNOTE # 008
Page 9 of 11
Memory Management Register 3 (MMlt3) is used to select 1S-bit or 22-bit
address mapping and is used to onable/disable the data space for any of
the processor modes.
MEMORY MANAGEMl~NT REGI STER 3 (MMR3)

:=:J

15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00

/ 0/ 0/ 0/ 01 0/ 0/ 0/ 0/ 0/ 0/
MMR3 <05>

1 1 1

UNINTERPRETED
May be set or cleared but is not interpreted.

MMR3 <04>

ENABLE 22-BIT ]~PPING
1

MMR3 <03>

MMR3 <01>

MMR3 <00>

Mapping is to 22-bit space.
Mapping is to 1S-bit space.

ENABLE CSM (Call Supervisor Mode) INSTRUCTION
1

MMR3 <02>

<->
<->

CSM is recognized.
CSM is ·not recognized.

KERNEL DATA SPJ~CE
1

<->

Enable data space mapping in
Kernel Mode
Disable data space mapping in
Kernel Mode

SUPERVISOR DAT.A SPACE
1

<->

Enable data space mapping in
Supervisor Mode
Disable data space mapping in
Supervisor Mode

USER DATA SPACE
1

<->

Enable data space mapping in
User Mode
Disable data space mapping in
User Mode

uNOTE # 008
Page 10 of 11

Summary:
The LSI-11/73 Memory Management unit provides a powerful,
general
purpose tool for memory management~
It can be used to expand memory in
a simple way and it can be used in a multiprogramming system to provide
all the services necessary for an efficient and secure environment.
The following is a simple MACRO-11 program which illustrates the method
of setting up the registers and performing some mappings.
It writes a
known value to an unmapped location and sets up the MMU registers and
turns on the unit.
It then writes another known value to the same
virtual address which is now mapped. Then it turns the MMU off.
At
this point the two known valuas are in different memory locations .
. TITLE

MMU

;

;
;

Program to demonstrate setting up MMU registers
and to illustrate the mapping that takes place

;

PSW
MMRO
PDRO
PARO
PAR1
PAR7

-=-

177776
177572
172300
172340
172342
172356

Processor status Word
Memory Management Register 0
Page Descriptor Register 0
Page Address Register 0
Page Address Register 1
Page Address Register 7

; INSURE THAT MMU IS NOT ACTIVATED
START:: CLR

@#MMRO

CLEAR MMRO

; STORE A KNOWN VALUE (152152) IN UNMAPPED LOCATION 20000
MOV

#152152,@#20000

SET PSW TO KERNEL MODE
BIC

#140000,@#PSW

; SET THE PARS SO THAT EACH PAGE MAPS TO ITSELF

LOOPl:

MOV
MOV
CLR

#PARO,R5
#10,R4
R3

MOV

R3, ( R5 ) +

ADD
SOB

#200,R3
R4,LOOPl

SET UP PAR POINTER
SET UP PAR COUNTER
SET UP PAR OFFSET VALUE
SET EACH RELOCATION CONSTANT TO
MAP TO ITSELF
UPDATE OFFSET
DO ALL OF THEM

uNOTE # 008
Page 11 of 11
;

SET PAR1 TO MAP PAGE 1 TO PAGE 2
MOV

#400,@#PAR1

SET PAR7 TO MAP THE I/O PAGE TO THE TOP OF MEMORY
MOV

#7600,@#PAR7

172356 POINTS TO 760000

SET UP THE PDRS
;

; 77406 (8) - 0 111 111 100 000 110 (2)

RESIDENT - READ/WRITE
UPWARD EXPANDING
NOT WRITTEN INTO
8KB PAGE SIZE
DON'T BYPASS CACHE

;
;
;
;
;

LOOP2:

MOV
MOV

#PDRO,R5
#10,R4

SET UP PDR POINTER
SET UP PDR COUNTER

MOV
SOB

#77406,(R5)+
R4,LOOP2

SET EACH PDR
DO THEM ALL

; ENABLE THE MMU
INC

@#MMRO

; SET BIT 0 OF MMRO

; WRITE A VALUE TO LOCATION 20000. THIS SHOULD BE MAPPED.
MOV

#107010,@#20000; WRITE 107010 TO MAPPED 2000

DISABLE THE MMU
DEC

@#MMRO

; CLEAR BIT 0 OF MMRO

; AT THIS POINT IN THE PROGRAM, ;E:XAMINING PHYSICAL
ADDRESS 20000 SHOWS THE VALUE OF 152152 WHICH WAS PLACED THERE
; ADDRESS 40000 (WHICH 20000 MAPPED TO) HOLDS THE VALUE 107010
HALT
.END

START

uNOTE # 009

Title: Cache Concepts and the LSI-ll/73

Date: 02-JUL-84

Originator: Charlie Giorgetti

Page 1 of 6

The goal is to introduce the concept of cache and its particular
implementation on the LSI-ll/73 (KDJll-A).
This is not a detailed
discussion of the different cache organizations and their impact on
system performance.
What Is A Cache ?
The purpose of having a cache is to simulate a system having a large
amount of moderately fast memory. To do this the cache system relies on
a small amount of very fast, easily' accessed memory (the cache), a
larger amount of slower, less expensive memory (the backing store), and
the statistics of program behavior.
The goal is to store some of the data and its associated addresses in
the cache and all of the data at its usual addresses (including the
currently cached data) in the backing store. If it can be arranged that
most of the time when the proces.sor needs dat, it is located in fast
memory, then the program will execute more quickly, slowing down only
occasionally for main memory operations.. The placement of data in the
cache should not be a concern to the programmer but is a consequence of
how the cache functions.
Figure 1 is an example of a memory organization showing a cache with
backing store.
If the data needed by the microprocessor (uP) can be
found in the cache then it is accessed much faster due to the local data
path and faster cache memory than by having to access the backing store
on the slower system bus.

c::J
uP

CPU Internal Buses C]yrstem
>
Bus
Interface

System Bus
For Memory and I/O Options

Fast Path
to Cache

System Memory
(Backing Store)
Cache

Figure 1 - An Example Memory System with Cache

uNOTE # 009
Page 2 of 6
cache memory system can only work if it can successfully predict most
of the time what memory locations the program will require. If a
program accessed data from memory in a completely random fashion, it
would be impossible to predict what data would be needed next. If this
was the case a cache would operate no better then a conventional memory
system.

Pr()grams rarely generate random addresses. In many cases the subsequent
memory address referenced is often very near the current address
accessed. This is the principle of program locality. The next address
generated is in the neighborhood of the current address. This behavior
helps makes cache systems feasible.
concept of program locality is not always adhered to, but is a
statement of how many programs behave. Many programs execute code in a
linear fashion or in loops with predictable results in next address
generation.
Jumps and context switching give the appearance of random
address generation. The ability to determine what word a program will
reference next is never completely successful and therefore the correct
"guesses" are a statistical measure of the size and organization of the
cache, and the behavior of the program being executed.
Th~!

The measure of a cache performance is a statistical evaluation of the
number of memory references found versus not found in cache. When
memory is referenced and the address is found in the cache this is known
as a hit.
When it is not it is termed a miss. Cache performance is
usually stated in terms of the hit ratio or the miss ratio where these
are defined as:

Hit Ratio =

Miss Ratio =

Number of Cache Hits
Total Number of Memory References

Hit Ratio

The LSI-11/73 Cache

Impl~mentation

cache organization chosen must be one that can be implemented within
the physical and cost constraints of the design.

ThE~

ThE~ LSI-11/73 implements a direct map cache.
A direct map
organization
has a single unique cache location for a given address and this is where
thE! associated data from backing store are maintained.
This means an
access to cache requires one address comparison to determine if there is
a hit. The significance of this is that a small amount of circuitry is

uNOTE # 009
Page 3 of 6
required to perform the comparison operation. The LSI-11/73 has an 8
KByte cache. This means that therle are 4096 unique address locations
each of which stores two bytes of information.
The cache not only maintains the d.ata from backing store but it also
includes other information that is needed to determine if its content is
valid. These are parity detection and valid entry checking.
The
following diagram shows the logical layout of the cache and what each
field and its associated address in the cache is used for.
Binary Cache
Entry Address

000000000000
000000000001
000000000010

111111111101
111111111110
111111111111
Figure 2 ~ LSI-11/73 Cache Layout
The Cache Entry Address is the address of one of 4096 entries within the
cache.
This value has a one-to-one relationship with a field in each
address that is generated by the processor (described in the next
section on how the physical address accesses cache).
Each field has the following meaning:
Tag (TAG) - This nine bit field contains information that is
compared to the address label, described in the next section on
how the physical address accesses cache.
When the physical
address is generated, the address label is compared to the tag
field.
If there is a match it can be considered a hit provided
that there is entry validation and no parity errors.
Cache Data (BO and B1) - These two bytes
stored in cache.

are

the

actual

data

uNOTE # 009
Page 4 of 6
Valid Bit (V) - The valid bit indicates whether the information
in BO and B1 is usable as data if a cache hit occurs. The valid
bit is set when the entry is allocated during a cache update
which occurs as a result of a miss.
Tag Parity Bit - (P) - Even
stored in the tag field.

parity

calculated

for

the

value

parity Bits (PO and P1) - pO is even parity calculated for the
data byte BO and P1 is odd parity calculated for the data byte
B1.
When the processor generates a physical address,
the on-board cache
control logic must determine if there is a hit by looking at the unique
location in cache. To determine what location to check,
the cache
control logic considers each address generated as being made up of three
unique parts. The following are the three fields of a 22-bit address
(in an unmapped or lS-bit environment the label field is six or four
bits less respectfully):
21 20 19 18 17 16 15 14 13

12 11 10 09 OS 07 06 05 04 03 02 01

1<------------- INDEX ----------->1

LABEL -------->1

BYTE,
SELEC~

Figure 2 - Components of a 22-bit Address For Cache Address Selection
Each field has the following meaning:
Index - This twelve bit field determines which one of the 4096
cache data entries to compare with for a cache hit. The index
field is the displacement into the cache and corresponds to the
Cache Entry Address.
Label - Once the location in the cache is selected, the nine bit
label field is compared to the tag field stored in the cache
entry under consideration.
If the address label and the tag
field match, the valid bit is set, and there is no parity error,
then a hit has occurred.
Byte Select Bit - This bit determines if the reference is on an
odd or even byte boundary. All Q-bus reads are word only so
this bit has no effect on a cache read. Q-bus writes can access
either words or bytes.
If there is a word write the cache will
be updated if there is a hit.
If there is a miss a new cache
entry will be made.
If there is a byte write, the cache will
only be updated if there is a hit. A miss will not create a new
entry on a byte write.

uNOTE # 009
Page 5 of 6
The LSI-ll/73 direct map cache mu:;t update the backing store on a memory
write.
The LSI-ll/73 uses the write through method.
With this
technique, writes to backing store occurs concurrently with cache
writes.
The result is that the backing store always contains the same
data as the cache.
Features Of The LSI-ll/73 Cache
The LSI-l1/73 direct map cache has a number of features that assist in
the performance of the overall system in addition to the speed
enhancement as a result of faster memory access. These features consist
of the following:
o Q-bus OMA monitoring
o I/O page reference monitoring
o Memory management control of cache access
o Program control of cache parameters
o Statistical monitoring of cache performance
The LSI-ll/73 cache control logic monitors the Q-bus during OMA
transactions.
When an address that has its data stored in cache is
accessed during OMA, the cache a:nd backing store contents might no
longer be the same.
This is an unacceptable situation. The cache
control logic invalidates a cache entry if the address is used during
OMA.
This also includes addresses used during Q-bus Block Mode OMA
transfers.
Memory referen 7es to the I/O page are not cached since that data is
volatile, meanlng its contents can change without a Q-bus access. Since
the cache could end up with stale data, I/O references are not cached.
There are situations for which using the cache to store information for
faster access is not desirable. An example is a device that resides in
the I/O page, and is true in other instances as well. One situation is
a device that does not reside in the I/O page but can change its
contents without a bus reference, such as dual ported memory.
Another situation is partitioning and tuning an application
for
instruction code execution versus data being manipulated.
In this case
the instruction stream may execute many times over for different data
values.
Speed enhancement can be obtained if the instructions are
cached while the data is not cached. By forcing the data never to be
cached it cannot replace instructions in the cache.
The memory management unit (MMU) of the LSI-l1/73 can assist in this
situation.
Pages of memory allocated for data can be marked to bypass
the cache and therefore not effect instructions that loop many times.
The cache and the MMU work together to achieve the goal of increased
system performance.
The dynamics of cache operation are under program control through use of
the Cache Control Register (CCR), an LSI-ll/73 on-board register. This

uNOTE # 009
Page 6 of 6
register can "turn" the cache on or off, force cache parity errors for
diagnostic testing, and invalidate all cache entries. The details of
the CCR are described in the KDJll-A CPU Module User's Guide (part
number EK-KDJ1A-UG-001).
During system design or at run-time the performance enhancements
provided by the cache system can be monitored under program control.
This is accomplished by using another LSI-ll/73 on-board register the
Hit/Miss Register (H~R).
This register tracks the last six memory
references and indicates if a hit or miss took place.
The details of
the HMR are also described in the KDJll-A CPU Module User's Guide.
Summary
Caches are a mechanism that can help improve overall system performance.
The dynamics of a given cache are dictated by the organization and the
behavior of the programs running on the machine. The LSI-ll/73 cache is
designed to be flexible in its use,
simple in implementation, and
enhance application performance.
More detailed discussions on how caches work
and
other
cache
organizations can be found in computer architecture texts that have a
discussion of memory hierarchy.

uNOTE

* 010

Title: MicroVAX I/O Programming

Date: 27-JUL-84

Originator: Peter Jonhson

Page 1 of 5

The Qbus MicroVax implements the full Vax memory management, so virtual
addresses are translated to physical addresses - just as they are for
the Vax minicomputers. When memory management is enabled,
system and
process space virtual addresses ,are translated into physical addresses
and sent onto the Qbus. Normally,
the programmmer need not concern
himself with this translation ,as this is completely handled by the
operating system; however, when accessing locations in the I/O space
directly the programmer must concern himself with the mapping since
specific information must be supplied by the programmer to MicroVMS in
order for it to successfully map the user's virtual addresses into the
I/O space. The process of mapping a virtual address to a physical
address must start by determining the physical address that you wish to
access.
In our case this means that we must calculate a Qbus MicroVax
physical address given that we know the address that the Qbus board is
configured to.
In order to do this we must know a few key facts about
the Qbus MicroVax architecture.

1) The Qbus MicroVax I/O space begins at physical 20000000 (hex)
2) The I/O space of a Qbus MicroVax is largely empty containing
only Q22 bus I/O space which is SK bytes long

Given these two pieces of information we now know that the I/O space for
the Qbus MicroVax starts at physical 20000000 (hex) and extends to
20001FFF (hex). This I/O space directly corresponds to the configurable
addresses on Qbus option boards 160000-177777 (oct).
In order to
convert any Qbus option address to a Qbus MicroVax address one simply
subtracts 160000 from the boards configured address to get its offset
into the I/O space and then add this value to the base of the Qbus
MicroVax I/O space. For example, let us consider a board which has been
configured to-166540.
In order to calculate its equivalent Qbus
MicroVax address we would do the following:

uNOTE # 010
Page 2 of 5

1) Subtract. off the I/O base address for this board (160000)
166540 (oct)
160000 (oct)
6540 (oct) -->

060 (hex)

2) Add the board's address offset to the Qbus MicroVax I/O space
base address
+

20000000 (hex)
060 (hex)
20000060 (hex)

This addition results in the physical address on the Qbus MicroVax
system that this board would answer to.
Now we have calculated the physical address for the board in the Qbus
MicroVax environment.
This value, however, is in the raw state and is
still not usable by the uVMS software to perform virtual to physical
address translation.
In order for this address to be useful to the
software it must now be converted from a physical address to a page
frame number.
The page is the basic unit of memory mapping and
protection. A page is 512 contiguous byte locations.
A page frame
number (PFN)
is the address of the first byte of a page in physical
memory. This means that the lsb ofa PFN has the resolution of 1 page
or 512 bytes.
It is a simple matter now to convert a physical address
to a PFN. Since the lsb of a PFN is 1 page to convert a physical
address to PFN just shift right the physical address 9 bits, i.e.
shift
off the 9 least significant bits.
physcial 20000060 (hex)

shift right 9 --> PFN 100006 (hex)

The PFN value which we have calculated is sufficient to allow the system
to map a physcial page of addresses into your virtual address space.
The address of the Qbus option resides somewhere in the page which we
have mapped.
It is the responsibility of the programmer to correctly
offset from the beginning of the page in order to access the board i.e.
the programmer _must displace from the base of the mapped page with the
correct virtual address offset.
To determine the offset from the
beginning of the mapped page look to bits 0-9 of the configured address
of the Qbus option board - this is the offset.
In our example the
offset would be:

uNOTE # 010
page 3 of 5

166540 (oct)

I I

\ I

540

bits 9-0 are the offset

This offset would be used by thE! programmer to access the device
registers on the board. Failure to use the offset will usually result
in an attempt to access non-esxistE!nt locations (analagous to memory
time-outs) which will result in an access violation error being returned
to the user. A sample program follows which illustrates the principles
which have been discussed.
It uses the same board address discussed
earlier so that one can see the code needed to acutally implement the
previous example.

The following program illustrates, in a raw fashion, how one might
actually access the I/O space with software.
It is not meant to
illustrate good or recommended pro9ramming practice but rather to show
the mechanics of accessing the I/O space of a Qbus on MicroVax I.

uNOTE # 010
Page 4 of 5

iThis program will allow a user with suitable privilege to access
idevice registers in the I/O space of a uVax. This example shows
icode which is used to extract data from a DRV11 - a general purpose
iparallel interface which resides in I/O space. It is sufficiently
igeneral to allow the concept to be used in other situations where
iaccess to the I/O space from a user process is desireable.
iThis portion of the program is responsible for creating the
ivirtual to physical mapping required to access registers in
ithe I/O space. For this example the device registers are assumed to
istart at 166540. In order for virtual to physical mapping to occur
ithe user must calculate the physcial page frame that the device
iregisters overlap into. (See accompanying text for how to do this)

iCreate and map section directive does the actual work of mapping.
iln order for this system service to work correctly the
iuse must have PFNMAP privilege
.entry

start,A m<>

$crmpsc s inadr .-maprange, retadr - actadr, -

ilnput virtual address range
iVirtual address range acutally
imapped
iNon zero required for page frame
pagcnt • #1, isection
flags -#<sec$m expreglsec$m pfnmap!sec$m wrt>, iActual page frame of I/O space
vbn - pfn number
ipage which contains device registers
blbs

rO,continue

icheck the return status of create
iand map - if successful branch

pushl
calls

rO
#l,g"'lib$stop

iput status onto stack
itell him what happened and
istop program

uNOTE # 010
Page 5 of 5

iAt this point one page of virtual addresses in the user's process
ispace is now mapped into one page of the I/O space. Now the user
ican access device registers by using move instructions.
i •••••• ** Please note that only certain instructions are allowed when
idoing physical I/O to the bus. For example a MOVL instruction is
iNOT legal to the I/O space.
continue:
movl

actadr, r6

;Get starting virtual address from

addl

# . . x160, r6

;system service and put into R6
;Add the displacement into this page
ito access the device registers

iAccess data from the parallel interface
tstb
bgew
movw

(r6)
10$
4(r6), data in buffer

10$:
$exit s code ;; #1

;Test for data transfer request
;If no data exit
;Data is present - store it

;exit gracefully

;data for program •••.•.
maprange:

.long
.long

"'x4.00
"'x800

control status
data in-buffer

.word
.word

actadr:

.blkl

.long

"'x100006

.end

start

;holds returned virtual
; address range
;actual pfn of I/O page to
;be mapped

uNOTE # 011

Title: LSI-11/73 ADVANCED MEMORY MANAGEMENT

Date: 04-Sep-S4

Originator: Art Bigler

Page 1 of 11

This micronote examines the advanced memory
management
features
available on the DCJ11 based LSI-11/73 series processors (KDJ11-A,
KDJ11-B).
These features include the
standard
virtual
address
relocation within the physical address space and the kernel and user
execution modes, all of which are currently available as options on the
mid-range LSI-11/23 (KDF11-A, KDF11-B) processors.
In addition to these
features, the DCJ11 based processors also provide instruction and data
space (I/O space) memory management and the supervisor execution mode.
The following discussion is intended to further clarify these features.
For information pertaining to address relocation the reader is referred
to micronote OOS, MEMORY MANAGEMENT AND THE LSI-11/73.
1.0

INSTRUCTION/DATA SPACE M:EMORY MANAGEMENT

I/O space memory management is utilized in the DCJ11 based processors IN
ADDITION TO the relocation of virtual addresses within the physical
address space. This provides the ability to place multiple program
images in physical memory while at the same time providing an increased
virtual address space of 128 kb OI' 64 kw by mapping instructions and
data to separate areas of physical memory. The means by which I/O space
memory management is attained involves both hardware and software as
described in the following paragraphs.
I/O SPACE HARDWARE

1.1

The hardware required to implement: I/O space addressing is integrated
into the memory management uni.t and is standard on all DCJ11 based
processors. This includes the following:
1.

Eight (8) additional active page registers (APR'S)
per
execution mode (more about execution modes later). These APR's
are used to map to the data space when I/O space memory
management is enabled.

Additional control and status bits in memory management
registers 0 and 3 (MMRO, MMR3) which are used to control the
enabling and disabling of data space addressing.
INSTRUCTION
SPACE ADDRESSING IS ALWAYS ENABLED.

uNOTE # 011
Page 2: of 11
1.1.1

ACTIVE PAGE REGISTERS

The hardware provides a total of sixteen (16) APR's per execution mode,
eight (8) instruction space registers and eight (8) data space registers.
THE APR's are further divided into page descriptor registers (POR'S)
and
page address registers
(PAR's) as described in micronote 008.
The
physical addresses for these registers are contained in the I/O page and
are as follows:

MODE

KERNEL
I
SPACE

PAR's

POR's

PAGE

17772340

17772300

17772342

17772302

17772344

17772304

17772346

17772306

17772350

17772310

17772352

17772312

17772354

17772314

17772356

17772316

17772360

17772320

17772362

17772322

17772364

17772324

17772366

17772326

17772370

17772330

17772372

17772332

17772374

17772334

17772376

17772336

I-

KERNEL
I-

SPACE
f-

I-

TABLE 1a
KERNEL MODE APR'S

uNOTE # 011
Page 3 of 11

MODE

SPVSR
I
SPACE

I-

SPVSR
D
SPACE

PAR's

PDR's

PAGE

17772240

17772200

17772242

17772202

17772244

17772204

17772246

17772206

17772250

17772210

17772252

17772212

17772254

17772214

17772256

17772216

17772260

17772220

17772262

17772222

17772264

17772224

17772266

17772226

17772270

17772230

17772272

17772232

17772274

17772234

17772276

17772236

I-

TABLE 1b
SUPERVISOR MODE APR'S

uNOTE # 011
Page 4 of 11

MODE

PAR's

POR's

PAGE

17777640

17777600

17777642

17777602

17777644

17777604

17777646

17777606

17777650

17777610

17777652

17777612

17777654

17777614

17777656

17777616

17777660

17777620

17777662

17777622

17777664

17777624

17777666

17777626

-17777670

17777630

17777672

17777632

17777674

17777634

17777676

17777636

USER
I
SPACE

USER
~

SPACE
~

TABLE 1c
USER MODE APR'S

1.1.2

MEMORY MANAGEMENT REGISTER 0

Memory management register 0 (MMRO) contains control
and
status
information for the memory management unit (MMU). This register is
discussed complete~y in micronote 008, to which the reader is again
refferred for information on those functions which are not directly
applicable to I/O space and supervisor mode.
MMRO contains three (3) status bits which are used in the implementation
of I/O space memory addressing. These bits, 04 through 06, yield MMU
status information whenever a MMU abort occurs and are used
in

uNOTE • all
page 5 of 11
conjunction with MMRO bits 01 t:hrough 03 and 13 through 15 to provide
complete execution mode and I/O spcLce status for the page causing the
abort. See figure 1.
Bit 04, the page address space status bit, indicates the address space
associated with the aborted page and is equal to a zero (0) for an
instruction space page and a one (1) for a data space page whenever I/O
space addressing is enabled. If I/O space addressing is not enabled this
bit always reflects a zero (0).
Bits 05 and 06, the processor mode status bits, indicate the processor
execution mode associated with 1:he page causing the abort. These bits
are coded as follows:
BIT
06 05

EXECUTION MODE

o 0

KERNEL

SUPERVISOR

ILLEGAL (causes an abort with bit 15 set)

USER

For more information on MMU aborts see micronote 008.

uNOTE # 011
Page 6 of 11
MMRO
1
5

1
4

1
2

1
1

ADDRESS: 17777572

o
9

o
5

o
4

o
o

READ-ONLY
ACCESS VrOLATION

~--ABORT

~-------ABORT
~-----------ABORT

PAGE LENGTH ERROR
NON-RESIDENT

PAGE
ENABLE
ADDRESS
RELOCATION
SPACE (I/D)

BIT #

DESCRIPTION

<15>
<14>
<13>
<12:07> <06:05> <04>
<03:01> <00>

ABORT READ-ONLY ACCESS VIOLATION (R ONLY)
ABORT PAGE LENGTH ERROR (R ONLY)
ABORT NON-RESIDENT (R ONLY)
NOT USED (R ONLY)
PAGE MODE (R ONLY)
PAGE ADDRESS SPACE (I/D) (R ONLY)
PAGE NUMBER (R ONLY)
ENABLE RELOCATION (R/W)
FIGURE 1
MEMORY MANAGEMENT REGISTER 0 (MMRO)

MEMORY MANAGEMENT REGISTER 3
Memory management register 3 (MMR3)
contains control
and
status
information for data space addressing, 22 bit mapping, and the call to
supervisor mode
(CSM)
instruction.
This register,
once again,
is
discussed in detail in micronote 008.
MMR3 contains three (3) control bits which are used in the implementation
of I/D space addressing.
These bits, 00 through 02, individually enable
data space addressing for each of the execution modes.
Bit 00 enables
data space addres$ing for the USER mode, bit 01 enables it for SUPERVISOR
mode, and bit 02 enables it for KERNEL mode.
The desired bits are set to
a one
(1) whenever data space addressing is desired.
MMR3 is cleared
during power-up,
console restart,
and the execution of the RESET
instruction.
See figure 2.

uNOTE # 011
Page 7 of 11
ADDRESS: 17772516

MMR3 REGISTER
1
5
0

1
4

1
3

1
2

1
1

0
8

0
7

0
6

0
5

0
4

0
3

0
2

0
1

0
0

UNINTERPRETED------------~

ENABLE 22 BIT MAPPIN~------~
ENABLE CSM

INSTRUCTION-------~

KERNEL------------------------------~

SUPERVISOR------------------------------~
USER--------------------------------------~-~

BIT #

DESCRIPTION

<15:06> <05>
<04>
<03>
<02>
<01>
<00>

NOT USED (R ONLY)
UNINTERPRETED (R/W)
ENABLE 22 BIT MAPPING (R/W)
ENABLE CSM INSTRUCTION (R/W)
KERNEL DATA SPACE (R/W)
SUPERVISOR "DATA SPACE (R/W)
USER DATA SPACE (R/W)
FIGURE 2
MEMORY MANAGEMENT REGISTER 3

I/O SPACE ADDRESS MAPPING

1.1.4

When I/O space addressing has been enabled the MMU hardware performs the
address mapping (IN ADDITION TO ADDRESS RELOCATION WHICH IS PERFORMED
USING THE APPROPRIATE SET OF APR'S) as follows:

The ~urrent instruction is ALWAYS fetched from the
. space.

The operands are mapped according to table 2.

instruction

uNOTE # 011
Page 8 of 11

OPERAND
ADDRESSING
MODE

TYPE
OF
ADDRESSING

I OR D
SPACE
USED

000

ANY

001

ANY

010

0 THROUGH 6

AUTOINCREMENT

IMMEDIATE

0 THROUGH 6

AUTOINCREMENT
DEFERRED

D (A)
D (D)

ABSOLUTE

I (A)
D (D)

0 THROUGH 6

AUTODECREMENT

DO NOT USE 11

0 THROUGH 6

AUTODECREMENT
DEFERRED

DO NOT USE 11

110

ANY

INDEX

I ( A)
D (D)

111

ANY

INDEX
DEFERRED

I (A)
D (A)
D (D)

011

100

101

D (A)
D (D)

(A) - INDIRECT OR INDEX ADDRESS
(D) =- DATA
TABLE 2
OPERAND ADDRESSING WITH DATA SPACE ENABLED

All address mapping is performed using the I space APR's when data
addressing is not enabled.

space

The most difficult example showing data space
deferred type of addressing.

index

addressing

the

uNOTE # 011
Page 9 of 11
CLR

@1000(R3)

The instruction
location pc.

fetched

The base address 1000 is fetched from the instruction space at
location PC+2.
The index in R3 is added to the base address
forming the address of the indirect address.

The indirect address is fetched from the data space
address calculated in step 2.

The data is fetched from
calculated in step 3.

data

the

instruction

space

using

space

using

the

address

At the present time I/O space addressing is supported by two (2)
supplied operating systems, RSX-llM-PLUS and ULTRIX-l1.

Digital

1.2

the

from

I/O SPACE SOFTWARE

RSX-11M-PLUS provides linking of tasks which utilize I/O space addressing
via the task builder (TKB) utility. Those programs which include the
data PSECTs in their object files may be task built using the /ID switch.
It should be noted that the task may not make use of the entire 32kw data
space because RSX-llM-PLUS requires that the stack and the task header be
placed in data space.
Other restrictions may apply, consult the task
builder manual for further information.
When using I/O space with other operating systems or in standalone
programs,
the user must do all the mapping within the program. This
implies that the mapping of the operating system must be attended to by
the user program if operating system features are to be utilized.
To make use of data space addressing the program must:
1.

Separate the instruction space from the data space.
(ie.
create different regions in memory for instructions and data)

Load the instruction space and data
appropriate relocation information.

Enable I/O space mapping by setting the MMR3 bit associated
with the execution mode under which the program will run.

The following

~estrictions

space

APR's

with

the

apply to I/O space programs:

The instruction space can only contain instructions,
operands,
absolute addresses, and index words.
reflected in table 2.

immediate
This is

The stack page must be mapped into both

and

instruction

data

uNOTE # 011
Page 10 of 11
space if the
off the stack.

MARK instruction is used because it is executed

Instruction space-only pages
cannot
contain
subroutine
parameters which are data. This precludes the mapping of any
pages containing standard PDP-11 calling sequences entirely
into an instruction space page.

The trap catcher technique of putting .+2 in the trap vector
followed by a halt must be mapped into both instruction and
data space.

For further information on I/O space addressing under
ULTRIX-11 consult the appropriate documentation set.

2.0

RSX-11M-PLUS

and

SUPERVISOR MODE

'The DCJ11 based processors provide three (3) execution modes:
KERNEL,
SUPERVISOR, and USER.
They provide for various forms of memory and
processor protection and permit additional features to be implemented in
:multiprogramming environments.
Each mode has its own set of mapping
registers.
KERNEL mode is the most privileged of the modes, allowing the execution
of any instruction and the modification of any area in memory including
the I/O page.
USER mode prohibits the execution of privileged instructions such as HALT
and RESET and the modification of areas in memory that the KERNEL program
does not provide access to.
SUPERVISOR mode has the same privileges as USER mode with its awn set of
mapping
registers,
thus
providing
another level of protection.
SUPERVISOR mode is intended for use in the mapping and execution of
programs to be shared by users while still providing protection from
them. Examples of this are command line processors which are required
for use by all users on a system, while necessitating write protection
from them.
The execution mode is controlled by the state of bits 14 and 15 in the
processor status word (PSW). These bits are changed by the execution of
traps and interrupts, pushing and popping of old PSW's to and from the
stack, and, when in KERNEL mode, the direct manipulation by the program.
Bits 12 and 13 re(lect the execution mode which existed prior to the
event which placed the processor in the current mode. See figure 3.

uNOTE 41: 011
Page 11 of 11
The current and previous mode PSW bits are coded as follows:
BIT
15 14
13 12
0
0
1
1

EXECU~rION

0
1
0
1

MODE

KERNE1~

SUPERVISOR
ILLEG1~L

USER

PROCESSOR STATUS WORD (PSW)
1
5

1
4

1
3

1
2

1
1

1
0

0
9

CURRENT PREVIOUS
MODE
MODE
GPR
GROUP
BIT

0
7

0
6

0
5

0
4

PRIORITY
LEVEL
SUSPENDED
INFORMATION

TRACE
BIT

CURRENT MODE (R/W)
PREVIOUS MODE (R/W)
GENERAL PURPOSE REGISTER SET (R/W)
NOT USED (R ONLY)
SUSPENDED INFORMATION (R/W)
PROCESSOR PRIORITY LEVEL (R/W)
TRACE BIT (R/W)
NEGATIVE CONDITION CODE (R/W)
ZERO CONDITION CODE (R/W)
OVERFLOW COND:ITION CODE (R/W)
CARRY CONDITION CODE (R/W)
:rIGURE 3
PROCESSOR STATUS WORD

0
3

0
2

0
1

CONDITION
CODES

DESCRIPTION

41:

<15: 14>
<13:12>
<11>
<10:09>
<08>
<07:05>
<04>
<03>
<02>
<01>
<00>

0
8

ADDRESS: 17777776
0
0

uNOTE

Title:

DMA on The Q-bus

Originator:

* 012

Date: 06-SEP-84

Jack Toto

Page 1 of 4

This Micronote explains the various, types of DMA on
Cycle Mode, Burst Mode and Block Mode.

the

Q-bus;

Single

SINGLE CYCLE MODE:
Single cycle mode DMA like all DMA on ~he Q-bus requires that the DMA
device gain control of the bus through an arbitration cycle. During the
arbitration cycle the DMA device be!comes bus master by first asserting a
DMA request (BDMR).
When the arbiter acknowledges this request it
issues a DMA grant (BDMGO).
In the' event that there is more than one
DMA device in the backplane the grant signal is daisy chained from
device to device.
Eventually the device that issued the DMA request
will latch the grant signal and take control of the bus, and proceed
with the DMA transfer.
Once becoming bus master the device asserts BSACK and is allowed to do
one word tranfer to or from memoI'y, during which time the CPU is idle.
Certain processors such as the KCJ1.1-B have a cache memory with dual tag
store which allows it to process dSlta while DMA transfers are occurring.
Regardless of which processor type is used only one transfer is allowed
in single cycle mode.
If the device must perform additional transfers,
it must go through the bus arbitration cycle again.

~~----------~

SACK
BDAL

ADRS/DATA

ADRS/DATA
1

In single cycle mode, the theoretic:al transfer rate across the Q-bus is
1.66 Mbytes/sec (833Kw/sec) A dE!vice such as the DRVll-B or the newer
22-bit compattble DRV11-W can trane;fer data at a rate of 250KW/sec while
in single cycle mode.

uNOTE # 012
Page 2 of 4
BURST MODE:
Burst mode DMA can be performed by certain devices such as the DRV11-B.
Once the DMA controller becomes bus master (through the arbitration
routine described in the single cycle section and it has asserted BSACK,
the DMA tranfers can begin.
Each data word that is transfered is
accompanied by an address that the data word is targeted for.
In burst
mode loading an octal value into the 16 bit word count register (WCR)
allows for that number of words (64Kb max) to be transfered under one
sack.
This differs from single mode, in that the word count register
can be loaded with the same value, but each single word transfer will
require a new arbitraion cycle, i.e in order to transfer 64Kb of data it
would require 65,536 arbitration cycles.

SACK
BDAL --~IADRS/DATA ADRS/DATA ADRS/DATA .........••..... (N)~I---N :- word count;

The theoretical transfer rate across the Q-bus in burst mode remains at
1.66 Mbytes/sec, however a device such as the DRV11-B operating in burst
mode can transfer data at a rate twice that of a DRV11-B operating in
single mode,
or 500Kw/sec.
In burst mode the DMA bus master maintains
control of the bus until it has transferred all of the required data.
Burst mode has the advantage of moving large blocks of memory across the
bus with no delay. The caution here is that no other device
(including
the CPU) has access to the bus during that time. This can have severe
impact on system performance.
DMA COMPROMISE:

Since Single Cycle Mode requires a rearbitration for every data transfer
and Burst Mode can adverseley impact system performance in some cases
DIGITAL EQUIPMENT CORP. has made some compromises with certain DMA
controllers.
Most DIGITAL devices will do a limited Burst Mode
operation. Thes~controllers (for example the RXV21 and RLV12)
are

uNOTE # 012
Pag·e 3 of 4
~llowed

up to do four words of data tranfer.
Each word of transfer is
preceeded on the bus by an address that the data word is targeted for.
This allows data to move across the bus with a minimum of rearbitraton.
However, when a group of four t,ransfers is finished,
the DMA devices
must again go through the arbitration cycle in order to allow other
devices the opportunity to use the bus.
If no other bus requests are
pending at a higher priority, then bus mastership will be returned to
the device for the next set of data transfers.

SACK

____----Ir

BDAL

--------1' ADRS/DATA P..DRS/DATA ARDS/DATA ADRS/DATA ....' - - 1 2 3

BLOCK MODE:
For increased throughput, Block Mode DMA may be implemented on a device
for use with memories that support this type of transfer. Block Mode
DMA devices are only block mode when operating. They may not operate as
a Single or Burst Mode device. They may, however, appear to operate
dike a single mode device if they are only doing a single word transfer,
and they will always look like a Single Cycle Mode DMA device when used
with non-Block Mode memory.
Once a Block Mode device has arbitrated for the bus, the starting memory
address is asserted,
then data for that address, followed by data for
consecuetive addresses. By eliminating the assertion of the address for
each data word,
the transfer ratE~ is almost doubled.
The DMA device
should monitor the BDMR line.
If thE~ line is not asserted after the
seventh transfer than the device can continue. This allows a maximum of
16 data transfers for one abitration cylce.
If the BDMR line is not
monitored by the DMA device than a maximum data tranfer of 8 words is
allowed after completing one bus arbitration cycle.
Block Mode DMA
transactions can be described as two types, a DATBI (block mode data in)
and DATBO (block mode data out). Both of these cycles are explained in
depth in Micronote #002.
When reading the appropriate micronote
special attention should be paid to the use of BREF and BBS7 signals
when performi~g a DATBO.

uNOTI~ # 012
:~age 4 of 4

BOAL----l AORS/OATA/ ......... DEPENDS ON STATE OF BOMR L-_
(1)
* (7)
(16)

BDMR~---------------------*-----------------------/\/\/
Block Mode devices such as the DEQNA, RQOXl and the MSV11-P memories can
transfer data across the bus at rates that approach twice that of OMA
devices in Burst Mode. The actual rate is dependent upon the device
itself.
The technical manuals for each of these devices should be
checked for actual performance figures.

100

uNOTE

* 013

Title: Run-time System Performance Evaluation
Using MicroPower/Pascal V 1.5

Date: 09-0ct-84

Originator: Herbert Maehner

Page 1 of 5

In real-time programming, the performance of the run-time system and the
compiler together govern the overall power of the application. The
performance of the MicroPower/Pascal compiler has been extensively
discussed by R.Billig/R.Cronk [1].
The performance of the run-time executive of MicroPower/pascal is
measured in this MicroNote using different LSI-11 CPU-boards and the
KXT11-CA I/O processor.
Data was obtained using Micropower/Pascal
version 1.5.
Test Conditions
Results obtained through a lab experiment are only as precise as the
test environment and may only be referenced giving the exact test
conditions.
The goal was to measure the elapsed time of a given primitive execution
on the Pascal process level, i.e. how long it takes to call/execute a
kernel primitive from a Pascal program.
Generally, the following procedure was used to obtain the elapsed time,
where in some cases more than one output bit has been used to obtain the
desired pulse-width.
WHILE Condition - TRUE DO
BEGIN
out_port.bitO := TRUE;
{ here call/execute given primitive }
Out port.bitO :- FALSE;
END; The whole test was done in a loop as long as the condition was true.
Here, Condit~n is a boolean variable, which is set FALSE by a high
priorty process waiting on a terminal input (READLN).
The Outport.bitO is bitO of a parallel device.

101

The parallel device

was

uNOTE # 013
Pac.;re 2 of 5
either
devi~e

a DRV11 (using LSI 11/23 and LSI 11/73) or the on-board parallel
(using the FALCON plus SBC 11/21 and KXTI1-CA).

The bitO pulse is used as the input to an oscilloscope which has the
capabilities to measure and display time differences and frequencies.
The elapsed time required to execute the various primitives was
obtained.
In addition to the primitive requests some math-functions
times were obtained.
The results are shown in Table 1 at the of this
MicroNote.
Interrupt-Test Conditions
A pascal-program with an embedded interrupt service routine needs DRIVER
privileges in a mapped environment. The test program either connects to
a "normal" ISR or to a prio7 ISR.
The program executed a simple loop
like:
WHILE TRUE DO
BEGIN
Out port.Bit1 := TRUE;
Out-port.Bit1 :- FALSE;
ENDiThe Outport is the parallel device of the type mentioned above.
This is
used to monitor process execution behavior.
Testing the interrupt
response time, we used a square wave generator which triggered an
interrupt on that parallel device.
The ISR was coded as
.ENABL
. MCALL
.MCALL

GBL
MACDF$,PURE$
IMPUR$

Enable global symbols
Set-up pure/impure area

.GLOBL

lNPORT,OUTPRT

port A,B of PPl

MACDF$
PURE$

MACDF$ must be called before the
two assembly directives

. DSABL AMA
PPIINT: :
BlSB
MOVB
MOVB
BICa
RTS
RTS
TEMP:

#l,@#OUTPRT
@#INPORT,@#Temp
@#INPORT,@#Temp
#l,@#OUTPRT
PC

IMPUR$
.WORD 0
.END

set bit 0 output port
dummy read
dummy read
set bit 0 output port
normal lSR return
prio 7 lSR return
reserve one word

102

1];

ISR time
measured

uNOTE # 013
Page 3 of 5
Depending upon the ISR-type either the RTS PC or the RTS R4 must be used
to exit the ISR. The first MACRO-statement within the ISR signaled bitO
of the parallel port. The resultinq interrupt dispatch time was defined
as the pulse width given by the square wave generator edge and the
signaled output port. This includes the hardware ISR dispatch time as
well.
The ISR execution time was given by the pulse width indicated
within ISR source above. Again, all pulses were measured using an
oscilloscope.
The maximum interrupt rate was determined by increasing
the square frequency (whi.ch in turn increases the outpt square wave of
the ISR) until the system lost interrupts.
Using CONNECT SEMAPHORE the interrupt performance
was
similarly
measured.
In this case only a dynamic process was waiting on the
semaphore to be signaled. The results are shown in table 2.

References
1. Rich Billig and Randy Cronk,. A System/Architecture Approach to
Microcomputer Benchmarking, DIGITAL Equipment Corporation,
Sept. 1982, EZ-12053-03/82
2. MicroPower/Pascal Newsletter, Volume 1, No.1, March 1984, p. 23,
DIGITAL Equipment Corporation, Order Number AV-B067A-TK

103

uNOTE # 013
Page 4 of 5

Operation

LSI-11/23
w/o FPU
m
u

LSI-11/23
w/ FPU
m
u

LSI-11/73
u
m

SBC
11/21+

KXT11
-CA

Process
creation
deletion

3.1
2.4

5.48
4.19

3.56 5.93
2.55 4.35

1.84 2.64
1.14 1.92

3.96
2.96

2.71
2.06

Schedule +
context Switch

0.56 0.97

0.82 1.27

0.38 0.57

0.69

0.49

0.55 0.96
0.50 0.93

0.55 0.99
0.51 0.95

0.27 0.42
0.25 0.39

0.67
0.63

0.47
0.43

0.61 1.05
0.58 1.01

0.61 1.05
0.58 1.02

0.29 0.43
0.28 0.42

0.72
0.70

0.51
0.49

0.73 1.20
0.71 1.17

0.73 1.18
0.71 1.15

0.36 0.50
0.35 0.49

0.88
0.86

0.62
0.60

0.35 0.64
0.61 0.93
0.36 0.65

0.35 0.65
0.61 0.94
0.36 0.66

0.16 0.25
0.27 0.37
0.17 0.29

0.44
0.75
0.44

0.30
0.52
0.30

0.42 0.84

0.42 0.85

0.20 0.33

0.50

0.35

1.17 2.18
1.46 2.50

1.18 2.20
1.46 2.51

0.59 0.89
0.73 1.11

1.45
1.79

1.01
1.24

1.26 2.28
1.59 2.64
3.09 4.32

1.26 2.31
1.59 2.67
3.09 4.35

0.67 0.96
0.84 1.14
1.74 2.11

1.54
1.94
3.78

1.08
1.35
2.63

Ring buffer
1 cnaracter
get
put
2 characters
get
put
4 characters
get
put
Signal Semaphr
by descriptor
by name
fast named
Get status
Send + Receive
(by value)
- 1 Byte
- 34 Bytes
Send + Receive
(by reference)
- 10 Bytes
- 100 Bytes
- 500 Bytes

TAN

6.84 7.74

1.64 1.68

0.35 0.36

9.00

6.24

SIN

5.13 5.82

1.75 1.78

0.33 0.34

6.80

4.69

COS

6.19 7.00

1.94 1.98

0.39 0.39

8.15

5.64

5.04 5.69

1.45 1.48

0.32 0.33

6.55

4.59

5.34 6.01

1.27 1.31

0.28 0.29

6.95

4.86

EXP

Table 1: Micropower/Pascal V1.5 Runtime System

104

(millisE~c)

uNOTE # 013
Page 5 of 5
Notes for Table 1
o
o
o
o

u - without MMU and m - with MMU
FPU = with floating point unit (KEF11)
Send/Receive without context-switch
SBC-ll/21+ using on-board memory only

Operation

LSI-l1/23
m
u

LSI-11/73
m
u

Interrupt dispatchtime (usec)

ISR execution
time (usec)

Maximal interruptfrequency (kHz)

7.0

Interrupt dispatchtime (usec)

sac
11/21+

KXT11
-CA

13.4

5.1

12.9 10.9

4.8

7.5

28.5

ISR execution
time (usec)

Maximal interruptfrequency (kHz)

17.8

9.3

12.8

16.5

ISR:
54

PRI07 ISR:
38
13.4
26

CONNECT SEMAPHORE: (one process waiting on that semaphore)
Interrupt dispatch +
context-switch time
(msec)

0.88 1.36

0.49 0.63

1.15

0.82

Maximal interruptfrequency (kHz)

0.67 0.39

1.20 0.83

0.41

0.75

Table 2: Interrupt Performance
Note for Table 2
Additionally, the system had to service the clock interrupt
at
rate of 50 Hz without the clock driver implemented, i.e.
the interrupt dispatcher discarded the interrupt. The clock
interrupt was enabled because realistically most systems have
the clock enabled.

105

106

uNOTE # 014

Title:

Using Fortran Routines In A
VAXELN-Pascal Environment

Date: 16-0ct-84

Originator:

Herbert F. Maehner

Page 1 of 4

This Micronote discusses the VAXELN interface to
following topics are covered are discussed:
1.

VAX-11

Fortran.

The

The VAX-11 Procedure Calling Standard

2. Establishing a COMMON-datal area between a
and Fortran routines

VAXELN

program

VAXELN Procedure Ccllling Standard
VAXELN Pascal (EPascal) does conf:orm to the VAX Procedure Calling
Standard.
The standard allows for three methods of parameter passing :
value, reference, and descriptor, and requires that values be no longer
than a longword.
EPascal does not explicitly support descriptors as
parameters, and other languages may not treat conformant parameters as
EPascal does, but EPascal does nothing to violate the calling standard.
All routines can be described according to the conventions described in
the summary of run-time library E~ntry points [1]. There are principle
differences in passing parameters in Pascal and Fortran:
In pascal, you may pass parameters as

- values, e.g PROCEDURE pass_it (What: INTEGER);
i.e. the value of the parameter will be copied into the
procedure's stack frame with no implications for the source
variable. This is termed pass by value.
or as
- variable, e.g. PROCEDURE pass_it (VAR What: INTEGER);
i.e. the parameter will be rE~ferenced through its address.
An assignment to the parameter within the procedure will
directly~ffect the source variable.
This is termed pass by
reference.

107

uNOTE # 014
Page 2 of 4
In Fortran, you pass parameters as
- values, e.g. SUBROUTINE passit( What)
INTEGER*4 What
i.e. with no implications for the source.
It uses a common
data area to pass variables to the main program. The main
difference to Pascal is, that Fortran use~ pass by reference,
although it is actually a value.
Calling a Fortran routine with parameter passing from a
Pascal
environment, you have to declare the parameters as VAR parameters in
Pascal ( Figure 1 and Figure 2).
COMMON Data Area
As mentioned before, Fortran uses a COMMON data area to pass variables
from procedures to the main part of the program.
In VAX-11 Pascal the
[COMMON] attribute enables the linker to establish the common data
section. VAXELN- Pascal has no such attribute and wouldn't overlay data
sections for common areas. To overcome this restriction you must use
the [EXTERNAL] attribute in VAXELN-Pascal to declare the prospective
data as externally declared and use a MACRO-32 declaration to assign the
Fortran common part to the "global" data area (Figure 3).

References:
1. VMS RUN TIME LIBRARY USER'S GUIDE (Summary of Run Time
Library Entry Points)
2. VAXELN Encyclopedia, Procedures and Functions,
3. VMS MACRO Language Reference Manual

108

uNOTE # 014
Page 3 of 4

MODULE Fortran_TO_pascal;
{ This module is a simple example on, how to use Fortran
routines in VAXELN. }
CONST
Max - 50;
TYPE
Array_type - ARRAY[l .. Max] OF INTEGER;
VAR
AA: [EXTERNAL] Array_type;
PROCEDURE Valaccess (VAR What:INTEGER); EXTERNAL;
FUNCTION Double_it (VAR What: INTEGER):INTEGER; EXTERNAL;
PROGRAM FORTEST(INPUT,OUTPUT);
VAR
what,I,J,K:
INTEGER;
Twenty: [READONLY] INTEGER:-20;
BEGIN
WRITELN('Program start ');
FOR I:-1 TO Max DO AA[I] :== 0; { initialize array}
valaccess(Twenty);
call Fortran routine Valaccess }
FOR I:-21 TO Max DO
BEGIN
What :- I;
{ use Fortran Function to
AA [ I] : - Doubl e i. t (Wha t ) ;
double array value }
END;
{ formated output to screen

}

: - 1;
FOR I:-1 TO 10 DO
BEGIN
FOR J:-l TO 5 DO
BEGIN
WRITE(AA[K):4,'
');
K :- K+1
END;
WRITELN;
END;END;
END; { Bend of module Fortran_to_pascal }
K

Figure 1 : VAXELN main pl:ogram module

109

uNOTE i 014
Page 4 of 4

C Fortran SUBROUTINE TO SET THE INDEXED ARRAY VALUE
C THE MAXIMAL INDEX IS PASSED AS A PARAMETER
C

SUBROUTINE VALACCESS(WHAT)
IMPLICIT INTEGER*4 (A-Z)
C

COMMON

/XX$AA/ AA(SO)

C
C

DO 10 I-1,What
AA(I) - What-I
CONTINUE

RETURN
C

END
C
C
C

C INTEGER FUNCTION TO DOUBLE THE VALUE PASSED AS A PARAMETER
C

INTEGER FUNCTION DOUBLE IT(WHAT)
IMPLICIT INTEGER*4 (A-Z)
DOUBLE IT - WHAT + WHAT
RETURN
C

END
Figure 2: External Fortran routines used

; definition file for common array AA to be accessed by Fortran
subroutine VALACCESS
the P-section name XX$AA must be the same as the one used in the
Fortran routine

AA::

.TITLE COMDAT
.PSECT XX$AA,LONG,PIC,USR,OVR,REL,GBL,SHR,NOEXE,RD,WRT,NOVEC
• LONG 50
.END

Figure 3: MACRO definition module to define the common array

110

uNOTE # 015

Title: Q-Bus Hardware Bootstraps

Date: I6-0ct-84

Originator: Dave Smith

Page 1 of 4

The purpose of this micronote is to provide a comprehensive
Q-Bus hardware bootstraps and the devices they support.

list

The tables on the next two pages are organized as follows.
There is a
row for each of the currently supported bootable devices. There is a
column for each hardware bootstrap. The columns span both pages.
In
the heading for each bootstrap w'ill be found any ordering information
and/or references to notes which follow the tables.
When two order
numbers are given, both must be ordered since the boot code is divided
into high byte and low byte ROMs.
The bootstrap devices listed are:

BOOT
DEVICE

DESCRIPTION

BDV11

Bus Terminator, Bootstrap & Diagnostic ROM
used primarily with older LSI-1I configurations

MXV11-A2

Bootstrap ROM set designed for MXV11-A board

MXVI1-B2

Bootstrap ROM set designed for MXV11-BF & MRV1I-D

KDF11-BA

Bootstrap ROM on board PDP-11/23+ systems

KDF11-BE

Bootstrap ROM on board MicroPDP-11/23 systems

KDF11-BF

New Bootstrap ROM for PDP-I1/23+ and MicroPDP-II/23

KXT11-A2

Bootstrap ROM on board Falcon

KXTI1-A5

Bootstrap ROM on board Falcon-Plus

KDJll-S

Bootstrap ROM on board MicroPDP-11/73 CPU

uVAX I

Bootstrap ROM on board MicroVAX I CPU

111

uNOTE it 015
Page 2 of 4

BOOTSTRAP DEVICE SUPPORT
DEVICE

BDV11

MXV11-A2

Rev A

MXV11-B2

KDF11-BA

KDF11-BE

see Note 2

part no
23-339E2
23-340E2

part no.
23-1s7E4
23-1s8E4

see Note 1
RX01

RX02

TUs8

see Note 1

RL01/2
MRV11-C

MRV11-D
RKOs

RXsO

RDs1

RDs2
TSVOs

TK2s
RC2s
DEONA
DLV11-E

DLV11-F

DUVl1

DPV11

112

uNOTE # 015
page 3 of 4

BOOTSTRAP DEVICE SUPPORT
DEVICE

KDF11-BF

KXT11-A2

KXT11-AS

KDJ11-B

uVAX I

available available
on CPU
on CPU
board only board only

part no
23-183E4
23-184E4
RX01

Rx02

TUSS

RL01/2

MRV11-C
X

MRV11-D
RKOS

RXSO

RDS1

RDS2

TSVOS

TK2S

RC2S

DEQNA

X
See note 3 See note 3
X

DLV11-E

DLV11-F

DUV11

DPV11

113

uNOTE # 015
page 4 of 4

NOTES:
(1)

The information in the BDVII column refers to the Rev A
chips. There were also Rev 0 chips and an additional TU58
chip that can be added to the board:
Rev 0:
Part numbers 23-010E2, 23-011E2
Does NOT support:
DLVII-F, RX02 as bootable devices
TU58 ROM:
Part number 23-126F3
Inserted into socket XE40. Other ROM must be
Rev A. Allows use of the TU58 DEC tape II as
a bootable device.

(2)

The MXVII-B2 Bootstrap ROMs can be used with the MXV11-BF
multifunction module as well as the MRV11-D ROM module.
It will not work with the MXVI1-A module.

(3)

The RC25 adapter board must be configured at the the DEC
standard base address for the first MSCP controller
(772150). Other MSCP controllers may also reside but
may not be booted.

114

uNOTE # 016

Date: 16-0CT-84

KXT11-CA Software Development Tools

Title:

Page 1 of 8

Originator: Scott Tincher

The KXT11-CA is a single board computer (SSC) which executes the PDP-11
instruction set.
It may be utilized as a stand-alone SSC or interfaced
to the Q-bus as a peripheral processor or as an intelligent I/O
processor
(lOP). This article will describe the software tools
available to develop applications in either the stand-alone mode or the
lOP mode.
The KXT11-CA features:
o

T11 Microprocessor
instruction set

32K bytes of on-board static RAM

Two 28-pin sockets for up to 16K
additional RAM or 32K bytes of ROM

Three serial line units:
o
o
o

which

implements the PDP-11

bytes

One asynchronous DL compatible line (RS232)
One synch/asynch line with modem control
(RS449)
One synch/asynch with data and timing only
(RS449)
.

20 programmable parallel I/O lines

Three 16-bit programmable interval timers

2-channel DMA controller

Q-bus interface

Four diagnostic LEDs

The Q-bus interface of the KXTI1-CA allows up to 14 KXT11-CAs to be
added to a traditional Q-bus system. AS a slave device the KXT11-CA
offloads the arbiter CPU's processing activities by providing real-time
I/O data buffering, preprocessing, and high speed communications.

115

uNOTE i 016
Page 2. of 8
ThE! KXT11-CA is especially suited for applications with critical
interrupt latency requirements or applications that must service a high
frequency of interrupts.
The KXT11-CA may also be used as a
computational engine in applications where it is possible to partition
the application to run in parallel.
The

software
development environment for systems which utilize
is slightly different from that of the traditional Q-bus
The system programmer must develop application programs for
each KXT11-CA in the system in addition to the application code which
runs on the arbiter cpu.
Different software application tools are
available for the arbiter and "onboard" environments.
(When used in
stand-alone mode only the onboard environment need be considered.)
KX1~11-CAs
sysltem~

THE ARBITER ENVIRONMENT
The- arbiter
systems:

system

may

run

MicroPower/Pascal

RT-11

RSX-11M

RSX-11M-PLUS

under

any

the following operating

Each of these operating systems offers a device handler for the
two-port RAM of the KXT11-CA as well as a utility for loading
application
programs
across
the Q-bus into the KXT11-CA.
A
MicroPower/Pascal application may be coded in Pascal and MACRO-ll.
RT-ll and RSX-ll applications will be coded in MACRO-ll or a high level
language,
such as FORTRAN, which is capable of issuing programmed
requests {RT-ll) or QIO directives (RSX-ll).
USING A MICROPOWER/PASCAL ARBITER SYSTEM
If the arbiter system controlling the application is running in a
MicroPower/pascal environment there are KXTll-CA specific functions
available to aid in program development.
The first component is the KX
device handler.
This handler provides the arbiter-side interface to
the two-port RAM of the KXTll-CA.
The KX handler supports up to 14
KXTll-CAs on the Q-bus.
Two functions are supplied which simplify the
interface between the application program and the KX handler.
These
functions are:
o

KX write data:
Transfer data from an arbiter
butfer
to a KXTll-CA process and return a
completion-status value.

116

uNOTE # 016
page 3 of 8
o

KX read data:
Transfer
proc~ss
to an arbiter
completion-status value.

data from a KXTII-CA
buffer and return a

Micropower/pascal
also
provides
a
function which transfers a
MicroPower/Pascal
.MIM file from the arbiter to a KXT11-CA.
This
function,
KXT LOAD, reads a .MIM file from the arbiter and initiates a
DMA transfer using the DTC of the KXT11-CA to transfer the file to the
KXT11-CA's local memory.
This procedure may be called at any time by
the arbiter's application program - not necessarily at system startup
time.
MicroPower/pascal also supplies the symbolic debugger PASDBG.
supplies the following features:
o

A set of debugger commands and qualifiers that
allow for control of an executing program.

Access to the symbol table generated by the
Pascal
compiler,
providing symbolic (Pascal
language) referencing and variable access.

Access
to
structures.

Control of an application system not configured
for terminal I/O.

A method
error.

A method for loading a program on the application
system
while
PASDBG is running on a host
computer.

process

for

user

control

variables

PASDBG

and

after an execution

USING AN RT-11 OR RSX-11 ARBITER SYSTEM
If the arbiter system controlling the application is running in a RT-11
or RSX-11 environment there are tool kits available to aid in program
development.
They are the KXTII-C/RT-11 Peripheral Processor Tool Kit
(QJV51) and the KXT11-C/RSX-11 Peripheral Processor Tool Kit (QJV52).
There are two major components in each of these tool kits.
the KX device handler and the KUI utility program.

They are

The KX device handler manipulates the two-port RAM of the KXT11-CA so
that it appears to be a standard Q-bus I/O device. The KUI utility
program allows programs to be load~ed into a peripheral processor from
the arbiter, performs debugging operations, starts execution of KXT11-C
programs, and initiates KXT11-CA self tests.

117

UNOTE # 016
Page 4 of 8

The KX handler supplied with the RT-11 tool kit supports up to four
KXT11-CAs where each KXT11-CA appears as two logical units.
More than
four KXT11-CAs may be supported by editing, renaming, and rf~building
the KX handler.
The following
handler:

RT-11

programmed

requests

are

supported

.OPEN
associates a user-specified
number
with
a logical unit number
KXT11-CA.

.CLOSE
frees a previously opened channel for
use with another device or file.

. READ
processor
.READC)

.WRITE - transfers data from an arbiter buffer to
a
peripheral
processor.
(.WRITE,
.WRITEW,
. WRITEC) .

the KX

channel
of the

transfers
data from a peripheral
to an arbiter buffer.
(.READ, .READW,

The KX handler supplied with the RSX-11 tool kit supports up to 14
KXT11-CAs.
The KX handler assigns a unit number for each data channel
in each KXT11-CA two-port RAM. This handler supplies the following
RSX-11 I/O requests:
o

IO.RVB
Read a virtual block of data from the
device unit unit specified in the macro call.

IO.WVB
write a virtual
physical device unit.

IO.ATT - Attach a physical device to the control
of the task which issued the request.

IO.DET
Detach a physical device from the
control of the task which issued the request.

block

of data to a

Included in the RT-11 and RSX-11 tool kits is the KUI (KXT11-CA User
Interface) utility program.
The KUI program has several commands which
supply the following functions:
o

@ - Process commands from the specified indirect
command file.

CLOSE
command.

the

file

118

specified

in the LOG

uNOTE # 016
Page 5 of 8
start

program

the

specified

EXECUTE
KXT11-CA.

EXIT
Exit the
operating system.

LOAD
Load a program from the arbiter's mass
storage to arbiter memory. Then perform a DMA
operation to transfer the image to the specified
peripheral prQcessor's memory. KUI under RT-11
supports the transfer of .SAV, .LDA, and .MIM
files.
KUI under RSX-11 supports the transfer of
.TSK and .MIM files.

LOG
Record all commands, status information,
and messages during this terminal session in the
specified file.
The CLOSE command terminates the
logging session.

ODT
Executes the octal debugging tool (ODT).
This tool allows the arbiter system to examine
and modify the contents of registers and memory
local to a KXT11-CA.
ODT may also be used to
start or halt a program.

REINIT
Reinitialize the specified peripheral
processor and reboot it's application.

RESUME
Causes a
continue execution.

SELFTEST
Causes one or more
diagnostic programs to execute.

SET
Specifies a peripheral processor as the
target for subsequent commands.

SHOW
Displays information about the state of
the peripheral processor.

SUSPEND
Used in an indirect command file to
halt execution of the file.
The RESUME command
can return control to the command file.

TRAP
performs a trap emulation so that a trap
handling routine can be tested.

KUI utility and return to the

SUSPENDed

119

command
of

file to
several

uNOTft~

# 016
Page 6 of 8

THE ONBOARD PROGRAMMING ENVIRONMENT
The KXTll-CA may be programmed in ei ther MACRO-l1 or MicroPOWEtr/Pascal.
MicroPower/Pascal provides the ability to program the onboard devices
in a high-level language, pascal.
In particular Micropower/pascal
provides the following device handlers:
o

DO:
This handler supports the TU58 tape drive.
It allows the TU58 to be interfaced to any of the
asynchronous I/O channels.

KK:
This handler manipulates the two-port RAM
from the KXTll-CA side in the KX/KK protocol.
This protocol allows the KK handler to pass
variable length messages to the arbiter system by
emulating a traditional Q-bus slave device. Two
functions
are
supplied
which simplify the
interface between the user's application code
and the KK handler. These functions are:

KK read data: transfer data from the arbiter
return
to
a
KXTll-CA
buffer
and
a
completion-status value.

KK write data: transfer data from a KXTll-CA
burfer
to
return a
the
arbiter
and
completion-status value.

QD:
This handler supports the two-channel DMA
transfer
controller (DTC).
The QD handler
enables the DTC to move data from source to
destination without the aid of the cpu. One
location, source or destination, must be local to
the KXTll-CA. The QD handler may be used for the
following functions:
0

Transfer data to and from Q-bus memory.

Transfer data to and from local memory.

Search for data.

Transfer to and from local I/O devices.

Access the Q-bus I/O page.

Assure access to a DMA Channel.

XL:
Supports asynchronous communications on the
three serial ports of the KXT11-CA. The first
port is a standard DL device. The second port is
channel A of the multiprotocol chip.
This

120

uNOTE
016
Page 7 of 8
channel is supported \{ith full modem controls.
The third port is channel B of the multiprotocol
chip.
This channel is supported as though it
were a standard OL devicE~.
All three channels
may be operated simultaneously.
o

XS:
Supports synchronous operation of channel A
of the multiprotocol chip. The handler provides
the
following
bit-()riented
communication
procedures:
o

Synchronization

(Flag detection)

Transparency

Invalid frame detection

Frame abortion detection

Frame
check
checking/calculation

(Bit stuffing)

sequence

(rcs)

The

handler can be used by user-written software as
component in performing bit-oriented protocols
such as X.25, HOLC, SOLC, and others.

YK: Supports the parallel I/O port and the three
counter-timers.
The
handler provides the
functions of read, write, pattern recognition,
OMA
read,
OMA
write,
counter-timer
set,
counter-timer
read, and counter-timer clear.
Typical parallel port operations are:
o

Transferring a series of bytes or words
through a port with handshake protocol.

Setting or reading the bits of external state
lines.

Generating a time base to software.

Generating a waveform for external output.

Counting pulses from an external input.

These Micropower/Pascal device handlers do not support all of the
functions of ehe onboard devices of the KXT11-CA. For this reason, or
because of preference, the application code for the KXT11-CA may also
be written in MACRO-11.

121

uNOTE # 016
:f?age 8 of 8
RELATED DOCUMENTS
For further
information pertaining to the KXT11-CA and it's software
dE!velopment tools please reference the following materials:
KXT11-CA Single-Board Computer User's Guide

EK-KXTCA-UG

KXT11-C Peripheral Processor Software User's Guide

AA-Y61SA-TK

122

uNOTE # 017

Title: LSI 11/23 ECO History

Date: 19-NOV-84

Originator: Bob Hessinger

Page 1 of 8

This micronote documents the ECO and etch revision history of the
KOF11-A (LSI 11/23) module. A quick verify has been included so that
the status of a module may be determined by a visual check.
For the M8186, the revision identifier is a two field alphanumeric
designation stamped on the reverse side of the module handle. The first
field indicates the etch revision.
The second field indicates the'
modifications to this etch.
Hardware revision notation :
A 0

Identifies etch level

Identifies modifications

The M8186 began as hardware revision "AO", as shown above.
That is,
etch revision "A" with no modifications or rework. As ECO's were
released calling for rework, the hardware revision level was updated to
"A1", then "A2", etc. Periodically new etch revisions were released,
incorporating previous modifications.
When these occurred the etch
revision field was updated from "A" to "C", and later from "e" to "0".
For the M8186, no etch revision "B" was released.

123

uNOTE # 017
Page 2 of S
The hardware revision history of the MS1S6 is shown below:
Release

Rework
ECO #1

Rework
ECO #2

NOTE: All modules
shipped are at
rev A3 or greater

Rework
ECO #3

NOTE : New etch
rev C created. No
rev B boards were
built

Relayout
ECO #4

I
I

co
A4

Rework
ECO #5
Rework
ECO #6
Rework
ECO #7
Rework
ECO #S
Rework
ECO #9
Rework and
Relayout
ECO #10
Rework
ECO #11

124

I
I
A6
I
A6
I
.A7
I
.AS

NOTE: Rev C layout
incorporates changes
for ECO #5

I
I
C2
I
C2 NOTE: This was a
documentation change
only
IC3
I
C4 DO

NOTE: This was a
documentation
change only

uNOTE # 017
Page 3 of 8
,Jumper Functions on Etch Revision "A", "C" and "D" Modules
Jumper

Function

Description

Shipped

Master Clock

In - Enabled, do not remove

W2,W3

DEC Reserved

Factory configured, do not
change (see note 1 )

W2-0ut
W3-In

BEVENT

Out - Enabled

W5,W6

Power-up Mode

Mode
0 - PC-24,PS-26
1 - Console ODT
2 - Bootstrap
3 - Reserved

Halt/Trap
Option

In - Trap to 10 on Halt
Out - Enter Console ODT
on Halt

Out

Bootstrap
Address

In - Boot to 17773000
Out - Bootstrap address
specified by jumpers W9-W15

W9-W15

Use r Bo,otstrap
Address

W9-W1S correspond to address
bits 9-15 respectively.
In - logic 1, Out - logic 0

W16,W17

DEC Reserved

Factory configured, do not
change

W5
Out
In
Out
In

W6
Out
Out
In
In

Mode 1
W5-In
W6-0ut

Etch A only
W18

DEC Reserved

Factory configured, do not
change

W19

wake-up Circuit

Out - enabled
This jumper is a red wire
across diode D1

Etch C and D only
w18

note 1

Wake-up Circuit

W3 on etch A modules consists of a jumper from E2 pin 5 to
E2 pin 15.

125

uNOTE # 017
Page 4 of 8

W18
01

(W19 - see text)

W17 W1
W16
i

W15
W14
W13
W12
W11
W10
W9
W8
W6
W7
w6
w5

I
W2 -

W4 -

I
KOF11-A REV A Jumper Layout

126

uNOTE # 017
Page 5 of 8

01(W18 - see text)

W1-

W15
W14
W13
W12
W11
W10
W9
W8
W6
W7

W4 -

W16
W17

KOF11-A REV C Jumper Layout

127

uNOTE # 017
Page 6 of 8

W18 ·1

Wl - -

W15
W14
W13
W12
Wll

W10
w9
w8
w6
W7
w6

W4 -

W3
W2

W16
W17

KDF11-A REV D Jumper Layout

128

uNOTE # 017
page 7 of 8
The following table details the ECOI'S issued since the M8186 began to
ship to the field.
These ECO's are coded "M8186-MLOXX", where "XX" is
the ECO number shown below :
ECO #
04

Problem

Quick Verify

Too many wires and etch cuts, new etch
needed. Note that the jumper locations

Module handle will be
stamped "Cn" where n

change for etch Revision C.
Note also that etch A boards bring only
18 bits of addressing from the MMU to the
Q-BUS, while etch C boards bring all 22
bits of addressing from the MMU to the
Q-BUS.

indicates
modifications.

I/O page addressing scheme differs from
LSI-11/2 processor.

Check for etch cut
to E7 pins 16 and 18
(rev A boards only)

The internal wake-up circuit defeats the
power sequencing provided by standard
DEC power supplies.

Red jumper wire is
installed in parallel
with 01.

CTL/DAT hybrid (57-00000-00) and MMU IC
(21-15542-00) were not compatible with
KEFI1-AA floating point option. The FP
registers in the MMU were inaccessible,
and the CTL/DAT data path caused
intermittent errors in floating point
instructions.

CTL/DAT should be
57-00000-01 or higher
and,MMU should be
21-15542-01 or higher
for floating point
compatibility.
Coordinate with ECO
M8186-ML009

MMU (21-15542-01) was in.cluded as part of
the M8186 module. This documentation
change removes the MMU and makes it an
option which is ordered separately.

Some modules mayor
not have MMUs,
depending on the
options ordered.

129

uNOTE # 017
Page 8 lof 8
ECO :i

Problem

Quick Verify

1) No jumper table in print set (doc only)
2) Crystal oscillator may short to adjacent
components

3) Possibility of worst case MMU timing
violations. Chang~ configuration
of W2 and W3 to adjust timing. This
ECO must be installed :
A) When ECO m8186-ML007 is installed
B) When the KEF11 or FPF11 is installed
C) When one of the F-11 chips is replaced
D) Whenever unexplained system crashes
occur

1) Table added
2) Manufacturing
includes nylon
spacer
3) Module will have
W2 removed and W3
in. On rev A
modules w3 is a
wire from E2 pin
5 to E2' pin 15.

1) Heavily loaded systems lock up during
worst case timing between DMA and
interrupt arbitration. Symptoms
usually occur with DMA options not
manufactured by DEC.
2) Too many wires and etch cuts, new etch
needed. Note W18 now uses jumper posts.

1) Rev A and Rev C
modules will have
wires on E2 pins
2 and 4.
Rework
included in Rev D.
2) Module handle will
be stamped "Dn"
where n indicates
modifications.

Documentation updated.

Documentation only.

130

uNOTE

Title:

programming the KXT11-CA DMA controller

Originator: Scott Tincher

41:

018

Date: 28-DEC-84
Page 1 of 24

The KXT11-CA intelligent
I/O
processor
contains
several
user
pr'ogrammable devices. One of these devices is a DMA transfer controller
(DTC). This article will describe the features of the DTC and provide
some programming examples.
This article is intended for use by
individuals interested in programming the DTC using MACRO-11.
DIGITAL
supplies
a
DTC
device
driver
for
those
programmers
using
MicroPower/pascal. A working knowledge of MACRO-11 and of the KXT11-CA
is assumed.
FEATURES/CAPABILITIES
The DTC is addressable by the local T-11 microprocessor as an I/O
device.
It is capable of performing DMA transfers between any of the
following addresses:
1)

A 16-bit local address to a 16-bit local address

A 16-bit local address to a 22-bit global address

A 22-bit global address to a 16-bit local address

A 22-bit global address to a 22-bit global address

To/From channel A of the multiprotocol SLU

To/From the PIO chip

Word, high byte, and low byte transfers are supported
word transfers are supported across the Q-bus.

locally.

Only

The operations of the DTC are controlled by several internal registers.
It was designed with the capabilty of loading these registers directly
from memory thereby minimizing the amount of processor intervention
necessary to perform a DMA transaction. The area of memory where the
parameters for the DTC are stored is referred to as the chain table.
The local microprocessor need only load the address of the chain table
into the DTC a-nd give a "start" command to initiate a DMA transfer.

131

uNOTE # 018
Page 2 of 24
transactions may be initiated locally by the T11 or by the arbiter
If the transfer is initiated by the arbiter the command words and
transfer parameters are placed in the command registers of the two-port
RA~~
file.
The local CPU will then initiate the DMA transaction using
the parameters supplied by the arbiter.

Dru~

cpu.

DTC consists of two identical channels.
DMA transfers may be
interleaved between these two channels or interleaved between the DTC
and the T-11. It is also possible to select a "hog mode" that allows
thE! DMA transfer to run to completion without interruption.
ThE~

The DTC supports three types of operations:
Transfer, Search, and
Transfer-and-Search. As the name implies, Transfer operations move data
from a source to a destination. Search operations read data from a
source and compare the data to the pattern register. A mask register
allows the user to declare "don't care" bits.
The Transfer-and-Search
operation combines the features of the Transfer and Search functions.
In this type of operation data is transferred between a source and
destination until the data transferred meets the match condition
specified in the Channel Mode register.
ThE~ DTC is capable
of performing multiple DMA transactions without
processor
intervention.
This can be accomplished in two ways:
base-to-current reloading or chaining. Base-to-current reloading allows
thE~
DTC to reload a portion of its registers before initiating a DMA
transfer. The reload operation occurs between internal registers so
there are no memory access related delays. This type of operation is
only practical in applications where data is continuously transferred
between the same addresses.
Chaining allows all of the applicable
registers of the DTC to be reloaded from a new chain table.
Therefore
this is a slower but more flexible alternative.

Upc)n completion of a DMA transfer the DTC may perform any combi.nation of
thE!
following
options:
Interrupt the local processor, perform
base-to-current reloading, or perform a chain reload.
It may also
choose to take no action.

DTC REGISTERS
Among the internal registers of the DTC are two chip-level registers,
thE! Master Mode register and the Command register. These registers
control both channels of the DTC. In addition, each channel of the DTC
is controlled by several channel-level registers.
For the sake of
completeness a brief description of these registers will be included
here.
For a detailed description refer to the KXTII-CA Single Board
computer User's Guide (EK-KXTCA-UG-OOl).

132

uNOTE
018
Page 3 of 24
CHIP-LEVEL REGISTERS
Master Mode Register
The Master Mode register controls the chip-level interfaces.
to:
-

It is used

Enable/disable the DTC
Select DTC/CPU interleaving
Enable/disable asynch operation
Enable/disable countet/timer interrupt request
Enable/disable interrupt save vector

Command Register
The command register is used to issue commands to the DTC channels
as: Reset, Start Chain, etc.

such

CHANNEL-LEVEL REGISTERS
(Each of the following registers is present in each channel of the DTC)
Current Address Registers A and B (CARA, CARB)
CARA and CARB consist of two words, the segment/tag and the offset.
segment/tag is used to indicate:

The

- Address bits <21:16> of the source (or destination)
- If the source (or destination) resides on the a-bus
- Whether the source (or destination) address should be
incremented, decremented, or held constant
- Whether wait states should be included
The offset is used to indicate:
- Address bits <15:00>
Base Address Registers A and B (BA.RA, BARB)
BARA and BARB are identical to CA~A and CARB. They are used to reload
CARA and CARS if base-to-current reloading is selected after a DMA
operation has terminated.

13:3

uNOTE # 018
Page 4 of 24
Current Operation Count Register (COPC)
This 16-bit register is used to specify the number of words (or bytes)
to be transferred during a DMA operation. The maximum word count is
obtained by programming this register with a zero.
Base Operation Count Register (SOPC)
This register is identical to the COPC register. It is used to
the COPC register when base-to-current reloading is selected.

reload

Pattern and Mask Registers
The Pattern and Mask
registers
are
used
during
Search
and
Transfer-and-Search operations.
The contents of the Pattern register
are compared to the read data to generate a "match" condition. The Mask
register is used to generate "don't care" bits. Setting a bit to '1' in
thE! Mask register specifies that the bit always matches.
Status Register
ThE! status register is a 16-bit read-only register which returns the
status of the following fields: Interrupts status, DTC status, Hardware
interface status, and Completion status.
Interrupt vector and Interrupt Save Registers
The Interrupt vector register contains the vector that is output during
an interrupt acknowledge cycle. When an interrupt occurs the contents
of the Interrupt vector register and a part of the Status register are
stored in the Interrupt Save register. This allows a new vector to be
loaded during chaining so that a new DMA operation can be performed
before an interrupt acknowledge cycle occurs.
Channel Mode Register
ThE! Channel Mode register consists of two words, channel mode
channel mode low. Channel mode low is used to indicate:

high

and

- The operation type (transfer, search,
transfer-and-search,bytes,words)
- Whether CARA (or CARS) defines the source (or destination)
- Transfer type (single, hog mode, interleaved)

134

uNOTE # 018
Page 5 of 24
- Completion options (interrupt CPU, base-to-current reload,
chain reload)
Channel mode high is used to:
- indicate match conditions
- mask the hardware requests for DMA operations
- cause the channel to request the bus for a DMA operation
Chain Address Register
The chain address register consists of two words,
the segment/tag and
the offset.
This register is used to point to the reload word, the
first word in a chain table.
The sE~gment/tag is used to indicate:
whether the reload word resides in Q-bus memory
Whether the reload word resides in the Q-bus I/O page
- Address bits <21:16>
The offset is used to indicate:
- Address bits <15:00>

PROGRAMMING THE DTC
programming the DTC consists of three phases: Chip Initialization, Data
Transfer
(or Search), and Termination.
This section will provide a
general description of these phases.
CHIP INITIALIZATION
The Reset instruction is used to place the DTC in a known state.
A
reset will clear the CIE, IP, SIP and WFB bits and set the CA and NAC
bits in the Channel Status registers.
The Master Mode register will
also be cleared.
Before a DMA operation is initiated the local CPU
loads the Master Mode register and the Chain Address register of the
appropriate channel of the DTC. The DTC fetchs any other parameters
that are necessary from a table located in system memory referred to as
the chain t~ble.
This minimizes the amount of CPU intervention
necessary to perform a DMA operation. ·The relationship of the Chain
Address register to the chain table is shown in Figure 1.

135

uNOTE # 018
page 6 of 24
System
Memory
DTC
Channel 0/1

,....------>

Reload Word
DTC
Register
Data

Chain
Address
Reg.

- - - - - - - - New Chain Address

Reload Word

DTC
Register
Data

- Figure 1 The first word in the chain table is the reload word. The reload word
is used to specify which registers are to be loaded for the pending DMA
operation. Bits <9:0> of the reload word correspond to the re9isters of
the DTC as shown in figure 2. Bits <15:10> are not used.
Reload Word

I x

Ix Ix Ix Ix I

Current ARA
I
Current ARB
Current Op-Count - - - - - - - - - - - - - - '
Base ARA ---------------------------~.
Base ARB
Base Op-Count
Pattern and Mask
Interrupt Vector
Channel Mode -------------------------------------------~
Chain Address
Figure 2 -

136

uNOTE i 018
page 7 of 24
Therefore if a bit in the reload word is set then the corresponding
register is to be reloaded from the chain table. Since all of the
registers are not applicable to each DMA operation the chain table may
be of variable length. (i.e. The pattern and mask registers would not
be used in DMA operations that do not search the data.) It is NOT
correct to select a register in the reload word and subsequently load
that register with a dummy argument such as zero.
The following are
examples of the relationship between th~ reload word and the chain
table.
8

Ix IxIxIxIxI1 I1

7
1
Ii

Current ARA

I0 I0 I0 I0 I0 I1 I0

Segment/Tag

Current ARA
Current ARB

Offset
Segment/Tag

Current ARB

Offset

Current Op-Count
Channel Mode High
Channel Mode Low

x I x I xl x J x 1 x 1 1 l 0 1 1 I 0 I 0 I 0 1 1 1 0 1 1 I 1
Current ARA
Current ARA

Segment/Tag
Offset

Current Op-Count
Pattern Register
Mask Register
Channel Mode High
Channel Mode Low
Chain Address Segment/Ta9
Chain Address Offset

137

uNOTE # 018
Page 8 of 24
The DTC has been properly initialized once the chain table(s) have been
created and the Master Mode register and Chain Address Register for the
selected channel have been loaded.
DATA TRANSFER
The DTC may perform a DMA operation once it has been properly
initialized.
A DMA operation may be initiated in one of four ways: by
so1:tware request, by hardware request, by loading a set software request
bit: in the Channel Mode register during chaining, or as the result of a
command from the arbiter.
Software Request: The local CPU may initiate a DMA operation by writing
a 'software request' command followed by a 'start chain' command to the
Command register. The 'software request' command sets the software
request bit in the channel's Mode register. If either the SIP (second
interrupt pending) bit or the NAC (no auto-reload or chain) bit is set
in the channel's status register the DMA operation will not begin. The
SIP bit will be cleared when the channel receives an interrupt
acknowledge.
The NAC bit will be cleared when the channel receives a
'start chain' command. The 'start chain' command initiates the DMA
operation after the registers of the selected channel are loaded from
the chain table. The 'start chain' command is ignored if the SIP bit or
the CA (Chain Abort) bit are set in the channel's status register. The
SIP bit was described above. The CA bit is cleared when the channel's
chain address register is reloaded.
Hardware Request: DMA operations may be started by applying a 'low' on
the channel's DREQ input. No details about this type of request will be
provided since they fall beyond the scope of this note.
Starting After Chaining: If the software request bit of the channel's
Mode register is loaded during chaining the channel will perform the DMA
operation at the end of chaining.
Arbiter Request: The arbiter may interrupt the local CPU to request a
DMA operation.
This is accomplished by passing parameters to load the
chain address register of channel 0 via the two-port RAM.
The arbiter
loads register 2 of the TPR with the offset of the chain address
register and register 3 of the TPR with the segment/tag of the chain
address register.
The DMA operation is then initiated by setting the
DMA Loa d bit (b i t 1) in the TPR comma nd reg i s t e r ( reg i s t e r 0 ) .,
Err 0 r
conditions will be returned in TPR register 1.
Information in tAe channel's Mode register determines what type of DMA
operation will be performed. The Channel Mode register consists of two
\iords, Channel Mode High and Channel Mode Low.
Bits <3:0> of the Channel Mode Low register select the type of DMA
operation. These bits determine whether the data should be transferred,

138

uNOTE
018
Page 9 of 24
searched, or transferred-and-searched. Bit 4 is the flip bit.
It is
used to determine which set of current address registers (CARA, CARB)
points to the source.
Bits <6:5> determine the transfer type. The types of DTC transfers are:
single transfer, demand dedicated with bus hold, demand dedicated with
bus release, and channel-to-channel demand interleave. Single transfer
is used with devices which transfer data at irregular intervals. A
single DMA transaction will occur e.ach time a 'software request' command
is issued or the DREQ input is asserted. Demand dedicated with bus hold
is a software hog mode. This mode allows the DMA transaction to run to
completion as long as there is a valid op count and the DREQ input is
asserted. If the DREQ input is not asserted no DMA operations will
occur but the channel will retain bus control. Demand dedicated with
bus release is similar to demand dedicated with bus hold in that a DMA
transaction is allowed to run to completion if DREQ is asserted. If
DREQ is not asserted the DTC must rlelease the bus thus allowing other
devices
to
obtain
the
bus.
The
operation
performed by a
channel-to-channel demand interleavle request depends on the state of bit
2 in the Master Mode register. If MM bit 2 is clear then control may be
passed between each channel of the lDTC without the need to release the
bus.
If MM bit 2 is set then the DTC must share the bus with the local
processor. The DTC will release the bus and then re-request it after
every DMA iteration.
Bits <1:0> of the Channel Mode High register are used to determine
type of match control in Search and Transfer-and-Search. operations.
DTC is capable of generating a termination condition based on
Match', 'Word Match', and 'Byte Match'.

the
The
'No

Bit <4> of the Channel Mode High re9ister causes the channel to request
the bus and perform transfers l~hen it is set by a 'Software Request
Command' or a chain reload.
TERMINATION OPTIONS
Bits <15:7> of the Channel Mode Low register control the termination
options. A DTC operbtion may be terminated in a number of ways. If the
Current Operation Count Register gOles to zero then a Terminal Count (TC)
termination is generated. External logic may assert the End Of Process
(EOP) input of the DTC to generate an EOP termination at any time.
In
addition, during a Search or Transfer-and-Search operation a match
condition may occur which generates a MC termination. Bits <15:7> allow
the DTC to perform a chain reload, a base-to-current reload, or to
interrupt the local processor if a Irc, EOP, or MC termination condition
is encountered.
If bits <15:7> are cleared then no special action is
initiated whe& a TC, EOP, or MC condition is encountered.

139

uNOTEI: 018
Page 10 of 24
EXl\MPLES
ThE~ following example programs were developed
on a PDP-11/23+ system
with 256KB of memory using the RT-11 (version 5.1) operating system with
These examples
the KXT11-C Peripheral Processor Software Toolkit.
assume the programmer is familiar with MACRO-II and the KXTII-C
Peripheral Processor Toolkit.

140

uNOTE # 018
Page 11 of 24
.TITLE EXAM1.MAC
; This program transfers data from local KXT11-C addresses to other
local KXT11-C addresses.
This program should be compiled and linked
on the development system and then downloaded into the KXT11-C using
the KXT11-C Software Toolkit.

Once the program has been compiled and

linked use the following KUI commands to execute it and verify its
; successfullness.
;

;
;
;

.KUI
KUI>SET n
KUI>LOAD EXAM1
KUI>ODT

Where n is the appropriate KXT11-C
Use KUI ODT to verify that the destination
addresses are cleared

ODT>AC
KUI>EXECUTE
KUI>ODT

Execute EXAM1
Use KUI ODT to verify that the transfer was
success:Eul

ODT>AC
KUI>EXIT
SET UP REGISTER ASSIGNMENTS

START:

174470
174454
174446
174442

MASTER MODE REGISTER
COMMAND REGISTER
CHAN 0 CHAIN ADDRESS SEG/TAG FIELD
CHAN 0 CHAIN ADDRESS OFFSET FIELD

MMREG
CMDREG
CASTFO
CAOFO

MOVB

#130,MMREG

LOAD MASTER MODE REG TO DISABLE DTC

CLRB

CMDREG

RESET THE DTC

MOV
MOV

#O,CASTFO
#RELOAD,CAOFO

LOAD THE CHAIN ADDRESS REG SEG/TAG
LOAD THE CHAIN ADDRESS REG OFFSET

MOVB

#131,MMREG

LOAD MASTER MODE REG TO ENABLE DTC

MOVB

#102,CMDREG

SET SOFTWARE REQUEST CHANNEL 0

MOVe-

#240,CMDREG

START CHAIN CHANNEL 0

==
==

STAY HERE WHILE THE USER VERIFIES
THAT THE PROGRAM WAS SUCCESSFUL

BR
; CHAIN LOAD REGION
RELOAD:

.WORD

001602

; RELOAD ~qORD <Select CARA, CARB, COPC, CM>

141

uNOTE # 018
Page 1.2 of 24
.WORD
.WORD

000000
SOURCE

CURRENT ADDRESS REGISTER A SEG/TAG
CURRENT ADDRESS REGISTER A OFFSET
<This local address is the source>

.WORD
.WORD

000000
DESTNT

.WORD

000013.

CURRENT OPERATION COUNT <Transfer 1.3 words>

.WORD
.WORD

000000
000040

CHANNEL MODE REGISTER HIGH
CHANNEL MODE REGISTER LOW
<No match conditions, do nothing upon
completion, tran~fer type - Demand Dedicated
w/Bus Hold, CARA - source, word transfers>

SOURCE:

.WORD

1,2,3,4,5,6,7,6,5,4,3,2,1

DESTNT:

.BLKW

13 .

CURRENT ADDRESS REGISTER B SEG/TAG
CURRENT ADDRESS REGISTER B OFFSET
; <This local address is the destination>

. END START

142

uNOTE
018
Page 13 of 24
.TITLE EXAM2.MAC
This program transfers data from local KXT11-C addresses to
global Q-bus addresses. This program should be compiled and linked on
the development system and then downloaded into the KXT11-C using the
KXT11-C Software Toolkit. Once, the program has been compiled and
linked use the following commands to execute it and verify its
successfullness.
<HALT the development machine so that locations may be examined
with Q-bus ODT>
@600000/xxxxxx
Examine the destination locations and clear
them if necessary

@600030/xxxxxx
@P

Use the 'P' command to return to the
system prompt

.KUI
KUI>SET n
KUI>LOAD EXAM2
KUI>EXECUTE
KUI>EXIT
;

Where n is the appropriate KXT11-C

<HALT the development machine so that locations may be examined
with Q-bus ODT>
@600000/xxxxxx
Examine the destination locations to verify
the success of the transfer

@600030/xxxxxx
SET UP REGISTER ASSIGNMENTS

START:

MASTER MODE REGISTER
COMMAND REGISTER
CHAN 0 CHAIN ADDRESS SEG/TAG FIELD
CHAN 0 CHAIN ADDRESS OFFSET FIELD

MMREG
CMDREG
CASTFO
CAOFO

MOVB

#130,MMREG

LOAD MASTER MODE REG TO DISABLE DTC

CLRB

CMDREG

RESET THE DTC

MOV
MOV

#O,CASTFO
#RELOAD,CAOFO

LOAD THE CHAIN ADDRESS REG SEG/TAG
LOAD THE CHAIN ADDRESS REG OFFSET

MOVB

#131,MMREG

LOAD MASTER MODE REG TO ENABLE DTC

MOVB

#102,CMDREG

SET SOFTWARE REQUEST CHANNEL 0

MOVB

#240,CMDREG

START CHAIN CHANNEL 0

=
=

174470
174454
174446
174442

143

uNOTE # 018
Page 14 of 24

STAY HERE WHILE THE USER VERIFIES
THAT THE PROGRAM WAS SUCCESSFUL

BR
; CHAIN LOAD REGION
RELOAD:

.WORD

001602

RELOAD WORD <Select CARA,CARB,COPC,CM>

.WORD
.WORD

000000
SOURCE

CURRENT ADDRESS REGISTER A SEG/TAG
CURRENT ADDRESS REGISTER A OFFSET
<This local address is the source>

.WORD
.WORD

101400
000000

CURRENT ADDRESS REGISTER B SEG/TAG
CURRENT ADDRESS REGISTER B OFFSET
<This global Q-bus address is the destination>
<This corresponds to address 600000 on the
Q-bus - the DTC uses physical addresses only>

• WORD

000013. ; CURRENT OPERATION COUNT <Transfer 13 words>

.WORD
.WORD

000000
000040

SOURCE: .WORD

CHANNEL MODE REGISTER HIGH
CHANNEL MODE REGISTER LOW
<No match conditions, do nothing upon
; completion, transfer type - Demand Dedicated
w/Bus Hold, CARA = source, word transfers>

1,2,3,4,5,6,7,6,5,4,3,2,1

.END START

144

uNOTE i 018
Page 15 of 24

·TITLE EXAM3.MAC
This program transfers data from global Q-bus addresses to local
KXT11-C addresses.
This program should be compiled and linked on
the development system and then downloaded into the KXT11-C using the
KXT11-C Software Toolkit. Once the program has been compiled and
linked use the following commands to execute it and verify its
successfullness.
<Use Q-bus ODT to deposit values in locations 600000(8) --> 600030(8).
These values will be the source for this operation>
@600000/000001

1 Deposit source values

@600030/000001
@P

Use the 'P' command to return to the system prompt

.KUI
KUI>SET n
KUI>LOAD EXAM3
KUI>EXECUTE
KUI>ODT

Where n is the appropriate KXT11-C
Use KUI ODT to examine the destination locations to
verify the transfer was successful

;

ODT> .
•.

ODT>"C
KUI>EXIT
SET UP REGISTER ASSIGNMENTS

START:

MASTER MODE REGISTER
COMMAND REGISTER
CHAN 0 CHAIN ADDRESS SEG/TAG FIELD
CHAN 0 CHAIN ADDRESS OFFSET FIELD

MMREG
CMDREG
CASTFO
CAOFO

MOVB

i130,MMREG

LOAD MASTER MODE REG TO DISABLE DTC

CLRB

CMDREG

RESET THE DTC

MOV MOV

iO,CASTFO
#RELOAD,CAOFO

LOAD THE CHAIN ADDRESS REG SEG/TAG
LOAD THE CHAIN ADDRESS REG OFFSET

MOVB

#131,MMREG

LOAD MASTER MODE REG TO ENABLE DTC

MOVB

i102,CMDREG

SET SOFTWARE REQUEST CHANNEL 0

MOVB

i240,CMDREG

START CHAIN CHANNEL 0

=
==
==

174470
174454
174446
174442

145

uNOTE # 018
Page 16 of 24

STAY HERE WHILE THE USER VERIFIES
THAT THE PROGRAM WAS SUCCESSFUL

BR
; CHAIN LOAD REGION
RgLOAD:

DESTNT:

.WORD

001602

RELOAD WORD <Select CARA,CARB,COPC,CM>

.WORD
.WORD

000000
DES TNT

CURRENT ADDRESS REGISTER A SEG/TAG
CURRENT ADDRESS REGISTER A OFFSET
<This local address is the destination>

.WORD
.WORD

101400
000000

CURRENT ADDRESS REGISTER B SEG/TAG
CURRENT ADDRESS REGISTER B OFFSET
<This global Q-bus address is the source>
<This corresponds to address 600000 on the
Q-bus - the DTC uses physical addresses only>

.WORD

000013.

CURRENT OPERATION COUNT <Transfer 13 words>

.WORD
.WORD

000000
000060

CHANNEL MODE REGISTER HIGH
CHANNEL MODE REGISTER LOW
<No match conditions, do nothing upon
completion, transfer type = Demand Dedicated
w/Bus Hold, CARB = source, word transfers>
<Notice how similar this reload table is to
the one in EXAM2.
By utilizing the flip bit
in the eM Reg Low no further changes were
necessary to use this table in this example>

.BLKW

13 .

• END START

146

uNOTE # 018
Page 17 of 24
·TITLE EXAM4.MAC
This program transfers data from global Q-bus addres~es to other
global Q-bus addresses.
This program should be compiled and linked
; on the development system and then downloaded into the KXT11-C using
the KXT11-C Software Toolkit. Once the program has been compiled and
linked use the following commands to execute it and verify its
successfullness.
<Use Q-bus ODT to deposit values in locations 600000(8) --> 600030(8).
These values will be the source for this operation>
;

; @600000/000001
;
;

! Deposit source values

; @600030/000001
; @P

Use the 'P' command to return to the system prompt

.KUI
KUI>SET n
KUI>LOAD EXAM4
KUI>EXECUTE
KUI>EXIT

Where n is the appropriate KXT11-C

;

<Use Q-bus ODT to examine the destination locations to verify that
the operation was sucessful>
@610000/xxxxxx

@610030/xxxxxx
@P

Return to system prompt

SET UP REGISTER ASSIGNMENTS

START:

MASTER MODE REGISTER
COMMAND REGISTER
CHAN 0 CHAIN ADDRESS SEG/TAG FIELD
CHAN 0 CHAIN ADDRESS OFFSET FIELD

174470
174454
174446
174442

MMREG
CMDREG
CASTFO
CAOFO

=
=

MOVB

#130,MMREG

LOAD MASTER MODE REG TO DISABLE DTC

CLRB

CMDREG

RESET THE DTC

MOVMOV

#O,CASTFO
#RELOAD,CAOFO

LOAD THE CHAIN ADDRESS REG SEG/TAG
LOAD THE CHAIN ADDRESS REG OFFSET

MOVB

#131,MMREG

LOAD MASTER MODE REG TO ENABLE DTC

MOVB

#102,CMDREG

SET SOFTWARE REQUEST CHANNEL 0

MOVB

#240,CMDREG

START CHAIN CHANNEL 0

==-

147

uNOTE # 018
Page 18 of 24

STAY HERE WHILE THE USER VERIFIES
THAT THE PROGRAM WAS SUCCESSFUL

BR
; CHAIN LOAD REGION
RELOAD:

. WORD

001602

RELOAD WORD <Select CARA,CARB,COPC,CM>

.WORD
.WORD

101400
000000

CURRENT ADDRESS REGISTER A SEG/TAG
CURRENT ADDRESS REGISTER A OFFSET
<This global Q-bus address is the source>
<This corresponds to Q-bus address 600000(8»

.WORD
.WORD

101400
010000

CURRENT ADDRESS REGISTER B SEG/TAG
CURRENT ADDRESS REGISTER B OFFSET
<This global Q-bus address is the destination>
<This corresponds to Q-bus address 610000(8»

. WORD

000013 .

CURRENT OPERATION COUNT <Transfer 13 words>

.WORD
.WORD

000000
000040

CHANNEL MODE REGISTER HIGH
CHANNEL MODE REGISTER LOW
<No match conditions, do nothing upon
completion, transfer type - Demand Dedicated
w/Bus Hold, CARA = source, word transfers>

.END START

148

uNOTE # 018
Page 19 of 24
.TITLE EXAMS.MAC
This program demonstrates how chaining is implemented using the
DTC. A local to local transfer will be initiated under program
control.
Then, using the chaining feature of the DTC, a local to
global transfer will be performed followed by a global to global
transfer and finally a global to local transfer.
The following
diagram illustrates these transfers.
KXT11-C Memory

Q-bus-Memory

;

iTransfer #1
Transfer #2

------->

---->

Transfer #4

Xfer
#3

This program should be compiled and linked on the development system
and then downloaded into the KXT11-C using the KXT11-C Software
Toolkit. Once the program has been compiled and linked use the
following commands to execute it and verify its successfullness.
<Use Q-bus ODT to clear the memory locations 600000(8) --> 600030(8)
and 6100000(8) --> 610030(8) before executing the program>
.KUI
KUI>SET n
KUI>LOAD EXAMS
KUI>EXECUTE
KUI>ODT
ODT> .
ODT> .
ODT>"C
KUI>EXIT

Where n is the appropriate KXT11-C
Use KUI ODT to verify that the destination contents
are accurate

<Use Q-bus ODT to examine the cont~nts of the intermediate
destinations to verify their accuracy>
SET UP REGISTER ASSIGNMENTS
MMREG
CMDREG
CASTFO
CAOFO

=
=
=
=

MASTER MODE REGISTER
COMMAND REGISTER
CHAN 0 CHAIN ADDRESS SEG/TAG FIELD
CHAN 0 CHAIN ADDRESS OFFSET FIELD

174470
174454
174446
174442

149

uNOTE # 018
Page 20 of 24

ST,ART:

MOVB

#130,MMREG

LOAD MASTER MODE REG TO DISABLE DTC

CLRB

CMDREG

RESET THE DTC

MOV
MOV

#O,CASTFO
#LOAD1,CAOFO

LOAD THE CHAIN ADDRESS REG SEG/TAG
LOAD THE CHAIN ADDRESS REG OFFSET

MOVB

#131,MMREG

LOAD MASTER MODE REG TO ENABLE DTC

MOVB

#102,CMDREG

SET SOFTWARE REQUEST CHANNEL 0

MOVB

#240,CMDREG

START CHAIN CHANNEL 0
STAY HERE WHILE THE USER VERIFIES
THAT THE PROGRAM WAS SUCCESSFUL

BR
; CHAIN LOAD REGION
LOAD1

LOAD2

.WORD

001603

RELOAD WORD <Select CARA,CARB,COPC,CM,CA>

.WORD
.WORD

000000
AREAl

CURRENT ADDRESS REGISTER A SEG/TAG
CURRENT ADDRESS REGISTER A OFFSET
<This local address is the source of transfer
#1>

.WORD
.WORD

000000
AREA2

CURRENT ADDRESS REGISTER B SEG/TAG
CURRENT ADDRESS REGISTER B OFFSET
<This local address is the destination of
transfer #1>

. WORD

000013 .

CURRENT OPERATION COUNT <Transfer 13 words>

.WORD
.WORD

000000
100040

CHANNEL MODE REGISTER HIGH
CHANNEL MODE REGISTER LOW
<No match conditions, chain reload upon
completion, transfer type = Demand Dedicated
w/Bus Hold, CARA = source, word transfers>

.WORD
.WORD

000000
LOAD2

CHAIN ADDRESS REGISTER SEG/TAG
CHAIN ADDRESS REGISTER OFFSET
<This address points to the new chain table>

.WORD

001603

RELOAD WORD <Select CARA,CARB,COPC,CM,CA>

.WORD
.WORD

000000
- AREA2

.WORD
.WORD

101400
000000

CURRENT ADDRESS REGISTER A SEG/TAG
CURRENT ADDRESS REGISTER A OFFSET
<This local address is the source of xfer #2>
CURRENT ADDRESS REGISTER B SEG/TAG
CURRENT ADDRESS REGISTER B OFFSET
<This global address is the destination of

150

uNOTE i 018
Page 21 of 24
transfer #2 - 600000(8»
.WORD

000013.

.WORD
.WORD

000000
100040

; CURRENT OPERATION COUNT <Transfer 13 words>
CHANNEL MODE REGISTER
CHANNEL MODE REGISTER
<No match conditions,
completion, transfer

HIGH
LOW'
chain reload upon
type - Demand Dedicated

w/BUS Hold, CARA = source, word transfers>

LOAD3

.WORD
.WORD

000000
LOAD3

CHAIN ADDRESS REGISTER SEG/TAG
CHAIN ADDRESS REGISTER OFFSET
<This address points to the new chain table>

.WORD

001603

RELOAD WORD <Select CARA,CARB,COPC,CM,CA>

. WORD
.WORD

101400
000000

CURRENT ADDRESS REGISTER A SEG/TAG
CURRENT ADDRESS REGISTER A OFFSET
<This global address is the source of xfer #3>
<600000(0»

.WORD
.WORD

101400
010000

CURRENT ADDRESS REGISTER B SEG/TAG
CURRENT ADDRESS REGISTER B OFFSET
<This global address is the destination of
transfer #3 - 610000(8»

.WORD

000013.

CURRENT OPERATION COUNT <Transfer 13 words>

.WORD
.WORD

000000
100040

CHANNEL MODE REGISTER
CHANNEL MODE REGISTER
<No match conditions,
completion, transfer

HIGH
LOW
chain reload upon
type = Demand Dedicated

w/BuS Hold, CARA = source, word transfers>

LOAD4

.WORD
.WORD

000000
LOAD4

CHAIN ADDRESS REGISTER SEG/TAG
CHAIN ADDRESS REGISTER OFFSET
<This address points to the new chain table>

. WORD

001602

RELOAD WORD <Select CARA,CARB,COPC,CM>

.WORD
.WORD

101400
010000

.WORD
.WORD

000000
AREA3

CURRENT ADDRESS REGISTER B SEG/TAG
CURRENT ADDRESS REGISTER B OFFSET
<This local address is the destination of
transfer #4>

.WORD

000013.

CURRENT OPERATION COUNT <Transfer 13 words>

CURRENT ADDRESS REGISTER A SEG/TAG
; CURRENT ADDRESS REGISTER A OFFSET
<This global address is the source of sfer #4>
<610000(8»

151

u.NOTE '# 018
Page 22 of 24
CHANNEL MODE REGISTER HIGH
CHANNEL MODE REGISTER LOW
<No match conditions, do nothing upon
completion, transfer type - Demand Dedicated
w/Bus Hold, CARA - source, word transfers>

.WORD
.WORD

000000
000040

AREAl

.WORD

1,2,3,4,5,6,7,6,5,4,3,2,1

,PtoREA2

. BLKW

13 .

AREA3

.BLKW

13.

.END START

152

uNOTE # 018
Page 23 of 24
. TITLE

EXAM6. MAC

This program demonstrates how to initiate a DTC operation from the
; arbiter cpu. This program will tranfer a block of data from Q-bus
; memory to KXT11-C memory. All of the information necessary for the
transfer will reside in Q-bus memory (chain table, source data)
This program should be compiled, linked, and run on the arbiter
development system. After the program executes use the following
KUI commands to verify the transfer
.KUI
Where n is the appropriate KXT11-C
KUI>SET n
; KUI>ODT
Examine locations 5000 --> 5030 to verify that
ODT>5000/xxxxxx
,
the data was transfered correctly

ODT>5030/xxxxxx
ODT>"C
KUI>EXIT
Two-port RAM register definitions
TPRO-160100
TPRl-160102
TPR2-160104
TPR3-160106

START:

;

.MCALL

.EXIT

MOV

#100000,TPR3

place Chain Address Reg Seg/Tag in TPR3

MOV

#LOAD,TPR2

Place Chain Address Reg Offset in TPR2

NOTE!!

The KXT11-C User's Guide contains an error which instructs the
programmer to place the CA register Seg/Tag in TPR2 and the CA
register Offset in TPR3.
correct as stated above.
BIS

This information is reversed and is

#2,TPRO ; Issue DMA Load cmd to the command register

.EXIT
LOAD

. WORD

001602

RELOAD WORD <Select CARA,CARB,COPC,CM>

. WORD
.WORD

100000
SOURCE

CARA SEG/TAG <Select Q-bus address as source>
CARA OFFSET

. WORD
.WORD

000000
005000

;CARB SEG/TAG <Select KXT address 5000 as dest •
;CARB OFFSET

.WORD

000013.

; COPC <Op-count - 13 words>

15.3

uNOTE # 018
Page 24 of 24

SOURCE:

•

CM High
CM Low <select no termination options,
software hog-mode, CARA = source,
word transfers>

.WORD
.WORD

000000
000040

.WORD

1,2,3,4,5,6,7,6,5,4,3,2,1

.END

START

RELATED DOCUMENTS
For further information concerning the KXT11-CA and the DTC please
consult the following sources:
KXT11-CA Single-Board Computer User's Guide
AmZ8016 DMA Transfer Controller User's Guide

EK-KXTCA-UG-OOl
01924C

For further information concerning the KXTI1-CA Peripheral Processor
Software Toolkit please consult:
KXT11-C Peripheral Processor Software User's Guide
KXT11-CA Software Toolkit/RT Reference Manual
KXT11-CA Software Toolkit/RSX Reference Manual

154

AA-Y615A-TK
AA-AU63A-TC
AA-AU64A-TC

uNOTE # 019

Title: Disabling RAM on the MXV11-BF

Date: 10-JAN-85

Originator: Mike Collins

Page 1 of 3

This uNOTE describes how to disable the on-board memory of the MXV11-BF
multifunction module.
There is also a comparison of features between
the MXV11-BF (with RAM disabled) and the combination of the MRV11-D and
DLV11-J modules.
DISABLING RAM ON THE MXV11-BF MODULE

WARNING 1
The procedure outlined below for disabling the RAM
requires
physical
changes
to the circuit board.
Implementing this change will void the warranty of the
MXV11-BF as well as voiding any field service contract
for the board.
The procedure requires cutting one etch and adding one wire.
PROCEDURE (see figure below)
1. The etch cut can be achieved two ways.
Cut and bend up pin 13 of chip E17.
OR
On side 2 of module (the non-component side), cut etch
which connects E17 pin 13 to E26 pin 2.
2. Add wire between E17 pin 13 and E17 pin 14 (+5 volts).
3. The on-board RAM is now disabled.

155

uNOTE # 019
Pag1e 2 of 3
MXV11-BF (M7195)

Pin 1
Pin 14

v V
Pin 1
E26

-: DO 0
I

E17

COMPARISON OF THE MXV11-BF VERSUS THE COMBINATION OF MRV11-D AND DLV11-J
The following table lists several features common to both the
with the RAM disabled and the MRV11-D / DLV11-J combination.

MXVI1-BF

FEATURE

MXV11-BF w/o RAM

MRV11-D and DLV11-J

RAM

None

Boot ROMs

Mxvl1-B2

MXV11-B2

SlGU's

2 DLARTs
4 UARTs
4 baud rates
9 baud rates
No format options
Many format options
(Start, stop bits, parity, # of bits, etc.)

Miscellaneous
features

4 Red LED's
1 Green LED

14 unused ROM/RAM sockets

Cabinet kit

Ctrrrently N/A

Available

+S V

3.4A

2.6A

Heat diss.

16.65W

16W

156

uNOTE # 019
Page 3 of 3
FEATURE

MXV11-BF w/o RAM

MRV11-D and DLV11-J

Slots

1 dual

2 duals

AC loads

2.3

4.0

DC loads

0.5

1.5

+12 V

0.1A

0.25A

When comparing the features on page 2, the MRV11-D/DLV11-J combination
works out better than the MXV11-BF. All of the features on page 3 show
the advantages of the Mxv11-BF.
The MXVI1-BF is the best choice in situations where backplane space and
loading is a primary concern.
In terms of backplane space, if the
number of slots available is limited, the MXV11-BF is preferable since
it takes up one dual slot whereas the MRV11-D/DLV11-J combination
requires two dual slots.
In a large system where AC loading may be a concern, the MXV11-BF also
has an advantage over the MRV11-D/DLV11-J combination. The number of AC
loads the MXV11-BF presents to the bus is fewer than the two board
combination.
The most attractive use for the MxV11-BF is in a minimal yet powerful
two-board system i.e. KDJ11-A and the MXV11-BF. The advantages of such
a system are the size or form factor (only two dual height modules)
128Kb of RAM, 2 serial lines, bootstrap capability and the high
performance 11/73 CPU.

157

158

uNOTE # 020

Title: Differences between the MXV11-A and Mxv11-B

Date: 10-JAN-85

Originator: Dave Smith

Page 1 of 2

This MicroNote illustrates the features to consider when upgrading from
MXV11-AA/-AC to MXV11-BF multifunction boards or when choosing one in a
new configuration.

Mxv11-A

MXV11-BF

o Dual height form factor

o 18-bit compatible only

o 18 or 22-bit compatible

o 2 SLU's (DLV11-J type)

o 2 SLU's (DLARTs)

o RAM:
8 KB non-parity (MXV11-AA)
32 KB non-parity (MXV11-AC)

o RAM:

o ROM: 2 sockets (24-pin)
(for MXv11-A2 boot ROMS
- cannot use MXV11-B2 ROMS)

o ROM: 2 sockets (28-pin)
(for MXV11-B2 boot ROMS
- cannot use MXV11-A2 ROMS)

128 KB non-parity

Notes:
The MXV11-B2 Boot ROMs are required for an LSI-11/73 based system to be
maintained under a DEC Field ServicE~ contract because these ROMs contain
cache diagnostics.
For a comprehensive list of Bootstraps and device
MicroNote #15, entitled "Q-bus Hardware Bootstraps"

159

support,

refer

uNOTE
020
Page 2 of 2
Since the ROM sockets on these boards may be used for user-written
application code as well as boot code, it is important to note what is
different on the two boards. Besides the sockets being of different
size, the ROM on the two boards has another difference. The ROM on the
MXV11-BF is window mapped and may be used under application control to
address up to 8 KB.
The MXV11-A ROM is direct mapped and can only
address 256 bytes. Thus, an upgrade would require new ROMs and possible
application recoding.
For more detailed
MicroNote 19.

information

concerning

MXV11-BF

issues,

For more detailed informabion concerning MXV11-A issues,
archived MicroNotes listed in appendix A.

refer

the

Summary:
When upgrading from the MXV11-A to the MXV11-BF or choosing the MXV11-BF
over the MXV11-A, three important features are obtained:
1) 22-bit compatibility - allows use in large memory systems
(The MXV11-BF memory can only be configured to start in the
lower 512 KB. It does, however, decode all 22 lines of
address which makes it usable in" systems with up to 4 MB.)
2) More memory (although its non-parity feature creates some software
support issues if used with RSX or RSTS)
3) Support for boot ROMs that will boot MSCP devices such as the Rx50
and Ro51 and will provide cache diagnostics for the LSI-11/73.

160

uNOTE # 021

Title: Floating Point Considerations on MicroVAX I

Date: 10-Jan-85

Originator: Christopher DeMers

page 1 of 2

The MicroVAX architecture implements a subset of VAX data types.
Four
that are part of the VAX architecture but not part of the MicroVAX
architecture are the D floating, F floating, G floating and H floating
data types.
Floating point instructions that use these data types are
likewise not part of the architecture.
The MicroVAX I system implements a proper superset of the MicroVAX
architecture;
that is, MicroVAX I uses the MicroVAX architecture, but
implements a few items that are not defined as part of the MicroVAX
architecture.
Even though the architecture specifies emulation support
for floating point,
the following data types and instructions are
supported in the MicroVAX I microcode:
- F float
- D-float
- G-float
The F float data type and instructions are standard on the MicroVAX I.
In aQdition,
the user may specify EITHER D float or G float as the
double precision instruction set.
The decision to use D float or
G_float depends on the application.
Both D float and G float are double preclslon floating point data
types/lnstructions.- D float is compatible with the PDP-11 format and is
the double precision floating point default for many of Digital's
compilers including FORTRAN, PLII, BASIC and Pascal.
Therefore, if the
application has been compiled, say, on a VAX-11/780, with the default
(D float)
and is not to be re-compiled before being run on the MicroVAX
I,-then choose the D float option.
The compilers mentioned above have a
switch that allows the generation of G float instructions.
If you wish
to choose the G float option for your MlcroVAX I, the program needs to
be re-compiled with the G float switch set.
If Macro programs use a specific data type such as G float,
then the
MicroVAX I will need to have the G float option unless the program is
modified so that the floating point instructions match the option chosen
for the MicroVAX I.

161

uNo'rE
021
Page 2 of 2
Note that even though a program uses one type of double preclslon
floc!ting point and the MicroVAX I has the other as an option, the
program will run. A feature of the MicroVAX architecture is that all
instructions are executed. The floating point instructions not chosen
as a microcode option are emulated in software.
An instruction/data
type mismatch could result in severe performance degradation.
Another reason for choosing one double precision format over another is
the size and accuracy of the data. Both formats are 64 bits long. The
D float range is 2.9E-37 to 1.7E38.
This type gives approximately
sIxteen decimal digits precision. G float "steals" three bits from the
fraction to give the exponent a large~ range.
The G float range is
.S6E-308 to .9E308 and gives approximately fifteen decimal digits
preclslon. The range of the number is increased significantly while
only reducing the precision by one decimal digit.
H float, the only other floating data type in the VAX

architecture, is
bits long with a range of close to 10ESOOO and a precision of
thirty-three decimal digits. H'float is not implemented as part of the
MicroVAX architecture. It is, nowever, emulated in software.
1~8

Data Type Representations

7 6

sl Exponent I Fraction
Fraction
31

D Floating

sl Exponent

7 6

4 3

sJ Exponent I Fraction

Fraction

Fraction -

Fraction

Fraction
48

162

uNOTE it 022

Title: Differences between the z.1licroVAX I and the
MicroVAX II CPUs

Date: 28-APR-85

Originator: Mike Collins

Page 1 of 13

This MicroNote identifies the differences between the MicroVAX I
processor and the MicroVAX II processor. The term 'MicroVAX 630' is
sometimes used in this and other documentation when referring to the CPU
module of the MicroVAX II system. Table 1 below contains a summary of
these differences and following the table are detailed discussions of
each.
Table 1 - MicroVAX II versus the z.1licroVAX I
FEATURE

MicroVAX II

MicroVAX I

CPU Technology

MicroVAX 78032

Custom VLSI

Memory System

Local Memory
System

Uses Q-bus Memory

Floating Point

MicroVAX 78132

Microcode

Q-bus I/O Map

YES

Addressable Physical Memory

16 MBytes

4 MBytes

On-Board Memory

256KB or 1MB

Non~

Performance

See Performance Section

Console Serial Line

YES

Boot & Diagnostic ROMs

YES

Form Factor

1 Quad

2 Quads

Configuration set via

Cabinet Kit

Cabinet Kit &
On-board Switches

RQDX Contro!ler Type

RQDX2

RQDX1 or RQDX2

163

uNOTE # 022
page 2 of 13
Table 1 - MicroVAX II versus the MicroVAX I (cont'd)
TOY Clock wi Battery Backup

YES

Multicomputing Hooks

YES

Instruction Set Differences
Power Requirements

See MicroNote #24
+SV - 6.2 Amps
+12V - 0.14 Amps

+SV - 14 Amps
+12V - 0.5 Amps

AC Loads

2.7

DC Loads

240 Ohms

Termination

The MicroVAX II is both faster and smaller than the MicroVAX I.
Two
major
features
of
the
MicroVAX II are responsible :for these
enhancements: the MicroVAX 78032 microprocessor and the memory system.
CPU TECHNOLOGY
The technologies used to design the two processors are different.
This
is why the MicroVAX II CPU is half the size and three times the speed of
the MicroVAX I.
The MicroVAX I CPU was designed using a custom VLSI chip, several ROMs
and off-the-shelf parts to implement the ALU, memory management unit and
the microcode. In contrast, these same features are implemented in the
MicroVAX 78032 microprocessor. The MicroVAX 78032 is the first VAX on a
chip. Two custom gate arrays were also designed to reduce the size of
the MicroVAX II CPU to one quad module: the Q-bus interface gate array
and the MicroVAX 78032 interface gate array.
MEMORY SYSTEM
The significant difference in performance is due in part to the
different memory systems used by the two processors. The MicroVAX II
memory system uses a high speed interconnect between the MicroVAX 78032
microprocessor and RAM.
The MicroVAX I uses standard Q-bus memories
which are not as-fast but are also less expensive and usable by both the
MicroVAX I and other 16-bit processors (such as the MicroPDP-11). The
MicroVAX I also uses a cache memory scheme.

164

uNOTE # 022
Page 3 of 13

The MicroVAX II CPU communicate!s to memory over a local memory
interconnect.
This was done to increase the performance of the system
in two ways. First, the local memory system provides a fast connection
between the processor and memory (400 nsec read and write cycles).
Second, since memory fetches occur over the local memory system, the
Q-bus is now a dedicated I/O bus. The diagrams below contrast previous
Q-bus processors and the MicroVAX II.
The local memory system allows for 2 expansion memory boards.
section on Addressable Physical Memory)

(See next

Configuration Used by Previous ~-bus Processors:
This approach is used by most Q-bus processors such as the 11/23,
LSI-ll/73 and the MicroVAX I. In this design, the Q-bus bandwidth is
shared by th~ processor and I/d devices when accessing memory.

Processor

.MeDlory

I/O
Device

Q--bus
Figure 1 - Memory Design Used by Previous Q-bus Processors
MicroVAX II Design:
The MicroVAX II uses a local memory system for all memory references,
allowing the Q-bus to be a dedicated I/O bus. The local memory system
is implemented using the C-D intE!rconnect of the backplane and an
over-the-top cable. The memory system has a bandwidth of 10 MBytes/sec
which will support the MicroVAX 78032 microprocessor running at full
speed (approx.
6 MB/sec) with simultaneous Q-bus DMA transfers (3.3
MB/sec) .

165

uNOTE: # 022
Page 4 of 13
10 MBytes/sec

I
Processor
6 MB/sec

Ca bl e
over- th e-.op
T

C-D Interconnect in Backplane

Expansion
Memory
(max. of

I/O
Device

Q-bus (3.3 MBytes/sec)
Q-bus is a dedicated I/O bus
Figure 2 - MicroVAX II Memory Design
FLOATING POINT
The MicroVAX architecture specifies that the floating point instruction
set need not be implemented in the hardware of a MicroVAX processor.
For those processors that fall into this category, there is an emulator
in the software which guarantees that the instructions are still
executable. However the MicroVAX architecture does not restrict a
MicroVAX design from having floating point instructions implemented in
hardware.
This is what was done on the MicroVAX I. The MicroVAX I does have the
F floating and D floating or the F floating and G floating instructions
i~ microcode.
(s~e MicroNote
#21 -"Floating Poi~t Considerations on
MicroVAX Itt)
Th,e Mi c r 0 VAX I Ius e s the Mi c r oVAX 78132 flo at i n g poi n t un i t t 0 i mpl eme n t
floating point instructions. It is a high performance coprocessor for
the MicroVAX 78032 and eliminates the need to emulate floating-point
instructions in software.
Thle MicroVAX 78132 handles the F floating (single precision), D floating
(double-precision) and the G floating (extended range double-precision)
floating point data types and-instructions. The FPU also accelerates
the execution of integer multiply and divide operations.
The H floating instructions are emulated in both the MicroVAX :r and
MicroVAX II.

166

the

uNOTE i 022
Page 5 of 13
Q-bus I/O MAP (SCATTER/GATHER MAP)
The concept of a scatter/gather map has been used on the large UNIBUS
VAXes since the VAX 11/780. ThE~ same concept is used on the MicroVAX
II.
Simply stated, the scatter/ga1:her mechanism maps addresses from one
bus to another bus.
This mapping is necessary because the address
length is not the same for the two buses.
The term 'scatter/gather'
is a description of what operations are
performed through the scatter/gathE~r map. A VAX with mapping enabled is
a virtual machine and manages data in 512-byte pages which may be
discontiguous in physical memor~r. When a DMA write operation occurs,
pages of data may be 'scattered' into physical memory.
During a DMA
read operation from memory to an I/O device, such as a disk, -these pages
of data must be 'gathered' from thl:oughout memory and transferred to the
device.
The MicroVAX I does not requi re a ()-bus I/O map.
Since all I/O devices
and memory share the same bus,
the Q-bus, there is no mismatch in
address lengths and no I/O map is necessary. Reading and writing data
to and from memory in 512 byte pages becomes the responsibility of the
I/O device or the system software.
In the case of the MicroVAX II CPU" the scatter/gather map provides the
mapping mechanism to allow DMA devices on the Q-bus, with a 4 MByte
physical address range, to gain access to all of main memory on the
local memory system, a 16 MByte physical address range.
Figure 3 below illustrates the mapping process.
The high order 13 bits of the Q-bulS address select one of 8192 mapping
registers.
Each register translatf!s an address for a range covering one
page of 512 bytes; thus the mappin<} registers cover the entire Q-bus
address space of 4MB.
The lower 15 bits of the mapping r~gister will have been previously
loaded with the correct information, which when appended to the lower 9
bits of the Q-bus address selects the appropriate byte in main memory.
The high order 15 bits of the physical address select which pag~ in main
memory has the correct address and the low order 9 bits select the byte
within a page.

167

uNOTE # 022

Page 6 of 13
9 8

Q-bus Address

13 bits

Q-bus I/O Map
8K Mapping Registers

~----------------------->

Selected Mapping Register
31

15 14

15 bits

I <------------~
Local Memory

Physical Addr.
in local
memory

24 bits

~------------------->

Figure 3 - Q-bus to Private Memory Mapping Process

168

uNOTE
022
Page 7 of 13
ADDRESSABLE PHYSICAL MEMORY
The total amount of addressable physical memory
different because of the memory system designs.

for

each

CPU

The MicroVAX I uses standard Q-bus memories for main memory and
therefore has a lower physical addressing limit than the MicroVAX II.
This limit is constrained by the number of address lines on the Q-bus.
There are 22 address lines on the Q-bus, limiting maximum memory to 4
MB.
The MicroVAX II uses a 24 bit address when accessing the local memory
system.
Therefore the maximum amount of addressable memory is 16
MBytes.
When the system is first available, 9 Mbytes will be the maximum because
the 16 MByte total depends on the availability of 1 Mbit RAM parts. The
9 MByte total includes a MicroVAX II CPU (KA630-AA) which includes 1
MByte on-board plus two 4 MByte expansion modules.
The memory module capacities are listed in the table 3 below.
Table 3 - Expansion Memory Options
MEMORY

MEMORY SIZE

FORM FACTOR

MS630-AA

1 Mbyte

Dual

MS630-BA

2 Mbytes

Quad

MS630-BB

4 Mbytes

Quad

PERFORMANCE
The relative performance between thl~ processors is of course application
dependent.
However, as a generi~l rule of thumb, the MicroVAX II CPU
will be approximately 3 times faster than the MicroVAX I.
The results
of standard, compute bound floating point benchmarks indicate that the
MicroVAX II (with the MicroVAX 78132 FPU) will run 4 to 6.6 times faster
than the MicroVAX I.
CONSOLE SERIAL LINE
The MicroVAX II and the MicroVAX I processors both have one dedicated
serial line for the console terminal. There are two differences between
the two serial line units. First, the number of selectable baud rates
is different. The possible baud rates are listed in table 4.

169

uNOTE # 022
Page 8 of 13
Table 4 - Baud Rate Selections
M:icroVAX II

MicroVAX I

300
600
1200
2400
4800
9600
19200
38400

300
1200
9600
19200

Second, the console device connector on the patch panel for the MicroVAX
I is an RS232 25-pin D-subminiature connector~ The connector on the
lVIicroVAX II patch panel is a 9-pin D-subminiature connector.
Because
the connectors are different, different cables will be used to connect
to the console terminal.
FORM FACTOR
All of the features and functions of the MicroVAX II processor are
contained on one quad module. The MicroVAX I processor is made up of
two quad modules, a data path module ('DAP'), and a memory controller
('MeT').
The two modules of the MicroVAX I communicate over the C-D
backplane interconnect and an over-the-top ribbon cable.
BOOT AND DIAGNOSTIC ROMs
Both processors have boot/diagnostic ROMs. The ROMs on the MicroVAX I
are NOT the same as those on the MicroVAX II CPU, therefore there are
differences in their operation.
Both ROMs perform the following functions :
Initialize the machine into a known state.
Perform diagnostic tests.
Allow for the automatic restart or bootstrap of the system following
a processor halt or initial power-up.
Provide bootstrap capability from a variety of devices.
Provide the VAX console command language.
Perform diagnostic tests.
When either machine is powered on, their respective diagnostic tests are
executed.
Microverify is the name given to the diagnostics executed by the
MicroVAX I system. There are three LEDs on the DAP module and a seven
segment display on the patch panel which will isolate the problem to one
of the two CPU modules. Error codes are defined in table 10-1 on page
10-4 of the MicroVAX I Owner's Manual.

170

uNOTE # 022
Page 9 of 13
A similar function is performed by the MicroVAX I I CPU diagnostics.
As
each test is run, a code is displayed on the processor LEDs, the patch
panel and the console terminal. Th1ese codes count down in hexadecimal
from F to O.
There are potentially 16 steps which may be executed,
therefore the MicroVAX 630 has 4 LEDs. The definitions for these codes
may be found in the MicroVAX 630 CPU Module User's Guide
(PIN
CK-KA6 30-UG) .
Power-up modes.
A major difference between the two processors is what occurs at
power-up. The MicroVAX I will ei th,er attempt to do a restart, bootstrap
or halt and enter console mode (the appropriate option is selected via
two switches on the DAP module).
The MicroVAX I I can also be configured to try a restart,
perform a
bootstrap or halt. Before it attempts these options however, it does a
language inquiry. All console messages may be output in one of eleven
different languages; one must be selected. There are options such as
defaulting to English or defaulting to the language which was selected
previously for unassisted bootstrap or always prompting for the language
at power-up. These options are described in the MicroVAX 630 CPU Module
User's Guide.
Bootstrap Devices.
The list of devices which each processor can boot from is slightly
different.
Table 5 lists the supported boot devices for each processor.
The devices are listed in the order by which they are searched by the
processor~

Table 5 - Bootstrap Devices
MicroVAX I I

MicroVAX I

RODX, KDA50 or
RC25

RQDX

TKSO
MRV11-D

MRV11-D

DEONA

VAX Console Command Language.
Both processors implement the VAX console command language in their boot
ROMs.
Most of the frequently used commands are implemented by both
machines.
However, there are a few commands which are only implemented
by one or the other. Table 6 lists the commands and indicates which are
available on each processor.

171

uNOTE # 022
Page 10 of 13
Table 6 - VAX Console Commands
COMMAND
BREAK
INITIALIZE
START
CONTINUE
HALT
BOOT
UN JAM
EXAMINE
DEPOSIT
X

FIND
REPEAT
TEST
1 (Comment)
N (Next)
CTRL/U
CTRL/S
CTRL/O
CTRL/O
CTRL/R
CTRL/C

MicroVAX II

MicroVAX I
X
X
X

X
X
X
X
X
X
X
X
X
X
X
X
X
X

X
X
X
X
X
X

X
X

X
X
X
X
X
X

CONFIGURATION
Both CPUs have a cabinet kit through which certain features are
configured.
However the cabinet kits are different. The cabinet kit
for the MicroVAX I will not work with the MicroVAX II CPU and vice
versa.
In addition to the cabinet kit are eight switches on one of the MicroVAX
I CPU boards used for setting such functions as the recovery action,
break detect enable and the baud rate selection. The cabinet kit for
the MicroVAX I is a set of two cables and a patch panel insert for FCC
system integration.
It performs three functions:
1. Console terminal connector
2. Baud rate rotary switch
3. Two digit LED display

172

uNOTE # 022
Page 11 of 13
The MicroVAX II CPU has no switches or jumpers on the module itself.
All options are set via the patch panel insert of the cabinet kit or an
optional configuration card used in place of the cabinet kit. The patch
panel insert has the following functions
1.
2.
3.
4.
5.
6.

Halt enable switch
Power-Up mode rotary switch
Baud rate rotary switch
Hexadecimal display
Console terminal connector
Batteries for battery backup

For MicroVAX II applications which do not need the cabinet kit, Digital
designed a special configuration card. This card allows the user to
configure the same functions as the cabinet kit but it is much smaller
and requires no cables. The configuration card is 1.5" x 2.5" and plugs
into two connectors on the CPU module. Simple DIP switches are used to
select the appropriate functions.
TIME-OF-YEAR CLOCK WITH BATTERY BACKUP
The MicroVAX I does not have the capability for keeping time after a
system power-down or power fai.lure. Each time the system is brought
back up the time must be reentered manually (This limitation can be
bypassed under MicroVMS for example, but the system time will be
incorrect until set at a later time).
The MicroVAX II has the capabili t~r for a battery backed up time-of-year
(TOY) clock.
A low-power TOY clock chip was designed onto the CPU
module. After a system power-down the chip keeps track of the correct
time and the system can reboot without needing an operator to enter the
time and date.
During normal operation the system keeps track of time using a 10 msec
interval timer internal to the MicroVAX 78032. When power is lost this
interval timer will stop but the TOY clock chip will continue to
operate. The TOY clock chip has a resolution of 1 second.
The batteries for the time-of-year clock chip are located on
panel insert of the cabinet kit.

the

patch

The battery backup capability is not present if a system is using the
configuration card instead of thE~ cabinet kit in order to configure the
system. However there are pins on the configuration card which can be
used to connect external batteries to provide the same capability. It
is the user's-responsibility to pl:ovide the batteries and cabling for
battery backup when using the configuration card.

173

uNOTE # 022
Page 12 of 13
RQDX CONTROLLER TYPE
Initial MicroVAX I systems use the RQDXl disk controller for
the RX50
floppy disks and the RD51 / RD52 winchester disks.
This controller is
required to be the last module in a system because it does not pass
interrupt acknowledge (lACK) nor the DMA grant (BDMG) signals to options
which come after it in the backplane.
The RQDX2 disk controller was designed to work with and is shipped with
initial MicroVAX II systems.
The RQDX2 will also work with other Q-bus
processors such as the MicroVAX I and MicroPDP-ll/73.
IMPORTANT!
The RQDXl is incompatible with the MicroVAX II CPU therefore
the two should never be configured into the same system.
MULTICOMPUTING HOOKS
The MicroVAX II CPU has been designed to allow a maximum of four
processors to coexist in the same system.
There will always be an
arbiter and up to 3 auxiliaries.
This feature is NOT supported by any
Digital operating system and is not an off-the-shelf multiprocessing
solution.
For more information on the specifics of the multicomputing
feature,
reference MicroNote #26 and the MicroVAX 630 CPU Module User's
Guide.
INSTRUCTION SET DIFFERENCES
The MicroVAX architecture specifies which
instructions
must
be
implemented in the hardware/microcode, all other instructions will then
be emulated in software.
Depending on the particular instruction,
the
emulation is either entirely in software or in software with a hardware
assist. Any specific MicroVAX implementation will meet this minimum
requirement but may choose to include in its microcode some instructions
which would otherwise be emulated. MicroNote #24 contains a table which
lists all of the instructions in the VAX architecture and indicates for
each MicroVAX processor whether or not the instruction is in the
hardware or emulated.
POWER REQUIREMENTS, AC LOADS, DC LOADS AND TERMINATION
Table 7 below summarizes the pertinent information
configure one of these processors into a system.

necessary

Since the MicroV~X II CPU is only one quad module it is not
that
the
amount of current drawn from the +5 volt
substantially less than that required by the MicroVAX I CPU.

174

surprising
supply is

uNOTE # 022
page 13 of 13
Table 7 - Specifications
SPECIFICATION

MicroVJ~X

MicroVAX I

Power Requirements
+5 volt (amps)
+12 Volt (amps)

6.2
0.14

14.0
0.5

AC loads

2 • ~/I

DC loads

1.0

Termination (ohms)

240

17!5

176

uNOTE # 023

Title: MicroVAX I to MicroVAX II Upgrade Issues

Date: 28-APR-85

Originator: Mike Collins

Page 1 of 5

This MicroNote describes the
MicroVAX I to a MicroVAX II.

hardware

issues

upgrading

from

The Add-On and Upgrades group within Digital Equipment Corporation
announced a formal upgrade kit at the time of the MicroVAX II
announcement. For more information about this program contact a local
DEC sales representative.
This f1icroNote is intended for those users
who wish understand the issues in an upgrade.
Reference MicroNote #22 for a detailed description of the differences
between the processors of the MicroVAX I and MicroVAX II systems.
Upgrading a MicroVAX I to a MicroVAX II is straightforward because the
two systems share many common components.
First of all the BA23
enclosure is used by both systems, this includes the backplane, power
supply, control panel, and I/O patch panel. The 5 1/4" disk devices
used on a MicroVAX I are also compatible with the MicroVAX II.
Since
I/O devices for both machines are Q-bus devices they are directly
compatible with the new processor. The upgrade process does however
involve replacing the processor, the memory, the 5 1/4" disk controller
and the processor cabinet kit.
Each of these upgrade issues is
addressed in detail.
An upgrade example is shown at the end of this MicroNote.
THE PROCESSOR UPGRADE:
The MicroVAX I CPU is made up of tW() quad modules, the memory controller
('MCT') and the data path ('DAP'). These two modules occupy slots 1 and
2 in the backplane. Both of these modules are replaced with a single
quad module, the MicroVAX II CPU which must be placed in slot 1. The
MicroVAX II CPU module includes 1 MB of memory and the MicroVAX 78132
floating point unit.
Slot 2 previously used by the MicroVAX I is now
available for expansion memory or other options.
THE MEMORY UPGRADE:
The memory system designed for tht~ MicroVAX I l i s unique to that
processor, therefore the Q-bus memories used in the MicroVAX I must be
removed and replaced by the new type.

177

uNOTE # 023
Page 2 of 5
If the MicroVAX I being upgraded has only 1 MB of main memory then the
processor and memory can both be replaced with the MicroVAX II CPU
module. Additional memory may be added to a MicroVAX II CPU if
necessary.
Besides the 1 MB of on-board memory, the MicroVAX II CPU
will support a maximum of 2 memory expansion boards.
These additional
boards must be placed immediately after the processor in slots 2 and 3
of the backplane. The memory modules communicate with the CPU over the
C-D interconnect of the backplane and an over-the-top cable. A cable is
shipped with each memory module.
Figure 1 is an example of how the processor and memory boards are
configured into a system. If the dual height memory expansion module is
used (MS630-AA) it must be placed in the C-D side of the backplane. The
memory modules may be placed in any order in slots 2 and 3~ Table 2
lists the memory expansion options.
WARNING
Both the MicroVAX II CPU and MS630 memory expansion
modules must be placed in backplane slots with the C-D
interconnect. Damage may result if these modules are
placed in backplanes with Q-bus signals on both the A/B
and C/o sides.
Table 2 - MS630 Memory Expansion Modules
MEMORY

MEMORY SIZE

FORM FACTOR

MS630-AA

1 Mbyte

Dual

MS630-BA

2 Mbytes

Quad

MS630-BB

4 Mbytes

Quad

Figure 1 - Processor and Memory Configuration
1

I MicroVAX II CPU

I MS630-B

I
<

MS63'0-AA-->

.
8

Additional slots

178

Memory Expansion
Cable

uNOTE # 023
page 3 of S
i

THE RQDX DI SK CONTROLLER UPGRADE:
The RQDX1 S 1/4" disk controller used in MicroVAX I
systems must be
removed and replaced with the HQDX2 controller.
This upgrade is
necessary because the RQDX2 provide:; features not available on the RQDX!
and because the RQDX1 is incompatible with the MicroVAX II.
The RQDX1 does not pass the interrupt acknowledge (lACK) or DMA grant
signal
(DMGO)
to other modules which may be located after it in the
backplane. Therefore it must always be the last module in a system.
This restriction has been removed with the RQDX2, which does pass both
of those signals.
Both RQDX modules are capable of controlling 4 logical units.
However
the RQDX1 can only control a maximum of 2 fixed winchesters (RDSn type
drives). Therefore the largest amount of storage that can be connected
to an RQDX1 would be a combination of 2 RDSn type drives and an RXSO,
which counts as two logical units bf!cause it actually handles two 400KB
floppies.
The RQDX2 also control:; 4 logical units but it knows how to
control any combination of RDs and HXSOs. Therefore the maximum amount
of storage that can be connected to an RQDX2 would be four RDSn type
drives.
The RQDX1 is compatible with RXSO floppies (SOOKB), RDS1 (11MB) and RDS2
(31MB) disk drives.
The RQDX2 is compatible with those drives but is
also capable of controlling RDS3 (71MB) drives.
THE CABINET KIT UPGRADE:
The MicroVAX I cabinet kit is incompatible with the MicroVAX II,
therefore the cabinet kit used in the MicroVAX II, BA23 based system
must be used. The part number is CK-KA630-AB.
Both cabinet kits have one serial line connector in order to communicate
with the VAX console device.
'rhe MicroVAX I cabinet kit uses the
standard 2S-pin, D-subminiature lRS232 connector~
The MicroVAX II
cabinet kit uses a different type of connector.
It is a 9-pin
D-subminiature connector and will therefore require a different cable
from the patch panel to the consl)le device. The appropriate cable is
part number BCCOS.
OPERATING SYSTEM UPGRADE:
Once the hardware has been upgraded it is also necessary to have the
appropriate system software which will support the MicroVAX II.
Table 3
lists the initial versions of MicroVMS, ULTRIX-32m and VAXELN which
support the MicroVAX II.

179

uNOTE # 023
Page 4 of 5
Table 3 - System Software Support
System Software

Version with MicroVAX II Support
V4.1m or later
V1.1 or later
V2.0 or later

MicroVMS
ULTRIX-32m
VAXELN

Many software layered products support the MicroVAX II.
Consult the
appropriate Software Product Description (SPD) to verify if the current
version of the layered product is supported.
UPGRADE EXAMPLE:
Th~! following example illustrates the
changes made to a MicroVAX I
~ystem
to upgrade it to a MicroVAX II system. The diagrams represent
the modules placed in the BA23 backplane.
Both systems have a CPU, 2MB of memory, a DHV11 8-line asynchronous
multiplexer, a DEQNA Ethernet controller and an RQDX 5 1/4" disk
controller.
MicroVAX I System

MicroVAX II System

KD32 CPU - MCT

KD32 CPU - DAP

KA630-AA
DEQNA

I MS630-AA

MSV11-QA (1MB)

RQDX2

MSV11-QA (1MB)

DHV11

6
7

DEQNA

I G7272

RQDX1

Comments:
The 2 modules of the MicroVAX I CPU and the two quad memory
(MSV11-QAS) were-replaced by the KA630-AA and one MS630-AA.

boards

Th.! DHV11 and DEQNA are compatible with both processors, therefore
were not replaced and remained in the system.

they

180

uNOTE
023
Page S of S
The ROOX1 controller is incompatible with the MicroVAX II, therefore it
is replaced with the ROOX2. Any S 1/4" disk (RXSO, ROS1 and ROS2) used
on the MicroVAX I is compatible with the ROOX2 on the MicroVAX II.
The ROOX1 controller must occupy the last slot in a system.
The ROOX2
controller is located before the OHV11 in the upgraded system to
emphasize the point that it is not, required to be the last module in the
system.
The MicroVAX I system required a G7272 grant continuity card in slot 6
in order to make the system work properly. This was not necessary in
the upgraded MicroVAX I I system be'cause there was an empty dual-height
slot next to the MS630-AA memc1ry module. This illustrates the point
that the dual height slot next to an MS630-AA is a valid O-bus slot and
can be occupied by any compatible, dual-height option.
The cabinet kits for the two systems are not shown in the diagrams, but
the one used for the MicroVAX I rnust be replaced by the cabinet ki t for
the MicroVAX II, part number CK-K~.630-AB. The serial line cable from
the patch panel to the terminal must also change. The cable of the
MicroVAX I system must be replaced by a BCC08 cable.

181

182

uNOTE # 024

Title: MicroVAX Instruction set Differences

Date: 28-APR-85

Originator: Mike Collins

Page 1 of 11

The MicroVAX architecture specifies that the full VAX instruction set
need not be implemented in the hardware of a MicroVAX processor. For
those processors that fall into this category, there is a software
emulator which guarantees that the instructions are still executable.
This MicroNote lists all of the instructions of the VAX architecture and
for each MicroVAX processor indicates which instructions are implemented
in hardware/microcode, those that are emulated and those that are
present in a floating point unit.
The instructions are listed in alphabetical order by instruction
mnemonic.
The following designations are used to indicate where an
instruction will be executed.
CPU

Instructions marked with 'CPU' are implemented in the hardware of
the particular MicroVAX processor.

EMA

- Instructions marked with 'EMA' are emulated with microcode assist.

- Instructions marked with an 'E' are emulated entirely in software.

Processor specific designations:
MicroVAX II
FPU
- Instructions marked with 'FPU' are implemented in the hardware
only if an external floating point unit is present, otherwise they
are emulated.
MicroVAX I
Hx
- Instructions marked with 'H', 'HF', 'HD' or 'HG' are implemented
in hardware even though the MicroVAX architecture specifies that
these instructions are emulated.
There are two versions of the MicroVAX I, one with F
and
and the pther with F and G floating instructi~ns in
mIcrocode. There are no MicroVAX I processors with all 3 of
these floating point instruction types in the hardware. The
F floating instructions are identified by 'HF', the D floating
by 'Ha' and the G_floating by 'HG'.
-

o floating

183

uNOTE # 024
Page 2 of 11
Reference MicroNote
Mi era VAX I'.

#21,

'Floating

Point

Considerations

The following table lists statistics about the
distribution
instructions
based
on where they are executed.
There are
instructions in the VAX instruction set.

of
304

Table 1 - MicroVAX Instruction Distribution
Description

MicroVAX
Architecture

MicroVAX I

MicroVA:K II

Percentage executed
in CPU

57.6

74.3

57.6

Percentage executed
in FPU

N/A

23.0

Percentage emulated
'wi th microcode assist

8.9

7.3

8.9

Percentage emulated
entirely in software

33.5

18.4

10.5

'rable 2 - Instruction Set Differences
Mnemonic
ACB:B
ACBD
ACBF
ACBG
ACBH
ACB:L
ACBW
ADAWI
ADDB2
ADDB3

Description
Add compare
Add compare
D floating
ACId compare
F floating
ACId compare
G floating
ACId compare
H_floating

MicroVAX
Architecture

MicroVAXI Mi c roVAXI 1-

and branch byte
and branch

CPU
E

CPU
HD

CPU
FPU

and branch

FPU

and branch

FPU

and branch

CPU

CPU
CPU
CPU
CPU

Add compare and branch
longword
Add compare and branch word
Add aligned word interlocked
Add byte 2-operand
Add byte 3-operand

184

uNOTE # 024
Page 3 of 11
Mnemonic

Description

MicroVAX
Architecture

ADDD2
ADDD3
ADDF2
ADDF3
ADDG2

Add
Add
Add
Add
Add

D floating
D-floating
F-floating
F-floating
G=floating

2-operand
3 operand
2-operand
3-operand
2=operand

E
E
E
E
E

ADDG3
ADDH2
ADDH3
ADDL2
ADDL3

Add
Add
Add
Add
Add

G floating 3 operand
H=floating 2-operand
H floating 3=operand
l~ngword 2-operand
longword 3-operand

E
E

ADDP4
ADDP6
ADDW2
ADDW3
ADWC

Add
Add
Add
Add
Add

packed 4-operand
packed 6-operand
word 2-operand
word 3-operand
with carry

AOBLEQ

Add one and branch on
less or equal
Add one and branch on less
Arithmetic shift longword
Arithmetic shift and
round packed
Arithmetic shift quad

AOBLSS
ASHL
ASHP
ASHQ
BBC
BBCC
BaCCI

Bacs
BBS
BBSC
BBSS
BBSSI

Bec
BCS

Branch on bit
Branch on bit
Branch on bit
interlocked
Branch on bit
Branch on bit

MicroVAXI MicroVAXII
HD
HD
HF
HF
HG

FPU
FPU
FPU
FPU
FPU

FPU

E
E

CPU
CPU

E
E

CPU
CPU
CPU

EMA
EMA
CPU
CPU
CPU

CPU

CPU
CPU
E

CPU
CPU
EMA

CPU

clear
clear and clear
clear and clear

CPU
CPU
CPU

cl~ar

CPU
CPU

CPU

CPU
CPU

CPU
CPU
CPU

CPU
CPU

CPU
CPU
CPU
CPU

CPU

and set

set

Branch on bit set and clear
Branch on bit set and set
Branch on bit set and set
interlocked
Branch on carry clear
Branch on carry set

BEQL
Branch on equal
BEQLU (-BEQL) Branch on equal unsigned
Branch on greater or equal
BGEQ
BGEQU (-BCC) -Branch on greater or equal
unsigned
Branch on greater
BGTR

185

uNOTE: i 024
Page 4 of 11
Mnemonic

MicroVAX
Architecture

Description

MicroVAXI MicroVAX.

BGTRU
BI:CB2
BI:CB3
BICL2
BICL3

Branch on greater unsigned
Bit clear byte 2-operand
Bit clear byte 3-operand
Bit clear longword 2-operand
Bit clear longword 3-operand

CPU
CPU
CPU
CPU
CPU

BICPSW

Bit clear processor status
word
Bit clear word 2-operand
Bit clear word 3-operand
Bit set byte 2-operand
Bit set byte 3-operand

CPU

CPU
CPU
CPU
CPU

Bit set longword 2-operand
Bit set longword 3-operand
Bit set processor status
word
Bit set word 2-operand
Bit set word 3-operand

CPU
CPU
CPU

CPU
CPU

Bit test byte
Bit test longword
Bit test word
Branch on low bit clear
Branch on low bit set

CPU
CPU
CPU
CPU
CPU

Branch on less or equal
Branch on less or equal
unsigned
Branch on less
(-BCS) Branch on less unsigned
Branch on not equal

CPU
CPU

CPU
CPU
CPU

CPU
CPU
CPU
CPU
CPU

CPU

CPU
CPU
CPU

CPU

BICW2
BICW3
BISB2
BISB3
BISL2
BISL3
BISPSW
BISW2
BISW3
BITB
BITL
BITW
BI~BC

BI~BS
BI~EQ
BI~EQU

BI~SS
B]~SSU

BNEQ

BNEQU (-BNEQ) Branch on not equal unsigned
Bl?T
Break point fault
BUB
Branch with byte displacement
Branch with word displacement
BRW
BSBB
Branch to subroutine with
byte displacement
BSBW
BVC
BVS
C1~LLG
C1~LLS

Branch to ~ubroutine with
word displacement
Branch on overflow clear
Branch-on overflow set
Call with general argument
list
Call with argument list on
stack

186

uNOTE
024
Page 5 of 11
Mnemonic

Description

MicroVAX
Architecture

Case byte
Case longword
Case word
Change mode to executive
Change mode to kernel

CPU
CPU
CPU
CPU
CPU

CHMS
Change mode to supervisor
CHMU
Change mode to user
CLRB
Clear byte
CLRD (-CLRQ) Clear D floating
CLRF (-CLRL) Clear F=floating

CPU
CPU
CPU
CPU
CPU

CLRG (-CLRQ) Clear G floating
CLRH (-CLRO) Clear H-floating
CLRL
Clear longword
CLRO
Clear ocatword
CLRQ
Clear quadword

CPU
CPU
CPU

CASEB
CASEL
CASEW
CHME
CHMK

CLRW
CMPB
CMPC3
CMPCS
CMPD

Clear word
Compare byte
Compare character 3-operand
Compare character 5-operand
Compare D_floating

CMPF
CMPG
CMPH
CMPL
CMPP3

Compare
Compare
Compare
Compare
Compare

CMPP4
CMPV
CMPW
CMPZV
CRC

Compare packed 4-operand
Compare field
Compare word
Compare zero-extended field
Calculate cyclic redundancy
check

CVTBD
CVTBF
CVTBG
CVTBH
CVTBL

Convert
Convert
Convert
Convert
Convert

F floating
G-floating
H-floating
longword
packed 3-operand

byte
byte
byte
byte
byte

to
to
to
to
to

0 floating

F-floating
G-floating
H-floating
longword

187

MicroVAXI MicroVAXII

CPU

CPU
CPU

E
E
E

EMA
HD

CPU
CPU
EMA
EMA
FPU

E
E
E

HF
HG

FPU
FPU

CPU

CPU
EMA

EMA
CPU
CPU
CPU
EMA

E
E
E
E

HD
HF
HG

FPU
FPU
FPU

CPU

CPU
CPU
CPU
E

uNOTE # 024

Page 6 of 11
Mnemonic
CV'l'BW
CV'l'DB
CVTDF
CV,]~DH
CV,]~DL

CV,]~DW
CV,]~FB
CV,]~FD

CV,]~FG
CV,]~FH

CVTFL
CVTFW
CVTGB
CVTGF
CVTGH
CVTGL
CVTGW
CV~rHB

CVTHD
CVTHF
CVTHG
CVTHL
CVTHW
CVTLB
CVTLD
cv~rLF

CVTLG
CV~rLH
CV~rLP

CV~rLW

Description

MicroVAX
Architecture

MicroVAXI

MicroVAXI~

CPU

" byte to word
Convert
Convert D floating to byte
Convert D-floating to
F floating
Convert D floating to
H floating
Convert D floating to
longw~rd -

CPU

E
E

HD
HD

FPU

Convert D floating to word
Convert F-floating to byte
Convert F-floating to
D floating
Convert F floating to
G floating
Convert F floating to
H_floating

E
E

HD
HF
HF

FPU
FPU
FPU

FPU

Convert F floating to
longword Convert F floating to word
convert G-floating to byte
Convert G-floating to
F floating
convert G floating to
H floating

FPU

E
E
E

HF
HG
HG

FPU
FPU
FPU

Convert G floating to
longword Convert G floating to word
Convert H-floating to byte
Convert H-floating to
D floating
convert H floating to
F_floating

FPU

E
E

Convert H floating to
G floating
Convert H floating to
longword Convert H floating to word
Convert longword to byte
Convert longword to D_floating

Convert longword to F floating
Convert longword to G-floating
Convert longword to H-floating
Convert longword to packed
Convert longword to word

188

FPU

CPU

CPU
FPU

E
E
E

HF
HG

FPU
FPU

EMA

CPU

EMA
CPU

uNOTE # 024
Page 7 of 11
Mnemonic
CVTPL
CVTPS
CVTPT
CVTRDL
CVTRFL
CVTRGL

Description

MicroVAX
Architecture

Convert packed to longworcl
convert packed to leading
separate
Convert packed to trailin9
Convert rounded D_floatin9
to longword
Convert rounded F_floatinq
to longword

MicroVAXI MicroVAXII

EMA
EMA

E
E

EMA
HD

EMA
FPU

FPU

EMA

E
CPU

EMA
CPU

E
E
E
E
CPU

HD
HF
HG
E
CPU

FPU
FPU
FPU
CPU

CVTTP
CVTWB

Convert rounded G_floatinq
to longword
Convert rounded H_floatinq
to longword
Convert leading separate
to packed
Convert trailing to packed
Convert word to byte

CVTWD
CVTWF
CVTWG
CVTWH
CVTWL

Convert word
Convert word
Convert word
Convert word
Convert word

DECB
DECL
DECW
DIVB2
DIVB3

Decrement byte
Decrement longword
Decrement word
Divide byte 2-operand
Divide byte 3-operand

CPU
CPU
CPU
CPU
CPU

DIVD2
DIVD3
DIVF2
DIVF3
DIVG2

Divide
Divide
Divide
Divide
Divide

D floating
D-floating
F-floating
F-floating
G=floating

2-operand
3-operand
2-operand
3-operand
2-operand

E
E
E
E
E

HD
HD
HF
HF
HG

FPU
FPU
FPU
FPU
FPU

DIVG3
DIVH2
DIVH3
DIVL2
DIVL3

Divide
Divide
Divide
Divide
Divide

G floating 3-operand
H=floating 2-operand
H-floating 3-operand
longword 2-operand
longword 3-operand

E
E
E
CPU
CPU

HG
E
E
CPU
CPU

FPU
E
E
CPU
CPU

DIVP
DIVW2
DIVW3
EDITPC

Divide packed
Divlde word 2-operand
Divide word 3-operand
Edit packed to character
string
Extended divide

E
CPU
CPU
E

EMA
CPU
CPU
EMA

CPU

CVTRHL
CVTSP

EDIV

to
to
to
to
to

o floatin9

F-floatin9
G-floatin9
H-floatin9
longword

189

uNOTE # 024
Page B of 11
Mnemonic

MicroVAX
Architecture

Description

MicroVAXI MicroVAXI!
HD
HF
HG

FPU
FPU
FPU

EMODD
EMODF
EMODG
EMC>DH
EMtJL

Extended modulus D floating
Extended modulus F-floating
Extended modulus G-floating
Extended modulus H-floating
Extended multiply -

CPU

EX~~V

Extract field
Extract zero extended field
Find first cIear bit
Find first set bit
Halt (kernel mode only)

CPU
CPU
CPU
CPU
CPU

INCB
INCL
INCW
INDEX
INSQHI

Increment byte
Increment longword
Increment word
Index calculation
Insert at head of queue,
interlocked

CPU
CPU
CPU
CPU
CPU

INSQTI

Insert at tail of queue,
interlocked
Insert into queue
Insert field
Jump
Jump to subroutine

CPU

CPU
CPU
CPU
CPU

Load process context (only
legal on interrupt stack)
Locate character
Match characters
Move complemented byte
Move complemented longword

CPU

CPU
CPU

EMA
CPU
CPU

EMA
EMA
CPU
CPU

CPU
CPU

CPU

CPU
HD
HF

CPU
FPU
FPU

E
E

FPU

CPU
CPU
CPU

Ex'rzv

FFC
FFS
HAI,T

INSQUE
INSV
JMP
JSB
LDPCTX
LOCC
MATCHC
MCOMB
MCOML

MNEGB
MNEGD
MNEGF

Move complemented word
Move from processor register
(kernel mode only)
Move negated byte
Move negated D floating
Move negated F=floating

MNEGG
MNEGH
.MNEGL
.MNEGW
:MOV,AB

Move
Move
Move
Move
Move

MCOMW
MFPR

negated G floating
negated H-floating
negated longword
negated word
address of byte

190

E
E

uNOTE # 024
Page 9 of 11
;Mnemonic

Description

MOVAD
MOVAF
MOVAG
MOVAH
MOVAL

(-MOVAQ)
(-MOVAL)
(-MOVAQ)
(-MOVAO)
Move

MOVAO
MOVAQ
MOVAW
MOVB
MOVC3

MicroVAX
Architecture

MicroVAXI MicroVAXII

Move address of D floating
Move address of F-floating
Move address of G-floating
Move address of H-floating
address of longword

CPU
CPU
CPU
CPU
CPU

Move
Move
Move
Move
Move

address of ocatword
address of quadword
address of word
byte
character 3-operand

CPU
CPU
CPU
CPU

MOVCS
MOVD
MOVF
MOVG
MOVH

Move
Move
Move
Move
Move

character 5-operand
D floating
F-floating
G-floating
H:=floating

CPU

CPU
HD
HF
HG

CPU
FPU
FPU
FPU

MOVL
MOVO
MOVP
MOVPSL

Move longword
Move octaword
Move packed
Move processor status
longword
Move quadword

CPU

E
E

CPU

EMA
CPU

CPU

EMA
EMA

CPU
CPU

CPU

CPU
CPU

CPU
CPU
HD

CPU
CPU
FPU

HD
HF
HF
HG
HG

FPU
FPU
FPU
FPU
FPU

MOVQ
MOVTC
MOVTUC
MOVW
MOVZBL
MOVZBW

Move translated characters
Move translated until
character
Move word
Move zero-extended byte to
longword
Move zero-extended byte to
word

MULB2
MULB3
MULD2

Move zero-extended word to
longword
Move to processor register
(kernel mode only)
Multiply byte 2-operand
Multiply byte 3-operand
Multiply D_floating 2-operand

MULD3
MULF2
MULF3
MULG2
MULG3

Multiply D floating
Multiply F-floating
Multiply F-floating
Multiply G-floating
Multiply G:=floating

MOVZWL
MTPR

3-operand
2-operand
3-operand
2-operand
3-operand

191

E
E

E
E
E

CPU
CPU
CPU
CPU
CPU

uNOTE # 024
Page 1.0 of 11
MicroVAX
Architecture

Description
MULH2
MUI,H3
MUI,L2
MUI,L3
MUI,P

Multiply H_floating 2-operand
Multiply H floating 3-operand
Multiply longword 2-operand
Multiply longword 3-operand
Multiply packed

MUI,w2
MULW3
NOP
POLYD
POLYF
POI,YG
POI,YH
POPR
PROBER
PROBEW
PUSHAB
PUSHAD
PUSHAF
PUSHAG
PUSHAH

MicroVAX:r MicroVAXI

E
E

CPU
CPU

Multiply word 2-operand
Multiply word 3-operand
No operation
Evaluate polynomial D floating
Evaluate polynomial F=floating

CPU
CPU
CPU

CPU
CPU
CPU
HD
HF

CPU
CPU
CPU
FPU
FPU

Evaluate polynomial G floating
Evaluate polynomial H=floating
Pop registers
Probe read access
Probe write access

E
E

FPU

CPU
CPU
CPU

CPU
F-floating CPU
G-floating CPU
H=floating CPU

CPU
CPU
CPU
CPU
CPU

CPU

CPU
CPU
CPU

Push address of byte
(-PUSHAQ) Push address of
(=PUSHAL) Push address of
(=PUSHAQ) Push address of
(=PUSHAO) Push address of

0 floating CPU

PUSHAL
PUSHAO
PUSHAQ
PUS HAW
PUSHL

Push
Push
Push
Push
Push

PUSHR
REI

Push registers
Return from exception or
interrupt
Remove from head of queue,
interlocked
Remove from tail of queue,
interlocked
Remove from queue

CPU
CPU

CPU

Return from procedure
Rotate longword
.
Return from subroutine
Subtract with carry
Scan for character

CPU
CPU
CPU
CPU

CPU
CPU
CPU
CPU
EMA

REMQHI
REZVIQTI
REZVIQUE
RE'l~
RO'l~L

RSB
SBWC
SCANC

address of
address of
address of
address of
longword

E
E

longword
ocatword
quadword
word

192

uNOTE i 024
Page 11 of 11
Mnemonic

Description

SKPC
SOBGEQ

SPANC
SUBB2

Skip character
Subtract one and branch
on greater or equal
Subtract one and branch
on greater
Span characters
Subtract byte 2-operand

SUBB3
SUBD2
SUBD3
SUBF2
SUBF3

Subtract
Subtract
Subtract
Subtract
Subtract

SUBG2
SUBG3
SUBH2
SUBH3
SUBL2

Subtract
Subtract
Subtract
Subtract
Subtract

SUBL3
SUBP4
SUBP6
SUBW2
SUBW3
SVPCTX

SOBGTR

MicroVAX
Architecture

MicroVAXI MicroVAXII

CPU

EMA
CPU

CPU

EMA
CPU

byte 3-operand
D floating 2-operand
D-floating 3-operand
F-floating 2-operand
F=floating 3-operand

CPU

CPU
HD
HD
HF
HF

CPU
FPU
FPU
FPU
FJ?U

G floating 2-operand
G-floating 3-operand
H=floating 2-operand
H floating 3-operand
longword 2-operand

E
E
E
E

HG
HG

FPU
FPU

E
E

CPU

Subtract longword 3-operand
Subtract packed 4-operand
Subtract packed 6-operand
Subtract word 2-operand
Subtract word 3-operand

CPU
CPU
CPU

CPU
EMA
EMA
CPU
CPU

CPU

TSTB
TSTD
TSTF
TSTG

Save
mode
Test
Test
Test
Test

CPU

CPU
HD
HF
HG

CPU
FPU
FPU
FPU

TSTH
TSTL
TSTW
XFC
XORB2

Test H floating
Test longword
Test word
Extended function call
Exclusive OR byte 2-operand

XORB3
XORL2
XORL3
XORW2
XORW3

Exclusive
Exclusive
Exclusive
Exclusive
ExcThsive

process context (kernel
only)
byte
D floating
F-floating
G=floating

O~ byte 3-operand
OR longword 2-operand
OR longword 3-operand
OR word 2-operand
OR word 3-oper'and

193

E
E
E
E

E
E

E
E
E
E

CPU
CPU
CPU
CPU

CPU
CPU
CPU
CPU
CPU

194

uNOTE # 025

Title:

FPJ11-AA Compatibility with the
LSI-11/73 (KlDJ11-A)

Date: 28-APR-85

1---'

Originator: Mike Collins

Page 1 of 2

Early LSI-11/73 (KDJ11-A) modules are incompatible with the FPJ11-AA
floating point accelerator.
This MicroNote describes how to identify
those modules which are compatiblf~ and those which are not compatible
with the FPJ11-AA.
The following information refers to two identifying numbers.
the module variation and the module revision.
The module variation number is stamped onto the end of
handles.
It will be 'M8192', 'M8192-YB' or 'M8192-YC'.

They
the

are

plastic

The module revision number can be found on side two of the module
(noncomponent side)
stamped int:o the plastic handle, or written with
indelible ink. This number is updated as the board is ECO'd.
The
designation is a number followed by the module revision.
e.g.
441 C1,
indicates module revision C1.
The first LSI-11/73 module is called a KDJ11-AA and is incompatible with
the FPJ11-AA.
The module variation for the KDJ11-AA is M8192, and the
module revision number is C1.
The KDJ11-AA can be upgraded to be
FPJ11-AA compatible. contact thE~ local DEC office for more information
concerning the upgrade procedure.
Two new options have been created.
The KDJ11-AB is a module which is
fully compatible with the FPJl1-AA.
The module variation for the
KDJ11-AB is M8192-YB, and the module revision number is A1 or A2.
The third option is called a KDJ11-AC and is used for fully compatible
modules which have FPJ11-AAs installed onto the board by Digital.
It
has a module variation of M8192-YC and the module revision number is A1
or A2.
Therefore a KDJ11-AB becomes a KDJ11-AC by simply installing an
FPJ11-AA.

195

uNOTE 41: 025
Page 2 of 2
The following table summarizes the above information and should be
used as a 'quick check' for FPJ11-AA compatibility.
OPTION

MODULE
VARIATION

MODULE
REVISION

FPJ11 COMPATIBLE?

KDJ1l-AA

M8192

NO (But upgradeable)

KDJll-AB

M8192-YB

A1 or A2

KDJ1l-AC

M8192-YC

A1 or A2

YES
YES (FPJll-AA Installed)

L....--.

CAUTION
An FPJ1l-AA installed on a KDJll-AA may APPEAR
but cache errors and parity errors may occur.

work

An MXV11-BF must be REV C to be compatible with a
KDJ1l-A with an FPJll-AA (KDJ1l-AC). Earlier versions
of the MXV11-BF are incompatible
with
KDJ11-ACs.
KDJ11-As without FPJ11-AAs are compatible with all
versions of the MXV11-BF.
The MCV11-D is incompatible with KDJ1l-ACs.
KDJll-As
without FPJll-AAs are compatible with all versions of
the MCV1l-D.

196

uNOTE # 026

Title:

The MicroVAX II CPU Multicomputing
Capability

Date: 28-JUN-85
Page 1 of 14

Originator: Mike Collins

The MicroVAX II CPU may be configured as an arbiter CPU or as one of
three auxiliary CPU's.
Therefore it is possible to configure a Q-bus
system with multiple MicroVAX II CPUs.
This 'multicomputing' capability
is the topic of this MicroNote.
Multicomputing Introduction
The multi computing capability is a hardware design feature of the
MicroVAX II.
It allows a maximum of four MicroVAX II CPUs to reside on
the same O-bus.
Figure 1 below is a block diagram which shows how 2 of
a possible 4 CPUs may be configured on the bus. One of the processors
will be the arbiter and the others will be auxiliaries.
NOTE
There is no shared memory between processors,
therefore
this system should not be considered as symmetrical
multiprocessing.
Each processor may use expansion memory modules provided that there are
sufficient O/CO slots in the backplane.
See the configuration section
for more detail on the configuration rules.

I
Arbiter
Processor

I
Auxiliary
Processor
#1

[ Memory

Q-bus
Figure 1 - Multicomputirtg Configuration

197

I
Memory

uNOTE # 026
Page 2 of 14
CAUTION
Digital's 32-bit operating systems DO NOT support the
multicomputing feature.
Users who wish to customize
their systems to take advantage of the multicomputing
capability may do so but are responsible for designing
the software system.
The following topics which are pertinent to
will be described in detail:

the

MicroVAX II Memory System

Interprocessor Communications Register

Arbiter/auxiliary Processor Differences

Bootstrapping an Auxiliary Processor

Configuration Rules

mUlticomputing

design

REFERENCES
The MicroVAX 630 CPU
Module
User's
Guide
(PIN
EK-KA630-UG)
and MicroNote #22 have more detailed
information on all aspects of the MicroVAX II CPU and
memory system.
MicroVAX II Memory System
Before describing the details of the multi computing feature
:necessary to understand the memory system of a MicroVAX II.

'The memory system of the MicroVAX II is unique. Unlike previous Q-bus
processors, the memory modules do not communicate to the CPU over the
Q-bus. Instead, the communication and transfers occur over a dedicated,
closely coupled interconnect.
This design allows for very fast reads
and writes to memory (400 nsec). Not only are the transfers very fast,
but none of this CPU-memory activity appears on the Q-bus. Therefore
the Q-bus is strictly for I/O.
Since memory is not directly on the Q-bus it is necessary to allow DMA
devices on the Q-bus to access memory. This feature is called the Q-bus
I/O map. It is a mechanism which maps Q-bus addresses (22-bit physical
address) to th~ local memory system of a MicroVAX II (24-bit physical
address). This same concept is used on larger UNIBUS based VAXes.
When one. or more auxiliary processors are added to a system, remember
that each has its own local memory system. Therefore it is intended
that they will each operate out of their own memory.
This design is

198

uNOTE # 026
Page 3 of 14
well suited for applications which can be easily partitioned between
multiple processors such that only messages are passed between them.
It would be possible for a process()r to operate out of memory on the
Q-bus but this would be unconvE~ntional from a systems standpoint and
would decrease system performance significantly.
Digital's operating
systems do not support the use of standard Q-bus memories in a MicroVAX
II.
With only one processor on the Q-bus, the system software has complete
control over DMA transfers. The software controls the contents of the
Q-bus map registers. First, it determines whether the register is
enabled and second, if it is enabled, where the DMA transfers are
directed in the local memory system.
In a multiple processor configuration (since each has its own set of
Q-bus I/O map registers) it is now possible for multiple map registers
to respond to a single a-bus addrel;s. It is the responsibility of the
system software running on each processor to cooperate and assure that
one and only one map register will respond to any Q-bus address.
Otherwise multiple memory locations may respond and the results are
indeterminate (i.e. multiple BRPLYs on the Q-bus for a single address).
A similar situation occurs if standard Q-bus memories are added to a
The system software is again responsible for
MicroVAX II system.
assuring that for any address on the Q-bus which is 'shared' by a Q-bus
memory board and a a-bus I/O map register, the map register is disabled
to allow only a Q-bus memory reply.
Q-bus memories would not be added to 'typical' systems.
However there
are some special applications which may req~ire this capability. For
example, a graphics system where the Q-bus memory is the bit map of a
graphics display.
On power-up, the MicroVAX II boot :ROM will check for the presence of
Q-bus memory and clear the valid bits of the corresponding mapping
registers. This will prevent the ,above situation from occurring as long
as the system software does not alter the state of these valid bits at a
later time.
Interprocessor Communications Register
The interprocessor communications register (ICR) is
the
primary
mechanism of the MicroVAX II CPU which enables multiple processors to
cooperate and reside on the same Q-bus. Figure 3 describes the ICR and
the bit definitions.

199

uNOT!= # 026
Page 4 of 14
The ICR provides the following four functions:
1.

Any processor on the bus may interrupt another without using
the Q-bus interrupt lines.
This is done by setting the
appropriate bit in the ICR of the second processor.
The CPU
will then interrupt at IPL 14 (HEX) with an interrupt vector of
204 (HEX).

The ICR also has a bit which controls external access to local
memory via the Q-bus map. When set this bit allows external
devices to access the local memory system.
When reset, this
bit prevents the local memory system from responding to any
Q-bus address references.

If a processor is an auxiliary then the ICR provides a
mechanism which allows it to be halted by other CPUs. This
feature is used at power-up to coordinate the bootstrap
process.

Parity errors are identified when one occurs during accesses to
the MicroVAX II's local memory.

The address for the ICR is located in the Q-bus I/O page address space
and may be accessed by any device which can become Q-bus master. The
ICR is byte-addressable.
Si.nce it is possible to put a maximum of 4 MicroVAX II CPUs on one Q-bus
they each have their own unique ICR. Table 1 lists each processor and
the associated ICR address.
Table 1 - Interprocessor Communication Register Address Assignments
Processor

22-bit Octal Address

32-bit Hexadecimal Address

Arbiter

17 777 500

2000 1F40

Auxiliary #1

17 777 502

2000 1F42

Auxiliary #2

17 777 504

2000 1F44

Auxiliary #3

17 777 506

2000 1F46

200

uNOTE # 026
Page 5 of 14
111 1 1
5 4 321

DMA QPE

I I
I

1
0

000 0 0 0

321

I I I I I o0 0 0 I I

AUX HLT
OBI IE
LM EAE
OBI RO
Figure 3 - Interprocessor Communications Register
Bit(s) Mnemonic
<15>

Meaning
DMA 022-Bus Address Space Parity Error.
This read-only bit is set if Memory System
Error Register bit <04> (DMA OPE) is set.
The DMA QPE bit indicates that a parity
error occurred when an external device (or
CPU) was accessing the MicroVAX II CPU
local memory.

DMA OPE

Unused.

<14:09>
<08>

Auxiliary Halt. On an auxiliary MicroVAX,
AUX HLT is a read-write bit. When set,
typically by the arbiter CPU, it causes
the on-board CPU to transfer program
control to the Halt Mode ROM Code. On
an 'arbiter MicroVAX II, AUX HLT is a
read-only bit which always reads as zero.
It has no effect on arbiter CPU operation.

AUX HLT

Unused.

<07>
<06>

OBI IE

<05>

LM EAE

Read as zeros.

Read as zero.

Doorbell Interrupt Enable. This bit, when
set, enables interprocessor doorbell
interrupt requests via ICR <00>. When the
on-board CPU is Q22-Bus master, OBI IE
is a read-write bit. When an external
device (or CPU) is bus master, OBI IE
is a read-only bit. OBI IE is cleared
by power up, by the negation of DCOK and
by writes to the Bus Initialize Register.
Local Memory External Ac.cess Enable. This
bit, when set, enables external access to

201

uNOTE # 026
page 6 of 14
local memory (via the Q22-BUS map). When
the on-board CPU is Q22-Bus master, LM EAE
is a read-write bit. When an external
device (or CPU) is bus master, LM EAE is
a read-only bit. LM EAE is cleared by
power up, by the negation of DCOK and
by writes to the Bus Initialize Register.
Unused.

<04:01>
<00>

OBI RQ

Read as zeros.

Doorbell Interrupt Request. If ICR <06>
(OBI IE) is set, writing a "1" to OBI RQ
sets OBI RQ, thus requesting a doorbell
interrupt. If ICR <06> is clear, writing
a "1" to OBI RQ has no effect. Writing a
"0" to OBI RQ has no effect. OBI RQ is
cleared when the CPU grants the doorbell
interrupt request. OBI RQ is held clear
whenever OBI IE is clear.

When a processor is interrupted via its ICR the interrupt vector is 204
(He,). This vector is used when the interrupting device is the arbiter,
auxiliary #1, auxiliary #2, auxiliary #3, or any device which may become
Q-bus master.
Therefore it is the responsibility of the interrupt
service routine to determine which device caused the interrupt since the
same vector is used no matter what device set the OBI RQ bit. This
interrupt occurs at the same interrupt priority level (IPL) as IRQ4 on
the Q-bus.
NOTE
Following such an interrupt, the MicroVAX II sets the
IPL to 14 (Hex). This is different from what happens
after a standard Q-bus interrupt.
When
a
Q-bus
interrupt occurs on IRQ4, the processor raises the IPL
to 17 (Hex) and it is the responsibility of the
interrupt service routine to lower the IPL later on.
Arbiter/Auxiliary Processor Differences
There are several differences between arbiter and auxiliary
It is important to understand these differences when
multiple process~rs into a system.
1.

processors.
configuring

The arbiter MicroVAX II arbitrates bus mastership in accordance
with the Q22-Bus DMA protocol.
The arbitration logic is
disabled on an auxiliary MicroVAX II.

202

uNOTE # 026
Page 7 of 14
2.

Bot.h the arbiter and aux:iliary MicroVAX II
mastership via the Q22-BuS DMA Request protocol.

request

bus

They both assert BDMR on the Q22-Bus.

The arbiter MicroVAX II receives DMGI from its arbitration
logic.
But an auxiliary receives DMGI from its Q22-Bus
BDMGI pin.

Only the auxiliary MicroVAX II actually
the Q22-Bus.

asserts

BSACK

The arbiter MicroVAX II asserts the Q22-Bus BINIT signal when
DCOK is negated and when its CPU software writes to its Bus
Initialize Register. An auxiliary MicroVAX II never asserts
Q22-Bus BINIT, but receives BINIT and uses it to initialize the
MicroVAX chip and to clear all internal registers which are
cleared by the negation of DeOK.

The physical address of the Interprocessor
Communication
Register is different for each of the four MicroVAX II
arbiter/auxiliary configurations.

An auxiliary MicroVAX II can be halted by setting bit <08> (AUX
HLT) of its Interprocessor Communication Register.
On an
arbiter MicroVAX II this feature is disabled and AUX HLT is a
read-only bit which always reads as zero.

The CPU halts are controlled by the external connector HLT ENB
input.
However, the external halts which are affected differ
somewhat for the arbiter and auxiliary MicroVAX II modules. If
the HLT ENB signal is assert'ed (low) the a MicroVAX II CPU will
halt and enter the console program if:
a.

The program executes a halt instruction in kernel mode.

The console detects a break character.

Arbiter CPU only - the Q-bus halt line is asserted.

Auxiliary CPU only
the
Register AUX HLT bit is set.

Interprocessor

Communication

If the HLT ENB signal is negated then:
a.

~he halt line and break character are ignored and
the ROM
program responds to a halt instruction by restarting or
rebooting the system.

203

uNOTE # 026
Page 8 of 14
b.

If the MicroVAX CPU is an
responds to the assertion
rebooting.

auxiliary, the ROM program
of the ICR AUX HLT bit by

The state of the HLT ENB bit can be read by
Boot and Diagnostic Register.

software

via

the

field
Each arbiter or auxiliary MicroVAX II module can
interrupt requests from its interval time r, from its console
device, and from its interprocessor doorbell. Only the arbiter
MicroVAX II can field interrupts from Q22-Bus interrupt request
lines IRQ7-4.

The arbiter asserts BIAKO on the Q22-Bus when it responds to a
Q22-Bus interrupt request. An auxiliary asserts BIAKO on the
Q22-Bus when it receives the assertion of BIAKI in order to
pass it through to devices after it.

Although both the arbiter and auxiliary MicroVAX II modules
contain
the same time-of-year clock and battery back-up
circuitry, it is assumed that the auxiliary will be configured
without batteries and that its clock will never actually be
enabled. This configuration will ensure a single time base for
the system.
If an auxiliary needs to set its time-of-year
clock it can do so by referencing the arbiter's clock.

10.

An arbiter processor can bootstrap from a variety of devices
but an auxili~ry will always boot using the ROM bootstrap
protocol. See the following section for a detailed description
of the bootstrap process.
Bootstrapping an Auxiliary Processor

Since there are distinct differences between the
operation
and
capabilities of arbiter and auxiliary processors, it is necessary to
bootstrap them differently. An arbiter processor bootstraps in the
conventional manner from one of several devices but an auxiliary boots
using only one method.

204

uNOTE # 026
Page 9 of 14
On power-up both processors initialize themselves and perform some self
tests. At this point the primary bootstrap (VMB) begins to execute. An
arbiter processor may bootstrap from anyone of the following devices:
1.

DU type device (RX50, RDxx, RC25 or RAxx)

TK50 tape

ROM

Ethernet (DEQNA)

bootstrap protocol

An auxiliary processor will not attempt to boot from disk, tape or
ethernet.
It will always boot via the ROM bootstrap protocol, which is
described below.
In order to synchronize the bootstrap process, after power-up and
initialization an auxiliary process,or will not boot until it is allowed
to do so by the arbiter. The contrclliing device is not required to be
the arbiter, it could be another auxiliary or DMA device which is bus
master, but it is the most logical point of control.
The following steps summarize the bootstrap procedure for a system
an arbiter and one (or more) auxiliaries:

with

Both types of processors initialize themselves after power-up.

Self-diagnostics execute tC) check out

The arbiter boots from one of
above.

cpu.

the

major

four

sections

device

types

the

listed

While the arbiter is booting the auxiliary completes
diagnostics and waits to start its bootstrap process.

its

The auxiliary clears the valid bit in each of its Q-bus map
registers to prevent accidental transfers to or from its
local memory.

The auxiliary loops doing nothing until the AUX HLT bit in
its ICR is cleared. When this bit is finally cleared, the
auxiliary boots via the ROM bootstrap protocol.

Some~here in the system thE! appropriate data structure has been
created to allow the au~(iliary to boot via the ROM bootstrap
protocol. This can be done several ways:

205

uNOTE # 026
Page 10 of 14

The bootstrap code is actually in ROM on an MRV11-D module.

The bootstrap code is loaded into non-volatile RAM.

The arbiter ·CPU loads the bootstrap code into its own local
memory then sets up some Q-bus map registers so that this
data can be seen by the auxiliary CPU over the Q-bus.
This
method is the most flexible since the bootstrap code can be
changed easily.

'When the arbiter is ready and knows auxiliary boot code is
available, it allows the auxiliary CPU to bootstrap by clearing
the AUX HLT bit in its ICR.

ROM Bootstrap Protocol.
To locate a PROM bootstrap, VMB searches the Q22-bus address range from
high to low addresses by page (512 bytes per page) looking for readable
memory.
If the first six longwords of any such page contains a valid
PROM "signature block"
(see figure 4), VMB passes control directly to
the bootstrap code in the PROM, it does not copy the PROM code to local
memory for execution as it does for all other secondary bootstraps.
Note that while defined as an MRV11 PROM or equivalent bootstrap, VMB
does not actually require that the signature block or the bootstrap code
be in PROM.
It could be in ROM, nonvolatile RAM or it could be loaded
into another MicroVAX II's RAM and mapped to the Q22-bus thus enabling
an auxiliary to see it.
RB:
+

check byte

I any value

any value

18 (hex)

size of PROM in pages

+ 12:

must be zero

+ 16:

offset into PROM to start execution

+ 20:

sum of previous three longwords
Figure 4:

PROM Bootstrap Memory Format

RB + 0:

This byte must be 18 (hex).

RB + 1:

This byte must be O.

RB + 2:

This byte may be any value.

206

uNOTE # 026
Page 11 of 14
RB + 3:

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

RB + 4 :

This byte must be zero.

RB + 5:

This byte must be 1.

RB + 6:

These two bytes may be any value.

RB + 8:

This longword contains the size in pages of
PROM.

RB + 12:

This longword must be zero.

RB + 16:

This longword contains the byte offset into
PROM where execution is to begin.

the

RB + 20:

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

the

sum

Configuration Rules
In order to configure multiple Micro,VAX II CPUs onto one bus,
must be addressed:

issues

Q-bus slot requirements for the CPU and MS630 memory boards.

Compatible enclosures or boxes.

Bus termination.

Using a POP-11 CPU as the Arbiter.

1. Q-bus slot requirements.
To operate properly both the MicroVJl~X II CPU and all versions of the
MS630 memory modules MUST be insertE!d in Q-bus slots which feature Q-bus
signals on the A/B side and the CO interconnect on the C/O side.
The
MicroVAX II CPU and any expansion mE!mory modules must all be adjacent in
the backplane.
WARNING
The MicroVAX II CPU WILL be damaged if inserted
slot tAhich has Q-bus signals on the C/O side.

207

into

uNOTE # 026
Page 12 of 14
2. Compatible enclosures or boxes.
Since O/CD slots are required, there are only
compatible with these modules. They are:

enclosures

which

are

BA23 (8 slots total, first 3 are O/CD)

BA123 (12 slots total, first 4 are O/CD)

BA11-S (9 slots total, all 9 are Q/CD)

BA11-N (9 slots total, all 9 are Q/CD) This enclosure is
electrically compatible but since it is older it is only 1S-bit
compatible and has not been tested for FCC compliance in a
system package.
Since the BA11-S is the 22-bit, updated
version, the BA11-N enclosure is not recommended.

3. Bus termination.
Each MicroVAX II processor has 240 ohm termination. When multiple CPUs
are
placed
into one system,
take care to abide by the Q-bus
specification regarding termination and configuring
multiple
box
systems.
REFERENCE
Reference MicroNote #29,
entitled 'Q-bus
Expansion
Concepts' and appendix A of the Microsystems Handbook
(P/N EB-26085-41) for more information concerning Q-bus
configuration rules.
The BA11-S enclosures are best suited for multiple CPUs because they
have backplanes with the Q22/CD configuration in all slots. Therefore
multiple CPUs and expansion memory can be accommodated most easily. The
other potential boxes, the BA23 and BA123, are not as flexible because
they only have 3 and 4 Q22/CD slots respectively.
When using multiple MicroVAX II CPUs in one system the goal should be to
configure each backplane with 120 ohm termination if the number of
backplanes used is one or two.
In the three backplane case, only the
first and third backplanes should have 120 ohm termination.
This
implies that no MicroVAX II CPUs should be configured into the middle
backplane of a three backplane system (three backplanes is the maximum
number allowed for the Q-bus).
'rhe following configurations assume the BA11-S enclosures will be used.
Two CPU System:
A two CPU system is the easiest case to configure.
As mentioned
earlier,
each CPU has 240 ohm termination. With two CPUs in the same

208

uNOTE # 026
Page 13 of 14

backplane, the proper overall termination of 120 ohms is achieved.
The
first CPU has 240 ohms in parallel ~7ith 240 ohms on the second CPU which
is 120 ohms, assuming there is no tE!rmination on the backplane (which is
true for the BA11-S enclosure).
Three CPU System:
A three CPU system should be configured in 2 backplanes to maintain 120
ohm termination in each. The first 2 CPUs should be configured in the
first box which terminates that backplane properly as in the case above.
The third CPU should be· placed in the second backplane. The modules of
the expansion cable set must be terminated differently. The module of
the expansion cable set in the first backplane should add no additional
termination to the system while thE! module in the second backplane
should be terminated with 240 ohms. Therefore the second backplane is
also terminated in 120 ohm (240 on the processor in parallel with 240 on
the expansion module).
Four CPU System:
A four CPU system should also be configured in 2 backplanes. The first
backplane will have 2 CPUs for 120 ohm termination and the second
backplane will also have 2 CPUs fc)r 120 ohm termination.
But the
expansion cable set connecting thE! two backplanes will not be the same
as in the three CPU system. In this case there should be no termination
on either of the expansion modules.
These same basic rules should be followed if the BA23 enclosure is used.
However the configurations beCOmE! more constrained because of the
relatively few number of Q/CD slots.
The configuration also becomes
more complicated because the BA23 has built in termination on the
backplane (termination resistors arE! socketed and therefore removable).
4. Using a PDP-11 CPU as the Arbiter.
The arbi ter can be a Q-bus PDP-11 CE)U as well as a MicroVAX II CPU.
In
this configuration only the 3 auxiliary MicroVAXes could be added to the
system. Although there are tremendous architectural differences between
a PDP-11 and MicroVAX CPU, they both perform the arbiter function on the
Q-bus and therefore such a configuration is possible. Two issues arise
from this 'mixed' configuration.
1.

All Q-bus PDP-11s to-date have their main memory on the Q-bus.
In
order to talk to an auxiliary MicroVAX CPU's local memory, part of
the Q-bus physical address spacE~ must be reserved for mapping to
that local memory.

The PDP-11 processor will not have an interprocessor communication
register because that featurE~ is unique to the MicroVAX II CPU.
Therefore, if it is necessary to have the capability for an
auxiliary CPU to interrupt the arbiter, an additional device must be
added to the system. This device will look like the interprocessor

209

uNOTE i 026
Page 14 of 14
communication register for an arbiter and will convert and ICR
interrupt into a conventional Q-bus interrupt (there
is
no
capability which allows an auxiliary to interrupt the arbiter via
the standard Q-bus interrupt protocol).

210

uNOTE # 027

Title: USING MESSAGES WITH VAXELN

Date: 28-JUN-85

Originator: Christopher DeMers

Page 1 of 5

This Micronote discusses how VP.. XELN uses messages for
inter-job
communication.
Included is an overview of the message architecture,
benchmark data from MicroVAX II configurations and a sample program
illustrating the m~ssage handling technique.
In a VAXELN application, every job(Pascal,C or Macro-32 program)
has a
unique and protected virtual addrE~ss space. Within a single processor,
the kernel separates each job's virtual address space using the VAX
memory management hardware.
Within a network,
each job's virtual
address space is separated by virtue of the fact that the jobs may exist
in the memories of different computer systems.
One of the principal reasons for dividing an application into separate
jobs is to aid the migration and distribution of the jobs within the
network.
In order for the jobs to work together on the
same
application, they must be able to share data, but the only way of moving
data from the memory of one processor to another in a network is by
packaging the data in a message and directing the network hardware to
move the message to the destination memory.
To make the network movement of data between jobs the same as in the
non-network case, messa~e passing is the principal means of inter-job
communication. The kernel provides a number of facilities to make an
efficient and transparent means of communication.
The VAXELN MESSAGE object describes a block of memory that can be moved
from one job's virtual address space to another's.
The block of memory
is called 'message data' and is allocated dynamically by the kernel from
physically contiguous, page-alignE~d blocks of memory. A MESSAGE object
and its associated message data are both created by calling the
CREATE MESSAGE kernel service.
Message data is mapped into a job's PO virtual address space, so it is
potentially accessible to all the processes in the job.
If a message is
sent to a job on the sending job's local node, the kernel unmaps the

211

uNOTE # 027
Page 2 of 5
message data from the sending job's virtual address space and remaps it
into the receiver's space.
Instead of moving the data, page Table
Entries are remapped, resulting in very fast message transmission time.
If a message is sent to a remote node, the kernel again unmaps the
message data, but it remaps it into the appropriate network device
driver job to send the message to the remote system.
The reverse
operations then cause the message data to be remapped in the receiver's
space.
The code necessary to send a message local to a machine or over the
network is identical in both cases.
A port name table parameter
(NAME$LOCAL or NAME$UNIVERSAL) allows the programmer to define local or
remote ports.
The kernel maintains the local name list, while the name
table for network-wide names is maintained by the name server.
Names
known throughout the network are guaranteed to be unique.
Thus, jobs
can initially be executed on one processor and later be segmented to run
on multiple processors without modification of the program.
Datagrams and Circuits
Messages can be used two ways to transmit data:
- One process can obtain the value of a port anywhere in the system
(including other jobs) or in a different system running on a different
Ethernet node.
The process can send the port a message with the SEND
procedure.
This is called the datagram method.
- Any two ports (usually in different jobs) can be bound together to
form a circuit.
In this case, having established the circuit, the
sending process has one port of its own bound to another port, which
usually is in a different job or on a different network node.
The
sender sends the message to its own port, and it is routed automatically
to the other port in the circuit.
Processes can both send to and
receive from a circuit port.
In the datagram method, as well as in the circuit method, a process can
uSle the WAIT procedures to wai t for the receipt of a message on the
specified port.
The datagram method requires no connection sequence as in circuits, but
cannot guarantee that a message is actually received at the destination.
However, it does guarantee that received messages are correct.
At the cost of setting up and handling a circuit connection,
offer several advantages over the basic datagram method:

circuits

- Guaranteed delivery.
The circuit method guarantees that either the
message arrives at the destination port regardless of its location, or
that the sender is notified that the message could not be delivered.

212

uNOTE # 027
Page 3 of 5
- Flow control.
You can prevent a sending process from sending too many
messages to a slower rece1v1ng process.
If a port is connected in a
circuit and is full, the sender is put into the waiting state until the
port is no longer full (you can override this default).
The implicit
waiting performed by the SEND procedure evens the flow of messages
between the transmitting process and the receiving process without
having to explicitly program for the condition.
Furthermore,
circuits
guarantee the sequence of message delivery as no other unconnected port
can send a message to a connected port.
- Segmentation. Message can have any length (datagrams are limited to
approx.
1500 bytes),
and, if the transmission is across the network,
the network services will divide the message into segments of the proper
length,
transmit the segments and reassemble them at the destination
node.
- User interface via Pascal I/O routines.
The OPEN procedure permits
you to 'open' a circuit as if it were a file and to use the I/O routines
such as READ and WRITE to transmit messages.
There is no performance penalty with circuits for messages transmitted
over the same network node and very little over the network.
For full
generality, programs should assume that the sending and receiving jobs
may be distributed on different nodes in a network.
Circuits are the
preferred means of sending message in almost every practical case.
Expedited Messages
An expedited message bypasses the normal flow-control mechanism and can
be sent even if the receiving port already has its maximum number of
messages.
The message is received by the port before any normal data
messages.
The size of an expedited message is limited to a maximum of
16 bytes.
Monitoring Network Integrity
Circuits can be used as a method for monitoring the status of a network
connection.
In addition to the circuit used to send data, another
process could establish a secondslry circuit with a process in a
remote
node.
Neither process sends data, they only WAIT on their respective
ports. When a node fails,
the circuit is broken and the WAIT is
satisfied.
At this point exception handling routines could be invoked
to handle this condition.
This clllows the programmer to separate the
error handling code from the ~essage transmission code.

213

uNOTE # 027
Page 4 of 5
Connecting with VAX/VMS nodes
The VAXELN procedure CONNECT CIRCUIT can be used to request a connection
with a VAX/VMS program on the same DECnet network.
Instead of using a
port as the destination for the connection, a VMS node and an object
name
(program name on the VMS node) is used.
The program on the VMS
node completes the connection by opening the "file" SYS$NET.
A 'VAX/VMS node may also request a connection by specifying a node name
and port name in the file portion of an OPEN statement. The VAXELN node
complete the connection by issuing an ACCEPT CIRCUIT statement.
Performance Data
MicroVAX II, 5MB memory, connection via circuit
All times in microseconds (us).
Throughput in thousand bytes/second(KB/s).
Delivery
Me ssage Size Create Delete
One Machine
Two Machines
( bytes)
Time
Time Time Throughput Time Throughput
0
5 12
20 48
81 92

131
361
450
481

144
255
274
394

1094
1611
1885
2139

N/A
318
1087
3830

214

4479
5271
8675
27538

N/A
97
236
298

uNOTE # 027
Page 5 of 5
PROGRAM msgsend(INPUT,OUTPUT)i
{++

{ This program connects a circuit to the global name 'msgrecv',
{ sends a message to the receiver and waits for a reply.

{-}

VAR

send port,reply port:
msg data ptr:
repTy_data_ptr:
msg,~eply:

PORTi
MESSAGE;
"'VARYING STRING(20);
"'VARYING=STRING(10);

BEGIN
CREATE PORT(send port);
CONNECT CIRCUIT(send port, destination name := 'msgrecv');
CREATE MESSAGE(msg,msg data ptr);
msg data ptr'" := 'messige f~om msgsend';
SEND(msg~send port);
WAIT ANY(send-port);
RECEIVE(reply~reply data ptr,send port);
DELETE(reply);
DISCONNECT CIRCUIT(send port);
END; { progrim msgsend } PROGRAM msgrecv (INPUT,OUTPUT);
{++

{ This module runs a receive program that accepts a circuit,receives
{ a message and sends back a reply.

{-}
VAR
reply_port:
nam:
msg,reply:
msg data ptr:
repl"y_data_ptr:

PORT;
NAME;
MESSAGE;
"'VARYING STRING(20);
"'VARYING=STRING(20);

BEGIN
CREATE PORT(reply port);
CREATE-NAME(nam,'msgrecv',reply port,table :- name$universal);
INITIALIZATION DONE;
ACCEPT CIRCUITTreply port);
WAIT ANY(reply port);
RECEIVE(msg,msg data ptr,reply port);
DELETE(msg);
CREATE MESSAGE(reply, reply data ptr);
reply aata ptr'" := 'reply';
SEND(~eply~reply port);
END; { program msg~ecv }

215

216

uNOTE # 028

Title: MSV11-Q/M/J MEMORY COMPARISONS

Date: 28-JUN-85

Originator:

Page 1 of 3

JACK TOTO

This MicroNote will compare three of Digital Equipment Corporation's
newest memory modules. Following the description of each memory module,
is a chart which, list the differences between these memories.
MSV11-Q
The MSV11-Q has three versions,
the MSV11-QA,
the MSV11-QB and the
MSV11-QC. The MSV11-QA (M7551-A) is a quad size Q-bus memory module and
contains 1MB of MOS RAM using 64K bit parts. The MSV11-QA has two etch
revisions which must be checked when configuring the module into a
system. The two revisions are the C rev and the A rev, both of these
revisions are discussed in the Users Guide (EK-MSVIO-UG) and in
Micronote # 030. The second version of the MSV11-Q is the MSV11-0B
(M7551-B) which is a half populated quad size O-bus memory module
containing 2MB of MOS RAM using 256K bit parts. The last version of the
MSV11-Q is the MSV11-QC which is a fully populated MSV11-QB quad size
Q-bus memory module containing 4MB of MOS RAM using 256K bit parts.
Both the MSV11-QB and the MSV11-QC use the MSV11-QA printed circuit
board, however that board is ECOed to etch level C.
MSVII-J
The MSV11-J has four versions, the MSV11-JB and MSV11-JC which are used
in the PDP-11/84 UNIBUS systems and the MSV11-JD and MSV11-JE are used
in either the MicroPDP-11/83 Q-bus systems, or the PDP-l1/84 UNIBUS
systems.
All four modules use ECC memory for error correction, as well
as using 256K bit MOS RAM parts on either a half or fully populated quad
size module.
NOTE:
NONE OF THE FOUR MSV11-J MODULES CAN BE PLACED IN A 0/0
BACKPLANE SLOT. IF THIS IS ATTEMPTED PERMANENT DAMAGE WILL
BE DONE TO THE BOARDS AND TO THE SYSTEM.
The MSVII-JB (M8637-BA) is a half populated quad size PMI memory module
containing 1MB of memory.
The second version of the MSV11-J is the
MSVI1-JC (M8639-CA), this is a fully populated MSVI1-JB quad size PMI
memory module containing 2MB of memory. These two modules can not be
used in a Q-bus system due to gate array incompatibilities, and can only

217

uNOTE # 028
PClge 2 of 3
be used in PDP-11/84 systems which use the UNIBUS/PMI bus interface
(KTJ11-A).
The third version of the MSV11-J is the MSV11-JD (M8639-DA)
which is a half populated quad size PMI memory module containing 1MB of
memory.
The last version of the MSV11-J is the MSV11-JE,
(M8639-EA)
which is a fully populated MSV11-JD quad size PMI memory module
containing 2MB of memory.
These last two modules can be used with
either the MicroPDP-11/83 system which uses the Q-bus/PMI bus interface
or the PDP-11/84 system which was mentioned above.
For details
reference the PMI protocol Micronote # xxx .
.Although the MSV11-JD and Msv11-JE are PMI memories they can be used
two other Q-bus configurations.

1. If either of these two memories are used in slots 1 and/or 2 of
a Q/eD backplane such as the H9276
(BAll-S box) or in the
MicroPDP-11 BA23 backplane, and with the standard 15MHZ KDJ11-B
cpu (non-fpj compatible) in slot 3, the system will perform PMI
memory cycles. In the case of BA23 backplanes, a maximum of two
memory modules may be used in slots ahead of the processor, with
a minimum of one memory module in front of the processor still
functioning as PMI memory. In the case of the H9276 backplane
a number of MSV11-JD/JE memory modules may be used ahead of the
processor bringing the system to a full 4MB of PMI memory.
2. If in a Q/eD or BA23 backplane the memories reside in slots 2&3
with either of the KDF11 or KDJ11 processors in the slot 1
the MSVll-J memories will respond as standard Q-bus memories,
performing normal Q-bus and block mode memory cycles. This use
of the MSV11-J memories is also true for the MicroVAX :r cpu.
However the fact that the MicroVAX I cpu is a two
board set
requires a slightly different configuration. Slots 1&2 will be
used for the MicroVAX I cpu boards with only one memory card
used, that being located in slot 3 for the BA23 backplane and
one or more memory cards being used for other Q/eD backplanes.
The only constraint with either of the second configurations is
that in the BA23 or other Q/eD backplanes no module may be
placed adjacent to the MSV11-J that uses pins in the eD
connector. Instead leave an empty slot between the MSV11-~J and
this option. An option which does not use the eD interconnect
may be placed adjacent to the MSV11-J.
MSV11-M
The MSV11-M has two versions;
the MSV11-MA and the MSV11-MB.
The
MSV11-MA (M7506-AA)
is a half populated dual sized Q-bus memory module
which contairts 0.5MB of MOS RAM using 256K parts.
The second version
the MSV11-MB
(M7506-BA)
is a fully populated dual size Q-bus memory
module containing 1MB of MOS RAM using 256K parts.

218

uNOTE # 028
Page 3 of 3

MEMORY COMPARISON TABLE
ATTRIBUTE

MSVll-QA/QB/QC

MSVll-MA/MB

1MB, 2MB, 4MB

0.5MB, 1MB

1MB, 2MB

MSVll-JB/JC/JD/JE

,...

MEMORY SIZE
FORM FACTOR

QUAD

DUAL

QUAD

SYSTEM SIZE

Q18/Q22

PMI/CD

BLOCK MODE

YES

ONLY

(JD/JE ONLY)

1'"-.

BLOCK MODE
CONFIGURABLE

YES FOR REV-A
NO FOR REV-C

AC BUS LOADS

2.4

2.0

2.5

DC BUS LOADS

1.0

0.5

AMPS @ +5 VDC
(ACTIVE ONLY)

QA
QB
QC

TYP
2.4
2.3
2.5

AMPS @ +12VDC

MEMORY ERROR
CORERECTION

MA
MB

NO +12v SUPPLY

WATTS
(ACTIVE ONLY)

MAX
3.99
3.59
4.30

NO
(DEFAULT OPTION)

QA
QB
QC

TYP
12.0
11.5
12.5

MAX
20.95
18.85
22.58

PARITY

MA
MB

TYP
2.19
2.22

MAX
3.11
3.34

NO
(DEFAULT OPTION)

JB/JD
JC/JE

TYP
1.5
1.7

MAX
3.94
4.29

JB/JD
JC/JE

TYP
7.5
8.5

MAX
19.7
21.5

NEEDED
TYP
11.0
11.1

MAX
16.3
17.5

PARITY

ECC

1--.

BATTERY BACKUP
SUPPORT

YES FOR REV-C
NO FOR REV-A

YES

DIAGNOSTICS

CVMSAA FOR PDPlls
EHXMS FOR MICROVAX

SAME
SAME

CVMJAO

MP02053

MP02056

EK-MSV1M-UG

EK-MSV1J-UG

_.
MAINTENANCE
PRINTSET

MP01931

USER GUIDE

EK-MSV1Q-UG

219

220

uNOTE # 029

Title: Q-bus Expansion Concepts

Date: 28-Jun-85

Originator: Charlie Giorgetti

Page 1 of 5

This
MicroNote
discusses
the
expansion
(multiple
backplanes)
characteristics of a Q-bus system. Understanding this topic is critical
when configuring a system. The loading, impedance, and single backplane
characteristics of the Q-bus and some assumptions and definitions are
discussed prior to defining the expansion rules. The specific products
used in expansion are not discussed here.
Viewing the Q-bus for Electrical Analysis
When analyzing the Q-bus from a configuration rule standpoint the bus is
treated as a transmission line. The reasons for this:
o

The Q-bus has voltage sources at both ends of a conductor.

When one of these voltage sources (typically a processor) changes
state (a control/data signal transitioning) its effect is not seen
instantaneously at the other end, but after some propagation delay.
The propagation delay could result in signal reflections on the bus
if it is not properly terminated or expanded.
Loading Definitions

The Q-bus specification defines two loading parameters used when
configuring a system. These parameters, AC and DC loading, indicate the
load presented to the system by individual elements on the Q-bus.
A
system element is either a Q-bus module or a backplane. The definition
of AC and DC loads are:
o

AC loading is the capacitive loading added to a Q-bus system by a
Q-bus module or by the backplane itself. Capacitive loading will
cause bus reflections and impact signal rise and fall times.
This
is measured at the time the module or backplane is being designed.
An AC load is 9.35 pf/signal line.

DC loading is the amount of leakage current presented to the Q-bus
by an undriven signal line on a Q-bus module. This information is
obtained from the specification data for Q-bus
drivers
and
receivers. A DC load is defined as 210 uA.

221

uNOTE # 029
Page 2 of 5
The number of AC and DC loads allowed in a configuration is dictated by
the number of backplanes and the termination used.
This will be
discussed in later sections of this MicroNote.
The AC and DC values for Q-bus modules and backplanes can be found in
either
the Microcomputer Products Handbook
(#EB-26078-41)
or the
Microcomponents Configuration Guide (#EB-27318-68).
Backplane Configurations
The rules that govern Q-bus system implementation must be viewed in
light of the backplane arrangement used.
The two supported Q-bus
configurations are:
single backplane or multiple backplanes.
How the
Q-bus
is
treated as a transmission line varies for these two
configurations and is the foundation for the implementation rules.
Impedance and Termination Characteristics
ThE~ characteristic impedance of the Q-bus
is approximately 120 Ohms.
Therefore, when implementing a system (single or multiple backplane) the
basic configuration is:

Transmission Line Impedance = 120 Ohms
Source Backplane

Destination Backplane
Source (usually the processor)

Far-end termination

Z - Bus Termination with 120 Ohms Characteristic Impedance
S - voltage Source
The transmission line in this diagram could be a single
backplane or multiple backplanes connected with expansion
cables.
Figure 1 - General Q-bus Configuration

222

uNOTE # 029
Page 3 of 5
a-bus Configuration -

Single Backplane

For the single backplane case the transmission line is the length of the
etch runs on the a-bus connector blocks and the backplane printed
circuit board. This orientation has a signal generator at one end (the
processor) and potentially a terminator at the far end of the bus. The
length of the etch runs cannot exceed 14 inches (35.56 cm).
In figure 1
the transmi~sion line is the backplane itself.
A single backplane system does not require termination if there are less
than 20 AC loads.
In this case the signals do not lose their integrity
because the reflections, caused by the mismatched impedances, are not
significant enough to disrupt bus activity. However, in a high ambient
electrical noise environment, system integrity may be further insured by
proper termination.
The single backplane configuration requires termination if the number of
AC loads is 20 or greater. The number of allowable AC loads in this
case is dictated by the termination on the processor.
A 120 Ohm
processor can have up to 45 AC loads. A 240 Ohm processor can have up
to 35 AC loads.
Q-bus Configuration - Multiple Backplanes
For the multiple backplane case (where the multiples are two or three
backplanes), the transmission line is the cables used to interconnect the
multiple backplanes. The expansion cable set consists of:
o

A module in the source backplane

A module in the destination backplane

Cables to connect the two modules

The maximum length of the cables is 16.0 feet (4.88 meters).
The length
of these cables is by comparison significantly longer then the length of
the a-bus connector blocks and the backplane etch used in the single
backplane case. Therefore, onl~r the interconnect cables are considered
for configuration purposes. This arrangement has a signal generator at
one end and requires termination at the far end.
The far end termination must reside in' the last backplane of the
configuration. The location of the far end termination can be any place
in the last backplane, since the backplane etch runs do not enter into
transmission line considerations. The lump sum termination must be 120
Ohms.
The termination in the source box must also be 120 Ohms.
If the
processor is 240 Ohms then the expansion cable set module or the
backplane printed circuit board must have 240 Ohm termination to achieve
the 120 Ohms for the lump sum load.

223

uNOTE: # 029
Page 4 of 5
Lump s~m implies that the 120 Ohms can be achieved by one or more
expans10n module or backplane printed circuit board mounted terminators
and its location is position independent in a given backplane. Figure 2
shows an example of how such a lump sum load can be accomplished.

Expansion Cable from
Source Backplane

Backpla ne
Slot #

Expansion Module
with'Termination (Z1)

Printed Circuit Board
Backplane

<-.->

Lump Sum Termination -

* Z2

Z1 + Z2

Printed Circuit Board
Mounted Termination (Z2)
Figure 2 - Example of Lump Sum Termination in an Expanded Backplane
Figure 1 shows the double backplane configuration where the expansion
cable set is considered the transmission line. The far end termination
is required.
Figure 3 shows the three backplane
configuration.
Backplane #2 in figure 3 for all practical purposes is part of the
expansion cable set when looking at it from an expansion point of view.
The lengths of the expansion cables in multiple box configurations are
strictly specified.
As mentioned the maximum length of the overall
cable is 16.0 feet. The minimum length is 2.0 feet (0.61 meters).
Therefore, in a two backplane configuration the expansion cable must be
between 2.0 and 16.0 feet.
In the three backplane configuration the maximum cable length is still
feet. One of the two interconnect cables must be between 2.0 feet
and 6.0 feet (1.83 meters) in length. The other interconnect cable must
be at least 4.0 feet (1.22 meters) but not longer than 10 feet (3.05
meters). The difference in the two cable lengths must be 4.0 feet.
16.0

224

uNOTE # 029
Page 5 of 5
The cable lengths are specified to insure that any reflections occur
the expansion cables and not in the backplane (if they happen).

The etch runs vn the backplane printed circuit board used in a multiple
backplane cortfiguration must be no longer than 10 inches (25.4 cm). Not
all backplanes used in single configurations can be used in multiple
backplane configurations.
Expansion Cable
#1 to #2

Expansion Cable
#2 to #3

Is I

Iz I

IS I
I

Backplane #1

Backplane #2

Backplane #3

Z - Bus Termination with a Characteristic Impedance
S - voltage Source
Figure 3 - Three Backplane Q-bus Configuration
Multiple backplane configurations
allow
22
AC
loads/backplane.
Therefore,
it is 44 AC loads in a two or 66 AC loads in a three
backplane configuration. To avoid lumping too many AC loads together
the total number of AC loads should be distributed as evenly as possible
over the two or three backplanes.
The entire configuration cannot
exceed 20 DC loads.
In summary,
following the expansion rules insures proper
system
operation.
The set of rules to be followed are dictated by the single
or multiple configuration chosen and the arrangement of the termination
in the system.

225

226

uNOTE # 030

Title:

The Private Memory Interconnect
between the KDJ11-B and the MSV11-J

Originator:

Peter Kent

Date: 28-Jun-85
Page 1 of 9

Purpose
This MicroNote describes the Private Memory Interconnect on
the
MicroPDP-11/83 system.
It is not intended to be a design guide for PMI,
since no devices other than the CPU and memory will make use of it.
General Description
A MicroPDP-11/83 system consists of the KDJ11-B CPU and one or more
MSV11-J memories in a Q-bus backplane. The slots used for the CPU and
memory use the CD interconnect.
In a MicroPDP-11/83 configuration,
the
first 1 or 2 slots in a BA23 backplane (an 8 slot backplane with the
first 3 slots Q/CD) are reserved for MSV11-J memory.
The CPU is put in
the third slot.
The mechanical design of the signal pathways between
the CPU and memory were designed to prevent accidental interference
between the PMI and other device's that might be placed adjacent to the
CPU and memory.
It is possible to have a single 2 Mb board in slot 1
followed by the CPU in slot 2.
putting the CPU after the memory ends
the PMI because the PMI signals from the CD side of the CPU board are
only on the component side of the CPU board.
"Private Memory Interconnect" is the addition of 14 unique signals to
the Q-bus.
These new signals use the CD part of the backplane in a
Q-bus system for communications between the KDJ11-B CPU and one or two
MSV11-J memories. Only the CPU and memory may communicate over this bus
(hence PRIVATE). The Q-bus Data/P.~ddress lines are used for passsing
data and addresses between the CPU and memory.
All other Q-bus
transactions proceed as before.
The PDP-ll/84 Unibus system uses the KTJ11-B Unibus Adaptor,
KDJ11-B
CPU,
and one or two MSVll-J memories.
No Q-bus devices may be
configured with the PDP-11/84 system.
Five of the PMI signals are used
only with Unibus systems. All communications between Unibus devices and
the KTJ11-B occur according to the Unibus protocol.
The KTJ11-B
provides the interface between PMJ: and Unibus protocols. This MicroNote
does not explain the details of the Unibus and PMI interaction.

227

uNOTE I 030
Page 2 of 9
What is PMI?
To understand PMI it is necessary to describe some of the
used by PMI and compare them with ordinary Q-bus cycles.
PMI cycles used in the MicroPDP-ll/83 system:

bus cycles
There are 4

DATI - Data word input.
This cycle is used to read one or more 16
bit words from memory by the cpu.
DATIP - Data word input pause. This cycle is used to read one or
more 16 bit words from memory by the cpu.
It is often used to
perform a read/modify/write cycle.
DATO - Data word ouput.
to memory by the cpu.

This cycle is used to write a 16 bit word

DATOB - Data byte output.
memory by the cpu.

This cycle is used to write a byte to

The KDJ11-B does not perform Block Mode reads or writes with memory.
Certain other Q-bus devices (such as the RDRX1 and RQDX2 controllers and
RQC25) perform Block Mode DMA with MSV11-P,MSV11-Q,AND MSV11-M memories.
The CPU monitors Block Mode transactions to keep its cache in order, but
it has no control over such transfers once it has relinquished control
of the bus to those devices.
REFERENCES
PMI signal definitions are listed at the end of this
MicroNote. All other signal definitions are as given in
the Microcomputer Products Handbook
(EB 26078-41)
or
Microsystems Handbook (EB 26085-41).
TWTBT, a Q-bus signal,
is used somewhat differently during a PMI
transaction than during a normal Q-bus transaction.
See the definitions
section for an explanation of this signal.
NOTE
Few timing relationships are given here because it is
not necessary for a basic understanding of PMI.
The
relationships that are given are a comparison to Q-bus
only.
The prefix "T" refers to bus driver input and "R"
refers to bus receiver
output.
This
helps
to
distinguish between the device which issues a particular
signal and that of the receiver of the signal.
If the
prefix "B" is used, it denotes a general term for the
signal on the bus without regard for its timing relation
with respect to sender or receiver (i.e. BSYNCH).

228

uNOTE # 030
Page 3 of 9
Address part of cycle
The address portion of the MicroPDP-11/83 PMI cycles is the same for all
4 PMI cycles.
It is listed here first and the description of the other
cycles follow.
1.

For the first part of the cycle, the CPU gates ADDR, BBS7
(if the
I/O page is referenced),
TWTBT, and TPBYT onto the Q-bus.
The
combination of TWTBT and TPBYT (PMI signal) determine what type of
PMI transaction will take place - see Table 1 below. These signals
are asserted for a brief period after the assertion of TPBCYC.
Table 1
BWTBT L

PBYT L

Description

H
H
L
L

H
L
H
L

. DATI or DATBI Cycle
DATIP Cycle
DATO Cycle
DATOB Cycle

As noted above, Q-bus signals such as TWTBT are used differently
during a PMI cycle. TWTBT is not normally used during a DATI cycle,
for example.
2.

Next, memory issues TPSSEL after receiving RADDR and RBS7.
The CPU
receives RPSSEL.
This part of the cycle indicates that the memory
is responding.

If the CPU was the previous bus master and the previous cycle was a
Q-bus cycle,
then the CPU must not assert TPBCYC or TSYNC until
after the negation of TSYNC and after the negation of RRPLY.
If the
cycle was an interrupt service cycle, then the CPU must wait until
after the negation of RRPLY.
This stipulation allows for other
Q-bus devices equal access to the bus. Also, if another
Q-bus
device was previously bus master, then the CPU must not asssert
TPBCYC or TSYNC until after the negation of RSYNC - this is to make
sure RRPLY is negated long enough as per Q-bus protocol.

Now, if RPSSEL is asse~ted and if RPUBMEM is negated, the PMI master
proceeds with a PMI cycle. The negation of RPUBMEM indicates no
that no Unibus memory is responding - in other words a Q-bus PMI
cycle.
Here is where the diffe- rence between Q-bus cycles and PMI
cycles becomes visible.

229

uNOTE # 030
Page 4 of 9
5.

The CPU asserts TPBCYC after gating TADDR, TBS7, TPBYT, and TWTBT
onto the bus.
The PMI master continues to gate TADDR, TBS7, and
TWTBT after the assertion of TPBCYC.

If at this point RPSSEL is negated, the
normal Q-bus cycle.

This describes the address portion of
systems.

the

system
PMI

will

cycle

revert

for

Q-bus

only

DATI
When the CPU (KDJ11-B) is accessing memory for a PMI Data In Cycle, it
transfers 2 words. This takes advantage of the KDJ11-B restart overhead
to load a second 16-bit word into the cache on the CPU module.
Listed
below equivalent Q-bus cycles are compared with PMI cycles under "Timimg
Comparisons". For the read cycle, 2 data words (one after another) are
latched into the MSV11-J data gate array and both words are placed on
thf~ bus.
Interestingly enough, either word may be selected to be placed
on the bus first.
If the odd wo~d is placed on the bus first, it is
followed by the preceding even word. For example, if a word at address
17362 is selected to be placed on the bus first, the next word
transferred will be from address 17360. If the even word is selected to
be placed on the bus first, the next odd word is then transferred
second. For example, if a word at address 17360 is selected to be
placed on the bus first, the next odd word is then transferred second.
For example, if a word at address 17360 is selected to be placed on the
bus, the next word transferred will be at address 17362.
Using the MSV11-J memory as a normal Q-bus memory (disabling the PMI by
putting it after the CPU in the bus) and performing a read cycle, 2
words will be latched into the data gate array. However, only one word
is placed on the Q-bus.
1.

At this point the address portion of the cycle is over.
gates TDATA onto the bus after the assertion of RPBCYC.

Immediately after RPBCYC
TPHBPAR and TPLBPAR.

Memory asserts TPRDSTB immediately after the reception of RPBCYC.

The strobe signal TPRDSTB is negated by memory after
of RPBCYC.

The memory gates the second data word onto the bus after TPRDSTB is
negated.
Shortly after the parity in- formation is sent. Another
advantage is realized here: the second data word is transmitted
without the need of any further signals between the CPU and memory.

the

230

memory

enables

the

The

memory

parity

signals

the

reception

uNOTE # 030
Page 5 of 9

If the CPU has read 2 words, it negates TPBCYC
second data word.

After the negation of RPBCYC memory removes TDAT from the bus.

after

latching

the

It becomes evident that there is an essential difference between normal
Q-bus transactions and PMI transactions. Q-bus transactions are all
based on handshaking. During a DATI Q-bus transaction,
the memory
responds with BRPLY after BDIN from the processor. There must be the
signal between each device that the transaction has taken place. During
a PMI DATI transaction, there is only a strobe signal from the memory
saying that it is ready for the data. The only further communication
between the memory and CPU is the actual data transfer. Only upon the
transmission of the second possible data word is parity information sent
along with the second data word. No other memory-CPU signalling occurs.
KDJ11-B

MSV11-J

Address Memory
o Gate Address
onto Address Lines
o Combination of
TPBYT and TWTBT
result in DATI Cycle
o Assert BBS? if Address
is in I/O page
PMI Cycle Assertion

Decode Address
~-------

<--------~

o TPSSEL asserted shows
Memory is Selected

-----l

o TPBCYC Indicates PMI Cycle
deasserts Address, BBS?
TPBYT,TWTBT Signals
Address part of
cycle is finished

PMI Cycle End

<_ _

o CPU deasserts TPBCYC
to end PMI Cycle

~------>

J
lL.....--_>

231

Data
o TDATA, TPHBPAR, TPLBPAR
(Data and Parity) is
asserted onto Data Lines
o Memory strobes CPU by
Asserting TPRDSTB to tell
CPU Data is on the Bus
o The strobe signal
TPRDSTB is deasserted
o The 'second data word and
parity info are put on
the Data Lines
Data
o Memory removes
data from Bus

uNOTE # 030
Page 6 of 9
Timing Comparisons
At this point it would be interesting to make some timing comparisons
between Q-bus and PMI DATI transactions.
Considering a Q-bus DATI
transaction, the cycle time
(timing from BSYNCH to TRPLY ignoring
addressing time) is 510 ns for MSV11-M.
The MSV11-M was chosen because
its cycle time does not include the ECC overhead of the MSV11-J. Add to
this 320 ns access time and this totals 830 ns to transfer 1 word from
memory to cpu. Now, if 2 words are to be transferred in this manner,
add another 300 ns due to delay between RRPLY and TSYNCH in order for
other Q-bus devices access to the bus. This results in 1130 ns total
for a 2 word transfer using MSV11-M parity memory.
Th.~

MSV11-J memory access time is 417 ns.
This is the time from RPBCYC
PRDSTB.
Fifty eight ns later, at the trailing edge of PROSTB, the
cpu receives the second data word. This means that PMI is approx.
2.5
times faster than Q-bus on 2 word reads from memory to cpu. Remember,
this also accounts for the time the ECC requires to do its modified
Hamming code versus the MSV11-M parity check.
For each 18 bits of
MSV11-J memory there are 6 bits used for ECC.
This accounts for the
space needed on the MSV11-J for 2 Mb of memory whereas 4 Mb is possible
on the MSV11-Q on the same size board.
to

DATO (DATOB)

The CPU uses DATO to transfer a single word (or byte for a DATOB cycle)
to memory.
The address portion of the cycle is the same as for the DATI
and is described above.
1.

The CPU determines what type of cycle (DATO or DATOB) by logically
combining TWTBT and TPBYT. During the address portion of the cycle,
these signals were used to indicate which type of PMI cycle was
selected.

Memory asserts TRPLY after RPBCYC.

After the assertion of TPBCYC, data is gated onto

The CPU asserts TPWTSTB after data is gated onto the bus.

Memory asserts TPSBFUL after RPWTSTB.

The CPU deasserts TPBCYC after negating TWTSTB.

The memory waits before it can accept another PMI
cycle) - then it deasserts TRPLY.

cycle

(or

Q-bus

Memory negates TPSBFUL before it can accept another
cycle).

PMI

(or

Q-bus

cpu.

232

the

bus

the

uNOTE .. 030
page 7 of 9
KDJll-B

MSVll-J

Address Memory
o Gate Addresses onto
Address Lines
o Combination of TPBYT
and TWTBT Result in
DATO Cycle
o Assert BBS7 if Address
is in the I/O page
PMI Cycle Assertion

lll---_>
<------~

o TPSSEL Shows
Memory is address
selected

--l

Memory Responding

o Assertion of TPBCYC
indicates PMI Cycle
o CPU deasserts Address, BBS7,
TPBYT, TWTBT Signals Address Portion of Cycle
is finished

'----->

Data
o TDATA, TPHBPAR, TPLBPAR
(Data and Parity) is put
onto the Data Lines
o CPU then strobes the
Memory by asserting TPWTSTB

PMI Cycle End

Decode Address

Reception of Data

-,'------>

<---------~

o CPU deasserts TPBCYC
to indicate current
PMI Cycle is finished

o After reception of
RPBCYC, memory sends
TRPLY to CPU

o Memory asserts TPSBFUL
after reception of
RPWTSTB

Memory Cycle End

1 . . . ___ >

233

o Memory waits for other
devices to claim Bus
before it can accept
another PMI Cycle - then
deasserts TRPLY
o Memory must negate
TPSBFUL before another
PMI Cycle can begin

uNOTE # 030
Page 8 of 9
Timing Comparisons
Here is a comparison of a Q-bus DATO cycle with a PMI DATO cycle.
Looking at a Q-bus DATO transaction, the cycle time (timing from RSYNCH
to TRPLY) for MSV11-M is 550 ns.
Comparing this to the MSV11-J DATO
cycle,
the result of 223 ns is obtained. This figure is arrived at as
follows:
38 ns access time for the memory + 80 ns TPBCYC to TDATA + 75
ns TPWTSTB after data is on the bus + 30 ns to hold TPWTSB. Again the
speed advantage of PMI transactions over normal Q-bus transactions is
about 2.5 to 1.
DATIP
The PMI Data In Pause cycle is identical to the DATI cycle except that
TPBYT
is
asserted with TADDR to indicate that the next cycle
(immediately following the current cycle) will-be a data out cycle to
the same address.
PMI and Q-bus signal definitions
Eight of the PMI signals are used in an MicroPDP-11/83 system, therefore
only those will be defined here. One Q-bus signal, BWTBT, is defined
h.~re
because it is used differently than
during
normal
Q-bus
transactions.
PBYT L

PMI Byte. When the CPU gates address onto the bus, it asserts
this signal with BWTBT to indicate the type of bus cycle (see
Table 1 above).

PBCYC L

PMI bus cycle.
The CPU asserts this signal at the start of
a PMI cycle and negates it at the end of that cycle.

PRDSTB L

PMI read strobe. Memory asserts and negates this signal to
control data transfers during DATI cycles. The CPU latches
the received first word data on the negating edge of this
signal.
The second word is latched after that without further
signalling.

PWTSTB L

PMI Write Strobe. The CPU asserts this signal after gating
data onto the bus. The memory latches the data into its
write buffer after the leading edge of this pulse.

PSSEL L

PMI slave selected. Memory asserts this signal whenever it
decodes its address on the Q-bus.

234

uNOTE # 030
Page 9 of 9
PHBPAR L

PMI high byte data parity.
This signal is generated by PMI
memory during DATI cycles and provides odd parity for the high
byte data on the Q-bus.

PLBPAR L

PMI low byte data parity.
This signal is generated by PMI
memory during DATI cycles and provides even parity for the low
byte data.

PSBFUL L

PMI memory buffer full.
Memory asserts this signal during a
write cycle indicating that its write buffer is full and that
it cannot respond to another cycle request.
Q-bus signal

this
BWTBT L write byte (PMI write indication).
In Q-bus systems,
the
signal is used for Q-bus write cycles.
For PMI transactions,
cycle.
CPU gates this signal with PBYT to indicate the type of
PMI
See Table 1 above.
References
Microcomputer Products Handbook
Microsystems Handbook
MSVll-M User Guide
MSVll-Q User Guide
MSVll-J User Guide

235

EB-26078-41
EB-26085-41
EK-MSV1M-UG-OOl
EK-MSV1Q-UG-002
EK-MSV1J-UG-OOl

236

uNOTE # 031

Title: MSV11-QA Revision Differences

Date: 28-JUN-85

Originator: Jack Toto

Page 1 of 9

Digital Equipment Corporation recently announce the addition of three
memories for the Q-bus space; the MSV11-QA quad module at 1MB, the
MSV11-QB quad module
at 2MB, and the MSV11-QC quad module at 4MB.
Earlier versions of the MSV11-QA were shipped using a
revision A etch
and the
documentation correctly showed the jumper
configurations.
However early in 1985 the MSV11-QA/QB/QC started shipping with revision
C etch.
The documentation at that point did not show how to properly
configure the C etch.
It is the intent of this MicroNote to point out
the differences between the two modules and to explain the configuration
of both the etch revisions.
The two modules can
in the table below;

be identified

in anyone of the three ways listed

1. The location and value of the modules serial number.
2. The location of CSR and address jumpers and switches.
3. The module's designation number, stamped on the insertion
handles will be different.
3A. Revision A modules will be labeled M7551-AA.
3B. Revision C modules will be labeled M7551-AA.
SERIAL NUMBER LOCATION
The two modules can be identified by the location of its serial number.
The revision A module will have its serial number located in the upper
right hand corner of the module as you hold it with the fingers pointing
down or at you and the component side facing you or up as it would lay
on a work bench. This serial number will be 5017547A1. The location of
the serial number for revision C module will be on the component side
also, but in the upper left hand corner. This
serial
number
will
be 5017547-01-C1. The attached diagrams of the revision A and revision
C modules show the location of these numbers.

237

uNOTE # 031
Pag 2 of 9
JUMPER LOCATION
The MSV11-QA revision A module allows for the selection of Block Mode
DMA transfers, parity detection, and extended address parity error
detection as well as CSR and address selection. The address selection
includes two switches, one for the modules starting address and one
for the modules ending address. The ending address switch is used to
control the decode logic on the module as the same etch is used for 2MB
and 4MB boards as well, each with different value memory chips to reach
there designed capacity.
The location and function of these switches
and jumpers if
detailed in the diagrams and configuration
tables
attached to the end of this MicroNote.
The MSV11-QA revision C module does not allow for the selection of Block
Mode DMA or for the selection of parity detection, these features
are built into the module itself and can be used or not used through
hardware/software compatibility. When used in a system that supports
Block Mode the MSV11-QA will perform as a Block Mode device, when used
in a non Block Mode system it will perform as a normal memory module
without any decrease in that system's performance. When used with
software such as RSX11 and using mixed
parity/non-parity memories
parity detection can be disabled through sysgen. The only functions
that a user is required to configure to use the MSVll-QA revision C is
CSR selection and starting and ending address.
It should be pointed out
that the two switches for starting and ending addresses. have been flip
flopped from the positions in which they were located on the revision A
module. Once again refer to the diagrams and configuration tables
attached to this MicroNote for location and function of these switches
and jumpers.
The following pages contain diagrams and tables for configuring the two
versions of the MSVll-QA

238

uNOTE # 031
Page 3 of 9
MSV11-QA revision A Module Identification

5017547A1 <--------+- PRINTED CIRCUIT
BOARD NO.

(COMPONENT SIDE)

(A) MSV11-QA (ETCH revision A ONLY)

MSV11-QA revision A CSR SELECTION
NUMBER OF
MEMORY MODULE
1ST
2ND
3RD
4TH
5TH
6TH
7TH
8TH
9TH
10TH
11TH
12TH
13TH
14TH
15TH
16TH

JUMPER POSITION
R
P
N
IN
OUT
IN
OUT
IN
OUT
IN
OUT
IN
OUT
IN
OUT
IN
OUT
IN
OUT

IN
IN
OUT
OUT
IN
IN
OUT
OUT
IN
IN
OUT
OUT
IN
IN
OUT
OUT

239

IN
IN
IN
IN
OUT
OUT
OUT
OUT
IN
IN
IN
IN
OUT
OUT
OUT
OUT

CSR REGISTER
ADDRESS

IN
IN
IN
IN
IN
IN
IN
IN
OUT
OUT
OUT
OUT
OUT
OUT
OUT
OUT

17772100
17772102
17772104
17772106
17772110
17772112
17772114
17772116
17772120
17772122
17772124
17772126
17772130
17772132
17772134
17772136

uNOTE =I 031
Page 4 of 9
MSV11-QA revision A STARTING AND ENDING ADDRESS
DESIRED
STARTING
ADDRESS

SW1
SWITCH
POSITION

IN KBYTE

12345

00000
11111
01111
10111
00111
11011
01011
10011
00011
11101
01101
10101
00101
11001
01001
10001
00001
11110
01110
10110
00110
11010
01010
10010
00010
11100
01100
10100
00100
11000
00010
10000

128
256
384
S12
640
768
896
11024 (1MB)
1152
1280
1408
lS36
1664
1792
1920
21048 (2MB)
2176
2.304
2432
2S60
2688
2816
2944
3072 (3MB)
3200
3.328
3456
3!584
3712
3840
3968
1

SW2
SWITCH
POSITION
6

o
1
1

1
1
1
1
1
1
1
1
1
1
1
1

1
1

1
1
1
1
1
1

1
1
1
1

1
1
1
1
1

STARTING
ENDING
ADDRESS

ENDING
SWITCH
POSITION

IN KBYTE

12345

128
256
384
512
640
768
896
1024
1152
1280
1408
1536
1664
1792
1920
2048
2176
2304
2432
2560
2688
2816
2944
3072
3200
3328
3456
3584
3712
3840
3968
4096

11111
01111
10111
00111
11011
01011
10011
00011
11101
01101
10101
00101
11001
01001
10001
00001
11110
01110
10110
00110
11010
01010
10010
00010
11100
01100
10100
00100
11000
01000
10000
00000

(1MB)

(2MB)

(3MB)

(4MB)

off position (open)
position (closed)

o = on

NOTE: Switch S6 of SW1 is not used.
For a memory starting address of
0, switch S6 of SW2 should be set to 0 (on).
For all other
starting addresses S6 of SW2 should be off (1).

240

uNOTEI: 031

Page 5 of 9

MSV11-QA revision A

5017547A1

PARITY - - - )
LED

~; <

D
D

CSR REGISTER
SELECTION

ENABLE/DISABLE
CSR SELECTION
th

1
2
3
4
5
6

(COMPONENT SIDE)

<--------+_ STARTING ADDRESS
SWITCHES
(S6 NOT USED)
ENABLE/DISABLE
BLOCK MODE

OFF ON

ENABLE/DISABLE
EXTENDED
ERROR ADDRESS

<---+- ENDING ADDRESS

1
2
3
4

SWITCHES

5
6
OFF ON
+5V

[]JJ <

ENABLE PARITY
ERROR DETECTION

<_J_H_ _+-

NOT USED, MODULE
DOES NOT SUPPORT
BATTERY BACKUP

+5VB
D

Jumper and Switch Locations
(Drawing not to scale)

24·1

uNOTE # 031
Page 6 of 9
MSV11-QA revision C Module Identification

PRINTED CIRCUIT -+--------> 5017547-01-C1
BOARD NO.

(COMPONENT SIDE)

•

( B ) MSV11-QA (ETCH revision C OR LATER)
MSV11-QB AND MSV11-QC
(Drawings not to scale)
MSVI1-QA revision C CSR SELECTION
NUMBER OF
MEMORY MODULE

JUMPER POSITION
J5
J7
J9
J11

1ST
2ND
3RD
4TH
5TH
6TH
7TH
8TH
9TH
10TH
11TH
12TH
13TH
14TH
15TH
16TH

IN
OUT
IN
OUT
IN
OUT
IN
OUT
IN
OUT
IN
OUT
IN
OUT
IN
OUT

IN
IN
OUT
OUT
IN
IN
OUT
OUT
IN
IN
OUT
OUT
IN
IN
OUT
OUT

IN
IN
IN
IN
OUT
OUT
OUT
OUT
IN
IN
IN
IN
OUT
OUT
OUT
OUT

242

IN
IN
IN
IN
IN
IN
IN
IN
OUT
OUT
OUT
OUT
OUT
OUT
OUT
OUT

CSR REGISTER
ADDRESS
17772100
17772102
17772104
17772106
17772110
17772112
17772114
17772116
17772120
17772122
17772124
17772126
17772130
17772132
17772134
17772136

uNOTE # 031
Page 7 of 9
MSV11-QA revision C STARTING AND ENDING ADDRESS
DESIRED
STARTING
ADDRESS

SW2
SWITCH
POSITION

IN KBYTE

12345

00000
11111
01111
10111
00111
11011
01011
10011
00011
11101
01101
10101
00101
11001
01001
10001
00001
11110
01110
10110
00110
11010
01010
10010
00010
11100
01100
10100
00100
11000
00010
10000

1,,~8

2'~,6

384
512
640
768
896
1024 (1MB)
1152
1280
1408
1536
1664
1792
1920
2048 (2MB)
2176
2304
2432
2560
2688
2816
2944
3072 (3MB)
3200
3328
3456
3584
3712
3840
3968

SW1
SWITCH
POSITION

STARTING
ENDING
ADDRESS

ENDING
SWITCH
POSITION

IN KBYTE

12345

0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1

128
256
384
512
640
768
896
1024
1152
1280
1408
1536
1664
1792
1920
2048
2176
2304
2432
2560
2688
2816
2944
3072
3200
3328
3456
3584
3712
3840
3968
4096

11111
01111
10111
00111
11011
01011
10011
00011
11101
01101
10101
00101
11001
01001
10001
00001
11110
01110
10110
00110
11010
01010
10010
00010
11100
01100
10100
00100
11000
01000
10000
00000

(1MB)

(2MB)

(3MB)

(4MB)

1 - off position (open)
o =- on position (closed)
NOTE: 5witch 56 of 5W2 is not used. For a memory starting address
of 0, switch S6 of SW1 should be set to 0 (on) . For all other
starting addresses 56 of 5Wl should be off (1).

243

uNOTE # 031
Pa<:re 8 of 9
MSVI1-QA revision C

5017547-01~Cl

CSR REGISTER
SELECTION

SW2
1
2
3
4
5

STARTING ADDRESS
SWITCHES
(S6 NOT USED)

(COMPONENT SIDE)
SWI
1
2
3
4
5
6

L_
Jumpers and Switches
(Drawing not to scale)

244

0
0
0
0

ENDING ADDRESS
SWITCHES

0
0
0

BATTERY BACKUP
JUMPERS

uNOTE # 031
Page 9 of 9
COMPARISON OF SIMILAR FUNCTION JUMPERS

JUMPER
FUNCTION

SELECTABILITY
REV-A
REV-A

ENABLED
CONFIGURATION

DISABLED
CONFIGURATION

DISABLE
BLOCK MODE

YES

Wi IN (Jii TO J12)
W2 OUT

W2 IN (Jii TO J10)
W1 OUT

DISABLE
PARITY
MEMORY

YES

JUMPER B IN
(J14 TO 13)
JUMPER A OUT

JUMPER A IN
(J14 TO J5)
JUMPER BOUT

DISABLE
PARITY
DETECTION

YES

JUMPER H IN
(J2 TO J3)
JUMPER GOUT

JUMPER G IN
(J1 TO J2)
JUMPER H OUT

DISABLE
22-BIT
ADDRESSING

YES

JUMPER L IN
(J8 TO J7)
JUMPER K OUT

JUMPER K IN
(J8 TO J9)
JUMPER LOUT

BATTERY'
BACKUP
SUPPORT

YES

W3 AND Wl IN
WITH
W4 AND Wl OUT
(revision CONLY)

W4 AND Wl IN
WITH
W3 AND W1 OUT
(revision CONLY)

BATTERY BACKUP
CONFIGURATION

NOTE: JUMPERS W4 AND W2 ARE LOCATED BETWEEN E21 AND
E13 IN THE LOWER RIGHT HAND CORNER OF THE
COMPONENT SIDE OF THE MODULE.
FOR THE ACTUAL
LOCATION OF THESE AND ALL OTHER JUMPERS PLEASE
REFER TO THE USERS GUIDE.

245

246

uNOTE,

KXTll-C Parallel I/O Programming

Title:

Originator:

Scott Tincher

* 032

Date: 28-JUN-85
Page 1 of 42

The KXT11-CA is a single board computer that provides the user with
flexible I/O programming options.
One of the onboard programmable
devices is a 20 line parallel I/O port (PIa). This note will describe
the operation of the PIa and will provide some programming examples.
Since the DIGITAL operating system MicroPower/Pascal provides a device
handler for the PIa, the programming examples included in this note will
be written in MACRO-ll for the user who wishes to program the PIa in
MACRO-ll.
The example programs assume the user is familiar with the
KXT11-C Software Toolkit for RT-ll or RSX.
FEATURES/CAPABILITIES
The PIO of the KXTll-C supplies the following features:
o

Two 8-bit, double buffered, bidirectional I/O ports

A 4-bit special purpose I/O port

Four handshake modes

REQUEST signal for utilizing the DMA controller

Pattern recognition logic

Three independent l6-bit counter/timers

The two 8-bit ports (A and B) are identical except that Port B can
provide external access to Counter/Timers 1 and 2.
Each port may be
configured under program control as a single or double buffered port
with handshake logic or as a bit port for control applications.
Pattern
recognition logic is also included in each port.
This logic allows
interrupt generation whenever a specific pattern is recognized.
Ports A
and B may be linked to form a l6-bit port with handshake.
When Port A o~ B is used as a port with handshake the control lines are
supplied by a special 4-bit port (Port C).
If no handshake lines are
required then Port C may be used as a bit port.
Port C also provides
external access to Counter/Timer 3 and a REQUEST line that allows the
PIO to utilize the DMA controller when transfering data.

247

uNOTE # 032
Page 2 of 42
Th4! PIO supplies three identical
16-bit
Counter/Timers.
These
Counter/Timers operate at a frequency of 2 MHz which provides a
resolution of 500 ns. Each Counter/Timer may operate with one of three
output duty cycles: pulse, one-shot, or square-wave. In addition, each
unit may operate as retriggerable or non-retriggerable.

•

The following section provides a brief description of the
tht:r! PIO.

registers

MASTER CONTROL REGISTERS
Tht:r!re are two registers that control the overall function of the PIO,
the Master Interrupt Control Register and the Master Configuration
Control Register.
Master Interrupt Control Register
7

Address - 177000
Bit 7:

Master Interrupt Enable (MIE)

o - Inhibits this device from requesting an interrupt or

responding to an interrupt acknowledge.
1 - Allows interrupt logic to operate normally.
Bits 6,5,4,3,2,1:
Bit 0:

These bits must be programmed to zero.

Reset

o - Clears the reset bit and allows the other registers to

function properly.
1 - Resets the device. While this bit is 1 reads of other
registers will be 0 and writes to other registers will be
ignored. This bit is cleared only by writing a 0 to the
RESET bit.

248

uNOTE # 032
Page 3 of 42
Master Configuration Control Register
2

Address - 177002
Bit 7:

Port B Enable (PBE)

Inhibits Port B from issuing an interrupt request and forces
tth Port B I/O lines into a high impedance state.
1 - Allows Port B to operate normally.
Bit 6:

Counter/Timer 1 Enable (CT1E)

Inhibits Counter/Timer 1 from issuing an interrupt request
and clears the Count In Progress (CIP) flag. All trigger
inputs are ignored.
1 - Allows Counter/Timer 1 to operate normally.
Bit 5:

Counter/Timer 2 Enable (CT2E)
Provides the same functions for Counter/Timer 2 that CT1E does
for Counter/Timer 1.

Bit 4:

Port C and Counter/Timer 3 Enable (PCE) and (CT3E)
Provides the same functions for Port C that PBE does for Port B
and the same functions for Counter/Timer 3 that CT1E does for
Counter/Timer 1.

Bit 3:

Port Link Control (PLC)

o - Allows Ports A and B to operate independently.
1 -

Bit 2:

Links Ports A and B to form a 16-bit port. In this mode
Port A's handshake and command and status registers are
used. Port B is specified as a bit port. This bit must be
set before the ports are enabled.

Port A Enable (PAE)
Provides the same functions for Port A that PBE provides for
Port B.

Bits 1,0:

Counter/Timer Link Controls

These two bits specify how Counter/Timers 1 and 2 are linked
according to the following table:

249

uNOTE # 032
page 4 of 42
Bit 1

Bit 0

o
1
o

1
1

Counter/Timers
CIT l's output
CIT l's output
CIT l's output

are independent
(inverted) gates CIT 2
(inverted) triggers CIT 2
(inverted) is CIT 2's count input

The Counter/Timers must be linked before they are enabled.
PORT SPECIFICATION REGISTERS
Ports A and B both utilize the following port specification registers:
Port Mode Specification Register
3

Port A = 177100
Port B = 177120
A RESET forces all of these bits to O.
Bits 7,6:

All bits are read/write.

Port Type Select

These two bits specify the port type as defined by the
following table:
Bit 7

o
o

1
1

Bit 5:

Bit 6

o
o

Bit port (No handshake)
Input port with handshake
output port with handshake
Bidirectional port with handshake

Interrupt on Two Bytes (ITB)

o - Indicates that Interrupt Pending (IP) should be set when

one byte of data is available for transfer.
For an input
port IP is set when the Input Data Register is full.
For an
output port IP is set when the Output Data Register is
empty.
1 - Indicates that IP should be set when two bytes of data are
available for transfer.
For an input port IP is set when
both the Input Data Register and the Input Buffer Register
are full.
For an output port IP is set when both the Output
Data Register and the Output Data Buffer are empty.
This bit must be set to zero for ports specified as bit
ports, single-buffered ports, or bidirectional ports.

250

uNOTE # 032
Page 5 of 42
Bit 4:

Single Buffered (SB)

o - Indicates that the port is double-buffered.

1 -

Indicates the the port is single-buffered.

This bit is always 0 for bit ports.
Bit 3:

Interrupt on Match Only (IMO)

o - Port operates normally.

1 - An interrupt is generated when the data moved into the Input

Data Register or out of the Output Data Register matches the
pattern specification.
Bits 2,1:

Pattern Mode Specification Bits

These bits define the operation of the pattern recognition logic
as shown by the following table:
Bit 2

o
o

1
1

Bit 0:

Bit 1

Disable Pattern Match
AND Mode
OR Mode
OR-Priority Encoded vector Mode

Latch on Pattern Match (LPM) or Deskew Timer Enable (DTE)
When a port is used as a bit port the LPM function is used.
When a port with handshake is used the DTE function is used.
LPM:

o - Pattern matches are detected but the data read from the port

follows the port pins.
1 - When a pattern match is detected the input data at the port
is latched.
DTE:

o - The deskew timer is not activated.
1 - The deskew timer is activated to perform delay functions as
set in the Port Handshake Specification Register.

Port Handshake Specification Register
3

Port A == 1 77102
Port B -- 177122

251

uNOTE :I 032
Page 6 of 42
These bits are ignored if the port is a bit port.
bits to O. All bits are read/write.
Rits 7,6:

A RESET forces all

Handshake Type Specification Bits

These bits define the type of handshake a port will use as shown
by the following table:
Bit 7

o
o

Bit 6

o
o

Interlocked Handshake
Strobed Handshake
Pulsed Handshake
3-Wire Handshake

The Pulsed and 3-Wire Handshakes must not be specified for
bidirectional ports. Only one port at a time may use the Pulsed
Handshake. If one port uses the 3-Wire Handshake the other port
must be specified as a bit port.
Bits 5,4,3:

REQUEST/WAIT Specification Bits (RWS)

The WAIT function is not implemented on the KXT11-C. These bits
define the utilization of the REQUEST line as shown by the
following table:
Bit 5
0
0
0
1
1
1

Bit 4
0
0
1
0
0
1

Bit 3
0
1
1
0
1
1

REQUEST disabled
Not supported
Not supported
Special REQUEST
Output REQUEST
Input REQUEST

Only Port A may use the REQUEST capability - Port B must be
programmed as a bit port.
Bits 2,1,0:

Deskew Time Specification Bits

These bits specify the amount of deskew time to be provided for
output data. They define the minimum number of Peripheral Clock
(PCLK) cycles of delay between the output of a new byte of data
and the handshake logic indicating that new data is available.
PCLK - 250 ns. 0 PCLK cycles are chosen by setting DTE-O in the
Port Mode Specification Register.

252

uNOTE # 032
Page 7 of 42
Bit 1
0
0
1
1
0
0
1
1

Bit 2
0
0
0
0
1
1
1
1

Bit 0
0
1
0
1
0
1
0
1

PCLK cycles
2

4
6

8
10
12
14
16

Port Command and status Register
7

I5 I4

Port A - 177020
Port B - 177022
A RESET forces ORE to 1 and all other bits to O.
readable and four are writeable.
Bit 7:

Interrupt Under Service

All bits are

(IUS)

o - Cleared to indicate that the port is not servicing an

interrupt.
1 - Indicates that that the port has been recognized by an
interrupt acknowledge sequence.
Bit 6:

Interrupt Enable (IE)

o - Interrupt logic disabled.

The port is unable to request an
interrupt or to respond to an interrupt acknowledge.
1 - Interrupt logic operates normally.
Bit 5:

Interrupt Pending (IP)

o - Cleared to indicate that the port does not require service.
1 - Set to indicate the port needs service because of a pattern
match, a handshake, or an error.
Bits 7, 6, and 5 are written using the following codes:

253

uNOTE # 032
Page 8 of 42
Bit 7

Bit 6
0
0
0
0

1
1
1
1

Bit 4 :

Bit 5
0
0

1
1

0
0

1
1

0
0
0

Null code
Clear IP and IUS
Set IUS
Clea r IUS
Set IP
Clear IP
Set IE
Clear IE

Interrupt Error (ERR)

This bit is set to 1 when using a a bit port with pattern match
enabled if a second match occurs before the previous match is
acknowledged. This is a read-only bit.
Bit 3:

Output Data Register Empty (ORE)

A status bit that indicates when an output port's Output Data
Register is empty. This bit can only be cleared by writing to
the data register. This is a read-only bit.
Bit 2:

Input Data Register Full (IRF)

A status bit that indicates if an input port's Input Data
Register is full. This bit can only be cleared by reading the
Input Data Register. This is a read-only bit.
Bit 1:

Pattern Match Flag (PMF)

If the port pattern match logic is enabled this bit will
indicate when a match is detected. This bit is read-only.
Bit 0:

Interrupt on Error (IOE)

o - Disables the generation of an interrupt if an error occurs

within the pattern match logic.
1 - Enables the generation of an interrupt if an error occurs
within the pattern match logic.
This bit is valid only for bit ports with pattern match logic
enabled. It is ignored by ports with handshake and should be
programmed to O.
BIT PATH DEFINIT~N REGISTERS
Each port has a set of these registers.
bits are valid in the port C registers.

254

Only the four least significant

uNOTE
032
Page 9 of 42
Data Path Polarity Registers
These registers define whether the bits in a port are inverting or
non-inverting.
These bits are cleared by a RESET and are read/write.

Port A = 177104
Port B = 177124
Port C = 177012

o - Non-inverting
1 =- Inverting
Date Direction Registers
These registers are ignored by ports with handshake.
For bit ports
they define the data direction for each bit. These bits are cleared
by a RESET and are read/write.
7

Port A =- 177106
Port B = 177126
Port C =- 177014

o =- Output bit
1 == Input bit
Special I/O Control Registers
These registers supply special characteristics to the port's data
paths. A RESET clears all bits to O. All bits are read/write.
7

I5 I4 I3 I2 I1
Port A = 177110
Port B = 177130
Port C = 177016

0 = Normal Input or Output
1 = Input with l's catcher

255

uNOTE: # 032
Page 10 of 42
PATTERN DEFINITION REGISTERS
These registers are used collectively to specify the match pattern for a
port. A RESET clears all bits to O. All bits are read/write .
Pattern Polarity Registers (PPR)
3

Port A - 177112
Port B - 177132
Pattern Transition Registers (PTR)
3

Port A - 177114
Port B = 177134
Pattern Mask Registers (PMR)

Port A = 177116
Port"B -= 177136
The pattern specification for each bit is shown in the following
table:
PPR

PTR

PMR

1
1

o
1
o
o

o
o
o
1
o

o
o

Bit masked off
Any transition
Zero
One
One to zero transition
Zero to one transition

PORT DATA REGISTERS
Ports A and B have a data path that consists of three registers: an
Input Data Register, and Output Data Register, and a Buffer Reqister.
The Buffer Register is used to buffer the input or output data of a port
with handshake.
It is also used by bit ports to latch data whE~n pattern
matching is enabled.

256

uNOTE # 032
Page 11 of 42
Port A and B Data Registers
7

Port J\. == 177114
Port B == 177134
The Port C data register consists of two registers:
an Input Data
register and an Output Data register. Because Port C is only 4 bits
wide the least significant four bits of the data register are used for
the data path. The four most si9nificant bits are used as a writeprotect mask for the four least significant bits.
Port C Data Register

I I I I4 I3 I I1 I0 I
7

,..

;j
Bits 7,6,5,4:

,..

0 == writing of corresponding LSB enabled
1 - writing of corresponding LSB inhibited
Port C = 177036

COUNTER/TIMER CONTROL REGISTERS
Each counter/timer has a set of Counter/Timer Control registers to
specify the operation of the counter/timers.
Counter/Timer Mode Specification Registers
These registers define the modE~ of operation for the counter/timers
and specify the external contr()l and status lines to provide for it.
A RESET clears all bits to O. All bits are read/write.
7

I6 I5 I4 I3

I1 I0

Counter/Timer 1 = 177070
Counter/Timer 2 = 177072
Counter/Timer 3 = 177074

257

uNOTE # 032
Page 12 of 42
Bit 7:

Continuous/Single Cycle

o - When the counter reaches 0 the countdown sequence is

terminated.
1 - When the counter reaches 0 the time constant value is
reloaded and the countdown sequence is repeated.
Bit 6:

External Output Enable (EOE)

o - No external access.
1 - The output of the counter/timer is available on the I/O pin
associated with that counter/timer. (See table 2 for pin
assignments.)
Bit 5:

External Count Enable (ECE)

o - No external access.
1 - The I/O line of the port associated with the counter/timer
is used as an external counter input. (See table 2 for pin
assignments.)
Bit 4:

External Trigger Enable (ETE)

o - No external access
1 - The I/O line of the port associated with the counter/timer
is used as a trigger input to the counter/timer.
(See
table 2 for pin assignments.)
Bit 3:

External Gate Enable (EGE)

o - No external access
1 - The I/O line of the port associated with the counter/timer
is used as an external gate input to the counter/timer.
This allows the external line to suspend/continue the
countdown in progress by toggling the line. (See table
2 for pin assignments.)
Bit 2:

Retrigger Enable Bit (REB)

o - Triggers (external or internal) that occur during a

countdown sequence are ignored.
1 - Triggers that occur during a countdown sequence cause a
new countdown to begin.
Bits 1,0:

Output Duty Cycle Selects

These two bits select the output duty cycle as shown in the
following table:

258

uNOTE # 032
Page 13 of 42
Bit 1

o
o

Bit 0

o
o

Pulse Output
One-Shot Output
Square Wave Output
Do not uf;e

See figure 2 for a description of each output duty cycle.
Counter/Timer Command and Status Registers
Each counter/timer contains a command and status register for
controlling the operation of thl~ counter/timer. A RESET clears all
bits to O.
7

Counter/Timer 1 - 177024
Counter/Timer 2 - 177026
Counter/Timer 3 = 177030
Bit 7:

Interrupt Under Service (IUS)
The'operation of the this bit is the same as the IUS bit
described on page *.

Bit 6:

Interrupt Enable (IE)
The operation of the this bit is the same as the IE bit
described on page *

Bit 5:

Interrupt Pending (IP)
This bit is set to 1 to indicate that the counter/timer needs
to be serviced.
It is automatically set to 1 each time the
counter/timer reaches its terminal count.

The IUS, IE, IP bits are written by using the codes shown in the
following table:
Bit 7
0
0
0
0
1
1
1
1

Bit 6
0
0
1
1
0
0
1
1

Bit 5
0
1
0
1
0
1
0
1

259

Null code
Clear IP and IUS
Set IUS
Clear IUS
Set IP
Clear IP
Set IE
Clear IE

llNOTE # 032
PagE~

14 of 42

Bit 4:

Interrupt Error (ERR)
This bit is set to indicate that the counter/timer has reached
a terminal count before the previous terminal count has been
serviced.

Bit 3:

Read Counter Control (RCC)
Writing this bit to a 1 causes the contents of the Counter/Timer
Current Count Register (CCR), which normally follows the downcounter, to be frozen until the least-significant byte of the
CCR is read.

Bit 2:

Gate Command Bit (GCB)

o - Halts the countdown sequence.
1 - starts or resumes the countdown sequence.
Bit 1:

Trigger Command Bit (TCB)
When written with a 1, this bit causes the down-counter to be
loaded with the time constant value and a countdown sequence
to be initiated.

Bit 0:

Count in Progress (CIP)
This status bit is set to 1 to indicate that a countdown
sequence is in progress.
It is automatically set to 0 when
the down-counter reaches o.

Counter/Timer Time Constant Registers
These registers contain the time constant value that is loaded into
the down-counter when a trigger is detected. These registers are 16
bits wide and are accessed as two a-bit registers.
(Bit 7 of the
most-significant byte is bit 15 of the Time Constant register). A
RESET does not effect these registers.
Bit 15

Bit 0

> <

MSB

I7 I6

I4 I3

Counter/Timer.. 1 MSB = 177054
Counter/Timer 2 MSB = 177060
Counter/Timer 3 MSB = 177064

260

LSB

I I7

>
3

I0 I

Counter/Timer 1 LSB - 177056
Counter/Timer 2 LSB - 177062
Counter/Timer 3 LSB - 177066

uNOTE # 032
Page 15 of 42
Counter/Timer Current Count Registers
These 16-bit registers follow the contents of the appropriate downcounter until a 1 is written into the RCC register. At that time the
contents of the CCR are frozen until the least-significant byte of the
CCR is read. A RESET forces the CCR to follow the down-counter again.
Bit 15

Bit 0

> <

MSB

I7 I6

Counter/Timer 1 MSB == 177040
Counter/Timer 2 MSB - 177044
Counter/Timer 3 MSB - 177050

LSB

I I7

I0 I

Counter/Timer 1 LSB - 177042
Counter/Timer 2 LSB - 177046
Counter/Timer 3 LSB - 177052

INTERRUPT RELATED REGISTERS
These registers contain the interrupt vectors output during an interrupt
acknowledge sequence. Registers are provided for Port A, Port B, one to
be shared by the Counter/Timers. Another register is provided to
indicate which devices need service in a polled environment.
Interrupt vector Registers
These vectors contain the vector output when the source of an
interrupt is acknowledged.
If Master Interrupt Enable - 1 then the
vector register returns status when read according to the following
table:
Port vector Status
OR-Priority Encoded vector Mode:
Bit 3

Bit 2

Bit 1

Encodes the number of the highest-priority
bit with Cl match

All other modes:
Bit 3
ORE

Bit 2
IRF

Bit 1
PMF

Normal
Error

Counter/Timer Status
Bit 2
0
O.

1
1

Bit 1
0
1
0
1

Counter/Timer 3
Counter/Timer 2
Counter/Timer 1
Error

261

uNOTE # 032
Page 16 of 42

Port A = 177004
Port B = 177006
Counter/Timers = 177010
The native firmware of the KXT11-C initializes these interrupt vectors
to the following values:
Port A - 200
l?ort B - 204
Counter/Timers - 210
Current Vector Register
When read) this register returns the interrupt vector that would have
been output by the device during an interrupt acknowledge cycle if its
lEI input had been high.
The vector returned corresponds to the
highest priority IP independent of IUS.
The order of priority is:
Counter/Timer 3, Port A, Counter/Timer 2, Port B, Counter/Timer 1"
If
no enabled iriterrupts are pending, a pattern of ones is returned.
This is useful in a polled environment.

Address

= 177076

I/O BUFFER CONTROL REGISTER
The PIO chip is protected from the connector by a set of buffers.
These
buffers comply with the IEEE 488 electrical standards.
The buffers
allow the ports to configured as inputs or outputs. They also allow the
ports to be configured as open collectors or active pull-ups.

[ 15

I 14 I 13 I 12 I 11

I9 I8 I7 I6

Address
Bit 15:

PCTT

= 177140

(Cleared on RESET)

o - Configures the Port C drivers for open collector
1 - Configures the Port C drivers for active pull-up

262

uNOTE i 032
Page 17 of 42
Bit 14:

PABTT

(Cleared on RESET)

o - Configures the Port A and B drivers for open collector
1 - Configures the Port A and B drivers for active pull-up
Bits 13:10:

PC DIR

(Cleared on RESET)

0 - Port C bit is a receiver
1 - Port C bit is a drivE~r
Bit 9:

PAHN DIR

(Cleared on RESE:T)

0 - Port A high nibble bits ( 4 : 7 ) are receivers
1 - Port A high nibble bits are drivers
Bit 8:

PALN DIR

(Cleared on RESET)

0 - Port A low nibble bits ( 0: 3 ) are receivers
1 - Port A low nibble bits are drivers
Bits 7 : 0:

PB DIR

(Cleared on RESET)

0 - Port B bit is a receiver
1 - Port B bit is a driver

PROGRAMMING THE I/O PORTS
This section will describe how to program the I/O ports and provide
example programs.
In particular this section will describe how to use
the I/O ports in the following modes:
as bit ports, as ports with
handshake, in 16-bit linked mode, and with the DMA controller. The use
of the pattern recognition logic will also be discussed.
programming the I/O Ports as Bit Ports
Using the I/O ports as bit ports provides up to 20 lines for control and
status. Each bit in ports Band C may be independently configured to be
an input or an output. Port A must be configured on a nibble (4-bit)
basis.
programming the PIO as a bit port is straight-forward. First, the Port
Mode Specification Register is used to select the port as a bit port
with/without pattern matching. 'I'hen the Bit Path Definition Registers
are
used
to
determine
the
polarity,
direction, and special
characteristics of the bits of the port.
If pattern recognition is
enabled the Pattern Definition Registers must also be initialized. It
is then a simple matter to write to the output data buffer to provide
the correct control signals and to read the input data buffer to monitor
status.

263

uNOTE # 032
Page 18 of 42
The following program provides an example for using the PIO in
mode:
.TITLE

the

bit

PI01.MAC

j: +

;

This program provides an example of how to program the PIO's
I/O ports as bit ports. This program utilizes the PIO
loopback connector (Part #H3021 or 54-16227) which makes the
following connections:
AO
A1

BO
B1

A7
CO
C1

B7
C3
C2

;

;
;
;

After this program has been assembled and linked on the
development machine use, the KUI utility of the KXT11-C Software
Toolkit to load the program into the KXT11-C to execute as
shown in this example:
SET 2
LOAD PI01.SAV
EXECUTE

;

lOOT

;
;
;

'001152
R2/000000
1154/041101
001156/042103
001160/043105
001162/177507
001164/041101
001166/042103
001170/043105
.001172/000107
1001174/000000

;

. EXIT

,
i

;
; .-

A non-zero result in R2 indicates that an error has occurred.
(Try
running the test without the loopback connector). Location 1154 is
the beginning of the output buffer.
Location 1164 is the beginning
of the input. buffer.
Register Assignments
MIC
MCC

177000
177002

264

uNOT! # 032
Page 19 of 42
PAMODE
PAPOL
PADDIR
PASIO
PADATA

177100
177104
177106
177110
177032

PBMODE
PBPOL
PBDDIR
PBSIO
PBDATA

177120
177124
177126
177130
177034

IOCNTL

177140

START: :
MTPS

#340

Inhibit recognition of
interrupts

;
Initialize PIO
MOVB
#1,MIC
CLRB

Reset device and inhibit interrupt
requests
Enable device (interrupts still
inhibited)

MIC

; Set-up Port A
CLRB
PAMODE
CLRB
PAPOL
CLRB
PADDIR
CLRB
PASIO

Port A: bit port, no pattern match
Port A bits are non-inverting
Port A bits are output bits
Normal output

; Set-up Port B
CLRB
PBMODE
CLRB
PBPOL
MOVB
#377,PBDDIR
CLRB
PBSIO

Port B: bit port, no pattern match
Port B bits are non-inverting
Port B bits are input bits
Normal input

; Set-up the PIO buffers
configure the PIO buffers for
MOV
#1400,IOCNTL
A-output and B-input
;
Initialize GPRs
MOV
#OUTBUF,RO
MOV
#INBUF,R1
CLR
R2

Point to data to be output
Point to input data buffer
R2 will indicate error status

;
~ush input buffer
TSTB
PBDATA
; Enable Ports A and B and send the data
MOVB
#204,MCC
; Enable ports A and B

265

uNOTE # 032
Page 20 of 42
1$:

MOVB
NOP

(RO)+,PADATA

Move data out of Port A

MOVB

PBDATA, (R1 ) +

and into Port B

; Test to see if done
TSTB
(RO )
BPL
1$

IF (RO) is positive
THEN transfer another byte
ELSE check if data is valid

; Compare original data with received data
MOV
#OUTBUF,RO
Point to output data buffer
MOV
#INBUF,R1
Point to input data buffer
2$:

; Test to see if done
TSTB
(RO )
BMI
3$
CMPB
BEQ

( RO ) + , ( R1 ) +
2$

INC

IF (RO) is negative
THEN done comparing
ELSE do another compare
Compare bytes
IF bytes are equal
THEN test another pair
ELSE indicate error
A non-zero value of R2 indicates
an error
Branch here upon completion

3$:

OUTBUF:

.BYTE
. EVEN
.BLKB

101,102,103,104,105,106,107,-1

.END

START

INBUF:

266

uNOTE # 032
Page 21 of 42
programming the I/O Ports as Ports with Handshake
Ports A and B may be configured as ports with handshake to facilitate
transferring data on a byte-by-byte basis.
Port C is used to provide
the handshake lines.
In addition, Port C may use the REQUEST line to
utilize a DMA controller to transfer the data.
See table 1 for a
description of the Port C handshake lines.
Figure 1 shows how two PIOs
can be connected directly together to transfer data and the handshake
lines that are utilized.
PIO Handshake Lines
OUTPUT

INPUT

PIO

DATA

\
\
/

PIO

/
DAV
> ACKIN
RFD
ACKIN (-----------------

- Figure 1 The handshakes that are available are:
Interlocked,
Strobed,
Pulsed,
and 3-Wire. A short description of each handshake type follows:
When using the Interlocked Handshake any action by the PIO must be
acknowledged by the external device before the next action can take
place.
In other words, an output port does not indicate that it has new
data available until the external device indicates that it is ready for
data.
Likewise, and input port does not indicate that it is
ready for
new data until the external device indicates that the previous byte of
data is no longer available,
thereby acknowledging the
input port's
acceptance of the last byte.
The Strobed Handshake uses external logic to "strobe" data into or out
of a port.
In contrast to the Interlocked handshake, the signal
indicating that the port is ready for another data transfer operates
independently of the ACKIN input.
External logic must ensure the data
transfers at the appropriate speed.
The Pulsed Handshake is used to interface to mechanical devices which
require data to be held for relatively long periods of time in order to
be gated in or out of the device.
The logic is the same as the
Interlocked Handshake except that Counter/Timer 3 is linked to the
handshake logic to add the appropriate delays to the handshake lines.

267

uNOTE # 032
Page 22 of 42
The 3-Wire Handshake may be used so that one -output port can communicate
to several input ports simultaneously. This is essentially the same as
the Interlocked Handshake except that two individual lines are used to
indicate when an input port is ready for data (RFD) and when it has
accepted data (DAC).
Because this handshake requires three lines only
one port can use the 3-Wire Handshake at a time.
Port C Handshake Lines
Port C Bits
Port A/B Configuration

Pin C3

Pin C2

Pin Cl

Pin CO

Ports A & B - Bit Ports

Bit I/O

Port A - Input or Output
(Interlocked, Strobed,
or Pulsed Handshake)*

RFD or DAV

ACKIN

REQUEST
or Bit I/O

Bit I/O

Port B - Input or Output
(Interlocked, Strobed,
or Pulsed Handshake)*

REQUEST
or Bit I/O

Bit I/O

RFD or DAV

ACKIN

Port A or B = Input Port
(3-Wire Handshake)

RFD
(Output)

DAV
(Input)

REQUEST
or Bit I/O

DAC
(Output)

Port A or B = Output Port
(3-Wire Handshake)

DAV
(Output)

DAC
(Input)

REQUEST
or Bit I/O

RFD
(Input)

ACKIN

REQUEST
' or Bit I/O

IN/OUT

Port A or B = Bidirectional RFD or DAV
(Interlocked or Strobed
Handshake)

Both Ports A & B may be specified as input or output ports with
the Interlocked, Strobed, or Pulsed Handshakes at the same time
if neither uses REQUEST. Only one port can use the Pulsed
Handshake at a time.
- Table 1 -

When Ports A and B are configured as ports with handshake they must also
be configured as single- or double-buffered.
Double-buffering a port
allows more time for the interrupt service routine ,to respond to a data
transfer.
A s~cond byte of data is input to or output from the port
before the interrupt for the first byte is serviced. A single-buffered
port is used whe~ it is important to have byte-by-byte control over the
transfer or where it is important to enter the interrupt service routine
in a fixed amount of time after the data has been accepted/output.
The REQUEST line may also be used by ports with handshake.
This control
line enables the PIa to signal the DMA controller of the KXTll-C that
the port wishes to transfer data without CPU intervention.
The
operation of the REQUEST line is dependent on the Interrupt on Two Bytes

268

uNOTE # 032
Page 23 of 42
(ITS) bit in the Port Mode Specification Register.
If ITS - 0 then the
REQUEST line goes active anytime a byte is available to transfer.
If
ITB - 1 then the REQUEST line does not assert until two bytes are
available to transfer.
The implementation'of the PIO on the KXT11-C
requires that only Port A be used for DMA transfers.
Since the REQUEST
line utilizes one of the Port C bits Port B must be programmed as a bit
port when Port A uses the REQUEST facility.
The following example programs display the capabilities of the PIO
as a port with handshake:
.TITLE
;
;
;
;
;
;
;
;
;

used

PI02.MAC

This program demonstrates the ability of the PIO to transfer data
on a byte-by-byte basis. The program uses the Interlocked
Handshake to transfer data from Port A to Port B. Both ports are
configured as single-buffered. The PIO loopback connector (part
#H3022 or 54-16227) or a functional equivalent is required to
successfully run this program.
After this program has been assembled and linked on the
development machine use the KUI utility of the KXT11-C Software
Toolkit to load the program into the KXT11-C to execute as
shown in this example:
SET 2
LOAD PI02.SAV
EXECUTE
'ODT

;

;
;

001214
1262/065151
001264/066153
001266/067155
001270/070157
!001272/000377
!001274/065151
1001276/066153
!001300/067155
1001302/070157
1001304/000000

;

EXIT

;

This veri~ies that the contents of the output buffer (location 1262
were successfully transferred to the input buffer (location 1274).

;
;
;

; Register Assignments
MIC

177000

269

uNOTE # 032
Page 24 of 42
MCC

177002

PAVEC
PASTAT
PADATA
PAMODE
PAHDSH
PAPOL
PASIO

177004
177020
177032
177100
177102
177104
177110

PBVEC
PBSTAT
PBDATA
PBMODE
PBHDSH
PBPOL
PBSIO

177006
177022
177034
177120
177122
177124
177130

PCPOL
PCDDIR

177012
177014

IOCNTL

177140

STAR'r: :
MTPS

#340

Inhibit recognition of interrupts

MOVB

#l,MIC

CLRB

MIC

Reset device and inhibit interrupt
requests from the PIO
Enable device (interrupts still
inhibited)

MOVB
MOV
MOV

#200,PAVEC
#OUT,@#200
#340,@#202

Set up Port A interrupt vector
and PSW

MOVB
MOV
MOV

#204,PBVEC
#IN,@#204
#340,@#206

Set up Port B interrupt vector
and PSW

; set-up Port A
MOVB
#220,PAMODE
CLRB
PAHDSH
CLRB
PAPOL
CLRB
PASIO
MOVB
#300,PASTAT

Port A: Output Port, single-buffered
Use interlock handshake
Port A bits are non-inverting
Normal output
Enable Port A interrupts

; Set-up Port B
MOVB
#120,PBMODE
CLRB
PBHDSH
CLRB
PBPOL
CLRB
PBSIO
MOVB
#300,PBSTAT

Port B:
Input Port, single-buffered
Use interlock handshake
Port B bits are non-inverting
Normal input
Enable Port B interrupts

270

uNOTE # 032
Page 25 of 42
; Set-up the Port C handshake lines.
; All handshake lines are configured as inputs - even
;
if they aren~tl
MOVB
#377,PCDDIR
Port C bits are inputs
; Set-up the PIa buffers
MOV
#165400,IOCNTL; configure the PIO buffers for A-out
B-input, CO,C2-input, C1,C3-output
; Set-up data areas
MOV
#OUTBUF,RO
MOV
#INBUF,R1
; Enable Interrupts
MOVB
#224,MCC
MOVB
#200,MIC
MTPS
#0

Point to Output Buffer
; Point to Input Buffer
Enable ports A, S, and C
Enable MIC
Enable recognition of interrupts

; Start the first transfer
MOVB
#200,PASTAT
Set IP to initiate a transfer
BR

; Wait here for the interrupts

OUT: :
BMI

(RO)
1$

MOVB

(RO)+,PADATA

BR
MOVB
MOVB
RTI

#240, PASTAT'
#140,PASTAT

Clear IP when done
Clear IUS on each pass

MOVB

PBDATA, (R1) +

MOVB
RTI

#140,PBSTAT

Move byte from Port B input data
register
Clear IUS on each pass

.BYTE
• EVEN
.BLKB

151,152,153,154,155,156,157,160,-1

.. END

START

~STB

1$:
2$:

IF (RO) are negative
THEN transfers are complete
ELSE transfer another byte
Move byte to the Port A output data
register

IN: :

OUTBUF:
INBUF:

271

uNOTE i 032
Page 26 of 42
.TITLE

;

PI03.MAC

This program is basically the same as PI02.MAC with the
with the exception that the ports are double-buffered.
The PIO loopback connector (part #83022 or S4-16227) or a
functional equivalent is required to successfully run this program.
After this program has been assembled and linked on the
development machine use the KUI utility of the KXT11-C Software
Toolkit to load the program into the KXT11-C to execute as
shown in this example:

;
;
;

;
;

SET 2
LOAD PI03.SAV
EXECUTE
! OOT
1001214
11272/065151
'001274/066153
001276/067155
001300/070157
001302/000377
001304/065151
001306/066153
001310/067155
1001312/070157
1001314/000000
EXIT
This verifies that the contents of the output buffer (location 1272
were successfully transferred to the input buffer (location 1304).
; Register Assignments
MIC
MCC

177000
177002

PAVEC
PASTAT
PADATA
PAMODE
PAHDSH
PAPOL
PASIO

177004
171"020
177032
177100
177102
177104
177110

PBVEC
PBSTAT
PBDATA
PBMODE

177006
177022
177034
177120

272

uNOTE # 032
Page 27 of 42
PBHDSH
PBPOL
PBSIO

177122
177124
177130

PCPOL
PCDDIR

177012
177014

IOCNTL

177140

START: :
MTPS

#340

Inhibit recognition of interrupts

MOVB

#l,MIC

CLRB

MIC

; Reset device and inhibit interrupt
requests from the PIO
Enable device (interrupts still
;
inhibited)

MOVB
MOV
MOV

#200,PAVEC
#OUT,@#200
#340,@#202

MOVB
MOV
MOV

#204,PBVEC
#IN,@#204
#340,@#206

; Set up Port A interrupt
and PSW

vecto~

Set up Port B interrupt vector
and PSW

; Set-up Port A
MOVB
#240,PAMODE
CLRB
PAHDSH
CLRB
PAPOL
CLRB
PASIO
MOVB
#300,PASTAT

Port A: Output Port, double-buffered
Use interlock handshake
; Port A bits are non-inverting
Normal output
Enable Port A interrupts

; Set-up Port B
MOVB
#140,PBMODE
CLRB
PBHDSH
CLRB
PBPOL
CLRB
PBSIO
MOVB
#300,PBSTAT

Port B:
Input Port, double-buffered
Use interlock handshake
Port B bits are non~inverting
Normal input
Enable Port B interrupts

; set-up the Port C handshake lines.
All handshake lines are configured as inputs - even
;
if they aren'tl
Mova
#377,PCDDIR
Port C bits are inputs
; Set-up the PIO buffers
MOV #165400, IOCNTL
; set-up data areas
MOV
#OUTBUF,RO
MOV
#INBUF,R1

273

configure the PIO buffers for A-out
B=input, CO,C2-input, Cl,C3-output
Point to Output Buffer
; Point to Input Buffer

uNOTE # 032
page 28 of 42
; Enable Interrupts
MOVB
#224,MCC
MOVB
#200,MIC
MTPS
#0

Enable ports A, B, and C
Enable MIC
Enable recognition of interrupts

; start the first transfer
MOVB
#200,PASTAT
Set IP to initiate a transfer
SR

wait here for the interrupts

OUT: :

1$:
2$:

TSTB
BMI

(RO)
1$

MOVB

(RO)+,PADATA

MOVB

(RO)+,PADATA

BR
MOVB
MOVB
RTI

2$
#240,PASTAT
#140,PASTAT

MOVB

PBDATA, (R1)+

MOVB

PBDATA, (R1) +

MOVB
RTI

#140,PBSTAT

.BYTE
. EVEN
.BLKB

151,152,153,154,155,156,157,160,-1
10

.END

START

IF (RO) are negative
THEN transfers are complete
ELSE transfer another byte
Move 1st byte to the Port A output
data register
Move 2nd byte to the Port A buffer
register
Clear IP when done
Clear IUS on each pass

IN: :

OUTBUF:
INBUF:

Move 1st byte from Port B input data
register
Move 2nd byte from Port B buffer
register
Clear IUS on each pass

274

uNOTE # 032
Page 29 of 42

;
;
;

;

This example shows something a little more practical - one
KXT11-C transferring data to another.
Two programs follow:
one accepts data through Port B using the double-buffered
mode (PI04I.MAC); the second one sends data out of Port A
using the double buffered mode (PI040.. MAC).
In order to
successfully run these programs the KXT11-Cs must be connected
by a "straight-thru" ribbon cable which is given a half twist.
In other words, it should make the same connections that the
PIO loopback connector does. (AI-B1,A2-B2, ... A7-B7,CO-C3,C1-C2).

;

;
;

Each program should be assembled and linked separately on the
development machine.
Then use the KUI utility of the KXT11-C
Software Toolkit to load the programs into the KXT11-Cs to execute
as shown in this example:

;

;
;
;
;

;

SET 3
LOAD PI04I.SAV
EXECUTE
SET 2
LOAD PI040.SAV
EXECUTE
SET 3
lOOT

;

;
;

00113,0
1152/065151
001154/066153
001156/067155
001160/070157
001162/000000
EXIT

;

This verifies that the data was successfully transferred to
the input buffer of KXT11-C #3.
;

;-------------------------;----------------------------------------------------------------------.TITLE PI04I.MAC
; Register Assignments
MIC
MCC

177000
177002

PBVEC
PBSTAT
PBDATA
PBMODE
PBHDSH
PBPOL
PBDDIR

177006
177022
177034
177120
177122
177124
177126

275

uNOTE # 032
Page 30 of 42
PBSIO

177130

PCDOIR

177014

IOCNTL

177140

START: :
Inhibit recognition of interrupts
Reset device and inhibit interrupt
requests from the PIO
Enable device (interrupts still
inhibited)

MTPS
MOVB

#340
#l,MIC

eLRB

MIC

MOVB
MOV
MOV

#204,PBVEC
#IN,@#204
#340,@#206

Set up Port B interrupt vector
... and PSW

MOVB
eLRB
eLR
eLR
MOVB

#140,PBMODE
PBHDSH
PBPOL
PBSIO
#300,PBSTAT

Port B:
Input Port, double-buffered
Use interlock handshake
Port B bits are non-inverting
Normal input
Enable Port B interrupts

MOVB

#377,PCDDIR

Port C bits are inputs

MOV

#165400,IOCNTL

configure the PIO buffers for A-out
B=input, CO,C2-input, Cl,C3-output

MOV

#INBUF,R1

Point to input data buffer

MOVB
MOVB

#220,MCC
#200,MIC

Enable ports Band C
Enable MIC

MTPS
BR

Enable recognition of interrupts
Wait here for the interrupts

MOVB

PBDATA, (Rl)+

MOVB

PBDATA, (R1) +

MOVB
RTI

#140,PBSTAT

Move 1st byte from Port B input data
register
Move 2nd byte from Port B buffer
register
Clear IUS on each pass

.BLKB

.END

START

IN: :

INBUF:

276

uNOTE # 032
Page 31 of 42

.TITLE

PI040.MAC

; Register Assignments
MIC
MCC

177000
177002

PAVEC
PASTAT
PADATA
PAMODE
PAHDSH
PAPOL
PASIO

177004
177020
177032
177100
177102
177104
177106
177110

PCPOL
PCDDIR

177012
177014

IOCNTL

177140

P~~DDIR

START: :
MTPS
MOVB

#340
#1,MIC

CLRB

MIC

MOVB
MOV
MOV

#200,PAVEC
#OUT,@#200
#340,@#202

Set up Port A interrupt vector
... and PSW

MOVB
CLRB
CLR
CLR
MOVB

#240,PAMODE
PAHDSH
PAPOL
PASIO
#300,PASTAT

Port A: Output Port, double-buffered
Use interlock handshake
Port A bits are non-inverting
Normal output
Enable Port A interrupts

MOVB

#377,PCDDIR

Port C bits are inputs

MOV

#165400,IOCNTL

configure the PIO buffers for A-out
B=input, CO,C2=input, C1,C3-output

MOV

#OUTBUF,RO

Point to output data buffer

MOVB
MOVB
MTPS

#24,MCC
#200,MIC
#0

Enable ports A and C
Enable MIC
Enable recogn~tion of interrupts

Inhibit recognition of interrupts
Reset device and inhibit interrupt
requests from the PIO
Enable device (interrupts still
inhibited)

277

uNOTE i 032
Page 32 of 42
MOVB
BR

i200,PASTAT

Set IP to initiate a transfer
wait here for the interrupts

TSTB
BMI

(RO)
1$

MOVB

(RO)+,PADATA

MOVB

(RO)+,PADATA

IF (RO) are negative
THEN all data has been transferred
ELSE do another transfer
Move 1st byte to. the Port A output
data register
Move 2nd byte to the Port A buffer
register

BR
MOVB
MOVB
RTI

2$
i240,PASTAT
i140,PASTAT

OUT: :

1$:
2$:

OUTBUF::.BYTE
.END

Clear IP when done
Clear IUS on each pass

151,152,153,154,155,156,157,160,-1
START

278

uNOTE # 032
Page 33 of 42
;
;
;
;
;

The following two programs demonstrate how the DTC may be used
to transfer data from the PIO to KXTII-C local memory~ DTC
transfers may only be accomplished using Port A of the PIO.
It is not possible to properly eonnect two PIOs with a ribbon
cable because the handshake lines will not align correctly when
connecting Port A to Port A.
Therefore it is necessary to build
a caple that makes the following connections:

;

Input Port A
output Port A
AO
(---->
AO
Al
(---->
Al

;
;
;
;

(--

C2
C3

(-(--

>
>

C3
C2

;
;

It is also necessary to place a jumper between posts M48 and M49
so that the REQUEST line from the PIO may signal th~ DTC.
For more
information about 'programming the DTC please refer to Micronote 18.

;

After each program has been assembled and linked on the
development machine use the KUI utility of the KXTII-C Software
Toolkit to load the programs into a KXT11-C to execute as
shown in this example:

;

;
;
;
;

SET 3
LOAD PI05I.SAV
EXECUTE
SET 2
LOAD PI050.SAV
EXECUTE
SET 3
ODT

;

;
;
i

;
;
;
;
;

001140
1140/000777
001142/065151
001144/066153
001146/067155
1001150/070157
1001152/001602
!
Examinin~the contents of the input buffer (location 1142)
verifies that the data was successfully transferred.

;
;------~--------------------------------------------------------

.TITLE

PI05I.MAC

279

uNO'l'E # 032
Page 34 of 42
This program transfers data from Port A of the PIO
to local memory by utilizing the DTC
Register Assignments
MMREG
CMDREG
CASTF1
CAOF1

174470
174454
174444
174440

MIC
MCC

177000
177002

PAVEC
PASTAT
PADATA
PAMODE
PAHDSH
PAPOL
PADDIR
PASIO

177004
177020
177032
177100
177102
177104
177106
177110

PCPOL
PCDDIR

177012
177014

IOCNTL

177140

START: :
MTPS

#340

; Inhibit recognition of interrupts

; Initialize the DTC - for more information on the DTC
; refer to Micronote #18.
MOVB
#154,MMREG
Load Master Mode Reg to Disable DTC
CLRB
CMDREG
Reset the DTC
MOV
#O,CASTFl
Load the CH1 Register SEG/TAG
MOV
#RELOAD,CAOF1
Load the CHl Register Offset
MOVB
#l55,MMREG
Load Master Mode Reg to Enable DTC
MOVB
#241,CMDREG
Start Chain Channel 1
; Initialize the PIO
MOVB
#l,MIC
CLRB

Reset device and inhibit interrupt
requests from the PIO
Enable device (interrupts still
inhibited)

MIC

; Set-l::tp Port A
MOVB
#l20,PAMODE
MOVB
#70,PAHDSH
CLR
CLR

Port A:
Input Port, single-buffered
Use interlock handshake, input
REQUEST
Port A bits are non-inverting
Normal input

PAPOL
PASIO

280

uNOTE # 032
page 35 of 42
MOVB

#2,PCPOL

MOVB

#377,PCDDIR

MOV

#164377,IOCNTL

configure the PIa buffers for A-in
B=output, CO,C2-input, C1,C3-output

MOV

#INBUF,R1

Point to input data buffer

MOVB

#24,MCC

Enable ports A and C

BR
INBUF:

Invert pin C1 - this is the line
that is used for the REQUEST signal
Port C bits are inputs

Wait here while the DMA transfers
take place

.BLKB

; Chain Load Region
RELOAD:

.WORD

001602

.WORD
.WORD

000020
; Current Address Register A Seg/Tag
padata+1; Current Address Register A Offset
<This local address is the source,
its address is held constant, since
the DTC is doing byte transfers specify
the source address high byte>

.WORD
.WORD

000000
inbuf

Current Address Register B Seg/Tag
Current Address Register B Offset
<This local address is the destination>

.WORD

000010

Current Operation Count <Transfer 8 words>

.WORD
.WORD

000000
000001

Channel Mode Register High
Channel Mode Register Low
<No match conditions, do nothing upon
completion, transfer type - Single Transfer
CARA = source, byte transfers>

.END

START

.TI~LE

PIOSO.MAC

Reload Word <Select CARA,CARB,COPC,CM>

;

This program transfers data out of Port A of the PIO
utilizing the DTC
Register Assignments

281

uNO'l?E # 032
page 36 of 42
MMREG
CMDREG
CASTFI
CAOFI

174470
174454
174444
174440

MIC
MCC

177000
177002

PAVEC
PASTAT
PADATA
PAMODE
PAHDSH
PAPaL
PADDIR
PASIO

177004
177020
177032
177100
177102
177104
177106
177110

PCPOL
PCDDIR

177012
177014

rOCNTL

177140

START: :
MTPS

#340

Inhibit recognition of interrupts

; Initialize the DTC
MOVB
#154,MMREG
CLRB
CMDREG
MOV
#O,CASTFI
MOV
#RELOAD,CAOFI
MOVB
#155,MMREG
MOVB
#241,CMDREG

Load Master Mode Reg to Disable DTC
Reset the DTC
Load the CHI Register SEG/TAG
Load the CHI Register Offset
Load Master Mode Reg to Enable DTC
Start Chain Channel 1

; Initialize the PIO
MOVB
#l,MIC
CLRB

Reset device and inhibit interrupt
requests from PIO
Enable device (interrupts still
inhibited)

MIC

; set-up Port A
MOVB
#220,PAMODE
MOVB
#050,PAHDSH
CLR
CLR

PAPOL
PASIO

MOVB

'- #2,PCPOL

Port A: Output Port, single-buffered
Use interlock handshake, output
REQUEST
Port A bits are non-inverting
Normal output
Pin Cl must be inverted - this is
the line used to signal the DTC
Port C bits are inputs

MOVB

#377,PCDDIR

MOV

#165400,IOCNTL

282

configure the PIO buffers for A-out
B=input, CO,C2=input, Cl,C3=output

uNOTE i 032
page 37 of 42
MOV

iOUTBUF,RO

Point to output data buffer

MOVB

i24,MCC

Enable ports A and C

BR
OUTBUF::.BYTE
. EVEN

Wait here while the DMA transfers
complete
151,152,153,154,155,156,157,160,-1

; CHAIN LOAD REGION
RELOAD:

.WORD

001602

. WORD
.WORD

000000
outbuf

.WORD
.. WORD

000020
; Current Address Register B Seg/Tag
padata+l; Current Address Register B Offset
<This local address is the destination,
Hold the address, must specify high byte
;
for byte transfer>

. WORD

000010

Current Operation Count <Transfer 8 words>

.WORD
.WORD

000000
000001

Channel Mode Register High
Channel Mode Register Low
<No match conditions, do nothing upon
completion, transfer type - Single Transfer
CARA = source, byte transfers>

.END

START

Reload word <Select CARA,CARB,COPC,CM>
Current Address Register A Seg/Tag
Current Address Register A Offset
; <This local address is the source>

283

uNOTE # 032
page 38 of 42
PROGRAMMING THE COUNTER/TIMERS
This section will describe how to program the Counter/Timers and provide
example programs demonstrating their capabilities.
Each of the three Counter/Timers provides up to four lines for external
access.
If these external lines are used the corresponding port pins
must be available and programmed in the proper direction. The following
table displays which port pins correspond to the Counter/Timer external
access lines:
Counter/Timer External Access Lines
Function
Counter/Timer Output
Counter Input
Trigger Inp\lt
Gate Input

CIT 1

CIT 2

CIT 3

Port B4
Port as
Port B6
Port B7

Port BO
Port B1
Port 52
Port 53

Port CO
Port C1
Port C2
Port C3

- Table 2 The first step in programming a Counter/Timer is to specify which (if
any) external lines are to be used, the output duty cycle, and whether
the cycle is continuous or single-cycle. The following figures display
the available output duty cycles:
Output Duty Cycles
If Time Constant Value = 5

Pulse Output Mode

-) 500 nS

One-Shot Mode

284

uNOTE # 032
Page 39 of 42
If Time Constant Value = 8
Square Wave Mode

~
I

- Figure 2 Next, the Time Constant Registers must be loaded.
Each Counter/Timer
contains two of these registers which are used to form the 16-bit value
that is loaded into the down-counter when the Counter/Timer
is
triggered.
If external lines are to be used then the corresponding port pins should
be programmed as bit ports with the correct data direction. Finally,
the Counter/Timer enable bit for that port must be enabled in the Master
Configuration Control Register.
The down-counter is loaded and the countdown sequence is initiated when
the Counter/Timer is triggered.
This trigger may occur because the
Trigger Command Bit (TCB) in the Command and Status Register is set or
because an external trigger input was asserted. Once the countdown is
initiated it will continue towards the terminal count as long as the
Gate Command Bit (GCB) in the Command and status Register is set and the
Gate Input is held asserted (if it is enabled).
If a trigger occurs
during a countdown sequence the action taken is determined by the
Retrigger Enable Bit (REB). If REB = 0 then the trigger is ignored, but
if REB = 1 then the down-counter is reloaded and a new countdown is
initiated.
When the terminal count is reached the state of the Continuous/Single
Cycle bit (C/SC) in the Mode Specification Register is examined. If
C/SC - 0 then the countdown sequence stops. If C/SC - 1 then the time
constant is reloaded and a new countdown is initiated. If the Interrupt
Enable Bit (IE) is set an interrupt request is generated when the
down-counter reaches its terminal count. If a terminal count occurs
while the Interrupt Pending Bit (IP) then an error is indicated by the
Interrupt Error (ERR) bit.
The following program
Counter/Timers:

provides

285

example

how

program

the

uNOTE # 032
Page 40 of 42
.TITLE
;
;
;

CT1.MAC

This program demonstrates how to utilize one of the Counter/Timers
on the KXT11-C.
Counter/Timer 1 will be used in this program.
This counteritimer is clocked at a 500 ns rate.
The time constant
used for the counter is 50,000. Therefore the countdown sequence
will take 25 ms.
(500 ns x 50,000 - 25,000,000 ns - 25 ms).
The
interrupt service routine waits until the countdown sequence has
completed 40 times and then outputs an 'A' out of the console
port. This should happen approximately one time a second.
(25 ms
x 40 - 1 s).

;

;
;
;
;

After this program has been assembled and linked on the
development machine use the KUI utility of the KXT11-C Software
Toolkit to load the program into the KXT11-C to execute as
shown in this example:

;
;
;

SET 2
LOAD CT1.SAV
EXECUTE
EXIT

;

Notice that the 'A's keep on coming after you exit

KUI~

; Register Assignments
MIC
MCC
CTVEC
CT1CON
CT1HI
CT1LO
CT1MOD

177000
177002
177010
177024
177054
177056
177070

START: :
MTPS

#340

MOVB
CLRB

#l,MIC
MIC

MOVB
MOV
MOV

#210,CTVEC
#ISR,@#210
#340,@#212

CLR

Used as a counter

MOVB

-#200, CT1MOD

MOVB
MOVB

#203,CT1HI
#120,CT1LO

Select continuous mode, no external
access, pulse output
CT1HI and CT1LO combine ,to form
141520(8) = 50000(10)

MOVB

#100,MCC

Enable Counter/Timer 1

Disable recognition of interrupts
;

;

286

Reset PIO
Enable PIO (Interrupts disabled)
Initialize Counter/Timer vector
and ISR address

uNOTE # 032
page 41 of 42
MOVB
MTPS

#200,MIC
#0

Enable PIO interrupts
Enable recognition of interrupts

BISB

#306,CT1CON

Set IE,GCB,TCB - this starts the
countdown
wait here for the interrupts

Rl
Rl,#40.
2$
Rl
#101,@#177566

Increment the counter
IF this is not the 40th time
THEN count again
ELSE clear the counter and ...
send an 'A' to the console

BR
ISR:
INC
CMP
BNE
CLR
MOVB

;+
;
;
;

The console in this case is the KXTll-C console - NOT the
Therefore you'll have to hook a
development system console.
terminal up to SLUl to see the ' A's pop out.

2$:

MOVB

Clear IUS and IP but don't bother
GCB

#44,CT1CON

RTI
.END

START

287

uNOTE i 032
Page 42 of 42
RELATED DOCUMENTS
For further information about the KXTll-C and the PIO please consult the
following sources:
KXT11-C Single-Board Computer User's Guide

(EK-KXTCA-UG)

AmZ8036 Counter/Timer, Parallel I/O Technical Manual*
*

This manual may be obtained from Advanced Micro Devices

288

uNOTE # 033

Title:

System Configuration of DL-type Devices

Originator:

Date: 28-Jun-85
Page 1 of 14

Art Bigler

DL-type devices are single,
asynchronous serial line unit
(SLU)
interfaces used on Digital's Q·-bus and UNIBUS processors. On PDP-lIs
the OL-type SLU is required as thf~ console terminal interface for use
with console octal debugging technique (ODT), diagnostics, and operating
system consoles.
They are also used to provide interfacing to a wide
variety of peripherals on both POP-II and VAX processors.
This MicroNote examines the proper use and configuration of DL-type SLUs
in system environments.
It first discvsses their characteristics, and
then, some of the applications in which they are used.
Lastly,
the
configuration of OL-type SLUs in the system environment is discussed and
a number of recommendations for their use are presented.
It should be noted that the examination of a system configuration and
any resulting recommendations are' based upon the particular application
of the system.
The configuration guidelines presented here are not
necessarily suitable for all application environments.
The system
designer must determine the extent to which this information is
a.ppropriate.

1.0 CHARACTERISTICS OF THE OL-TYPE SLU
The DL-type SLU is an interface to asynchronous serial peripherals (e.g.
terminals)
consisting of a host bus interface (to the Q-bus or UNIBUS),
a receiver and transmitter (usually an industry-standard UART),
and an
electrical interface to the peripheral
(20 rna.
current loop, EIA
RS-232-C, RS-422, etc.). Additional features (e.g.
the line time clock
register on the UNIBUS DL11 or modem control on the Q-bus OLVE1) mayor
may not be present on a oL-type SLUe These features have nothing to do
with the basic function of the SLU which is transmit and receive
asynchronous serial data (i.e. Modem control is a extension of the
capabilities of the interface, not a basic function). A block diagram
of a oL-type SLU is presented in figure 1.

289

uNOTE # 033
Page 2 of 14

Q-BUS OR UNIBUS

HOST
BUS
INTF

~---)

<------f

ASYNC
TRANS
/REC

1-----)

<---

ELECT
INTF
TO
SERIAL
LINE

TO/FROM
SERIAL
LINE

Figure 1
Block Diagram, DL-type SLU

1.1 DL-TYPE SLU REGISTERS
All DL-type SLUs must implement four registers:
two control and status
registers
(CSRs),
and two data buffer registers (BUFs).
The same base
configuration of bits within these registers must also be implemented.
These registers and their functions are listed below:
1.

The receiver control and status register (RCSR)
provides a
minimum of control and status of the receive interrupt
enable (bit 06) and status of the receiver done flag
(bit
07).
The receiver done flag is set by the SLU whenever a
character is received.
It may be polled by software or it
may generate an interrupt if the receive interrupt enable
has been set.
The receiver done flag is reset by an
initialization from the host bus or by reading the character
from the receiver data buffer register.

The receiver data buffer register (RBUF) provides a minimum
of received character data (bits 00 through 07) and received
data error information (bits 12 through 15).
The received
data isvalid whenever the receiver done flag is set in the
RCSR.
The error bits are implemented in all DL- type SLUs
except the DLV11 and provide status information for the
received data. All DL-type SLUs implement framing error
(bit 13), overrun error
(bit 14), and error summary (bit
15).
Additionally,
all DL- type SLUs,
except
those

290

uNOTE # 033
Page 3 of 14
implemented with the DC319-1\A DLART, implement parity error
status (bit 12). Error summary is set whenever any of the
other error bits are set. Overrun error is set when a newly
received character is received before the receiver done flag
is reset.
Framing error is set whenever a character is
received without a valid stop bit, usually by a break
character.
Parity error is set whenever a character is
received with the incorrect parity, if the interface has
been configured to check parity.
3.

The transmitter control and status register (TCSR) provides
a minimum of control and status of the transmit interrupt
enable (bit 06) and the transmit break enable (bit 00), and
status
of the transmitter ready flag (bit 07).
The
transmitter ready flag is set by the SLU whenever the
transmitter is ready to transmit another character, or by an
initialization from the host bus. It may be polled by a
program or it may generate an interrupt if the transmit
interrupt enable has been set. The transmitter ready flag
is
res.t
by
transferring
another character to the
transmitter data buffer register. The transmit break enable
forces the transmitter to generate a continuous break
character (continuous space level) while it is set.

The transmitter data buffer register (TBUF) holds a minimum
of the last character to be transmitted (bits 00 through
07). Transferring a character to this register resets the
transmitter ready flag in the TCSR.

Transfers to these registers are performed by programmed I/O, the result
of the execution of an instruction by the host processor. The only
other bus operation a DL-type SLU may initiate is an interrupt from the
transmitter or receiver.
Figure 2 provides graphic representations of these registers.
1
5
RC SR

1
4

1
3

o
1

o
o

[L----'---~--!.-----L.---'----'---.L.-..---iIL----.....l.I----L.I---J....----'------'------A..-~--'
RECEIVER DONE FLAG

Figure 2
DL-type SLU registers

291

RECEIVE INTERRUPT
ENABLE

uNOTE # 033
Page 4 of 14
1
5

1
4

1
3

1
2

1
1

o
o

RBUF

+------~I-------+

PARITY ERROR
RECEIVED
CHARACTER
DATA

FRAMING ERROR

OVERRUN ERROR
ERROR SUMMARY

1
5

1
4

1
3

1
2

1
1

o
5

o
4

o
1

o
o

TCSR

TRANSMITTER READY FLAG

TRANSMIT BREAK
ENABLE

TRANSMIT INTERRUPT ENABLE

1
2

1
1

TRANSMIT
CHARACTER
DATA
Figure 2, continued
DL-type SLU registers

292

o
o

uNOTE # 033
Page 5 of 14
1.2 DL-TYPE SLU ADDRESSES AND VECTORS
DL-type SLUs must implement their addresses and vectors in the following
manner:
1.

The four registers, RCSR, RBUF, TCSR, and TBUF, occupy four
contiguous word addresses in the I/O page.
The first
address is called the base address.
A.

RCSR is assigned base address +00.

RBUF is assigned base address +02.

TCSR is assigned base address +04.

TBUF is assigned base address +06

The receive and transmit. interrupt vectors occupy two
contiguous vectors with the' receive vector always first.

For the console SLU on a PDP-11 processor the base address is always
17777560 (octal) and the receive vector is at 60 (octal). DL-type SLUs
used for applications other than the console SLU are usually assigned
address and vectors in the floatin9 address and vector spaces.

1.3 DL-TYPE SLU PROGRAMMING CONSIDERATIONS
There are two methods
interrupt driven I/O.

programming

DL-type

SLUS;

polled

I/O

In polled I/O the host software polls, or tests, the
receiver done flag in the ReSR or the transmitter ready flag
in the TCSR to determine if a character has been received or
is ready to be transmitted. If the flag is set the software
executes an instruction to move the character from the RBUF
or to the TBUF. The polling is then resumed. Polled I/O is
used by PDP-11 diagnostics because it is the simplest method
and requires the least amount of hardware working in a
system, a definite advantage when attempting to service a
system which is operating improperly.

In interrupt driven I/O the software sets the receive
interrupt enable in the RCSR or the transmit interrupt
enable in the TCSR.
If the receiver done flag or the
transmitter ready flag is set, an interrupt is generated
through the appropriate vector. Execution is transferred to
an interrupt service routine (ISR) and an instruction is

293

and

uNOTE # 033
Page 6 of 14
executed to move the character from the RBUF or to the TBUF.
A return from interrupt (RTI) instruction then returns
control back to the main program.
All Digital operating
systems and most user software utilize interrupt driven I/O
because processor time is optimized.
When programming a DL-type SLU, several restrictions must be taken into
account.
Most of these are due to the design of the asynchronous
receiver and transmitter and its implementation in the SLUe
The
important restrictions are detailed below.
1.

There is only a one character buffer in the receive side of
the SLUe
Therefore, any character which has been received
must be moved from the RBUF prior to the next character
being assembled in the receiver. If characters are actually
being received at the maximum character rate as defined by
the bit data rate of the serial line, the RBUF must be read
within one character time or an overflow error will occur on
the SLU and data will be lost.

The transmitter also has only a one character buffer.
However,
while
this
restriction
may result in the
transmission of characters at a rate lower than the maximum
character rate, the transmitter can wait a theoretically
infinite time for the next character. No data will be lost
and no errors will occur.

Direct memory access (DMA) I/O has precedence over interrupt
I/O.
Therefore, if a DMA device and DL-type SLU wishing to
interrupt the processor are both requesting use of the bus,
the DMA device will be granted it. This does not normally
cause problems in systems which make use of single-cycle DMA
transfers.
An exception to this is when the system is
heavily loaded with a number of active DMA
devices.
However, the use of burst-mode DMA or, on the Q-bus,
block-mode DMA could conceivably lock out the interrupts
from the SLU for an appreciable length of time. This should
have little effect on the transmitter since it can wait
indefinitely for interrupts, but it could have a disastrous
effect on the receiver, resulting in the loss of data and
the generation of overrun errors.

294

uNOTE # 033
Page 7 of 14
1.4 DIGITAL'S DL-TYPE SLUs
Digital manufactures a variety of DL-type SLUs for both the Q-bus and
the UNIBUS.
The following list is compilation of those currently
available.
1.

Q-bus compatible, DL-type SLUs

DLV11 - a single line, DL-type SLU on one dual
height module. Data rate from 50 to 9,600 bits
per second, full duplex, data leads only (no
modem control).
RS-232-C and 20 mae
current
loop serial line interfaces.

DLVE1
(formerly DLV11-E)
a single
line,
DL-type SLU on one dual height module.
Data
rate from 50 to 19,200 bits per second,
full
duplex with limited modem control.
RS-232-C
serial line interface.

DLVJ1
(formerly DLV11-J)
four individual,
DL-type SLUs on one dual height module.
Data
rate from 150 to 38,400 bits per second,
full
duplex, data leads only (no modem control).
RS-232-C serial line interface.

UNIBUS compatible, DL-type SLUs
A.

DL11 - single line,
DL-type SLU on one quad
height small peripheral controller (SPC) module.
Data rate from 50 to 9600 bits per second,
full
duplex.
A number of variations are available
some including modem control and line time clock
interfaces.
RS-232-C and 20 mae
current loop
available.

Digital produces two multifunction modules for the Q-bus,
the MXV11-A and the MXVI1-B, which contain DL-type SLUs.
These are intended for the board-level applications where
RAM and ROM memory and SI,Us in a single compact board are
required.

Addit~onally,

Digital manufeLctures a DL-type SLU on a chip,
the DC319-AA DLART.
The DLART is used in several of
Digital's systems as the console terminal SLU for processor
modules such as the KDJ11-B.

295

uNOTE # 033
Page 8 of 14
2.0 DL-TYPE SLU APPLICATIONS
The following are examples of the potential uses
systems.
1.

for

DL-type

SLUs

In general, DL-type serial line units are required for the
console device interface on all POP-II processors for three
functions:
A.

Console ODT - the console ODT routines in these
processors
can
communicate
with
DL-type
interfaces only.

Diagnostics - diagnostics which run under XXDP
and DEC/XII assume the use of a DL-type console
interface.

Operating system console - the operating systems
which run on PDP-11 processors require DL-type
SLUs for the system console.
Even if the
console interface device can be redirected to
another serial line, as is possible in the RSX
family of operating systems, the crash and panic
dumps routines usually require the use of a
DL-type SLUe

The reason DL-type interfaces are used for these functions
is that they are the simplest, most reliable serial line
unit available. If a system is down, having a DL-type SLU
as the console interface will almost always eliminate the
possibility that the problem is with the console interface.
2.

DL-type SLUs are also used in some systems to provide
Their
use
for this
interactive
terminal
support.
are
application is not recommended for reasons which
discussed later in this document.

Applications requiring the use of a serial hardcopy terminal
as a low-cost system printer may use the DL-type SLU as the
interface.

Applications which require immediate attention to a serial
data stream may require a DL-type SLU as the interface. The
serial data stream is most often from an instrumentation
device, ~uch as a thermocouple, in a process control
environment.

The next sections examine the configuration of DL-type
environments.

296

SLUs

system

uNOTE # 033
Page 9 of 14
3. 0 SYSTEM CONFIGURATION OF DL-TYP:e: SLUS
There are several items which
DL-type SLUs into systems.

must

considered

when

configuring

The data rate at which the SLU is expected to transfer data
to and from the serial line, and the impact on the host
processor's I/O bus.

The aggregate data rate expected from all dev~ces on the
host processor's I/O bus. This includes the amount and mode
of DMA activity on the bus and its potential effect on the
processor's response to the DL-type SLU.

The interrupt priority of the SLU on
bus.

the

host

processor's

In the following discussions, ,~e use an example based upon the
configuration of a DLVJ1 quad SLU in a Q-bus system. with the except~on
of block-mode DMA (which does not exist on the UNIBUS) the example 1S,
in general, valid for both Q-bus and UNIBUS PDP-11 and VAX processors.
It must be remembered, however,
that the configuration is largely
dependent upon the system application which may alter some of the rules
presented.

3.1 DLVJ1 DESCRIPTION AND CONSIDEru\TIONS FOR USE
The DLVJ1 is a dual height Q-bus module consisting of four
individually
programmed RS-232-C/RS-449/RS-423 compatible DL-type SLUs. Although
they share common Q-bus transceivE~rs and device selection and data
gating logic,
the four SLUs each have their own sets of serial line
interfaces circuits, Universal Asynchronous Receiver Transmitter
(UART)
circuits,
and DC003 interrupt controller circuits. This, in effect,
gives the system·designer four individual DL-type serial line units each
with its own set of CSRs and data buffer registers and data rates to
38.4K bits per second per channel.
The four DC003 interrupt controllers are configured and wired. in Q-bus
compatible fashion for bus request level four Only (BR4) devices.
That
is, BIAKI comes in from the bus, through the first DC003,
and out as
BIAKO which then goes to the BIAKI input of the second DC003.
The
second De003 then routes the BIAK signal to the third De003 and the
third to the-fourth which then routes its BIAKO signal out to the Q-bus
for continuation of the daisy chain. The Q-bus specification provides
for two methods of establishing device priority:

297

uNOTE • 033
Page 10 of 14
1.

Distributed arbitration - priority levels are implemented in
hardware on the device. Devices must monitor all interrupt
requests with higher priority than their own and pass
through the interrupt acknowledge if one exists. When
devices
of
equal
priority
request
an
interrupt
simultaneously
,
priority
is
given
to the device
electrically closest to the processor.

Position-defined arbitration - priority is determined solely
by electrical position on the bus. The closer a device is
to the processor, the higher its priority is. Devices which
use
position-defined
arbitration
must
be placed in
descending bus request order after any devices
which
implement distributed arbitration.

Digital has produced only one Q-bus device with multiple interrupt
request levels, the TSV05.
All other devices produced to date have
implemented BR4 only, and depend upon position-defined arbitration for
their priority.
This is largely due to the standard Q-bus interface
chips' lack of circuitry required to perform the higher level bus
request monitoring.
Due to the implementation of the bus, UNIBUS
devices do not have this restriction. For further information on the
subjects of interrupt priorities and device placement consult the PDP-11
Architecture Handbook (EB-23657) and the Microcomputer Products Handbook
(EB-26078).
Receiver done and transmitter done interrupt requests are wired to the
DC003's so that the four receiver done interrupts have higher priority
than the four transmitter done interrupts.
Elevating the receivers'
done interrupt priorities over the transmitters' done interrupts helps
reduce the potential for lost input characters due to receiver data
overrun errors. Transmitter operation is essentially unaffected, except
potentially in throughput, since the transmitters will hold their
interrupt
requests
indefinitely.
This configuration i~ actually
preferable to that of four individual DL-type interfaces (DLVE1, etc.
on the Q-bus or DL11 on the UNIBUS) which would have the transmitter
done interrupts placed between the receiver done interrupts.
The device address selection and vector address generation circuits
allow the DLVJ1 to be configured at a number of different base addresses
and vectors, Channel three may be configured for use as the system
console device interface and it is this capability, not its cost, that
has made the DLVJ1 an extremely popular option.
The serial interfaces are capable of data-Ieads-only interfacing (i.e.
transmit data, receive data and ground) to external equipment. That is,
there is no modem control capability in the DLVJ1. This is usually of
no consequence since the largest use of this device is for local console
device and terminal interfacing. If the user requires modem control,
the DLVE1 is available.
If the interface is not being used for the
console terminal, asynchronous multiplexers with modem control such as
thE~
DzV11 and DHV11 are available and are preferable in almost all
applications.

298

UNOTE # 033
page 11,of 14
3.2 SLU DATA RATE CONSIDERATIONS
The UART used in the DLVJl is the 6402 which is a member of a generic
UART family in wide use in a large number of Digital and third party
vendor products, including the DLVE1 and DLV11 Q-bus options and the
OL11 UNIBUS option. They are very similar to Digital's DLART interface
chip which is used on the
MXV11-B
multifunction
module,
the
MicroPDP-l1/23 and PDP-l1/23-PLUS processor board (KDF11-Bx), and the
MicroPDP-11/73 processor board (KDJ11-Bx).
The 6402 provides one level of buffering on input and output data with
the implementation of a receiver data holding register and a transmitter
data holding register respectively. While the level of buffering is
relatively unimportant to the transmitter due to its ability to wait
indefinitely for additional characters, it is extremely important to the
receiver. To illustrate this the following example is used:
The 6402 provides a receiver register which holds the current,
incoming character. The data is transferred into thi~ register
at the bit data rate at which the serial line is runnIng.
The
time required to fill the receiver register can be calculated as
follows:
t =·1 /

(bit data rate) * (number of bits per character)

Where t is the character time and the number of bits per
character includes the start bit, all data bits, parity
bit if used, and all stop bits.
picking some common numbers for this example:
Bit data rate = 9600. bits per second.
Number of data bits = 8.
Number of parity bits = O.
Number of stop bits = 1.
The character time is therefore:
t = 1/9600*(1+8+0+1)
t - 1.041 msec.

per character

Therefore, at a 9600 bits per second data rate, the time from
the start of transmission of the character to the time the
character is loaded into the receiver buffer register is
approximately one millisecond.

299

uNOTE # 033
Page 12 of 14
If the next character starts transmission immediately,
the
processor has at least one character time before the receiver
buffer register must be emptied so that it can accept the
current input character,
in this case one millisecond.
This
implies that the receiver done interrupt must be serviced within
that time also.
Provided that the combination of software and
hardware is capable of servlclng the interrupt within
a
character time the receive data should never overrun.
Therefore, limiting the serial data rate will help reduce the amount of
system resources required to service the SLU and optimize processor
time.
Specifically it increases the allowable interrupt response
latency before data overrun would occur.

3.3 HOST PROCESSOR AGGREGATE DATA RATE CONSIDERATIONS
ThE~
D~\

above example does not take into account any other bus interrupt or
activity which will impact the speed at which the DLVJ1 interrupt is
serviced.
To minimize the effects of the host processor's aggregate
data rate two configuration rules should be followed:
1.

The data rate on the DLVJ1 devices should be kept to a
reasonable limit which is usually considered to be at or
below 1200 bits per second.
This allows additional time for
the processor to service the receiver done interrupt and
will keep the the amount of bus activity due to serial line
interrupts reasonable.

Careful attention should be given to the amount and mode
(i.e.
single cycle, burst, or block) of DMA activity on the
host processor's bus.
Large quantities of DMA traffic mean
that the processor has less time to service interrupts which
have a lower priority than DMA operations.
Devices doing
burst and block mode DMA operations may hold the bus for
long periods of time, causing interrupts to be blocked for
the duration of the DMA operation.
This results in data
from the receiver being lost or data to the transmitter
being postponed.

3.4 INTERRUPT PRLORITY OF THE DL-TYPE SLU
The DL-type SLU should be configured as
the
highest
priority
interrupting device on the bus if at all possible.
In most cases this
will result in the SLU being the first device on the bus, with the
possible exception of the line time clock or BEVNT line.
This is

300

uNOTE # 033
Page 13 of 14
consistent with the MicroPDP-ll's, PDP-ll/23-PLUS's
,
and the UNIBUS
processors, which have their console device interfaces very close to the
beginning of the bus.
By placing the
possible,
the
devices on the
the
rest of
resulting in a

DL-type SLUs as close .to the beginning of the bus as
interrupt priority is elevated above that of the other
bus.
This allows interrupt requests to serviced before
the devices and immediately after the DMA activity,
reduced possibility of data loss.

4.0 SUMMARY AND RECOMMENDATIONS
The DL-type SLUs are
required by PDP-II systems as their console
interface.
There are several options which may be used to provide this
function.
Theses include theDLVxx series options on the Q-bus and DLxx
series options on the UNIBUS.
Additionally,
several multifunction
options and processors have DL-type interfaces integrated into them.
These include the MXVII-A, MXVII-B, KDFII-B and KDJII-B.
The use of all DL-type SLUs should be limited in most systems
(special
applications may have valid uses of DL-type devices).
They should, in
most circumstances, be used only for the console device interface and
serial printer applications.
The use of an asynchronous multiplexer is
recommended for all other serial line requirements,
excepting special
applications.
The use of any DL-type SLU for an interactive terminal on a multiuser
system is indicative of a poor system configuration.
In this case, the
proper configuration would include asynchronous multiplexers such as
DZVll's,
DZQll's,
or DHVll's (or their UNIBUS counterparts) to provide
efficient handling of terminal
interfaces with the minimum of bus
activity and operating system overhead.
The use of a DL-type SLU as a low cost printer port is exempt from the
above statement because it incurs approximately the same overhead as the
LPVll or LPll-type line printer controller.
However,
the use of an
asynchronous multiplexer with DMA output, such as the DHVll, may provide
a more efficient method of handling printers, depending upon the
implementation.
The data rate at which any DL-type SLU operates should be kept to a
minimum,
particularly when receiving data, to ensure that the amount of
bus activity is as low as possible since these interfaces are
interrupt
intensive.
This holds for any inte'rrupt intensive device (parallel I/O
devices such as DRVlls, etc.) in general.
The problem is not that of
interface limitations but of the amount of bus bandwidth available to
support the aggregate bus data rate.

301

uNOTE # 033
Page 14 of 14
The DL-type SLU should be p~aced in as high an interrupt priority
position as possible to lnsure adequate servicing by software.
This
will not affect DMA activity since it holds priority over
bus
interrupts.
The performance of most systems will not be affected by the
increased priority level of the maximum one or two DL-type interfaces
which are recommended to be active at one time.
NeVE!r place any device, including a DL-type interface, on the bus after
a FtQDX1 disk controller.
The RQDX1 does not pass through the DMA and
interrupt grant lines properly, thus producing unpredictable results and
often times "hung" devices.
Recommendations for the DL-type SLUs, and any other interrupt
devices, are:

intensive

Limit their use whenever possible.
Use
asynchronous
multiplexers or other more advanced interfaces whenever
possible. The cost savings of a DLVJ1 over a DZQ11 must not
overshadow the performance issues.

Limit the rate at which they operate.
For
DL-type
interfaces a good limit appears to be 1200 bits per second
or less although in some applications a higher rate may be
possible.

Place them so that they have as high an interrupt
as possible, in most cases the highest priority.

If a DL-type SLU is chosen for use, perform the calculations
as in section 3.2. Make a rational decision as to whether
the configuration can handle the data rates imposed.

priority

Following these few recommendations will result in improvE~d system
performance when configuring DL-type SLUs into systems.
For additional
information consult the appropriate technical manuals, user guides,
and
systems manuals for the specific devices under consideration.

302

[

programming the KXT11-C Multiprotocol SLU

Title:

uNOTE. 034

Date: 19-Jul-85
Page 1 of 24

Originator: Scott Tincher

The KXT11-CA single board computer provides a two-channel multiprotocol
serial line unit.
The SLU is implemented with an NEC uPD7201 chip.
This Micronote will explain the operation of this SLU and provide
example programs which display its capabilities. The example programs
will be written in Macro-11 so it is assumed that the programmer is
familiar with Macro-11 and either the RT-11 or RSX KXT11-C Software
Toolkits.
It should be noted that the DIGITAL operating system
Micropower/pascal provides a device handler for the uPD7201 chip.
FEATURES/CAPABILITIES
The multiprotocol SLU supplies the KXT11-C with the
and capabilities:
o

following

Two full duplex channels
Channel A provides full modem control
Channel B provides data and timing leads only

Each channel may be operated in one of three modes:
Asynchronous
o

5, 6, 7, or 8 Data bits

1, 1-1/2, or 2 stop bits

Odd, Even, or No parity

Break

Interrupt on parity, Overun, or Framing Errors

gen~ration

and detection

Charaster-oriented synchronous

303

features

uNOTE i 034
Page 2 of 24
o

Monosync, Bisync, and External Sync Operations

Software Selectable Sync Characters

Automatic Sync Insertion

CRC Generation and Checking

Bit-oriented synchronous
o

HDLC and SDLC Operations

Abort Sequence Generation and Detection

Automatic Zero Insertion and Detection

Address Field Recognition

CRC Generation and Checking

I-Field Residue Handling

Programmable Baud Rates

Double Buffered Transmitted Data

Quadruply Buffered Received Data

Programmable CRC Algorithm

Channel A may utilize the DMA controller to transfer data

REGISTER DESCRIPTION
The multiprotocol SLU is controlled by manipulating the registers of the
uPD7201 chip as well as registers in support chips that provide access
to the baud rate generator and the modem control signals. This section
will provide a brief description of the registers necessary to program
the multiprotocol SLU.
uPD7201 Registers
This section will describe the registers found in the uPD7201 itself.
~rhese
registers are found in both channels of the uPD7201 unless
otherwise indicated.
Control Register 0
7

304

uNOTE
034
Page 3 of 24
Bits 0,1,2:

These bits are used to specify which register will be
affected by the next Control Register Write or status
Register Read. After a reset the register pointer is set
to o.
When the register pointer is set to a value other
than 0 the next control or status access is to the
specified register, then the pointer is reset to O.
Bits 3,4,5:

Command

These bits are used to select the command to be
the uPD7201. A list of these commands follows:

sent

NULL (000)
This command has no effect and is used when
register pointer or issuing a CRC command.

setting

the

SEND ABORT (001)
When operating in the SOLe mod~, this command
uPD7201 to transmit the SOLC abort code.

causes

the

RESET EXTERNAL/STATUS INTERRUPTS (010)
Clears any pending external interrupts and reenables
latches so that new interrupts may be detected.

the

CHANNEL RESET (011)
After issuing a
reset
command
the
receivers
and
transmitters are disabled, the transmitters are set in the
marking (high) state, and the modem control outputs are
set high.
In addition, all interrupts are disabled, and
all interrupt and DMA requests are cleared.
All control
registers must be rewritten after a
reset.
One NOP
instruction must be issued before writing a new command.
ENABLE INTERRUPT ON NEXT CHARACTER (100)
When operating in Interrupt on First Character mode this
command is issued to re-enable the interrupt logic for the
next received character.
RESET PENDING TRANSMITTER INTERRUPT/DMA REQUEST (101.)
Issue this command to reset a pending Transmitter Buffer
Becoming Empty interrupt or DMA request without sending
another character.
ERROR RESET (110)
This command resets a Special Receive Condition interrupt.
It also re-enables the Parity and Overrun Error latches
that allow you to check for these errors at the end of a
m.essage.
END OF INTERRUPT (111)

(Channel A only)

305

uNOTE # 034
Page 4 of 24
When an interrupt request has been issued by the uPD7201
all lower priority interrupts are blocked to permit the
current interrupt to be serviced. At some point in the
interrupt service routine this command must be issued to
re-enable the daisy chain and permit any pending lower
priority interrupt requests to occur.
Bits 6,7:

CRC Control Commands
the

eRC

NULL (00)
This command has no effect and is used when issuing
commands or setting the register pointer.

other

These commands control
generator/checker logic.

operation

the

RESET RECEIVER CRC CHECKER (01)
This command resets the CRC checker to 0 when the channel
is in a synchronous mode and resets to all ones when is
SDLC mode.
RESET TRANSMITTER CRC GENERATOR (10)
This command resets the CRC generator to 0 when the
channel is in a synchronous mode and resets to all ones
when is SOLC mode.
RESET IOLE/CRC LATCH (11)
This command resets the Idle/CRC latch so that when a
transmitter underrun condition occurs,
the transmitter
enters the CRC phase of operation and begins to send the
16-bit CRC character calculated up to that point.
The
latch is then set so that if the underrun conition
persists,
idle characters are sent following the CRC.
After a hardware or software reset, the latch is in the
set state.
Control Register 1
7

Bit 0:

External/Status Interrupt Enable
When this bit is set to one,
the uPD7201
interrupt-whenever any of the following occur:
o

transition of OCO input

306

issues

uNOTE i 034
Page 5 of 24

Bit 1:

transition of CTS input

transition of synch input

entering or leaving synchronous
break detection or termination

SDLC abort detection or termination

Idle/CRC

phase

becoming set (CRC being sent)

Transmitter Interrupt Enable
When this bit is
interrupt when:

Bit 2:

la~ch

Hunt

set

one,

the

uPD7201

issues

The character currently in the transmitter buffer is
transferred to the shift register (Transmitter Buffer
Becoming Empty)

The transmitter enters
Idle
Phase
transmitting sync or flag characters

and

begins

Status Affects vector (Channel B only)
This bit must always be programmed to one so that the
fixed vector programmed into Control Register 2B is
modified to indicate the cause of the interrupt.

Bits 3,4:

Receiver

Interrup~

Mode

This field determines how the
character receive conditions.

uPD7201

handles

the

RECEIVER INTERRUPTS/DMA REQUEST DISABLED (00)
The uPD7201 does not issue an interrupt or DMA
request
when
a character has been received.
(Polled Mode).
INTERRUPT ON FIRST RECEIVED CHARACTER ONLY (01)
The uPD7201 issues an interrupt for
the first
character received after an Enable Interrupt on
First Character Command (CRO) has been given.
If
the channel is in DMA mode then a DMA request is
issued for each character received including the
first.
INTERRUPT ON ALL RECEIVED CHARACTERS (10)
An interrupt is issued whenever a character is
present in the receive buffer. A DMA request is
issued if the chclnnel is in DMA mode.
A parity
error is considered a special receive condition.

307

uNOTE # 034
Page 6 of 24
INTERRUPT ON ALL RECEIVED CHARACTERS (11)
This mode is the same as above except that a parity
error
is
not
treated as a special receive
condition.
The following
conditions:

Bits 5,6,7:

are

always

considered

Receiver Overrun Error

Asynchronous Framing Error

SOLe End of Message

receive

special

These bits should always be programmed to O.

Control Register 2 (Channel A)

4
Bits 0,1:

DMA Mode Select

These bits det~rmine the mode in which channels A and B
operate.
If a channel operates in a non-OMA mode it my
perform transfers in either polled or interrupt mode.

Bit 2:

Bit 1

Bit 0

Channel A

Channel B

0
0
1
1

0
1
0
1

Non-DMA
DMA
Illegal
Illegal

Non-DMA
Non-DMA
Illegal
Illegal

Priority
This bit is used to select the appropriate internal
priorities for interrupts. The Channel A receiver always
has a higher priority than the Channel A transmitter when
Channel A is in DMA mode.
If Channels A and B are both in Interrupt Mode:

o - RxA > TxA > RxB > TxB > extA > extB
1 - RxA >-RXB > TxA > TxB > extA > extB
If Channel A is in DMA mode and Channel B is in
Mode:

308

Interrupt

uNOTE # 034
Page 7 of 24
0,1 - RxA > RxB > TxB > extA > extB
Bits 3,5,6,7:
Bit 4:

These bits must be programmed to O.

This bit must always be programmed to 1.

control Register 2 (Programmed in Channel B for both channels)
[ 7

Bits 0 .. 7:

Interrupt vector

The native firmware of the KXT11-C initializes the uPD7201
interrupt vector to 70(8).
All interrupts use this
vector. In order to determine the cause of the interrupt
the uPD7201 must be operated with Condition Affects vector
enabled.
(Control Register 1 - Bit 2). When this bit is
set the vector is modified to reflect the cause of the
interrupt. This modified vector is read from status
Register 2.
control Register 3
[ 7
Bit 0:

Receiver Enable

o - Disables the receiver
1 - Enables the receiver
Bit 1:

Sync Character Load Inhibit
In a synchronous mode, this bit inhibits the transfer of
sync characters to the receiver buffer. When using the
uPD7201's CRC checking capabilities this feature should
only be used to strip leading sync characters preceding a
message since the load inhibit does not exclude sync
characters
embedded
in
the
message from the CRC
calculations. Synchronous protocols using other types of
block checking such as checksum or LRC are free to strip
embedded sync characters with this bit.

309

uNOTE I 034
Page a of 24
Bit 2:

Address Search Mode
In SOLC mode, setting this bit places the uP07201 in
Address Search mode where character assembly does not
begin until the a-bit character (secondary address field)
following the starting flag of a message matches either
the address programmed into CR6 or the global address
11111111.

Bit 3:

Receiver CRC Enable
This bit enables (enable - 1) the CRC checker in COP mode
to
allow
the
selective inclusion or exclusion of
characters form the CRC calculation.

Bit 4:

Enter Hunt Phase
The uPD7201 automatically enters Hunt Phase after a reset.
Setting this bit to 1 causes the uP07201 to re-enter the
Hunt Phase.

Bit 5:

Auto Enables
Setting this bit to 1 causes the OCO and CTS inputs to act
as
enable
inputs to the receiver and transmitter,
respectively.

Bits 6,7:

Number of Received Bits/Character

This field specifies the number of data bits per
character:
Bit 7

Bit 6

0
0

1
1

received

Bits/Character

1
0
1

7
6
a

Control Register 4
7

Bit 0:

Parity Enable
Setting this bit to 1 adds an extra data bit containing
parity information to each transmitted cahracter. Each
received character is expected to contain this extra bit
and the receiver parity checker is enabled.

310

uNOTE # 034
Page 9 of 24
Bit 1:

Parity Even/Odd

o - Odd parity generation and checking

1 -

Bits 2,3:

Even parity generation and checking

Number of stop Bits/Sync Mode

This field specifies whether the channel is used in a
synchronous mode or in asynchronous mode. In asynchronous
mode, this field also specifies the number of stop bits
used by the transmitter. The receiver always checks for
one stop bit.
Bit 3

Bits 4,5:

Bit 2

0
1
1

Mode
Synchronous mode
Asynch Mode, 1 stop bit
Asynch Mode, 1-1/2 stop bits
Asynch Mode, 2 stop bits

Sync Mode

These bits select the synchronous protocol to use if
channel has been programmed in a synchronous mode.

Bits 6,7:

Bit 5

Bit 4

0
0
1
1

0
1
0
1

the

Mode
Monosync
Bisync
SDLC
External Synchronization

Clock Rate

These bits
specify
the
relationship
between
the
transmitter and receiver clock inputs and the actual data
rate. When operating in synchronous mode the clock rate
must be specified as 1X the data rate.
Bit 7

Bit 6

0
0
1
1

0
1
0

Clock Rate
Clock Rate == 1X Data Rate
Clock Rate = 16X Data Rate
Clock Rate = 32X Data Rate
Clock Rate = 64X Data Rate

Control Register 5

Li I
Bit 0:

Transmitter CRC Enable

311

uNOTE # 034
Page 10 of 24
A 1 enables the CRC generator calculation. By setting or
resetting this bit just before loading the next character,
it and subsequent characters are included or excluded from
the calculation.
Bit 1:

RTS
In synchronous and SOLC modes, setting this bit to 1
causes the RTS pin to go low while a 0 causes it to go
high. In asynchronous mode, setting this bit to 0 does
not cause RTS to go high until the transmitter is
completely empty.

Bit 2:

CRC polynomial Select
A 0 selects the CRC-CCITT Polynomial (X**16 + X**12 + x**5
+ 1). A 1 selects the CRC-16 polynomial (X**16 + X**15 +
X**2 +1).
The CRC-CCITT polynomial must be selected when
in SOLC mode.

Bit 3:

Transmitter Enable
After a reset the transmitted data output is held high
(marking) and the transmitter is disabled until this bit
is set.

Bit 4:

Send Break
Setting this bit to 1 forces the
(spacing).

Bits 5,6:

transmitter

output

low

Transmitted Bits/Character

These bits specify the number of data bits per transmitted
character.
Bit 6

Bit 5

1
1

Bit 7:

Bits/Character
5 (or less)

OTR
When this bit is 1, the OTR output is active.

Control Register 6
7

312

uNOTE # 034
Page 11 of 24
Bits

0.~7:

Sync Byte 1

Sync byte 1 is used in the following modes:
Monosync:

The a-bit character transmitted during
the Idle Phase.
The least significant a bits of the 16-bit
transmit and receive sync character.
Sync character transmitted during
the Idle Phase.
Secondary address value matched to the
Secondary Address field of the
SOLC frame when the uP07201 is in Address
Search Mode.

Bisync:
External Sync:
SOLC:

Control Register 7
7

Bits 0 .. 7: Sync Byte 2
Sync Byte 2 is used in the following modes:
Monosync:
Bisync:

a-bit sync character matched by the receiver.
Most significant a bits of the 16-bit transmit
and receive sync characters.
Must contain the flag value, 01111110, for flag
matching by the uP07201 receiver.

SOLC:
Status Register 0
7

Bit 0:

Received Character Available
When this bit is set, it indicates that one or more
characters are available in the receiver buffer. Once all
of the available characters have been read, the uP07201
resets this bit until a new character is received. By
utilizing this bit the programmer my run at higher data
rates than normal because it will be possible to capture
more that one character per interrupt service routine.

Bit 1:

Interrupt Pending (Channel A only)
The interrupt pending bit is used with the interrupt
vector register (status register 2) to make it easier to
determine the uP07201's interrupt status. In Non-vectored

313

uNOTE # 034
Page 12 of 24
Interrupt mode,
interrupt pending is set when status
register 2B is read.
If status affects vector is enabled
and interrupt pending is set, the vector read from SR2
contains valid condition information.
Bit 2:

Transmitter Buffer Empty
This bit is set whenever the transmitter buffer is empty,
except during the transmission of the CRC. After a reset,
the buffer is considered empty and transmitter buffer
empty is set.

Bit 3:

DCD (Data Carrier Detect)
This bit reflects the inverted state of the DCD input.
When DCD is low,
the DCD status bit is high. Any
transition of this bit causes an External/status Interrupt
request.

Bit 4:

Sync Status
The bit assumes different meanings
operating mode of the uPD7201.

depending

the

Asynch mode:
Sync Status reflects the inverted state fo
the Sync input.
Any transition· of this bit causes an
External/Status interrupt request.
External Sync mode:
Sync Status operates in the same
manner as asynch mode. A low-to-high transition indicates
that synchronization has been achieved and character
assembly begins.
Monosync,
Bisync, SDLC modes:
Sync Status indicates
whether the receiver is in the Sync Hunt (bit -1) or the
Receive Data phase (bit - 0) of operation.
Bit 5:

CTS (Clear to Send)
This bit reflects the inverted state of the CTS input.
Any transition of this bit causes an External/Status
interrupt request.

Bit 6:

Idle/CRC
This bit i~dicates the state of the Idle/CRC latch used in
synchronous and SDLC modes.

Bit 7:

Break/Abort
In async mode, this bit indicates that the detection of a
break sequence that occurs when the input is held low

314

uNOTE # 034
Page 13 of 24
(spacing) for more than one character time. This
reset when the input returns high (marking).

bit

In SOLC mode, Break/Abort indicates the detection of an
abort sequence when 7 or more ones are received in
sequence.
Any transition of the
Break/Abort
External/Status interrupt.

bit

causes

status Register 1

Bit 0:

All Sent
In async mode, this bit is set when the transmitter is
empty and reset when a character is present in the
transmitter buffer or shift register. In synchronous and
SOLC modes, this bit is always 1.

Bits 1,2,3:

SOLC Residue Code

The data portion of an SOLC message can consist of any
number of bits and not necessarily an integral number of
characters. Special logic determines and reports when the
End of Frame flag has been received, the boundary between
the data field, and the eRC character in the last few data
characters that were read.
Bit 4:

parity Error
This bit is set when parity is enabled and the received
parity bit does not match the sense calculated from the
data bits.

Bit 5:

Receiver Overrun Error
This error occurs when the receiver buffer
already
contains three characters and a fourth character is
completely received, overwriting the last character in the
buffer.

Bit 6:

eRC/Framing Error
In Async modem a framing error is flagged when no sop
is detected at the end of a character.

315

bit

uNOTE # 034
Page 14 of 24
In sync and SOLC modes, this bit indicates the
result of
the comparison between the current CRC result and the
appropriate check value.
Bit 7:

End of SOLC Frame
This flag is used in SOLC mode to indicate that the End of
FRame flag has been received and that the CRe error flag
and residue code is valid.

status Register 2
7

Bits 0 .. 7:

Interrupt Vector (Channel B only)

Reading Status Register 2B returns the interrupt vector
that
was
programmed into Control Register 2B.
If
Condition Affects Vector is enabled the value of the
vector is modified as follows:
Condition Affects Vector Modifications
Bit 2

Bit 1

Bit 0

1
0
0
1
1
0
0
1
1

1
0
1
0
1
0
1
0
1

0
0
0
1
1
1
1

Condition
No interrupt pending
Channel B Transmitter Buffer Empty
Channel B External/Status Change
Channel B Received Character Available
Channel B Special Receive Condition
Channel A Transmitter Buffer Empty
Channel A External/Status Change
Channel A Received Character Available
Channel A Special Receive Condition
- Table 1 -

Code 111 has two meanings:
either Channel A Special
In order to
Receive Condition or no interrupt pending.
distinguish between the two,
the Interrupt Pending bit
(SRO) must be examined.
Baud Rate Generator Registers
Programmable baud rates for channels A and B are supplied by an
Intel 8254-2 timing controller chip with two counters operating
at 9.8304 MHz. A third counter that operates at 800 Hz is
available for general use.
This general purpose counter issues a
level 6 interrupt request to the T-11 via vector 104.

316

uNOTE # 034
Page 15 of 24
Programming these counters is straightforward.
First,
Control register is initialized to provide the proper
mode. Then a divider ratio is loaded into a Timer Data
to obtain the desired baud rate. The divider ratio is
from the following calculations:

a Timer
counting
register
obtained

For synchronous transmission,
Synchronous bit rate - 9830.4K / divider ratio
Therefore,
divider ratio = 9830.4K / synchronous bit rate
A few examples,
Bit Rate

Ratio

1200
9600
38.4K
76.8K

8192
1024
256
128

For asynchronous transmission (assuming that the
divided by 16),

clock

rate

Asynchronous bit rate = 9830.4K (1/16) / divider ratio
Therefore,
divider ratio = 614.4K / asynchronous bit rate
A few examples,
Bit Rate

Ratio

1200
9600
38.4K
76.8K

512
64
16
8

Timer Control Register
7

317

uNOTE # 034
Page 16 of 24
Bit 0:

BCD or Binary

o - Use 16-bit binary counter
1 - Use BCD counter with four decades
Bits 1,2,3:

Mode Select

The mode of the counter is selected with these bits:

Bits 4,5:

Bit 1

Bit 3

Bit 2

0
0
0
0
1
1

0
0
1
1
0
0

1
1

0
1
0
1
0

Mode
Interrupt on Terminal Count
Not supported
Rate Generator
Square Wave Generator
Software Triggered Strobe
Not supported
Reserved
Reserved

0
1

Read/Write Sequence Selection

The Timer Data registers are programmed on a byte basis.
These bits determine the sequence in which the Timer Data
registers interpret the data.

Bits 6,7:

Bit 5

Bit 4

o
o

1
1

o
o

Sequence
Counter Latch Command
Read/Write least significant byte only
Read/Write most significant byte only
Read/Write least significant byte first,
then most significant byte

Counter Select

These bits select which counter is being programmed.
Bit 7

Bit 6

0
0
1

0
1
0

Counter
Counter 0
Counter 1
Counter 2
Read-back command

KXT Control/Statcrs Register A
4

This register contains some of the control lines for the uPD7201.

318

uNOTE i 034
Page 17 of 24
Bit 0:

SYNCM B

o - Channel B receives its clock

~rom
the onboard baud
rate generator
1 - Channel B receives its clock from an external source

Bit 1:

SLU2B R EN

o - Party line receive data enabled
properly configured)
1 - party line receive data disabled
Bit 2:

(Board

must

SYNCM A

o - Channel A receives its clock

from the onboard baud
rate generator
1 - Channel A receives its clock from an external source
Bit 3:

Data Terminal Ready (DTR)

o - DTR is not asserted
1 - DTR is asserted
Bit 4:

Terminal in Service (Busy)

o - Terminal in Service is not asserted
1 - Terminal in Service is asserted
Bit 5:

Diagnostic Prom Enable
This bit allows two different 1K portions of the onboard
firmware to be visible at addresses 160000-163777.

Bit 6:

Real Time Clock Enable

o - The RTC interrupt is inhibited
1 - The RTC interrupt is enabled
Bit 7:

Counter 2 Interrupt Enable

o - Counter 2 interrupts are inhibited
1 - Counter 2 interrupts are enabled
The following table lists the registers that have been
and their add~esses:

described

KXT Control/Status Register A

177520

Read;Write

Timer Control Register
Timer 2 Data Register
Timer 1 Data Register

175736
175734
175732

Write only
Write only
Write only

319

uNOTE # 034
Page 18 of 24
Timer 0 Data Register
Timer 2 Data Register
Timer 1 Data Register
Timer 0 Data Register

175730
175724
175722
175720

Write only
Read only
Read only
Read only

Channel B Transmitter
Channel B Control Register
Channel B Receiver
Channel B status Register
Channel A Transmitter
Channel A Control Register
Channel A Receiver
Channel A status Register

175716
175714
175712
175710
175706
·175704
175702
175700

write only
Write only
Read only
Read only
Write only
Write only
Read only
Read only

- Table 2 ;E»ROGRAMMING EXAMPLES
'rhe following programs provide 'skeletons' on which to base
application programs •
• TITLE

user

SLU1.MAC

This program utilizes the uPD7201 to transfer serial data. The
data will be transfered out of Channel A and received by Channel
A so a loopback connector is required (Part #H3022 or 54-16229-01)
This example transfers the data in asynchronous mode using
interrupts.
;
;

;

SET 2
LOAD SLU1.SAV
EXECUTE
lOOT

;
;

;

;
;

1001206
'001302/041101
001304/042103
001306/043105
001310/044107
001312/041101
001314/042103
001316/043105
001320/044107
001322/000000
R4/000000

320

uNOTE
034
Page 19 of 24
EXIT

;

This verifies that the data was successfully transfered. 1302 is
the address of the transmit buffer and 1312 is the address of the
receive buffer. R4.0 verifies that no external or special
condition interrupts were received.

. Register Definitions

STATA
RBUFA
CNTRLA
TBUFA

175700
175702
175704
175706

Channel A status register
Channel A receiver
Channel A Control register
Channel A transmitter

STATB
CNTRLB

175710
175714

Channel B status register
Channel B control register

TIMREG
TIMERO

175736
175730

Timer control register
Timer o data register

START: :
This section initializes the KXT11-C system environment
MTPS

#340

Disable recognition of interrupts

MOV
MOV

#ISR,@#70
#340,@#72

SLU2 interrupts at location 70
Let the ISR run at priority 7

CLR

This is the transmit char counter

MOV
MOV

#TBUF,R2
#RBUF,R3

R2 points to the transmit buffer
R3 points to the receive buffer

CLR

This counter keeps track of external
status changes and special receive
receive conditions

This section initializes the bit rate generator

;

MOVB

#26,TIMREG

MOVB

#64.,TIMERO

; Select timer 0, low byte only,
; mode 3, binary
This divider selects 9600 bps

This section initializes the 7201 for asynch operation
MOVB
NOP

#30,CNTRLA

MOVB
NOP

#30,CNTRLB

;

Reset Channel A
Wait for reset to complete
Reset Channel B
Wait for reset to complete

321

uNOTE # 034
Page 20 of 24
MOVB
MOVB

#2,CNTRLA
#24,CNTRLA

Point to CR2A
setup bus interface options:
No DMA, RxA>RxB>TxA ... , Non-Vectored

MOVB
MOVB

#4,CNTRLA
#104,CNTRLA

Point to CR4
Set operation mode:
No parity, asynch mode, 1 stop bit,
clock rate = 16x data rate

MOVB
MOVB

#3,CNTRLA
#301,CNTRLA

Point to CR3
Enable receiver, char length - 8

MOVB
MOVB

#5,CNTRLA
#152,CNTRLA

Point to CR5
Enable transmitter, Char length - 8

CLRB
MOVB

CNTRLA
#20,CNTRLA

Point to CRO
Reset External/Status Interrupts

MOVB
MOVB

#l,CNTRLA
#36,CNTRLA

Point to CRl
Transmit IE, Interrupt on all
received chars, enable condition
affects vector

MTPS
MOVB
BR

#0
(R2)+,TBUFA

Enable recognition of interrupts
Send first character
Stay here while the interrupts occur

MOVB
MOVB

#2,CNTRLB
STATB,-(SP)

Point to SR2B
Store the condition affects vector
on the stack

MAIN: :

ISR: :

;

This section inspects the condition affects vector to
determine the cause of the interrupt

ROR
BCS

(SP)
EXT

ROR
BeS

(SP)
RCV

Rotate bit 0 into the carry bit
If this bit was set then the
interrupt was caused by a special
receive condition or an external/
status change
Rotate bit 1 into the carry bit
If this bit was set then the
interrupt was caused by a received
character

If neither of the above conditions was
satisfied then the interrupt must have
been caused by the transmitter buffer
going empty
;XMIT: :

322

uNOTE # 034
Page 21 of 24

1$:
RCV: :

INC
CMP
BEQ
MOVB
BR
MOVB
BR

RO
RO,#8.
1$
(R2)+,TBUFA
IDONE
#50,CNTRLA
IDONE

Increment the xmit char counter
IF this is the eight char
THEN branch to 1$
ELSE send another char
and return
reset pending xmit interrupt
request - then return

MOVB
BR

RBUFA,(R3)+
IDONE

Store this character
and return

EXT: :

This program does not take any special action if an
External/Status interrupt or Special Receive Condition
occurs.
Just note that it occurred (there shouldn't be
any) and continue.
R4

Increment the counter
and return

IDONE:: TST
MOVB
RTI

(SP)+
#70,CNTRLA

Fix the stack
Issue end of interrupt command
and return to main program

TBUF::
RBUF::

.BYTE
.BLKB

101,102,103,104,105,106,107,110
8.

.END

START

.TITLE

SLU2.MAC

INC

;
;

This example program for the uPD7201 transfers serial data via
a loopback connector (part #H3022 or 54-16229) between Channel
A's transmit and receive using the DMA controller.
No ISR is
included in this example as it is meant to show how the uPD7201
and the DTC may work together. A 'real-life' program should
include an ISR which monitors any External or Special Receive
condition interrupts.
For more information regarding the
programming of the DTC please refer to MicroNote #018.

;

SET 2
LOAD SLU2.SAV
EXECUTE
.10DT

;

1001234

323

uNOTE # 034
Page 22 of 24
11276/041101
1001300/042103
1001302/043105
001304/044107
001306/041101
001310/042103
001312/043105
001314/044107
001316/000000
;

EXIT
This verifies that the data was tranfered successfully..
The
transmit buffer begins at address 1276 and the receive buffer
begins at address 1306.
Register Assignments
MMREG
CMDREG
CASTFO
CAOFO
CASTF1
CAOF1

Master Mode Register
Command Register
Chan 0 Chain Address
Chan 0 Chain Address
Chan 1 Chain Address
Chan 1 Chain Address

174470
174454
174446
174442
174444
174440

Seg/Tag Field
Offset Field
Seg/Tag Field
Offset Field

STATA
RBUFA
CNTRLA
TBUFA

175700
175702
175704
175706

Channel
Channel
Channel
Channel

A status register
A receiver
A Control register
A transmitter

STATB
CNTRLB

175710
175714

Channel B status register
Channel B control register

TIMREG
TIMERO

175736
175730

Timer Control register
Timer 0 Data register

START: :
;

This section initializes the KXT11-C system environment
MTPS

#340

MOV
MOV

#TBUF,R2
#RBUF,R3

Disable recognition of interrupts
R2 points to the transmit buffer
; R3 points to the receive buffer

This section initializes the bit rate generator
MOVB

#26,TIMREG

MOVB

#64.,TIMERO

Select timer 0, low byte only,
mode 3, binary
This divider selects 9600 bps

This section initializes the 7201 for asynch operation

324

uNOTE # 034
Page 23 of 24
MOVB
NOP

#30,CNTRLA

Reset Channel A
Wait for reset to complete

MOVB
NOP

#30,CNTRLB

Reset Channel B
; Wait for reset to complete

MOVB
MOVB

#2,CNTRLA
#2S,CNTRLA

MOVB
MOVB

#4,CNTRLA
#104,CNTRLA

; Point to CR4
Set operation mode:
No parity, asynch mode, 1 stop bit,
clock rate - 16x data rate

MOVB
MOVB

#3,CNTRLA
#301,CNTRLA

Point to CR3
; Enable receiver, char length - 8

MOVB
MOVB

#5,CNTRLA
#152,CNTRLA

Point to CRS
Enable transmitter, Char length - 8

CLRB
MOVB

CNTRLA
#20,CNTRLA

l?oint to CRO
Reset External/Status Interrupts

MOVB
MOVB

#l,CNTRLA
#16,CNTRLA

Point to CR1
Transmit IE, Interrupt on 1st
received char and issue DMA request
enable condition affects vector

Point to CR2A
setup bus interface options:
Chan A DMA, RxA>RxB>TxA ... ,
Non-Vectored

This section initializes the DMA controller
CLRB

CMDREG

Reset the DTC

MOV
MOV
MOV
MOV

#O,CASTFO
#LOADO,CAOFO
#0,CASTF1
#LOAD1,CAOF1

MOVB

#115,MMREG

Load Master Mode Reg to Enable DTC

MOVB
MOVB

#240,CMDREG
#241,CMDREG

start Chain Channel 0
Start Chain Channel 1

Load
Load
; Load
Load

Chain Address
Chain Address
Chain Address
Chain Address

Seg/Tag
Offset
Seg/Tag
Offset

MAIN: :
BR
;

stay here while the DMA transfers
occur

; Chain Load Region
LOAD1:

.WORD

001602

; Reload Word <Select CARA,CARB,COPC,CM)

325

uNOTE # 034
Page 24 of 24

LOADO:

TBUF::
RBUF: :

.WORD
.WORD

000000
TBUF

Current Address Regist~r A Seg/Tag
Current Address Register A Offset
<This local address is the source>

.WORD
.WORD

000020
TBUFA+1

Current Address Register B Seg/Tag
Current Address Register B Offset
<This local address is the destination>

.WORD

000010

Current Operation Count <Transfer 8 bytes>

.WORD
.WORD

000020
000001

Channel Mode Register High
Channel Mode Register Low
<No match conditions, do nothing upon
completion, transfer type - single transfer
CARA - source, byte transfers>

.. WORD

001602

Reload Word <Select CARA,CARB,COPC,CM>

.WORD
.WORD

000020
Current Address Register A Seg/Tag
RBUFA+l ; Current Address Register A Offset
<This local address is the source>

.WORD
. WORD

000000
RBUF

Current Address Register B Seg/Tag
Current Address Register B Offset
<This local address is the destination>

.WORD

000010

Current Operation Count <Transfer 8 bytes>

.WORD
.WORD

000000
000001

Channel Mode Register High
Channel Mode Register Low
<No match conditions, do nothing upon
completion, transfer type - single transfer
CARA = source, byte transfers>

.BYTE
• BLKB

101,102,103,104,105,106,107,110
10

.END

START

RELATED DOCUMENTS
For further information about the KXT11-C and the uPD7201
consult the following sources:
KXT11-C Single-Board Computer User's Guide
uPD7201 Technical Manual *

This manual may be obtained from NEC

326

(EK-KXTCA-UG)

please

uNOTE # 035

Title:

Backplane Expansion/Termination

Date: 19-Jul-85

Originator: Jack Toto

Page 1 of 8

The following MicroNote discusses the termination
and
expansion
configurations.
These configurations will deal with 18 and 22-bit Q-bus
processors, backplanes and enclosure!s.
Not all cases presented in this
MicroNote meet FCC regulations, and only those that do are so marked.
The MicroNote is partitioned as follows:
1.
2.
3.
4.
5.
6.

System configurations
Single Box expansion/termination rules.
Multiple box expansion/termination rules.
Configuration/case reference chart.
Supported single box configuration cases.
Supported multiple box configuration cases.

1. SYSTEM CONFIGURATION
The following is a list of single and multiple backplane termination
rules which must be followed when termination is required.
Further
explanation of these rules can be found in MicroNote # 029,
the
Microcomputers
Products
Handbook
(EB-26078-41),
the Microcomputer
Products Configuration Guide (EB-27318-68), and generally the user guide
for any of the CPUs.
The LSI-11 Bus system can be divided into two types:
1.
2.

Systems containing one backplane.
Systems containing multiple backplanes

Before configuring any system, module/system
known.
These characteristics are:
The

must

and

current

+12

Vdc

Power consumption.
requirements.

AC bus loading.
The amount of capacitance that a module
pres~ts
to a bus signal line. AC loading is expressed in
terms of ac loads where one ac load equals 9.35 pf of
capacitance.

327

Vdc

characteristics

uNOTE # 035
Page 2 of 8
3.

DC bus loading.
The amount of dc leakage current a module
presents to a bus signal when the line is high (undriven).
DC
loading is expressed in terms of dc loads where one dc load
equals 210 rna nominal.

Total backplane loading must include ac and dc loads and the
power consumption of the processor, modules, terminator module,
and backplane.

Processor termination, class as either 120 ohms or 240 ohms, as
follows:
OPTION
A.
B.
C.
D.
E.
F.

KDF11-A
KDF11-B
KDJ11-A
KDJ11-B
MicroVAX I
MicroVax II

TERMINATION
240
120
240
120
240
240

OHMS
OHMS
OHMS
OHMS
OHMS
OHMS

MODEL NAME
LSI 11/23
LSI 11/23 +
LSI 11/73
PDP 11/73
MicroVax I CPU
MicroVax II CPU

Power consumption, ac loading, and dc loading specifications
module can be found in sources mentioned earlier.

for

each

2. SINGLE BACKPLANE TERMINATION RULES
1.

When using a processor with 240 ohms termination, the bus can
accommodate up to 20. ac loads
(total)
before addi tional
termination is
required.
If more than 20 ac loads are
included,
the far end of the bus must be terminated with 120
ohms, although termination of 240 ohms is optimum.
Following
the addition of at least the minimum termination up to 35 ac
loads may be present in a single backplane.

When using a processor with 120 ohms termination, up to 35 ac
loads
(total)
may be present before additional termination is
required.
If more than 35 ac loads are included, the far end
of the bus must be terminated with 120 ohms. When this has
been done up to 45 ac loads may be present.

The bus can accommodate up to 20 (total)
true in all cases.

This

The bus signal lines on the backplane can be up to 35.6 cm
in) long.

(14

328

loads.

uNOTE i 035
page 3 of 8
3. MULTIPLE BACKPLANE TERMINATION RULES
1.

Up to three backplanes maximum can be configured in a
backplane system.

The signal lines on each backplane can be up to 25.4 cm (10 in)
in length.

Terminated multiple backplane systems can accommodate up to 44
ac loads, for two backplane systems, and 66 ac loads for three
backplane systems.
In multiple backplane systems no more than
22 ac loads may be present in anyone backplane, nor may any
unused ac loads from one backplane be added to the next
backplaneo
It is best to load each backplane equally, but if
not possible, then the first and second backplanes should have
the highest number of ac loads.

OC loading for all modules in all backplanes cannot
loads (total).

Both ends of the bus must be terminated with 120 ohms.
This
means that the first and last backplanes must have an impedance
of 120 ohms.
To achieve this, each backplane must be lumped
together as a single point.
The resistive termination may be
provided by combining two of the modules in the backplane;
the
processor providing 240 ohms to ground in parallel with an
expansion module providing 240 ohms to give the needed 120 ohms
termination. Alternately a processor with 120 ohms termination
would require no additional termination on the expansion module
to provide 120 ohms in the first box.
The 120 ohms termination
in the last box may be provided in three ways.
The termination
resistors may reside either on the bus expansion module, or on
a bus terminator module such as a BOVl1, or on the backplane
itself as in the case of the H9275 and H9278 (BA23-A enclosure)
backplanes.

The cable lengths connecting the first and second backplane are
61 cm (2 ft) or greater.

The cables connecting the second and third backplane are 122 cm
(4 ·ft)
longer or shorter than the cables connecting the first
and second backplanes.

The combined length of the cables can not exceed 4.88 m
feet __

The cables must have a characteristic impedance of 120 ohms.

329

multiple

exceed

uNOTE ~~ 035
Page 4 of S

4. CONFIGURATION/CASE REFERENCE CHART
rrhe chart below is designed to be a quick reference to a specific CPU
and system combination.
The actual configurations are listed after the
chart.
To use the chart below, find the CPU that is in the system and the
number of backplanes or enclosures that you will be using.
The
intersection of the two parameters will give you the case/variation
number that is valid for that configuration.
Ex.
case 1.2 represents
case 1, with variation 2.
SYSTEM CONFIGURATION CHART
PROCESSOR

SINGLE BOX

TWO BOX

THREE BOX

KDF11-A

240 OHMS

CASE 1
CASE 2

CASE 4.1
CASE 4.2
CASE 4.3

1S-BIT SYSTEMS
ONLY

KDFll·-B

120 OHMS

CASE 1
CASE 2

CASE
CASE
CASE
CASE

3.1
3.2
3.3
3.4

1S-BIT SYSTEMS
ONLY

KDJ11-A

240 OHMS

CASE 1
CASE 2

CASE 4.1
CASE 4.2
CASE 4.3

1S-BIT SYSTEMS
ONLY

KDJ1l-B

120 OHMS

CASE 1
CASE 2

CASE
CASE
CASE
CASE

3.1
3.2
3.3
3.4·

lS-BIT SYSTEMS
ONLY

MICROVAX I 240 OHMS

CASE 2

CASE
CASE
CASE
CASE

3.1
3.2
3. 3
3.4

NOT
APPLICABLE

MICROVAX II 240 OHMS

CASE 2

CASE 4.1
CASE 4.2
CASE 4. 3

NOT
APPLICABLE

330

uNOTE # 035
Page 5 of 8

5. SINGLE BOX SYSTEM CONFIGURATION CASES
Single box 18 or 22 bit system configurations can be terminated the
following two ways.
The two configuration cases presented in this
section will give optimum bus termi.nation respectively to 120 ohm and
240 ohm processor based systems.
CASE 1. Use an unterminated enclosure/backplane with a termination
card such as the BDV11 in the first unused slot. This card should
be ECO'd to etch revision E, when used in 22-bit systems
.
This
card should also have the on board processor and memory diagnostics
disabled if it is going to be used to terminate a system with the
KDJ11-A or as the CPU.
(refer to MicroNote # 003) The following
enclosures and backplanes are unterminated:

A.
B.
C.
D.
'E.
F.

OPTION

SYSTEM SIZE

BAll-SA
BA11-M
BA11-N
H9270-Q
H9281-QA
H9273-A

18/22 BIT
18 BIT
18 BIT
18/22 BIT
18/22 BIT
18 BIT

CASE 2. Use an enclosure/backplane which is already terminated.
All but one of Digital's backplanes are terminated with 120 ohms,
and will meet the minimum termination required for additional ac
loading beyond the capabilitiE!s of an unterminated backplane.
The
one backplane ,that is not terminated at 120 ohms is the one found
inside of the BA23-A enclosure. This option is terminated at 240
ohms. This enclosure is the only option that will provide optimum
termination for 240 ohm CPUs. The following table list all of the,
terminated enclosures and backplanes available
from
Digital
Equipment Corporation:

A.
B.
C.
D.

OPTION

SYSTEM SIZE

BA23-A
H9275-A
H9281-QB
H9281-QC

18/22 bit
22 BIT,
18/22 BIT
18/22 BIT

TERMINATION
240 OHMS
(not expandable) 120 OHMS
(not expandable) 120 OHMS
(not expandable) 120 OHMS

6. MULTIPLE BOX SYSTEM CONFIGURATION CASES
Multiple box configurations can be up to three boxes maximum.
However
currently only 18-bit three box systE~ms can be configured and terminated
properly. Therefore cases 3 and 4 dE~scribed below will deal only with
two box 22-bit system configurations using CPUs of either impedance as

331

uNOTE # 035
Page 6 of 8
l8-bit systems are sufficiently documented as noted below.
NOTE
FOR 18-BIT MULTIPLE BOX SYSTEMS USING A CPU CONTAINING
EITHER 120 OR 240 OHMS OF IMPEDANCE THE PROCEDURE FOR
EXPANDING FROM A ONE BOX SYSTEM TO A TWO BOX .SYSTEM IS
DOCUMENTED IN SEVERAL TECHNICAL RESOURCES, SUCH AS THE
EXPANSION PRODUCTS HANDBOOK (EB24836-75/68) AND THE
BA11-N
TECHNICAL
MANUAL
(EK-BA11N-TM-001).
A
PARTICULARLY GOOD RESOURCE FOR 18-BIT MULTIPLE BACKPLANE
EXPANSION AND TERMINATION GUIDELINES IS THE LSI SYSTEM
SERVICES MANUAL (EK-LSIFS-SV-005).
CASE 3. This case deals with a 120 ohm CPU.
The 120 ohms of
impedance on the CPU does not have to matched in the first box, but
does have to be matched at the far end of the bus which will be
located in the second box. This will generate four variations to
the case dealing with 120 ohm CPUs. All four of these variations
will have in common the BCV2A expansion assembly.
This option
contains two paddle cards (M9404-00 at 0 ohms and the M9405-YA at
120 ohms)
and the BC02D-03 interconnect cable.
The card for
expanding the bus out of the first box (M9404) will be installed in
the first unused slot of the first backplane, with the cable
connected to it the bus will be carried to the second backplane.
Here the bus is terminated by installing the termination card
(M9405) in the first slot of the second backplane.
VARIATION 1: Use two unterminated enclosures such as the
BAll-SA master box and the BA11-SE expansion box, connected
with the BCV2A.
This configuration is not FCC compliant and
places the task of FCC compliance on the user.
FCC compliance
can be obtained by rack mounting these two enclosures in an
H9642 cabinet and using the H349 distribution panel to make
connections from the system to the outside environment,
using
the appropriate option cabinet kits.
This cabinet system has
been tested by Digital
Equipment
Corporation
for
FCC
compliance.
NOTE
THE NEXT TWO VARIATIONS MAY BE MADE
FCC
COMPLIANT BY RACK MOUNTING BOTH BOXES IN AN
H9642 CABINET THAT HAS THE H9544-AJ
SIDE
PANELS.
THESE SIDE PANELS ALLOW FOR THE SIDE
TO SIDE AIR FLOW FOR THE BA23 ENCLOSURE.
ALSO
-INCLUDED IN THIS CABINET CONFIGURATION IS THE
H3490 PATCH PANEL WHICH IS USED FOR MAKING
CONNECTIONS FROM THE SYSTEM TO THE OUTSIDE
ENVIRONMENT VIA THE APPROPRIATE OPTION MODULE
CABINET KITS.

332

uNOTE # 035
page 7 of 8
VARIATION 2: Use the BA23 enclosure as the primary enclosure
and the BA11-SE as the expansion chassis, again using the BCV2A
as the interconnect for the two enclosures.
The termination
that exists on the BA23 backplane must be removed because the
that the' CPU has 120 ohms of impedance in the first box and
does not require any additional termination at this point. The
BA11-SE has not been tested in this configuration for FCC
compliance, however using the information in the above NOTE MAY
produce FCC compliance.
VARIATION 3: Use two BA23 enclosures. When using two BA23-A
enclosures
and
the BCV2A expansion assembly option the
termination from both backplanes must be removed. This is due
to the fact that the 120 ohms of CPU impedance does not have to
matched in the first backplane of a multiple backplane system
and that the BCV2A will put the required termination into the'
last backplane of this configuration.
VARIATION 4: A final variation to the 120 ohm CPU system would
be
to follow the same scenario as in the first three
variations, but using a mix of some terminated and untermiriated
backplanes as opposed to system enclosures. These backplanes
and their termination states are~ listed in cases one and two.
CASE 4. This case deals with the 240 ohm CPUs. As stated in the
termination rules for 240 ohms CPUs, the processors impedance must
be matched in the first box. This would bring the total impedance
in the first box to 120 ohms which is the ideal impedance. This
120 ohms from the first box, would be matched at the far end of the
bus which will be located in the second box. Configurations with
240 ohm CPUs have three variations. All of the case 4 variations
will have in common the BCV2A expansion assembly. The installation
of this option is explained above, in the section introducing two
box systems.
VARIATION 1: This case variation uses the BA23 enclosure as
the primary box and expands into a BA11-SE.
Using this
configuration requires that the termination on the backplane of
the BA23 be left in.
This will provide for an optimum
impedance match in the first box. The bus will be terminated
at the far end in the second box via the expansion assembly
termination card (M940S-YA). This configuration as is will not
be FCC compliant however following the guide lines from the
CASE 3 variations FCC compliance MAY possibly be achieved.
VARIATION 2: The two enclosures used here will be the BA23
system
box
and
the
BA23
expansion box.
While this
configuration resembles case 4 with variation 1, the only
change will be the removal of any termination from the second
(expansion) backplane. Interconnect between the two boxes and
FCC compliance can be achieved as described.

333

uNOTE # 035
Page 8 of 8
NOTE
WHEN CONFIGURING MULTIPLE BACKPLANE SYSTEMS
USING THE BA23-A BOX WITH THE RQDXl RD/RX
CONTROLLER,INSTALLED, CONSIDERATION SHOULD BE
GIVEN TO THE PLACEMENT OF THE CONTROLLER AND
ITS RELATIONSHIP TO THE DEVICES THEMSELVES.
FURTHER WHEN USING MULTIPLE BA23-A ENCLOSURES
IT BECOMES POSSIBLE TO HAVE THE BEVNT LINE FROM
BOTH OF THE POWER SUPPLIES TO BE ACTIVE AT THE
SAME TIME. THERE SHOULD ALWAYS BE ONLY ONE
BEVNT LINE ACTIVE AT ANYTIME, THEREFORE CARE
MUST TAKEN TO AVOID THIS CONFLICT.
THIS
PROBLEM IS AVOIDED WHEN USING A BA23-C AS THE
SECOND BOX.
VARIATION 3: This final case 4 variation deals with the use of
terminated and unterminated backplanes rather than enclosures.
Using a mix of these products the configurations would resemble
the first two for case 4, and would follow the same rules for
proper termination.

334

uNOTE # 036

Title:

MicroVMS Revealed

Originator:

Date: 19-Jul-85

Edward P. Luwish

Page 1 of 25

ABSTRACT
This MicroNote explains the contents of the MicroVMS
distribution kit as well as listing the "Full" VMS files
not included in said kit.
The description is of
MicroVMS V4.1M and VAX/V]~S V4.1, but will apply, with
minor changes, to later revisions of VMS V4.

DESCRIPTION OF THE COMPONENTS OF THE MICROVMS KIT
The MicroVMS kit comes in three parts
a standalone BACKUP piece
(currently three diskettes),
the BASE system (which is copied to a
blank, formatted hard disk by the standalone BACKUP) and a collection of
additional pieces which are addE~d to the system (using VMSINSTAL) as
though they were layered products. These pieces are labeled UTIL, USER,
PROG
and
SYSP.
Another piece, described here but purchasable
separately, is NET (DECnet). Note that the tape distribution contains
all these components (except DECnE~t) on a single volume - even so, the
partitioning is the same.
The installation procedure for MicroVMS is simple
first boot the
standalone BACKUP volume, use it to copy the BASE system to the hard
disk, then boot and log into the system thus built.
In many cases,
no
other files need be included on the hard disk.
If necessary, additional
options can be added to the system using VMS INSTAL and the remaining
pieces of the distribution kit.
The following sections describe the
components, starting with the Base system.
The files are divided into classes according to their usefulness in a
turnkey runtime environment. Class I was established experimentally, as
described in MicroNote # 37 - "In Search of NanoVMS".
The remaining
classes
represent
the author's opinion,
rather than defining a
hierarchy, and were based on the author's experiences with minimum
runtime environments.
Your environment may be somewhat different.

335

uNOTE # 036
Page 2 of 25
FILES INCLUDED IN THE BASE SYSTEM KIT
Class I files The following BASE SYSTEM files are required if a system is to boot up
at all.
The assumption is that the boot disk is an RQDX or other MSCP
device.
sys$system:DCL.EXE
sys$system:DUDRIVER.EXE
sys$system:FI1BXQP.EXE
sys$system:FPEMUL.EXE
sys$system:INSTALL.EXE
sys$system:JOBCTL.EXE
sys$system:LOGINOUT.EXE
sys$system:MTAAACP.EXE
sys$system:PDDRIVER.EXE
sys$system:PUDRIVER.EXE
sys$system:RMS.EXE
sys$system:RUNDET.EXE
sys$system:SCSLOA.EXE
sys$system:SET.EXE
sys$system:SETPO.EXE
sys$system:STARTUP.COM
sys$system:SYS.EXE
sys$system:SYSBOOT.EXE
sys$system:SYSGEN.EXE
sys$system:SYSINIT.EXE
sys$system:SYSLOAUV1.EXE
sys$system:SYSLOAUV2.EXE
sys$system:TTDRI~ER.EXE

sys$system:TUDRIVER.EXE
sys$system:VAXEMUL.EXE
sys$system:VAXVMSSYS.PAR

- Command language interpreter
(Executes startup command file)
- Class (protocol) driver for MSCP devices
- File ·structure and volume structure
(Extended QIO Processor)
- Emulate floating point instructions
- utility that installs known images
- Job controller/symbiont manager
(Creates detached process for LOGINOUT)
- Login/logout utility
(Needed for response to unsolicited
input from non-logged-in terminals)
- Magnetic tape ancillary control process
(Required if system is booted from TK50)
- Pseudo-disk driver for bootstrap
(Required if system is booted from TK50)
- Port (physical) driver for MSCP devices
- Record Management Services
- Runs detached images
(Needed to run JOBCTL.EXE)
- Loadable routines used by System
Communication Services
(needed by MSCP, etc.. )
- Processes many SET commands
(Needed frequently by STARTUP. COM)
- Processes SET MESSAGE command
(Needed frequently by STARTUP. COM)
- System-startup DCL command procedure
(Creates a standard VMS environment)
- Operating System image file
- System bootstrap utility
(Sets up system parameters prior to
invocation of STARTUP.COM)
- System customization utility
(Loads drivers, sets system parameters)
- Operating System Initialization image
- MicroVAX I-specific initialization
- MicroVAX II-specific initialization
(Pick only one of the above two files)
- Terminal driver (including console)
- Class (protocol) driver for TMSCP tapes
(Required if system is booted from TK50)
- Emulate VAX instructions not in uVAX arch.
- System parameter file
(Used by SYSGEN.EXE and SYSBOOT.EXE)

336

uNOTE # 036
Page 3 of 25
Class I files -

(continued)

sys$system:VMOUNT.EXE

- Volume mount utility
(Needed to mount system and user disks)
sys$library:DCLTABLES.EXE - Command-parsing tables
(Required by DCL.EXE)
sys$library:LBRSHR.EXE
- Runtime shareable library for Librarian
(Required by INSTALL.EXE)
sys$library:LIBRTL.EXE
- Runtime shareable library of common
system support routines
(Required by Job Controller)
sys$library:LIBRTL2.EXE
- Runtime shareable library of common
system support routines (Part 2)
(Required by Job Controller)
sys$library:MOUNTSHR.EXE - MOUNT shareable image
(Required by VMOUNT)
sys$library:SCRSHR.EXE
- V3.x screen management package
(Required by SYSGEN.EXE)
sys$manager:VMSIMAGES.DAT

Data file for installing known images

sys$message:SYSMSG.EXE

- System error messages
(required for boot up)
sys$message:SYSMGTMSG.EXE - ACC, EDIT/ACL, BACKUP, INSTALL,
MONITOR and AUTHORIZE error message file
(required for boot up)

337

uNOTE # 036
Page 4 of 25
Class IA files These files are required for proper system initialization and
shutdown, but will not prevent a system from booting if absent:
sys$system:DISMOUNT.EXE
sys$system:OPCCRASH.EXE
sys$system:SHUTDOWN.COM
sys$system~UVSTARTUP.COM

orde~ly

- Volume dismount utility
(Required for orderly system shutdown
or disk changing)
- System shutdown utility
(Required for orderly system shutdown)
- System shutdown DCL command procedure
(Required for orderly system shutdown)
- Processor-specific startup commands
(Required for orderly system startup)

sys$library:DISMNTSHR.EXE - DISMOUNT shareable image
sys$library:MTHRTL.EXE
- Math support runtime shareable library
(required by an image invoked by
SHUTDOWN. COM)
sys$library:UVMTHRTL.EXE - MicroVAX version of MTHRTL
sys$manager:SYSTARTUP.COM - Site-specific startup commands
(Required for Qrderly system startup)
sys$manager:SYCONFIG.COM - Required for orderly system startup
sys$manager:SYSHUTDWN.COM - Site-specific shutdown commands
(Required for orderly system shutdown)

338

uNOTE # 036
Page 5 of 25
Class IB Files These files are required by optional hardware:
sys$system:ANALYZBAD.EXE
sys$system:BADBLOCK.EXE
sys$system:DLDRIVER.EXE
sys$system:DZDRIVER.EXE
sys$system:MTAAACP.EXE
sys$system:SMGMAPTRM.EXE

sys$system:SYSLOAWS1.EXE
sys$system:SYSLOAWS2.EXE
sys$system:TERMTABLE.EXE
sys$system:TUDRIVER.EXE
sys$system:YFDRIVER.EXE

- ANALYZE/MEDIA image
(Required only for non-MSCP disk support)
- Dynamic bad block Files-11 ACP subprocess
(Required only for non-MSCP disk support)
- RL02 Disk Driver
- DZV11 Serial Interface Driver
- Magnetic tape ancillary control process
(Required for tape support)
- TERMTABLE global section - runs at
system startup.
(Required for video
terminal support using VMS screen
management package)
- Graphics display initialization
(RequirE~d for VAXstation I support only)
- Graphics display initialization
(RequirE~d for VAXstation II support only)
- Compiled terminal definitions file
(Required for te~minal support)
- Class (protocol) driver for TMSCP tapes
(Required for TK50 support only)
- DHVll Serial Interface Driver

339

uNOTE # 036
Page 6 of 25
Class II files These files MAY be required by user applications or layered products,
since they depend on which high-level language or operating system
features are used:
[Note that C and ADA are absent
their runtime
licenses are separate from, and in addition to, that of VMS]
sys$library:BASRTL.EXE
sys$library:BASRTL2.EXE
sys$library:CDDSHR.EXE

- Runtime shareable library - BASIC
- Runtime shareable library - BASIC
- Required by layered products using the
Common Data Dictionary - such as
Datatrieve
sys$library:COBRTL.EXE
- Runtime shareable library - COBOL
sys$library:ENCRYPSHR.EXE - Dummy encryption module
(Required by layered products that can
optionally use DES data encryption)
sys$library:FORRTL.EXE
- Runtime shareable library - FORTRAN
sys$library:PASRTL.EXE
- Runtime shareable library - PASCAL
sys$library:PLIRTL.EXE
- Runtime shareable library - PL/I
sys$library:RPGRTL.EXE
- Runtime shareable library - RPG II
sys$library:SMGSHR.EXE
- VMS screen management package
sys$library:VMSRTL.EXE
- Old-f~rmat VMS runtime library
(Required by V3.x applications)
sys$message:CLIUTLMSG.EXE - ANALYZE/MEDIA, EXCHANGE, MAIL, PHONE,
PRINT, SUBMIT, RUN, SET, SHOW and
SEARCH error messages.
sys$message:FILMNTMSG.EXE - ANALYZE/OBJECT, ANALYZE/IMAGE,
EDIT/FDL, ANALYZE/DISK error messages
sys$message:PASMSG.EXE
- PASCAL language error messages
sys$message:PLIMSG.EXE
- PL/I language error messages
sys$message:RPGMSG.EXE
- RPG language error messages
sys$message:SHRIMGMSG.EXE - CONVERT, DCX (library de/compression
utility), FDL, SORT, SMGSHR and EDT
error messages

340

uNOTE # 036
Page 7 of 2S
Class IIA files These are use.r utilities that can be called by application programs even
though there may exist no way to invoke them from the terminal by DeL
command:
sys$library:CRFSHR.EXE
sys$iibrary:DCXSHR.EXE
sys$library:EDTSHR.EXE
sys$library:FDLSHR.EXE
sys$library:SORTSHR.EXE

- Cross-Reference shareable image
(Required by compilers & linker if
cross-reference option is invoked)
- Data de/compression support
- Callable editor
(Required by EDT.EXE)
File Description Language parsing
shareable image
(Required by CREATEFDL.EXE and EDF.EXE)
- VAX Sort/Merge Runtime library
(Required by SORTMERGE.EXE)

Class III files These are often used to diagnose or maintain systems in the field.
They
can be used to adapt systems to changing user need on an interactive
basis.
Some applications call these as part of their operation.
sys$system:BACKUP.EXE
sys$system:CHECKSUM.EXE
sys$system:ERRFMT.EXE
sys$system:LINK.EXE
sys$system:MODPARAMS.DAT
sys$system:PATCH.EXE
sys$system:SUMSLP.EXE

- Backup utility
- Used during installation of
VAX/VMS updates
- Error logging facility
- Linker
(Development/upgrade utility)
- Site modifactions to sysgen
parameters - Used by AUTOGEN.COM
- Image patching utility
(Required for system updates/bug fixes)
- Batch-oriented source file editor
(Required for system updates/bug fixes)

sys$library:SECURESHR.EXE - Rights database (RIGHTSLIST.DAT)
service routines.
(Required by BACKUP.EXE)
sys$library:SUMSHR.EXE
- ShareablE~ image required by SUMSLP
sys$update:AUTOGEN.COM
sys$update:LIBDECOMP.COM
sys$update:REMOVE.COM
sys$update:SWAPFILES.COM
sys$update:VM~INSTAL.COM

System tuning utility
Library decompression utility
Update utility
System Tuning utility
Update utility

Optional files for disk support:
sys$system:INIT.EXE
- Volume initialization utility
sys$system:UNLOCK.EXE
- For reopening improperly closed files
sys$system:VERIFY.EXE- For error-correction of disks

uNOTE # 036
Page 8 of 25
Class IV files These set up and maintain a multi-user environment even
DCL is not supported by the turnkey system:
sys$system:AUTHORIZE.EXE
sys$system:CVTNAF.EXE
sys$system:CVTUAF.EXE
sys$system:NOTICE.TXT
sys$system:OPCOM.EXE
sys$system:REPLY.EXE
sys$system:SETSHOACL.EXE
sys$system:SYSALF.DAT
sys$system:SYSUAF.DAT

interactive

- User authorization utility
(Required only for login passwQrd support)
- Convert NETUAF.DAT utility
(Required only for V3.5+ system upgrades)
- convert SYSUAF.DAT utility
(Required only for V3.5+ system upgrades)
- Announcement file for logged-in users
- Operator communications facility
(For systems with a human operator)
- Message broadcasting utility
(For systems with a human operator
/multi-user/secure. Required by OPCOM)
- SET and SHOW ACCESS CONTROL LIST commands
(For secure systems)
- Automatically logged-in terminal data file
(Required only if this feature is used)
- User authorization data file
(Required only for login password support)

sys$library:SECURESHR.EXE - Rights database (RIGHTSLIST.DAT)
service routines.
(Required for multi-user systems)
sys$manager:ADDUSER.COM
sys$manager:ALFMAINT.COM
sys$manager:EDTINI.EDT
sys$manager:LOGIN.COM
sys$manager:SUCCESS.TXT
sys$manager:SYLOGIN.COM
sys$manager:WELCOME.TXT
sys$update:BACKUSER.COM
sys$update:CVTNAF.COM
sys$update:CVTUA~.COM

sys$update:RESTUSER.COM

- For maintaining multi-user systems
- For managing automatically
logged-in terminals
- Editor initialization script for
system manager's account
- Command file executed when system
manager logs into account
- Not required
- Command file executed when any user
logs in (prior to user's own LOGIN.COM)
(Required for multi-user systems)
- Not required
- Back up user directories before
performing system update
Update utility (multi-user systems)
- Convert NETUAF.DAT utility
(Required only for V3.S+ system upgrades)
- Convert SYSUAF.DAT utility
(Required only for V3.5+ system upgrades)
- Restore user directories after
performing system update
Update utility (multi-user systems)

342

uNOTE # 036
Page 9 of 25
Class V files These are user utilities that exist for the convenience of interactive
users.
Some of these are of interE!st primarily to programmers.
None of
the Class V files normally become part of a turnkey application.
sys$system:CDU.EXE
sys$system:CONVERT.EXE
sys$system:COPY.EXE
sys$system:CREATE.EXE
sys$system:CREATEFDL.EXE
sys$system:DELETE.EXE
sys$system:DIRECTORY.EXE
sys$system:EDT.EXE
sys$system:LIBRARIAN.EXE
sys$system:RECLAIM.EXE
sys$system:RENAME.EXE
sys$system:SHOW.EXE
sys$system:SORTMERGE.EXE
sys$system:TYPE.EXE
sys$system:VMSHELP.EXE

- For defining new DCL commands
(User-oriented utility)
- Converts RMS files to
new formats and organizations
(User-oriented utility)
- User-oriented file copying utility
- User-oriented file and directory
creation utility
- CREATE/FDL image
- User-oriented file deletion/purge utility
- User-oriented directory utility
- Interactive text editor
- Librarian (Development utility)
- Used to recover free space in
ISAM RMS files
(User-oriented utility)
- User-oriented file renaming utility
- SHOW command processor
- SORT and MERGE command processor
- Utility for typing text files on terminal
(User-oriented utility)
- Interactive help utility

sys$library:CONVSHR.EXE

- Shareable image required by CONVERT.EXE
and RECLAIM.EXE
sys$library:DBGSSISHR.EXE - DEBUG system service intercept handler
(Development utility)
sys$library:TRACE.EXE
- Error traceback facility
(Development utility)
sys$help:EDTHELP.HLB
sys$help:HELPLIB.HLB
sys$help:UAFHELP.HLB

- Help library for EDT
- Main help library (small version)
- Help library for AUTHORIZE

sys$message:DBGTBKMSG.EXE - DEBUG, TRACE messages
(Development utility)
sys$message:PRGDEVMSG.EXE - CDU, DIFF, DUMP, Librarian, Linker,
MACRO, MESSAGE, PATCH, ANALYZE/SYSTEM,
and ANALYZE/CRASH messages
(Development utility)
sys$update:SP~ITBLD.COM

sys$update:VMSKITBLD.DAT

- utility :for building software kits
(Development utility)
- Data for VMSKITBLD.COM - for building
MicroVMS binary distribution kits
(Development utility)

343

uNOTE # 036
Page 10 of 25
Class VI files These are files required by options which are not included in
System:

the

BASE

sys$message:NETWRKMSG.EXE - DECnet error messages

FILES INCLUDED IN THE OPTIONAL KITS
'The optional kits include UTIL, USER,
PROG,
SYSP and (at additional
cost) NET.
The files of these kits are described in the next sections
of the MicroNote.
First, a word of explanation about the format:
These
kits are in VMSINSTAL format - this means they consist of a number of
BACKUP savesets. Thus the UTIL option consists of the UTILxxx.A,
UTILxxx.B,
etc.
savesets, where IIXXX" is a number giving the version
and revision level.
Each saveset is listed separately, and denoted as
"UTIL A",
"UTIL B", etc.
The savesets are described individually
becauie they can-be added to your system (or not) depending on your
replies to the interactive VMSINSTAL.COM procedure.
The" A" saveset
contains the installation data tables and any default files- (if any)
needed by ALL the other savesets, so it will often appear empty in the
tables below.

NETWORK DEVICE DRIVERS
In order to permit the use of DECnet communication
devices
as synchronous serial lines,
the hardware
drivers are included in the UTIL option, and do not
require a DECnet license.
These same files are also
included in the DECnet kit so as to simplify network
installation.

344

uNOTE # 036
Page 11 of 25
This section lists the files of the UTIL option:
UTIL A

KITINSTAL.COM

UTIL B

MAIL utility

sys$system:MAIL.COM
sys$system:MAIL.EXE
sys$system:MAILEDIT.COM
sys$help:MAILHELP.HLB

Command procedure used by DECnet mail
Mail Utility
Default MAIL editing command procedure
Mail Utility help file

UTIL_C -- SEARCH utility
sys$system:SEARCH.EXE

File search utility

File compare utility

UTIL_D -- DIFF utility
sys$system:DIFF.EXE
UTIL_E -- DUMP utility
sys$system:DUMP.EXE

-- File dump utility

UTIL_F -- RUNOFF utility
sys$system:DSRTOC.EXE
sys$system:DSRINDEX.EXE
sys$system:RUNOFF.EXE

RUNOFF/CONTENTS image
RUNOFF/INDEX image
Text formatting utility

UTIL_G -- PHONE utility
sys$system:PHONE.COM
sys$system:PHONE.EXE
sys$help:PHONEHELP.HLB

PHONE startup procedure
Phone utility
phone utility help file

UTIL_H -- MicroVMS HELP library
sys$help:HELPLIB.HLB

Full default (DCL) help file

UTIL I -- Remote terminal support via SET HOST/DTE
sys$system:RTPAD.EXE
sys$library:DTE_DF03.EXE

Remote terminal command interface
-- SET HOST/DTE support for
DFO] dialer

UTIL J - - Drivers for netw'ork communication devices
Asynchronous DECnet driver
DECnet DMV11 datalink driver
DEQNA Ethernet interface driver

sys$system:NODRIVER.EXE
sys$system:XDDRIVER.EXE
sys$system:XQDRIVER.EXE

345

uNOTE i 036
Page 12 of 25
1

(UTIL option, continued)
UTIL K -- LAT-11 terminal server support (via Ethernet)
sys$system:LATCP.EXE
sys$system:LTDRIVER.EXE
sys$system:XQDRIVER.EXE
sys$help:LATCP.HLB
sys$manager:LTLOAD.COM
UTIL_L -

LAT-l1 Control Program
LAT-ll Driver
DEQNA Ethernet interface driver
LAT-11 Control Program help file
Command procedure to load and start LAT

Stand-alone backup on system disk support

sys$system:STABACCOP.EXE
sys$system:STABACKUP.EXE
sys$system:STANDCONF.EXE
sys$system:STASYSGEN.EXE
sys$update:STABACKIT.COM

Copy program for building
standa16ne BACKUP kit
Standalone BACKUP utility
Standalone BACKUP configure image
Standalone SYSGEN utility
Command procedure that builds
standalone BACKUP to media

UTIL_M -- MicroVAX-I bootstrap that works for any MSCP system device
sys$system:VMBUVAXlP.EXE
sys$update:VMBUVAXl.COM

Image which boots disks inaccessible
from boot ROM or console command
Command procedure to build Rx50
console floppy to boot other disks

UTIL_N -- Error Log Report Generator utility
sys$system:ERF.EXE
sys$system:ERFBRIEF.EXE
sys$system:ERFBUS.EXE
sys$system:ERFDISK.EXE
sys$system:ERFINICOM.EXE
sys$system:ERFPROCl.EXE
sys$system:ERFPROC2.EXE
sys$system:ERFPROC3.EXE
sys$system:ERFPROC5.EXE
sys$system:ERFSUMM.EXE
sys$system:ERFUVAX.EXE
sys$library:ERFCOMMON.EXE
sys$library:ERFCTLSHR.EXE
sys$library:ERFLIB.TLB
sys$library:ERFSHR.EXE

ANALYZE/ERROR image
ANALYZE/ERROR brief report generator
ANALYZE/ERROR bus display ge:nerator
ANALYZE/ERROR disk display generator
ANALYZE/ERROR initialize routines
ANALYZE/ERROR processing routines
ANALYZE/ERROR processing routines
ANALYZE/ERROR processing routines
ANALYZE/ERROR processing routines
ANALYZE/ERROR summary display routines
ANALYZE/ERROR uVAx-specific routines
ANALYZE/ERROR common data structures
ANALYZE/ERROR shareable image
ANALYZE/ERROR device descriptions
ANALYZE/ERROR common routines

346

uNOTE
036
Page 13 of 25
This section lists the files of the USER option:
USER A

Default files

USER B

File Access Control List utilities

sys$system:ACLEDT.EXE
sys$library:ACLEDIT.INI
sys$help:ACLEDT.HLB

Access Control List (ACL) Editor
ACL Editor initialization file
ACL Editor help file

USER_C -- Disk Quota utility
sys$system:DISKQUOTA.EXE
sys$help:DISKQUOTA.HLB
USER_D -- Print and Batch

--- Disk Quota utility
------ Disk Quota utility help file

Queu(~

sys$system:LPDRIVER.EXE
sys$system:PRTSMB.EXE
sys$system:QUEMAN.EXE
sys$system:REQUEST.EXE
sys$system:SUBMIT.EXE
sys$library:SMBSRVSHR.EXE

utilities
Line printer driver
Print symbiont
Queue managing utility
Operator request facility
Batch job submission utility
Print symbiont service routines

USER_E --- Input Queue Symbiont
Card reader input symbiont

sys$system:INPSMB.EXE

USER_F --- Accounting Log Report Generator utility
sys$system:ACC.EXE

-- Accounting Utility

347

uNOT1!: # 036
Page 14 of 25
This section lists the files of the PROG option:
PROG A

KITINSTAL.COM

PROG B

Debugger utility

sys$library:DEBUG.EXE
sys$help:DEBUGHLP.HLB

Symbolic debugger
Debugger help file

PROG_C -- Image Dump utility
sys$system:ANALIMDMP.EXE
sys$library:IMGDMP.EXE

-- ANALYZE/PROCESS DUMP image
-- Image dump procedures

P'ROG_D -- RMS Analyze and FDL Editor utilities
sys$system:ANALYZRMS.EXE
sys$system:EDF.EXE
sys$help:ANLRMSHLP.HLB
sys$help:EDFHLP.HLB

ANALYZE/RMS FILE image
File Definition Language editor
ANALYZE/RMS FILE help file
FDL Editor help file

PROG_E -- Message utility
sys$system:MESSAGE.EXE

-- Message compiler

348

uNOTE # 036
Page 15 of 25
(PROG option, continued)
ImagE~

PROG_F -- Object and Shareable
sys$library:IMAGELIB.OLB
sys$library:STARLET.OLB

libraries

System default shareable image library
-- System object and runtime library

PROG G -- Macro libraries
sys$library:LIB.MLB
sys$library:STARLET.MLB

Operating system macro library
System macro library

PROG H -- Macro assembler
sys$system:MACR032.EXE

-- VAX MACRO assembler

PROG_I -- SDL intermediary form of STARLET.MLB
sys$system:SDLNPARSE.EXE
sys$library:STARLETSD.TLB

SDL compiler (for installing
optional software)
Text library of STARLET definitions
Used during layered product installations

PROG J - - FORTRAN require files
sys$library:FORDEF.FOR
sys$library:FORIOSDEF.FOR
sys$library:LIBDEF.FOR
sys$library:MTHDEF.FOR
sys$library:SIGDEF.FOR
sys$library:XFDEF.FOR

349

FORTRAN INCLUDE file: FOR$ sysmbols
FORTRAN INCLUDE file: IOSTAT error codes
FORTRAN program utility INCLUDE files
FORTRAN INCLUDE file: MATH$ symbols
FORTRAN program utility INCLUDE files
Definitions available for programs
using DR780 support routines

uNOTE # 036
Page 16 of 25
This section lists the files of the SYSP option:
SYSP A -- Default files
Install utility help file
Patch utility help file
Sysgen utility help file

sys$help:INSTALHLP.HLB
sys$help:PATCHHELP.HLB
sys$help:SYSGEN.HLB

SYSP_B -- Files-11.0DS1 ACP and EXCHANGE utility
RT-11/DOS file transfer utility
Files-l1 Structure Level 1 ACP
Exchange utility help file

sys$system: EXCHANGE. EXE
sys$system:F11AACP.EXE
sys$help:EXCHNGHLP.HLB
SYSP_C -- Monitor utility
sys$system:MONITOR.EXE
sys$help:MNRHELP.HLB
SYSP_D -

-- Monitor utility
-- Monitor utility help file

Analyze Object File utility

sys$system:ANALYZOBJ.EXE

-- ANALYZE/IMAGE and ANALYZE/OBJECT image

SYSP_E -- Delta debugger (for drivers and other privileged code)
sys$library:DELTA.EXE
sys$library:DELTA.OBJ

-- DELTA multimode debugging tool image
-- Alternate debugging tool

SYSP_F -- System Dump Analyzer utility
sys$system:SDA.EXE
sys$help:SDA.HLB

-- System Dump Analyzer
-- System Dump Analyzer help file

SYSP_G -- System Symbol Table file
sys$system:SYS.STB

-- Global symbol table of operating system

SYSP_H -- Misc Symbol Table files
sys$~y~tem:SYSDEF.STB

Global definitions for
executive structures

SYSP_I -- System map
sys$system:SYS.MAP
SYSP_J -

-- Map of the operating system

ConnecE-to-Interrupt Driver

sys$system:CONINTERR.EXE

-- Connect-to-Interrupt Driver

350

uNOTE # 036
Page 17 of 25
This section consists of the files
included in the DECnet Kit.
In
addition to these,
a license disk is included,
which unlocks the
end-node or the full routing node functionality in these files:
NET A -- Default files
Command file used by DECnet
error logging
DECnet event logging program
Network control program
DECnet pseudo-datal ink driver
DECnet ancillary control process
DECnet logical link driver
Network server DECnet command procedure
Network server image
Ethernet configurator DECnet
command procedure
Ethernet configurator image
NML server startup procedure
DECnet network manager listener
Asynchronous DECnet driver
DECnet DMV11 datalink driver
DEQNA Ethernet interface driver
DECnet management listener
shareable image
Network Command Program help file
DCL procedure to create
network ACP process
DCL procedure to configure
network database
DECnet startup procedure

sys$system:EVL.COM
sys$system:EVL.EXE
sys$system:NCP.EXE
sys$system:NDDRIVER.EXE
sys$system:NETACP.EXE
sys$system:NETDRIVER.EXE
sys$system:NETSERVER.COM
sys$system:NETSERVER.EXE
sys$system:NICONFIG.COM
sys$system:NICONFIG.EXE
sys$system:NML.COM
sys$system:NML.EXE
sys$system:NODRIVER.EXE
sys$system:XDDRIVER.EXE
sys$system:XQDRIVER.EXE
sys$library:NMLSHR.EXE
sys$help:NCPHELP.HLB
sys$manager:LOADNET.COM
sys$manager:NETCONFIG.COM
sys$manager:STARTNET.COM

NET_B -- Incoming Remote File Access files
sys$system:FAL.COM
sys$system:FAL.EXE

-- FAr. startup procedure
-- DECnet File Access Listener

NET C -- Incoming Remote Terminal files
CTERM Driver
Remote device ACP
Remote terminal driver
stop REMACP utility
Remote terminal loader

sys$system:CTDRIVER.EXE
sys$system:REMACP.EXE
sys$system:RTTDRIVER.EXE
sys$system:STOPREM.EXE
sys$manager:RTTLOAD.COM

351

uNOTE # 036
Page 18 of 25
(NET option, continued)
NET_D -- Outgoing Remote Terminal files
sys$system:RTPAD.EXE
sys$library:DTE_DF03.EXE

Remote terminal command interface
-- SET HOST/DTE support for DF03 dialer

NET E -- Network Test files
sys$system:DTR.COM
sys$system:DTRECV.EXE
sys$system:DTSEND.EXE
sys$system:MIRROR.COM
sys$system:MIRROR.EXE
sys$system:MOM.COM
sys$system:MOM.EXE

DTRECV.EXE server initiating procedure
DTSEND server
DECnet logical links test program
MIRROR startup procedure
DECnet node loopback server
Maintenance operations module
DECnet command procedure
Maintenance operations module image

NET_F -- Remote Task Loading
sys$system:HLD.COM
sys$system:HLD.EXE

Command procedure used by HLD.EXE
Downline task loading program

352

uNOTE # 036
Page 19 of 25
FILES WHICH ARE INCLUDED IN VMS DISTRIBUTIONS BUT NOT IN MicroVMS:
Files which are specific to larger CPUs:
Console-device files for 730, 750, 780:
VMB.EXE
BOOTBLDR.COM
DXCOPY.COM
730CNSL.DAT

BOOT58.EXE
BOOTUPD.COM
SETDEFBOO.COM
CONSOLBLD.COM

BOOTBLOCK.EXE
R~rB. EXE
7HOCNSL.DAT

CONSCOPY.COM
WRITEBOOT.EXE
750CNSL.OAT

Part of system startup:
SYSLOA730.EXE
SYSLOA750.EXE
SYSLOA780.EXE
SYSLOA790.EXE
CONFIGURE.EXE

CPU-specific initialization (11/730)
CPU-specific initialization (11/750)
CPU-specific initialization (11/780,782,785)
CPU-specific initialization (VAX 8600)
Dynamic device configure process

System-bus attachments:
CVDRIVER.EXE
DQDRIVER.EXE
PADRIVER.EXE
STACONFIG.EXE
XFDRIVER.EXE
XFLOADER.EXE

8600 Console Disk Controller (RL02)
RB730 11/730 Integrated Disk Controller (R80/RL02)
CI780 Port Driver
HSC System Disk Configurator
DR7S0, DR780 Ultra-high-speed Parallel Interface
DR750, DR780 Microcode loader

omitted from MicroVMS for reasons of size or performance:
DES Encryption:
ENCRYPFAC.EXE --

ENCRYPT command image

Related to new Screen Management handler for terminals:
SMGBLDTRMeEXE
SMGTERMS.TXT
TERMTABLE.TXT

Compiler for TERMTABLE definition file
ASCII source file for DEC terminal definitions
Terminal definitions source file

Related to SORT/MERGE:
SRTTRN.EXE

SORT specification file translator image

353

uNOTE # 036
Page 20 of 25
VAXCluster support:
FILESERV.EXE
CLUSTRLOA.EXE
CSP.EXE
MSCP.EXE
CNDRIVER.EXE
MAKEROOT.COM
CLUSTRLOA.MAP
SHWCLSTR.EXE
SHWCLHELP.HLB

File system cache flush server
Loadable VAXcluster support code
Cluster server process image
MSCP server
CI DECnet Protocol Driver
Add new roots to cluster common system disk
Link map of loadable VAXcluster support code
SHOW CLUSTER command
SHOW CLUSTER help file

11/782 Shared Memory support:
MP.EXE
MP.MAP
MPSHWPFM.EXE
MPCLRPFM.EXE
MBXDRIVER.EXE

VAX 11-782 multiprocessing code
Link map of multiprocessing code
Multiprocessing utility
Multiprocessing utility
Shared memory mailbox driver

PDP-11 Compatibility-mode images:
TEeO.EXE
TECO.HLB

TEeo text editor and programming language
TEeo help file

MASSBUS drivers:
DBDRIVER.EXE
DRDRIVER.EXE

RPOS, RP06 Disks
RM03, RMOS, RM80, RP07 Disks

LPA11-K Laboratory Peripheral Accelerator support:
LADRIVER.EXE
LALOAD.EXE
LALOADER.EXE
LPA11STRT.COM

LPA11
Sends
Loads
LPA11

Laboratory Peripheral Accelerator driver
requests to LALOADER.EXE
LPA11 microcode
site-specific startup command file

354

uNOTE # 036
Page 21 of 25
UNIBUS drivers:
CRDRIVER.EXE
DDDRIVER.EXE
DMDRIVER.EXE
DXDRIVER.EXE
DYDRIVER.EXE
DZDRIVER.EXE
LCDRIVER.EXE
TFDRIVER.EXE
TMDRIVER.EXE
TSDRIVER.EXE
TUDRIVER.EXE
XADRIVER.EXE
XEDRIVER.EXE
XGDRIVER.EXE
XMDRIVER.EXE
XWDRIVER.E,XE
YCDRIVER.EXE

CR11 Card Reader
Tu58 Cartridge Tape
RK611 (RK06, RK07) Disks
RX01 Floppy Diskette
RX02 Floppy Diskette
DZ11 Asynchronous Serial Multiplexer
(NOT the same as MicroVMS DZDRIVER.EXE)
DMF32 Line Printer Port
TU78 Magnetic Tape
TE16, TU45, TU77 Magnetic Tape
TS11, TS05, TUBO Magnetic Tape
(TSV05 will be supported)
TAB1, TUBI Magnetic Tape
(NOT the same as MicroVMS TUDRIVER.EXE)
DRI1-W High-speed Parallel Interface
DEUNA Ethernet Interface
DMF32 Synchronous Port
DMCll Synchronous Communications Adapter
DUP11 Synchronous Serial Line Interface
DMF32, DMZ32, CPI32 Asynchronous Serial Multiplexers

355

uNOTE # 036
Page 22 of 25
Files from sys$examples:
ADDRIVER.MAR
CONNECT.COM
DOI> ERAPAT.MAR DRCOPY.PRM
DRCOPYBLD.COM
DRMAST.MAR
DRMASTER.FOR
DRSLAVE.FOR
DRSLV.MAR
DTE DF03.MAR
GBLSECUFO.MAR
LABCHNDEF.FOR
LABIO.OPT
LABIOACQ.FOR
LABIOCIN.MAR
LA.BIOCIN. OPT
LABIOCOM.FOR
LABIOCOMP.COM
LABIOCON.FOR
LABIOLINK.COM
LABIOPEAK.FOR
LABIOSAMP.FOR
LABIOSEC.FOR
L1\BIOSTAT. FOR
LABIOSTRT.COM
LABMBXDEF.FOR
LBRDEMO.COM
LBRDEMO.FOR
LBRMAC.MAR
LPATEST.FOR
LPMULT.B32
MAILCOMPRESS.COM
MAILCVT.COM
MAILUAF.COM

Example device driver for ADII-K
Command procedure that connects device for
LABIO system
Example loadable erase pattern generator
Parameter file for DRCOPY routines
Command procedure to build DRCOPY.EXE
VAX RMS interface for DRMASTER.FOR
Master subroutines for DRCOPY
Slave subroutines for DRCOPY
VAX RMS interface for DRSLAVE.FOR
SET HOST/DTE dialer support
Opens file used as global section for LABIO system
Defines information associated with each AID
for LABIO system
Linker options file for linking modules
to be used in LABIO
Acquires data for LABIO system
Contains connect-to-interrupt call for LABIO system
Linker options file for linking LABIO DATA ACQ
Attaches a LABIO user program to the LABIOsystem modules of the LABIO system
Command procedure to compile and assemble
the modules of the LABIO system
Handles user requests and modifies the
database for LABIO system
Command procedure to link LABIO system
Samples channel for peak data in LABIO system
Samples channel in intervals, reporting date, time
and average value on logical device for LABIO system
places LABIO SECTION on page boundary
Displays AID-channel status for LABIO system
Command procedure to start LABIO system
Defines mailbox block for LABIO system
Command procedure to create Librarian DEMO.EXE
Librarian demo (first part)
Librarian demo (second part)
LPAII-K test program
Example program for line printer
Sample procedure to compress mail files
Sample procedure to convert V3.x mail files
Sample procedure to manipulate sys$system:VMSMAIL.DAT

356

uNOTE # 036
Page 23 of 25
Files from sys$examples, continued:
MSCPMOUNT.COM
PEAK. FOR
SCRFT.MAR
SYSGTTSTR.MSG
TDRIVER.MAR
TESTLABIO .. FOR
USSDISP.MAR
USSLNK.COM
USSTEST.MAR
USSTSTLNK.COM
XADRIVER.MAR
XALINK.MAR
XAMESSAGE.MAR
XATEST.COM
XATEST.FOR
XIDRIVER.MAR

Example cluster disk mount procedure
Peak selection routine in LABIO system
Optional screen package (SCR$ ... in RTL) extension
to handle foreign terminals
Sample SYSGEN TERMINAL/ECHO message file
Template for user-written driver
Tests LABIO system
Sample user system service dispatch and
service examples
Link command procedure for USSDISP
Sample program to invoke one of the example
user services implemented in USSDISP
Link command procedure for USSTEST
DR11-W driver
Sample DR11-W to DR11-w link program
DR11-W test program
Used to set up XA[,INK. MAR
Companion program for XAMESSAGE
Example driver for parallel port on DMF32

11/730 Dual RL02 Tailoring Files:
VMSTAILOR.COM
EXAMPLES.TLR
MANAGER.TLR
TEXTTOOLS.TLR

BLISSREQ.TLR
FILETOOLS.TLR
MISCTOOLS.TLR
UETP.TLR

357

DE:CNET. TLR
HE:LP. TLR
QUEUES.TLR
VMSTLRHLP.HLB

DEVELOP.TLR
LIBRARY.TLR
REQUIRED.TLR

uNOTE # 036
Paqe 24 of 25
User Environment Test package files:
TCNTRL.CLD
UETPGCOM
UETCLIGOO.COM
UETCLIGOO.DAT
UETCLIGOO.EXE
UETCOMSOO.EXE
UETDISKOO.EXE
UETDMPFOO.EXE
UETDNETOO.COM
UETDNETOO.DAT
UETDR1WOO.EXE
UETDR7800.EXE
UETFORT01.DAT
UETFORT01.EXE
UETFORT02.EXE
UETFORT03.EXE
UETINITOO.EXE
UETINIT01.EXE
UETLOADOO.DAT
UETLOAD02.COM
UETLOAD03.COM
UETLOAD04.COM
UETLOAD05.COM
UETLOAD06.COM
UETLOAD07.COM
UETLOAD08.COM
UETLOAD09.COM
UETLOAD10.COM
UETLOADll.COM
UETLPAKOO.EXE
UETMA7800.EXE
UETMEMY01.EXE
UETNETSOO.EXE
UETPHASOO.EXE
UETRSXFOR.EXE
UETSUPDEV.DAT
UETTAPEOO.EXE
UETTTYSOO.EXE
UETUNASOO.EXE

Defines UETP DCL commands
Main command procedure
For cluster-integration phase
For cluster-integration phase
For cluster-integration phase
DMC and DMR device test
Disk device test
DMP and DMF32 device test
For DECnet phase
For DECnet phase
DRII-W device test
DR780 and DR750 device test
Used by load test
Used by load test
Used by load test
Used by load test
Initializes UETP environment
Initializes UETP environment
Used by load test
User script for load test
User script for load test
User script for load test
User script for load test
User script for load test
User script for load test
User script for load test
User script for load test
User script for load test
User script f~r load test
LPAII-K device test
MA780 device test
Artificial load for load test
Used by DECnet phase
Test controller
Artificial load for load test
Supported device data file
Magnetic tape device test
Terminal and line printer device test
DEUNA device test

358

uNOTE # 036
Page 25 of 25
Unsupported files for linking against system images:
RMS.STB
CLUSTRLOA.STB
MP.STB
SCSDEF.STB
RMSDEF.STB
IMGDEF.STB
DCLDEF.STB
NETDEF.STB

RMS symbol table
Symbol table for loadable VAXcluster routines
Symbol table for MP.EXE
Symbol table for loadable SCS routines
Global definitions for VAX RMS structures
Global definitions for image activator structures
Global definitions for DCL structures
Symbol table for network definition

BLISS Require Files:
LIB.REQ
STARLET.REQ
TPAMAC.REQ

Structure definitions of executive internals
for use by BLISS programs
User interface structures for use by BLISS programs
Structure definitions for BLISS programs using TPARSE

Superceded or obsolete:
VMSUPDATE.COM

For updating VMS or adding layered products

SUMMARY
This MicroNote details the contents of the MicroVMS system, as well as
the portion of VAX/VMS not supplied with MicroVMS.
The reader can use
this information to determine whether any unnecessary files
can be
omitted from a turnkey system. Additional information can be found in
MicroNote # 37 ("In Search of NanoVMS")
which describes a working
minimal VMS subset.
Further information about the structure of VMS can
be found in the full VMS document set (Order # QL001-GZ-V4.0 and update
QL001-WZ-V4.1),
"VAX/VMS Internals and Data Structures" (Digital Press,
1984) and the VAX/VMS source listings on microfiche
(source license
required see sales representative).
NOTE
DIGITAL does not recommend the deletion of any component
files of the MicroVMS or VAX/VMS operating systems
except where explicitly stated in
the
respective
document sets
(of which this is NOT a part). A subset
operating system cannot be warranted or supported by
DIGITAL in any way.
This MicroNote is to be used for
informational purposes
only,
and
represents
the
research,
conclusions and opinions of the author, not
those of DIGITAL or OEM Technical Support.

359

360

uNOTE # 037

Ti tIe:

In Search of "NanoVMS

Originator:

Date:. 19-Jul-85

Edward P. Luwish

Page 1 of 8

ABSTRACT
This MicroNote describes the results of ongoing research
into the size and composition of a minimal VMS system.

A WORD ABOUT NOTATION
Where command lines, prompts and messages are discussed,
text printed by the computer is indicated by normal
type, text entered by the user is
indicated
by
boldface type.
Unless explicitly stated otherwise, all user entries are
to be terminated by the "return" character.
WHY "NanoVMS"
MicroVMS as currently packaged a.nd supported by Digital Equipment
Corporation is not always an ideal solution for customers who would like
to use it as a realtime application bed (rather than a multi-user
timesharing system). For this reason, research has been done for over a
year on minimal VMS systems.
Also, the number of floppy diskettes
required to bring up the system hals been found excessive by some users.
Currently three floppies for standallone backup are followed by thirteen
for the base system.
This incurs user inconvenience and a greater
likelihood of failure in the process. The TKSO cartridge tape is not
yet a universal solution to this problem.
HOW WAS "NanoVMS" BUILT?
The problem was approached by building a VMS system, component by
component, on the second winchester of a two-disk MicroVAX. This system
could be tested simply by shutting the system down and booting the
second disk.
If unsuccessful, the full system disk would be rebooted,
some files added to the minimal sys;tem, and it would be tried again,
guided by the error messages produced in the previous attempt.

361

uNOTE # 037
Page 2 of 8
HOW WAS "NanoVMS BUILT? (continued)
The first cut at a solution was derived from the
"Reboot Consistency
Check" offered by sys$system: SHUTDOWN. COM.
Notably absent from the list
of files was the disk driver! A number of other missing files were
disclosed,
and
success was eventually achieved through repeated
attempts.
Often the proper functioning of an image depended on the
presence of another
(such as a library file).
The dependencies are
shown in the attached directory listing.
HOW DOES ONE GENERATE A "NanoVMS" SYSTEM?
1.

Make some choices

There are a number of choices which affect how you generate a
"NanoVMS"
system.
You can create a backup set that can be loaded onto a MicroVAX
processor using standalone backup [Note - floppies only.
TKSO bootable
Mic:roVMS distributions cannot be created without access to a source
kit].
The other choice is to create "NanoVMS" on a winchester and
physically install it in to another MicroVAX.
This choice a:Efects the
thi.rd and fourth steps in the process, "Creating the distribution" and
"Loading the distribution". Another up-front choice that affects your
work is the list of target CPU's you intend to be able to run "NanoVMS"
on
currently this includes MicroVAX I, MicroVAX II, VAXstation I and
VAXstation II.
The work on the latter two has not yet been done
special graphics font files and server files need to be added to the
list.
Read "Copy the files" below for details.
2.

Create the directories

If you have a single-winchester system, create [sysl].
If you have a
two-disk system,
create [sysO]
on the non-system disk instead.
In
either case, create the subdirectories [.sysexe],
[.syslib],
[.sysmgr]
and [.sysmsg] in the [sysO] or [sysl] directories you just created.
If you have chosen the distribution option of physically installing
a bootable winchester,
and your non-system disk's data is expendable,
then you will want to initialize it.
Study the section "Creating the
Distribution",
below, with respect to initialization options. After
initializing the disk, create the previously mentioned directories.
3 ..

Copy the files

Copy all of the files listed on pages 7 and 8 from the cbrresponding
directories of your MicroVMS V4.1M system.
Note that a MicroVAX I CPU
requires the file SYSLOAUV1.EXE and a MicroVAX II CPU
requires
SYSLOAUV2.EXE.
Make sure to include the correct one (or both) as
required by the t~rget CPU. Also be sure to use the /CONTIGUOUS option
when copying SYSBOOT.EXE.

362

uNOTE # 037
Page 3 of 8
4.

Create the distribution

You will fir s twa n t to dec ide whe t h Ie r you r dis t r i bu t ion will inc 1 ud e all
of the files (including your own application files) of the final system,
or merely a basic "NanoVMS" skeleton to which additional files are added
from separate disk volumes.
If the former, at least list and count all
the additional files you need.
Note that VMS utilities occasionally
need runtime library files,
and your application files may need
language-related runtime libraries not part of the basic "NanoVMS"
system.
Be sure to include some extra files in your count.
Remember
that there are nine files that are part of any VMS volume, and that each
directory and subdirectory you create is a file as well.
The nine files that are part of every VMS volume
INDEXF.SYS
oOOOaO.DIR
CONTIN.SYS

BITMAP.SYS
CORIMG.SYS
BACKUP.SYS

BADBLK.SYS
VOLSET.SYS
BADLOG.SYS

If you chose to create a backup set, simply issue the appropriate
mount and backup commands, and insert the floppies into the RXSO drive
(n
floppy unit number, x = "NanoVMS" disk unit number,
r root
number) :
:if

$ MOUNT/FOREIGN DUAn:
If you wish to merge your own software into the backup set:
$ BACKUP/INITIALIZE/LOG/VERIFY -m
$ DUAx:[SYSr •.. ]*.*i*,[yourdirectorY···]*·*i*-m
DUAn:MICROVMS./SAVE_SET

If you wish to separate your own software from the backup set:
$ BACKUP/INITIALIZE/LOG/VERIFY -m
$ DUAx:[SYSr .•• ]*.*i*-m
DUAn:MICROVMS./SAVE_SET

The backup set created will then install exactly as described in the
Installation chapter of the MicroVMS User's Manual.
with standalone backup, you lose flexibility in initializing your
system disk - it uses all the default values, which may be unsuitable or
wasteful in a bounded system.
It is therefore recommended to use the
"walking winchester" as a way to transport bounded systems.
You would
not be considering "NanoVMS" unless you have a legitimate need to save
disk space,
and standalone backup will often waste space.
The index
file on an RD-volume is greater than 1000 blocks in allocated size,
in
order to accomodate a large number of files on the disk.
If you can put
an upper bound on the number of files you expect to have,
you can
realize considerable savings in index file size.
The two parameters
which most affect disk usage, Clustf~r Factor and Maximum File Count, are
explained in the next two paragraphs.

363

uNOTE # 037
Page 4 of 8
4.

Create the distribution (continued)

The cluster factor is the number of disk blocks allocated every
time a new file is created, or if additional blocks are needed when
editing, etc. If you issue the DCL command
$ DIRECTORY/SIZE-ALLOCATION

you will notice that all the sizes are divisible by 3 (the default
cluster size for "large" disks). If you have many small files, this can
be wasteful.
Unless you add the /CLUSTER SIZE-n option to
the
INITIALIZE command, this number will be 3 for-disks larger than 50,000
blocks, or 1 for smaller disks.
Small cluster sizes will adversely
affect disk performance since files may be stored as many small pieces
sCclttered widely over the disk surface. On the other hand large cluster
sizes will waste disk space, since only one or two of the three (or
more) allocat~d blocks may have data in them.
The maximum number of files contained on a disk is determined at
initialization time by the number of empty file headers allocated
contiguously in the index file. The DCL command
$ INITIALIZE/MAXIMUM_FILES-x DUAn:

label

initializes a disk with an index file capable of storing x file headers,
no more. The largest value of x is derived from the formula
volume size in blocks
maximum number of files -

cluster factor + 1

The default (when the /MAXIMUM_FILES switch is omitted, or when
$ BACKUP/INITIALIZE

is issued) is equal to one-half the number derived by the above formula.
If the default is much larger than the actual largest number of files
you anticipate storing, then you can gain many free blocks by specifying
/ru~XIMUM FILES-x,
where x is an upper bound on the number of files you
expect on the disk. In fact, you get exactly (default maxfiles)-x free
blocks, since each file header occupies a full block. The potential
disadvantage is that the disk will have to be reinitialized (i.e.
erased) if you need to store x+1 or more files.
The following table can be compared with your overall needs, so
that the appropriate initialization command line can be given:

Volume Size
Cluster Factor
Maximum Files

RD51

RD52

RD53

19530

60480

138649 blocks
3
blocks
17331 files

4880

7560

364

uNOTE # 037
Page 5 of 8
5.

Load the distribution

If the distribution is the "walking winchester",
then loading it
consists of installing the disk in the MicroVAX enclosure, removing the
existing one if necessary.
Instructions for the installation and
removal of hard disk drives can be found in the system's Owner's Manual.
If the distribution is a backup set stored on a number of RX50
floppy diskettes, follow the instructions in the Installation chapter of
the MicroVMS User's Guide.
6.

Boot "NanoVMS"

This procedu~e departs from the normal process, since "NanoVMS" does not
have a paglng file or a system-parameter file, nor can it execute the
full system startup command procedure since many of the commands in it
try to invoke image (.EXE) files and libraries that are not on the disk.
A number of error messages
(shown below) will be displayed on the
console terminal.
These are normal for "NanoVMS".
To boot the system,
you must use the conversational boot by typing the commands

»> B/1 DUAn
2 •• 1 •• 0 ••

%SYSBOOT-E-Unable to locate file
SYSBOOT> SET STARTUP PI "MIN"
SYSBOOT> SET VAXCLUSTER 0
SYSBOOT> CONTINUE
Note
If your system i.s a MicroVAX I,
you will be prompted for the time
and date before the
"MicroVMS
Version 4.1M" text appears.
MicroVMS Version 4.1M 13-MAY-1985 22:29
%SYSINIT-E- lookup failure on paging file, status - 00000000
%DCL-W-ACTIMAGE, error activating image SETPO
-CLI-E-IMGNAME, imagefile DUAr.t:[SYSO.SYSCOMMON.][SYSEXE]SETPO.EXE;
-RMS-E-DNF, directory not found
-SYSTEM-W-NOSUCHFILE, no such file
%RMS-E-FNF, file not found
%SET-I-N9MSG, Message number 007781B3
SYSTEM job terminated at 8-AUG-1985 09:39:05.01

365

uNOTE i 037
Page 6 of 8
6.

Boot "NanoVMS" (continued)

At this point, press carriage return and you will be prompted with
"Username:".
Type any non-null alphabetic string,
followed by a
carriage return.
You will then be prompted twice with "Password:".
R&Spond both times with a carriage return.
The familiar "$" DCL prompt
will then appear.
The default directory is SYS$SYSTEM.
7.

Further steps ...

The only DCL commands available at this point are COPY,
BACKUP,
RUN,
MOUNT and DISMOUNT, and a very small subset of the SET commands.
If you
have access to a second winchester with a full MicroVMS systl~m on it,
you can mount it and copy additional files to your "NanoVMS" disk.
You
can also use BACKUP/SELECT to copy selected files
from the MicroVMS
di.stribution floppies.
Remember to try the commands first before
walking away, since sometimes additional files (primarily in sys$library
and sys$message) are needed.
A paging file is often needed, particularly for applications which
set up large arrays or data buffers, especially when the system has
limited physical memory.
DECnet requires a 1000 block paging file
just
to initialize itself.
The file can be created by the following
commands:
$ RUN SYSGEN
SYSGEN> CREATE PAGEFILE.SYS /SIZE=lOOO /NOCONTIGUOUS
SYSGEN> EXIT

To make it less painful to reboot, and to allow you to save any
system tuning work, create a parameter file with the following commands:

$ RUN SYSGEN
SYSGEN> SET STARTUP Pl "MIN"
SYSGEN> SET VAXCLUSTER 0
SYSGEN> WRITE CURRENT
SYSGEN> EXIT
The next time you reboot, you need only type "»> B DUAn".
In order to have a secure system,
or to have incoming DECnet
access,
or
to
support login command files or to run turnkey
applications, you will probably want a user authorization file.
To
support this, copy the following files from the MicroVMS distribution or
from
a
MicroVMS
system
disk:
sys$system:AUTHORIZE.EXE,
sys$library:MTHRTL.EXE
and
sys$library:PLIRTL.EXE
and
INSTALL
sys$library:SECURESHR.EXE with the /prot/shar/open
options.
When
running AUTHORIZE for the first time, you will create the authorization
file SYSUAF.DAT._ You will have to reboot before you can log in
successfully.

366

uNOTE i 037
Page 7 of 8
DIRECTORIES OF FILES NEEDED FOR "NanoVMS"
Directory DUAl: [SYSO.SYSEXE]
BACKUP.EXEi1

189

COPY.EXEil

DCL.EXE;l

132

DISMOUNT.EXE;l
DUDRIVER.EXEi1
F11BXQP.EXE;1
FPEMUL.EXEi1
INSTALL.EXEi1
JOBCTL.EXEi1
LOGINOUT. EXE i 2
PUDRIVER.EXE;l
RMS.EXEi1
RUNDET.EXE;l
SCSLOA.EX E i1
SET.EXEi1
STARTUP.COM;l
SYS.EXE;l

8
27
107
20
46
102
103
13
211
14
8
167
17
344

SYSBOOT.EXE;l
87
115
SYSGEN.EXEi1
87
SYSINIT.EXE;l
SYSLOAUV2.EXEi 1 15
45
TTDRIVER.EXEi 1
23
VAXEMUL.EXEi1
16
VMOUNT.EXEi1

Required for adding additional files
to basic "NanoVMS" from backup sets
Required for adding additional files
to basic "NanoVMS" from VMS volumes
Required by STARTUP.COM and subsequent
user command execution
Required to remove auxiliary volumes
Disk controller protocol driver
Files-11 server
Floating-point emulator
VMOUNT.EXE must be INSTALLed to be run
Required to create LOGINOUT as detached process
Permits logins·after STARTUP.COM exits
Disk controller port driver
RMS-32 server - required to find and open files
Required to run JOBCTL as detached process
Required when using MSCP system disks
Required to enable interactive logins
Sets up LOGINOUT and system logical symbols
The operating system image (except for
device and file support, instruction emulation)
The primary bootstrap
Required to alter and save system parameters
The first image to be run as a process
MicroVAX II processor-specific initialization code
The terminal driver
Emulates non--floating-point VAX instructions
Required to mount auxiliary volumes

Total of 24 files, 1954 blocks.
Directory DUAl: [SYSO.SYSLIB]
DCLTABLES.EXE;3 248
DISMNTSHR.EXE;l 11
ENCRYPSHR.EXE;l 18
LBRSHR.EXE;l
76
LIBRTL.EXEi1
128
LIBRTL2.EXE;1
39
MOUNTSHR.EXE;l 120
SCRSHR.EXE;l
21
SECURESHR.EXE;l 58

Required by
Required by
Required by
Required by
Required by
Required by
Required by
Required by
Required by

Total of 9 files, 719 blocks.

367

sys$system:DCL.EXE
sys$system:DISMOUNT.EXE
sys$system:BACKUP.EXE
sys$system:INSTALL.EXE
sys$system:JOBCTL.EXE
sys$system:JOBCTL.EXE
sys$system:VMOUNT.EXE
sys$system:SYSGEN.EXE
sys$system:BACKUP.EXE

uNOTE # 037
Page 8 of 8
DIRECTORIES OF FILES NEEDED FOR

~NanoVMS"

(continued)

Directory DUAl: [SYSO.SYSMGR]
ACCOUNTNG.DATi1

5 ! This file is created by LOGINOUT.EXE

Total of 1 file, 5 blocks.
Directory DUAl: [SYSO.SYSMSG]
SYSMGTMSG.EXEi1 49 ! Required for intelligible error messages
268 ! Required for intelligible error messages
SYSMSG.EXEi1
Total of 2 files,

317 blocks.

Grand total of 4 directories, 36 files, 2995 blocks.
Not shown:
Index file (see text)
Other files produced by volume initialization
Directory files (average 5 blocks each)
Page file (see text)
Sysgen parameter files (15 blocks each)

NOTE
This MicroNote describes a minimal VAX/VMS system which
is not in any way warranted or supported by Digital
Equipment Corporation - it reports ongoing research by
the author,
and repr~sents solely his conclusions and
opinions, not those of Digital Equipment Corporation.
The minimal VAX/VMS system described here can only be
used on MicroVAX computer systems which are licensed to
run MicroVMS.
It is composed of files which are normal
components of MicroVMS V4.1M.
Earlier or later versions
of
MicroVMS
may not successfully execute in the
described subset environment.

368

uNOTE. # 038

Title: DECnet Down-line Loading

Date: 26-Jul-85

Originator: Scott D. Blessley

Page 1 of 9

This article overviews the downline load process used by DECnet for
remote loading of PDP-11 and VAX processors.
Downline loading is a
versatile and complicated process.
This article is intended as an
introduction/aid to the process, not a tutorial. An extensive reference
list appears at the end of the article for
readers interested in
pursuing the subject further.

OVERVIEW OF THE DOWNLINE LOAD PROCESS

DECnet downline load is the set of hardware and software features which
allow complete systems
(RSX-11S and VAXELN) to be loaded into remote,
potentially unattended processors.
In addition,
RSX-llS offers the
capability to:
dynamically load tasks over comm lines, checkpoint tasks
out of memory over the line, and upline dump a failed operating system.
RSX-11S functionality is a subset of those features found in RSX-11M.
VAXELN also features a symbolic debugger that allows debug of the target
from the host processor.

2
2.1

DEFINITIONS
HOST

The host [node] (for this discussion) refers to both the machine which
originates the load,
as well as the machine which loads the software.
In actuality, these need not be the same machine.

2.2

TARGET

The target [node] ,is the machine being loaded with new software.
It
must be powered up,
but mayor may not have to be awaiting primary
bootstrap, de~nding on its communications bootstrap device and boot
options.

369

uNOTE # 038
Page 2 of 9
2.3

EXECUTOR

The executor [node] is the node which initiates the commands to downline
load a target.
It need not be the same as the host.

TARGET
(HOBSON: : )

<----------~

Load request

Operating System

NCP)TRIGGER NODE HOBSON

HOST
(FURILO::)

EXECUTOR
(FURILO::)

( " same CPU or
different)
Relationship between host, target, and executor nodes

PREPARING FOR DOWNLINE LOAD

There are three overall steps:
o

Configuring the communications hardware
target systems

host

and

Configuring the DECnet software and the operating system image
will be loaded.

that

Verification and testing.

both

the

The most frequent problem is the failure to correctly configure the host
and/or target hardware.
There are two principal places for error:
setting DIP awitches inappropriately resulting in incorrect
speeds, wrong power-up boot options (BSEL switches), etc.

line

Skew between hardware configuration and software
(for example
mis-specifying the vector/CSR or the Ethernet address for the target
device).
Be sure to have the latest version of the hardware
manuals.

370

uNOTE # 038
Page 3 of 9
Specific points to be careful about:
1.

Vector/CSR

B[oot]SEL[ect] switches - these specify under
comm interface will force a bootstrap.

conditions

the

Service password - this is a protection feature to lessen
likelihood of an inadvertent or malicious downline load.

the

Ethernet address (Ethernet circuits only) - the unique address
the target Ethernet device will respond to.

that

Service circuit - this
the target.

Enable SERVICE for the circuit being downline loaded. This enables
the DECnet software to start thE~ downline load process on the host.

Make sure event logging is enabled, or you'll miss error messages.

It may seem obvious, but make sure that the target comm device
you're using,
and the processor bootstrap are *capable* of doing'
what you ask.
For details,
see uNote 1015,
"Q-bus Hardware
Bootstraps"

RSx-11S OVERVIEW

identifiE~s

what

at the end of which wire to expect

Configure the RSX-11S image on a VAX/VMS, RSX-11M or RSX-11M+ system,
us i ng the no rmal tool s (SYSGEN, M.l-\C, TKB, VMR).
P repa re and bui ld the
host loader table.
(Refer to the References section for documentation
on RSX downline load procedures)

VAXELN OVERVIEW

The program/VAXELN image development sequence is:

Develop the source modules

LINK the source modules with the RTLSHARE.OLB and RTL.OLB libraries

EBUILD the LINKed image to produce a bootable VAXELN system.
To be
able to downline load the VAXELN image, you must select Boot Method
DOWNLINE in the VAXELN System Characteristics portion of EBUILD.

371

# 038
Page 4 of 9

uNOTI~

Downline load the target over Ethernet (this is not the only method
of loading a VAXELN target).
The target can be loaded through
EDEBUG commands, or via NCP LOAD/TRIGGER commands.

Debug the application and repeat steps 1-4.

~)ASCAL or C
L:tource prog.

.OBJ>I~ ~~AS or

I·EXE>~I_$__E_B_U_I_L_D__~I .SYS>~~_r_E_~_~_~_U_G__~
Other VAXELN
modules

VAXELN Program development sequence

OBSERVING & DEBUGGING

There are a variety of error indications, and diagnostic aids available.
Some are at the hardware level (comm device diagnostic LEDs), some from
the host software (upline dump for RSX-11S, EDEBUG for VAXELN).
Others
are provided by the DECnet components that handle downline load, through
the EVL (EVent logger) capability. Some diagnostic facilities:
1.

Device status LEDs give a numeric indication as to potential
hardware, or hardware configuration problems with the interface or
its connections~

Event logging messages:
Event code 0.3 - Auto service:
DLL is taking place.

indication that a portion

Event code 0.7 - Aborted service request:
indication that a
portion of a DLL load request is failing. This is not always
bad. For example, it is an acceptable "error" when multiple
hosts (on an Ethernet) offer service and the target accepts only
one. The remaining systems report event 0.7. EVL messages come
with varying amounts of diagnostic information. A 0.3 or 0.7
event in~ludes the type of load being requested, from where it
is requested, to whom it is requested, etc.

372

uNOTE # 038
Page 5 of 9
3.

Failure message from NCP on LOAD/TRIGGER commands insight as to the source of the problem

may

Line/circuit counters - indicate how much data has been
and received , and what errors have occurred.

give

some

transmitted

Remember: Enable event logging:
NCP SET LOGGING <facility> KNOWN
EVENTS STATE ON.
Otherwise, EVL will not display this diagnostic
information!

EXAMPLES

One the next three pages are examples showing the successful load of a
terminal server and a VAXELN target. The appearance of the output will
be approximately the same for your targets, only with different node
names and files.

373

uNOTE # 038
Page 6 of 9

$ reply/enable-network
%%%%%%%%%%% OPCOM 26-JUL-1985 13:09:11.96 %%%%%%%%%%%
Operator FURILO$RTA1: has been enabled, username BLESSLEY
%%%%%%%%%%% OPCOM 26-JUL-1985 13:09:11.99 %%%%%%%%%%%
Operator status for operator FURILO$RTA1:
NETWORK
$ run sys$system:ncp
NCP>show node hobson characteristics

!Hobson is a DECserver 100

Node Volatile Characteristics as of 26-JUL-1985 13:10:49
Remote node -

13.102 (HOBSON)

= UNA-O

Service circuit
Hardware address
Load file
Dump file

= 08-00-2B-02-0F-5F
=

SYS$SYSROOT:[DECSERVER]PS0801ENG.SYS

= SYS$SYSROOT:[DECSERVER]PSDMPOF5F.SYS

NCP>trigger node hobson
NCP>~Z

%%%%%%%%%%% OPCOM 26-JUL-1985 13:10:13.16 %%%%%%%%%%%
Message from user DECNET on FURILO
DECnet event 0.3, automatic line service
From node 7.272 (FURILO), 26-JUL-1985 13:10:13.04
Circuit UNA-O, Load, Requested, Node = 13.102 (HOBSON)
File = MOM$LOAD:PS0801ENG, Operating system, Ethernet address·
= 08-00-2B-02-0F-SF
%%%%%%%%%%% OPCOM 26-JUL-1985 13:10:18.08 %%%%%%%%%%%
Message from user DECNET on FURILO
DECnet event 0.3, automatic line service
From node 7.272 (FURILO), 26-JUL-198S 13:10:16.40
Circuit UNA-O, Load, Successful, Node = 13.102 (HOBSON)
File - MOM$LOAD:PS0801ENG, Operating system,
Ethernet address - 08-00-2B-02-0F-SF
DECserver-100 Downline Load Example

374

uNOTE i 038
Page 7 of 9
Below is an example of down-line load of a MicroVAX II system using
EDEBUG.
The first part of the illustration shows the DECnet volatile
database entries for the target, as seen from the system that ultimately
boots the target, and from another that fails to boot the target.
[This command is issued on system "BELKER"]
BELKER> NCP SHOW NODE TUBBS CHARACTERISTICS
Node Volatile Characteristics as of
Remote node -

7-AUG-1985 10:38:59

7.453 (TUBBS)

= UNA-O
= 08-00-2B-02-1C-63

Service circuit
Hardware address
Load file

DISK$USER:[SAMPLE.ELN]CHER.SYS;

[This command is issued from system "FURILO"]
FURILO> NCP SHOW NODE TUBBS CHARACTERISTICS
Node Volatile Characteristics as of
Remote node =

7-AUG-1985 10:40:52

7.453 (TUBBS)

Load file

= DISK$USER:[SAMPLE.ELN]CHER.SYS;
Command to downline load the VAXELN image from EDEBUG:

[This command and related output is from system "BELKER"]

$ EDEBUG/LOAD=PROG1 TUBBS
Edebug V2.0-00
Loading "TUBBS"
Connecting to "TUBBS"

(screen mode debugger)
Event log messages resulting from the EDEBUG command:
DECnet event ()".7, aborted service request
From node 7.272 (FURILO),
6-AUG-1985 16:13:14.46
Circuit UNA-O, Line open error, unrecognized component, Node
Ethernet address = 08-00-2B-02-1c-63
FURILO:: didn't nave this address defined in its
volatile database so it couldn't service the request
A

375

uNOTE # 038
Page 8 of 9
DECnet event 0.3, automatic line service
From node 7.190 (BELKER),
6-AUG-1985 16:12:51.34
Circuit UNA-O, Load, Requested, Node = 7.453 (TUBBS)
File = DISK$USER:[SAMPLE.ELN]CHER.SYS;, Operating system
Ethernet address - 08-00-2B-02-1C-63
BELKER:: did have the address, corresponding to an
entry for "TUBBS::" Here, the target system is
requesting an operating system load. BELKER's DECnet
software is acknowledging the request.
A

DECnet event 0.3, automatic line service
From node 7.190 (BELKER),
6-AUG-198516:12:57.62
Ci.rcuit UNA-O, Load, Successful, Node - 7.453 (TUBBS)
File - DISK$USER:[SAMPLE.ELN]CHER.SYS;, Operating system
Ethernet address - 08-00-2B-02-1C-63
BELKER responds with packet(s) containing the
requested O.S. code for the target

SUMMARY

This Micronote has presented an overview of the downline loading
process8
Many "components" are involved in the process - at least two
CPUs and at least two communication interfaces, target operati.ng system
and images plus host,
target,
and executor DECnet software.
The
procedure is akin to bringing up a complex, customized operati.ng system
up on a remote processor, without a local load device.
Once configured,
it offers the benefits of not requiring any mass storage devices
(resulting in higher MTBF and lower cost), plus the ability to bootstrap
a processor which my be physically inaccessible.
There is a great
amount of information on DECnet downline load.
There is no single
compendium, although each of the supported operating systems,
plus
VAXELN have a chapter on the subject.

376

uNOTE # 038
Page 9 of 9
9

REFERENCES

All of the following references are to Digital publications.
DECnet-RSX Volume IV - System Ma.nager's Guide AA-H224C-TC
Guide to Networking VAX/VMS - AP..-Y512A-TE (chapter 4)
QMA DMV11 Synchronous Controller Technical Manual EK-DMVQM-TM
DEQNA User's Guide EK-DEQNA-UG
DECnet Digital Network Architecture (Phase IV)
AA-N149A- TC

General

Description

IV)

Maintenance

DECnet Digital Network
Architecture
(Phase
Operations Functional Specification AA-X436A-TC
Networks and Communications

BUyt~r's

Guide ED-26347

"VAXELN Installation and Programming" AA-Z454A-TE
"MicroVax

Owner's Manual" EK-KD32-0M

"MicroVAX I Owner's Manual" (Release Notes) EK-KD32A-OM-CNl
Micronote #015, "Q-Bus Hardware Bootstraps"
Software Product Descriptions:
DECnet-11S #10.74
DECnet-11M #10.75
DECnet-11M+ #10.66
DECnet-VAX #25.03

377

378

uNOTE' # 039

Differences between KDJll-A and KDJll-B

Title:

Date: 8-Aug-85

Peter Kent

Originator:

Page 1 of 5

Purpose
The purpose of this MicroNote is to identify and discuss the differences
between the KDJll-A and KDJll-B CPU modules.
The table that follows lists the differences between the CPU modules.
Differences that require explanation follow the table and are marked *
FEATURE

KDJll-A

KDJll-B

Cache

Single tag

Dual tag

Yes

Boot/diagnostics *
control status reg.

Yes

Boot page *
control register

Yes

Boot configuration *
and display register

Yes

PMI support

On-board bootstrap
and diagnostic ROM

Instruction implementation differences
DCJ-ll speed/FPJll differences
Backplane compatibility

Maintenance register differences

*
cont'd

379

uNOTE # 039
Page 2 of 5
The differences between the CPU modules.

cont'd:

FEATURE

KDJ11-A

KDJ11-B

Module I .0.

M8192

M8190

Size

Dual

Quad

Power: 5 volt (12 Volt)

4.5

5.5 ( 0 .2)

AC loading

3.4

2.3

Console serial line

One
Cache

For a full discussion of cache memory as used on the KJD11-A and KDJ11-B
refer to MicroNote #9 and the KDJI1-A and KDJ11-B User's Guides.
Both
CPU modules have a similar cache organization using a nine bit tag.
This nine bit field contains information that is compared to the address
label, which is part of the physical address. When the physical address
is generated, the address label is compared to the tag field.
If there
is a match it can be considered a hit provided that there is entry
validation and no parity errors.
The KDJ11-B has an additional tag
store called the DMA tag.
The OMA tag is an identical copy of the cache
tag store and is used to monitor the main memory DMA updates while the
cache tag store monitors the DCJ11 requirements.
The presence of the
second tag store - DMA tag - allows the J-11 microprocessor to continue
processing after it has relinquished the system bus to a OMA device.
When the DMA tag detects a hit (main memory location written to by the
O~~ device), the microprocessor stops and relinquishes the internal
bus
to the cache controller to allow it to monitor further OMA activity on
the bus.
The KDJ11-A,
however,
has only one tag store and stops
processing as soon as it relinquishes the system bus to a DMA device.
PMI support
ThE~ PMI or Private Memory Interconnect is described
in MicroNote #30.
ThE! PMI consists of 14 unique signals which use the CD interconnect side
of the backplane of certain Q-bus backplanes.
PMI is used only with the
KDJ11-8 and MSVII-J.
PMI DATI and DATO bus transactions between the
KDJ11-B and MSV11-J are more than twice as fast as those between non-PMI
CPU and memory configurations.
The KOJ11-A does not offer a PMI
capability.
ThE~ Unibus adaptor used with PDP11/84 systems enables the Unibus map
if
a particular PMI signal - PMAPE (Unibus map enable) - is asserted and
disables the Unibus map when PMAPE is negated.
The memory modules
associated with PMI (MSV11-J) do not use this signal.
PMAPE is asserted
if Memory Management Register 3, bit 05 is set, and negates this signal

380

uNOTE # 039
page 3 of S
if MMR3 is clear.
If there are ~evices which require this signal to
work, the KDJ11-A will not and cannot (without warranty violating
modifications) be made to issue this signal.
KDJ11-B boot/diagnostic ROM
The are basically 3 parts to the ROM code.
The first part is the
diagnostic tests which are run at power up or at the initiation of the
operator.
These tests perform checks on the CPU module,
the memory
module(s),
and the Unibus adaptor for Unibus systems.
The second part
of the ROM is the boot code.
The following devices can be booted from
the KDJ11-B:
RA80/81/60, RDS1/S2, RXSO, RC2S, RL01/02, RX01/02, TUSS,
RKOS, TK2S/S0, TSOS, TU81, DEQNA, DECnet DUV11, DECnet DLV11-E,
DECnet
and DLV11-F.
The boot code can also start programs stored in the EEPROM
or programs stored in M9312 type boot ROMs located on the KTJ11 Unibus
adaptor module.
The third part of the the code allows the storing and
modification of parameters for the CPU,
the Unibus adaptor,
and the
system..
This portion of the boot code also provides support for the
EEPROM itself.
The user can also create (using a machine code editor)
his own custom boot code and save this code in the EEPROM.
Boot and diagnostic controller status register
The boot and diagnostic controller status register (BCSR) is both word
and byte addressable.
The BCSR allows the boot and diagnostic ROM
programs to test battery backup and reboot status, to set parameters for
the PMG (processor mastership grant)
counter and the line clock, to
enable the console halt on break feature and to enter or exit from stand
alone mode.
Boot page control register
The page control register is a read/write register which is both byte
and word addressable.
The PCR high byte provides the most significant
ROM address bits when the 16 bit RO~[ sockets are accessed by bus address
1777300-17773776.
The PCR low byte provides ·the most significant ROM
(or EEPROM) address bits when the 16 bit or 8 bit ROM sockets are
accessed by addresses 17765000-17765776.
Configuration and display register
The configuration and display register reflects the status of the eight
switches edge mounted at the top of the ~odule.
It also allows boot and
diagnostic programs to update the 8 bit LED display located at the top
of the KDJ11-B module.
Instruction set differences
a
read-modify-write
are
Instructions which are required to do
There are only 3
implemented differently on the KDJ11-A and KDJ11-B.
be
instructions which are defined by the PDP11 architecture to
They are the TSTSET,
uninterruptible during its read- modify-write.

381

uNOTE # 039
Page 4 of 5
WRTLCK,
and ASRB instructions.
The KDJII-A will
implement these
read-modify-write instructions differently than a KDJI1-B.
The KDJ11-A
processor uses the AIO signal outputs of the J11 to determine whether it
performs either a 1) DATIO cycle or 2) a DATI cycle followed by a DATa
cycle.
The KDJ11-A will ONLY do a DATIO Q-bus cycle when it executes a
TSTSET, WRTLCK or ASRB instruction.
Past implementations of the PDP-II
architecture have also implemented
other
instructions
doing
a
read-modify-write cycle as being uniterruptable.
The BIS (Bit Set)
instruction will be used as an example.
This instruction requires the
CPU to READ a word from memory, possibly MODIFY that word, then WRITE
the word back to memory.
A KDJ11-B uses a Q-bus DATIO cycle to
implement
this
instruction.
Therefore,
the instruction is not
interruptable between doing the READ and the WRITE.
When it executes
other instructions which want to do a read-modify-write operation like
the BIS instruction, it will use two separate Q-bus cycles.
This
implementation allows for an interrupt or DMA request to be granted
between the DATI and the DATa (case 2 above).
There are third party
vendors whose equipment assume that a BIS instruction will use a DATIO
bus cycle.
Those devices will work fine in a system with a KDJ11-B, but
will work intermittently in a system with a KDJ11-A because what they
assume to be uninterruptible is now interruptible and affects their
on-board firmware.
Speed and the FPA

FPA compatible

FPA on board

system

15 MHz

18 MHz

KDJ11-AA

Yes

Q18/Q22

KDJ11-AB

Yes

Q18/022

KDJ11-AC

Yes

Q18/Q22

KDJI1-BB

Yes

11/73

KDJ11-BC

Yes

11/73

KDJ11-BF

Yes

11/83

Notes on the above table
The 15 MHz or 18 MHz refers to the crystal frequency at which the DCJ-11
will
run.
FPA-means the FPJ11 floating point accelerator chip.
Refer
to MicroNote #25 for more information on upgrading with the FPJ11.
The
KDJ11-A is a CPU module that is not sold as part of a package system.
The reference to Q18/Q22 refers to the fact that the KDJ11-A can be used
in any 18 or 22 bit Q-bus backplane.
The notation 11/73 means that the
indicated KDJ11-B CPUs are used with the MicroPDP-11/73 systems and the
indicated KDJ11-B CPU are used with the MicroPDP-11/83 system.

382

uNOTE # 039
Page 5 of 5
Backplanes
The KDJll-A CPU may be used in any C~18/Q22 slot.
The KDJll-B,
being a
quad module must be accomodated in a backplane which has Q-bus in AB
slots and the CD interconnect in thE! CD slots.
The KDJll-B cannot be
used in a backplane (or that part of the backplane) where there is Q-bus
in both AB and CD slots.
Maintenance register differences
The maintenance register contains the following information in both the
KJDll-A and KDJll-B:
POK (power ok),
power up mode selected, HALT
status, Module ID, FPA available,
and Boot address.
The module ID
number is a
4 bit code that difj:ers between the KDJll-A and KDJll-B.
The ID number for the KDJll-A is 0001 and 0002 for the KDJll-B.

383

384

uNOTE # 040

Title: FPJll Theory of Operation

Date: 17-SEP-85

Originator:

Page 1 of 4

Bill Jackson

The goal of this MicroNote is to introduce the FPJll, a floating point
coprocessor
to
the
DCJll,
and
to explain the interprocessor
communication between the FPJll and DCJll.
Figure 1 shows a typical
DCJll based system which includes the FPJll.
For a discussion of FPJl1
support on the KDJI1-A processor, see MicroNote #025.

OCJll
DATA BUS
IDMR
FPJll

V
DMR

CACHE

r--~

FPE

AIO

>
>
>

ACK
5TL
DV
OP
ROY
FPE
AIO<3:07
ALE
5TRB
PRDC
ABORT
ADDR<2:0>

L
A
T
C

I
ADDRESS BUS

Figure 1 - Typical DCJll/FPJll Application

385

BUS
INTERFACE

uNOTE # 040
Page 2 of 4
The FPJ11 is a single chip floating point accelerator for the DCJ11
microprocessor.
Its coprocessor interface,
along with optimizations
within the chip allow for 5 to 8 times acceleration over the DCJ11
microcoded floating point performance.
The FPJ11 provides

Complete FP11 floating point instructions (46)

Two FP11 floating point data types (F and D)

Six 64-bit floating point accumulators

FEC floating exception code register

The FPJ11 interfaces as a true Co-processor.
The Bus Interface Unit or
BIU)
inputs all instruction stream data and decodes instructions in
parallel with the DCJ11.
Support microcode in the DCJll initiates all
I/O cycles required by the FPJ11.
This Co-processor interface allows
overlap of floating point instruction executing in the FPJ11 and integer
instructions executing in the DCJ11.
This allows for reduced execution
time by interleaving floating point and integer instructions.
The interface to the FPJ11 involves several DCJll signals which indicate
the state of the DCJ11 processor, and synchronize the two processors.
Table 1 lists the signals and their use in the FPJ11 interface, Figure 1
shows their use.
TABLE 1
DCJll/FPJll signals
DCJ11 signal

Use

AIO<3:0>
PRDC
STRB
DMR
FPE
ALE
DV
DAL<2:0>
FPA-OP
FPA-STL

Indicate to FPJ11 current DCJ11 cycle type
signal instruction decode to FPJ11
signal beginning of bus cycle to FPJll
used by FPJ11 to stall the DCJ11
indicate to DCJ11 a floating point exception
used to latch cache hit data (trailing edge)
used to latch non-cache data (trailing edge)
indicate GPREAD and GPWRITE information
signal to SI that writes come from FPA
used to stall DCJ11 during multiple FPA
instructions
indicates FPA data will be ready in 125ns
enable FPA output drivers

FPA-RDY
FPA-ACK

The DCJ11 supports several types of bus operations in communicating with
the external system.
Since the FPJ11 relies on the DCJ11 to initiate

386

uNOTE # 040
Page 3 of 4
all I/O cycles, the FPJ11 will monitor DCJ11 I/O cycles for activity.
'When specific I/O cycles occur,
the FPJ11 will 'wake up' and start
processing. A subset of the DCJll bus cycles are used by the FPJ11
in
communicating with the DCJ11 and the system interface (51).
These bus
cycles are listed in Table 2~
The bus read and write cycles are used to
read/write data to/from memory (or cache).
The GP transactions are used
for interprocessor communications between the DCJ11 and FPJ11.
Table 2
DCJ11 bus operations
Cycle

Description

IREAD
DREAD
WRITE
GPREAD
GPWRITE

latched to search for FP instruction
used for data fetches for FP instructions
used to write FP data back to memory
used to read FP data to DCJ11 internal registers
used to write FP data to DCJ11 internal
registers

The DCJ11 divides all bus reads into 3 categories:
Instruction stream
Demand READ (IDREAD), Instruction stream Request READ (IRREAD), and Data
stream READ (DREAD).
Instruction stream reads are used by the DCJll to
fetch instruction stream data such as PDP-11 instructions, immediate
data and absolute data. All other DCJ11 reads are classified as Data
stream reads
(for more information on DCJ11 bus cycles and data
classification see the DCJ11 data sheet EK-26921-00)
Request reads are reads that the DCJll will attempt when doing internal
cycles such as register transfers.
This is an attempt at filling the
DCJ11 4 stage pipeline.
Demand reads are reads that must be completed
in order to finish an instruction.
The DCJ11 will always try to keep
the pipeline full by doing request reads, but will do demand reads as
necessary.
The most typical FPJll operation is the common FP11 instruction that
reads some data from memory, operates on it, then writes the result back
to memory.
In this operation, the FPJ11 monitors the DCJll bus cycles
for either type of instruction stream read. When the FPJ11 sees any
type of Instruction stream read,
it latches the data from
the
data/address lines (DAL) and holds it in its instruction register.
The
FPJ11 keeps doing this until it sees the DCJ11 indicate that it is now
doing a
ins~ruction
decode by the assertion of the DCJ11 signal PRDC.
The FPJ11 then does a parallel decode of the instruction and checks if
it is a
floating point instruction.
If the instruction is not a
floating point instruction, the FPJ1l 'goes to sleep' and continues to
latch. all I-stream read data.
If the instruction is a floating point
instruction, the DCJ11 will initiate all bus cycles while the FPJ11 will
remove data from the bus.
The FPJ11 will then do the floating point

387

uNOTE # 040
Page 4 of 4
operation.
If the operation is a store type operation the DCJll will
initiate the bus write operation signaling to the FPJll to write data to
memory~

When either the sourca or destination of the floating point instruction
is a DCJll general purpose register, a GP cycle will be used to access
the DCJll register.
Load type operations would use the GPWRITE bus
cycle to write the contents of the DCJ11 register to the FPJ11.
GPREAD
operations are used to read data from the FPJll and deposit it into the
DCJ11 general purpose registers.
Because of the overlapping instruction capability,
the DCJll/FPJ11
combination can start to fetch operands for a next floating point
operation while one is executing.
Because there is a single datapath
internal to the FPJ11,
this prefetched data must not get to the
execution unit until the current operation is finished.
The FPJll will
output FPA-STL to the DCJll if the current operation will not be
completed before all of the data is ready.
This mechanism guarantees
that the datapath will only be used by one floating point operation at a
time. When the FPJ11 is done with the current operation the DCJ11 is
continued, and the floating point operation proceeds.

388

uNOTE # 041

Title:

Device Ordering Chart for Q-bus Systems

Originator:

----.

Jack Howes and Peter Kent

Date: 16-Sep-85
Page 1 of 6

Primary Device Ordering Determination
DMA devices as well as interrupt devices on the Q-bus are position
dependant.
That means that the order in which devices are placed in the
bus relative to the CPU determines in what order their DMA (or
interrupt) requests will be serviced.
The primary factor in determining the device sequencing order is the
length of time that each device can wait to become bus master without
error.
These errors normally occur when a controller's data buffer
fills
to capacity before the device connected to it has finished its
transfer.
Generally, the cause of this is a higher priority device
(or
devices)
transferring data over the Q-bus, and the controller that gets
the error is blocked from becoming bus master.
Characteristics that
influence whether a device will fail in this way are:
the on board
buffer size that a controller/device has,
the intelligence of the
controller/device, and the transfer speed of the device connected to the
controller.
Methodology
There has been an in-house test instrument developed which can detect
the failure of Q-bus devices when they cannot get bus service.
This
measurement is the length of time a device can wait before getting a
data late or device timeout error.
The test instrument can be
programmed to hold the Q-bus, per acquisition, for any time between 1
microsecond and 3.9 milliseconds.,
It runs in conjunction with the
device under test.
During the test process the length of time the test
instrument holds the Q-bus is variE~d until the device under test fails.
This measurement is called "latency tolerance".
Holding the Q-bus for
3.9 milliseconds is equivalent to the test instrument transferring 4095
words (non-block mode DMA) per assertion of BSACK.

389

uNOTE # 041
Page 2 of 6
Secondary Device Ordering Determination
The large buffer sizes and intelligence built into some of the newer
controllers make them less susceptible to data late or device time out
errors.
These devices do not get an error waiting for the Q-bus up to
3.9 milliseconds and consequently are ordered by other criteria:
1.

The type of Q-bus transfer they do (block mode, burst mode or single
cycle).
See
MicroNote #12 for a description of Q-bus DMA
transaction types.

If interrupted by a lower priority DMA device will they pass the
Q-bus (DMG) grant signal, when they are doing a blockmode transfer.

The effect the ordering has on device and system performance.

The power consumption and/or cabling requirements of the device.
Examples:

A magtape advertise~ as a "streaming" tape drive may not stream if
it is assigned a lower priority than a device that utilizes a
significant amount of bus time.
In this instance the tape drive
will be ordered ahead of a device that it would normally follow
according to its latency tolerance.

A device that consumes a substantial amount of power may have to be
configured in an expander box with another power supply for
practical reasons, even though this device would normally precede
other devices.

The following pages contain the recommendations for the order of devices
on the Q-bus. Also contained in these pages are the measurements taken
and the reasons for suggesting the guidelines.
This ordering table is
only a guideline for Q-bus system configurations, and it should be noted
that a system will work satisfactorily in many other configurations as
well.
Additionally,
customers may alter the configurations to better
meet their specific application needs.
The measurement process to determine the device sequence chart has been
an evolving one and as such not all the devices on the chart contain the
same data.
The measurements on this chart were only true for the system
that they were measured on.
These measurements will vary from system to
system dependent upon the memory type, system architecture
(mapped or
unmapped. DMA)
and the speed of each CPU's arbitrator logic.
The
variations in measurements that can occur between CPU's should not
theoretically effect the bus placement of each device.

390

uNOTE # 041
Page 3 of 6
Table 1 lists the order in which devices should be placed in the Q-bus.
please refer to the detailed information about each device that follows
the table.
Table 1

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

T5V05 9 track magtape controller
DMV11 Microprocessor controlled DECnet communications interface
TQK25 Controller for 8 inch magtape drive
DHV11 Microprocessor controlled communications multiplexor
DEQNA Ethernet controller
TQK50 Controller for single spindle cartridge magtape
RLV12 Controller for 14 inch RL series disk drives
RQDX3 Controller for 5 1/4 inch RD/RX drives
KDA50 Controller for 14 inch ~\ series disk drives
RQC25 Controller for 8 inch RC25 series disk drives
RQDX2 Controller for 5 1/4 inch RD/RX drives
DRV11-WA General purpose 22 bit: DMA interface

Table 2 lists the transfer time and time between requests for DATI
DATO cycles and latency tolerance. All times are microseconds.

391

and

uNOTE # 041
Page 4 of 6
Table 2

No. words
transferred

Transfer time
DATO
DATI

TSV05

1 word

2.8

DMV11

1 word

3.1

TQK25

4 word
block mode

5.1

Device

Time between
requests
DATI
DATO

Latency
tolerance

8.7

280

@ 56

Kbits

175

280
4 W single
& burst mode

7.25

DHV11

1 word

2.15

DEQNA

16 word
block mode

11.78

13.87

5.1

- or >
3900

TQK50

4 word
burst

9.49

10.7

24.35

20.63

- or >
3900

1200

RLV12

4 word
burst

7.09

7.8

5.92

5.7

- or >
3900

RQDX3

16 word
block mode

13.5

12.7

4.48

- or >
3900

KDA50

8 word
block mode

9.0

8.9

6.68

- or >
3900

RQC25

2 X 8 word
block mode

14.84

16.52

15.41

14.41

- or >
3900

RQDX2

16 word
block mode

15.23

15.48

1.7

- or >
3900

DRV11-WA

4 word
burst

6.6

7.0

0.17

- or >
3900 *

* for DEC/X11 only

392

uNOTE # 041
Page 5 of 6
Additional device information
TSVOS
This device does not do 16 word block transfer so it doesn't monitor the
Q-bus BDMR (DMA request line) signal.
DMV11
This device does not do 16 word block transfers, so it
the Q-bus BDMR signal.

doesn't

monitor

Latency Tolerance was determined while running DECNET on a uVAX-I.
The
following error occurred when the DMV11 was held off the bus for more
than 17Sus:
"COPYEOPENIN RMS-F-SYS, QIO Request Failed,
SYSTEM-F-LINK
exit".
TQK25
This device does not do 16 word block transfers, so it
the Q-bus BDMR signal.

doesn't

monitor

DHV11
This device does not do 16 word block transfers, so it doesn't monitor
the Q-bus BDMR signal.
It performs DMA on output to the controller,
however is interrupt driven when accepting data from the attached
asynchronous lines.
DEQNA
This device monitors Q-bus BDMR signal and passes grant when interrupted
by a lower priority device.
This device is placed relatively close to
the CPU because it cannot quickly recover from bus latency conditions.
Re-transfers over the ethernet are costly in system resources.
TQK50
This device d~es not do 16 word block transfers, so it
the Q-bus BDMR signal.

doesn't

monitor

While this tape drive has a high latency tolerance, it should be placed
in front of the other devices that utilize a significant amount of bus
time.
Doing this enhances its ability to stream data.

393

uNOTE # 041
Page 6 of 6
RLV12
This device does not do 16 word block transfers so it doesn't monitor
the Q-bus "BOMR" signal.
It is configured in this position because of
its ability to avoid bus latency conditions even though it doesn't do
block mode transfers.
RQOX3
This device monitors BOMR and passes grant when interrupted by a
lower
priority device.
This device may have to be placed as the last device
in the CPU box because of cabling requirements.
KDA50
Instead of monitoring BDMR, the KDA50 does an eight word block transfer
and releases the bus between transfers to allow other devices access.
Although this device works more efficiently before the RQOX2 and RC25,
it may have to be configured in an expansion box due to its high power
consumption.
RQC25
This device does not monitor BDMR.
It performs two consecutive eight
word block transfers, during which it will not pass the grant to a lower
priority device.
RQDX2
This device monitors BDMR however it does not pass grant to a lower
priority device when interrupted.
It holds the Q-bus from a lower
priority device for 288us average.
In a dual expander box system this
device may have to be configured in the first expansion box due to
cabling requirements.
DRV11-WA
This device does not do 16 word block transfers so it doesn't monitor
the Q-bus BOMR signal.
The DRV11-WA may "monopolize" the bus if traffic
to/from the devi~e is sufficiently high.
The placement of this device
is very dependent upon the customers application.
For DEC/X11 and
diagnostic testing it should be configured as the last device on the
Q-bus.

394

APPENDIX A
TABLE OF CONTENTS
ORIGINAL MICRONOTES

001
002
003
004
005
006
007
008
009
010A
011
012
013
014
015
017
018
019
020
021
022
023
024
025
026
027A
028
029
030
032
033
034
035
036
037
038
039
040
041
042
043
044
045
046A
047
048
049
050
051

BATTERY BACKUP
REV11 PROM CHIPS
MACRO & ASSEMBL ON THE 11V03
4K RAM IN BANK 0
IEEE BUS SUB-SPECS
CORRECT MU BASIC LANGUAGE MANUAL
MEMORY IN LSI-11 AND 11/03 SYSTEMS
DMA DEVICES IN LSI-11 SYSTEMS
HEX AND QUAD HOLD-DOWN BRA.CKET FOR LSI-11 SYSTEMS
POWER SUPPLY FOR H909C
LSI-11 HALTING DURING INTERRUPT CYCLE
LSI-11 BUS THEORY OF OPERATION
INSTALLING APL-11 ON 11V03 AND 11T03
CORRECT INPUT PARAMETERS FOR THE QJV11 PROM
FORMATTING PROGRAM
POWER SEQUENCING FOR THE KD11-HA MODULE
LSI-11/2 PROCESSOR CLOCK
DR11-C VS. DRV11
EIA RS-422 AND RS-423
9 X 6 SLOT BACKPLANE DOCU~ENTATION ERROR
COMPARISON OF DATA TRANSMISSION TECHNIQUES
MRV11-BA NEW FEATURE
USING THE MSV11-D 30K OPTION
ASYNC., SERIAL LINE UNIT COMPARISONS
CONFIGURING MEMORY SYSTEMS WITH MSV11-D RAM & PROM
MICRO BACKPLANE MECHANICAL MOUNTING GUIDELINES
PROM CHIPS AVAILABLE UNDER PART #MRV11-AC
EXTENDED MEMORY FOR THE LSI-11
USING THE MRV11-AA FOR A BOOTSTRAP ROM
SRUN SIGNAL
EXTENDED BUS TIME-OUT LOGIC
CABLES FOR DLV11, DLV11-E, DLV11-F
CONFIGURING A 3-BOX 11/03 SYSTEM
PROM PROGRAMMING
CORE MEMORY IN 11/03-L BACKPLANE
C-D INTERCONNECT SCHEME
DIAGNOSTICS FOR 30K MEMORIES ON LSI-11'S
DMA REQUEST/GRANT TIMING
PARCHES FOR BASIC/PITS ON LSI-11
NEW FUNCTIONS FOR BDV11-AA BOOT
REMOVING MODULES FROM "LIVE" BACKPLANES
BACKPLANES FOR THE RLV11 (RL01)
CONS"OLE ODT "L" COMMAND ON 30K SYSTEMS
MOUNTING LSI-11/2 MODULES ON THE EUROtARD
DLV11-F REPLACEMENT FOR THE DLV11
INCOMPATIBILITY BETWEEN THE REV11 AND THE LSI-11/23
LSI-11/23 INSTRUCTION TIMING (PRELIMINARY)
SYSTEM DIFFERENCES - LSI-11 VS. LSI-11/23
MICRO ODT DIFFERENCES - LSI-11 VS. LSI-11/23
DIGITAL SUPPORTED PROM'S

052
053
054
055
056
057
058
060
061
062A
063A
064A
065A
066
067B
068
069
070
071
072
073
074
075
076
077
078
079
080A
081
082
083
084
085
086
087
088
089
090
091
092
093
094A
095
096
097
098
099
100
101
102
103
104
105
106

PARITY MEMORY IN LSI-11/23 SYSTEMS
PDP-11 FAMILY DIFFERENCES
MXV11 CONFIGURATION
LSI-11 VS. LSI-l1/23 BUS TIMING
DLV11-J CABLING
LOCATION OF W13 ON THE BDV11
CONFIGURING MEMORY FOR LSI-11 SYSTEMS WITH MORE THAN
64K BYTES
MAXIMUM CONFIGURATION OF DLV11-J MODULES
PROGRAMMING THE MRV11-C
BOOTSTRAPS FOR TU58, RL01, RK05, RX02, RX01
RL01 TYPE-IN BOOTSTRAP
DLV11-J I/O PAGE ADDRESS PROBLEM REPORT
BOOTSTRAP FOR RX02
11/123 FLOATING POINT COMPATIBILITY
DLV11-J RECEIVER CHIP PROBLEM
MICROCOMPUTER MODULE ENVIRONMENTAL CONSIDERATIONS
18-BIT DMA WITH CHIPKITS
LSI-11 VS. LSI-11/23 TRANSACTION DIFFERENCES
EXPANDING BA11-MA AND BA11-NC BASED SYSTEMS
PERIPHERAL COMPATIBILITY WITH 11/23 SYSTEMS
TU58 CABLING
MXV11-AA, -AC CABLING
MXV11-A2 BOOTSTRAP ERROR HALTS
DLV11-F CURRENT LOOP PROBLEM
SUMMARY OF BOOTSTRAP SOURCES
LSI-11/23 PROCESSOR DIFFERENCES
THE LSI-11/23 AND THE LSI-11/2BUSES ARE THE SAME
LSI-11/23 I/O PAGE ADDRESSING
USE OF RECOMMENDED DISKETTES
HANDLERS FOR SERIAL LINE PRINTERS
ALTERNATE CLOCK FREQUENCIES FOR THE MXV11
IMPROVED DLV11-F
WAKE-UP CIRCUIT IMPLEMENTATIONS
INTERFACING TO THE TU58 W/O BREAK
TYPE-IN BOOTSTRAP FOR TU58
RT-11 V3B FB MONITOR AND TUS8'S
STANDALONE PROBLEM LOADER
USING THE BAll-VA IN SMALL SYSTEMS
USING THE MXV11-A2 BOOTSTRAP ON THE MRV11-C
TWO POTENTIAL PROBLEMS WITH THE RXV21
USER WRITTEN SYSTEM TASKS UNDER RT-11 V4
RL02 SUPPORT BY DIGITAL SOFTWARE
VTI03 APPLICATIONS FOR UNUSUAL BAUD RATES
TU58 TIPS
TUS8 TAPE FORMAT AND ADD.RESSING MODES
11/23 & 11/03 RL01 BASED PACKAGED SYSTEM EXPANSION
RL02 BOOTSTRAP FAILURES USING BDV11
UPG~DES FOR PB11
TU58 SYSTEM POWER PROBLEM
MMU CONFIGURATION JUMPERS
CREATING A DIAGNOSTICS DECTAPE II UNDER XXDP+
11/23 ECO STATUS
MXV11 BOOTSTRAP PROBLEMS
MXV11 FUNCTIONALITY

107
108
109
110
111

22-BIT ADDRESSING FOR DMA CHIPKIT USERS
ADV11-A,AAV11-A,KWV11-A vs. ADV11-C,KWV11-C,AAV11-C
DIFFERENCES
USING THE FALCON SBC-11/21 IN A STANDALONE ENVIRONMENT
MUL, DIV, AND ASH INSTRUC~rION FOR THE FALCON SBC-l1/21
DIFFERENCES BETWEEN MSVI1-L AND MSV11-p MEMORIES

APPENDIX B
Subject Index - By MicroNote Number

BDV11
Backplanes
Block Mode DMA
Bootstrap
C

35
2,12
3,15
27

Cache
9
40
DCJ11
38
DECnet
33
DL-type devices
19
DLV11-J
12,41
DM
Disabling RAM
19
38
Down-line loading
ECO
17
EIS extended instruction set 1
25,40
FPJ11-A
Falcon
1,7
Falcon-Plus
1,7
21,25
Floating point
11
I/D space
I/O programming
10
J-11 see DCJ11
KA630 see MicroVAX II
KDJ11-A see LSI-11/73
30,39
KDJ11-B
16,18,32
KXT11-C
34
18
KXT11-C DMA controller
KXT11-C multiprotocol SLU
34
32
KXT11-C parallel port
4,6,17
LSI-11/23
3,4,6
LSI-11/73
8,9,11
25,39,40
3
LSI-11/73 bootstrap options
18,32,34
MACRO-11
19
MRVI1-D
28,30
MSV11-J
28
MSV11-M
28,31
MSV11-Q
20
Mxv11-A
3,4
MXv11-A2
19, 20
MXV11-B
3, 4
MXV11-B2
28,31
Memory differences
8,11
Memory management
7
Memory maps
8,9,11
Memory systems
4
MictoPDP-11/23
13,16
MicroPower/Pascal
10
MicroVAX
21,22,23
MicroVAX I
22,23,26
MicroVAX II
36,37
MicroVMS
36
MicroVMS files description
B1

Minimum MicroVMS system
37
Module differences
20
Multicomputing
26
NanoVMS
37
PDP-11/23 Plus
4
PDP-11/84
30
Pascal
14,27
Performance evaluation/data 13
Private Memory Interconnect 30
Processor differences
4,22,23
24,39
Processor upgrades
4,23
Q-bus expansion
29,35
Q-bus memory
28,30
Q-bus operation
2,5,10
12,26,29
35,41
Q22
5
RSX-11s
38
SBC-11/21-Plus see Falcon-Plus
Software development
16,18,27
32,34
System configuration
29,33,35
41
VAX-11 Fortran
14
21,24
VAX-11 instruction set
14,27,38
VAXELN