Digital PDFs

AA-H267B-TC

October 1982

330 pages

Original

105MB

view download

OCR Version

42MB

view download

Document:	RSX-11M-PLUS Guide to Writing an I/O Driver
Order Number:	AA-H267B-TC
Revision:	0
Pages:	330
Original Filename:

OCR Text

RSX-11M-PLUS
Guide to Writing an 1/O Driver
Order No. AA-H267B-TC

RSX-11M-PLUS Version 2.0

digital equipment corporation - maynard, massachusetts

First

Printing,

October

Revised,

March

1979
1982

The information in this document is subject to change
without
notice
and
should
not
be
<construed
as
a commitment by Digital Equipment
Corporation.
Digital Equipment Corporation assumes no
responsibility
for any errors that may appear

in this document.

The software described in this document is furnished under
a
1license
and
may
be
used or copied only in accordance with the terms of such
license.

responsibility

equipment that
affiliated

is assumed

for

the

use or

is not supplied by Digital

companies.

its

1979, 1982 by Digital Equipment Corporation
All

Rights

Reserved.

The postpaid READER'S COMMENTS form on the

requests

reliability of software on

Equipment Corporation or

last page of this

document

the user's critical evaluation to assist in preparing future

documentation.

The following are trademarks of Digital Equipment Corporation:
DEC
DEC/CMS
DECnet
DECsystem-10
DECSYSTEM-20
DECUS

DECwriter

DIBOL

EduSystem

IAS
MASSBUS
PDP
PDT

RSTS

RSX

UNIBUS

VAX
VMS
VT

mgnan

ZK2150

HOW TO ORDER ADDITIONAL DOCUMENTATION
in Continental USA and Puerto Rico call

800-258-1710

In New Hampshire, Alaska, and Hawaii call 603-884-6660
In Canada call

613-234-7726 (Ottawa-Hull)
800-267-6146 (all other Canadian)

DIRECT MAIL ORDERS (USA & PUERTO RICO)"
Digital Equipment Corporation
P.O. Box CS52008
Nashua. New Hampshire 03061

DIRECT MAIL ORDERS (CANADA)

Digital Equipment of Canada Ltd.

940 Belfast Road

Ottawa, Ontario K1G 4C2
Attn: A&SG Business Manager

DIRECT MAIL ORDERS (INTERNATIONAL)
Digital Equipment Corporation
A&SG Business Manager
c/o Digital's local subsidiary or
approved distributor

*Any prepaid order from Puerto Rico must be placed
with ihe local Digital subsidiary (809-754-7575)

Internal orders should be placed through the Software Distribution Center (SDC), Digital Equipment

Corporation, Northboro, Massachusetts 01532

CONTENTS

Page

PREFACE

xiii

SUMMARY OF TECHNICAL CHANGES
CHAPTER 1

RSX-11M-PLUS I/0 DRIVERS

1-1
1=2
1-2
1-4
1-4
1-4

1.1
1.2
l.2.1
1.2.2
1.3
1.3.1
1.3.2

VECTORS AND CONTROL AND STATUS REGISTERS . . . . .
SERVICE ROUTINES 2 4 ¢ o o o o o o o o o o o o o« o«
. . . + ¢« + o « « o«
Executive and Driver Layout
e o+ o o s e o o «
.
Contents
Driver
EXECUTIVE AND DRIVER INTERACTION e o o o o o o o «
.
The Driver ProCesSsS . « « o o « o o o o o
Interrupt Dispatching and the Interrupt Control

1.3.3
1.3.4
1.4
1.4.1
l.4.2
1.4.3
1.4.4
1.4.5
1.4.6
l1.4.7
1.4.8
1.4.9
1.5
1.5.1
l.5.2
1.5.3
1.6

Interrupt Serv1c1ng and Fork Process « « « o« « o« 1-8
. . . . . « . . 1-9
Nonsense Interrupt Entry Points
1-10
o « o« » o « o«
«
2
¢
«
.
FEATURES
DRIVER
ADVANCED
1-10
. + + o « ¢ o o « o« « « »
Overlapped Seek I/O
1-11
o«
»
«
o
o
o«
o
o
«
&«
o
«
=«
Dual-Access SUPPOrt
1-11
e o o o o o o
. .
Delayed Controller Access
1-11
Controller Reassignment and Load Sharing . . .
1-12
Common Interrupt Dispatching . . . .. « « . «
1-13
. « ¢« ¢ « « ¢ o o o o« o«
Subcontroller Devices
1-13
Full Duplex Input/Output . . . . « « « « &« « o+
1-14
. . « « ¢+ « « o« « o
Buffered Input and Output
1-14
.
«
«
«
«
¢«
«
¢«
¢«
¢«
.
.
n
I/0 Queue Optimizatio
1-16
. o « o o o o o o o s o s o o« «
DISTRIBUTED I/0
1-16
.« o o « o o o o o o « o o o« «
UNIBUS RUNn Mask
1-17
Conditional FOrk .« « o« « o o o o o o s o o o «
1-17
e o o o
Processor-Specific Functions
OVERVIEW OF INCORPORATING A USER~WRITTEN DRIVER
1-18
. + « ¢ « o o o o s o o o« « «
INTO RSX~-1IM=PLUS
1-20
+ & o o o o o o o o o o o o o o o o
SPR SUPPORT

1.7
CHAPTER 2

2.1

2.1.1
2.1.2

2.1.3
2.1.4
2.1.5
2.2
2.2.1
2.2.2
2.2.3
2.2.4
2.2.5
2.2.6
2.3

Block

o«

@«

1-5

DEVICE DRIVER I/0 STRUCTURES

e o o s o e o
I/0 STRUCTURES . .
Controller Table (CTB) e e s s e o
Controller Request Block (KRB) . .«
Device Control Block (DCB) &« o « o
Unit Control Block (UCB) ¢ o« « « o
Status Control Block (SCB) « + o« o«
e o o o
DRIVER DISPATCH TABLE (DDT)
I/0 Initiation . « « ¢ ¢ ¢ ¢¢ o s
Cancel I/0 ¢ o o o . o o s o o o o
Device TimeouUt « « « « o o o s o o
Device Power Failure . . « o,¢ o« o
Controller and Unit Status Change
Device Interrupt Addresses . . « «
. « «
TYPICAL CONTROL RELATIONSHIPS
iii

o o
&
«
o o
« s
« o
o s
« o
o o
s o
s o
. .
« o«
o «

&
«

o
«

o
o
o«
o
o
o
.
«
o

o
o
o
o
o
o
.
o
o

o
o

&«

o
«

o
o
o
o
o
o
o
o«
«
«
«

o
o

o
o
«
o
o
o
o
s+
.
o
o

o 2-1

o 2-1
. 2-1

o 2=2
o« 2-3

o«
»
o
»
o«
o
.
o
o«

2-3
2—-4
2-5
2=5
2=5
2-6
2-6
2-6
2-6

CONTENTS

Page

7.4.2
7.4.3

Allocate Core
Assign UNIBUS

Buffer . .
. .
e
Mapping Reglsters

e
e

¢
o

o
o

s
o

o
o

7.4.4
7.4.5

Check Logical
Move Block of

Block
Data .

o
o

s
¢

o
o

s
o

o
o

o
o«

1-10
71-11

CHAPTER

Buffer

.
«

e
«

o
o

o«

[1-12

. « o«
Number

¢
.

o
.

¢
.

o
.

o
«

o
«»

o
«

«
«

1-13
7-14

7.4.6

Check

Clock Queue Insertion
Convert Logical Block

7.4.9

Deallocate

o«

1-15

7.4.10
7.4.11
7.4.12

Deassign UNIBUS Mapping Reglsters
Device Message Output
. « o ¢ ¢« o
FOrk o« o o« o« o o o o o o o s o o o

«
o
o

s
o
s

o
o
o

o
o
o«

o
o
»

o«
o
«

1-16
1-17
[1-18

7.4.13
7.4.14
7.4.15
7.4.16
7.4.17
7.4.18

Forkl
. o
Get BYEE o
Get Packet

o
a
&
~
¢«
o

o
o
o
o
o
o

o
o
o
o
o
s

o«
o«
e

o«
o
o

o
&«
o

o
«
o

«
o«
o
o
«
»

1-19
1-20
1-21
1=-23
1-24
1=25

7.4.19
7.4.20

Interrupt Exit . .
I1/0 Done Alternate

. .
c e
Entry and

o e
I/0

o o e
Done

o
.

&
.

o
.

o
o

1-26
71-27

7.4.21

I/O

Finish

1-28

7.4.22
7.4.23

Map
Map

UNIBUS
UNIBUS

to
to

. . .« .
.
.
(Alternate Entry)

e
e

o
«

o
o«

1-29
1-30

7.4.24
7.4.25
7.4.26
7.4.27
7.4.28
7.4.29
7.4.30

Put BYte ¢« ¢ ¢« o o« o o o o o o s
Put Word . .
i
e + o s o o o
Queue Insertlon by Priority
. «
Relocate . . . .
e o o o s s s
Relocate UNIBUS Physxcal Address
Queue Kernel AST to Task « ¢« ¢ o
Set Up UNIBUS Mapping Address
.

s
o
&«
s
o
o

o
s
«
o
o
o
e

o« »
o o
« o«
« o
o o
o« .«
o o

1=31
1=32
7-33
1-34
1-35
1-36
1=37

7.4.31
7.4.32

Set Up UNIBUS Mapping Address (Alternate Entry)
Test if Partition Memory Resident for Kernel
AST
® ® e ® » @ » » . - o ° o . ° . ® ® ® ® °
Test for I/0 Buffering . . « « o« « o« o« o« o« « o

7-38

Core

1-8
1-9

7.4.7
7.4.8

7.4.33

I/O0

o
o

Buffer

o o o o o o
¢ o o o o o
. . . . .
Get Word . « o « o o o«
Initiate I/0 Buffering
Interrupt Save . « o« «

¢«

Memory
Memory

o
o
e
o
.
o

o
o
o
o
«
+

o
o
s
s
¢«
«

o
o
s
s
¢
o

s
s
s
o
¢
o

o«
e
¢«
e
.
o
.

»
s

¢«
s
«
o

o
e
¢«
o
«
«

7""'39

7-40

SAMPLE

DRIVER

CODE

8.1

SAMPLE

DRIVER

DATA BASE

¢«

8-1

8.2
8.3

SAMPLE DRIVER CODE . . . .
e
HANDLING SPECIAL USER BUFFERS

o
e

e
o

o
s

o
o

o
s

s
e

o
o

8-3
8-12

APPENDIX A

RSX-11M-PLUS

SYSTEM

DATA

STRUCTURES

AND

SYMBOLIC

DEFINITIONS

APPENDIX B

B.1l
B.2

CONVERTING A

USER~-SUPPLIED RSX~-11M

ASSUMPTIONS AND GENERAL APPROACH
MODIFYING THE DATA BASE CODE . +.

B.2.1

Unit

Control

B.2.3

The

Controller

B.2.2

B.3
B.3.1
B.3.2
B.3.3
B.3.4
B.3.5
B.3.6
B.3.7

.
e

.
o

«
«

«
»

¢«
«

«
o

o«
»

o
«

B-1
B-1

o«

B=2

¢«

o«

B=-3

MODIFYING THE DRIVER CODE
. « « 2«
Conditional Symbols
. ¢« ¢« o o «
Controller-Dependent Code
. . «
Driver Dispatch Table
. . « ¢« «
Reconfiguration Support
. « « ¢
Volume Valid Processing
. « ¢« «
Converting Logical Block Numbers
Interrupt Entry Processing . « «

«
o
«
¢«
«
«
.
«

o
o«
«
¢«
¢«
o
.
«

=
o
»
«
«
«
.
«

»
»
«
o
«
.
«

B-4
B-4
B-4
B-4
B=5
B-5
B-6
B-6

Control

Changes

.
¢«

Status

Block

DRIVER

Block
Table

INDEX

Changes
.

«
o
o
o«
¢«
¢
o«
.
«

o
o
»
«
¢
o
.
«

o
«
o«
»
«
«
o
.
«

o«
»
«
»
«
«
«
.
«

B-2

PREFACE

MANUAL OBJECTIVES

The primary goal of this manual is to introduce RSX-11M-PLUS
physical
I/0
concepts,
define
Executive
and
I/0
service routine protocol,
~describe system I/0 data structures, and prescribe I/0 service routine
coding
procedures.
This information is in sufficient detail to allow
you

to:

Prepare
software
that
supports a conventional

interfaces
I/0 device

Incorporate the user-written

with

software

the

into

Executive

and

RSX-11M-PLUS

system

Detect typical

errors that cause the

Use Executive service routines that

system to crash

I/0

service

routine

typically employs

A secondary objective is to introduce advanced hardware
and
software
features
and sophisticated Executive facilities, and to describe both
the conventional and advanced features
of
I/0
data
structures
and
mechanisms.
Knowledge
of
advanced
features
should facilitate the
understanding of conventional I/O processing and eliminate some of the

confusion

inherent

1in

seeing

data structures without knowing their

usage.

The manual does not describe how to write software
that
incorporates
advanced
driver
features.
The
only
complete
package
of
such
information
1is
DIGITAL-supplied
software,
such
as
DVINT.MAC
and
DBDRV.MAC
(for
overlapped
seek,
dual
access, and common interrupt
handling);
IOSUB.MAC
and
TTDRV.MAC
(for
full
duplex
1I/0);
and
MMDRV.MAC
(for subcontroller device operation).
The manual also does
not describe how to attach hardware to
the
PDP-11,
how
to
perform
diagnostic
functions
to
uncover
hardware
faults,
nor
how
to
incorporate DIGITAL-standard error-reporting functions in user-written
software.

INTENDED AUDIENCE

This manual is written for the senior-level system programmer

who

1is

familiar
with the hardware characteristics of both the PDP-11 and the
device that the user-written software supports.
The programmer should

also be knowledgeable about DIGITAL peripheral devices and experienced
in using the software

supplied

manual
neither
describes
general system structures.
Executive

role

with

RSX-1lM-PLUS

system.

The

general
Executive
concepts
nor
defines
The manual does describe I/O concepts, the

in processing

I/0 requests,

and some pertinent aspects

of I/0 processing done by DIGITAL-supplied software.

Therefore,

with

PREFACE

a firm understanding of hardware characteristics
software,
a
senior-level
system
programmer
appreciate

how

can

overall

affect

STRUCTURE

user-written

THIS

system

software

and real-time
system
should
be
able
to

interfacing

with

the

Executive

performance.

DOCUMENT

This document is structured to be self-contained so that you need
not
refer
to
any
other
manual
to build and incorporate a user-written
driver into your system.
The manual has three types
of
information:
conceptual,

the

procedural,

chapters
e

the

Chapter

and

reference.

The

following

are

abstracts

terms

and

document:
"RSX-11IM-PLUS

I/O

Drivers,"

concepts
fundamental
to
RS5X-11M-PLUS, and describes

the

integrity.

preserve

system

driver
features
and
becoming
acquainted

introduces

understanding

protocol

physical

that

I/O0

driver

summarizes

RSX-11M-PLUS
capabilities
with
overall
Executive

must

advanced

helpful
in
and
driver

interaction.
@

Chapter

"Device

Driver

1I/0

Structures,"”

continues

conceptual
discussion begun in Chapter 1.
It introduces
general
level
the
software
data
structures
1involved

handling

I/0 operations

arrangements

data

the

device

structures

controlling
hardware
functions;
software
configuration
that

relationships
e

Chapter

the

I/0 data

"Executive

level;

that

examines

are

the

a
in

typical

necessary

for

and presents a macroscopic
summarizes
the
logical

structures.

Services

and

Driver

Processing,"

ends

the conceptual presentation.
It summarizes how an I/0 request
originates;
how the Executive processes the request;
and how
a
driver
would
wuse
Executive
services
to
satisfy an I/0
request.

Chapter

provides
a

"Programming

the

detailed

conventional

I/0

Specifics

reference
driver.

programming

standards

programming

facilities

and

data
base itself and the
driver;
and an extensive
and

the

Chapter

driver

need

into

memory,

supports.

and

Also

Included

1is

I/0

Driver,"

necessary
a

summary

an introduction
for
both
the

executable

code

elaboration

that

the

to the
driver

constitutes

driver

code

data

tha

base

code.

supplies

assemble

Writing

protocol;
requirements

"Incorporating

RSX-11M-PLUS,"

for

information

build

make

the

User-Supplied
procedural

loadable

accessible

included

are

the

Driver

information

driver

image,

devices

summary

that

you

1load

the

into

that

driver

system

generation dialogue concerning including user-supplied drivers
and a description of the loading mechanism and the
diagnostic

operations

Chapter

performed

during

"Debugging

User-Supplied

Driver,"

software
features
provided
to
help
vyou
drivers and
gives
procedures
to
follow
successful in isolating faults in drivers.

e¢

Chapter 7, "Executive Services Available to
gives
general
coding
information relating
RSX-11M-PLUS

Executive

service

routines.

summarizes

uncover faults in
that
might
prove

An
to

I/0O
Driver,"
the PDP-11 and

PREFACE

Chapter 8,
data
base
of source
buffers.

and
<code

Driver
driver of
from
a

Code,"

shows the source code for the
a conventional device and an excerpt
driver
that
handles
special
|user

Appendix

A, "System Data Structures and
Symbol
Definitions,"
lists the source code of system macro calls that define system
device structures, driver-related structures, and
system-wide
symbolic

"Sample

offsets

Appendix

describes
RSX-11M

the

needed

"Converting

access

driver

structures.

User-Supplied

modifications

user-supplied

those

that
to

run

you must
on

RSX-11M
make

Driver,"
enable

RSX-11M-PLUS

system.

ASSOCIATED DOCUMENTS
Accompanying

the

software

your

and

RSX-11M-PLUS

hardware

system

the

are

system.

documents

that

software

describe

documents

both

are
listed and described in the
RSX-11M-PLUS
Information
Directory
and
Index.
Consult
the
directory
for
concise
summaries
of
software-related publications.
Processor
and
peripherals
handbooks
sumrarize
hardware
information
published
1in
wvarious
maintenance,
installation, and operator manuals that are provided with your system.

The

SUMMARY OF TECHNICAL CHANGES

This revision of the RSX-11M-PLUS Guide
to Writing
an
I/0
incorporates the following technical changes and
additions:
l.

Two new arguments (BUF and OPT)

macro call

in Chapter

have been added to

The I/0 Function Masks for Mass Storage,
Record

Devices have been

added

Additions have been made to

in Chapter

Magtape,
4.

Driver

the

DDTS

and

Unit

the UCB in Chapter 4 as follows:

A new symbolic name U.MUP has been added

(redefinition

U.CLI)

The DV.MXD offset to U.CWl1l has been renamed to DV.MSD
mass

for

storage.

U.UCBX

has

been

added

for

mass

storage

errorlogging

devices.

New status control block extension bit
definitions
(S2.0PT,
S2.0P1,
S2.0P2,
and
S3.0PT)
have been added to the SCB in
Chapter

New controller bit definitions
have been

added

the

KRB

(KS.MOF,
Chapter

KS.EXT

and

The Queue Optimization entry point, Deallocation entry
and

the

Next command

KS.SLO)

entry point have been

added

point

Chapter

New tracing

faults of SHEADR have been added to Chapter

Some Executive routines listed in Chapter 7 have
been
moved
to
new
Executive
modules
and
12
have
been
added.
The
following is a list of the affected modules and
subroutines,
plus the

additions:
Routine

01d Module

New Module

SACHKB
SACHCK
SASUMR
$BLKCK
$BLKC1

IOSUB
I0SUB
TOSUB
I0SUB
(new)

EXSUB
EXSUB
MEMAP
MDSUB
MDSUB

$SBLXIO
SCKBFI
$CKBFR
SCKBFW
SCKBFB

(new)

(new)
(new)
(new)
(new)
(new)

MDSUB

IOSUB
IOSUB

BFCTL
EXESB
EXESB
EXESB
EXESB

MDSUB
MEMAP

$BLKC2

$SCVLBN
SDEUMR

xiii

SUMMARY OF

Routine

SINIBF
SMPUBM
SMPUB1

SRELOC
SRELOP
SREQUE

01d

TECHNICAL CHANGES

Module

New Module

(new)

IOSUB

I0SUB

MEMAP
MEMAP

IOSUB
IOSUB

MEMAP

I0SUB

MEMAP

(new)

IOSUB
IOSUB

SREQU1

(new)

$STMAP
$STMP1
STSPAR
STSTBF

I0OSUB
I0OSUB

MEMAP

(new)

REQSB

(new)

IOSUB

Xiv

MEMAP

CHAPTER

RSX-11M-PLUS

I/0 DRIVERS

Device drivers on RSX-11M-PLUS are the primary method
of
interfacing
Executive
software
with
hardware
attached
to
the computer.
Most

DIGITAL-supplied hardwarel is supported by

drivers

accompanying

the

remaining
software
that
the
wuser
receives. with the system.
This
chapter introduces the concept of device drivers and
explains
driver

~operations and

1.1

VECTORS

features.

AND CONTROL AND STATUS REGISTERS

A device controller has a unique address on
the
PDP-11
UNIBUS
that
identifies itself and distinguishes it from other hardware attached to

the computer.
At this unique address is usually a control and
status
register (CSR) containing data elements that allow software to operate
and interrogate the related
device.
The
CSR
resides
in
physical
address space that is reserved for device registers and is referred to
as the I/0, or peripheral, page.
Other registers associated with
the
device are placed in contiguous addresses lower and/or higher than the
CSR address.
Software usually controls a device by accessing the
CSR
to
enable
interrupts,
initiate
a
function,
and
respond
to
the
resulting interrupt to continue or finish the function.
Associated with many devices can be one or more
2-word
areas
called
interrupt
vectors.
A vector provides a connection between the device

device
a
A vector allows
and the software that services the device.
to trigger certain software actions because of some external condition
the
sends
it
interrupts,
device
~
When
device.
related to the
The first word of the
the address of the interrupt vector.
processor
interrupt vector contains the address of the interrupt service routine
The processor uses the second word of the vector as
that device.
for

a new Processor Status Word.

Thus, when the

processor

services

the

word of the vector is taken as the new Program
first
the
interrupt,
Counter (PC) and the second word is the new PS.

Space is reserved on the PDP-11 for the interrupt vectors.

This space

The vectors are considered to
in the low part of Kernel I-space.
is
by the
thus mapped
be in Kernel mode virtual address space and are
1in Kernel space, the
1is
wvector
interrupt
the
Because
Executive.
Executive receives control of the processor on every interrupt.
On
a

multiprocessor

system, each central processor unit has its own vector

space.

1. The CINTS directive enables a privileged task to gain control when
The
thereby to access device registers.
interrupts and
a device
The
K-series Laboratory modules use this feature to perform I/0.
equally wviable method of
secondary but
is a
directive
CINTS
interfacing

software to hardware.,

1-1

RSX-11rM~-PT.US

1.2

SERVICE

The

service

I/0

DRIVERS

ROUTINES
routine

that

entered

process

interrupt

most

frequently
1in
the
device driver.
Device drivers vary in complexity
depending on the capabilities of the type of device and the number
of
device
units
they
service.
A driver can reside with the Executive
itself or can
the latter is

separated

from

it.

The

former

driver

resident

and

loadable.

The distinction between resident and loadable drivers is mainly one of
flexibility.
A
resident driver is built in during system generation
as a permanent part of the Executive.l It
resides
in
the
Executive
address

space

interrupts
into
the

and

cannot

removed.

outside

the

remove

virtual

address

space

loadable

driver

means

any driver

not

loaded.

The

space

normally occupied

another

tasks

space

support,

Executive

l.2.1

required

the

addition,
user

resident

driver

slightly faster than a loadable
driver.
Executive
structures,
a loadable driver

driver.

making

which

can

Executive

and

for

Driver

driver

used

Executive.
of

period

the

system

loadable

additional

responds

user

MCR

time

VMR

can

add

command.

need

unloaded

driver

Executive

virtual

can

space

or
In

not

without

frees

Although
1linked
resides in memory

hold
data

the

pool.

Layout

A device

driver is a logical extension of the Executive that need
not
be contiguous in physical memory with the Executive code.
Active Page
Registers (APRs) 0 through 4 map
the
Executive,
whereas
APR
7
is

reserved

to map the

Executive

space.

memory

and

default

restricted

controls

are

1its

I/O page.Z2 Resident drivers

Loadable
mapped

own

drivers

the

APR

reside

with

space

APR

are mapped within

separate

Therefore,

4K words

mapping

driver

loadable

mapped
gain

APR

access

the

partition
5

unless
an

extra

it
4K

words.

The virtual to physical mapping
support is shown in Figure 1-1.

Virtual addresses 0
the
same
physical
vectors,

stack,

control

block

code.

I-space

virtual

APR

map

remaining

the

16K words.
through

data

D-space

APR

structures

with

processor-specific

(ICB)

pool

addresses

Executive

virtual
the

maximum

dynamic

space

through
code,

addresses

map

a system

through 4K words (APR 0) of
memory.
The
mapped area

processor

interrupt

memory

well

20K

which

through

storage

region

the

(APR1

(or

and

20K

words

pool)

information
and

APR

term

(Page

(PDR).)

Refer

Task

assignments

referring

Address

on hardware mapping

RSX-11M/RSX-11M-PLUS

mapping

pair

Builder

the

and

the

relevant

system

for

processor
a

must

KT1ll

(PAR)

memory management.

Manual

software.

1-2

(APR

words.

through

limited

Active

Page

and

Executive

therefore

all drivers

Descriptor

for

some

On systems with Executive data space support,

Management

space

locations,

words
is

loadable.

data

I and D space
overmap
contains the interrupt

16K

Kernel

and

Memory
Page

handbook

Refer

description
V

to
of

RSX-11M-PLUS

I/0 DRIVERS

Physical Memory
Address Space

1/0 Page

Virtual

Kernel

32K Words

D-Space /

APR 7

b oo o e

28K Words

APR 5

—

b e e e

20K Words

IR
- — —

Privileged Task

Driver

)
/7

Processor n

\ I-Space

- - - -

—

Dynamic Storage

Region

APR 0

APR 5

\\{

28K Words

—

e — —

20K Words

I
e

Specific !

APR 1

32K Words

APR 7

—

4K Words b em em
OK Words

APR 1

. — — — | akwords

APR 0

OK Words

Processor 0
Specific

1t:)n multiple processor systems, each additional processor requires its own processor-specific area in the CPU partition.
LK -245-81

Figure 1-1

Virtual to Physical Mapping for the Executive

D
and
Virtual addresses 20K through 28K words (APR 5 and APR 6) of I
map
to
reserved
is
which
memory,
physical
same
space overmap the
(Although APR5S
loadable drivers and privileged tasks in Kernel mode.
APR6 are reserved for drivers, the Executive maps only APR5 when
and
32K words
it calls a driver.) Finally, virtual addresses 28K through
(APR 7)

of I and D space overmap the I/0 page.

1I/0
the
Thus, a device driver is mapped with the Executive code and
registers
device
the
access
can
it
control,
has
driver
a
When
page.
all
It also has available
in the I/0 page to perform its operations.
the Executive service routines to help it process I/0 requests.

Because of the layout of the Executive and device drivers, many common

functions

to I/0 are centralized in the Executive as service

routines. This commonality eliminates the inclusion of repetitive
Coding in each driver is therefore
in each and every driver.
coding
reduced to handling the specific functions of the device supported.

RSX-11M-PLUS

there

are

distinct

wunits

capable

I/O

DRIVERS

being active simultaneously.

(Moreover, some drivers supporting advanced features can have multiple
I/0
requests
simultaneously
active for a given unit.
1In this case,
each active I/0 request is part of a separate driver
process.
Refer
to

Section

1.4.7 for more

information.)

Central to a full understanding of a driver and the I/0O
structure
1is
The
process and the driver code.
driver
a
between
difference
the

routine
driver code, which is pure instructions, invokes an Executive
This activity
process.
to
I/O packet
an
get
to
SGTPKT
called
generates data for the request being processed and the unit doing
the
processing.
The driver process, once initiated, starts the proper I/0
function, waits for a completion
requests
another
I/0 packet.
continues until the I/0 queue
1is

interrupt,
posts
1I/0O
status,
and
This
sequence
of
execution
steps
empty.
The
driver
process
then

terminates.

Because a driver may be capable of servicing several I/O
requests
in
parallel,
it
1is
©possible
that,
for
a
single driver, many driver
processes exist at the same time.
However, there is only one copy
of
driver
code.
The driver process is reentrant code and the data that
defines the state of the code is stored in the driver data
base
when
the
process
1is not executing (for example, when it is waiting for an
interrupt).
The driver process executes driver code for a
particular
device
type
on behalf of a specific unit.
If independent units of a
particular
device
type
are
concurrently
active,
several
driver

processes

are

also active at the same time,

each with its own set of

data.

1.3.2

Interrupt Dispatching

and

the

Interrupt Control

Block

Once a driver starts an I/0 function, it must await the I/0 completion
interrupt.
When
a device interrupt occurs, the processor pushes the
current PS and PC onto the current stack and loads the new PS
and
PC
from the device controller interrupt vector.
By convention, the PS in
the interrupt vector is preset with a priority of 7 and the number
of

the
in

controller associated with the vector.

the

low-order

four

(The controller number

bits.)

Because

an interrupt must be serviced in Kernel address space, how the
interrupt
is
handled
depends
on
whether the driver is resident or
loadable.
A resident driver,
being
mapped
with
the
Executive
1in
Kernel
address
space,
handles
the interrupt directly (that is, the
entry point address of the driver is the
PC
word
of
the
interrupt
vector) .
For
a
resident
driver,
then,
the
hardware
dispatches
directly to the interrupt service routine in the driver.
Figure
1-2
shows this mechanism.

RESIDENT

CONTROLLER

DRIVER

NUMBER

INTERRUPT
VECTOR
ZK-246-81

Figure

1-2

1Interrupt Dispatching

for

Resident

Driver

RSX-11M-PLUS I/0 DRIVERS

Load APR 5 to map the driver

Transfer control to the driver

Restore the mapping after return from the driver

Restore R4 and RS

Thus, the interrupt vector for a controller serviced by a 1loadable
driver points to an ICB rather than to the driver. Accordingly, the
loadable driver does not (and must not) call the SINTSV routine as the
resident driver does because the $INTSI routine saves the context on
behalf of the loadable driver. When it gains control, the loadable
driver 1is also partially interruptable as if it had called the S$SINTSV
routine. After it gains control, the loadable driver is exactly 1like
the

resident

driver.

(That

established on the system.)

1is, it must also observe the protocols

CONTROLLER
NUMBER

INTERRUPT
CONTROL

3h§fiK

LOADABLE

INTERRUPT

DRIVER

VECTOR

ZK-247-81

Figure 1-3

Interrupt Dispatching for a Loadable Driver

The ICB allows up to 128 controllers of the same

type

system.

The low-order four bits in the PS of the interrupt vector restricts
the number of controllers to 16. In the ICB, the system maintains a
er number
controller group number and the PS bits describe the controll
Executive
the
number,
er
controll
real
the
within the group. To obtain
the ICB
in
number
group
er
controll
the
adds
routine
service
interrupt
and the controller number in the PS. (Note that, because a resident
driver does not use the ICB mechanism, there can be at most 16
controllers of one type if the driver is resident. Furthermore, only
the LOAD command in VMR supports more than 16 controllers of one
type.)

The simplest case in handling an interrupt is that in which a
controller can have only one unit active at any one time. Multiple
controllers may be active concurrently, vyet only one unit per
controller may be active. When an interrupt occurs, the driver can
determine the number of the saved controller from information encoded
routine
in the low-order four bits of the PS. The interrupt service and
to
CTB
the
in
table
a
index
to
in the driver uses the number
access the proper unit data and context.

a
The more complex case in dispatching an interrupt is that in which
controller can have multiple units operating in parallel. This is an

advanced driver feature called overlapped seek I/0 and is described in
Section

1l.4.1.

RSX-11M-PLUS

the

other

the

port.

This

load

between

switching
the

two

I/0O

DRIVERS

between

ports

allows

the

system

controllers.

NOTE

dual-access

attached

does not
through

The system
determine
other, the
controller.

device

the

support
a

has

same

both'

system.

systems

ports

DIGITAL

loosely coupled

peripheral.

also
maintains
an
1I/0
count
for
each
controller
to
how
busy
it
is.
If one controller is not as busy as the
system can queue the
access
requests
to
the
less
busy
Whenever

Executive

makes

access

the

1.4.5

Common

any

load

sharing

reassignment

done

necessary

dual-access

before

actually

the

controller.

Interrupt

Dispatching

handle interrupts from a controller that
supports
more
type of device, the Executive uses a mechanism called common
dispatching.
The RH70 MASSBUS controller can have different

devices

unit,

requesting

(RP04,

RPO05,

moving
head
disks;
non-rotating memory;
and
TU77
magnetic

and

RP06

moving

head

disks;

RM80
and
RP0O7
fixed
RS03 and RS04 fixed head
tape
drives)
connected

RM02,

media
disks;
to
the

controller.

than

one

interrupt
types
of

RM03,

RMOS5,

disks;
ML11
and TEl6, TU45,
same
type
of

Interrupt dispatching for such devices is more difficult
than for standard interrupt devices because associated with one set of
interrupt
vectors
are
multiple
drivers.
To
dispatch interrupts,

therefore, a routine in the
Executive
must
intervene.
shows an example of common interrupt dispatching.

Figure

1-4

Driver

)

Common

Interrupt

Dispatch

Driver

Routine

(SRHALT)
>

Driver

RH70 Interrupt

Vectors
ZK-248-81

Figure

1-4

The
vectors
dispatching

routine

Interrupt

for
such
routine
1in

avoids

having

Dispatching

for

Common

controllers
point
to
the
Executive
module

duplicate

code

essence
acting like an RH70 controller
determines which
driver
will
receive

Interrupt

Devices

interrupt
This common

common
DVINT.

drivers.

driver

This

routine,

sophisticated

in
ICB,

control
wupon
an
interrupt.
Operating like the routine that handles interrupts for overlapped seek
devices, this routine determines the type of device
that
interrupted
and dispatches to the proper driver.

1-12

RSX-11M-PLUS

I/O

DRIVERS

Using a loadable driver with a loadable data base saves
work
in
the
long
term.
During debugging, data base inconsistencies are likely to
be caught by LOAD.
Thus, you prevent
many
such
errors
from
later
creating
A

system

resident

problems.

driver

loadable

driver

with

resident

data

base

1is

more
difficult
to
debug
and
to
modify.
LOAD
does
not perform
consistency and validity checks on a
resident
data
base.
Thus,
a
valuable
debugging
aid
1is
not available.
Moreover, to modify such
drivers, you must
rebuild
the
rebuilding the privileged tasks.

1.7

SPR

capability

is a

supported

which

generally

implies

SUPPORT

The

considered

system

Executive,

that

incorporate

user-written driver

feature of RSX-11M-PLUS.
a

system

results

modification,
after

you

Because a
DIGITAL

incorporate

your

may

into

your

system

user-written driver
not

driver.

of the Executive, your
driver
can
subtly
corrupt
it.
DIGITAL
cannot guarantee support which entails debugging
drivers.

support
Being

the
part

Therefore,
user-written

Fixing a problem in a system is largely a
matter
of
being
able
to
reproduce
the
problem
reliably.
If a problem on your system can be
shown to have no relation to your driver and DIGITAL can reproduce the

problem,
SPR
support
can
be
provided.
A good reason for using a
loadable driver with a loadabkle data base is that you can more
easily
~attain
an
unmodified
system by not loading your driver and its data
base.
You can then reproduce a suspected
problem
in
an
unmodified
system and
attempting

driver
the

SPR.

and

can

submit an
recreate a

SPR that DIGITAL can
suspected problem on

its data base saves both you and

answer.
Therefore,
your system without

DIGITAL time

your

answering

CHAPTER

DEVICE DRIVER I/O0 STRUCTURES

This chapter deals mainly with structures at the
block
relationship
to
the
hardware
configuration
and
supported,
and
their
relationships
to
each
other.

description of each structure

2.1

is given

in Chapter 4.

1level,
their
functionality
The
precise

I/0 STRUCTURES

The main elements in the driver I/0 environment essentially define
logical
and
physical
characteristics
of the supported hardware
establish the links and connections by which routines can
access
manipulate
driver
data.
The
following
subsections
describe

control blocks that a driver data base module defines, and explain

general

2.1.1

terms the purposes for each block.

Controller

A controller

CTB

must

Table

for

1in

(CTB)

table defines a

exist

the
and
and
the

each

unique controller

type on

physical controller type.

the

systenm.

All controller

tables are linked together, in a list,
with
the
head
of
the
1list
SCTLST
in
the
Executive
common
area.
The list of the controller

tables is one of the threads through the system data base
to
provide
access
to
all
device-related data.
The link in the last CTB in the
list

has

value

zero.

Associated with each CTB is a 2-character ASCII controller name
which
must
be
wunique
throughout
the system.
This unique name allows the
Executive to find the
correct
CTB
for
the
controller
type.
For
example, the RH11/70 controller has the name RH instead of DB, DS, DR,
or

MM,

A CTB is a static structure created
during
system
generation.
user-written
driver data base, therefore, must have its own CTB.
user-created controller table must also be linked into the system

Any
The
CTB

list.

A CTB has generic

structures

status

the

the means by which the
type and dispatches to

2.1.2

information,

system.

links,

and

pointers

other

The table of KRB addresses in the CTB is

Executive handles interrupts for
the correct driver routine.

Controller Request Block

the controller

(KRB)

The controller request block is
the
means
by
which
the
Executive
maintains
controlleror
hardware-specific information and accesses

DEVICE

DRIVER

I/0O

STRUCTURES

A cell in each device control block forms a link in
a
forward-linked
list,
with
the
head
of the list starting in a cell (SDEVHD) in the
Executive common area.
This list, as with the CTB
1list,
1is
a
main
thread through the system data structures to device-related data.
The
link in the last DCB in the list has a value of zero.
The

static data

in the

DCB

gives

such

information

device
name,
unit
quantity
and
1links to individual
address of the driver dispatch
table,
and
types
of
supported
processing

2.1.4

the

generic

unit data, the
1I/0
functions

by
the
driver.
Typically,
the
Executive QIO directive
code and not the driver code accesses the DCB.

Unit

Control

Block

(UCB)

The unit control block holds much of the static information
about
an
individual
device
wunit and
contains
a
few
dynamic
parameters.
Although unit control blocks need not be
any
prescribed
1length
for
different
devices,
all
wunit control blocks for the same device type
must be of equal length.
(The UCB length
1is
stored
in
the
device
control
block.)
This
condition
allows
the
UCB to contain varying

amounts of unit- and device-independent data for

different

devices.
A

UCB, one of which exists for each device
access
most
of
the
other structures in

types

unit,

the

enables a
driver
to
I/0 environment.
A UCB

provides access to most
of
the
dynamic
data
associated
with
I/O
operations.
Given
the
address
of a UCB, a driver may readily find
most of the other data structures in which it
1is
interested
because
the
proper
1links exist.
Because of this access information, the UCB
is a key control block in the driver I/0 structure.
The static data in the UCB includes pointers to other I/0
structures,
definitions
of unit control bits which regulate directive processing,
definitions of unit status bits which describe operational conditions,
and
definitions
of
wunitand
device-dependent characteristics and
storage

cells.

Data

the

UCB

accessed

and

modified

both

the

Executive

and

the

driver.

2.1.5

Status

Control

The status control
device
unit.
In

Block

(SCB)

block holds driver
the SCB are stored

context
for
such data as

operations
the pointer

on
a
to the

head of the queue of input/output requests;
the
1link
to
the
fork
blocks
queued for the unit;
the fork process context;
timeout, unit
status, and error
1logging
information;
and
the
address
for
the
controller
request block (KRB) representing the device controller (if
the

device

The

Executive

context
status.
access

has

controller).

accesses

the

SCB

set

while
a
request
1is
1in
progress,
When the driver accesses the SCB,
it

I/0

and
1is

request,

store

to post results and
usually
for
read

only.

The number of status control blocks depends on the processing
support
in
the
Executive.
If
the controller itself cannot handle parallel
operations, only one SCB is needed for each
«controller.
In
such
a
case,
a controller can have only one unit’ processing a command at one
time, and there is no need to store context for more than one unit
at

DEVICE

time.

There

request

block

need

the

driver

data

control

block.

the

controller
this

which

the

are

must

the

hardware

from

required

operations
one

SCB

controller

unit

context.

KRB cells

and

store

the

Executive

context

for

each

1In such
a
controller

(DDT)

contains

the

entry

addresses
for
the
driver.
the Executive calls the driver
interrupt
entry
address
1is
a

processor

servicing

contains

separate

data

connected.

interrupt
entry
location at which

for

physically
generic

parallel

The driver dispatch tablel

function.

independently on the controller.
each SCB points to the KRB of the

DRIVER DISPATCH ‘TABLE

central

for

base

there

operating
a cell in

units

1/0 STRUCTURES

separate

allows

feature,

unit capable of
configuration,

2.2

no
to

supports

also

(KRB)

Therefore,
status

DRIVER

Executive

interrupts.

transfers

points
An
to

and

the

entry point is the
perform a specific

location
to which

control

within

The

pointer

the

entry

points

follows:

the

driver

interrupt

entry

address resides either in an interrupt control block if the driver
is
loadable
or
in the device interrupt vector in the system common area
of the Executive if the driver is resident.
Every driver

Two

For

four

conventional

I/O initiation

cancel

I/0

device

timeout

device

powerfail

entry points

off-line

has

status

are

added

for

controller

KRB

status

change

UCB

status

change

many devices, these status change
Executive calling routine.

the

There

are

driver

two

additional

entry

features:

Deallocate

©¢

Address

buffers

checking

and

points

and

entry points

that

command

conversion

drivers)

The

DDT

it
is
because
the

data

and

unit

on-line

changes:

not

structure

the

strict

have

are

been

(FDX

added

description.

return

advance

optimization

the

defined
in the instruction part of the driver
it contains addresses for dispatching code, it
structure

for

TTDRV)

(queue

sense

merely

and

word

disk

because

code.
However,
is included
in

DEVICE DRIVER I/0 STRUCTURES

I/0 Initiation

2.2.1

The Executive transfers control to this entry point to inform the
for the
driver that work for it is waiting to be done. To make work
processing.

predriver—-initiation
driver, the Executive performs
in Chapter 3). If, at the end of
ed
describ
1is
ion
1initiat
er
(Predriv
I/0 packets queued for the
has
predriver processing, the Executive
driver, it calls the driver at this entry point.

ion entry point, R5
When the driver gets control at its I/O initiat
the request is
contains the address of the UCB for the unitI/0on which
the driver
packet,
the
to
access
sh
establi
To
ed.
process
to be
tion in
informa
an Executive routine that either returns
calls
the
and
ed
process
be
to
packet
the
both
registers concerning

associated

data

order

to gain access to the data structuresl or

causes the driver to dismiss itself.

(There

may

packet

and

there

1is

request

process or the driver may already be busy.)

control is returned to

driver

Once
rs,
process, the driver must extract the information from the registe
request.
the
process
and
blocks,
control
the
establish data within
it sets
This means that the driver proceeds with an I/O request until
1I/0
the
es
initiat
lly
physica
which
the GO bit on the device,
operation.

there 1is a
Typically a driver is called at this entry point when
before a
called
be
can
driver
a
packet in the I/0O queue. However,
of the
tion
descrip
the
to
Refer
queue.
I/0
packet is placed in the
U.CTL control flag UC.QUE in Section 4.4.4 for information on queueing
an I/0 packet to the driver.

2.2.2

Cancel

I/0

To terminate an in-progress I/0 operation, the system flushes the 1I1/0
situations
queue and calls the driver at this entry. There are many
in which a task must terminate I/O. When such a termination ve becomes
relays
necessary, a task issues an Executive request and the Executi
point.
entry
this
at
it
calling
by
driver
the
to
the request
The driver 1is responsible for checking that the I1/0 operation

termination,
in-progress was issued from the task that is forcing the returni
ng to
before
on
operati
the
and for completing or terminating
the

caller.

an I/0
Typically, a driver is called at this entry point only when
unit
the
if
even
called
be
can
driver
A
operation 1is 1in progress.
control
U.CTL
the
of
tion
descrip
the
to
Refer
busy.
specified is not
UC.KIL in Section 4.4.4 for information on unconditional
flag
cancelling of I/0O.

2.2.3

Device Timeout

timeout
When a driver initiates an I/0 operation, it can establishthe a specif
ied
within
te
comple
to
fails
ion
operat
the
If
count.
this
at
driver
the
calls
and
lapse
interval, the Executive notes the

1. The SGTPKT routine, which gets a packet for the driver to
is described in Chapter 7.

process,

DEVICE

entry

point.

Using

this

but
need
not hang up
should ever stall on a
expected

2.2.4
The

interrupt

from

facility,

Failure

Executive

calls

the

when

STRUCTURES

driver

can

wait

for

interrupt

happening.

Power

after

I/0

if the interrupt never occurs.
Thus, no driver
request because a hardware failure prevented an

Device

restored

DRIVER

power

failure

any

time

entry

the

point

controller

when
is

busy

power

(that

is,

I/0 is in progress).
Typically, a driver
responds
to
a
power
failure
in
the same manner it responds to a timeout.
1In such cases,
the power failure entry point may simply be
a
return
to
the
caller
because
recovery will occur by means of the timeout
entry point.
The
driver is called for both controller and unit
power failure unless the
driver
1is
associated with a common interrupt controller.
For common
interrupt controllers, the driver is called at
this entry
point
only
for unit power failure and is called at a special
entry defined in the

common

interrupt

table

for

controller

power

failure.

A driver can be called
when
power
1is
restored
regardless
of
the
existence
of
an outstanding I/0 operation.
Refer to the description
of the U.CTL control flag UC.PWF in Section
4.4.4 for
information
on
unconditional

2.2.5
Two

call

Controller

entry

points

power

and

Unit

failure.

Status

are

required

units.

The

controller

and

controller

on-line

Change

for configuration status changes
Executive enters one entry point to
take
it
off-line.
The
other
entry

and

the

put

the

point,

called
once
for each unit whose status changes, is for putting
units
on-line and taking them off-line.
The
driver
must
show
successful
completion
of
the
on-line or off-line request or the Executi
ve will
not effect the status change.
The driver has 60
seconds
to
perform
whatever
synchronization
it
requires
before
returning
to
the
Executive,
In
most
cases,
however,
the
driver
will
return

immediately.

2.2.6

Device

Control

passes

initiated
interrupt
it
more
such

Interrupt
to

interrupt

terminal

will

have

entry

differs

from

device

and

driver

the

interrupt

arrangement

the

include
number

implied

address

when

device,

previously

by
the
driver,
completes
an I/O operation and causes an
in the central processor.
A device may have associated with
than one interrupt entry.
For example, a full duplex device

entry

The

Addresses

addresses
is

terminal

1in
of

the

vectors

the

each

number

2.3

TYPICAL CONTROL

This
that

section presents
are
found
in

block

the

that

addresses

defines

has,

addresses.

the

block

and

is
in

the

address

DDT.

The

drivers

such

addresses

restriction

number

interrupt

the

involved.

the
or

interrupt
between

not

multicontroller

There

the

The

connections

Executive

support

driver.

controller

arranged

The

for

interrupt

direct--the

enough

driver.

vector

more
are

general

two

point

address

the

wvectors

1is

block.

RELATIONSHIPS

different arrangements of the control structures
RSX-11M-PLUS.
The
section concentrates on the

2-6

DEVICE

DRIVER

I/0

STRUCTURES

relationships among device control, unit control, status control,
controller
request blocks and controller tables based on hardware
functions supported.
Descriptions of the
detailed
contents
of

and
and
the

structures
is
1left
to
Chapter 4, where the coding requirements are
presented.
Some of the arrangements
are
not
conventional
but
are
shown to convey the flexibility you can find in a system.
Section 2.4
shows how such arrangements fit
into
the
overall
system
I/0
data
structure.

The arrangements described in this section illustrate the strategy
1in
offering
a
flexible
I/0
data
structure.
There
need be only one
controller table for each controller
type.
Multiple-device
control
blocks
for
a
single
device
type
reflect the capability to handle
varying characteristics.
The existence of one or more status
control
blocks
depends
on
the
degree of parallelism possible:
one SCB for
each controller servicing several units (no parallelism);
or one
for
each device unit combination on the same controller (unit operation in
parallel).

The I/0 data structure reflects the hardware
configuration
that
the
data
structures
describe.
The
flexibility
1in
the data structure
arrangements provide flexibility
1in
configuring
I/O
devices.
The
information
density
1in
the structures themselves reduces the coding
requirements for the associated drivers.

2.3.1
A

Multiple

typical

arrangement

Fiqure

with two
defines

Units per

2-1.

RKO5
the

The

block

type

running

device

structures

arrangement

drives
attached.
existence
of
the

device control
of

Controller,

(DCB)
on

for

could

Unit Operation

user-written

represent

A
single
<controller

establishes
the

Serial

the

driver

RKO05J

controller
type on the

shown

controller

table
(CTB)
system.
One

characteristics

for

the

controller.

The status control block (SCB) and controller request block (KRB)
are
contiguous
1in
this
arrangement
because the software does not allow
another I/0 operation to
begin
while
the
controller
1is
Dbusy.
A
separate

unit

control

block

(UCB)

describes

each

controller.
The UCBs are associated with the SCB,
context of the operation currently in progress.

'2.3.2

Single Controller,

Another

typical

Serial

conventional

user-written
driver is shown in
LP11 controllers, one
with
an
attached.
It
represents
the

unit

attached

which contains

the

Operation
arrangement

structures

for

Figure 2-2, which could represent
two
LP04
and
the
other
with
an
LP05
simplest
case
of driver processing.

Figure 2-2 shows what is required for a controller that allows only
a
single
1I/0
operation for each controller.
A single controller table
defines the existence of the
<controller
type
on
the
system.
One
device
control
block establishes the characteristics for the type of
device running on the controller.
The status control and controller request
blocks
are
<contiguous
1in
this
arrangement
because,
while the controller is busy, another I/0O
operation cannot begin.
Only
one
©SCB
1is
necessary
to
store
the
context
of
the
unit operation.
The UCB points to the SCB, which in
turn points to the KRB of the unit's controller.
Because
the
system
must handle interrupts from multiple controllers, the controller table
points to the KRB of each controller present.

DEVICE

DRIVER

I/0

STRUCTURES

DQB

CTB

List

i
CTB
b

]

DCB

KRB

ucs

SCB
e

ZK-249-81

Figure

2.3.3
Some

2-1

Parallel

Multiple

Unit

Units

per

Controller,

Serial

Unit

Operation

devices, such as the
1in
progress

operations

RK06, allow
multiple
units
to
have
at
the
same time.
In particular, the

seek
RK06

allows such operations to overlap a data operation.
Figure 2-3
shows
the
arrangement needed in the software structures to support parallel
operations on one controller,
Two
additional
structural
changes
are
required
from
operation
arrangement.
First, because more than one unit

operation pending at the same time,
unit
context.
Therefore, for each
there
can

is
come

proper
table
the

separate
from

status

than

control
one

a structure
1is
needed
to
unit (and each unit control
block.

unit,

some

Second,
way must

because
exist

unit.
As a result, the controller
request
of
wunit control block addresses that allows

structures

for

the

the
serial
may have an

unit generating

interrupt.

store
block)
interrupts

to access the
block
contains
a
the driver to find

DEVICE DRIVER

DCB

List

I/O STRUCTURES

DCB

‘

KRB
SCB o

UCB

UCB
.

KRB

SCB o

ZK-250-81

Figure

2-2

Single

Controller,

Serial

Operation

DCB

PSS

—

KRB

UCB
Table
ZK-251-81

Figure

2.3.4

2-3

Parallel

Multiple-Access

Unit

Operation

(Dual-Access)

(Overlapped

Seek)

Operation

Some devices, such as the RK06, have a dual port option that
provides
multiple-access
paths
to units.
On the RK06, dual ports on the unit
two
between
switched
-electronically
be
to
unit
single
enable a
2-4 shows the several changes in the structures
Figure
controllers.
needed to support dual-access operations.
2-9

DEVICE DRIVER

I/0 STRUCTURES

Common
Interrupt

Table

Current

n )

Port A

Table o

KRB

UCB
Table

SCB
<RB

-2

Port B

C‘Q,‘fgt
Pointer

cTB

Premem—

UCB
¢

Pointer

UCB

KRB

_*fiu_____q:=
°

PortA

Table o

Port B

KRB

ucB
Table
ZK-252-81

Figure

Separate

status

one

controller

and

allow

the

structure

1is

request

block

Executive

can

capability

enable

the

control
is

operation
that
all

the

blocks

for

The

the

for

points

overlapped

unit

differentiate

wunit

|if
idle

the

dual-access

same

controller

arrangement.

KRB

between

can

the

seek

which

because,

controller

difference

pointer

switch

each

alternate

longer

©SCB

electronically
to

Operation

needed
the

proceed.

the

software

are

busy,

©SCB

time

<change

Dual-Access

blocks

currently

unit,
the
SCB
has a
the table contains two
request

2-4

two

reflect

The

the

controllers.

controllers

may

access

table of KRB addresses.
For dual-access disks,
entries:
the
addresses
of
the
controller
each

controller

between

which

the

unit

can

switched.

2.4

OVERVIEW OF DATA STRUCTURE RELATIONSHIPS

This section presents an
overview
of
the
relationships
among
the
user-written
driver
data
structures
previously
introduced in this
chapter and the Executive I/0 structures and
DIGITAL-supplied
driver
structures.

The

goal

the

section

in which user-written structures and code
scheme
and to describe generally the use

structures.

The

somewhat

that

parts

the

structural

specific

system

the

relationships.

than

placed

convey

the

general

manner

link
1into
the
system
to which the system puts

user-written

emphasis

rather

the

structures
on

the

are

simplified

linkages

details

I/0
the

with

other
wuser-written

DEVICE DRIVER

I/O STRUCTURES

This section should be used with Section 2.3 to understand the general

structural
concepts.
For
example,
Section
2.3
describes various
arrangements of unit control, status control, and
controller
request
blocks
based
on
hardware functions the software structures support.
This section treats such arrangements as an engineering black box that
is
oriented in the general I/0 environment.
Thus, in the generalized
I1/0 data structure depicted in this section, the pointers in
the
KRB
table
of
the
SCB
are
not shown and the table is simply marked KRB

Table.

Figure 2-5, which provides the basis for the presentation of
the
1I/0
data
structure,
shows the individual elements and the important link
fields within them.
The numbers
in
the
£figure
correspond
to
the
numbers
in the lead paragraphs of the text to simplify the discussion
and

guide

you

The

through

location

the

data

structures.

represented by the

Executive symbol

S$DEVHD is

cell
1in system common (SYSCM).
It is the head (or start) of
a singly-linked, unidirectional list of
all
device
control
blocks
in
the system.
The first word in each DCB is a link
to

the

The list
through

DCB.

of device control blocks is one
the
system
data
tables

information.

For

example,

the

list

of the
two
threads
for
device-related
the

means

which

executive routines scan the data structures to determine what
devices are on the system and what is the
status
of
units.
User-written
device
control
blocks must be linked into the
list

system defined

DCBs.

Every loadable driver is associated with a partition
control
block
(PCB).
The
PCB
defines
the characteristics of the
memory area into which the driver is loaded.
The
Executive
and
tasks such as LOA and UNL reference the data in the PCB.
A driver is not concerned with the PCB.
If

task

control

attached
block

(TCB)

unit,

that

the

UCB has a

pointer

the

task.

The task header is an independent
entity
in
the
I/0
data
structure
and
the
driver never accesses it.
A copy of the
task header is taken from the task partition
and
stored
in
the
Executive
dynamic
storage
region whenever the task is
actually in memory.
This copy is then used by the Executive.
A

logical

unit

items
of
block and,

table

interest:
if a file

(LUT)

entry

the

task

header

has

two

a pointer to an associated unit control
is being accessed, a pointer to a window

block.
The
Executive
accesses the logical unit table of a
task during a QIO
request
and
1indexes
the
table
by
the
logical unit number specified in the QIO request.

A device
block of

control block has
the first related

a
pointer
to
unit.
Because

the
wunit
the length

control
of a UCB

is stored in
the
DCB
and
all
UCBs
are
allocated
in
a
continuous
area,
access to all the UCBs related to that DCB
is possible.
This arrangement allows software to access
all
related unit information for a device type.

A DCB

table.

also

has

pointer

the

This pointer allows the

at
its
entry
points
to
reconfiguration request.

start of the

driver

Executive to call

©process

dispatch

the driver

I/O-related

)”(- m.usung
—_—

LE-ES2-MZ

DRIVER
I/0

2-12

N L) ISV

8
0
5
—
—
3s1i$y9|0pwe1i0bueimpoysmoAysan1Aaj0auNjoqies[seod1TdAu}aw‘abjudew.esxea ° 894.

|a|qe

1dnuialuyg

3@0Q31378Aa49IM3030HH8I01Sv1OA0AVVa3H4I4LvLAH0O0IoQSLL[) nYJr3-AT|-o-i~@—g—L2bog:9-~--n10—H3LIXL3INNJvIOgda82H0aXL}HS_—4$J|i~||@OTB.=Og0/u/1dSR3L3eN-3—S7~3I-9IM@vNI—1VDdIH3AIHLQeaALg30bfi0@v|:|8ongu13o0y7Ow/e8.lvdoLn-e1M5N4I1TB4O8.QL0e1QJ=3IL|N8—N-1T0OOAW@-15g7A1)‘x19m0w—8mw.:
@ HM1ASmV31H-4—1LNA—HINI.2in9big,(MgaS-VnLz)93tsodwo)0L/Iejeq$29aNn3dn1a13s -(1I0WAMN)TaOA)
DEVICE
STRUCTURES

DEVICE

DRIVER

I/0

STRUCTURES

Each unit control
block contains
a
pointer
back
to
1its
related DCB.
This backpointer allows the Executive interrupt
dispatch code to enter the proper driver (through the pointer
to the driver dispatch table).
Associated

with

each

UCB

status

control

block.

The

SCB

is
shared
by
all
wunits
for
a
device type that does not
require units to operate in parallel.
When units can operate
in parallel, each UCB has its own associated SCB.

As part of processing
the

Executive

builds

a QIO directive
a

Storage for packets is in the system
(the
pool).
The Executive connects
in

each

packet

queue.

the
the

The

form

Executive

(queued

structure

I/0

called

request),

1I/0 packet.

dynamic
storage
the packets by a

singly-linked

list

maintains

pointers

two

list of packets.
The first pointer is
1list and the second pointer is to the

called

region
pointer
the

the

1I/0

SCB

to
the
start
last packet in

to
of
the

list.
The

driver

should

not

access

the

1list

1I/0

packets

directly.
When the Executive transfers control to the driver
to
initiate
©processing
of an
1I/0
request,
the
driver
immediately
calls
an
Executive
service
routine
to get a
packet

process.

sufficient

the

The

routine

process

packet).

Thus,

the

passes,

request

(for

Executive,

the

driver,

example,

and

not

the

data

address

driver,

removes
a
packet
from
the
queue of packets.
However, in
performing the I/0 request, the
driver
can
access
certain
fields in the packet to be processed because a pointer to the

currently active
The

Executive

queue.,
head of
8.

least

I/0 packet

determines

Typically,
the queue.
one

the

kept

status

control

the

requests

block

(SCB)

packets
are

placed

exists

for

the
the

each

a
controller
and
software
support
on multiple units, one SCB exists
for
operating independently.
A pointer in

the SCB connects to the controller request
controller
to
which
the
related
wunit
.

SCB.1l

ordering of

higher-priority

controller.
Where
operations in parallel
each
unit
capable of

block (KRB) of
1is
connected.

the
If

multiple—-access paths
between
a
wunit
and
controller
possible,
the
KRB pointer is dynamic.
The KRB to which
SCB points at one instant therefore, is considered to be
currently
assigned
KRB.
To
reflect
the
existence
alternate
controllers,
a
table
of
pointers
to
all
possible
KRBs
1is
<contained
in
the SCB, separate from

are
the
the
of
the
the

pointer
The

the

fork

block

context.

The

currently
in

processing will
status,

the

driver

occur

routine

assigned

SCB

KRB.

contains

executes

at fork
stores

some

level.

some

the

Executive

driver

preserve

context

the

When the driver eventually runs
again,
the
fork
recovers the proper context from the fork block.

l. Normally,
An exception
is queued or

process

routine

so that
processing

fork

block.

processor

the driver does not directly manipulate
the
1I/0
queue.
is when a driver needs to examine an I/0 packet before it
instead of having it queued.
This exception
involves
a
status
bit
in
a
control
byte of the unit control block.
For more
information on queuing of I/0 packets to
the
driver,
refer
to
the
description of the UC.QUE bit in Section 4.4.4.

2-13

DEVICE

DRIVER

I/0O

STRUCTURES

On multiprocessor systems, the fork block contains
an
extra
cell to define the processor on which the driver must execute
the
I/0
request,
The
Executive
routine
that
preserves

context

processed

the

fork

block

ensures

particular

that

The fork blocks for pending driver
a
singly-linked
1list,
the
head

(SFRKHD)

Processing

the

Executive

routines

certain

driver

1link

processes
of which

region.

block

the

10.

For

each

for

pointer

called

block

concerned

11.

The

driver

and,

the

dispatch

through

the

file

the

(The

the

file
FCB to

block

exists

hold

resides.

up the

pointers

The

process

block

number

device.)

The

retrieving

need
in

(DDT)
and

the

part

not
file

driver

the

interrupt

function

ACP

the

be
to

driver

control

not

block.

table
vector

window

associated

wvirtual

open

file

speed

window

code

block,

the

The controller request blocks (KRB) are linked into
the
data
structure
through the pointers in the controller

I/0
table

the means by which
driver.
12,

number

with

file.

convert

volume,

the

which

from the

mounted

has

window block

items

logical

volume

file,.

file on
task
that

the

data

the

open

each

areas

fork

FIFO order.

Associated with each open file on a mounted volume
control
block
(FCB).
The file system alone uses
access

are connected in
is in a location

Generally,

fork

location $FRKHD+2 the executive maintains
last fork block in the list.

control

code

processor.

(CTB).

The

table

the

device

KRB

interrupts

address

the

are

CTB

passed

static.

The KRB table allows the Executive access to
the
structures
for
a
controller when it initiates an interrupt.
To report
the termination of a
data
transfer
command,
a
controller
initiates
an
interrupt.
(While such a controller-initiated
interrupt is in progress, the hardware delays interrupts from

units.)

the

The

CTB

with

Executive

the

determines

controller

vector.

a controller
(overlapped
seek
of UCB addresses.
Structures

the

interrupts,

summary

unit

its

the

driver

must

index

the

UCB

table

control

that

generates

controller

The

physical

the

support
queue

unit
to

operation

regulate

controller

request

processes

KRB

indexing

word

1in

that

have

for

access

Processes

the

requested

placing
for

access

over

control

requests

the

number

parallel,

and

access

the

and

have

also

contains
queue,

blocks

been

use
it
to
proper unit

This

fork

When

attention

interrupting

the

KRB

access.

list

the

for

denied

the

driver

access

queue

driver requests access to a
controller.
busy, the Executive forces the driver to

waiting

positioning

KRB

interrupt.

(in

number

the

controller

queue,

the controller.
The
If the controller is

records

retrieve

block.

the

that
allows
unit
operation
1in
parallel
support), the related KRB must have a table
This table allows the driver to access the

unit.

wait

correct

from

For

unit

the

number

the

access.

fork

The

block

requests

for

onto

front

2-14

the

Executive

data

the
gives

transfer

the

queue

precedence

and

placing

adding

DEVICE DRIVER

I/O STRUCTURES

unit
When a
data transfer requests to the end of the queue.
is
given
access,
the
controller status is set to busy and
unit UCB address is set to connect the KRB to the owned UCB.

To indicate what unit to process on

controller

initiated

interrupt, a cell in the KRB points to the unit control block
(UCB) of the unit that currently owns the KRB.

The KRB queue cells have two words.
The first word points to
the
fork
block
in
the SCB of the next unit to get access.
The second word points to the fork block in the
SCB
of
the
last
unit
to
get access.
If the first word is 0, then the
second word points to the first and no unit
1is
waiting
for
access to

13.

the controller.

The location represented by the Executive symbol $CTLST is
a
cell
1in system common (SYSCM).
It is the head (or start) of
a

singly-linked,

unidirectional

list of all

controller

tables

(CTBs)
in
the
system.
A word in each CTB is a link to the
next CTB.
The last CTB in the list contains a link
word
of
0.

The list of controller tables

1is

one

the

two

threads

through the system for device-related information.
(The list
of device control blocks is the other thread.) A user-written
controller
table
must
be
linked
into
the
1list
of
system-defined CTBs.
This list is
the
mechanism
by
which
system
routines,
such
as those for reconfiguration,
I/0 data structures for hardware information.

14.

access

One volume control block (VCB) exists for each mounted volume
in
the
system.
The VCB maintains volume-dependent control
information.

Pointers within the VCB connect to
the
file
control
block
(FCB)
and
window block (WB).
The FCB and WB control access
to the volume's index file, which is a file of file
headers.
All
FCBs
for
a volume form a linked list starting from the
index file FCB.
These linkages aid in
keeping
file
access
time to a minimum.
A conventional driver does not access any
of

these

structures.

CHAPTER

EXECUTIVE SERVICES AND DRIVER PROCESSING

The Executive provides services related to I/0 drivers.
Some services
are
provided
before
a driver process is initiated and are therefore
called
predriver
initiation
services.
The
predriver
initiation
services are those performed by the Executive during its processing of
a QIO directive;
these services are not available as Executive calls.

Predriver initiation processing extracts from the
QIO
directive
all
I/0 support functions not directly related to the actual issuance of a
function request to a device.
If the outcome of predriver
initiation
processing
does
not
result
in
the
queuing
of an I/0 Packet to a
driver, the driver is unaware that a QIO directive was
1issued.
Many
QIO directives do not result in the initiation of an I/O operation.

Other services are available to the driver after
it
has
been
given
control,
either
by
the
Executive or as the result of an interrupt.
They are available as needed by means of Executive calls.

An important concept used in this section and

Chapter

1is

the

state
of a process.
In RSX-11M-PLUS, a process can run in one of two
states, user or system.
Drivers operate entirely in the system state;
the programming standards described in Chapter 4 apply to system-state
processes.

3.1

FLOW OF AN

I/O REQUEST

Following an I/0 request through the system at
the
functional
level
(the
1level
at which this chapter is directed) requires that limiting
assumptions be made about the state of the system when a task issues a
QIO directive.
The following assumptions apply:

The system is running and ready to accept an I/0 request.
All
required
data
structures
for supporting devices attached to
the

system are

intact,

The only I/0 request in the system is the sample request under
discussion.

The example progresses without encountering
any
errors
that
would prematurely terminate its data transfer;
thus, no error
paths are discussed.

The controller
a

time.

in question executes only a

single operation at

EXECUTIVE

Predriver

3.1.1
The

I/0

flow

AND DRIVER PROCESSING

Initiation Processing

proceeds

described

issues

QIO

directive

Task
The

SERVICES

user

program

first

below:

either

statically

(by

QIOWSC,

QIOWS,

QIOSC, or QIOS) or dynamically (by QIOWSS or QIOS$S) creates a
directive parameter block (DPB) containing information
about
what

I/O

the

directive.

All

Executive

EMT

causes

directives
the

pass

performed

are

processor

control

on what

device.

called

by means

the

push

the

Then,

and

issues

EMT

377.

the

and

Executive's directive

QIO

Dispatching

The
EMT

Executive directive dispatcher DRDSP ascertains
1is a QIO directive and calls the QIO directive

The
stack

processor.

that
the
processor

DRQIO.

First-level
The

QIO

(LUN)

directive

and

whether

validity

the

legal

checks

processor

Unit Control

LUN

supplied

value.

1If

assigned.

1If

checks

these

the

check
are

redirect

algorithm.

Redirect

algorithm

Because

the

Redirect

UCB

may

the

linkage

not

logical

pointer.

directive

fails,

legal

the

unit

number

DRQIO

checks

parameter

been

QIO

until

the

value,

the

directive

successful,

have

command,

redirect

the

(UCB)

block

is
rejected.
If the LUN is legal, DRQIO checks whether a
wvalid
UCB
pointer
exists
1in the Logical Unit Table (LUT) for the
specified LUN.
This check
ascertains
whether
the
LUN
is
both

validates
Block

DRQIO

then

dynamically

directive

rejected.

1If

performs

the

redirected

directive

©processing

traces

target

The

UCB

found.

target
the

UCB provides the links to most of the other structures
device
to which the I/0 operation will be directed.

Additional
The

event

address
illegal,

validity
flag

of
the

successful
the

I/0

Obtain
The QIO
dynamic
the

number

(EFN)

the

wvalidated,

DRQIO

resets

well

(IOSB).
If
Immediately

the

event

flag

for

and

create

device-independent
the

data

both

fulfilling

the

I/0

request.

Most

reque8ting

task's

Directive

Parameter

clears

items

that

are

used

and

the

driver

in
the

Executive

1items

originate

Block

return

directive

the

caller

rejection

with

the

(DPB).

At this point, DRQIO sets the directive status to
indicates
directive
acceptance.
Note
that
a
a

and

processor now acquires a 20-word
block
of
for
wuse as an I/0 Packet.,
It inserts into

rejection

the

I/0 Packet

subsequently

addition,

either is
following

block.

directive
storage

packet

Status
Block
is
rejected.

validation,

storage

checks

the
1I/0
directive

status

the

transparent

bit
to

+1,
which
directive

set.
the

driver.

EXECUTIVE SERVICES AND DRIVER PROCESSING

Validate the function requested

If the function is legal, DRQIO checks to see whether the
If the unit is off-line, the packet is
unit 1is on=line,
The function is one of four possible types:

rejected.

Control
No-op

ACP

Transfer

functions are
control
With the exception of Attach/Detach,
1is set,
If the bit UC.ATT
driver.
the
to
queued
If the
driver.
the
to
queued
be
also
will
ch
Attach/Deta

requested function does not require a call to the driver, the
Executive takes the appropriate action and calls the 1I/0
Finish routine

($SIOFIN).

The
No-op functions do not result 1in data transfers.
No-ops
them without calling the driver.
Executive performs
return a status of IS.SUC in the I/0 status block.

system.
file
by the
processing
1is a read or write virtual
the request
More typically,
function that is transformed into a read or write logical
function without requiring file-system intervention. When
the
function,
transformed into a read or write 1logical
function becomes a transfer function (by definition).

ACP functions may require

Transfer functions are address checked and queued to the
This means that DRQIO checks the address of
proper driver.
the 1/0 buffer, the byte count, and the alignment requirement
If any of these checks fails,
for the specified device.
(SIOFIN), which returns an
routine
DRQIO calls the I/0 Finish
request from the system.
I/0
the
clears
and
status
error
I/0
If the checks succeed, DRQIO either places the I/0 Packet in
the priority of the
ing
the driver request queue accordto

requesting task or, if the

packet

directly

the

UC.QUE

driver.

description of the UC.QUE bit.)

bit

1is set,

gives

the

(See Section 4.4.4 for a

Driver Processing

3.1.2
8.

Request work

To obtain work, the driver calls Get Packet (SGTPKT). S$GTPKT
either provides work, if it exists, or informs the driver
if no
that no work is available or that the SCB 1is Dbusy;
work exists, the driver returns to its caller. If work is
available, $GTPKT sets the device controller and unit to
busy,

driver.

dequeues

I/0

request

packet, and returns to the

EXECUTIVE

Issue
‘From

SERVICES

AND

I/0
the

available

required
subsequent

data

structures,

function

Interrupt
When

complete,

previously

causes
the

interrupt

Chapter

processing

interrupt
I/0 on the

1I/0

according

queues

checkpoint

1I/0

the

updated,

and
to

8).
queue

the

task

3.2

that

EXECUTIVE

interrupts,

the

entered.

the

The

programming

request

driver

calls

status

from

AST

the

pending

for

and

event

I0SB

SIODON

returns
entry

This

procedure

empty,

the

priority
7,
at
or at fork level.

the
1If

associated

the

QIO

the

further
an
I/0

the

task

Get

Interrupt

Create

I/0

Packet

driver

granted

Executive

services

system

(SGTPKT)
Save

Fork

(SINTSV)

Process

(SIODON

now

for

the

driver

returns

are
work

finds

its

caller

another

starting

the

ready-to-run
I/0

flow

anew.

TO A DRIVER

discussed

the

can

The

looks

until

and

whether

specified,

driver.
and

unit

determines

issuing

followed
the

device

and

flag,

point

directive,

AVAILABLE

Executive

virtually every driver

Done

with

vanishes.

processor

issues

SERVICES

whereupon

process

the

initiator

Executive
itself, a number
driver.
These services are
four

protocol

protocol,

Once a driver is given control following an I/O interrupt

However,

driver

$IODON.

required,

its

driver

Eventually,

request

The

branches
the

the

processing

effected.

and

According

the

SIODON removes the busy

(Step

operation

the
interrupt
at
interrupting device,

complete,

controller,

initiates

1is
still incomplete, the driver initiates
device (Step 9).
When the processing
of

Done

1I/0

driver

processes

driver may process
priority
of
the

ll.

issued

the

described

request

driver

returns
to
its
caller.
A
the driver that the initiated
assuming
the
device
is
interrupt

processing

interrupt

the

I/0
operation
and
interrupt may inform

driven,

10.

DRIVER PROCESSING

($FORK)
SIOALT)

services

detail

merit

uses

are

special

them:

available

Chapter

the

emphasis

because

EXECUTIVE

3.2.1

Get

Packet

SERVICES

AND

DRIVER PROCESSING

(SGTPKT)

The Executive, after it queues an I/0 Packet,
calls
the
appropriate
driver at its I/O initiation entry point.
The driver then immediately
calls the Executive
routine
S$GTPKT
to
obtain
work.l
If
work
is

available,

SGTPKT

executable
Status

I/0

busy,

delivers

Packet

busy.

S$GTPKT

1If

the

returns

I[f the SCB related
the
driver,
and
Executive,.

the

driver's

no-work

the

driver's

device

driver

driver
I/0

I/0

the

queue,

queue

already

3.2.2
A

either

Interrupt

the
the

SCB

driver

informs
to

distinction

I/0

operation

the

exists
cannot be

(SINTSV)

should not directly call the $INTSV coroutine but should
INTSVS macro call.
Therefore, if the driver is loadable, it
call SINTSV and the macro
will
not
generate
the
call
in

driver.

(The

interrupt

control

the

interrupt

block

Executive.)

generates

the

call

driver
the

SINTSV

coroutine

already
Section

there.
4.3 and

3.2.3

Fork

Synchronization
base,

5-word

1is

resident,

coroutine.

call

done

common

is
R4

and

the driver onto

the

system

access

1I/0 Done

completion

the

perform

1.An

shared

When

fork

block.

data

driver

process;

The

See

OStore

GSet

exception

driver

SGTPKT.

must

bases

(SIODON

number

of
of

status
event

<call

code

save

and

importantly,

system stack

call

the

is not

($FORK)

SFORK.

data

3.2.4

macro
saves

code

SCB

bases
needs

the

contains

Section

4.4.5

1is

accomplished

access

driver

preallocated

for

strictly

I/0

flag

request,

IOSB
if

driver

certain

See Section 4.4.4

storage

description
After

by
data

fork
for

the

SFORK

and

its

access

$I0ODON

S$IOALT

linear.

SIOALT)

centralized
if

shared
becomes
a

fork
block.
Section
7.4 contains details on $FORK.
called, a routine is fully interruptable (priority 0),
shared

the

routine

INTSVS$

coroutine

than

R5.

either

interrupt

the

The

shorter

use

need
the

INTSVS
macro
1is
described
in
more
detail
in
interrupt entry point is described in Section 4.5.

fork

1is

registers

process.,

calling

processing

appropriate

SINTSV

the

Process

fork

it must

process

the

gets

The
the

the

driver

conventional

Create

creating

save

because

restore

driver

the
not

case.

Save

sets
or

busy,
S$GTPKT
so
returns
control

1immediately

that, from the driver's pointof
view,
between
no-work
and
SCB
busy,
because
an

empty

indication.

Note

initiated

highest-priority,
and

one

that

the

checks
address
was

was

additional

functions:

specified

requested

handles

other

subroutines

and

special

Executive

for a description of

user

buffers.

routines

before

the UC.QUE

bit.

Such

calling

EXECUTIVE SERVICES AND DRIVER PROCESSING
e

Determine whether

a checkpoint request can now be honored

Determine whether

an AST should

be queued

SIODON and SIOALT also declare a significant event, reset the SCB and
to idle, and release the dynamic storage used by
wunit status
device
the completed

I/0 operation.

CHAPTER

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER

Chapters 2 and 3 give overviews of data structures and Executive
programming
summarizes
chapter
This
respectively.
services,
for
s
requirement
=
programming
of
overviews
presents
standards,
user-written driver code and data, and gives details of the data
structures and driver code. Executive services are covered in Chapter
7.

4.1

PROGRAMMING STANDARDS

I/0 drivers function as integral components of the RSX-11M-PLUS
Executive, and this manual enables you to incorporate I/O drivers into

your system. User-written drivers must follow the same conventions
and protocol as the Executive itself if they are to avoid complete

Failure to observe the internal
disruption of system service.
conventions and protocol that are described fully in Chapter 1 can
result in poor service and reductions in system efficiency.
The programming conventions used by RSX-11M-PLUS system components are
identical to those described in Appendix E of the PDP-11 MACRO-11
Language Reference Manual. DIGITAL urges you to adhere to these

conventions.

Programming Protocol Summary

4.1.1

Drivers are required to adhere to the following

when processing device

interrupts:

No registers are available for use
called,

the

SINTSV

been

has

operations.
available;

If $SINTSV is called, registers R4 and RS> are
any other registers must be saved and restored.

immediately

because

S$INTSV

SINTSV

controller number from the PS.

directly,

attempts

must

retrieve

the

Noninterruptable processing must not exceed 20 instructions,
and processing at the priority of the interrupting source
must not

unless

driver explicitly performs save and restore

If the driver is to call

conventions

internal

exceed

500us.

Only a fork process should modify system data bases.

PROGRAMMING

4.1.2
All

Accessing

SPECIFICS

Driver

Data

FOR WRITING

I/0

DRIVER

Structures

the

driver data structure elements have symbolic offsets.
Because
physical offset values may vary from one version of the Executive
to another, your
user-written
driver
code
should
always
use
the
symbols to access the elements.

the

Accordingly,

your

element

another

and

driver

code

should

(relying

individual

not

step
from
one
structural
juxtaposition of data structures
structure)
but
should
access
each

the

words in a
data
by
symbolic offset.
By following this aspect of
practice, you can reduce debugging time
when
converting

element

driver

to run on RSX-11M-PLUS.
physically from those in

differ

symbolic

the

This

Many of the offsets in the RSX-11M SCB
the RSX-11M-PLUS SCB but have the same

values.

other

offsets

hand,

(particularly

common

1link

good coding
an
RSX-11M

coding

pointers

practice

such

assume

D.LNK)

will

assumption

that

zero

remain

zero.

allows the saving
of
one
word
per
instruction
by
an instruction such as MOV (R3),R3 for MOV D.LNK(R3),R3.
recognizes that such practices are followed
and
consequently

substituting
DIGITAL
attempts

4.2

keep

OVERVIEW OF

such

offsets

PROGRAMMING

zero.

USER-WRITTEN DRIVER DATA BASES

You should create the source code for your
user-written
driver
data
base
in
a
file separate from that of the driver code.
You assemble
this file to create the driver data base module.
If
you
make
vyour

data

base
resident,
your data base module will be linked separately
from the driver code and will be linked to the
system
device
tables
module SYSTB.OBJ.
(The source code for the SYSTB module is created in
UFD

[11,10]

separate

the

during

module

driver

code

module

driver

code.

system

and

module.

that

generation.)

1If

vyour

loadable,

your

driver

vyour
will

data

code,

data
be

base
must

base

linked

1in

the

1is

the

end

the
end

same
of

the

The

detailed descriptions of the driver data structures are in Section
4.4,
A
few
fields
1in
the
structures
are conditional on certain
features
in
the
Executive.
You
therefore
must
use
<conditional

assembly

the

directives

Executive

system

and

assembly

some

prefix

system-wide

file

symbols

RSXMC.MAC,

generation.

that

which

are

defined

created

during

To create
detailed

the source code, you
need
to
know,
1in
addition
to
the
structures,
what ordering and labeling are required.
These
requirements, though not
extensive,
are
important
in
linking
and
loading
vyour
driver
data base.
The general coding requirements for

both loadable and resident driver
following subsections.

4.2.1
If

General

you

LOAD

are

Labeling

creating

and

Ordering

loadable

routines,

two

SxxDAT::

marks the

SXxXEND::

marks the end of
that
data

global

1is,
base.

data

data
as

labels

start of

bases

Data

base, you
follows:

the

immediately

are

described

the

for

the

Structures
must

specify,

user-written driver data base.

user-written
following

driver
the

final

data
word

base,
of

the

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER

The characters xx represent the 2-character
that
vyour
driver
data
base
supports.

mnemonic
of
the
device
If either or both of these

labels are not defined, LOAD cannot determine
base when you attempt to load your driver.

the

length of

your

data

There is no mandatory ordering of the different structures in a driver
data
base.
DIGITAL suggests, however, that you place the DCB first,
followed by the UCB, the SCB(s), the KRB(s), and the CTB.
If
vyou
do
not
follow
this
ordering
scheme,
you
must
specify
the starting
location of the first (or only) DCB as described in Section 4.2.2.

4.2.2

Device Control

Block

Labeling

If the data base for a driver is to be
loadable,
the
LOAD
routines
require
either
that
the
first
(or
only) DCB be identified by the
global label $xxDCB::
or that the DCB be at the
start
of
the
data
base.

If the data base for a driver is to be resident, you must
define
the
start of the first (or only) DCB with the global label SUSRTB::.
This
label is required to link the last DCB defined
1in
the
SYSTB
module
with
the
DCB
in
vyour driver data base.
If you fail to supply this
symbol, the Task Builder will generate an
undefined
reference
error
when it builds the Executive.

4,2.3

Unit Control Block Ordering

All the UCBs associated with a specific
device
control
block
(DCB)
must be contiguous with each other and must be of equal length.
These
requirements are necessary because the DCB has only one
1link
to
the

UCBs,
and
that link is to the first UCB.
length and the number of units, are stored

Two data elements, the UCB
in the DCB;
they, together

with
the
1link
to the first UCB, are used to locate subsequent UCBs.
If you do not follow these requirements, no software
can
access
the
UCBs.

4.2.4
All

Status Control

user-written

independent
KRB and SCB.

and Controller Request Blocks

drivers

that

not

need

separate

storage

for

unit
context should use the continuous allocation of the
(For an explanation of when independent unit context
1is

required,
refer
to
the discussion of overlapped seek I/0 in Section
1.4.1.) Therefore, the KRB and SCB are contiguous and some
fields
of
each
structure
overlap.
This arrangement saves space that would be
required for one SCB for each independent unit.
Because only one unit
can
be
active
at
any
one
time,
all
wunits
attached to the same

contrecller can share the
is described

4.2.5

Section

Controller

SCB.

4.4.7.

This arrangement of the KRB and the

Table

You must define the start of the table of KRB

with

the

global

SCB

1label $xxCTB::.

Executive LOAD routines require this

Both the
label.

addresses

the

CTB

INTSVS macro call and the

If your data base is resident, you must use the CTB macro at
the
CTB
link word L.LNK.
The CTB macro automatically generates a global label
SYSTB
the
in
that provides the linkage between the last CTB defined
4-3

PROGRAMMING

module
and
the
definition of the
system

4.3
To

SPECIFICS

CTB
defined
CTB macro is

FOR WRITING AN

in
vyour
created in

I/0 DRIVER

driver

tables module.
(The
file
RSXMC.MAC
during

the

generation.)

OVERVIEW OF
create

the

following

PROGRAMMING

source

code

USER-WRITTEN DRIVER CODE
drive

device,

you

must

perform

the

device

and

steps:

Thoroughly

read

2.,

Familiarize yourself in detail with
its operational characteristics.

Determine

the

Determine

actions

Create

the

and

level

understand

driver

support

taken

source

You can write driver code

for

this

manual.

the

physical

required
at

the

for

the device.

driver

entry

points.

code.

RSX-11M-PLUS

that

does

one

the

following:
l.

Supports

Supports standard functions and is
written
so
that
compatible
with use on both RSX-11lM and RSX-11M-PLUS.
driver needs separate data bases for each system.)

it
1is
(This

Supports advanced features and
(Although
Chapter 1 discusses

runs
on
RSX-11M-PLUS
advanced features, this

only.
manual

not describe how to
program
advanced
features.
guide
to
utilizing
advanced
features
1is
to

Your
wuse a

does
best

standard

DIGITAL-supplied

To assist you in
and
to
provide
system

Table

4-1.

The

requirements

The

DDTS$

RSX-11M-PLUS

the

driver

and

Generate

table.

runs

macro
The

DDTS

RSX-11M-PLUS

only.

model.)

system

provides

macro

the

<calls

macro

for

assembly
prefix file RSXMC.MAC.
the
format
of
the
macro
calls

user-written

4.3.1

driver

and

generating proper code for your
user-written
a stable user-level interface from one release

another,

definitions

Executive
describe

functions

code.

entry point

Driver

call

format

Driver

Dispatch

facilitates
of

the

<code

conditions)

DDTS$

Table

details

are

Macro

call

drivers

1listed

are

1in

the

The following subsections
and
other
features
of
(such

presented

Call

generation
macro

<calls

driver
of the

of
as

labeling

Section

4.5.

DDT$

the

driver

dispatch

follows:

dev,nctrlr,iny,inx,ucbsv,NEW,0OPT,BUF

Table 4-2 lists the arguments of
the
DDT$
macro
call.
The
macro
constructs the
DDT,
using as addresses those locations indicated by
the standard labels.
The macro has arguments allowing you
to
tailor
some

the

DDTS$S

the

standard

macro

entry points.

described

The

Section

format
4.5.1.

the

DDT generated

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER
Table

4-1

System Macro Calls for Driver Code
Macro

General

Name

DDTS

Functions

Used conventionally at the start of the driver code
to

allocate

storage

driver

supports,

(b)

point

procedures

(1)

for

to generate a

and

driver dispatch table containing the addresses of
entry points 1in the order in which the Executive
to generate special global
(2)
expects them;
(3) to tell the
Executive;
the
by
required
labels
(a) which controllers the
Executive LOAD routines:

many interrupt vectors

how

the association
each controller supports, and (c)
the driver
and
vectors
interrupt
the
between
generate
to
(4)
and
entry points;
interrupt
entry
change
status
unit
and
r
default controlle

GTPKTS

on-line

(for

transitions)

and

off-line

Used at the I/O initiator entry point to generate
the call to the $GTPKT routine and to generate code
to save the address of the currently active unit's
UCB

INTSVS

Used at an interrupt entry point to conditionally
generate a call to the S$INTSV routine and to
UCB address of the
1load the
generate code to
into R5

interrupting device
Table

DDT$ Macro

4-2

Call

Arguments

Meaning

Argument

dev

is the 2-character device mnemonic.

nctrlr

is the number 6f controllers that the driver

iny

(counting

from

services

1).

allows the definition of no interrupt entry point or
If you leave the
multiple interrupt entry points.
argument null, the macro generates as the interrupt
entry point address the location defined by the
conventional

label

If you specify

$xxINT.

NONE,

interrupt

generated for the controller.

If you specify an argument 1list
<aaa,bbb,...>, the macro generates

entry

point

the
of
multiple

containing addresses defined by unconventional

1is

form
cells

labels

of the form $xxaaa and $xxbbb. This latter mechanism
allows you to define multiple interrupt entry points
For example, the argument 1list
the driver.
in
interrupt address labels of
two
generates
<INP,OUT>
the form SxxINP and $xxOUT, the typical names used by
drivers with two interrupt entry points.

(continued on next page)

PROGRAMMING

SPECIFICS

Table

FOR WRITING

4-2

DDT$ Macro

I/O

DRIVER

(Cont.)

Call

Arguments

Argument

Meaning

inx

uses an alternate
label
instead of
specify
entry

inx,

I/O
the

initiation entry
point
conventional xxINI form.

address
If you

the macro uses as the only I/0 initiation
address the location defined by the label

point

Xxinx.

ucbsv

is for compatibility with RSX-11M drivers.
If you are
writing
a
driver
for RSX-11M-PLUS, you should leave
this

argument

blank.

allocate
the
For guidelines
Section 4.3.4.
NEW

except

the

a result, the macro does
not
for
the table of UCB addresses.
specifying this arqument,
refer
to

distinguishes

drivers.

space

between

you

null),

the

RSX-11M-PLUS

specify
macro

controller

and

this

generates

unit

two

status

addresses.
The referenced driver
labelled
xxKRB:
and
xxUCB:.
these entry
points,
it
cannot
RS5X-11M

the

use

unless

argument

the

on-line
OPT

the

routines

is null,

xxPWF

and

two

entry

off-line

The
the

1I/0

status

corresponding

request

and

required

output.

The

the

that
it

code

controller

and

xxDEA:

to
unit

seek

optimization.
labelled xxCHK:.
label should qualify
be

performs

point

hold

conditionalized.

changes.

convert

driver

entry

entry point
entry points must be
If
vyour driver uses
be
compatible
with

for

sector.

BUF

cells

the macro generates
point

that the driver supports
referenced
entry
point must

routine

RSX-11M

(any character

change

are

indicates
The

and

argument

cylinder

buffered
1is

track

input

and

generated.

NOTE

RSX-11M

drivers

and

unit

power

implicitly

on-line

and

failures.,

handle

status

changes

Although

this

default

operation

(enabled
by
code
this argument null) is

leaving

operation

probably

changed
points.

4.3.2
The

Get

Packet

Macro

GTPKT$S

macro

call

routine,

format

which

the

GTPKTS

The

description

RSX-11M-PLUS,

generated
from
not optimal for
the

function
properly
to
include the xxKRB

Call

retrieves

GTPKTS

driver

being

and

entry

xxUCB

- GTPKTS

standardizes

use

the

for

the

driver

I/0 packet

call

Executive

follows:

dev,nctrlr,addr ,ucbsv,suc

the

will

without

macro

controller

off-line

arguments

appears

4-6

Table

4-3.

SGTPKT
process.
The

PROGRAMMING SPECIFICS FOR WRITING AN

Table

GTPKTS Macro

I/O DRIVER

4-3

Call

Arguments

Argument

Meaning

dev

nctrlr

is the number of controllers
(counting from 1).

addr

is the local label defining the location at
which
to
continue
execution
if
there
is
no
I/0
packet
available.
A
driver
typically
executes
a
RETURN
instruction
when
the
S$GTPKT
routine indicates that
there is no I/0 packet to process.
If you leave
this
argument null, therefore, the macro generates a RETURN
instruction.

ucbsv

the

2-character device mnemonic.

for compatibility with

writing
a
driver
this argument null.
load
the
pointer

indicates
a
driver

the

driver

RSX-11M drivers.

services

you are

for RSX-11M-PLUS, you should leave
The macro then generates code
to
S.OWN
with the address of the UCB

returned by
SGTPKT.
For
argument, refer to Section
suc

that

guidelines
4.3.4.

single unit controller.
If you
for RSX-11M-PLUS that supports

wusing

the

are
writing
a controller

type such as the LPll, to which only a single unit can
be
attached,
vyou
should
specify this argument (any
character(s)
except
null).
If
vyou
specify
this
argument,
you
should
ensure
that
the
offset
K.OWN/S.OWN in the KRB(s) of
vyour
driver
data
base
points
to
the
UCB(s)
of
the
wunit(s) to which the
controller(s) is attached.
Thus, the macro
does
not
generate
code
that stores the UCB address in the KRB
(a gratuitous operation) for a device
that
has
only
one

UCB

per

your

attached
argument
store

KRB.

RSX-11M-PLUS
driver
has
same controller, you

to the
null.

The

macro

the

KRB

the

call

multiple

units

should leave this
therefore generates code
to
UCB

address

the

unit

process.

This macro

call

generates

the

Executive

S$GTPKT

routine.

You
should place it at the I/O initiation (xxINI) entry point because
the SGTPKT routine is the standard manner for a driver to receive work
from
the
Executive.
When
the driver receives control at its xxINI
entry point, the Executive has loaded R5 with the address of
the
UCB
of
the
wunit
that
the driver must service.
Because of the code the
macro call generates, the driver immediately calls $GTPKT,
which
can
set
the
C
bit
to
indicate
that
no
work
is
pending.
The call

additionally generates the BCS instruction that

calling

routine

argument

when

there

the macro

call,

work.

used

BCS
instruction.
The
address
1is
instruction, but does not have to
be.
execute

RETURN

the

you

the

returns control
specify an

address

destination

the

as
the

typically
that
of
a
RETURN
Eventually
the
driver
must

system.

The SGTPKT routine indicates that
process
by
<clearing
the C bit.

*he driver”
Therefore,

has
when

an
the

I/0
test

packet
of the

to
BCS

PROGRAMMING

instruction
process

false,
I/0

execution

continues
the

routine leaves information in
driver to process the request.
routine in Chapter 7.

the

Interrupt

packet

FOR WRITING AN

that

4,.3.3

the

SPECIFICS

Save Macro

I/0O

inline

Executive

DRIVER

and

queued

the
to

driver

it.

The

can

S$GTPKT

driver
registers
to
enable
the
Refer to the description of the S$GTPKT

Call

INTSVS

You should specify the INTSVS macro call at each interrupt entry point
in
the
driver.
The
macro
conditionally
generates
a call to the
Executive SINTSV routine based on whether the driver is loadable.
The
format of the INTSVS macro call is as follows:
INTSVS
The

dev,pri,nctrlr,pswsv,ucbsv

arguments

LD$xx

(where

generates
interrupt

the

call

1is

are

the

described

device

Table

mnemonic)

the call to $SINTSV and defines
service routine will run.
Not

4-4.

not

1If

the

defined,

the
priority
defining LDS$Sxx

symbol

the

macro

at
which
indicates

the
that

the

driver is resident.
(For loadable drivers, the interrupt
service
routine
1in the Executive dispatches the interrupt.) For both loadable
and resident drivers, however, the macro generates the code to load RS

upon

interrupt.

Table

INTSVS

4-4
Call Arguments

Macro

Argument

Meaning

dev

pri

the

2-character

the

processor

the

device

runs

device

priority
and

mnemonic.

(PR4,

which

PR5

the

PR6)

which

SINTSV coroutine

will

run.

nctrlr

the

number

(counting

pswsv

for

an
If

argument
ucbsv

for

your

driver

the

driver

services

driver,

1is

drivers.

leave

1If

this

RSX-11M

you

are

argument

driver,

this

effect.

compatibility

that

RSX-11M

RSX-11M-PLUS

has

writing

this
uses

controllers

1).

compatibility with

writing
null,

from

driver

with

for

RSX-11M

drivers.

RSX-11M-PLUS,

you

should

are

leave

argument null.
The macro
generates
code
which
the
controller
index returned in R4 by S$INTSV,

calculates

the KRB of the interrupting controller, and
loads
the
UCB
address of the interrupting unit into
R5.
For guidelines on specifying this argument, refer

4.3.4
The

Usage

DDT$,

argument

and

(ucbsv)

ucbsv

(one

for

INTSVS

that

does

argument

4.3.4.

UCBSV Argument

GTPKTS,

R5X-11M-PLUS

word

Section

not

each

the

macro

maintains
need

DDT$

controller

Macro

calls

allow

you

compatibility with
utilize

macro
that

Calls

the

wucbsv

allocates

nctrlr

the

driver

specify

RSX-11M

argument.

words

supports)

and

drivers.
The

storage

labels

the

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER

first word ucbsv:. This storage is the CNTBL area used by RSX-11M
drivers to contain the address of the wunit control block of the
interrupting devices for each controller. Both the GTPKTS and INTSVS
macro calls may use this same area. For more information concerning
CNTBL, consult the RSX-11M Guide toWriting an I/O Driver.

If you specify the argument ucbsv in the GTPKT$ macro call, it must be

same

the

1label

that you supplied for the ucbsv argument in the DDTS

UCB
to move the
The macro generates code
and INTSVS macro calls.
the correct 1location in the table
address returned by $GTPKT to
starting

at the label

ucbsv.

If you specify the argument ucbsv in the INTSVS macro call, it

should

the same label you supplied for the ucbsv argument in the DDTS$ and

The macro uses ucbsv to locate the UCB address of
GTPKTS macro calls.
then generates code to load the address
and
unit,
interrupting
the
|

into R5.

4.3.5

Specifying a Loadable Driver

To specify that a driver is

1loadable

and

enable

generation

The definition
you must define the symbol LDS$Sxx.
code,
conditional
can appear in either the driver source code or the assembly prefix

It is usually more convenient to define the symbol in

file RSXMC.MAC.

to
not have cause
the driver source code because you probably will
not
does
macro
INTSVS$
the
defined,
is
edit RSXMC.MAC. When the symbol

generate the call to SINTSV.

Loadable Driver Entry Points for LOAD and UNLOAD

4.3.6

and
initialization
A loadable driver that requires additional
completion functions can define two entry points by labels of the form
2-character device mnemonic).
1is the
$xxLOA and $xXUNL (where xx
Because these two labels do not appear in the DDT itself, their format
When
code.
driver
you must use the exact format in your
is fixed;
entry
S$xxLOA
the
for
check
routines
©LOAD
the
driver,
the
you load

point.

NOTE

The

LOAD

function

routines

can

only from MCR.

perform
If

this

you attempt

to load a driver
that
has
the
S$xxLOA
entry point from VMR, the load operation
is terminated
with
DRIVER
REQUIRES

the
error
message
RUNNING
SYSTEM
FOR

LOAD/UNLOAD.

The driver is entered, once per UCB, at the $xxLOA entry point at
At this stage, the driver data base has been loaded
priority =zero.
The driver is mapped through APR 5,
and pointers have been relocated.
and

the

following

registers are

set

up:

R3 - Controller index (undefined if S.KRB = 0)
R4 - Address of the status control block
R5 - Address of the unit control block,

The driver may use all the registers. When you unload the driver, the
UNLOAD routine calls it at the $xxUNL entry point with the same
conditions.

4-9

PROGRAMMING

SPECIFICS

FOR WRITING

I/O DRIVER

These two entry points in the loadable driver are independent
of
the
controller
and
wunit
status
change
entry
points used by Executive
reconfiguration software.
That is, the two entry
points
$xxLOA
and

$XXUNL

are

wused

time

and

4.4

DRIVER DATA

not

for

initialization and

on-line

and

off-line

completion at

status

change

LOAD and UNLOAD

time.

STRUCTURE DETAILS

The following elements in the
programmer writing a driver:

The

I/0 packet

The

DCB

The

UCB

The

SCB

The

KRB

The

CTB

I/0 data

structure

are

concern

the

The

I/0 data
particular,

structure, and the control blocks
1listed
contain
an
abundance of data pertaining

previously
in
to input/output

operations.
data.

Drivers

themselves

are

involved

with

only

subset

the

NOTE

Except where
all
wunused

explicitly noted otherwise,
bits,
fields, and words in

all

data

driver

reserved

for

base

DIGITAL

structures
system

wuse

are
and

expansion.

In the following descriptions, most data
classified by one of five descriptions.

fields (words or
Two items in each

bytes)
are
description

indicate:

Whether

the

field

initialized

the

data-structure

source,

and

What

sort

access

the

driver

has

the

field

execution

The

five

descriptions

are:

<initialized, not referenced>
This field is supplied in the data-structure source
is not referenced by the driver during execution.
<initialized,

This
may
<not

code,

and

code,

and

read-only>

field
be

during

read

supplied

initialized,

the

data-structure

source

driver.

read-only>

Either an agent
or
the
driver

other
sets

than the driver establishes this field,
it up once and thereafter references it

read-only.

4-10

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER

<not

initialized,

read-write>

Either the driver or some other agent establishes this field,

and the driver may read
<not

it or write over

initialized, not referenced>
This field does not involve the driver

it.

in any way.

These five descriptions cover most of the fields in the control blocks
No system software or hardware checks or
this section.
in
described
the
1in
noted
are
Exceptions
enforces any of the access described.
text.

4,.4,1

The

I/0

Packet

Figure 4-1 shows the layout of the I/O Packet,
which
1is
constructed
and placed in the driver I/O queue by QIO directive processing, and is
subsequently delivered to the driver by a call
to
SGTPKT.
The
DPB

from

which

the

1I/0

generated is illustrated in Section

1is

Packet

4,4.2.

I.LNK

Link to next |/O packet

|.PRI

I.EFN }
:

EFN

1.TCB

TCB address of requester

I.LN2

Address of second LUT word

I.UCB

Address of redirect UCB

I.FCN

Function code

1.10SB

[.AST

Modifier

Virtual address of 1/0Q status block

Relocation bias of 10SB

Real address of 10SB

Virtual address of AST service routine

[.PRM

Device
parameters

. AADA

Attachment Descriptor Pointer

I.AADA+2

Attachment Descriptor Pointer

|
Figure

4-1:

|
1I/0

4-11

| ZK-254-81
Packet

Format

PROGRAMMING

SPECIFICS

FOR WRITING

I/0O DRIVER

QIO directive processing dynamically builds the I/0O
packet
from
the
data
in
the
DPB.
Fields in the I/0 Packet (see the following text)
are classified as:
@

Not

referenced,

®¢

Read-only,

®¢

Read-write.

I.LNK

Driver

access:

Not

referenced.

Description:

Links I/0 Packets queued for
a
driver.
A
chain.
The listhead is in the SCB (S.LHD).

2zero

ends

the

I.EFN

Driver
Not

access:
referenced.

Description:

Contains

the

processing

event flag

from

the

number

requester's

copied

QIO

directive

DPB.

I.PRI

Driver
Not

access:
referenced.

Description:

Priority copied

from

the

TCB

the

requesting

task.

I.TCB

Driver
Not
and

access:
referenced usually.
power failure.

Sometimes

referenced

I/0

cancel

Description:
TCB

address

the

requesting

task.

I.LN2

Driver
Not

access:
referenced.

Description:

Contains the address of the second word of the LUT
entry
1in
the
task
header
to which the I/0 request is directed.
For
open files on file-structured devices, this word contains the
address of the Window Block;
otherwise, it is zero.

4-12

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER
I.UCB

Driver

access:

Not referenced by conventional driver;
by full duplex drivers.

frequently referenced

Description:

to be
1is
I/0
which
to
unit
Contains the address of the
1is the address of the Redirect UCB if the
I.UCB
directed.
MCR Redirect command.
an
starting UCB has been subject to
The field is referenced by the S$GTPKT routine.
I.FCN

Driver

access:

Read-only.

Description:

It consists
Contains the function code for the I/0 request.
The high-order byte contains the function
of two bytes.
During
bits.
contains modifier
the low-order byte
code;
predriver initiation the Executive compares the function code
The driver interprets
with a function mask value in the DCB.
the modifier bits.
I.I0SB

Driver

access:

Not

referenced.

Description:

Block
I.I0OSB contains the virtual address of the I/0 Status
(I0SB), if one is specified, or zero if one is not specified.
the
I.I0OSB+2 and I.IOSB+4 contain the address doubleword for
a detailed description of the
for
7.2
Section
(see
IOSB

address doubleword).
bias

the bias is,

formatted as

block

32-word

The

in which

second word

Bits 0 through
Bits 6 through
Bits

The first word contains the

of the I0SB;

13 through

5
12
15

the

IOSB

relocation

in effect, the number of the

starts.

follows:

Displacement
All zeros
6

in block

(DIB)

The displacement in block is the offset from the block base.
It is used to
The value 6 in bits 13 through 15 is constant.
cause

address

reference

through

Kernel

Address

Page

(APRG).

Section
to
Discussion of the address doubleword is deferred
7.3 because you seldom have to be concerned with its contents
1Its construction
or format in writing a conventional driver.
and subsequent manipulation are normally external to the
Subroutines are provided as Executive services for
driver.
programmed I/0 to render the manipulations of I/0 transfers
transparent to the driver

itself.

PROGRAMMING

SPECIFICS

FOR WRITING

I/0

AST

service

DRIVER

I.AST

Driver

access:

Not

referenced.

Description:

Contains

the

executed

field

virtual
I/O

contains

address

completion.

the

address

zero.

routine

specified,

be
the

I.PRM

Driver

access:

Read-write.

Description:

Device-dependent
words

parameters

the

DPB.

transfer

(refer

4.4.3),

the

buffer

parameter)

constructed

Note

that

1if
description

the

address

translated

wvirtual

word

buffer

DPB,

occupies

two

the

D.MSK

DPB

equivalent

the

address,

words

DIGITAL-supplied

read/write
been used.
When

storage

the

last

nonzero,

the

could

value

the

word

word,

SIODON,

wvalue

Executive.
be

For

one

example,
address,

if
the

word.

one

I.PRM

value

one

result,

word

words

that

contents

have

parameters
special

Executive

1its

+(2%*n)+2.

initial

Therefore,

restore

doubleword.

occupied

several

the

a
Section

which

these

their

six
is

device-dependent

have

locking

should

treat

after

the

can

Executive

block

drivers

area

1last

function

address

I.PRM.

all other parameters in I.PRM are shifted
device-dependent parameter n is copied to
Most

the

1I/0

(first

Therefore,
in

from
the

nonzero

assumes

1is

meanings

the

and

that

driver

contents before

the

uses

calling

I.AADA

I.AADA+2

Driver

access:

Not

referenced;

the

driver.

maintained

the

Executive

transparently

Description:

Two

pointers, each to an attachment descriptor
region
in which the task I/O buffer resides.

account

region
and to

4.4.2
The

QIO

never

The
DPB

I/O

region

and

enable

the

Executive

to make it noncheckpointable while I/0
unlock a region after I/0 completes.

QIO Directive

access

reference.

for

Parameter

constructed
the

DPB;

as
the

shown

Block
in

of
the
pointers

lock

progress,

(DPB)

Figure

information

block

These

4-2.
supplied

Usually

drivers

here

general

for

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER

The parameters in the DPB have the following meanings:
(required):

Length

The length of the DPB, which for the RSX-11M and RSX-11M-PLUS QIO

directive is always fixed at 12 words.
DIC

(required):

For the QIO directive, this value

Directive Identification Code.
is

Q.IOFN

For QIOW it

(required):

The code of the requested I/0 function

(0 through

31).

Length

DIC

Q.IOFN

Function code

Modifier

Q.1I0LU

Reserved

LUN

Q.IOPR/Q.IOEF

Priority

EFN

Q.10SB

1/0O status btock address

Q.I0AE

AST address

4
6

Q.10PL +0

+2 parameters

+10 Bl
+12 Bl

o
ZK-255-81

Figure 4-2:

QIO Directive Parameter Block

(DPB)

Modifier:

Device-dependent modifier bits.
Reserved:

Reserved byte;
Q.IOLU

must not be used.

(required):

Logical

Unit

Number.

Q.IOPR:

Request priority.

Ignored by RSX-11M-PLUS,

allocated for IAS compatibility.

but

space

must

PROGRAMMING

Q.IOEF

FOR WRITING AN

I/0O DRIVER

(optional):

Event
Q.I0SB

SPECIFICS

flag

number.

Zero

indicates

event

flag.

(optional):

This word contains a pointer to the I/0 status block, which
is
a
2-word, device-dependent I/O-completion data packet formatted
as:
Byte

I/0
Byte

status

Augmented
Bytes

and

The

data

supplied

the

driver.

contents

byte

Processed
contents

Q.IOAE

byte.

these

=1,

bytes

then

depend

these

byte
are

count.
If byte
device-dependent.

the

bytes
0

does

value

usually
not

equal

byte

contain

the

then

(optional):

Address

the

I/0 done

AST service

routine.

Q.IOPL
Up to six parameters specific
to
function
to
be
performed.
functions, the following four are

The

Buffer

Byte

Carriage

Logical

fields

the
device
and
to
Typically,
for
data
used:

address

count

for

control

block

type

number

any optional

parameters

not

specified

must

with

zeros.

4.4.3

The

Figure
static

4-3 is a schematic layout of the DCB.
The
DCB
characteristics
of a device controller and the

the

the
I/0
transfer

Device

Control

controller.

All

Block

fields

filled

(DCB)

must

describes
the
units attached

specified.

The fieldsl in the DCB are described as follows:
D.LNK

(link

Driver

DCB)

access:

Initialized,

not

referenced.

1. Parenthesized contents following
value to be initialized in the data

the

symbolic

base

source

4-16

offset
code.

indicate

the

PROGRAMMING SPECIFICS FOR WRITING AN I/0 DRIVER
Description:

Address 1link to the next DCB.

If this cell is

the

last

If you are
(or only) DCB, you should set its value to zero.
incorporating more than one user-written driver at one time,
field should point to another DCB in a DCB chain,
then this

which is terminated by a value of zero.
(pointer

D.UCB

Driver

first

UCB)

access:

Initialized,

not

referenced.

D.LNK

Link to next DCB (0O=last)

D.UCB

Link to first UCB

D.NAM

Generic device name (ASCII)

D.UNIT

Highest unit no.

Lowest unit no.

D.UCBL

Length of UCB

D.DSP

Address of driver dispatch table

D.MSK

Legal function mask bits O - 15.

Control function mask bits 0 - 15.

No-op’ed function mask bits 0 - 15,

ACP function mask bits 0 - 15.

Legal function mask bits 16. - 31.

Control function mask bits 16. - 31.

No-op'ed function mask bits 16. - 31.

- 30

ACP function mask bits 16. - 31.

Address of partition control block

D.PCB

ZK-256-81

Figure

4-3:

Device Control

Block

Description:

possibly
and
first,
Address link to the U.DCB field of the
For a
only, unit control block associated with the DCB.
the
and
locations
memory
given DCB, all UCBs are in contiguous
must all have the same length.

D.NAM

(ASCII
Driver

device

name)

access:

Initialized,

not

referenced.

‘Description:

Generic device name

mnemonically referenced.

ASCII

4-17

which

device

units

are

PROGRAMMING

D.UNIT

(unit

Driver

number

SPECIFICS

FOR WRITING

I/O

DRIVER

range)

access:

Initialized,

not

referenced.

Description:

Unit

number

contains

range

the

contains
logical

for

the

device.

The

1lowest

wunit
number;
unit number.
This

the

low-order

byte

high-order
range
covers

byte
those

the

highest
wunits
available
to the user for device assignment.
Typically, the lowest number is zero, and the highest is n-1,
where n is the number of device-units described by the DCB.
D.UCBL

(UCB

length)

Driver

access:

Initialized,

not

referenced.

Description:

The

unit

control

block can have any length to meet the
needs
for variable storage.
However, all UCBs for a
have the same length.
The
specified
1length

of
the driver
given DCB must
must

include

prefix

words

(such

U.LUIC

and

U.OWN),

present.

D.DSP

(driver

Driver

dispatch

table

pointer)

access:

Initialized,

not

referenced.

Description:

Address of the driver dispatch table, which is located within
the
driver
code.
(When
the Executive wishes to enter the

driver at
dispatch

the entry points
contained
it
accesses D.DSP, locates
table, and calls the driver at

address

For

resident

$SxxTBL,

the

which

start

then,

vyou

indicates
D.MSK

any of
table,

the

vyour

is generated by the
driver

should

that

(driver-specific

Driver

driver,

dispatch

function

DDT$

that

macro
For

this

field

is not

the
driver
appropriate

references

table.

1initialize

the driver

code

in
the

in memory.

address.)
the

loadable

symbol

mark

the

driver,

=zero,

which

the

proper

masks)

access:

Initialized,

not

referenced.

Description:

Eight

words,

functioning
words

QIO

beginning

validate

directive.

device
and

The

D.MSK,

are

driver.

dispatch

the

following

critical

The
I/0O

Executive

request

description

uses

specified

applies

these
by

only

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER

nonfile-~structured devices.l Four masks, with two
are

mask,

establish

described

for

these words:

the

bit

configurations

words

per

that you

function mask

Legal

Control

No-op function mask

ACP function mask

function mask

The
The QIO directive allows for 32 possible I/0 functions.
masks, as stated, are filters to determine validity and I/0
requirements for the subject driver.

The Executive filters the function code in

through

the

four

The

masks.

the

function

I/0

request

1I/0

1is the

code

high-order byte of the function parameter issued with the QIO
representation of that high-order
The decimal
directive.
If
byte is equivalent to the decimal bit number of the mask.
masks,
four
the
of
one
in
true
be
to
function
the
want
you
you must set the bit in that mask in the position that
For example,
numerically corresponds to the function code.
decimal
its
and
(octal)
1is 21
IO.RVB
the code for
If you want IO.RVB to be true for a
representation is 17.
mask, therefore, you must set bit number 17 in the mask.

Each
The masks are laid out in memory in two 4-word groups.
4-word group covers 16 function codes. The first 4 words

cover the function codes 0 through 15;

cover

codes

through 31.

for the driver example

the

second

in Chapter 8.

+WORD
-WORD
.WORD
+WORD
.WORD

177477
70
0
177200
377

: LEGAL FUNCTION MASK CODES 0-15.
; CONTROL FUNCTION MASK CODES 0-15.
;sNO-OP FUNCTION MASK CODES 0-15.
;ACP FUNCTION MASK CODES 0-15.
; LEGAL FUNCTION MASK CODES 16.-31l.

+WORD
+WORD

0
377

:NO-OP FUNCTION MASK CODES 16.-31.
:ACP FUNCTION MASK CODES 16.-31.

+WORD

; CONTROL FUNCTION MASK CODES 16.-31.

The Executive filters the

words sequentially as
Legal

words

Below is the exact layout used

function

follows:

code

through

the

mask

Function Mask:

Legal function values have the corresponding bit position in
Function codes that are not legal are
this word set to 1.
rejected by QIO directive processing, which returns IE.IFC in
the I/0 status block, provided an IOSB address was specified.

1. Although no DIGITAL publication describes writing drivers for
file-structured devices (drivers that interface with F11ACP), you
could write a disk driver by using a DIGITAL-supplied driver as a
For example, the RK1l1l driver (DKDRV) is one that does not
template.
use

advanced

features.

PROGRAMMING SPECIFICS FOR WRITING AN

Control

Function Mask:

If any device-dependent data
does
not
require
further
processor,

the

function.

Such

Copy

the

DPB

function

1is

function

Function

no-op

function
as

Function

soon

bit

function

codes must

specific

corresponding

any
as

data

directly

QIO

mask

is being

converts

the

into

1If

that

value

may

bits

for a
processing

device

logical

your

that

functions,

the
the

on
the

Consider

device:

and

file

medium.

driver

Moreover,

open

specified
the file
a

is
to

the

read-write

the

device is file-structured and no file is
open
the
specified LUN, then an error is returned and
further action is taken.
the

request

device
is

Function

1is

simply

function and
block number
Transfer

the

device

function.

useful.

file-structured

function.

function are
file-oriented

logical

specific

number

logical

the
ACP

nonfile-structured

block

(ACP),
set.

option.

virtual

read-write

queued

request

on
no

is
is

not

file-structured,

transformed

requesting

task)

the

transferred

for

multiple).

buffer

then

read-write

driver.

(The

the

logical

specified

Processing:

ACP

All

the QIO directive processor to check
legality
(that is, inclusion within
addition,

queued to the
unchanged.)

Finally, if the function is not
by default a transfer function.

the

to
I/0

wvirtual

set

particularly

function

than

read-write
recognizes

must

the
specified LUN, the block number
converted from a virtual block number in

the

considered

Processor

mask

greater

read-write

bits

requested

virtual

the

Control

function

control

If the function is a
immediately marks the request
filtering occurs.

ACP

have

request

conversion

read-write

processing

issued.

Ancillary

case

directive

function

is
processing

the

mask

corresponding

This

is legal but specifies neither
a
control
a
no-op,
then
it
specifies
either
an ACP
transfer function.
If a function code requires

intervention

and

QIO directive

code

corresponding

set,

considered

allows

and this data
QIO directive

Mask:

If a function
function
nor
function or a

the

DPB,
the

Mask:

no-op, QIO directive
successful;
no additional

the
by

successful

ACP

exists in
checking

device-dependent

Packet.
Ne-op

I/0 DRIVER

the
the

and proper alignment
processor
checks
the
proper

modulus

convention,

address

and

(that

the

first

second

function,

then
it
is
functions cause
specified buffer for
address space of the

transfer

(word

number

byte).
In
bytes being

is,

nonzero and a proper
user-supplied parameter

the

byte

count.

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER
Creating Mask Words:

Creating function mask

words

involves

the

following

five

the

device

steps:

Establish the I/0 functions available on

for which driver support is to be provided.

Check the standard
Build the Legal Function mask:
in Table 4-6 for
values
mask
function
US
RSX-11M-PL
is
function
I0.KIL
the
Only
equivalencies.
used,
if
,
functions
IO.DET
and
I0O.ATT
.
mandatory
must have the RSX-11M-PLUS system interpretation..
an
having
functions
that
suggests
DIGITAL
RSX-11M-PLUS system counterpart use the

RSX-11M-PLUS

code, but this is required only when the device is to
From the
1in conjunction with an ACP.
be used
function 1list in Table 4-5, you can build
supported
the two Legal

Function mask words.

Build the Control Function mask by asking:

address
Does this function carry a standard buffer
and byte count in the first two device-dependent
parameter words?

If it does not, then either it qualifies as a control
itself must effect the
or the driver
function
checking and conversion of any addresses to the
See Section 8.3 for
format required by the driver.
(Buffer
an example of a driver that does this.
standard format are automatically
in
addresses
converted to Address Doubleword

format.)

essentially

those

functions

Control functions

are

Create the No-op
legal functions

Function mask by deciding which
are to be no-op. Typically, for

whose DPBs do not contain buffer addresses or counts.

or
(FCS)
Services
compatibility with File Control
on
(RMS)
Services
Management
Record
nonfile-structured devices, the file access/deaccess
even
functions,
1legal
as
selected
functions are
or
access
to
required
is
action
though no specific
the
thus,
deaccess a nonfile-structured device;
access/deaccess functions are no-op.

Finally, include the ACP functions Write Virtual
Block and Read Virtual Block for those drivers that
(Include only one
and write.
read
support both
related ACP function if the driver supports only read

be
Other ACP functions that might
or write).
driver
tional
nonconven
the
into
fall
included
classification and are beyond the scope of this
document.
D.PCB

(0)

Driver

access:

Initialized, not referenced.

PROGRAMMING

SPECIFICS

FOR WRITING

I/0O

DRIVER

Description:
Address

driver

data

zero.

the

The

driver's

base

DCB

Partition

source

can

code

extended

A PCB exists for every partition
describes the partition in which
The

Executive

the
driver
loadable or
memory.

the

uses

D.PCB

Control

must

Block

adding

resides.

with

D.DSP

Zero

and

nonzero

shown

values

Fiqure

for

these

two

D.PCB.

driver

PCB

address

is
1in

(the

whether
whether

The

address

after

system.

dispatch table) to determine
resident and,
1if
loadable,

meanings

the

words

together

(PCB) .

initialize

driver
it
is

pointers

have

supplied

4-4.

D.DSP:

D.PCB:

Loadable

driver,

Resident

not in

driver

memory

(not

andabm

possible)

driver,
in memory

ZK-223-81

Figure

4.4.3.1

Establishing

assist

you

masks.

The

mask

the

- Table

are

use:
in
mask

function

mandatory

and

Meanings

values

proper

given

drivers.

the

D.DSP Bit

the

word

use

and

I/0 Function Masks

values

group

value
for
through 31,

D.PCB

determining

DIGITAL-supplied

which

4-4:

The

for

bits

first
value for

mask

values
a

number
numbered 0

standard

I/0 functions.)

code

these codes
The
other
establish

you

are

other

However,
process.
writing
the

determine

devices

QIO

and

Table

directive

the

code

used

4-5,

only

However,

no-op,

IO.KIL

1is

IO.ATT

and

(Refer
a

to
the
description of

processing

not

determine

encounters

QIO assumes

that

represent Attach Device and Detach
Device,
respectively.
codes
are
suggested
but not mandatory.
You are free to

all

devices.
filtering

establish

you

15, use the mask
bits numbered 16
second 4-word group.

the

interpretation.

function

for

IO.DET are used, they must have the standard meaning.
RSX-11M/M-PLUS
I/0
Drivers
Reference
Manual
for

function

the

through

group;

1listed

fixed

function

allows

4-word

word

1is

set

1I/0

bit

the

has

each

4-5
to

function-code

the

driver

standard

the

(such

punches/readers),

for

function

proper

mask

bit

Tables

must

still

values

for

card

4-6,

values

nonfile-structured

reflect

file-structured

mask

masks

terminals,
use

words

disks,

readers,

4-7

4-22

and

4-8

device,

Table

tapes,

line
as

the

proper

vyou

must

4-5.

and

unit

printers,
guides.

record

paper

tape

;;;;;;;;;;;

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER
Table

4-5

Mask Values for Standard I/0 Functions
Bit

Mask
Value

0
1

1
2

2
3

4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

21
22

24
25
26
27
28
29

30
31

4
10
20
40
100

I1/0
Function

Related
Symbolic
IO.KIL
I0.WLB

I0.RLB
IO.ATT
I0O.DET

200

Cancel I/0
Write Logical Block

Read Logical Block
Attach Device
Detach Device
General Device Control
General Device Control
General Device Control

400
1000

I0.FNA

Diagnostics
Find File in Directory

4000
10000

I10.RNA
I10.ENA

Remove File from Directory
Enter File in Directory

40000
100000

I0.ACW
I0.ACE

2000

20000

1
2
4
10
20
40
100
200
400

1000
2000
4000
10000
20000

40000
100000

I0.ULK

Unlock Block

I0.ACR

Access File for Read

I0.DAC
I0.RVB
I0.WVB
I0.EXT
I0.CRE
I0.DEL
IO.RAT
IO.WAT
I0.APC

Deaccess File
Read Virtual Block
Write Virtual Block
Extend File
Create File
Mark File for Delete
Read File Attributes
Write File Attributes

Access File for Read/Write
Access File for Read/Write/Extend

ACP Control
Unused
Unused
Unused
Unused
Unused
Unused
Unused

PROGRAMMING SPECIFIC3 FOR WRITING AN I/O DRIVER

Mask Word

Bit

Table 4-6
Settings for

—
Disk

Drives

Bit

RSX-11M~-PLUS

0
1

c
t

I0.KIL
I0.WLB

2
3
4

t
¢
c
c

I0.RLB
I0O.ATT
I0.DET

5
p

Symbolic

I10.STC

I0.CLN

Diagnostic

9
10
11

a
a
a

I0.FNA
I0.ULK
I0.RNA

10.ENA

I0.ACR

I0.ACW

I10.ACE

I0.DAC

17
18

a
a

I0.RVB
IO.WVB

I0.EXT
I0.CRE

I0.DEL

I0.RAT
I0.WAT

I0.APC

—

25
26

28
29
30

31
t
c

transfer function, bit set only in
control function,
bit set in legal

no-op

ACP

sa
sd

special
special
driver

function,

case,
case,

bit

set

bit

set

bit
bit

set
set

only
only

legal

in
if

legal function mask
and control function masks

and

no-op

ACP

function masks

function

ACP function mask,
diagnostic support

masks

but not legal
in system and

.
S

AN I/O DRIVER
PROGRAMMING SPECIFICS FOR WRITING
Table

4-7

Mask Word Bit Settings for Magnetic Tape Drives

Bit

RSX-11M-PLUS

0
1
2
3
4
5

C
t
t
c
C
c

I0.CLN

Diagnostic
I0.FNA

sd
a

8
9

Related Symbolic
I0.KIL
I0O.WLB
IO.RLB
I0.ATT
I0.DET
I0.STC

10
11
12
13
14
15

n
a
a
a

I0.ULK
I0.RNA
I0.ENA
I0.ACR
I0.ACW
I0.ACE

I0.DAC

17
18
19
20
21
22
23
24

a
a
a

a
a

I0.RVB
IO.WVB
I10. EXT
I0.CRE
I10.DEL
IO.RAT
I0.WAT
I0.APC

25
26
27
28
29

30
31

t
c
n
a
sa
sd

transfer function, bit set only in legal function mask
bit set in legal and control function masks
control function,
no-op function, bit set in legal and no-op function masks
ACP function, bit set in legal and ACP function masks
special case, bit set only in ACP function mask, but not legal
special case, bit set only if diagnostic support in system and
driver

PROGRAMMING

SPECIFICS

FOR WRITING AN

Table

Mask Word

Bit

Settings

Bit

RSX-11M-PLUS

0
1

c
t

4
>

c
c

DRIVER

4-8

for

Unit

Record

Devices

I0.KIL
I0.WLB

I0.RLB

I0.ATT

I0.DET
I10.STC
I0.CLN

8
9
10

sd
a
a

Diagnostic
I0.FNA
IC.ULK

11
12

a
a

I0.RNA
I0.ENA

14
15

a
a

I0.ACW
I10.ACE

16
17
18

10.DAC

a
a

I0.RVB
IO.WVB

a
a

I0.EXT
I10.CRE
10.DEL

19
20
21

I10.RAT

I0.WAT

25
26

10.APC

28
29

3Ot

30
31

transfer

function,

bit

Related Symbolic

I/O

set

only

legal

function mask

control function, bit set in legal and control function masks
no-op function, bit set in legal and no-op function masks
ACP function, bit set in legal and ACP function masks
special case, bit set only in ACP function mask, but not legal
special case, bit set only if diagnostic support in system and
driver

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER

4.4.4

The Unit Control Block (UCB)

Figure 4-5 is a layout of the UCB (a variable-length
control
block).
exists for each physical device-unit generated into a system
UCB
One
For user-added drivers, this control block is defined
configuration.
as part of the source code for the driver data structure.

The fieldsl in the UCB are described below:
U.UAB

(0)

Driver

access:

Initialized,

not

referenced.

Description:

For terminal UCBs only.
It is required
only
if
accounting
support
is
on
the
system
(AS$SSCNT
1is defined) but may be
This
system.
the
on
present if accounting support is not
value
1is
wused
to
access
the
user
accounting
block
in
secondary pool.
U.MUP

Driver

access:

Not

initialized,

not

referenced.

Description:

For terminal UCBs only.
Bits 1 to 4 contain an
index
to
a
table
which
contains
the address of CLI Parser Block (CPB)
for the current CLI;
the remaining bits are used
for
other
terminal specific features and are defined as follows:
UM.OVR
UM.CLI
UM.DSB

Override CLI indicator
CLI indicator

UM.NBR

UM.CNT
UM.CMO
UM. SER
UM.KIL

Continuation of command line in progress
Command is in progress from this terminal
Terminal is in serial mode
TTDRV should tell MCR to flush all pieces

Terminal

diabled

because CLI

eliminated.

broadcast

continued

command

the

user

types

CTRL/C.

U.LUIC

Driver

access:

Not

initialized,

not

referenced.

Description:

For

terminal

logon

UIC

UCBs only,

the

offset must exist

for

which the DV.TTY bit
into

the

and

wuser

only

in multiuser

any device on a

is set.

This word

multiuser

system

the

This
for

is altered by logging

system.

Parenthesized contents fcllowing the symbolic offset

value to be

systems:

the particular terminal.

initialized

in the data base source code.
4-27

indicate

the

PROGRAMMING SPECIFICS FOR WRITING AN

U.OWN

I/O DRIVER

(0)

Driver

access:

Initialized,

not

referenced.

Description:

Only

in multiuser

terminal

U.UAB

for

0
-

U.MUP1

systems:

allocated

the

UCB

address

— =

—

User Account Block

= - 1

Multiuser flags and CLI pointer

u.Luic?

Log-on UIC

-4

U.OWN

Owning terminal UCB address

-2

U.DCB

Back pointer to DCB

U.RED

Redirect UCB pointer

ngé’

}

Unit status

Control flags

U.ST?

}

Unit status |

hystical unit no

U.UNIT

the

owning

devices.

)

“

‘

U.CW1

Characteristics word 1

U.Cw2

Characteristics word 2

U.CW3

Characteristics word 3

U.Cw4

Characteristics word 4

U.SCB

Pointer to SCB

U.ATT

TCB address of attached task

U.BUF

Buffer relocation bias

Buffer address

Byte count

U.BUF+2
U.CNT

u.uBx?

All
devices

| Pointer to the UCB extension in secondary pool | 32
Device-

dependent
S

—

storage

1. This offset appears only for terminal devices (that is, devices that have DV.TTY set)
in multiuser systems.

2. This offset appears only for those devices that have DV.MSD set.
ZK-257-81

Figure

4-5:

Unit

Control

Block

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER
(pointer to associated DCB)

U.DCB

Driver

access:

Initialized, not referenced.
Description:

This word is a pointer to the corresponding device control
Because the UCB 1is a key control block in the I/O
block.
data structure, access to other control blocks usually occurs
by means of links implanted in the UCB.

U.RED (pointer to start of this UCB
Driver

(.-2))

access:

not referenced.

Initialized,
Description:

Contains a pointer to the unit control block to which this
This field is updated as
device-unit has been redirected.
redirect chain
The
the result of an MCR Redirect command.
ends when this word points to the beginning of the UCB itself
(U.DCB of the UCB, to be precise).

U.CTL

(device-dependent values)
Driver

access:

Initialized,

not referenced.

Description:

U.CTL and the function mask words in the device control block

control

QIO

directive

processing.

layout of the unit control byte.

Figure

4-6

shows the

U.CTL

U.STS
8,7

}UC. LGH - Buffer size mask bits for transfer length
UC.KIL - Unconditional cancel 1/0 (1=vyes)
UC.ATT - Attach/detach notification {1=yes)
UC.PWF - Unconditional call at powerfail (1=yes)
UC.QUE - Queue to driver bit {1=yes}

UC.NPR - NPR device bit (1=vyes)

UC.ALG - Alignment (byte or word}{1=no)
ZK-258-81

Figure

4-6:

Unit

Control

Byte

establishes

this

bit

The driver data base code

statically

erroneous 1/0 processing.

Bit symbols and their meanings are

pattern.
as

Any inaccuracy in the bit setting of U.CTL produces

follows:

UC.ALG - Alignment bit.

PROGRAMMING

SPECIFICS

FOR WRITING AN

If this bit is 0, then
allowed.
If UC.ALG is

byte
alignment
1, then buffers

UC.ATT

notification.

this

Attach/Detach

bit

processes

driver

does

set,

and

the

driver

case,

UC.QUE

driver

Cancel

1is

Executive

to-driver

control

S$GTPKT

for
the

the

Attach/Detach
entire

function

bit.

Cancel

busy.
an

when

Typically,

driver.

I/0 call

not

I/0 only

the

Queue

Cancel
called

called

performs

the

data
buffers
is
be word-aligned.

function.

obtain

from

of
must

1is

I/0

Executive

specified

called

the

Unconditional

wunit
any

need

any assistance

UC.KIL

the

then

Attach/Detach

not

requests,

without

set,

I/O DRIVER

I/0

request,

Typically,

I/0 operation

flushes

the

I/0

the

even

driver

progress.

queue.

bit.

If set, the QIO directive processor calls the driver
at
its
I/0
initiation
entry
point without queuing the I/0 packet.
After
the
processor
makes
this
call,
the
driver
is
responsible
for
the
disposition
of
the
1I/0
packet.

Typically,
the

the

driver,

processor

which

later

queues an I/0 Packet before
calling
retrieves it by a call to $GTPKT.

The most common reason for
a
before
queuing
1is
that
the
buffer, other than the
normal
request.

driver
See

Within

must

Section

context

address-check
8.3

for

multiprocessor

form

the

I/0O

driver
driver
buffer

and

certain

processing.

received directly from the
performing
a
conditional
fork

SCFORK)

to guarantee

the

must

not

driver

process

registers.

The

merely uses

buffers

and

packets

thereby do
unless

UC.PWF

that

not

directly

need

intervening

Unconditional

the

$DRQIO

access

apply

$CFORK

power

the

driver

been

I/0

summary,
processed

I/0 page

particular

failure

the

1In

device

secondary

not

has

I/0

first
call

processor.

itself.

may

this

processor,

map

activity on

this.

correct

I/0 packet

call

does

process

correct

executed

call

the

not

that

the

buffer.

QIO processor without
operation
(that
is,

does

from

they cause

task,

special

should

context

the

restrictions

causes

restriction

then queues

unless
an

packet

task

driver

running

current

received

directly
or

the

execution

1is

requesting

such

driver

packet

Unless

the

relocate

example

systems,

to
examine
a
packet
employs a special user
used
in
a
transfer

(and

processor)

performed.

bit.

If set and the unit is on-line,
called
when
power is restored
Typically, the driver is called

when

I/O operation

the driver is
always
to
be
after a power failure occurs.
on
power
restoration
only
progress.
See the discussion in

Sections
LOAD and

4.3.6 and 4.5 of the entry points
UNLOAD and for controller and unit

UC.NPR

NPR

devjce

in
the
DDT
for
status change.

bit.

If set, the device is an NPR device.
This bit determines
format
of
the 2-word address in U.BUF (details given in
discussion of U.BUF below).

the
the

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER

UC.LGH - Buffer size mask bits

(two bits).

These two bits are used
to
check
whether
the
byte count
specified
in
an I/O request is a legal buffer modulus.
You
select one of the values below by ORing into the byte a 0, 1,
2,

Any buffer modulus valid
00
01 - Must have word alignment modulus
10 - Combination invalid
11 - Must have double word-alignment modulus

UC.ALG and

UC.LGH are

independent

settings.

NOTE

UC.ATT, UC.KIL, UC.QUE, and UC.PWF are usually
zero,
especially
for
<conventional drivers.
Every driver,
however, must be concerned with its particular values
for
UC.ALG,
UC.NPR,
and
UC.LGH.
The
driver
|is
totally responsible for the values in these bits, and
erroneous
values are likely to produce unpredictable
results.

U.STS

(0)

Driver

access:

Initialized,

not

referenced.

Description:

Refer
to
4-7 shows

contains

status

information.

Figure

U.CTL

U.STS

‘ A

device-independent

the UCBDFS$ macro definition in Appendix A.
the layout of the unit status byte.

Unused bits are reserved

for system use and expansion.

US.MDM - Marked for dismount (1mvesw?m
US.FOR - Mounted as foreign volume (Q=38.

This byte

o= mno

US.MNT - Volume is mounted {(1=no)
US.BSY - Device-unit busy (1=yes)
ZK-259-81

Figure

4-7:

Unit

Status

Byte

US.MDM, US.MNT, and US.FOR apply only to mountable devices.!

If your user-written driver services a mountable device,

Section 4.5.9 for

information on volume valid processing.
4-31

refer

PROGRAMMING

The

bit

SPECIFICS

meanings

are

FOR WRITING

I/0

DRIVER

follows:

US.BSY

set,

device-unit

busy.

US.MNT

set,

volume

not

volume

mounted

device

marked

mounted.

US.FOR

set,

foreign.

US .MDM

U.UNIT

set,

for

dismount.

(unit number)

Driver

access:

Initialized,

read-only.

Description:

This

byte

contains

the

physical

device-unit
serviced by this
device supports only a single

UCB.
unit,

wunit
number
of
the
If the controller for the
the unit number is always

Zero.

NOTE

This

not

the

number
The

from

1logical

imply
U.ST2

the physical unit number
1logical
unit
number.

zero

designation

this

where n
DB0O:

the
device
The
range of

and
this

is device-dependent.
does not necessarily

byte.

(US.OFL)

Driver

access:

Initialized,

not

referenced.

Description:
This

byte

contains

additional

information.
these
shown
USsT2

status

the

system set and clear
status extension byte
is

U.UNIT
8,7

device-independent

Different
parts
of
bits.
The layout of the unit
in Figure 4-8.

Unused bits are reserved

for system use and expansion.

US.OFL - Unit offline (1=vyes)
US.RED - Unit redirectable {1=no)
US.PUB - Unit is public device (1=no)

US.UMD - Unit attached for diagnostic s (1=yes)
US.PDF - Privileged diagnostic

—

functions only (1=yes)

|
ZK-260-81

Figure

4-8:

Unit

Status

4-32

Extension

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER
The bit meanings are as follows:
US.OFL=1

set,

the

configuration).

device

1is

(that

off-line

is,

not

This bit should be initialized to 1.

1in

the

US.RED=2

If set, the device cannot be redirected.
US.PUB=4

If set, the device is a public device.
US.UMD=10

If set, the device is attached for diagnostics.
US.PDF=20

If set, this unit can be used

for

privileged

diagnostic

function only.

U.CW1

(device-specific characteristics)
Driver

access:

Initialized, not referenced.
Description:

device
of
cluster
The first of a 4-word continuous
are
U.Cw4
and
U.CW1l
information.
characteristics
are
U.CW3
and
U.CW2
whereas
device-independent,
are
words
s
eristic
charact
four
The
nt.
depende
device-

retrieved from the UCB and placed in the requester's buffer
on 1issuance of a Get LUN information (GLUNS$) Executive

directive. It is your responsibility to supply the contents
of these four words in the assembly source code of the data
structure.

U.CWl is defined as follows. (If a bit 1is set to 1,
corresponding characteristic is true for the device.)

the

DV.REC=1

Record-oriented device
DV.CCL=2

Carriage-control device
DV.TTY=4

Terminal device.

If DV.TTY is set,

then

the

UCB

contains

extra cells (for U.LUIC, U.CLI, and optionally U.UAB).

DV.DIR=10

Directory device
DV.SDI=20

Single directory device

PROGRAMMING

SPECIFICS

FOR WRITING

I/0

DRIVER

DV.S5QD=40

Sequential

device

DV.MSD=100
Mass

Storage

device

DV.UMD=200

Device

supports

user-mode

diagnostics

DV, EXT=400

Unit

extended

22-bit

controller

DV.SWL=1000

Unit

software

write-locked

DV.ISP=2000
Input

spooled

device

DV.0SP=4000
Output

spooled

device

DV.PSE=10000

Pseudo
past

device,

the

1If

U.CW1l

this

bit

set,

the

UCB

does

not

extend

offset.

DV.COM=20000

Device

mountable

communications

FILES-11

channel

DV.F11=40000

Device

mountable

device

DV.MNT=100000

Device mountablel
U.CW2

(device-specific
Driver

characteristics)

access:

Initialized,

read-write.

Description:
Specific

storage or

your

Section

2.
may

given

user-written

4.5.9

for

exception
not

used

driver

information

device

driver

constants).?2

that,

for

working

services

volume

mountable

valid

block-structured
storage.

1In

(available

for

device,

working

refer

processing.

devices,

drivers

for

U.CW2 and

U.CW3

block-structured

devices (disks and DECtape), these two words must be initialized to
a
double-precision
number
giving
the
total
number
of blocks on the
device.
Place the high-order bits in the low-order byte of U.CW2
and
the low-order bits in U.CW3.

4-34

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER
(device-specific characteristics)

U.CW3

Driver

access:

Initialized,

read-write.

Description:

Specific to a given device
storage or constants).l

driver

(available

for

working

(device-specific characteristics)

U.CW4

Driver

access:

Initialized,

read-only.

Description:

Default buffer size in bytes.

system

command

(SET

with

1is changed by a
This word
the /BUF keyword). The value in

this word effects FCS, RMS, and many utility programs.

(SCB pointer)

U.SCB

Driver

access:

Initialized,

read-only.

Description:

This field contains a pointer to the status control block for
R4 contains the value in this word
In general,
this UCB.
when the driver is entered by way of the driver dispatch
table, because service routines frequently reference the SCB.
U.ATT

(0)

Driver

access:

Initialized,

not referenced.

Description:

If a task has attached itself to the device-unit, this

contains its task control block address.
U.BUF

field

(reserve two words of storage)
Driver

Not

access:

initialized,

read-write.

1. An exception is that, for block-structured devices, U.CW2 and U.CW3
may not be used for working storage. In drivers for block-structured
devices (disks and DECtape), these two words must be initialized to a
double-precision number giving the total number of blocks on the
device. Place the high-order bits in the low-order byte of U.CW2 and
the low-order bits in U.CW3.

PROGRAMMING

SPECIFICS

FOR WRITING

I/0

DRIVER

Description:
U.BUF

labels

two

consecutive

words

that

communication
region
between
S$GTPKT
nhontransfer function is indicated
(in
U.BUF+2,

I/0

For

transfer

words

and

the

U.CNT

receive

the

first

serve

and the
D.MSK),
3

driver.
If a
then
U.BUF,

parameter

words

from

these

two

Packet.
operations,

depends

the

initial

setting

format

UC.NPR

U.CTL.

does not format
the
words;
all
before the driver receives control.

formatting
The format

the

for

UC.NPR

bit,

which

program-transfer

set

for

NPR

The

1is
is

driver

completed
determined

device

and

reset

device.

The

format for program-transfer devices is identical to
that
for
the
second
two words of I.IOSB in the I/0O Packet.
See
Section 4.4.1 for a description of I.IOSB in the I/0 packet.

In general,
performing
uses

the

Put

Word

user's
For

the
I/O

driver
to
a

Executive

does not manipulate these
program-transfer device.

routines

effect

data

NPR

device

uses

UNIBUS

and

drivers,

these

1initiate

MASSBUS

NPR

the physical
in word 1 are

MASSBUS

device

NPR

the

memory

responsibility
go

bits.

(the

KS.MBC

registers
a

Word,

Put

the

device

Byte,

and

the

set

typical

UNIBUS

represent

what

the

operation.

For

both

word

bit

must

the
NPR

contains

the

low-order

For a UNIBUS NPR
extension
bits;
is

set),

the function

action

initiate

words

transfer

bits.

(BIS) operation so that the
The driver must move these

For

Get

between

address.
memory

extension

This

two

the

devices,

16
bits
of
bits 4 and 5

and

Byte,

buffer.

driver

are

Get

transfers

words
when
1Instead, it

bits

code,

through

the
by

driver's

interrupt

accomplished

device,
for
a

enable,
Bit

Set

extension bits are not disturbed.
words
into
the
device
control

I/0

operation.

device

driver,

the

word

layout

follows:
Word

Bit
Bits

Bits
Bits
Bits

Word

Bits

1,2,3

Go bit initially set to zero
Function code--set to zeros

4,5
6

Memory extension bits
Interrupt enable--set

through

Zero

through

Low-order

The

construction

the

requested

these

three

U.BUF,

function

words

contain

bits

U.BUF+2,

transfer

the

first

of
and

zero

physical
U.CNT

occurs

only

not,

the

1I/0

function;
three

address

words

1if

Packet.

The

details

appear

the

in Section

construction

the

Address

Doubleword

7.2.
i

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER
(reserve one word of storage)

U.CNT

Driver

access:

Not

initialized,

read-write.

Description:

Contains the byte count of the

The

buffer

described

U.BUF.

driver uses this field in constructing the actual device

request.

U.BUF and U.CNT keep track of the current data

item

1in

the

for the current transfer (except for NPR transfers).
buffer
I/0
the
altered dynamically,
Because this field is being
(for
operation
I/0
an
reissue
to
needed
be
may
Packet
instance,

after a powerfail or error retry).

U.UCBX

Driver

Not

access:

initialized,

not

referenced

Description:

contains
This field
for
pool
secondary

in
extension
UCB
the
to
pointer
a
devices with DV.MSD set,
storage
mass

(DV.MSD=1)
.

For information on formatting,

UCBDFS$

see

the

description

the

macro.

(Device-dependent words)

U.PRM

Driver

Not

access:

initialized,

read-write.

Description:

The driver establishes this variable-length block of words to

requirements.
device-specific
suit
driver uses the first words to store

disk
a
example,
For
as
geometry
disk
the

follows:

.BLKB
.BLKB
« BLKW

1
1
1

; # OF SECTORS PER TRACK
¥
;# OF TRACKS PER CYLINDER
; # OF CYLINDERS PER VOLUME

The driver can call the $CVLBN routine

(described

Chapter

to convert a logical block number to a disk address based

on the values in U.PRM and U.PRM+2.

4.4.5

The Status Control Block

(SCB)

Figure 4-9 is a layout of the SCB.

unit

operation

and

describes

parallel with all other units.

the

The SCB contains the context for a

4-37

status of a unit that can run in

PROGRAMMING

SPECIFICS

FOR WRITING

S.LHD

I/0O

Input/Output

DRIVER

—

Queue Listhead

S.URM!

Fork UNIBUS Run Mask

S.FRK

Fork Link Word
Fork PC

Fork R5

Fork R4

S.KS5

Driver/Fork KISARS

S.PKT

1/0 Packet Address

Initial Time-Out Count | Current Time-Out Count

S.CTM/S.ITM

S.STS/S.ST3

Status Extension

Status

S.5T2

Status Extension

S.KRB

KRB Address

S.ROFF 2/S.RCNT 2 |Offset to Device Registers Number of Bytes to Copy|
TM

S.EMB?

s.kTB?

Error Message Block Pointer

KRB Address 0

F--—

o o

—---—--- — - - n

KRB Address 1

KRB Address n

)

e
L

e e

2
-

If the symbols below are defined at system generation time,
the related cells marked with a number appear in the structure.

IMul*&ci;::’rc:u::esr.s.c:)r support (M$$PRO)
zAppears only if driver supports error logging
31 the system has multiaccess device support (M$$ACD)
and the driver is multiaccess (S2.MAD)
ZK-261-81

Figure

4-9:

Status

Co ntrol

The fieldsl in the SCB are described as

Parenthesized

value

contents

initialized

following
the

data

the
base

4-38

Block

follows:

symbolic offset
source code.

indicate

the

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER

(fi rst

S.LHD

Driv er

word equals zero; second word points to first)
access:

Initialized,

not

referenced.

Description:
Two

words

forming

the

I/0 queue

1listhead.

points
to
the first I/0 Packet in
word points to the last I/O Packet
queue
is
empty, the first word is
points to the first word.
S.URM

(controller
Driver

UNIBUS

The

first

word

the queue, and the second
in
the
Qqueue.
If
the
zero, and the second word

run mask)

access:

Initialized,

not

referenced.

Description:

This word appears only in a multiprocessor system
(that
1is,
1is
defined).
It
contains
a
UNIBUS run mask that
defines the
UNIBUS
run
to
which
the
«currently
assigned
controller
1is attached.
When controller assignment is made,
this cell is set from K.URM.
For the purposes of
running
a
driver
on
the
correct processor, S.URM is used exclusively
and independently of the value of S.KRB or K.URM.
If
S.KRB
is
not equal to zero, and if S.URM is not equal to K.URM (an
unusual situation), then the driver must properly handle
the
fact
that
it will run on a different processor from the one
its currently assigned KRB would
normally
warrant.
It
1is
possible
that the processor on which the driver will run has
the CSRs at a different location
from
that
stored
1in
the
MSSPRO

current

S.FRK

(reserve
Driver

KRB.

four

ADJACENCY WITH

words of

storage)

words

zero,

THE

FORK

BLOCK

ASSUMED!

access:

Initialize

not

referenced.

Description:

The four
storage

words starting
if
and
when

establish

itself

at
the

S.FRK
are
used
for
fork-block
driver
deems
1t
necessary
to

Fork

process.

Fork-block

preserves the state of the driver, which is
driver
regains
control
at
fork
1level.
automatically
wused
if
the
driver
<calls

processor also depends on the adjacency of
the required support is generated into the
S.KS5

(0)

Driver

access:

Initialized,

not

referenced.

storage

restored when the
This
area
is
$FORK.
The Fork

S.URM and
system.

S.KS5

PROGRAMMING

SPECIFICS

FOR WRITING

I/O

DRIVER

Description:

This word
contains
the
contents
of
KISAR5
necessary
to
correctly alter the Executive mapping to reach the driver for
this unit.
It has no
meaning
for
a
driver
that
1is
not
loadable.
It
is
set by LOAD, and whenever a fork block is
dequeued and
into KISARS5.
S.PKT

(reserve

Driver

one

executed, this word
ADJACENCY WITH THE

word

1is
unconditionally
Jjammed
FORK BLOCK IS ASSUMED!

storage)

access:

Not

initialized,

read-only.

Description:

Address of the current I/0 Packet established by S$GTPKT.
The
Executive
wuses this field to retrieve the I/0 Packet address
upon the completion of an I/0 request.
S.PKT is not modified
after the packet is completed.
S.CTM

(0)

Driver

access:

Not

initialized,

read-write.

Description:
RSX-11M-PLUS

supports

device

timeout,

which

enables

driver

to
1limit the time that elapses between the issuing of an I/O
operation and its termination.
The current timeout count (in
seconds)
is
typically
initialized by moving S.ITM (initial
timeout count) into S.CTM.
The Executive clock
service
(in
module TDSCH) examines active times, decrements them, and, if
they

reach

zero,

calls

the

driver

its

device

timeout

entry

point.
The

internal

Thus,

clocking

clock

time

mechanism

execution.

The

intend to treat
condition.
If
zero

value

is,

operative.
responsible
actual
S.ITM

(initial

Driver

count

operating

minimum

fact,

1in

1l-second

precise

because

asynchronously

meaningful

timeout as a
the count is
in

kept

not

clock

indication

timeout
timeout

within

$SFORK

and

that

internal

with

interval

consistently
zero, then no

The
maximum
count
1is
for setting
this
field.

increments.

the
is

driver

if you
detectable
error
timeout occurs;
a
timeout

250.
The
Resetting

1is

driver
occurs

not

|is
at

$IODON.

count)

access:

Initialized,

read-only.

Description:

Contains the initial timeout value that
into S.CTM to begin device timeout.

the

driver

can

1load

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER
S.STS

(0)
Driver

access:

Initialized,

not referenced.

Description:

(nonzero/zero).
Establishes the controller as busy/not busy
a driver as
marking
for
mechanism
interlock
the
This byte is
The byte is tested and set
busy for a specific controller.
by SGTPKT and reset by SIODON.

S.ST3

(driver-specific status byte)
Driver

access:

Initialized, referenced by driver for synchronization.
Description:

bits

This status byte is reserved for driver-specific status

concerning

driver-executive

or driver-driver communication.

Figure 4-10 shows the layout of this byte.

S.ST3

(S.STS)

S3.DRL - Multiaccess drive in released state
S3.NRL - Driver should not release drive
-S3.SIP - Seek in progress on drive

S3.ATN - Driver must clear attention bit
S3.SLV - Device uses slave units
S3.SPA - Port ‘A’ spinning up
S3.SPB - Port ‘B’ spinning up

S3.0PT - Seek optimization enabled (1 - yes)
ZK-262-81

Figure 4-10:

Controller

Status

Extension 3

The following are the descriptions for the currently
bits.

All

currently

defined

defined bits are used by mass storage

devices.
S3.DRL=1

If this bit is set, the

drive

1is

the

released

state.

support dual-access (dual-port) operation set
Drivers that
release command by the
this bit after completion of the
The Executive routines Request Controller for Control
drive.
for Data Transfer
Function (SRQCNC) and Request Controller
test this bit to decide whether the drive is in a
(SROCND)
released state and whether the Executive should attempt load
balancing by switching ports.

4-41

PROGRAMMING

SPECIFICS

FOR WRITING

AN I/O

DRIVER

S3.NRL=2

this

bit

set,

This bit exists
to
debug
the
(dual-port)

driver

does

not

solely for DIGITAL
driver.
Drivers

operation

examine

release

the

drive.

to maintain the device and
that
support
dual-access

this

bit

and,

set,

not issue the release command to the drive and do not set the
S3.DRL
bit.
If
this bit is set, reconfiguration dual-port
activity (that is, port on-line and off-line operations) will
not

function

properly.

S3.SIP=4

If this bit
driver that

bit to
driver

seek
1in
operations

©progress.
A
examines this

keep track of whether the drive
1is
seeking.
that
does not support overlapped operations

support

bit

is set, the drive has
a
supports overlapped seek

error

1is

set

logging

(that

indicate

is,

that

cassette

and

positioning

For
a
but does

magtape),

operation

this

progress.

S3.ATN=10

This

bit

used

only

MASSBUS

devices.

The

Executive

common interrupt module DVINT checks this bit;
if it is set,
then the driver must clear the attention bit in the Attention
Summary
Register.
If
this
bit
1is
not set, DVINT itself
clears

the

attention

bit

the

Attention

Summary

S3.SLV=20

If this bit is set,
the
device
connects
to
slave
units.
Certain
devices,
such as magnetic tape controllers attached
to a MASSBUS controller, can in turn have units
attached
them.
These units are referred to as slave units.
Thus,

this bit is set, the SCB describes
slave units can be attached.

tape

controller

to
if

which

S3.SPA=40

this

bit

set,

port

A on

this

unit

spinning

up.

set,

port

B on

this

unit

spinning

up.

S3.SPB=100

this

bit

S3.0PT=200

If this bit is set, seek optimization
1is
enabled
for
this
device.
SGTPKT
uses
this
bit
to
determine
whether
optimization is to be used.
An MCR SET command can
set
and
clear
this bit.
If you select seek optimization support for
a Digital-supplied device during
system
generation,
SYSGEN
sets
this
bit in that device SCB when it creates the cdevice
data

S.ST2

base

(controller

Driver

structures.

status

extension)

access:

Initialized.
Description:

This status word defines certain status
conditions
controller-unit combination.
Figure 4-11 shows the
this word.
4-42

for
the
layout of

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER

8,7

[ T 1 forovecem ves and oxpancion.
| L S2.EIP- Error in progress (1 = yes)

|
L]
HERERNR
‘ A ‘ + ‘ f

S2.ENB - Error logging enabled (0 = yes)
$2.LOG - Error logging supported (1 = yes)
S2.MAD - Multiaccess device (1 = yes)
S2.LDS - Load sharing enabled (1 - yes)

S2.0PT - Device supports seek optimization (1

yes)

yes)
S2.CON - Contiguous KRB/SCB allocation (1
- Indicates the type of optimization used
S2.0P1
S2.0P2 - Indicates the type of optimization used
yes)
S2.ACT - Driver has operation (I/0) active (1
ZK-263-81

Figure 4-11:

Controller Status Extension 2

those
DIGITAL has attempted to restrict bits in this word to
and
driver
for
bits
Specific
status.
defining system-wide

Executive synchronization or driver internal synchronization
are allocated from S.ST3. The following are the descriptions
for the currently defined bits:

S2.EIP=1

This bit is reserved for DIGITAL error logging routines.
S2.ENB=2

This bit is reserved for DIGITAL error logging routines.
S2.L0G=4

This bit is reserved for DIGITAL error logging routines.
S2.MAD=10

This bit indicates the presence of the table of KRB addresses
If this bit is set,
the end of the Status Control Block.
at
KRB
a
has
SCB
the
the device is a multiaccess device and
KRBs of the controllers
the
to
pointers
containing
table
capable of accessing

the device.

S2.LDS=40

This bit enables and disables load

sharing

for

dual-access

If this bit is set, the Executive may dynamically
devices.
assignment when
switch ports and therefore alter controller
this bit is not
1If
driver.
a
for
path
access
an
g
establishin
enabled, the Executive does not alter the current controller
controller
static
permits
feature
This
assignment.
assignment, perhaps for diagnostic operations.

Devices (such as terminals)

with S2.LDS

clear

that explicitly manage controller assignment.

have

drivers

S2.0PT=100

If this bit is set, this device supports queue

optimization.

determines whether to call the
$DRQRQ,
by
used
bit,
This
block check and convert the LBN routine in the driver.

4-43

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER

S5S2.CON=200

This

bit

indicates

the

continuous

allocation

the

refer

controller
request
and status control blocks.
Devices that
do not support overlapped operation do not require a separate
SCB
for
each unit.
The KRB and SCB for such devices can be
contiguous and some fields in the SCB overlap
those
1in
the
KRB.
Therefore,
the
SCB
offsets S.CSR, S.PRI, S.VCT, and
S.CON are valid only for such devices.
For
these
devices,
S2.CON

set.

For the layout of
Section

the

contiguous

KRB

and

SCB,

4.4.7.

52.0P1=400
S2.0P2=1000

These bits indicate the type
of
optimization
selected
for
this
device.
An
MCR command can set and clear these bits.
These two bits give you three options of queue
optimization.
They are

follows:

s2.0pP2,S2.0P1 =
S2.0pP2,S2.0P1 =

0,0
0,1

Nearest cylinder
Elevator

s2.0pP2,82.0P1

1,0

CSCAN

s2.0pP2,S52.0pP1

1,1

Reserved

S2.ACT=2000

If this bit
S.KRB

(pointer
Driver

is set,

the driver has active I/O0.

currently assigned KRB)

access:

Initialized,

referenced

by driver

access

the

KRB.

Description:

This

word

points

the

currently assigned

controller

block.
For non-multiaccess devices, it is set
generation and never altered.
For multiaccess
load-sharing
enabled, it may take on the value
KRB pointers in the KRB table, S.KTB.
If
this
value of zero, then the device has no currently
It may, in fact, not have a KRB or CTB at all.
driver and virtual terminal driver have no KRB.

request

during system
devices
with
of one of the
word
has
a
assigned KRB.
Both the null

Certain restrictions apply to drivers whose data bases do not
include
KRBs.
They
will
receive
powerfail, timeout, and
cancel calls like any other driver,
but
the
priority
will
always
be
zero,
and
the
CSR address and controller index
(where supplied) will be undefined.

NOTE

All

code

has

that checks

S.KRB for

KRB

pointer

must

check
for a possible zero value and take appropriate
action.
A zero value in S.KRB does
not
necessarily
mean
that
a
KRB does not exist, but perhaps rather
that one is not currently assigned.
A
device
which
KRB will

not

have

4-44

S2.CON

set.

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER

The first cell

in the KRB

(K.CSR)

contains

the

control

and

The offset
status register (CSR) address for the controller.
K.CSR will always be zero so that the
pointer
(S.KRB)
will
always

connect

directly

the

cell

the CSR

containing

address.

S.ROFF

S.«.RCNT

S.EMB

This byte is reserved for devices that support DIGITAL
typically

zero.

This byte

for devices that support DIGITAL

error

This word

is reserved for devices that support DIGITAL

error

reserved

logging
software.
It represents the minimum number of words
of I/0 page registers that this device has.
logging

software.

(KRB

addresses)

Driver

access:

S.KTB

error

This value is an offset from S.CSR/K.CSR
software.
logging
to indicate
the
start
of
the
device
registers.
It
is

Initialized,

not

referenced.

Description:

This table appears only if the system has multiaccess
device
support
(MSSACD
is
defined)
and the device is multiaccess
(the

S2.MAD bit set).

Every controller to which the unit

(unit

control

block

and

is
can communicate
combination)
block
control
status
block
request
controller
by a
table
represented in this
table contains at least two entries, with the
The
address.
For devices with executive
list terminated by a zero word.
load sharing supported (S2.LDS set), bit zero of each word is

an on-line and off-line flag which, when set, indicates
that
with respect to this SCB and should not be
off-line
1is
KRB
S2.LDS
Devices with
considered for controller assignment.
clear
have
drivers
that
explicitly
manage
controller
assignment.
Only the driver may change S.KRB, and it may
or
use the low-order bit of the KRB addresses in S.KRB
may not
as an on-line and off-line
flag.
When
drivers
explicitly
manage controller assignment, system software (other than the
driver) must not modify S.KRB and must tolerate a
1
1in
the
low-order bit of the values

4.4.6

The Controller Request Block

Figure 4-12 is a layout of the

exists

for

each controller.

in S.KTB.

(KRB)

«controller

request

block.

One

KRB

a controller allows only a single

operation on a single unit at a time, then the driver can allocate the

request block and the status control block in continuous
controller
such continuous allocation, all offsets commonly used by
With
space.
The system will still
the driver are referenced by their S.xxx forms.
Refer to
references.
all
for
forms
K.xxx
the
and
S.KRB
use the offset
Section 4.4.7 for the continuous SCB/KRB allocation.

PROGRAMMING SPECIFICS FOR WRITING AN I/0 DRIVER

Driver dependent storage

K.PRM

K.VCT3/ K.PRI®

Vector/4

Priority

K.IOC/K.CON?3

Controller 1/0O count

Controller index

K.STS

Controller status

K.CSR?

Control and status register address

K.OFF

Offset to UCB table

-2

K.HPU

Unused

K.OWN.

Owner (UCB address of unit owned)

K.cRQ!

Controller request queue listhead

K.URM
;2

—4

l Highest physical unit

Controller UNIBUS run mask
e

W——

—

——

o———

22-bit
Working

Storage
Area

KE.RHB

11/70 UMR/RHBAE offset

Start of UCB table
UCB address physical unit 0
®

°
®

UCB address physical unit n
-1

1| contiguous allocation of KRB and SCB is used (that is, if S2.CON is set), this field overlaps the 1/O request queue.
2 This field is for multiprocessor support (M$$PRO is defined).
3 This area is for 11/70 extended memory support (M$$EXT is defined).
The area extends in a negative direction from the start of the UCB Table.

4 1f KS.UCB is set, then this table appears (allows overlapped function interrupts).

5 The S.xxx forms of these offsets are valid only for devices that perform a single operation on a

controller at a time. For such devices, S2.CON is set and the SCB and KRB are allocated in a contiguous area.

See Figure 4-7 for the contiguous SCB/KRB structure.

ZK-264-81

Figure

4-12:

Controller

Request

Block

The fieldsl in the KRB are described as follows:

l. Parenthesized comments following
value to be initialized in the data

the symbolic offset
base source code.

4-46

indicate

the

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER
(device-dependent storage)

K.PRM

Driver

access:

Initialized,

read-write.

Description:

LOAD does not relocate any addresses in this area.
(device priority)

K.PRI

Driver

access:

Initialized,

read-only.

Description:

Contains the priority at which the

values

symbolic

device

interrupts.

Use

(for example, PR4) to initialize this field

These symbolic wvalues are
in the driver data source code.
defined by issuing the HWDDF$ macro (refer to the sample data

base in Chapter 8 and to the listing of the HWDDF$ macro).
K.VCT (interrupt vector divided by 4)
Driver

access:

Initialized, not referenced.
Description:

Interrupt vector address divided by 4.

Because you

can

use

the CON task to change the vector value, you need not be
overly concerned with initializing K.VCT to the correct
If K.VCT equals zero, then neither LOAD nor UNLOAD
value.
In particular, LOAD does not create
takes any vector action.
any interrupt control block linkage for this KRB.
K.CON

(controller number times 2)
Driver

access:

Initialized,

read-only.

Description:

Controller number multiplied by 2.

Drivers that support more

A driver may use K.CON
than one controller use this field.
in the driver data
created
table
controller
a
into
index
to
base source code and maintained internally by the driver
itself. By indexing the controller table, the driver can
service the correct controller when a device interrupts.
Because this number is an index into the table

the

L.NUM

CTB,

that

its

CTB.

maximum

addresses

value is limited by the value of

PROGRAMMING

K.IOC

SPECIFICS

FOR WRITING

I/O

DRIVER

(0)

Driver

access:

Initialized,

not

referenced.

Description:

This

an I/O count used by the system to keep track of
how
the
controller is.
The value is related to the number
outstanding requests queued for this controller.
This
is
weighted number to be used only by the system to judge the

busy

of
a

relative
K.STS

activity of

(controller-specific

Driver

one

controller

with

respect

word

that

another.

status)

access:

Initialized,

not

referenced.

Description:

This

word

used

controller.
status

Figure

status

4-13

shows

the

layout

8,7
l

the

controller

(1 = yes)

15
l

the

word.

K.STS

concerns

A |

Unused bits are reserved

for system use and expansion.

KS.OFL - Controller offline

KS.MOF - Controller marked for offline

KS.UOP - Supports overlapped operation

KS.MBC - Device is a 22-bit MASSBUS controller
KS.SDX - Seeks allowed during data transfers
KS.POE - Parallel operation enabled

KS.UCB - UCB table present
KS.DIP - Data transfer in progress
KS.PDF - Privileged diagnostic functions only
KS.EXT - Extended 22-bit UNIBUS controller

KS.SLO - Controller is slow coming online
ZK-265-81

All

Figure

4-13:

undefined

bits

Currently

defined

Controller

are

bits

Status

reserved

Word

for

use

DIGITAL.

this

bit

to
place
place the

are:

KS.0FL=1

The

Executive

reconfiguration routines
controller
off-line
and
clear

the

controller

on-line.

KS.PDF

denote

assign
no

other

with

the

unit

on-line

IE.OFL

The

the

1is

controller

error

and

entry point

The

data

code

and

1in
If

this

found),

return

to get

should

wused

states.

controller

initiation
driver

bit

transition

set
the

conjunction
request

KS.OFL

the

made

request

the

new packet.

initialize

this

bit

with

made

set

(and

terminates

driver

I/0

PROGRAMMING SPECIFICS FOR WRITING AN I/0 DRIVER
KS . MOF
=2

If this bit is set, the unit/controller is in the process

becoming offline.
KS.UOP=4

This bit indicates whether the controller supports unit
operation in parallel and requires synchronization. If this
bit is set, each unit attached to the controller is capable
Therefore, the KRB contains a
of operating independently.
UCB table holding the UCB addresses of each independent unit.
KS.MBC=10

If this bit is set, the device is a 22-bit MASSBUS controller
and does not use UNIBUS mapping registers (UMRs) but has 2
If these
extra registers to describe a 22-bit address.
registers exist, the offset to the first of them (RHBAE) is
in the cell KE.RHB. These registers can be found by using
the contents of KE.RHB in conjunction with the contents of
S.RCNT. The Executive on-line reconfiguration code calls the
common interrupt controller status change routine (in the
module DVINT) which dynamically sets or clears this bit
during controller processing.
KS.SDX=20

If this bit is set, the controller allows seek operations to
(Some
be initiated while a data transfer is in progress.
ed
overlapp
support
RKO07,
and
types of disks, such as the RKO06

seek

operations but do not allow a seek to be initiated if a

data transfer is in progress.) The Executive routines Request
and Request
(SRQCNC)
Function
Control
for
Controller
Controller for Data Transfer ($SRQCND) examine this bit to
distinguish between the two types of controllers that support
overlapped

seeks.

KS.POE=40

1f this bit is set, the driver may initiate an I/O operation
on the controller in parallel with other I/0O operations. A
driver that supports overlapped seek operations checks this

bit to decide whether it should attempt to perform an I/0
operation as a seek phase and then a data transfer phase
(that is, overlapped) or as an 1implied seek (that is,
nonoverlapped). If this bit is set, the driver can then
attempt the overlapped operation.

An overlapped driver must check this bit once only
bit

can

was attempting a seek operation.

The

driver

operation.

Because

for

each

be reset by system

this

I1/0

commands at any time, the driver must not rely on the bit
value to decide whether, upon being interrupted, the driver
the
S2.SIP bit to hold its internal state.

must

use

KS.UCB=100

unit control
This bit indicates the presence of the table of
bit is set,
this
If
KRB.
the
with
block addresses associated
the
K.OFF gives the offset from the beginning of the KRB
start of the UCB table.

PROGRAMMING

Devices

that

overlapped

the

unit

set,

UCB

support
seeks)

UCB

table

parallel

may
regardless

I/0O DRIVER

parallel

mechanism

exist.

still

1If

exist

for

KS.UOP

require
determine

whether

KS.UOP

set.

whether

not

set,

unit

synchronization.

UCB

KS.UOP

UCB

1is

however,

devices

full

the

example,

the

some

support

used

because

not

(for

finding

Therefore,

multiplexers)

operation

interrupt.

must

may

but

unit
an

terminal

K5.UCB

FOR WRITING

require

generating

example,

SPECIFICS

(for

operation

Therefore,
table

exists,

KS.DIP=200

this

that

bit

set,

supports

bit

to
indicate
interrupt
module

transfer

bit.
to

Usage

data

overlapped

progress.
sets

is in
operation

itself
and
DVINT
whether,

progress.

transfer
seek

this

access

the

device

operation

was

The

bit

driver

eliminates

registers

the

after

must

the

A driver
clears this

Executive

common

interrupt,

set

need

for

determine

data

c¢lear

the

this

software

what

type

progress.

KS.PDF=400

This

bit

status

and

one

software

KS.OFL

the

accesses

on-line,

and

bit

indicate

controller.

both

transition

The

bits

the

reconfiguration

Executive

reconfiguration

describe

the

status

the

device

off-line,

controller.

KS.EXT=1000

this

and

bit

does

registers

exist,

set,
wuse

UNIBUS

offset

These

KE.RHG

the

describe

the

KE.RHB.

is
not

22-bit

the

registers

conjunction

22-bit

mapping

address.

first

can

with

them

found

the

UNIBUS

registers

has

these

(BAE)

using

contents

controller

but

extra

registers

the

cell

contents

S.RCNT.

KS.S5L0=2000

this

bit

extended

set,

time

out

If
this
bit
online/offline
K.CSR

(controller

Driver

the

controller

feature

1is
not
set,
immediately.

status

the

requires

the

wuse

reconfiguration

controller

the

subroutine.

will

transition

address)

access:

Initialized,

read-only.

Description:

Contains
for
the

the address of the
device controller.

Control and Status Register (CSR)
Because you can use the CON task

to change the CSR value, you need
with
1initializing
K.CSR
to
the
uses

K.CSR

indexing,

initiate

other

are located in
CSR;
it need

The
a

Executive

controller

memory

trap,

1I/0

registers

the

I/0

only

operations

that

the

are

address

the

This
member of

(If

software

probes

K.CSR

will

4-50

not

concerned
The driver
access,

device

and

the

need
device's

probing

controller

overly
value.

and

page.

reconfiguration
on-line.

not
be
correct

not
be
register

K.CSR

yields
brought

the

set.

bring

nonexistent

on-line.)

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER
NOTE

the
for
zero
offset
This word is qguaranteed to be
an RSX-11M-PLUS
that
means
assignment
This
KRB.

driver can access the CSR by the reference @S.KRB and
need not use a separate register.

K.OFF (offset in bytes (from K.CSR) to start of UCB table)
Driver

access:

Initialized,

referenced by interrupt dispatch code.

Description:

This word contains the offset to the beginning

the

wunit

When added to the starting address of
table.
block
control
The UNIBUS mapping
the KRB, it yields the UCB table address.

start of

work

the

area extends in a negative direction from the

UCB table.

The status bit KS.UCB may be used to determine whether the
A UCB table may exist if KS.UOP is not
UCB table exists.
set, since some devices (for example, terminal multiplexers)
no
with
parallel
in
operation
unit
full
support
If KS.UOP is set, a UCB table must
synchronization required.
(and KS.UCB will

appear

K.HPU

also be set).

(highest physical unit number)
Driver

access:

Initialized.

Description:

This byte contains the value of

number
K.OWN

used on this controller.

the

physical

highest

unit

(0)

Driver

access:

Initialized,

referenced

for actual

unit.

Description:

This word has three slightly different uses, depending on the
particular device.

For controllers which always have only a single unit
the 1line printer),
(for example,
connected to them
You
K.OWN/S.OWN always points to the UCB of that unit.
to
macro
GTPKTS
the
in
argument
suc
the
use
can
statically initialize this cell in the data base.

For controllers that may have multiple units attached but
do not support unit operation in parallel (for example,
the RK05), K.OWN/S.OWN is set with the currently active
unit by code generated with the GTPKTS macro suc argument
set

to blank.

PROGRAMMING

For

SPECIFICS

controllers

and
require
busy/nonbusy

support

interlock

controller

and

that

WRITING

1is

busy

UCB
for

for

unit

synchronization

contains the
This is true
set

FOR

I/O

DRIVER

operation

(KS.UOP

the

set),
controller.

data

transfer,

address of the
currently
RH disks such as the RP06.

cleared

the

Request

parallel

this

a
the

this

word

active
unit.
This word is

Controller

for

Access
(SRQCNC),
Request
Controller
for
Data
(SRQCND), and Release Controller (SRLCN) routines.
K.CRQ

(first

word

equals

second

word

points

Control

Access

first)

Driver access:
Initialized,

not

referenced.

Description:
Two

words

are

that

queued

controller

control

(controller

Driver

the

controller

for

access.

driver

Driver

functions

those that
end of the
K.URM

form

here

request

wait

queue.

©processes

processes

are

queued

access

for

data

that

the

run

have

request

front

transfer

blocks

requested

access

the

are

list.

UNIBUS

Fork

that

for

list,

queued

and

the

mask)

access:

Initialized,

not

referenced.

Description:

This word
MSSPRO is
It

contains

which

the

is made,
there.
Table

UCB

Driver

appears only
defined).
a

UNIBUS

controller

run

mask

the

cell

is moved

word

should

(offset

that

attached.

This

addresses

multiprocessor

into

not

from

system

defines

When

S.URM

zero.

K.CSR

the

(that

UNIBUS

controller

for

K.OFF

the

is,

run

assignment

fork

block

bytes)

access:

Initialized,

referenced

interrupt

dispatch

code.

Description:

This table contains the unit control block addresses for
the
units on this controller.
Physical unit zero is in the first

word,

unit

one

n+l.

The

table

of zero
which

in
no

terminated

has

the

second

length

this
by

word,

and

unit

(K.HPU(R?)+1l)

words.

table indicates a physical
unit
number
actual
physical
wunit
exists.
The
table
a

-1.

NOTE

This

table

KS.UCB

set.

exists

only

for

those

devices

that

word

A value

have

for

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER

KE.RHB

(reserve appropriate amount of

storage)

The UNIBUS mapping register work area extends in
a
negative
direction
from
the
start
of the unit control block table.

This work area always appears if the device is an NPR device.

For
devices with either KS.MBC or KS.EXT set, the first word
is used as the BAE offset
for
the
controller.
This
word

added to the CSR address
when
that,
offset
the
is
value
contained in K.CSR, yields the address of the BAE register on
the

controller.

device controller

4.4.7

both

KS.MBC and KS.EXT are clear,

the

uses UMRs.

Continuous Allocation of

the

SCB

and KRB

In a configuration where a controller and the Executive supports
only
a
single
operation
on
a
unit at one time, the driver can allocate
space for the KRB and the SCB in a continuous area.
Some
fields
of
the
KRB
overlap
those in the SCB.
Although the KRB and SCB in this
arrangement are contiguous, the system still considers
the
1I/0
data
structure
to
contain
a
KRB.
The
system will still use the S.KRB
offset and the
K.xxx
forms
for
all
references.
The
driver
can
reference
the
fields
by
the
S.xxx
form
of
the
symbolic offset
definitions.
1In such a case, although the physical offsets may differ
between
RSX-11M and RSX-11M-PLUS systems, correct referencing of many
locations on both systems is eased.
Figure 4-14
shows
the
physical
layout of the continuous KRB and SCB allocation.

4.4.8

Controller

Figure

4-15

is a

Table

(CTB)

layout of the

controller table.

You ensure

that

the

CTB is linked into the system list of controller tables by placing the
CTB macro immediately before the allocation of the
L.LNK
word.
The
CTB
macro
generates
a global symbol that links the user-written CTB
into

the

system list.

4-53

PROGRAMMING SPECIFICS

SCB

KRB

Offsets

Offsets
K.PRM

FOR WRITING AN

Driver-dependent storage

S.VCT/S.PRI

K.VCT/K.PRI

Vector/4

S.CON

K.IOC/K.CON

Controller 1/0O Count

S.CSR

I/O DRIVER

| Priority

— 6

Controller index

—4

K.STS

Controller status

K.CSR

Pointer to CSR

K.OFF

- 2

Offset to UCB table

K.HPU

Unused

Highest physical unit

K.OWN

Owner UCBV

S.LHD

K.CRQ

Input/output queue listhead

S.URM!

K.URM!

}-q—

A—

—

——

Fork URM

—

———

S.FRK

———

A—

——

—

14
——

Fork Link
Fork PC

Fork R5

Fork R4

KISARS
1/O packet address

S.KS5

S.PKT
S.CTM/S.ITM

Initial Time-Out Count | Current Time-Qut Count

S.STS/S.ST3

Status Extension

Status

S.ST2

Status extension

S.KRB

KRB address

22-bit
Working

Storage
Area
KE.RHB

Start of UCB table

11/70 UMR/RHBAE offset
UCB address physical unit 0
*
®
*

UCB address physical unit n
-1

IThis field is for multiprocessor support (M$SPRO is defined).
ZK-266-81

Figure

4-14:

Continuous KRB/SCB Allocation

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER

r—-—-——-=----=-=-=-=- ]
8-word

L.CLK

‘

Clock

Block

L.ICB

Link to first ICB

-2

L.LNK

Link to next CTB

L.NAM

Generic controller name

L.DCB?

DCB address

L.STS/L.NUM

Controller status

L.KRB?

lNumber of KRB addresses|

KRB address O

6
10

KRB address n

' The head of the list of controller tables is $CTLST in SYSCM.
21f LS.CIN is set, this cell points to the common interrupt
address table rather than to the DCB.

3See Table 4-10 for label XXCTB.

ZK-267-81

Figure

4-15:

Controller

Table

The fieldsl in the CTB are described below:
L.CLK

Driver

access:

Initialized
Description:
This

L.ICB

the

clock

single

<clock

appears

(reserve one
Driver

Not

LS.CLK
word

queue

block

entry

per

for

generic

these

devices

controller

that

type.

need

only

indicate

the

set.

storage)

access:

initialized,

not

referenced.

1. Parenthesized contents following the symbolic offset
value to be initialized in the data base source code.
4-55

PROGRAMMING SPECIFICS FOR WRITING AN I/0 DRIVER
Description:

This
this

word points to the first
interrupt
type
of
controller.
It is a link

any

system
I

distinct
local
must

for

ICBs

each

and

must

space

pool

leave

since

mapped

other

than

each

system,

pool

has

its

the

linkage

Executive

kernel

Since

usual

area.

they must

processor

KISARO.

the

block
for
an address.

executable

multiprocessor

processor,

executable
enter

own

mapping, the upper 4 bits encode a processor number
be used to enter $SK6TAB,
and
the
1lower
12
bits
address that has been shifted right once.
On other

which may
form
an
than an I

and

bits

space

multiprocessor

considered
right once.
L.LNK

the

and

control
and not

1link

Driver

part

the

CTB

system,

address,

the

which

upper

has

four

still

are

been

shifted

1in
the
system
are
found, and they are threaded
link terminates this list.

1linked
through

1list)

access:

Not

initialized,

not

referenced.

Description:
All

of
the
controller
together
so they can be
this first word.
A zero

CTB

must

exist

for

tables

every

physical

controller

type

the

system.

L.NAM

(2-character

Driver

ASCII

device

name)

access:

Initialized,

read-only.

Description:

This 2-character ASCII string is the controller mnemonic used
to
find
this
controller table from among all the others in
the system.
For the RH11/70 controller, it is RH instead
of
DB,

DS,

L.NAM

the
L.DCB

(DCB

DR,

must

device

address

Driver

MM,

unique

control
or

throughout

the

system,

unlike

D.NAM

block.

address

common

interrupt

table)

access:

Initialized,

not

referenced.

Description:
The
and

DCB pointer is used to reach the
device
control
block,
thereby the unit control block and driver dispatch table

for

block

the

driver.
that

1If

holds

interrupt

LS.CIN
the

common

dispatch

set,

L.DCB

interrupt

routine

the

1is

addresses
of
the DCBs
interfaces).
This block

interrupt

and

shown

Figure

pointer
(the

Executive),

addresses
(the
this controller

table

address

and

the

DCB

for the devices that
is called the common

4-16.

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER
CIL.CSR

Controller CSR Test Entry

CI.LKRB

Controller Status Change Entry

CIL.PWF

Powerfail Entry

Common Interrupt Address

DCBO

»
»

DCB n

n+2

n+4

1 If LS.CIN is set, L.DCB in CTB points to this structure
instead of to the DCB.

ZK-268-81

Figure 4-16:

Common Interrupt Table and Table of DCB Addresses

ller
The powerfail entry at offset CI.PWF and the contro
status change entry at offset CI.KRB are addresses of
routines built into the Executive and are used instead of the
entries in a particular driver dispatch table. This allows
devices that have no DCB (for example, the interprocessor
timer) to still participate in
sanity
and
interrupt
reconfiguration.

At offset CI.KRB is the address of a routine built into the
Executive for multidriver controllers such as the RH type.
This routine should set or clear the KS.MBC bit to indicate
whether the device is connected to an RH11l or an RH70. The

driver checks the KS.MBC bit to determine which addressing
format to use. If the value at CI.CSR is zero, the Executive
¢to
on-line routines check the existence of a device attached the
this controller by probing the address at K.CSR. If 1into
value is nonzero, it is the address of a routine built
the FExecutive to check device presence. Instead of probing
the address at K.CSR, the Executive on-line code calls this

routine, which returns either with the C bit clear if the
device is present or with the C bit set if the device is not
present.

The common interrupt table may have only the common interrupt
address in those cases 1in which a DCB does not exist (for
example, the IIST). If LS.MDC is clear, then only one DCB

(The zero termination is still necessarye.)
address exists.
If LS.MDC is set, then more than one DCB address is possible;

space should be left for all possible DCB
therefore,
addresses (for LOAD) and the table terminated by a zero,

followed by a -1. Empty entries in this case are indicated
by a zero word. LOAD will then enter the DCB addresses into
the table when it loads data structures for drivers.

4-57

PROGRAMMING SPECIFICS FOR WRITING AN 1/0 DRIVER
L.NUM

(number

Driver

KRB

addresses)

access:

Initialized,

read

only.

Description:
Used

programs

that

scan

the

the number of KRB addresses.
without
controller
request
controller

The

maximum

value

whether

the

driver

value
drivers

must

less

LOAD,

(generic

Driver

L.NUM

the

1loadable.

compute

type

For

device

common

(decimal).

For

drivers

and

interrupt

be
1less
than
17
(decimal).
drivers loaded by MCR LOAD, the

and

than

depends

1is

never zero, since
should
be
no

1loaded

For
value

VMR

the

data

base

table status bits give information
about
controllers.
Figure 4-17 shows the layout of

the
this

the

wvalue

base is loadable
is resident.
L.STS

for

the

resident

tables

table.

devices,

controller

This value is
blocks
there

controller

must

and

less

than

129

(decimal)

the

status)

access:

Initialized,

read

only.

Description:

The

controller

class
byte.

L.STS

L.NUM

15
[

(1 = yes)

8
[

Unused bits are reserved

for system use and expansion.

‘

LS.CLK - Clock block allocated

LS.MDC - Multidriver controller
LS.CBL
- Clock block linked into clock queue
LS.CIN - Controller uses common interrupt address table

LS.NET - DECnet device
ZK-269-81

Figure

The

4-17:

following

are

Controller

the

Table

descriptions

Status

Byte

these

bits:

LS.CLK=1

this

bit

set,

block.

the

controller

table

has

8-word

clock

LS.MDC=2

this

the

bit

set,

associated

multiple

drivers

service

units

attached

controller.

LS.CBL=4

this

queue.

bit

set,

the

clock

block

linked

into

the

clock

PROGRAMMING SPECIFICS FOR WRITING AN I/0O DRIVER

LS.CIN=10

this bit

interrupt

is set,

the driver

controller

and

is associated

must

have

vector.
The driver is therefore called at
point
only
for
unit power failure.
The
CI.PWF entry point in the common interrupt
controller
power
failure
recovery.
In
L.DCB does not point to the device control
to the common interrupt entry table in the
L.KRB

(KRB addresses of
Driver

with

common

exactly one interrupt

the
D.VPWF
entry
Executive uses the
entry
table
for
addition, the cell
block
but
rather
Executive.

controllers)

access:

Initialized

once

for

the

controller,

not

referenced.

Description:

A list of the controller request block addresses
ordered
by
their
respective system-wide controller numbers.
This table
is indexed by the controller index retrieved from the PS word
immediately
after
an
interrupt.
The
table
1is of length
(L.NUM(R?)) words.
While the
interrupt
routines
will
not
have
to
scan
the list in a linear fashion, the only way to
find all the controller request blocks in the system includes
a
linear
scan
of
all
the
controller tables.
The CTB is
static.
The address of the start of the KRB address list in
the
CTB
is
the
global
symbol
$xxCTB in the driver dispatch table,
where
xx
are
the
characters
comprising
the
controller
mnemonic.
Because LOAD supplies this address in the DDT when
it loads the driver, a loadable
driver
should
not
specify
this address in the DDT.

NOTE

KRB address of zero indicates a controller
specified
during
system generation with no
units.
No
controller
request
block
for

controller

that

was
attached
such
a

generated.

Proper action
for
drivers
to
access
their
1list
of
KRB
addresses
1is to retrieve the address of the start of the KRB
list in the CTB from the cell in the
driver
dispatch
table
set

4.5

DRIVER CODE

LOAD

(both

VMR and

MCR).

DETAILS

This section describes the specific requirements for driver code.
The
driver
code
must
contain
a
driver dispatch table which allows the
Executive to call the driver to perform discrete system functions.
If
the
driver
needs
to
access
either
system
structures such as the
partition and task control blocks or structures within
1its
own
data
base,
it
should use the system-wide symbolic offsets rather than the
real offsets.
Because the driver is DLuilt with the Executive
1library
EXELIB.OLB,
the
symbolic
offsets
are automatically defined for the
driver code.
If you want to see the definitions
of
the
symbols
1in

PROGRAMMING SPECIFICS FOR WRITING
AN I/O DRIVER

your driver listing, place in your
driver
source
code
the
related
macro
name
in
a
.MCALL
directive and invoke the macro.
(For your
convenience, the source code
of
the
macro
calls
that
define
the
symbols
of structures is in Appendix A.) The detailed descriptions of

the driver data base structures are

4.5.1

Driver

Dispatch Table

in Section 4.4.

Format

The driver
dispatch
table
associates
the
entry
points
that
the
Executive
expects to find in a device driver and the actual locations
of the routines in the driver code.
The DDT also provides a link from
the driver code to the driver data base.
Figure 4-18 shows the format
of the DDT.
Section
4.3.1
describes
the
DDT$
macro
call,
which
automatically generates

All

device drivers

first

located

words

the

DDT.

require a driver dispatch table

the

the beginning

driver

the

code.

somewhere

Conventionally,

1in

the table

the

code.

NOTE

If the length of
a driver must exceed 4K
words
(20000
octal
bytes),
then your
driver must set up the mapping
for
the
second
4K words whenever it is entered;
and, of course, all entry points must be
in the first 4K words of the driver.

The driver must define some labels that the Executive routines and the
INTSVS
macro
call
wuse
to
access
the DDT.
Table 4-10 lists these

labels, which are automatically generated by
the
DDT$
macro
call.
Because
these labels do not appear in the DDT itself, their format is
fixed

and

they must

specified

Table

Labels

Required

SxXTBL::

Required

for

the

Dispatch

Table

Meaning

"Defines the
this

start of the DDT.

1label

Defines

the

drivers

DDT.
For
routines use

link

loadable
this label

the pointer

You

specify

DCB

table

D.DSP word

the

DCB of

the
drivers,
the
LOAD
to fill in D.DSP.

the

KRB

addresses
in the CTB of the controller for
device xx.
Because a
driver
can
support
different
types
of controllers, there may
be more than one of
this
form
of
1label.
(The

DDTS

controller

SxXTBE: :

shown.

4-9

Driver

Format

resident

XxXCTB:

format

macro

Defines the end of the
LOAD and

supports

only

one

type.)

UNLOAD routines

DDT

that

for

scan

Executive
the

DDT.

PROGRAMMING SPECIFICS FOR WRITING
AN I/O DRIVER

——————
———
—
——
—
—

D.VNXC, D.VCHK'

Next Command/Optimization Entry Point Address

$xxTBL:: D.VINI

‘

-4

1/O Initiation Entry Point Address

D.VCAN

Cancel Entry Point Address

D.VTIM

Timeout Entry Point Address

D.VPWF

Powerfailure Entry Point Address

D.VKRB

Controller Status Change Entry Point Address

D.vuCB

Unit Status Change Entry Point Address

D.VINT

Generic Controller Name (ASCII) for xy

Interrupt Entry Point Address O
|
»

For Controller xy

°
Interrupt Entry Point Address n
o

xy CTB:

Pointer to KRB table in CTB (for INTSV$) for xy controller
Generic Controller Name (ASCII)
Interrupt Entry Point Address O

For Controller wz

‘

omam—

Interrupt Entry Point Address n
0

wzCTB:

Pointer to KRB Table in CTB (for INTSV$) for wz controller
.
L

$xxTBE::

p——

—

1. These are optional advance driver features

Figure

offsets

D.VINI

labels defining

4-18:

through

ZK-270-81

Driver

D.VUCB

Dispatch

the

Table

DDT

the addresses of the entry points

standard procedure,
the
entry
points

Format

your

driver

appear

in the driver.

you supply the labels described in Table
in
the
driver code.
The formats of the

As a

4-10
at
standard

labels that appear in the DDT are not fixed.
Because
the
Executive
expects
to
find
the entry point addresses at fixed offsets from the
start of the DDT and the labels themselves appear in the DDT, you
can

change
their
format
if you construct the DDT without using the DDTS$S
macro call.
(However, other labels that are required
1in
the
driver
code
but
do not appear in the DDT have a certain, fixed format which
you must not change.

$SxxTBL::

%
S

SxxTBE:
SxxLOA:
SxxUNL:

xxCTB:

For

reference,

these

fixed

format labels are:

PROGRAMMING

These

fixed-format

The
DDTS$
format of

some

D.VINT

offset

the
no

macro

driver

zero.

controller
types.)

labels

uses

the

described

standard

(such

DDT

(The

the

same

virtual

The

structure

allows

types.

(The

each

the

terminal
DDT$

controller.-

addresses.

I/0O

elsewhere

labels

but

the

terminal

the

DRIVER

1in

this

allows

you

chapter.)

driver

supports

follows

alter

the

only

support

one

block

the

has
word

multiple
controller

controller

first

that

driver
this

different

controller

begins

type

the

VTDRV),

supports

number

D.VINT+2

<controller

CTB.)

driver

macro

the

name

location

name

the

Although

there is no restriction
driver can support.
After

are

the

FOR WRITING

them.

supports.

controller

SPECIFICS

types

type,

that

interrupt

entry

interrupt address

block, each word of which defines an
address
to
be
included
in
a
vector for the driver.
A zero terminates the block and indicates that
there are no more interrupt entry points for the controller.
There is
no restriction on the number of vectors each
a single interrupt device, location D.VINT+2
0) is the interrupt address.

Standard

Table

4-10

for

Driver

Labels

Labell

Executive

accesses the

Entry

Entry Point
I/0

XXCAN:

Cancel

XxxCHK:

Block

check and

xxOUT:

Device

timeout

XXPWF:

Power

XXKRB:

Controller

xxUCB:

Unit

SXXINT::

Interrupt entry point

The

characters

reconfiguration

interrupt

initiation
I/0

K.VCT

result

1is

the

found

interrupt

examined.

points

the

for

status

are

software

address block

zero,

address

that

zero,

there

controller.
one

plus

address

point

entry

equal

entry point

entry point
an

not

vector

just

value

If
4

and

change

the

uses

2-character

the

multiplied
be

loaded

interrupt

vectors

that

even,

rules

vectors

when

for

address,
reconfiguration
in the controller request

will

mnemonic.

following

calculate

The

are

conversion

failure

controller.
To calculate the first
vector
routines
access
the
cell K.VCT (or S.VCT)

block.

may have.
For
entry
address

Points

XXINI:

The

controller
(interrupt

the

vector

address

(bit

with

entry

The

address

point

interrupt

vector
is

the

address

loaded

entry

with

1is
the

examined.
in

zero
1is
cleared
and
the
vector address.
To compute

the

block

odd

zero

1is

resulting number is an offset
the next vector
address,
the

set),

bit

to the next
offset
1is

PROGRAMMING SPECIFICS FOR WRITING AN

I/O DRIVER

added to the last vector address The next
interrupt
entry
point
is
examined.
If
it
1is
even,
then
1its value is loaded into the last
vector address computed.
If it is odd, the result is an
offset
that
is
added to the vector address just computed and the next entry point
is examined.
The computation of vector addresses terminates when
the
next entry point is zero.

The

entries shown

interrupt

vector

Figure

addresses when

4-19

can

K.VCT equals

used

300.

calculate

the

The vectors at 300 and 304 are loaded with addresses xxINl and
xxIN2.
The
odd
wvalue 7 yields the offset 6 that is added to the last vector
computed to attain 312.
The address xxXIN3 in the next interrupt entry
point
examined
1is
1loaded
1in the vector at 312.
A zero word in the
block

shows

there

are

more vectors

interrupt

entry points.

Following the interrupt entry address block for a controller type is a
pointer
to the KRB table in the CTB.
1Its label is in the form xxCTB,
which is used by the INTSVS macro.
This pointer connects .the
driver

code

the

specific

driver data base

and

the

last

entry in

block

for

controller.

A zero terminates
form $xxTBE marks

the
the

driver dispatch table.
terminating word in the

D.VINT

The global
DDT.

label

the

XXIN1

XXIN2

XXIN3

XXCTB:

ZK-271-81

Figure

4.5.2
The

this

1I/0

4-19:

Sample

Interrupt

Address Block

the

DDT

Initiation Entry Point

offset

D.VINI in the driver
entry point.
A driver is

dispatch

called

table

this

contains

the address of
entry point at priority

0 from the Executive routine $DRQRQ in the
module
DRQIO.
A
driver
should
call
the
Executive
SGTPKT
routine to get an I/0 packet to

process.
This action dequeues an I1/0 request.
The following are
register conventions when the Executive enters the driver.
RS

This

address of the UCB of
queued an I/0 packet

entry condition

queuing

operation.

pertains

the

unit

unless

the

Therefore,

for

which

driver

the

wants

the

Executive

has

the

if the queue-to-driver bit

delay

UC.QUE

PROGRAMMING

the unit
register

status block
conventions.

SPECIFICS

offset

FOR WRITING AN

U.CTL

1is

for

which

UCB

address

unit

SCB

address

the

address

the

I/0

packet

You may find more information
queue-to-driver
operation
in
Section

4.4.4

and

example

set,

I/0

the

packet

DRIVER

following

has

been

are

the

created

unit

on
and
coding
requirements
for
the
the
description
of the UC.QUE bit in

its

use

Chapter

The GTPKTS$ macro call automatically generates the call to the
S$GTPKT
routine
and
the code to process the return from SGTPKT.
Upon return
from SGTPKT, the C bit indicates whether there is a packet to process.
C

If the C bit is set, the Executive found the controller
busy, could not dequeue a request, or had to call S$FORK
to have the driver run on the correct processor.
If

the

bit

dequeued

device's

the

request

was

Address

unit

Address

status

Controller

Physical

Address

bit

code

continuous
may

registers
are
instruction to
a

driver

calls

the

I/C

set,

the

and

successfully

placed

the

queue.

the

following

are

the

contents

driver

1loads

the

with

process

block

device

process

returns

control

executed).

1location

the

packet

should

UCB

offset

address

request

the

and

the

executes

the

system,

before

conditional

the

correct

the
correct
processor,
an I/0 packet, queues it

SCFORK

caller

clear,

the

K.OWN/S.OWN

unit

activate

returning

the
bit

the

available to the driver.
The driver
transfer control to the system.

multiprocessor

SGTPKT

Executive

driver

block

control

KRB/SCB
then

control

index
unit number

instruction

generated

the

successfully dequeued,

driver

for

registers:

the

clear,

input/output

RETURN

1is

packet

the

The

device.

All

executes

packet

process.

the

RETURN

driver,

fork routine $CFORK to ensure that the

processor.
returns

the

current

S$SGTPKT,

and

processor

S$GTPKT dequeues:

to the driver, and returns to the driver with
the
C
bit
clear.
Should
the current processor not be the correct
processor, $CFORK will call $FORK which returns to the driver with the
C
bit
set.
This
action
causes
the
driver
to
dismiss
itself.
Eventually
correct

4.5.3

the

fork

processor

restarts

the

driver

executing

the

processor.

Cancel

Entry Point

The offset D.VCAN in
this
entry
point.

calls the
Executive
pertain:

the driver dispatch table contains the address of
The Executive routine $IOKIL in the IOSUB module

driver at this entry point
enters
the
driver,
the

UCB

address

SCB

address

Controller

index

Address

TCB

Address

active

at
device
following

(undefined if
current task
I/0

packet

4-64

S.KRB

priority.
register

equals

zero)

When
the
conventions

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER

All
The usage of this entry point is explained in Section 2.2.2.
registers are available to the driver. The driver returns control to
the Executive by executing a RETURN instruction.

Device Timeout Entry Point

4.5.4

The offset D.VTIM in the driver dispatch table contains the address of
Routines in the Executive module TDSCH call the
this entry point.

priority.

driver at this entry point at device

When

enters the driver, the entry conditions are as follows:
= UCB address
= SCB address

RS
R4

R3 = Controller index

the

Executive

(undefined if S.KRB equals zero)
|

R2 = Address of device CSR

RO = I/0 status code IE.DNR (Device Not Ready)

All
The usage of this entry point is explained in Section 2.2.3.
to
control
returns
driver
The
driver.
the
to
registers are available
the Executive by executing a RETURN instruction.

4.5.5

Next Command Entry Point

Ths offset D.VNXC in the driver dispatch table is only

applicable

The offset D.VNXC contains the entry point
the terminal driver.
address of a routine within the terminal driver which is called from
the routine $SNCMD in the Executive module DRSUB. This entry point is
The
is set to serial mode.
entered when a task exits whose TI:
driver then passes the next CLI command to the MCR dispatcher. When
the Executive enters the driver, the following register conventions
pertain:

RO = UCB address of the TI:

of the exiting task.

Queue Optimization Entry Point

4.5.6

The offset D.VCHK in the driver dispatch table contains the address of
this entry point. The routine $DRQRQ in the Executive's module DRSUB
When the
calls the driver at this entry point at priority =zero.
Executive enters the driver, the following register conventions
R5
R1

pertain:

UCB

address

I1/0 packet address

If the I/0 operation is a

data

transfer

function,

the

I/0

packet

contains the starting LBN for the I/0 request. The routine at this
entry point must verify the request is a data transfer function, and
if it is, the routine must replace the starting LBN with the starting
cylinder, track, and sector number to perform queue optimization. See
the

routine DBCHK in the module DBDRV for an example of a driver that

supports queue optimization.

PROGRAMMING

4.5.7
The

Deallocation

offset

D.VDEB

this
entry
the routine
request

SPECIFICS

Entry

All
to

registers
the

Power

offset

Point

The

driver

When

are

Executive

4.5.8
The

address

the

D.VPWF

Entry

the

expected

the
a

power

failures.
failure with

fashion

once

for

The
the

driver

The

driver

set

dispatch

controller.

CTB

KRB

may

(controller

are

its

buffers

set

The

driver

returns

control

instruction.

table

contains

power

the

address

Executive module POWER call the
0 for both unit and
controller

Executive first calls the
C bit
set.
The
driver

each

deallocate

Point

conventions:

C bit

registers

driver.

RETURN

this entry point.
The routines in the
driver at this entry point at priority
power

the

buffer

executing

Failure

called,

first

available
by

I/O DRIVER

driver dispatch table contains the address of
This entry point is called at priority zero from
the Executive module SYSXT after a buffered
1I/0

completes.

the

point.
$FINBF in

at this entry point.
follows:
RO

FOR WRITING

The

driver for controller
1is
called
in
this

following

are

the

failure)

address
address

use

all

registers.

After

the Executive has called the driver for all related controllers,
it
calls
the
driver
once for each unit power failure at priority 0
with the C bit clear.
The following are the register conventions:
C bit
R5

For

(unit

power

failure)

= UCB address
= SCB address
= Controller index

R4
R3

both

control

clear

controller
to

the

and

calling

unit

routine

If the driver supports a
bit
in the CTB is set),

power
by

failures,

executing

the

RETURN

driver

returns

instruction.

common

interrupt device (that is, the
LS.CIN
driver is called at this entry point only
for unit power failures.
For controller power failures, the Executive
calls
the
entry point at CI.PWF in the common interrupt entry table.
See

the

4.5.9

description

Controller

the

offset

Status Change

L.DCB

Section

4.4.8.

Entry Point

The offset D.VKRB in the driver dispatch table contains the address of
this
entry
point.
The Executive routine $KRBSC in the OLRSR module
calls the driver at this entry point at priority 0 to put a controller
on-line or to take a controller off-line.

4-66

PROGRAMMING

SPECIFICS

FOR WRITING AN

I/O DRIVER

NOTE

the

controller

controller
(LS.CIN
Executive does not call
this
address
(if any)
DDT but

interrupt
Section

The

C bit

The

following
R3

indicates

CTB

are

the

1labelled

CI.KRB.

4.4.8.

the

address

the
driver
at
specified in the
in
the
common

address

table

whether

the

common
interrupt
is
set),
the

for

request is
conventions

for

off-line

upon

entry

R2
0(SP)

= KRB address of
= Return address

the controller
controller changing
for completion

2(SP)

for

The

C bit

Return

address

set

C=10n-line

C =0

The

indicate
to

Off-line

the

requested

off-line

transition

on-line

transition

status change byte

$SCERR =

caller

$SCERR is

See

or
the

on-line.
driver.

status

Executive

status

routine

change

follows:

’

preset as

follows:

The driver indicates the return status in the $SCERR byte as follows:
$SCERR < 0

Operation is not successful and a negative

SSCERR = 1

Operation is

status

successful.

change

The

requested.

driver
This

accepts

the

condition.
All

registers

are

the status of
successful completion
driver
l.

must

The

the
of

return

driver

return

immediately by either

can

fashion.

1If

executes

indicate

the

first

driver

RETURN

the

return

address

accepts

1.)

status

the

change,

1loads

$SCERR and executes a RETURN

symbols are listed in an
Operations Reference Manual.)
driver

removes
returns

has

return

need

not

the
first
immediately

seconds
status,

and

indicate

the

status

the

instruction.

SSCERR has been preset with

The

the

default

to the driver.
The
Executive
does
not
controller until and unless the driver shows
the on-line or off-line request.

code

available

change

The

wvalue

$SCERR is the I/0 error code.
Thus, a negative value
rejects the status change requested by the C bit.

methods:

immediately

and can
normal

the

stack

(The

status

relevant

instruction.
appendix

perform

its

return

(The

the

processing,
first

merely
byte

rejects

I/0 error

status

the

change

driver

code

I/0

the

into

error

IAS/RSX-11

immediately

address
from
the
stack,
to the second address.
The

the

status change,

the

following

I/O

but

saves it, and
driver
then

indicate

address.

the
The

driver
can
use the offset S.CTM in the status control block
to time out some operation (such as a protocol
rundown)
and
then accept or reject the operation by ucing $SCERR.

4-67

PROGRAMMING SPECIFICS FOR WRITING AN I/O DRIVER

If the driver does not return to the first address on the stack, the
system can be considered to be in an indeterminate state and possibly

corrupted.

changes

The driver must return immediately because status

should not stall the system. The 60-second delay allows a driver time
(such as
to overcome conditions over which it has 1little control
network connections). System disk and terminal drivers must indicate
(TTDRV)
However, the terminal driver
return status immediately.
of
some
if
r
multiplexe
DZ1ll
a
for
request
on-line
controller
a
rejects
the status bits indicate that the device is not a DZ1l or that it |is
broken.

4.5.10

Unit Status Change Entry Point

The offset D.VUCB in the driver dispatch table contains the address of
The Executive routine $UCBSC in the OLRSR module
this entry point.
calls the driver at this entry point at priority 0 to put a unit
on-line or to take a unit off-line. This entry is called once for
The C bit 1indicates whether the
each unit whose status changes.
The following are the register
off-line.
request is for on-line or
conventions:
o

R5 = Address of UCB or unit changing status
R4 = Address of SCB of unit

R3 = Controller index (undefined if S.KRB equals zero)
0(SP) = Return address for driver completion

2 (SP) = Return address for caller of the Executive routine

C
C

The C bit is set to indicate the requested status change as follows:

1 On-line to off-line transition

0 Off-line to on-line transition

The status change byte $SCERR is preset as follows:
SSCERR =

The driver indicates the return status in the $SCERR byte as follows:

wvalue

1in

accepts

the

$SCERR < 0

Operation is not successful and a negative

$SSCERR = 1

Operation is

Thus, a negative value
SSCERR is the I/0 error code.
rejects the change requested by the C bit.

status

successful.

change

requested.

condition.

All registers are available to the driver.

The

driver

This

the

default

must

return

The

driver

The Executive does not change the status of a unit
within 60 seconds.
until and unless the driver shows successful completion of the on-line

off-line

request.

The driver must return immediately by either of the following methods:
1.

The driver can indicate the return status immediately and can
stack in the normal
the
address on
first
the
to
return
change, it merely
status
the
accepts
driver
the
1If
fashion.
status change byte
(The
instruction.
RETURN
executes a
the
rejects
the driver
$SCERR has been preset with 1.) If
relevant I/0 error code into
it 1loads the
status change,
I/0 error
(The
instruction.
$SCERR and executes a RETURN
symbols are listed in an appendix of the IAS/RSX-11 I/0
code

Operations Reference Manual.)

PROGRAMMING SPECIFICS FOR WRITING AN I/0 DRIVER

The driver need
not
indicate
the
status
immediately
but
removes
the
first
address
from
the
stack, saves it, and
returns immediately to the second address.
The
driver
then
has
60
seconds
to
perform its processing, to indicate the
return status, and to
return to
the
£first
address.
The
driver
can
use the offset S.CTM in the status control block
to time out some operation (such as a protocol
rundown)
then accept or reject the operation by using S$SCERR.

the driver does not return to

system

the

can be considered to be in an

first address on the

stack,

and

the

indeterminate state and possibly

corrupted.
The driver must return immediately because status
changes
should not stall the system.
The 60-second delay allows a driver time
to overcome conditions over which
it
has
1little
control
(such
as
network
connections).
System disk and terminal drivers must indicate
return

status

4.5.11

immediately.

Interrupt

Entry Point

Upon an interrupt,
control
is
dispatched
to
the
driver
from
an
interrupt
vector
through an interrupt control block or directly from
an interrupt vector.
A device may have more than one interrupt
entry
point.
The
entries
in
the DDT interrupt address block are used to

initialize either the vector(s) or the interrupt
control
block
with
the
address(es)
of
the related interrupt entry point(s).
(Refer to
Section 4.5.1 for a discussion of the interrupt
address
block.)
All
drivers should observe the protocol for handling interrupts introduced
in Section 1.3 and summarized in Section 4.1.
If the driver is loadable,
dispatch
coroutine
SINTSI

it
will
be
<called
from
the
interrupt
in
the Executive.
The following are the

= Controller

index

Registers R4 and R5 are available to the driver.
The driver
runs
at
the
priority
set
in
the
interrupt
control block.
To dismiss the
interrupt, a driver executes a RETURN instruction.

If the driver is resident,
it
receives
<control
directly
from the
interrupt vector.
It runs at priority PR7 and the low-order four bits
of the PS have the
controller
number
of the
interrupting
device.
Because
the
1low-order
four
bits
are
status
bits
and almost any
instruction
modifies
them,
the
first
operation
that
should
be
performed is to save the PS. Then, the driver does its processing at
priority PR7 (saving registers if necessary).
After
processing,
it

restores

executing

the

registers

RTI

(if necessary)

instruction.

and dismisses the interrupt by

However, all reasonable drivers should use the INTSVS macro call at an
interrupt entry point.
The INTSVS$ macro resolves entry processing for
both loadable and resident drivers.
For loadable drivers, INTSVS does
not
generate
a
call
to
S$SINTSV
because
LOAD
establishes
1in the

interrupt control block the call to the $SINTSI coroutine.
The
SINTSI
coroutine saves R4 and R5;
sets the priority
to that in the interrupt
control block;
and forms the controller index from the PS and
stores
it
in R4.
(LOAD previously set the priority in the interrupt control
block based on the value at offset K.PRI
in
the
controller
request
block.)

For resident drivers, INTSVS$ generates a call to the SINTSV coroutine,
which
sets the
priority to that specified in the INTSVS$ macro call;
saves registers R4 and R5;
and forms the controller index from the PS
and

stores

R4.

PROGRAMMING

For

both

with

call

The

UCB

address

may

then

Save

Become

the

drivers,
the

INTSVS$

interrupting

following

generates
unit.

conditions

extra

the

interrupting

code

After

the

pertain

1load
INTSVS

for

both

unit

following:

registers

fork

the

processing
process

Executive

Restore

the

necessary
is

routines

explicitly

necessary
access

the

data

saved

extra

Execute
a
RETURN
instruction
dismisses the interrupt

Volume Valid

System-supplied

registers

the

coroutine,

which

your having to
consider
a resident driver in the

Processing

drivers

have
the
DV.MNT
special processing

structures

necessary

In summary, then, the INTSVS macro eliminates
the coding differences between a loadable and
interrupt service routine.

4.5.12

I/0 DRIVER

index

whatever

call

code,

FOR WRITING

resident drivers:

resident

address

Controller

driver

and

UCB

driver

and
wu

the
the

loadable
R5

loadable

SPECIFICS

that

service

mountable

devices

(those

that

bit
1in
the
UCB U.CWl1l word set) take advantage of
of volume valid for a device.
For such devices the

Executive
directive processor DRQIO checks that either of the
status bits US.MNT or US.FOR in the UCB
U.STS
word
1is
set.
mounted

bit

status

called

set,

DRQIO

volume

valid

(US.VV)

a mounted

status

bit

directive.
volume

valid

bit.

the

volume

effectively

valid

user-written

take

advantage

SVOLVD routine

the

UCB

(DRQIO assumes

service

the

byte

should

volume

driver

status

not

requires

that

set

else

that

set,

the

rejects

the

DRQIO does not check the

MOUNT command

properly

set

bit.)

driver

system-supplied

spinning-up

bit

mounted
If
a
device-specific

the

bit

mountable
perform

valid

does.

(US.SPU)
(For

device
one

on
two

capability

This

Executive

U.STS.

the

processing

module

and

the

details

1IO0SUB,
this

system,

and

refer

Statically set the
base source code

US.VV bit

DCB

no-op

the

UCB

for

function

the

a user-written
by
doing
the

Enable

the

a
the

mechanism,

that

calling

(US.VV)

Enable the set characteristics function (I0.STC)
valid in the DCB legal function mask word
function

way

handling

same

can

bit

driver
source
code
supplied
on the system.) Second,
driver can
circumvent
the
volume
wvalid
processing
following:

the

same

valid

First,

involves

volume

the
ways.

mask

driver

volume

work

data

The second method allows the device to
be
successfully
mounted
and
associated
with an ancillary control processor without your having to
include code in the driver to handle US.VV.

CHAPTER

INCORPORATING A USER-SUPPLIED DRIVER INTO RSX-11M-PLUS

into

This chapter describes how to incorporate a user-supplied driver
system.

an RSX-11M-PLUS
having created source code
in Chapter

given

5.1

The material in the chapter depends on your

according

the

specifics

programming

GUIDELINES FOR INCORPORATING A DRIVER

The procedures that §ou follow to incorporate a

user-supplied

is one of the following types:

Loadable driver with a loadable data base

Loadable driver with a resident data base

Resident driver with a resident data base

driver

Your driver

RSX-11M-PLUS depend on the type of driver you have.

into

If your driver is loadable with a loadable data base, you may perform
a system generation to include your driver, or you may incorporate it
If you want to use a new
directly into your currently running system.
and your driver is
base,
loadable
a
with
driver
loadable
a
of
version

the
1load
file,
currently loaded, you must create a new system image
new
the
bootstrap
then
and
file,
the
into
driver
the
new version of
Refer to Section 5.1.1 if you want to incorporate your driver
system.
at
system generation.
Refer
to
Section
5.1.2
if
you want
to
incorporate your driver after system generation.

If your driver is loadable with a resident data base, or is

resident,

you must perform a system generation because the resident driver
and/or data base reside in the Executive and must be assembled and
Refer to Section 5.1.1 to
Executive.
task built as part of the
incorporate your driver at system generation.

Because loadable drivers and loadable data bases can

changed

and

reloaded without performing a system generation, loadable drivers with
and maintain than resident
loadable data bases are easier to debug

drivers and/or resident data bases.

Incorporating a Driver at System Generation

5.1.1

If you want to build a loadable driver with a 1loadable
data base during system generation, proceed as follows:

resident

Assemble and task build your driver to eliminate any assembly

or Task Builder errors.

INCORPORATING

USER-SUPPLIED DRIVER

INTO RSX-11M-PLUS

Put the MACRO-11 source files containing your driver code and
data
base
in
UFD
[11,10]
on the target system disk.
The
driver source file should be named
xxDRV.MAC
and
the
data
base
source
file should be named xXxTAB.MAC, where xx 1is the
2-character device
mnemonic.
Mnemonics
for
wuser-supplied
devices
should
begin
with
the
1letters
J
or
O to avoid
conflict with DIGITAL-supplied devices.

Perform a system generation and choose the Full-functionality
Executive.
Answer
the
questions
concerning user-supplied
drivers printed during
system
generation.
This
procedure
includes
your
driver
data
base
1in the Executive if it is
resident and builds
your
driver
task
1image.
A
loadable
driver
and
data base are loaded into the system image file.
Refer
to
Section
5.3
for
a
description
of
the
system

generation

you
1.

procedure.

Use CON from MCR to make your devices accessible.

Section

want

5.2.5

build

your

first

for

the

CON

command

resident driver,

driver

build

can

run

and

test

proceed

loadable

base.

Put

the

data

MACRO-11

base

driver source
base
source

source
UFD

file
file

files

[11,10]

with

your

should be named
should be named

system
driver,

generation.
you must not

Executive
questions
system

data
a

base

modules

description

the

your

target

data

driver

system

for

code

disk.

and
The

the
data
xx is the

user-supplied
or
0Q to avoid

Refer

Section

5.2.5

for

the

CON command

Driver

Assemble
Task

and

task

Builder

build

your

description.

with

5.3

for

Refer

procedure.

Use CON from MCR to make your devices accessible.

base,

loadable data

xxDRV.MAC
and
xxTAB.MAC where

generation

The procedures to incorporate a loadable
base after system generation involve the

If
you
want
to
include
a
choose the Full-functionality

Executive.

system

Incorporating a Loadable
System Generation

1loadable

or
Executive
data
space
support.
Answer
the
concerning
wuser-supplied
drivers
printed during
generation.
This procedure includes your
driver
and

Section

5.1.2

device mnemonic.
Mnemonics
should
begin
with
the
1letters
with DIGITAL-supplied devices.

Perform a
resident

follows:

loadable with

2-character

devices
conflict
3.

containing
on

Refer

description.

Loadable

Data

Base

After

driver with a loadable
following steps:

data

driver

errors.

eliminate

any

assembly

Put

the MACRO-11 source files containing your driver code and
data
base
in
UFD
[11,10] on your target system disk.
The
driver source file should be named
xxDRV.MAC
and
the
data

base
source
file should be named xxTAB.MAC, where xx is the
2-character device
mnemonic.
Mnemonics
for
user-supplied
devices
should
start
with
the
1letters
J
or
0 to avoid
conflict

with

DIGITAL-supplied

devices.

INCORPORATING

USER-SUPPLIED DRIVER

INTO RSX-11M-PLUS

Run

the
system
generation
procedure
and
follow
the
instructions
in
the
"“Adding
a
Device"TM
section.
(For
information
on
1invoking
the
system
generation
procedure

(SYSGEN),
refer
to
Installation Guide).

the

RSX-11M-PLUS

System Generation

The
system
generation
procedure
asks
you
2-character
device mnemonic for your driver.
should be the same mnemonic used in the driver
source

Use

file

the

MCR

LOA command to link
device
tables and

system

5.2

Use

CON

Refer

from MCR

line.

(CON

can

Section

5.2.5

for

WHAT THE

to
enter
Remember,

the
this

and

base

data

names.

and driver code.
descriptions.
5.

and

place

also
the

SYSTEM GENERATION

Section

the

5.2.4

data
base
driver data

for

the

controller(s)

alter

CON

your driver
to load your

vector

command

PROCEDURE

LOA

and

into
base

command

unit(s)

assignments.)

Refer

descriptions.

DOES

FOR YOU

The system generation procedure assembles your driver and
data
base,
puts
the resulting object modules in the Executive object library and
task builds your driver.
If your driver or its data base is resident,

the
driver
and/or
data
base is included in the Executive.
If your
driver or its data base is loadable, the driver and/or
data
base
is
loaded
into
the
system
image
file.
You
must
then
make
the

controiler(s)

and

unit(s)

accessible.

The

commands that the system generation
procedure
uses
to
assemble
your driver and data base, insert your driver and data base modules in
the library,
and task build your driver, are the
same
commands
that

you

may

use

assemble,

following

subsections
driver.

your

5.2.1

Assembling

the

explain

Driver

insert

and

task

each

the

procedures

and

Data

build

your

for

driver.

The

incorporating

Base

The system generation procedure assembles
base with the following commands:

your

driver

and

its

data

MAC>[11,24]xxDRV,[11,34]xxDRV/-SP=[1,1]EXEMC/ML,[11,10]RSXMC/PA:1,xxDRV

MAC>[11,24]xxTAB,[11,34]xxTAB/~-SP=[1,1]EXEMC/ML,[11,10]RSXMC/PA:1,xxTAB

your

driver

RSXASM.CMD.

the

file

The

commands

library

xxXxDRVASM.CMD,

for

some

offsets

the

The

[11,10].

contains

that

your

device

the

code

the macro definitions

symbols

macros

INTSVS).
UFD

where

EXEMC.MLB

symbolic

contains
some

these commands are
is loadable, these

located

1in

commands

are

the

file

located

mnemonic.

to the assembler specify as
input
the
Executive
macro
EXEMC.MLB,
the Executive assembly prefix file RSXMC.MAC, and
your driver code or driver data base source file (xxDRV.MAC
or

either
xXxTAB.MAC) .
and

is resident,
your driver

defined

that

your

assembler

during
looks

for

may

the

definitions of

reference.

is given

system

driver

macro

may

Appendix

generation

invoke

source

(The

and

structures

source

A.)

code

RSXMC.MAC

definitions

(such

DDT$,

GTPKTS,

and

file

your

driver

INCORPORATING

output,

the

listing
files
XXTAB.OBJ will

assembler

creates

object

in
UFD
[11,34].
later be put in
the

should
retain
documentation and

5.2.2

A USER-SUPPLIED DRIVER

Inserting

modules

UFD

xxDRV.LST

and

and Data Base Modules

and

xxTAB.LST

in the

Library

After your driver and data
base
modules
have
been
driver
and
data
base
modules
are
added
to
the
library.
Commands to the Task Builder (described
in
require the modules be in this library.

The

system generation procedure uses
both the driver and its data base to
LBR

[11,24]

The
object
modules xxDRV.OBJ and
Executive
object
1library.
You

the
listing
files
maintenance purposes.

the Driver

INTO RSX-11M-PLUS

the

for

assembled,
the
Executive object
Section
5.2.3)
|

following
commands
same library:

add

[1,24]RSX11IM/RP=[11,24]1xxDRV,xxTAB

The command to LBR adds the object modules of both your driver and its
data base to the Executive object library RSX11M.OLB, which resides in
UFD [1,24].
RSX11M.OLB is built from object modules assembled
during
system
generation.
The
/RP
switch ensures that any modules of the
same name are replaced by the recently created modules.
If
this
is
not
the
first
time
vyou
have
performed this operation, LBR prints
messages telling you that it replaced your modules in the library with
the

new versions.

5.2.3

Task Building

the Driver

After

the modules have been added to the Executive object library, the
system
generation
procedure
task
builds your driver and data base.
The commands for a resident driver are located in the file RSX11M.CMD.
The
commands
for
a
resident
data
base
are
1located
1in the file
RSX11M.CMD on systems without Executive data space support and in
the
file DSP11IM.CMD on systems with Executive data space support.

The

commands

for

loadable

XX
1is the device mnemonic.
the lines that are contained
driver:

driver

The
in

are

located

xxDRVBLD.CMD

where

following discussion explains each of
the
command
file
for
a 1loadable

When the system generation procedure builds
your
driver,
a
task-image
file
name
and a symbol definition file name are
specified

TKB

output.

The

task

1image

and

symbol

definition
files
are placed in the UFD corresponding to
system UIC that will be in effect when
the
LOA
command
issued.
The
file
names
are
both
xxDRV, where xx is

the
1is
the

device mnemonic.
The Task Builder produces the output
files
named
xxDRV.TSK, xxDRV.MAP, and xxDRV.STB.
For example, the
input supplied to TKB to build the xx device would look
1like
the

following:

[1,54]xxDRV/-HD/-MM, [1,34]xxDRV/-SP,[1,54] xxDRV=

No task header
is included.
the

example.

extension of the
3.

The

Executive,

switch /-MM must be

The

A driver

used

and
in

switch /-HD is used,
is

not

really

such needs no

the command

line.

task,

but

1in

task header.

INCORPORATING A USER-SUPPLIED DRIVER INTO RSX-11lM-PLUS

A map file is produced and
is
wuseful
for
debugging.
All
driver
map files are written to UFD [1,34].
The switch /-SP
suppresses automatic

spooling

The system generation procedure

the

line

1links

printer.

your

driver

the

system
symbol
definition
file that contains definitions of
Executive global symbols.
Continuing the example from item 1

above might give further TKB

input that would

like this:

[1,24]RSX11M/LB:xxDRV:xxTAB
[1,54]RSX11M.STB/SS

The first line above specifies
the
1library
file
(/LB)
1in
which
the input driver object module and the object file for
the loadable data base
can
be
found.
The
object
module
specification
for
the
driver
always
precedes
the
specification for the data base in the TKB command line.
The

second

definition

line

file

item

above,

RSX1IM.STB

1is

indicates that

be searched

the

symbol

selectively

(/SS) for definitions of Executive global symbols.
Note that
the
/SS
switch
must
appear
in this context.
It is never

omitted.

The system generation procedure

1links

your

driver

system
library
file
that defines masks and offsets used
the Executive.
To continue the example:

the
in

}l,l]EXELIB/LB

The single slash begins the option phase of the Task Builder.
7.

The

Task Builder

stack within

is directed not

allocate

space

for

the driver.

STACK=0

A partition

for

the driver

specified:

PAR=DRVPAR:120000:
40000

//
The
partition
name
DRVPAR
1is
the
typical
name
of
a
conventional partition reserved for drivers.
A driver may be
loaded
virtual
is,
The

the

1into
any
system-controlled
partition.
The
address of the partition is always 120000 (8).
loadable driver must be mapped through
kernel

1length of

exceed

The double

5.2.4

the partition,

8K words

(40000

octal

the

second

parameter

base
That
APRS.

should

not

bytes).

slash ends the option phase of

the Task Builder.

Loading the Driver

After your driver is task built, you are ready to load the
driver
on
your
system.
This procedure is used when you are incorporating your
loadable driver with a loadable data
base
after
system
generation.
Loading
is
done
by using the priviieged MCR command LOAD.
Its form
is:

>LOAD xx:[/PAR=GEN] [/HIGH]
>

INCORPORATING A USER%SUPPEIED'DRIVER INTO RSX-11M-PLUS
The variable xx is the
2-character
device
mnemonic.
Specifying
a
partition is optional.
1If a partition is not specified, the partition
input to the Task Builder is used.
The keyword /HIGH puts the
driver
as high as possible in the partition.
The default condition is to put
the driver as low as possible in the partition.
LOAD performs

many

diagnostic
checks
on
vyour
driver
data
base,
addresses within the data base, and loads the data base
and the driver code into memory.
Because the LOAD
diagnostic
checks
are
complicated
and
LOAD supports another, infrequently used option
(/CTB), a description of LOAD is given in
Section
5.4.
LOAD
error

relocates

many

messages

and

Manual.

After

the

driver

off-line

and

are

not

must

place

5.2.5
After

Making
your

meanings

the

are

listed

the

RSX-11M/M-PLUS

loaded,

the

controller(s)

accessible.

controller(s)

and

allow access
unit(s)

MCR

Operations

and

units

are

the device,

you

on-line.

Devices Accessible

driver

has

been successfully
1loaded,
vyou
must
make
the
units
accessible.
You use the CON task to place
controller(s)
and units on-line, to change vector and CSR
assignments
that
you
established
1in the driver data base, and to take units and

controller(s)

and

controller(s)

off-line.

Unless

the

vector

driver data base are not correct for
the controller(s) and units on-line.
CSR

assignments

while

the

match

the

hardware

CSR

controller(s)

and

units

5.2.5.1

Setting Vector

and

CSR Assignments

offsets

S.VCT/K.VCT

and

are

the

CSR

values

1in

the

and

vector

assignments

only

off-line.

the

KRB(s)

values

the

driver

data

system,
vyou
must
1issue
establish the correct values.

the

S.CSR/K.CSR

base are
incorrect
for
privileged SET command in

and

the running system, you can place
You may change
the
wvector
and

the

your

running

CON

NOTE

Because

CON

access

changes

must
the

vector

load

the

SET

commands

data
base
to load the
vector

You

must

this

off-line.
controller(s)
vector

and

and
CSR

and

CSR

unit(s)
a

CSR

driver
in

Executive
base

assignment,

before

CON.

are

driver

when

you
a

you

issue
driver

not need
correct

assignments.

while

ensures

for

the
data

1is resident, you do
driver to establish

operation

(LOAD

causes
driver

the

that,

for

off-line.)
that

controller(s)

loadable

Typical

supports

follows:

and

units

are

data

base,

the

commands

single

controller

set

are

>CON

CON>SET xxA VEC=300
CON>"Z

CSR=160040

The

command

type

xx.

data

base

first
The

and

establishes

Executive

writes

the

300

accesses

specified

as
the

the

vector

offset

value

for

controller

S.VCT/K.VCT

divided

the

The

driver

command

INCORPORATING A USER-SUPPLIED DRIVER

INTO RSX-11M-PLUS

secondly establishes the control and status register address as 160040
for
controller
A
of
type
xx.
The
Executive accesses the offset
S.CSR/K.CSR in the driver data base and writes
the
specified
value.
You
type
the CTRL/Z combination to exit from CON.
After you set the

vector or CSR assignment,
and

units

you can attempt to place

the

controller(s)

on-line.

5.2.5.2
Placing a Controller and Units(s) On-Line - If the vector and
CSR
assignments
in your driver data base are correct for the running
system, you can place the controller(s) and units on-line
by
issuing
the privileged ONLINE command in CON,

NOTE

Because

placing

on-line
driver,
before

causes the Executive to call the
you must have loaded the
driver
you
1issue the ONLINE command in

controller

unit

CON,

The following commands demonstrate
single controller and two attached

a
typical
sequence
units on-line.

place

>CON
CON>ONLINE

CON>ONLINE

xxA
xxO:

CON>ONLINE

xx1:

CON>"Z
>

The first command
places
controller A
of
type
xx
on-line.
The
Executive
accesses
the KRB of the controller to read the S.VCT/K.VCT
offset and initializes the vector to point to
the
related
interrupt
control

block.

NOTE

the

driver

Executive, the
the
driver.

1is

resident

vector
For
a

within

the

points directly to
common
interrupt

controller,
the
wvector
points
to the
interrupt entry address in the Executive
rather

The

Executive

then

than

ensures

that

ICB,

the

address

S.CSR/K.CSR

1is

wvalid

(that
1is,
some
device
responds at that address).
Refer to Section
5.2.5.3 for a discussion of CSR and vector assignment
errors.
Next,
the
Executive
calls the driver at its controller status change entry

point.
change
to

Only after the driver indicates
success
does
the
Executive
the
status bit in the SCB/KRB of the controller from off-line

on-line.

The second and third commands place logical units
0
and
1
on-line.
The
Executive
checks
that
the
controller
1is on-line (that is, an
access path exists to the unit).
If the controller
1is
not
on-line,
the
Executive
sets
the UCB of the unit as marked for on-line.
(The
Executive automatically places on-line a unit that is
1in
the
marked

for

on-line state only when its controller is placed on-line.)

If the

INCORPORATING

USER-SUPPLIED DRIVER

INTO RSX-11M-PLUS

controller

is on-line, the Executive calls
the
driver
at
its
unit
status
change
entry
point.
Only after the driver indicates success
does the Executive change the status bits in the UCB of the unit
from

off-line
action to

to on-line.
(The
indicate success.

entry

points

After

you

is
to

not
the

required to take any
discussion of status

that

want

them

special
change

4.5.)

have issued the ONLINE commands, you can issue
CON as follows to verify that the devices are

command

you

Section

driver
Refer

in:

FOR

the
DISPLAY
in the state

>CON
CON>DISPLAY

FULL

(The

display

appears

the

terminal.)

CON>"2Z
>

The command displays status of all
units attached to the controllers.

5.2.5.3

CSR

errors

are

ONLINE

some

and

command

device

S.CSR/K.CSR

three

Your

CON

Your

at
your

device

place

device

your

some

and

vector
When

on-line,

CSR

address.

some

other

on-line

device

CSR

established
does

device,

CSR

no:t

some

but

CON

all

assignment

you

issue

wverifies

the

that

at the
one of

the

Therefore,
if
subsequently

CON

places

does

not

representative

verify

assignment

your

the

vyour

CSR

I/0

responds
continues

page

than

other

device

responds

attempting

the

system
I/0

case,

CON

hang

page

device

your

the

place
or

other

your

crash.
than

the

responds
reports

the

device

error

on-line.

device

base

and it
want.
CON

distinguish

this

on-line

have

a
jumpers

address

data

and

respond,

driver

the

continues

device

you

other

cannot

address

address.

place

resulting

address,

address

on-line.

some

CON

and

possibly

established

device

address

established

and

cases:

address,

and

CSR

type

the CSR address that you established
driver data base.
CON can encounter

CSR

Your

detectable.

device is at the established CSR
the
CON probe.
This is the case

device
e

place

established

from

Errors

immediately

responds
offset

attempting
e

Assigment

always

possible
@

Vector

not

controllers

matches

and

the.

DIGITAL
Field
and ensure that
the

verified

device
Service
the
CSR

hardware

CSR

assignment.

When
at

the
the

vector
offset

address

developed

S.VCT/K.VCT

1in

from
the

the

value

that

yon

driver

data

base

differs

established
from

the

hardware vector assignment, several outcomes are possible.
Should the
established
vector already be in use (that is, pointing at other than
the nonsense interrupt entry address
in the
Executive),
CON
reports

the condition and does not place the device on-line.
If the
not in use, CON establishes it as
the
device
vector
and
attempting
to
place
the
device
on-line.
This
action
guarantee

that

the

software

and

hardware

vector

assignments

vector is
continues
does
not

match.

INCORPORATING

When CON does place a
vector assignments do
e

Your

The

driver

USER-SUPPLIED DRIVER

device on-line
not match, two

will

device will

INTO RSX-11M-PLUS

and
the
software
and
results are possible:

time out

waiting

for

interrupt

through

hardware

interrupt.

unused

vector.

If error logging is active on your system, a nonsense
interrupt
will
be
1logged as an undefined interrupt error and the ERRSEQ count in the
Executive is increased by 1.
The RMDEMO task display, which
1includes
the
ERRSEQ
count, will reflect the occurrence of nonsense interrupts
by an increasing number in ERRSEQ.
Consult an error
1log
report
and
look for undefined interrupt errors.
When

(1)

error

logging

1is

active,

(2)

nonsense

interrupts

not

occur,
and (3) your
driver
times out, the interrupt could be going
through some other driver vector.
If the unexpected interrupt goes to
a DIGITAL-supplied driver, one of two outcomes is possible.

The interrupt will
routines
dismiss
track

when

simply
be
wunexpected

they expect

dismissed.
(Common
interrupt
interrupts and some drivers keep

interrupts

and

dismiss

unexpected

ones.)

The driver will

react

attempting
to
system crash.

terminate

an
the

unpredictable
last

Thus, error logging and the ERRSEQ count
indicate improper vector assignments.

5.3

fashion

I/0 packet

the

RMDEMO

USER-SUPPLIED DRIVER SYSTEM GENERATION DIALOGUE

you

are

building

either

loadable driver

with

again)

(such

causing

display

help

SUMMARY

resident data

base

or
a
resident
driver,
vyou
must
perform
a
system
generation to
incorporate your driver into the system.
This section summarizes
the
system
generation dialogue only as it relates to user-supplied driver
support

and

generation

Generation

related features.
For
more
procedure
itself,
refer
and Installation Guide.

information
on
the
the
RSX-11M-PLUS

system
System

NOTE

If you are building
a
loadable
driver
with
a loadable data base, you need not

perform
a
incorporate
can

still

system
generation
to
vyour
driver.
However, you
build
your
driver
during

system
generation.
Section
5.1.2
describes
the
complete procedures
to
build
a loadable driver with a loadable

data base any time after
Executive
under
which

you
build
the
the driver will

run.

5.3.1
The

Choosing

Executive

system features
Options"TM
section.

are

Options

determined
during
the
"Choosing
Executive
You have to specify answers related to including a

INCORPORATING

user-supplied

driver

USER-SUPPLIED DRIVER

your

system.

INTO

question

RSX-11M-PLUS

the

following

appears:

>
If

you

form

you

want

choose

the

Full-functionality

Executive?

Executive,

[Y/N

your

D:Y]:

driver

must

loadable with either a loadable or resident data base.
If you want to
incorporate
a
wuser-supplied
resident
driver,
vyou
must
omit
the
Full-functionality
Executive
and
omit Executive data space support.
All DIGITAL-supplied
resident data base.

drivers

If you do not choose
generation procedure

the
asks

>
If

you

you want

have

base,

you

driver,

you must

driver

answer

loadable

Yes

space

with

support?

either

this

systems

with

controllers,
Whether

you

question

Executive

>
You

choose

you

should

data

the

this

want

to
Yes

question,

5.3.2

Choosing

Peripheral

the

form

base

supply
>

your

this

ICB

are

driver

pool

resident

have

data

resident

D:128.]:
be

1large

ICB

Executive

[Y/N

D:N]:
XDT

(described

not,

another

Chapter

incorporating

questions
or

space.

support:

which

pool

this

faulty

section

features.

Configuration

answer

section

questions

A question

the

about

your

following

system
driver

form

generation
and

its

asks

vyou

data

mnemonics:
mnemonics

for

user-supplied

drivers

([S]:

device mnemonic for your driver.
used in the driver and data base

This
source

names.

you

did

following
>

not

form
you

select

Executive

data

space

support,

question

you want

the

appears:
want

the

xx:

driver

loadable?

[Y/N

D:N]:

Answer Yes to this question if you want a loadable driver.
if

must

enough

XDT

support

Configuration

device

system problems

You must enter the 2-character
should
be
the
same mnemonic

file

you

system

D:NJ]:

([D R:16.-1024.

about

question.

must

device

Enter

asks

there

configuration.

there

XDT?

Peripheral

you

that

include

user-supplied

procedure,

the

Full-functionality

following

answer

concerning

the

question.

space,

ensure

is
helpful
1in debugging
driver may engender.
After

loadable

the drivers loaded into the virgin system image.
One
needed for every 16(10) controllers of the same type.
controlled
by
vyour
driver
has
a
1large number of

you should

the

[Y/N

loadable

question.

> What is the ICB pool size (in words)?
enough
for
all
ICB (8 words)
is
If
the
device

with

Full-functionality
Executive,
the two following questions:

Executive data

loadable

should

your

driver

resident.

5-10

Answer

INCORPORATING A USER-SUPPLIED DRIVER

your

driver

procedure
>

Answer

loadable,

the

you

want

the

this

question

Yes

you

asks

want

about

your

xx:

data

you

The

system generation procedure
interrupt vector address:
>

The

What

the

highest

system generation

interrupt

vector

the vector address for
highest vector address

This

ends

the

user-supplied

system

base

system

generation

loadable

loadable?

data

[Y/N

base.

Answer

resident.

asks

you

vector

specify the

calculates

for

the

address?

and

generation
are

highest

R:n-774

displays

the

DIGITAL-supplied

device is
higher
by your device.

you

the

needed

generation

want

interrupt

your
used

driver.

data

always

procedure

address

question

base:

driver's

base

INTO RSX-11M-PLUS

than

portion
a

highest

devices.

1If

enter

the

this,

generating

D:n]:

incorporating

new

system,
Executive

the

system

procedure includes your driver in the
if
it
is
resident,
or
loads
your
driver
into
the
system
image
if it is
loadable.
After the newly built system is running, you must make
the
devices
that
your driver supports accessible, as directed in Section
5.2.5.

you

are

adding

your

driver
described in

5.4

your

driver

after

system generation,

and

make
the
devices
Sections 5.2.4 and 5.2.5.

that

you

supports

must

load

accessible,

LOAD PROCESSING

The Executive LOAD routines extensively check the
driver
data
base;
LOAD
provides the /CTB switch to handle multidriver controllers.
The
following subsections describe the two aspects of LOAD.

5.4.1

LOAD Operations

Two

modules

one

conditionally

(LDVLDB

the

other

resident

The

LOAD

the

data

and

LDVFIN)

checks

finishes

the

Diagnostic

the

operation

base

and,

(If

the

data

base

the

global

data

base,

check

address

is,

not

the

result

data

base

labels

are

load
and

the

data
the

the

from

the

$xxDAT and

base,
DCB.

symbol

first

the

into
data

driver.
into
the

validate

resident,

memory:

base;

and

there

xxDRV.TSK

$xxEND,

file

other

validity

into

defining

the

word

the
If

table
of

LOAD

the
the

routines

global

file),

label

the

start

the

data base.

must
$xxDCB

start of
Many

know
is

the

not

DCB

unusual

the system pool.
pointers
within

data

checks

in
on

system

and

end

the

into

pool,

error

the

starting

defined

the
the

The driver itself is then loaded
control blocks are created.

when

driver

loads

needed.

and
the
Thus, to
start

process,
is

driver data base are performed.)
its partition, and the interrupt
read

LOAD,

validity

data base, the data base is loaded
routines relocate and validate many of

structures.

Checks

(that

assumed

conditions

LOAD assumes that the DCB is at the start of the data base
DCB is elsewhere in the data base and not labelled properly.
avoid this type of problem,
you
should
always
define
the

the

DCB

with

the

global

label

5-11

$xxDCB.

INCORPORATING A USER-SUPPLIED DRIVER

Each CTB
checked

is checked
and

and

relocated.

The

INTO RSX-11M-PLUS

following

offsets

are

both

relocated:

L.LNK

The 1link to the next CTB must be even.
If
1t
1is
not
zero, it must point within the data base, and
the CTB to which it points
must
1lie
within
the
data
base.
(Because it is highly unusual to have
two controller types in one driver data base, this

value

L.DCB

usually

zero.)

The address of the related DCB must be even, point
within
the
data
base,
and
the DCB to which it
points must lie within the data
base.
If
L.DCB
points
to
a
common
interrupt table, the common

interrupt entry point address in the table must be
even
and
1lie
within
the
Executive.
The
DCB
address(es) in the table must
be
even,
and
the
DCB(s)
to
which
each
address
points
must lie
within the data base.

L.KRB

Each pointer in the table of KRB addresses must be
even
and must point within the data base, and the
KRB to which each cell points must lie within
the
data

The

following

offsets

base.

the

CTB

are

checked:

L.NAM

The controller name cannot duplicate

L.NUM

The number of controllers must
(decimal)
.

entries

the

Each KRB is checked and relocated.
both checked and relocated:

resident

The

other

loadable data

following

1less

offsets

L.NAM

base.

than

the

KRB

are

K.OWN

The pointer to the owner
UCB
must
be
point
within the data base, or be zero.
nonzero, the pointer is relocated.

K.OFF

The start of the table of UCB
addresses
produced
from
K.OFF must be even and must point within the
data base.
The entries themselves must
be
even,
point
within
the data base, and the UCB to which
each

K.CRQ
K.CRQ+2

The

following

K.URM

cell

points must

lie

within

the

data

even
and
If it is

base.

The
1listhead
for
the
controller request
It is initialized to an empty list with the
word
zero,
and
the
second word pointing
first, relocated.
offset

the

KRB

queue.
first
to the

checked:

a multiprocessor

system,

the

UNIBUS

run

mask

for
and

the
<controller must have exactly one bit set
that bit must correspond to an exlstlng UNIBUS

run

(either

primary or

secondary).

LOAD puts each controller in the off-line state by setting the
KS.OFL
bit
in the K.STS byte.
Therefore, all controllers are off-line until
you use CON to place each one on-line.

INCORPORATING A

Each DCB is
checked and

checked and
relocated:

D.LNK

USER-SUPPLIED DRIVER

relocated.

The

D.UCB

offsets

are

both

The

following

offsets

D.NAM

link

The

the

DCB

device

specified
D.UCBL

The

pointer

show

that

Each

UCB

The

the

address

must

and

must

even

and

must

which

and the UCB
data base.

the

same

LOAD command

the

UCB

must

number

the

lie

dispatch

not

must

unit

forms

UCB

data base,
within the

checked:

the

highest

driver

is checked
and

name

D.UCBL

driver

first

the
lie

are

The .1ength

D.UNIT

1is
and
the

base.

point
within
it points must

checked

following

The link to the next DCB must be even.
If
it
nonzero,
it
must point within the data base,
the DCB to which it points
must
1lie
within

data

The

INTO RSX-11M-PLUS

last

within

table

that

even

and

(increased

address

all

the

data

(D.DSP)

which

you

line.
nonzero.

used

with

UCBs.

This

base.

set

=zero

loaded.

relocated.

The

following

offsets

are

both

DCB

that

relocated:

U.DCB

The

pointer

points
U.SCB

The

pointer

within

The

unit

the

DCB must

point

SCB must

the

UCB.

the

points must
U.RED

this

the

data

base,

lie within

redirect

even,

and

the

the data

pointer

must

SCB

point

which

base.
be

nonzero

and

even

if
it
1is
an Executive address.
If it is not an
Executive address, it must be nonzero,
even,
and
point
LOAD

places

the

CON

each

U.ST2
place

Each SCB is
checked and
S.KRB

unit

byte.

each

one

within
the

all

base.

state

units

are

setting

the

off-line

US.OFL

until

bit

you

use

on-line.

checked and
relocated:

relocated.

The

The pointer
within
the

points must

lie

data

off-line

Therefore,

nonzero,
base.

S.KTB

the

entry

the

data

there

must

table

point

bit

KRB

must

base,

within

must

preserves

following

zero

even,

and

the data

KRB

offsets

CTB

addresses

within

each

the

must

KRB

base.
the

1is

are

point

which

S.KRB

loadable

Each

data

present,

data base.

entry.)

both

each

(LOAD

entry

the
table
must also have a matching entry in the
table of KRB addresses of a CTB
in
the
1loadable
data base.

>-13

INCORPORATING

The

following

offsets

S.LHD

USER-SUPPLIED

each

S.PKT
last

After

the

driver

The
checks
data

end

base

1itself

address

to
at

initialized

the end
S.LHD.

pointer

the

1is

driver dispatch
dispatch
table
vector

are

INTO RSX-11M-PLUS

described:

The head of the I/0 queue is set to zero
pointer
to point

These

SCB

DRIVER

loaded

1loaded

the
and

and

into

the

queue

current

I/0

validating

validated

and

memory.

packet

of
no

the

wuse

higher

than

the

highest

set

the

correct

vector

controller

into

on-line.
Interrupt control
list starting at L.ICB in the

the

The

format of the
Section
4.5.1.

have

any

DDT

physical

nonzero,

device

least

one

labels

DDT.

The

values

even,

and

When

generic

the

for

the

entry
and

base

pseudo

the

S.KS5

fork

/CTB

The

CTB

CTB.

pointers
of

DCB

of
DCB

base

for

only

one

only

driver

define
that
reference the
in

vector

then

the

start

place

and

the

1linked

1in
not

offset

S.VCT/K.VCT

and

end

at.

The

two

the

interrupt

0 must be
the format

nonzero,
of DDT is

restores

and

therefore

checked.

nonzero

140000.

the

CTB(s)

DCBs

just

are

linked

the

block

number

driver

initialized.

RH70
a

system

device

The

DCB

the

end

front

PCB

address

the

first
address

data

base

word

and

of
the

the

DCB
the

D.PCB,

The

the driver
DDT.

table

KRBs

pointer

KRB

one

because

each

support

addresses

DCB

each

separate

controller

than

in
at

two
the

for

different

the

CTB,

different

device

supports
the different
the controller.
such

differs

controllers

addresses

can

controller

the
start

the

must

end

device

from

the

CTB

device

there

device

type.

types

one
ways

types.

pointer

must

have

Morever,

devices

necessarily

capable

split.
-

CTB
1is needed to describe the type of controller,
that supports a device on
that
controller
type
can

CTB.
The remaining
CTB defined for the

data

the

to
a

established.

D.DSP,

are

such

describe

one
driver
attached to

their

point

CTB, denoted in
loaded into the

First,

instead

table

syntax

you

to a
You

LOAD

for

Because

and

before

wvalue

entry

are

list

The

(the

block

controllers such

one

allowed

created

the

message,

links

the

address

Use

device.

DDT

5.4.2

data

the

not point
message.

checked.

DDT

must

and

error

all

put

KRB table in the
label $xxCTB, is

The

loaded,

of the
global

than
being

the

exits.

mapping

117777

1is,
not

The

range

driver

separate

found,

driver,

with
that
described
data base describes does

define

the

point.

$xXTBE must

LOAD prints

are

interrupt

The

Second,

one

Interrupt

first

contains

least

name(s)

data

standard

the

CTB.

(that
DDT

valid.

1list.

type.

the

controller

CTB

Some

base.

address

blocks

the

driver

driver)

that

must

lie

and

loadable

has

$xxTBL

inconsistent,
tables,

=zero),

interrupt

entry

consistent

controllers

equals

global

must
be
the device

S.VCT/K.VCT
the

set

table is validated, each interrupt entry in the driver
1is
1inspected,
and
the vector(s) are checked.
If a
is

CON

the

data

error

the
system (as specified at system generation) or does
nonsense interrupt entry point, LOAD prints a
warning
can

and

(S.LHD+2)

bases

can

LOAD command

drivers cannot
first driver.

loadable,

the

must

indicate

define a
Because

remaining
the
LOAD

CTB but must
drivers

all

drivers and the
routines
which

INCORPORATING A USER-SUPPLIED DRIVER INTO RSX-11M-PLUS

resident CTB to use.
(Of course, the driver data
base
that
defines
the
CTB
of
the
multidriver
controller
must
be loaded or already
resident before

the other drivers can be

loaded.)

The driver data base that defines the CTB
allows
for structures to define the data
resident.
In particular, for each device
slot in the CTB table of KRB addresses to

for a multidriver controller
base of drivers that are not
controller there must
be
a
hold the pointer to the KRB.
(A KRB must be defined to describe each occurrence of a controller.) A
zero
1s
in
the pointer for a device whose data base (and therefore,

whose KRB) is not resident.
Moreover, the table of DCB
addresses
1in
the
common interrupt table must have sufficient slots to point to the
DCBs of all device types that the controller supports.
A zero in
the
DCB table indicates no DCB exists (that is, the data base for a device
type

not

resident).

To load the
controller,

base
of
a
device
attached
to
the
multidriver
LOAD
routines
must
know
the controller name, the
location of the device on the MASSBUS controller and the KRB(s) of the
device(s)
whose
driver is to be loaded.
The /CTB syntax in the LOAD
command supplies the first two pieces of information.
For example:
>LOA

data
the

DR:/CTB=RHB,C

The letters RH are the name in the CTB already resident in the system.
LOAD
routines
search
the
system list of CTBs to locate the correct
one.
The letters B and C are the slots in the table of KRB
addresses
that
will
be
wused to link the resident CTB with the KRB in the data
base

being

loaded.

The name of the device DR reflects the name in the DCB that
1is
being
loaded.
An
empty slot in the table of DCB addresses in the resident
data base will be made to point to this DCB.
The LOAD routines need to find the correct KRB in the data base
being
loaded.
A
global label of the form $cca (where cc is the controller

name and a
the KRB(s)
above must

is the slot, or controller number)

The address(es)
the

CTB

must define the start of

being loaded.
Thus, the loadable data base
contain the labels $RHB and $RHC, which are

table

of the label(s)
KRB

loaded

into the

for the example
the KRB
names.
appropriate slot in

addresses.

In summary, then, the /CTB syntax on the LOAD
command
combined
with
the
global
1label(s)
allows
the LOAD routines to link a driver data
base being loaded with a currently resident
driver
data
Dbase.
The
KRB(s) being loaded are incorporated in the resident data base and the
DCB being loaded is connected to the common interrupt table.

CHAPTER

DEBUGGING

USER-SUPPLIED

DRIVER

Adding a user-supplied driver carries with it the risk of
introducing
obscure
bugs into an RSX-11M-PLUS system.
Because the driver runs as
part of the Executive, special debugging tools are both desirable
and
necessary.

into

You
If,

your

during

Crash

Executive

dump

provides

system

analysis

support

debugging

tool

not select any of this
however, you do require the

them

for

6.1

1incorporation
features and

the

CRASH DUMP ANALYSIS
crash

message

dump

analysis

such

aids,

which

can

incorporated

system

generation.

generation:

need

describe

The

RSX-11lM-PLUS

system

routine

(CDA)

(XDT)
software

facilities
your
system.

use

each

during

they offer, you can select
The
following
sections

debugging

aid.

SUPPORT ROUTINE
(CDA)

notification

CRASH

CONT WITH

support

device

SCRATCH

routine

specified

MEDIA

prints
system

device

the

following

generation:

mnemonic

You can
depress

then ensure that the secondary crash dump device is ready
and
the
CONT
switch
on
the operator's console.
The Executive
Dump routine will dump memory to the crash dump device and
halt

Crash
the

processor

The

the

upon

completion.

procedure

for

subsequently

memory

dump,

Analyzer

Reference

Manual.

6.2

EXECUTIVE

DEBUGGING

THE

An interactive
drivers,
and
XDT,

debugging
interrupt

version

Executive
data
that the system

invoking

documented

CDA,

the

which

reads
and
formats
RSX-11M/M-PLUS Crash Dump

TOOL

tool aids in debugging Executive modules, I/0
service routines.
This debugging aid, called

RSX-11

ODT.
Including
XDT
in
a
system
with
support does not reduce the size of pool space
have.
XDT occupies
physical
address
space
but

space

can
does
not
take up any Executive virtual data address space.
XDT also
does not interfere with user-level RSX-11 ODT, which can be used
with
any number of tasks while you are debugging your driver with XDT.

You can include
XDT
Options"
section
of

1in
a
system

system
during
generation when

asked:
Do

You

Want

Include

XDT?

[Y/N

6-1

D:N]

the
the

"Choosing
Executive
following question is

DEBUGGING A USER-SUPPLIED DRIVER

If you answer Y,
the

XDT is linked

into the Executive image when you build

Executive.

6.2.1

XDT Commands

XDT commands are generally compatible with RSX-11 ODT commands,
which
are
described
in
the IAS/RSX-11 ODT Reference Manual.
That manual,
together with the discussion in Section 6.2 in
this
manual,
can
Dbe
used

a guide

XDT operation on RSX-11M-PLUS.

XDT does not contain the

following commands available in ODT:

(Mask)

(Entry

Flag)

registers

(SST vector)

registers

(I/0

(SST data)

registers

$W -

(Directive

status word)

(Effective Address

(Fill

- (Not

(Restore

No W

(Memory word

LUN)

registers

Memory)

word

$DSW word

Search)

command

search)

command

SST vectors)

search)

command

In addition, the X (Exit) ODT command has been changed for XDT.
command causes a jump to the crash dump routine.

Except for the omitted

features and the change in the X

command,

The X

XDT

is
command-compatible
with RSX-11 ODT;
consequently, the IAS/RSX-11
ODT Reference Manual can be used as a guide to XDT operation.
XDT
includes
referencing.
referencing:

both
The

sets

address

references

Instruction

sets

address

references

Data

6.2.2

and
Data
control
the

When XDT starts up,
are

Instruction
space
following
commands

Data

XDT

the default condition

space
address
current address

space

is that

address

references

space.

Start

When you bootstrap a system
that
includes
XDT,
the
normal
system
startup
transfers
control
to
XDT,
which
identifies itself at the
system console terminal with the following message:
XDT:

<system

name

and

version>

DEBUGGING

If
by

no errors were
the prompt:

USER-SUPPLIED DRIVER

encountered,

the

identification message

the

conditions

followed

XDT>

The

following

XDT

CSR

address

LBN

the

system

image

LBN

the

system

image

R3
R4

= physical unit
= ASCII name of

runs

You can
passing
R5X-11

total

control

ODT

INITL

the

bootstrap

when

blocks

priority

read

level

the

image

7.
and
then
give
initialization

breakpoint,

printout

the

error

prefix

condition,

telling

condition

whether

a
G
command,
module
INITL.

similar

warning,

prints

the

before

you

can

rebootstrap

XDT has

your

condition

breakpoints to establish control or type the
the condition is fatal, the processor halts.

6.2.3

system

that

occurs.

encounters

condition

starts:

device

from

at this time,
the
Executive

reaches

XDT

device

number of the load
the load device

set breakpoints
control
to

preceded

fatal.

number

entirely

Whenever

are

error
is

control.

P
~

message

warning

You

can

set

command to
You
must

proceed.

correct

the

system.

XDT Restrictions

some

XDT
1.

types

when

systems,

first

All

systems

Some

data

pool

the

following

structures

not

are

not

set

and

bootstrapped

device

are

not

©Systems

Kernel

data

Data

with

space

restrictions exist

the

use

entered:

mapping

yet

console

The

secondary

terminal

and

the

on-line.

space

not

initialized.

the

support

vyet

set

up.

Certain

Executive

locations
that
the
Task
Builder could not resolve are not
initialized.
(The RH common interrupt table address ($SRHTBX)

does

not

<contain

the

common

interrupt

routine

address

(SRHALT)
.)
To

proceed

initial

when

XDT

you

encounter

prompt

you

such

should

restrictions

first

set

your

breakpoint

the

system,

near

INITL module (after the routine that sets up the data
Then, after you proceed and XDT encounters the breakpoint
of INITL, use XDT to examine locations in the
Executive
more

Executive

multiprocessor

When

system,

you

initially

prompt
from
processor's bit
2.

XDT

the

end

structures).
near the end
and

set

breakpoints.

you

should

aware

conditions:
1.

the

does

cannot
examine

not

place

that
in the

handle

a processor on-line,
processor
unless
vyou
$XDTPR word.

multiprocessor-specific

following

XDT
does
have
set

not
the

conditions.
You
can you easily

set processor-specific breakpoints nor
other processors' low memory context.

6-3

the

DEBUGGING A USER-SUPPLIED DRIVER

Under certain circumstances

(such as when Data space

1s not yet

set
up),
setting a breakpoint in shared Instruction space may
on
eventually cause a trap on a processor other than
the
one
which
vyou
set
the
breakpoint.
Consequently,
because
the

processor
encountering
the
breakpoint
does
not
have
that
breakpoint
in its XDT tables, XDT generates a breakpoint error
message (BE:) rather than a breakpoint message.
4.

6.2.4

All processors are locked out of the
Executive
being executed by one of the other processors.

XDT General

while

XDT

Operation

A forced entry to XDT can be executed at any time
from
a
privileged
terminal
by means of the MCR Breakpoint (BRK) command.
Thus, if your
system has no XDT restrictions as
described
in
Section
6.2.3,
the

normal
procedure is to type G when the system is bootstrapped without
setting any breakpoints.
When it becomes necessary to
use
XDT,
the
MCR
Breakpoint command is executed, causing a forced breakpoint.
XDT
then prints on the console terminal:
BE:XXXXXX

This message

followed by the prompt:

XDT>

You can then set breakpoints and issue other XDT
system operation by typing

All XDT command
List Memory (L)
line

the

Proceed

(P)

command

commands.

Continue

to XDT.

I/0O goes to and from the
console
terminal,
and
the
command can list on either the console terminal or the

printer.

XDT and Debugging a User-Supplied Driver

6.2.5

Using XDT to debug

problem that can arise

loadable

driver

is a T-bit error:

has

special

pitfalls.

One

TE:XXXXXX

XDT>

This error results when control reaches a
breakpoint
set,
using XDT, in a loaded driver.
The T-bit error,

expected BE:

error, occurs unless register

APR5

1is

that
you
have
rather than the

mapped

the

driver at the time XDT sets the breakpoint.

BPT
embedded
an
To avoid this T-bit error, assemble the driver with
instruction, or use either the ZAP utility or the MCR OPEN function to
BPT
the
with
code
of
word
a
replacing
by
breakpoint
the
set
the OPEN command in the following way to
use
You can
instruction.
access

the

>O0PE

driver:

nnnn/DRV=xX:

where nnnn matches the address in the driver map listing and xx is the

device
the

BPT

mnemonic.

(Write

instruction.)

down the instruction that you replace with

DEBUGGING

When control

reaches a

USER-SUPPLIED DRIVER

breakpoint

set

in the driver,

BPT

instruction

XDT prints:

BE :XxXXXXX

XDT>
Recover

follows:

Using XDT,

replace

the

with

the

desired

instruction.

Decrement the
register

Then

subtracting

from

the

contents

R7.

proceed

by using

the

P or

S commands.

NOTE

You should
than
one
Executive

not set
module
through

breakpoints
that
maps
APR

1in
1into

more
the

APR

particular,
do
not
set breakpoints in
more than one loadable driver at a
time
or
XDT
will
overwrite
words
of main
memory when it attempts to restore
what
it
considers
to
be
the
<contents
of
breakpoints.

6.3

FAULT

Four

causes

ISOLATION

can

identified

A user-state

system

The

user-supplied
the

The

system

The

host

the

system

when

task has

the

causes

When

system

faulted

faults:

such

a way

that

causes

fault.

driver

system

software

hardware

faults,

the

itself

has

you

has

faulted

such

way

that

fault.

has

faulted.

must

first

decide

which

these

four

causes is responsible.
This section presents some procedures that can
help you isolate the source of the fault.
Correcting the fault itself
is your responsibility.

6.3.1

Immediate

Servicing

Faults

manifest

themselves

increasing
l.

The

difficulty of

XDT

system

four

ways

(they

are

included,

displays

unintended

text

trap

indicating

halts.

The

system halts

but

displays

nothing.

The

system

unintended

loop.

listed

here

order

isolation):
to

XDT occurs.

crash

has occurred

and

DEBUGGING

The

A USER-SUPPLIED DRIVER

following discussions assume
least one debugging aid.

The

the

existence

system

built

with

immediate aim, regardless of the fault manifestation, is to get
point where you can obtain pertinent fault isolation data.

6.3.1.1

The

System Traps

XDT - The

trap may or

may not

intended

(for
example,
a
previously set breakpoint).
1If it is not intended,
type the X command, causing XDT to exit to location 40(8), from
which
the
CDA
support routine will be invoked.
1If, however, you have some
idea of the source of
the
problem
(for
example,
a
recent
coding
change), then you may use XDT to examine pertinent data structures and
code.

6.3.1.2
The System Reports a Crash - If the
text
displayed
on
the
console
terminal
consists
of
output
from the CDA support routine,
follow the procedure for obtaining and formatting
a
memory
dump
as
outlined in the RSX-11M/M-PLUS Crash Dump Analyzer Reference Manual.

6.3.1.3
any

The

System Halts but Displays No

action,

preserve

the

current

and

Information - Before
PC

and

the

pertinent

taking
device

registers (that is, examine and record the information these registers
contain).
The
procedure depends on the particular PDP-11 processor.
Consult the appropriate PDP-11 processor handbook for details.
After preserving the PS and PC, invoke your
resident
debugging
aid:
enter
40(8)
in
the switch register, press LOAD ADDR, and then press
START.
The contents of 40(8) cause the invocation of the CDA
support
routine.

6.3.1.4

The System

Halt

Record the
in Section

You may

then

attempt

must

first

the

PC,

locate
disable

the

bit

the

PS,

and

step

through

the

1loop.

the

programmable

Clear

follows:

any pertinent

device

registers,

6.3.1.3.

system

contents

line-frequency

Loop - Proceed

processor.

want

Examine

in an Unintended

For

clock.

<clock)

word
or

number

this

Proceed

777546

(if

word

instructions

attempt

772540

1in

be meaningful

you

follows:

your
(if

clock).

this

word

and

redeposit

the

word.

NOTE

Until
system

system

your

vyou
reenable
the
clock,
some
operations
do
not work because

they are waiting for time.
You can type
and
the system echoes typed characters.
You can input MCR commands.

system

has
has

a
a

DEBUGGING

USER-SUPPLIED

DRIVER

After trying to locate the loop and reenabling
location 40(8) as in Section 6.3.1.3.

6.3.2

Pertinent

Fault

Isolation

the

clock,

attempt to locate the fault, you should dump
SYSCM contains a number of critical pointers

CDA

dumps

the

SYSCM

area.

addition,

dynamic
and the

storage
region (system pool and, if
device tables.
The device tables are

point,

this

you have

The

stack

through

Pertinent

The

dynamic

The

device

System

These

data

the

following

should

dump

the

exists, the ICB pool)
the module SYSTB.

device

registers

storage

region

tables

common

represent

minimal

requirement

for

effectively

tracing

the

TRACING

Three
are

vyou

it
in

system
common
and listheads.

data:

fault.

6.4

Data

Before you
(SYSCM) .
always

transfer

FAULTS

pointers

described

SSTKDP

SYSCM

Stack

Depth

This data item
of
the crash.
origin

are

critical

fault

tracing.

These

pointers

below:

Indicator
indicates which stack was being
S$STKDP plays an important role

fault.
User

The

following

(task-state)

stack

values
or

used at
the
time
in determining the

apply:
privileged

task

user

state

0
If

the

less

stack

SHEADR

+1,

then

Pointer

the

Current

header

and

its

associated

the

task

The

location

vary

the

user

the Current Task Control
of

task

pointers

stack

TCB

The

the

System

depth

STKTCB - Pointer to
This

according

the

user-level

header

Task

and

whether

task

Header

pointers
the

the

has

crashed

Block
in

system.

(TCB)

control

the

CPU.

(Pool-Resident)
are

described

contents

task

the

has

below.

1its

external

associated

header.

DEBUGGING

USER-SUPPLIED DRIVER

task with an external header has its header attached in
contiquous
and
numerically
1lower location in memory.
nonexternal

header has
Therefore, a header in
header adjacent to the

Figure

6-1

shows

a
physically
A task with a

its header located
1in
Executive
pool
space.
Executive pool is a pool-resident header, and a
task is a non-pool-resident header.

the

interaction

header

©pointers

for

both

pool-resident and non-pool-resident headers.
For a pool-resident task
header, S$HEADR, $SAHPT, and $SAVSP all point to the first word of
the
task
header.
This
word also contains the user task's stack pointer
(SP) from the last time it
was
saved.
Figure
6-2
shows
a
brief
description of the task header.
The task header is fully described in
the RSX-11M/M-PLUS Task Builder Manual.

POOL-RESIDENT TASK HEADER (Non-external)

Virtual Header Addr.

l $HEADR

{ $SAVSP

l Saved Stack Addr.
|
l

! $SAHPT

Cu:en;'{ask
eader

~
|

Virtual Header Addr.

c—

—

Saved Stack Pointer
THDLN

lfiiSAHDB ~undefined value
NON-POOL-RESIDENT TASK HEADER (External)
.

Task

}

l $SAHPT 140000

Current Task

‘ $HEADR

Header

Executive

Data Area

l $SAVSP

1-word block J
Executive

{ $SAHDB - KISAR6
Figure

T HDLN 0
\

}—-——-{ Address resolution }-—

6-1:

Interaction

Task

Header

Pointers

The header (as pointed to by
$HEADR)
also
contains
register
set, just before the header guard word (the
header

The

four

pointed

H.GARD).

pointers associated with the header are:

SHEADR

S$SSAVSP

SSAHPT

S$SAHDB

the
last-saved
last word in the

DEBUGGING

A USER-SUPPLIED DRIVER

RS
PC

H.NLUN

H.GARD

H.HDLN

Length in bytes

SP
ZK-272-81

Figure

The pointers associated with

6-2:

Task

Header

pool-resident

header

are

described

SHEADR - Points to

the current task header.

The SHEADR word points to the pool-resident
task
header
of
the
task currently running.
The value in SHEADR is a kernel
virtual address in primary pool.

$SAVSP - Points to the first word of the current
contains

the

saved

stack pointer.

task

header,

which

SSAHPT - Points to the current task header in pool.
SSAHPT
contains
the virtual address of the header.
$SAHPT and S$HEADR contain
the

same virtual

SSAHDB - Contains an

address

for

a pool-resident header.

unknown value.

The pointers associated with a non-pool-resident header are

described

SHEADR - Points to the pointer for the saved stack pointer, S$SAVSP.
$SAVSP - Points to a 4-word block in the Executive data area.

SSAHPT - Contains the octal value of 140000 that is to

used

SSAHDB
to
resolve the address of the task's header.
always contains 140000 in this case.

6-9

with

$SAHPT

DEBUGGING

SSAHDB

- Contains the value
to be used
the task's

6.4.1
To

Tracing

trace

fault

Executive

failure

Executive.

the

module.

depth
A

call

the

also

stack

the

case

resolve

the

system

result

occur

within

crash-reporting

executed

which
S$SSAHPT

the

SST does

crash

Executive

display

(The
<crash
<call
zero or less.)

issued

value

stack

1is

occurs
in

depth
depth

internal

DRIVER

32-word

block-offset

the

address

SST

stack
an

the

less
fault

than
is

1is

Dispatcher

zero.
in

The

within

the

IOT

stack

structure

1in

R2
R1

Return to system exit
Zero or more SST parameters

SST fault code
-t

LZK-273-81

The

fault

codes

;ODD ADDRESS
;sMEMORY

Internal

are:

Structure:

;BREAK

; IOT

AND

PROTECT

POINT

TRAPS

VIOLATION

TRACE

TRAP

INSTRUCTION

; ILLEGAL
RSX

OR RESERVED INSTRUCTION
EMT INSTRUCTION

;NON

; TRAP

;11/40

;SST

ABORT-BAD

STACK

;AST ABORT-BAD

STACK

;ABORT

INSTRUCTION

FLOATING

VIA

POINT

DIRECTIVE

EXCEPTION

stack

6-3.

SST

Fault

EMT

Stack

instruction

Figure

when

origin
service

trap

6-3:

the

SST

Number of bytes

Usually

then

the
an

Dump

and

trap

issuing

less,

shown

stack

pointer.

Executive,

Directive

zero

SST-type

routine

the

and

Executive

initiated

Stack

Figure

examine

call

in KISAR6,

the

Using

after

first

USER-SUPPLIED

header.

Faults

contents,

the

with

DEBUGGING A USER-SUPPLIED DRIVER

26
30
32
34

; TASK
; TASK
; TASK
; TASK

LOAD READ FAILURE
CHECKPOINT READ FAILURE
EXIT WITH OUTSTANDING I/0
MEMORY PARITY ERROR

The PC points to the

instruction following the one that caused the SST

failure.
The
number
of bytes is the number normally transferred to
the user stack when the particular type of SST occurs.
If the
number
is

then a non-normal

transferred.

There

are

SST fault occurred,

and only the

PS and

PC are

SST parameters.

If the failure is detected in SDRDSP, the stack is the
same
as
that
shown
in
Figure
6-3, except that the number of bytes, the SST fault
code (the fault codes are listed above), and the
§SST
parameters
are
not

present.

One SST-type failure, stack underflow, does not result
1in
the
stack
structure of Figure 6-3.
To determine where the crash occurred, first
establish the stack structure;
this can be deduced by
the
wvalue
of
the
SP
and
the contents of the top word on the stack.
If the stack
structure is that of Figure 6-3, then the failure occurred
in $DRDSP,
or
was
a normal SST crash.
If the stack structure is that of Figure
6-4, then an abnormal SST crash has occurred.

PC
ZK-274-81

Figure

6-4:

Stack

Structure:

Abnormal

SST Fault

Abnormal
SST
failures
occur
when
it
1is
not
possible
to
push
information on the stack without forcing another SST fault.
When this
situation occurs, a direct jump to the crash-reporting routine is made
rather than an IOT crash.
The PS and PC on the stack are those of the
actual crash, and the
address
printed
out
by
the
crash-reporting
routine is the address of the fault rather than the address of the IOT
that crashes
the
system.
Note
that
the
<crash-reporting
routine
removes
the PC and PS of the IOT instruction from the stack, which in
this case is incorrect.
Thus, the SP appears to be four bytes greater
than

really is

(as

Figure

6-4).

You now have all the information needed to isolate the
cause
of
the
failure.
From
this
point
on,
rely
on
personal experience and a
knowledge of the interaction
between
the
driver
and
the
services
provided by the Executive.

6.4.2

Tracing Faults When the Processor Halts Without Display

To trace a fault when the processor halts but displays no information,
first
examine $STKDP, S$STKTCB, S$HEADR, $SAVSP, $SAHPT and $SAHDB.
The
stack
system
difficulty in tracing failures in this case is that the
is not directly associated with the cause of a

failure.

By examining $STKDP, you can determine the system state at the time of
failure.
If
it
was
in user state, the next step is to examine the
user's stack.
The examination
focuses
on
scanning
the
stack
for
that may be subroutine links that can ultimately lead to a
addresses

thread of events isolating the fault.

This is essentially the aim

looking at the system stack if SSTKDP is zero or less.
6-11

Frequently,

fault

Stack
(TOS)+4.
two items on the

DEBUGGING

can

that

This
stack

occur

USER-SUPPLIED

causes

fault results
are data.
The

then,
most
probably,
a
halt.
data items are on the stack when
points
to
a
word
<containing

DRIVER

the

point

from issuing an RTI
result
1is
a
wild

Top

when the
branch

top
and

Figure 6-5 shows a case in which two
the program
executes
an
RTI.
TOS
40100.
Suppose
that location 40100

contains a halt.
This indicates that the original SP was
four
bytes
below
the
final
SP,
and
fault
tracing
should
begin
from
the
original SP.

40100

:-:

SP
ZK-275-81

Figure

This
with

type

6-5:

Stack

fault also
1inconsistent

occurs

Structure:

Data

Items

Stack

when

an
RTS
instruction
However,
1in
that case,

stack.

1is
executed
SP points to

TOS+2.

A scan

to
the
leading

the

contents

the

general

neighborhood
in
which
a
up to the fault) occurred.

registers

fault

(or

may

give

the

sequence

some

hint

events

If the fault occurred in a new driver, a frequent source of
clues
1is
the buffer address and count words in the UCB (U.BUF, U.BUF+2, U.CNT),
as are the activity flags (US.BSY and S.S5TS).
Other locations in both
the

UCB

and

SCB

source

6.4.3

Tracing

trace

the

may also

provide

information

that

may help

locate

the

halt

the

fault.

Faults After

fault

when an

Unintended

unintended

Loop

loop has

occurred,

first

processor.

After you halt the
in
Section 6.4.2.
A

specific

data

processor, the same state exists as
was
discussed
Follow the same tracing procedure described there.

suggestion

check

successively duplicated

for

stack

overflow

loop.

the

stack

indicate

Patterns

stack

looping

item to check is the current (or last) I/0 Packet, the
of
which
1is
found in S.PKT of the SCB.
The packet function
defines the last activity performed on the unit.

address

failure.

6.4.4

Additional

Hints

for

Tracing

Faults

Another

(I.FCN)

If trouble occurred in terminating an
I/O
request,
a
scan
of
the
system
dynamic
memory
region may provide some insight.
This region
starts at the address contained in SCRAVL, a cell in
SYSCM.
Because
all
1I/0
packets
are built in system dynamic memory, their memory is
returned to the dynamic
memory
region
when
they
are
successfully
terminated.
Following
the
1link
pointers in this region may reveal
whether I/0 completion proceeded to that point.
1In systems
with
QIO
optimization,
S$PKAVL
(SYSCM)
points
to
a list of I/O packet-sized
blocks of dynamic memory that are not linked into the $SCRAVL chain.

6-12

DEBUGGING

USER-SUPPLIED DRIVER

A frequent error for an interrupt-driven device is to terminate an I/O
1I/0
on
properly disabled
not
1is
device
the
twice when
Packet
completion and an unexpected interrupt occurs.
This action ultimately
produces
a
double deallocation of the same packet of dynamic memory.
Double deallocation of a dynamic buffer causes a loop
in
the
module
SDEACB
on
the next deallocation (of a block of higher address) after
the second deallocation of the same block.
At that time,
R2
and
R3
both contain the address of the I/0 Packet memory that has been doubly
deallocated.
If XDT has been included in the system, the deallocation
routine
checks
for
bad
deallocation
and
crashes the system if it
occurs.

6.5

REBUILDING AND REINCORPORATING A LOADABLE DRIVER

After correcting and assembling the driver
source
and
updating
the
Executive object library, simply unload the old version, using the MCR
LOAD
the
wusing
it
command UNLOAD, task build the new one, and load

command.
are

shown

The commands for the assembler, Librarian, and Task Builder

Section

5.2.

Once loaded, the data base is not removed by the UNLOAD

command.

the
data
base is in error and cannot be patched, correct its source,
reassemble it, update the
Executive
object
1library
RSX11M.OLB
and

build

the

the driver

new driver task.

task

Then bootstrap the system before loading

image containing

the corrected data base.

CHAPTER

EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER

Because a driver is mapped within the Executive address space, it can
call Executive routines on the same basis as that of any other module
and
protocol
The driver must observe the
in the Executive.

The following sections
established on the system.
conventions
double word, tell what
address
the
describe
summarize the conventions,

special processing is required for NPR devices attached to a PDP-11
processor with extended memory support (22-bit addressing), and
summarize some of the typical Executive services available.

7.1

SYSTEM-STATE REGISTER CONVENTIONS

In system state, R5 and R4 are, by convention, nonvolatile registers.
This means that an internally called routine is required to save and
restore these two registers if the routine destroys their contents.
R3, R2, R1l, and RO are volatile registers and may be used by a called
routine without save and restore responsibilities.

When a driver is entered directly from an interrupt, it
at

interrupt

1level,

not

system state.

operating

At interrupt level, any

INTSVS generates
All drivers must

See the description of the driver dispatch table in

Section

4.5

maximum

physical

follow these conventions.

the contents of registers when a driver is entered.

7.2

for

THE ADDRESS DOUBLE WORD

RSX-11M-PLUS can accommodate

memory
words.
memory

is 2048K words.

configurations

whose

Individual tasks, however, are limited to 32K

The addressing is accomplished by using virtual addresses and
I/0 transfers, however, use physical
mapping hardware.

addresses 18 bits in length. Since the PDP-11 word size is 16 bits,
it
some scheme 1is necessary to represent an address internally until
encode
to
made
was
choice
The
n.
operatio
is actually used in an I/O
two words as the internal representation of a physical address and to
transform virtual addresses for I/0 operations into the internal
doubleword

format.

e
On receipt of a QIO directive, the buffer address in the Directivd
converte
is
address,
virtual
task
a
Parameter Block, which contains
to address doubleword format.

EXECUTIVE

The

SERVICES

virtual

address

Bits

through

Displacement

Bits

through

Block

number

Bits

Page

Address

The

through

internal

into
paragraphs.

The

base

relocation

in
the
virtual

the

structured

the

represents

32-word

collection

doubleword
by

second

through

was

cleared.

1is
the

computed,

the

processor's

word
of

Number

specified

Finally,

of PAR #6, which
transfer devices.

the

in
6

placing
into

the
is

task

first

DRIVERS

FOR NPR

DEVICES

USING

and

memory

devices

block (bits 0
block number
through
12
are
15 to enable use

service

address

I/0

for

program

requirements
are discussed

for
with

EXTENDED MEMORY

the

PDP-11

for

non-MASSBUS

PDP-11

processor

must

NPR
with

perform

transfers by using UNIBUS Mapping Registers (UMRs) as described
in
PDP-11 Processor Handbook.
One UMR is required for each 4K
words

involved

the

the UCB.
When
contiguous.
A

NPR

viewed

the

The

through

features must
be
built
into
drivers
(nonprocessor
request)
devices
attached
to a
extended-memory support (22-bit addressing).

I/0
the

in the
address

QIO directive

bits

Special

Non-Extended

memory

the

number

the

time

For nonprocessor request (NPR) devices, the
driver
manipulating
the address doubleword are direct and
the description of U.BUF in Section 4.4.4.

7.3

PAR

number

registers.

through

following

the

displacement

bits

uses

the

issuing

word

placed

Executive

the

bits

virtual

the

block
word
of

management

this
in

the

block

that

blocks

(PAR#)

described

32-word

Note

32-word

restructures
as

PAR

user's

address)

accommodated

nth

memory

formed

virtual

the

blocks.

DRIVER

follows:

terms

doubleword

contained

I/O

virtual address in the DPB is added to
address.
The result becomes the first

field

TO AN

translation

address

doubleword.

mapped

DPB

RSX-11M-PLUS

address

The

AVAILABLE

driver

can

transfer

multiple

assigned

Dynamically

UMRs

specified

are

required

for

one

UMRs

through

any

the

contents

transfer,

three

allocating

UMRs

for

the

duration

Dynamically allocating

UMRs

for

longer

periods

Statically

transfer,

allocating

UMRs

during

system

than

for

the

procedures

longer

necessary
can
result
blocking
of
other
drivers
reduction in system throughput.

U.CNT

in
be

procedures:

the

time,

generation.

NOTE

In large systems, use
above
to
hold
UMRs

they must

periods

in
and

the
a

data

EXECUTIVE SERVICES AVAILABLE TO AN I/0 DRIVER

7.3.1

Calling $STMAP and $MPUBM or $STMPl and $MPUB1

To obtain UMRs through use of the $STMAP and $MPUBM or the S$SSTMP1
SMPUB1 routines, a driver must:
e

Have available six words for
a
block
in
the
22-bit
working
controller request block (KRB).

mapping
register
assignment
storage
area of the device's
1is
area
this
of
end
The

accessed
by
adding
the
contents of K.OFF to
K.CSR.
If the driver uses $STMPl and
S$MPUBl,
have available a 10-word block

e
e

Call the routine $STMAP

Address)

atter getting

Call the routine SMPUBM

before

initiating

the

7.3.1.1

data

UNIBUS

(Set

$MPUBl1

(Map

UNIBUS

These requirements are detailed in the
Note
that
these
routines
are
only
performing

the address at
it
must
also

$STMP1l

I/O packet

transfer

transfer.

and

Mapping
Memory)

following
three
subsections.
required
when
the
driver is

Allocating a Mapping Register Assignment Block - The

controller
request
block
(KRB)
of
an NPR device requires a 6-word
mapping register
assignment
block
1located
in
the
22-bit
working
storage
area.
It
does
not
have
to
be initialized.
Any initial
contents are simply overwritten.

The following example shows
assignment
- BLKW

the

allocation

mapping

block.
M.LGTH

;UMR WORK AREA

If the driver does not support parallel NPR operations
requiring
UMR
mapping,
it calls $STMAP and $MPUBM.
If the driver supports parallel
NPR operations requiring UMR mapping, it must call $STMPl and
SMPUBI.
In
the
latter
situation,
the
six
additional
words in the 22-bit
working storage area are not used
but
must
still
be
present.
In
addition, the driver data base must provide a 10-word mapping register
assignment block for each data transfer to be mapped as
specified
in
the description of $STMP1l later in Section 7.4.31.

7.3.1.2
Calling $STMAP or $STMP1 - In
entry point, after the call to SGTPKT,

the
<coding
at
the
1initiator
the NPR-device driver must call
routines
dynamically
allocate

the routine $STMAP or S$STMPl.
These
required
UMRs.
If UMRs are not available

blocked.

Such blocking,

it occurs,

not blocking

has

occurred.

immediately, the driver

completely

transparent

1is

the driver.
The driver resumes processing at fork level when the UMRs
have been allocated.
The register returns
are
absolutely
identical
whether

UNIBUS
a
$STMAP or $STMP1l stores into U.BUF and U.BUF+2 (in the UCB)
address that causes the appropriate UMR to be selected for mapping the
transfer.
The call to $STMAP or S$SSTMP1
must
be
conditionalized
on
MSSEXT.

7.3.1.3
Calling $MPUBM or S$MPUB1 - Before executing the transfer, the
driver
must
call
$MPUBM or $SMPUBl.
These routines get the buffer's

EXECUTIVE

22-bit

physical

transfers

are

must

$SMPUB1

address

mapped

SSTMP1

and

$MPUB1l,

before

Calling

Use of
always

the

it must

SIOALT).

1In

call

SIODON

$ASUMR

procedure
allocated.

allocated all
longer
than

load

directly

TO AN

I/O

DRIVER

the

UNIBUS

mapping

registers

the

task's

space.

The

call

that
$SMPUBM

$STMAP and $MPUBM, the UMRs allocated
to
it
are
the call to $SIODON or S$IOALT.
If the driver calls

calling

7.3.2

and

AVAILABLE

conditionalized
on M$SEXT.

If the driver calls
deallocated
during
UMRs

SERVICES

and

$DEUMR

deallocate

$IOALT.

allocated

$DEUMR

described

Section

7.3.3

However,

driver

may

of the time,
the
normal

such cases,

any

assures

not

and yet require UMRs
time-frame
between

there

third

that

require

UMRs

are

for
periods
of
time
$GTPKT
and $SIODON (or

procedure

for

allocating

UMRs.

Through

use

dynamically
UMRs.

the

Executive

allocate,

Refer

retain

Section

7.4

routines

over
for

$SASUMR

desired

and

descriptions

routines.

Similar to the
also
requires

storage

the

$STMAP/SMPUBM procedure, the use of
the allocation of a 6-word mapping

block.
1In this instance, however,
the
22-bit working storage area.
attempt

$DEUMR,

time-frame,

deallocate

area.

the

UMRs

avoid

assignment block could
7-1 details the format

be
of

the

block

$IODON

this

block

driver

$ASUMR

SASUMR

must

not
be
$IOALT, when

found

the

dynamically allocated
the 6-word block.

from

M.LNK

Link Word

M.UMRA

Address of first assigned UMR

M.UMRN

Number of assigned UMRs "4

M.UMVL

Low 16 bits mapped by first assigned UMR
High 6 bits of

High 2 bits mapped by

M.BFVH

physical buffer address

UMR (in bits 4 and 5)

S$DEUMR

and
$DEUMR
assignment
located

called,

in
will

22-bit

working

mapping

the

M UMVH

can

deallocate
and

deallocation,

MBFVL

and

pool.

Figure

Low 16 bits of physical buffer address
ZK-276-81

Figure

7.3.3

7-1:

Mapping

Statically Allocating

UMRs

During

Assignment

Block

System Generation

UMRs can be statically assigned during system generation.
generation procedure defines the symbol N$SUMR equal to a

UMRs,

Before

multiplied
assembling

allocation
assembly

prefix
then be increased
multiplied by 4.

by
the

that

are

statically

Executive,

additional

number

file
RSXMC.MAC.
to represent the

the

UMRs

user

The value
additional

assigned
can

cause

editing
of the
number

The

system

fixed number
the
system.

the

static

Executive

symbol N$SUMR can
of
desired
UMRs

EXECUTIVE 'SERVICES AVAILABLE TO AN I/O DRIVER

The Executive assembly prefix file RSXMC.MAC further defines the
following three symbols, which describe the first UMR statically
allocated during system generation:

page

I/0

The

USSMLO

The low-order 16 bits

USS$SMHI

available for allocation to the user

the

18-bit

UNIBUS

The high-order 2 bits of

the

18-bit

UNIBUS

mapped by this UMR

these 2 bits are in bit positions 4 and 5

These three symbols are not used

available for the user's infcrmation.

7.4

the

system

UMR

first

the

address

USSMRN

itself.

address

address;

They

are

SERVICE CALLS

This section contains general commentary on the Executive routines
typically used by I/0 drivers. The descriptions of the routines are
taken from the source code of modules linked to form the Executive.
Table 7-1 summarizes the routines described in this section. Only the
other
however, many
most widely used routines are described;
related
the
for
code
source
The
available.
are
services
Executive
routines is in the MACRO-11 source files for the Executive modules.
Table

7-1

Summary of Executive Service Calls for Drivers
Routine

Location

Name

UFD [11,10]

Function

SACHKB
SACHCK

EXSUB
EXSUB

Adress check for byte-aligned buffers
Address check for word-aligned buffers

SASUMR

MEMAP

Assign UNIBUS mapping registers

$BLXIO
SCKBFI
SCKBFR
SCKBFW
SCKBFB
SCLINS
SCVLBN
SDEACB

BFCTL
EXESB
EXESB
EXESB
EXESB
QUEUE
MDSUB
CORAL

Move block of data
Check I/0 buffer
Check I/0O buffer
Check I/0 buffer
Check I/0 buffer
Clock queue insertion
Convert logical block number
Deallocate core buffer

$DVMSG
SFORK

I0SUB
SYSXT

Device message output
Create a fork process

SALOCB

$BLKCK
$BLKC1
SBLKC2

SDEUMR
$FORK1

CORAL

MDSUB
MDSUB
MDSUB

MEMAP
SYSXT

Alocate core buffer

Check logical block number
Check logical block number
Check logical block number

Deassign UNIBUS mapping registers
Fork but bypass clearing timeout count

SGTBYT
SGTPKT

BFCTL
I0SUB

Get byte
Get an I/0 packet

SGTWRD

BFCTL

Get word

SGSPKT

SINIBF
SINTSV
SINTXT

I0SUB

I0SUB
SYSXT
SYSXT

Get a special I/0 packet

Initiate I/0 buffering
Interrupt save and restore
Interrupt exit
(continued

on next page)

EXECUTIVE

SERVICES

AVAILABLE

Table

Summary

Routine
Name

Location
UFD

MEMAP

SPTBYT
SPTWRD
SQINSP
SRELOC

BFCTL
BFCTL
QUEUE
MEMAP

SREQU1

$SSTMAP

I0OSUB
I0OSUB
IOSUB
MEMAP

MEMAP
I0SUB

I0SUB

MEMAP

I/0

DRIVER

for

Drivers

(Cont.)

Service

Calls

[11,10]

SIOALT
SIODON
SIOFIN
SMPUBM
SMPUB1

SRELOP
SREQUE

7-1

Executive

TO AN

Function

Alternate entry to $IODON
I/0 done for completing an I/0 request
I/0 finish for special I/0 completion
Map UNIBUS memory
Alternate SMPUBM entry for parallel
operations

Put byte
Put word
Queue insertion by priority
Relocate address
Relocate UNIBUS physical address
Queue kernel AST to task
Queue kernel AST to task

Set up UNIBUS mapping address

$STMP1

MEMAP

Alternate S$STMAP entry for parallel

STSPAR

REQSB

Test

operations

STSTBF

IOSUB

for

if partition memory resident
kernel

Test for

AST

I/0 buffering

EXECUTIVE SERVICES AVAILABLE TO AN I/0 DRIVER

"$ACHKB
$SACHCK
Address Check

7.4.1

A driver can call either
These routines are in the file 1IOSUB.
the task is the current
while
address-check a task buffer
routine to
task. The Address Check routines are normally used only by drivers
setting UC.QUE in U.CTL.

Calling

See Section 8.3 for an example.

Sequences:

CALL

SACHKB

CALL

SACHCK

Description:
4+

; **_SACHKB-ADDRESS CHECK BYTE ALIGNED
; **_SACHCK-ADDRESS CHECK WORD ALIGNED
H

; THIS ROUTINE IS CALLED TO ADDRESS CHECK A BLOCK OF MEMORY TO SEE WHETHER
; IT LIES WITHIN THE ADDRESS SPACE OF THE CURRENT TASK.
H

;

INPUTS:

;

;
:
H

;

RO=STARTING ADDRESS OF THE BLOCK TO BE CHECKED.
R1=LENGTH OF THE BLOCK TO BE CHECKED IN BYTES.
OUTPUTS:

:
:

C=1 IF ADDRESS CHECK FAILED.
C=0 IF ADDRESS CHECK SUCCEEDED.

;
H
H

R2=ADDRESS OF WINDOW BLOCK MAPPING BUFFER
(FOR PRIV TASKS SEE NOTE.)

;

RO AND R3 ARE PRESERVED ACROSS CALL.

;
;
;
:
;

NOTE:

SINCE PRIVILEGED TASK I/0 BUFFERS ARE NOT ADDRESS
CHECKED, R2 ALWAYS RETURNS A POINTER TO THE FIRST
WINDOW BLOCK.
CHECKPOINTING AND SHUFFLING OF COMMONS
WILL STILL WORK PROPERLY PROVIDED THAT A PRIVILEGED
TASK NEVER SPECIFIES AN I/O0O INTO A COMMON WHICH IT
ALLOWS TO REMAIN CHECKPOINTABLE AND SHUFFLEABLE.

Notes:

use
the
to
all
is,
rather than queueing the
<¢IOFIN,
calls
and
the buffer
fills
via
1is completed
transfer ,which
a
starting
and/or
packet
In RSX-11M-PLUS Version 2.0, almost all drivers will wish to
the alternate routines $CKBFB/SCKBFW which correctly maintain
addition
in
I/0 count mechanism
attachment and partition
1If the driver completes
wuser buffer.
the
checking
address
(that
routine
initiation
the
references to the buffer in
interrupt

service)

then it

is permissible to use SACHKB/SACHCK.

See Section 7.4.6 for a description of SCKBFB/SCKBFW and

8.3 for

an example.

Section

EXECUTIVE SERVICES AVAILABLE TO AN

I/O DRIVER

SALOCB
7.4.2
This

Allocate
routine

Calling

Core
in

Buffer

the

file CORAL.

Sequences:

CALL

SALOCB

CALL

SALOC1

CORE

BUFFER

wxe$SALOC1=ALLOCATE

CORE

BUFFER

(ALTERNATE

ENTRY)

Wl
g

ALGORITHM

ROUTINE

BYTES,

CALLED

FIRST

FIT

ALLOCATE

AND

BLOCKS

ARE

EXEC

CORE

BUFFER,

ALLOCATED

THE

ALLOCATION

IN MULTIPLES

FOUR

INPUTS

RA=ADDRESS

THIS

*2«$ALOCB=ALLOCATE

}

Description:

R1=SIZE

THE

CORE

ALLOCATION

CORE BUFFER

LISTHEAD=2

TO ALLOCATE

ENTRY

IN BYTES,

$ALOCH,

THE

BLOCK,

OUTPUTS:

IF
IF

INSUFFICIENT
THE BLOCK IS
RusADDRESS

R1sLENGTH

CORE IS AVAILABLE
TO ALLOCATE
ALLOCATED,
OF

THE

BLOCK

C=1
Csd

7-8

ALLOCATED

BLOCK,

EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER

$ASUMR
Assign UNIBUS Mapping Registers

7.4.3

It is used only for PDP-11/70 NPR
This routine is in the file MEMAP.
UNIBUS Mapping Registers when 22-bit memory
requiring
devices

addressing is enabled. Normally, it is not called directly by an I/O
Rather, it is called from within the $STMAP routine. Refer
driver.
to Section 7.3 for a discussion.

Calling

Sequence:

CALL

$ASUMR

wke$ASUMR«ASSIGN

UNIBUS

MAPPING

REGISTERS

THIS ROUTINE IS CALLED TO ASSIGN A CONTIGUOUS SET OF UMR’S,
FOR THE SAKE OF SPEED,

NOTE THAT

THE LINK WORD OF EACH MAPPING ASSIGNMENT BLOCK

POINTS TO THE UMR AOQDRESS (2ND) WwORD OF THE BLOCK, NOT THE FIRST wWORD,
THE CURRENT STATE OF UMR ASSIGNMENT IS REPRESENTED BY A LINKED LIST OF
MAPPING ASSIGNMENT BLOCKS, EACH BLOCK CONTAINING THE ADDRESS OF THE
FIRST UMR ASSIGNED AND THE NUMBER OF UMR’S ASSIGNED TIMES 4,
THE
BLOCKS ARE LINKED IN THE ORDER OF INCREASING FIRST UMR ADDRESS,
INPUTS?

RP=POINTER

T0D A MAPPING REGISTEw

M OUMRN(R¢)SNUMBER

uUMK’S

ASSIGNMENT BLOCK,

WREQUIRED

QUTPUTS:

ALL

REGISTERS

C=a

ARE

PRESERVED,

wlp

N§

Description:

THE

ARE

THE

w¥
g
Sl

UMR’S wEKE SUCCESSFULLY

C=1

ASSIGNED,

ALL FIELDS OF THWE MAPPING REGISTER ASSIGNMENT BLOCK

Thmg

INITIALIZED AND THE BLOCK

ASSIGNMENT

uMR*S COULD NOT mE

LIST,

ASSIGNED,

IS LINKED INTO

EXECUTIVE

SERVICES

AVAILABLE

TO AN

I/0

DRIVER

output

from

$BLKCK
$BLKC1
$BLKC2
7.4.4
This

Check

Logical

routine

used
block

Block

the

file

MDSUB.

by disk

drivers

numbers

transfers.

Calling

data

input

The
the

$CVLBN

this

routine

handle

logical

Sequence:

CALL

SBLKCK

CALL

$SBLKC?2

**_SBLKCK-LOGICAL BLOCK CHECK ROUTINE
**-SBLKC1-LOGICAL BLOCK CHECK ROUTINE
**-SBLKC2-LOGICAL BLOCK CHECK ROUTINE

(ALTERNATE
(ALTERNATE

ENTRY)
ENTRY FOR

QUEUE OPT)

THIS

AND

ENDING

LOGICAL

STRUCTURED

DEVICE.

Description:

ROUTINE

DRIVER'S

ENTERED WITH

DRIVER

CALLED

I/O

DEVICE

NUMBERS

THE

FINAL

INITIATOR

RANGE

DRIVERS
AN

I/0O

BLOCKS

STATUS

"IE.BLK"

POINT

EXECUTED.

ENTRY

CHECK

TRANSFER

NOT

AND

ELSE

THE

STARTING
FILE

LEGAL,

THEN

RETURN

$IODON

THE

EXECUTED.

SBLKC2 RETURNS TO S$QOPDN IN

THE

BLOCK

OPTIMIZATION

INITIATOR
CODE

$DRQRQ

IF THERE IS AN ERROR INSTEAD OF

ENTRY

POINT.
BLKCK

USE

THIS

ALLOWS

THE

QUEUE

INPUTS:

I/0

PACKET.

R5=ADDRESS

THE

UCB.

OUTPUTS:

W
Me

THE CHECK FAILS, THEN
"IE.BLK" AND A RETURN

SIODON

THE

DRIVER'S

EXECUTED.

THE

ENTERED WITH A

THEN

THE

FOLLOWING

FINAL

INITIATOR

STATUS

ENTRY

POINT

ARE

RETURNED

R1=POINTS
R2=HIGH

R3=ADDRESS

SUCCEEDS,

RO=LOW

CHECK

WmE

IF
OF

R1=ADDRESS

®HE

DRIVER'S

PART

LOGICAL

I.PRM+12
OF

LOGICAL

I/0O

REGISTERS

BLOCK NUMBER.
(LOW PART OF USER
BLOCK

PACKET.

NUMBER.

LBN)

Wi,

EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER

$BLXIO
Move Block of Data

7.4.5

This routine is in file BFCTL.
Sequence:

Calling

CALL

SBLXIO

THIS ROUTINE IS CALLED TO MOVE DATA IN MEMORY IN A MAPPED SYSTEM.
INPUTS:

RO=NUMBER OF BYTES TO MOVE.
R1=SOURCE APR5 BIAS.
R2=SOURCE DISPLACEMENT.

R3=DESTINATION APR6 BIAS.
R4=DESTINATION DISPLACEMENT.

OUTPUTS:

RO ALTERED
R1,R3 PRESERVED

NOTE:

. WA

ME WS

DESCRIBED MOVE IS ACCOMPLISHED.

WS WS WE

e NG N

TMM We

** - SBLXIO-MOVE BLOCK OF DATA.

s e

g s

Description:

R2,R4 POINT TO LAST BYTE OF SOURCE AND DESTINATION + 1
THE COUNT INPUT IN RO MUST NOT BE ZERO AND IT MUST NOT
BE LARGE ENOUGH TO CROSS APR BOUNDARIES (THIS TYPICALLY

MEANS A MAXIMUM

7-11

4K-63).

EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER

$CKBFI
$CKBFR
$CKBFW
$CKBFB
7.4.6

Check

These

routines

Calling

I/0 Buffer
are

file

EXESB.

Sequences:

CALL

SCKBFB

(or

appropriate

entry

name)

**-SCKBFI-CHECK I/O BUFFER FOR
**-SCKBFR-CHECK

I-SPACE

(OVERLAY)

I/0 BUFFER FOR READ-ONLY

(BYTE)

**-SCKBFW-CHECK I/0 BUFFER FOR READ-WRITE

(WORD)

**.SCKBFB-CHECK

I/0 BUFFER

FOR READ-WRITE

ACCESS

(BYTE)

ACCESS

THESE

ASSOCIATED WITH

N§F

THE

ADDRESS

WME

THE

ATTACHMENT

Description:

ROUTINES

WILL

ONE

CALLED

THE

CHECK
OF

TO ADDRESS

CURRENT

(UNDER

PASSES,

THEN

DESCRIPTOR
THE

CHECK

ATTEMPT

POINTERS

FOLLOWING

I/0O

CONSTRUCTION)
AT

THE

BUFFER
I/O

MADE

PACKET.

POINT

ASSOCIATED ADB.

ONE
THIS

OUTCOMES:

THERE

CURRENTLY

ADB,

THE A.IOC,

THE

AND THE

- THERE

NO ATTACHMENT

POINTERS

P.IOC

"NORMAL"

AREN'T

FIELDS

SUCCESSFUL

ALREADY

UNTOUCHED,

W NS

%we

-s

HAVE

ARE

ONE

ARE

FOR

POINTER

FULL.

THIS

THE

POINTER

I/0O

ARE

TO THIS

ADB.

PACKET TO

THIS

FILLED

AND

THIS

INCREMENTED.

CASE.

POINTER

THE A.IOC

AND

P.IOC

THE

PACKET

FIELDS,

IS CONSIDERED SUCCESSFUL. THE IMPLICATION OF
A.IOC AND P,.IOC IS THAT DRIVERS AND ACPS MAY

AND THE
NOT
NOT

IS
CHECK

INCREMENTING
RELEASE

BUFFERS FOR AN I/0 REQUEST ONE AT
A TIME, I.E. THE DRIVER
SHOULD NOT CALL S$DECIO DIRECTLY, BUT SHOULD CALL S$IODON OR

- THERE ARE ALREADY TWO

DESCRIPTOR.

$DECAL AFTER ALL BUFFER ACCESS HAS COMPLETED.

WITH

CARRY

POINTERS,

NONE

CONSIDERED A

CHECK

THEM

TO THIS

FAILURE

AND

ATTACHMENT

RETURN

SET.

INPUTS:

WME

RO=STARTING

MADE

THIS

R1=LENGTH

ADDRESS

BLOCK

BUFFER

CHECKED

SATTPT=ADDRESS OF I.AADA IN CURRENT I/O PACKET

wmy

HEADER

THE

SUBJECT

TASK

PACKET

UPDAT

MAPPED

THROUGH

KISARG6

OUTPUTS:

CHECK AND
I.AADA

A.IOC,

P.IOC

C=0

C=1

CHECK

I.AADA+2

SUCCESSFUL
POINTS

THE

ADB

INCREMENTED

UNSUCCESSFUL

PACKET

COULD NOT

FILLED

EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER

SCLINS
Clock Queue Insertion

7.4.7

This routine is in the file QUEUE.
Calling

Sequence:

SCLINS

CALL

NE ME WE W WP WS Wy e NE We N W W e s NE WE WE NE e e WE wE Ng s LT 1]

o 1 ]

Description:

*%_$CLINS-CLOCK QUEUE INSERTION

ENTRY
THIS ROUTINE IS CALLED TO MAKE AN ENTRY IN THE CLOCK QUEUE. NGTHETIME.
ASCENDI
IN
ORDERED
IS
QUEUE
CLOCK
THE
IS INSERTED SUCH THAT
THUS THE FRONT ENTRIES ARE MOST IMMINENT AND THE BACK LEAST.
INPUTS:

RO=ADDRESS OF THE CLOCK QUEUE ENTRY CORE BLOCK.

R1=HIGH ORDER HALF OF DELTA TIME.
R2=LOW ORDER HALF OF DELTA TIME.
R4=REQUEST TYPE.

R5=ADDRESS OF REQUESTING TCB OR REQUEST IDENTIFIER.

OUTPUTS:

THE CLOCK QUEUE ENTRY IS INSERTED IN THE CLOCK QUEUE ACCORDING
TO THE TIME THAT IT WILL COME DUE.
NOTE:

ON MULTIPROCESSOR SYSTEMS, A REQUEST WITH TYPE C.SYST!100000

WILL BE EXECUTED ON A PRATICULAR UNIBUS RUN, WITH URM
SPECIFIED IN C.URM. TYPE C.CYST REQUESTS ON MP SYSTEMS ARE
DEFAULTED TO RUN ON ANY UNIBUS RUN, WHICH IN PRACTICE WILL
RESULT IN THE REQUEST EXECUTING ON THE CPU WHICH OWNS THE
CLOCK.

($SCKURM)

EXECUTIVE SERVICES AVAILABLE TO AN

I/0 DRIVER

$CVLBN
7.4.8
This
same

Convert
routine
as

the

Logical

output

the

Block Number
file MDSUB.

from

the

calls this routine to convert
disk
address.
The
routine
data base unit control block.

and

cylinder

parameters

description of the
Calling

U.PRM

for

The

$BLKCK

input

routine.

this

routine

Typically,

disk

logical block
number
to
a
physical
accesses the U.PRM fields in the driver
These fields contain the sector, track,
the type of disk supported.
Refer to the

fields

LOGICAL

BLOCK

Section

4.4.4.

Sequence:

CALL

SCVLBN

NUMBER

THIS SUBROUTINE

~TO

wILL CONVERT

SECTOR/TRACK/CYLINDER

INPUT S

(SAME

e wE WA WE WS WS WA WE WS we e

R2s_OW PART 0OF LBN

S$BLKCK

OUTPUTS)

R2sHIGH PART OF LBN
R3I=1/0 PACKET ADDRESS
RS=UCB ADDRESS
QUTPUTS

RAsSECTOR NUMBER
RISTRACK NUMBER
R2sCYLINDER

NUMBER

DISK

PARAMETERS

THE SPECIFIED LOGICAL BLOCK

ADDRESS,

Description:

**=$CVLBN=CONVERT

the

driver

NUMBER

EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER

$DEACB
7.4.9

Deallocate Core Buffer

This routine is in the file CORAL,
sequences:

Calling

CALL

SDEACB

CALL

SDEAC1

¢+

*»2=SDEACB=DEALLOCATE

CORE BUFFER
wae$DEACI=0EALLOCATE CORE BUFFER

(ALTERNATE ENTRY)

THIS ROUTINE

IS CALLED

TO DEALLOCATE

AN EXEC

CORE

BUFFER,

THE BLOCK

INSERTED INTO THE FREE BLOCK CHAIN 8Y CORE AODRESS, IF AN ADJACENT
RLOCK IS CURRENTLY FREE, THEN THE Tw0 BLOCKS ARE MERGED AND INSERTED
IN THE FREE BLOCK CHAIN,
INPUTSE
RAzZADORESS
Ri=SIZE OF
QI=ADDRESS

OF THE CORE BUFFER TO BE DEALLOCATED,
THE CORE BUFFER
TO DEALLOCATE IN BYTES,
OF CORE ALLOCATION LISTHEAD=2 IF ENTRY AT

SDEACY,

QUTPUTS

THE CORE BLOCK IS MERGED INTO THE FREE CORE CHAIN BY CORE
ADDRESS ann 1S AGCOMERATED IF NECESSARY wITr ADJACENT BLOCKS,

Description:

7-15

EXECUTIVE

7.4.10

This

Deassign

routine

requiring

UNIBUS Mapping

UNIBUS

Normally, it
called
from
discussion.

Calling

SERVICES AVAILABLE

the

file

Mapping

not called
within
the

I/O DRIVER

Registers

MEMAP.

Registers

TO AN

when

used

only

22-bit

for

NPR

is enabled.
Rather,
it
is

directly

by an I/0 driver.
routine.
Refer to Section

$IODON

devices

addressing

7.3

for

Sequence:

CALL

SDEUMR

Description:
s ¢

*x=$DEUMK=DEASSIGN

;

THIS

THE

NOTE

THE

ROUTINE
MAPPING
THAT

UMR

CALLED

ASSIGNMENT

FOR

THF

ADDORESS

LNIBUS

SAKE

(2ND)

MAPPING

REGISTERS

NEASSIGN

BLOCK
OF

NOT

CONTIGUOUS
IN

ASSIGNMENT

WORD

THE

BLOCK

UMR*S,

THE

LIST,

ACTION

SPEED,

THE

LINK

WORD

ASSIGMNMENT

TAKEN,

POINTS

BLOCK,

; INPUTS
.

R2=POINTER

;
s

QUTPUTS

’ -

ASSIGNMENT

gLOCK,

AND

ARE

PRESERVED,

7-16

EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER

$DVMSG
Device Message Output

7.4.11

Device Message Output is in file IOSUB.
Sequence:

Calling

SDVMSG

CALL

“‘ifi.“‘.“"‘.”Qf“"“‘fl'.“fi.“““‘t

Description:

+xe$DVMSG=DEVICE

“ESSAGE OUTPUT

E CALLED TO SUBMIT A MESSAGE TO THE TASK FTERMINATION
THIS ROUTINIS

NOTIFICATION TASK, MESSAGES ARE EITHER DEVICE RELATED OR A CHECKPOINT
WRITE FAILURE FROM THE LOADER,
INPUTSS

R2aMESSAGE

NUMBER,

RSsADDRESS OF THE UCB OR TCB THAT THE MESSAGE APPLIES TO,

OUTPUTSS

A FOUR WORD PACKET 1S ALLOCATED, R@ AND RS ARE STORED IN THE

SECOND AND THIRD WORDS RESPECTIVELY, AND THE PACKET IS THREADED
INTO THE TASK TERMINATION NOTIFICATION TASK MESSAGE GUEUE,
NOTE: IF THE TASK TERMINATION NOTIFICATION TASK IS NOT INSTALLED
OR NO STORAGE CAN BE OBTAINED, THEN THE MESSAGE REQUEST
1S

IGNORED,

Note:

Drivers use only two codes in calling $DVMSG:

ready)

and

called as

T.NDSE

follows:

MOV

#T .NDNR,
RO

MOV
CALL

#T.NDSE,RO
SDVMSG

(select

error) .

SDVMSG

T.NDNR (device not

can be set up and

EXECUTIVE

SERVICES

AVAILABLE

TO AN

I/O DRIVER

$FORK
7.4.12

Fork

the

file

SYSXT.

driver

partially

interruptable

1level

interruptable

level.

fully

Calling

calls

(its

state

$FORK

following

switch

from

call

$INTSV)

sequence:

CALL

SFORK

u‘."’fi"“h.“"”‘cfifli‘!‘*“&

Description:

**e$FORKeFORK

THIS
WILL

AND

CREATE

SYSTEM

PROCESS

ROUTINE IS CALLED FROM AN I/0
RETURN TO THE DRIVER AT STACK

DRIVER TO CREATE A SYSTEM PROCESS
DEPTH ZERO TO FINISH PROCESSING,

THAT

INPUTS
RS3ADDRESS

THE

UCB

FOR

THE

UNIT

@(SP)=RETURN

ADDRESS

2(SP)=RETURN

ADDRESS

TO CALLERS

CALLER,

BEING

PROCESSED,

CALLER,

QUTPUTS
REGISTERS
A

SYSTEM

QUEUE

AND

ARE

PROCESS

CREATED,

SINTXT

AND

JUMP

SAVED

SFORK cannot be called

called

assumes

that

S$SINTSI

A driver's

SFORK.

the

THE

FORK

LINKED

S$INTSV
The

has

timeout

set

count

the

has

BLOCK

AND

THE

FORK

EXECUTED,

run.

protects

CONTROLLER

PROCESS

wunless

has

Executive

current

This

IN
THE

been

previously

fork-processing
up

entry

1is

driver

routine

conditions.

cleared

from

calls

problems that can occur when an I/0O request and
the
for
that
request
happen
at the same time.
After

from a

call

$FORK,

driver's

entered.

If the clearing of the
has two alternatives:
a.

Perform

the

timeout

clock

timeout

operations

queue

SCLINS routine).
b.

Perform

necessary

S.STS

not

count

(refer

code

not

directly

initialization,

the

will

desired,

inserting

timeout
return

not

driver

elements

description

including

the

clearing

1in the SCB to zero (establishing the controller as
busy), and call the $SFORK1 routine rather than $FORK.

Calling

timeout
The

timeout

synchronization

driver

SFORK1l

bypasses

the

<clearing

count.
must

SFORK is called.

not

have

any

information on

the

current

stack

when

EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER

$FORK1
7.4.13

Forkl

A driver calls $FORK1l to bypass the
Forkl is in the file SYSXT.
clearing of its timeout count when it switches from a partially
the
interruptable level to a fully interruptable level (refer also to
description of the $FORK routine).
Calling

Sequence:

SFORK1

CALL

aha§FORK{=FORX

AND CREATE

SYSTEM PROCESS

THIS ROUTINE IS AN ALTERNATE ENTRY TO CREATE A SYSTEM PROCESS AND
SAVE REGISTER

RS,

INPUTSS

RUsADDRESS OF THE
RS=REGISTER TO BE

LAST w0ORD OF
SAVED IN THE

A 3 ~ORD FORK
FORK BLOCK,

BLOCK PLUS

OUTPUTS

REGISTER KRS IS SAVELR IMN THE SPECIFIED FORK BLOCK AND A SYSTEM
PROCESS IS CREATED, TWE PwOCESS IS LINKED TU THE
AND & JUMP TO SINTXT IS EXECUTED,
R5

PRESERVED

FOR

CALLERS

FORK QUEUE

CALLER,

Description:

A S5-word fork block is required for calls to S$FORK1l.

initialize
When a 5-word fork block is used, the driver must
fifth word with the base address (in 32-word blocks) of
the
the
This address can be obtained from
the driver partition.
fifth word of the standard fork block in the SCB.

The driver must not have any information on
SFORK1 is called.

the
|

stack

when

EXECUTIVE

SERVICES AVAILABLE

TO AN

I/0 DRIVER

$GTBYT
7.4.14
Get

Get

Byte

the

UCB.

U.BUF+2

Calling

sequence:

CALL

file

BFCTL.

Get

KYTE

USEW

Byte

manipulates

words

U.BUF

and

$SGTBYT

‘Q“‘.‘Q‘Q‘*‘Qfi!““fi.‘.‘!‘l“.“

Description:

ke GTBYTeGET

“EXT

FROMTM

BUFFEK

THIS RQUTINE IS CALLED TO GET THE NEXT BYTE FROM THE USER BUFFER
AND RETURKN IT TG THE CALLER ONM THE STACK, AFTER THE BYTE HAS BEEN
FETCHED,

THE

RYTE

ADDRESS

INCREMENTED,

INPUTS
RS=ANDDRESS

THE

UCHB

THAT

CONTAINS

THE

BUFFER

POINTERS,

QUTPUTS
THE NEXT BYTE
Tu THE CALLER

FETCHED

THE

ALL

ARE

REGISTE~S

FROM

STACK,

PRESERVED

THE

USER

ACROSS

BUFFER

BYTE

CALL,

AND

ADDRESS

RETURNED
IS

INCREMENTED,

EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER

$GTPKT
$GSPKT
Get

7.4.15

Packet

The
Get Packet and Get Special Packet are in the file IOSUB.
recommended way to use $GTPKT is to use the GTPKTS$ macro call defined
in Section 4.3. Usage of SGSPKT is described briefly 1in Section
l.4.7.

Calling

Sequences:

CALL

SGTPKT

CALL

$GSPKT

Description:
; +

** _SGTPKT-GET I/0 PACKET FROM REQUEST QUEUE
** _SGSPKT-GET SELECTIVE I/0 PACKET FROM REQUEST QUEUE

THIS ROUTINE IS CALLED BY DEVICE DRIVERS TO DEQUEUE THE NEXT I/O REQUEST TO

PROCESS. IF THE DEVICE CONTROLLER IS BUSY, THEN A CARRY SET INDICATION IS
RETURNED TO THE CALLER. ELSE AN ATTEMPT IS MADE TO DEQUEUE THE NEXT REQUEST
FROM THE CONTROLLER QUEUE. IF NO REQUEST CAN BE DEQUEUED, THEN A CARRY
SET INDICATION IS RETURNED TO THE CALLER. ELSE THE CONTROLLER IS SET BUSY AND
A CARRY CLEAR INDICATION IS RETURNED TO THE CALLER.

IF QUEUE OPTIMIZATION IS SUPPORTED AND ENABLED FOR THE DEVICE
THE APROPRIATE PACKET FOR THE CURRENT OPTIMIZATION ALGORITHM
THREE ALGORITHMS ARE SUPPORTED: NEAREST CYLINDER,
1S RETURNED.
ALL THREE ALGORITHMS INCORPORATE A
ELEVATOR, AND C-SCAN.
IF THE FIRST PACKET ON THE LIST IS PASSED OVER
FAIRNESS COUNT.
MORE THAN "FCOUNT" TIMES, IT IS DONE IMMEDIATELY.
THE ALTERNATE ENTRY POINT $GSPKT IS INTENDED FOR USE BY DRIVERS WHICH
SUPPORT PARALLEL OPERATIONS ON A SINGLE UNIT, A COMMON EXAMPLE BEING
SUCH DRIVERS ARE EXPECTED TO LOOK TO THE SYSTEM AS IF
FULL DUPLEX.
THEY ARE ALWAYS FREE, WHILE MAINTAINING THE STATUS OF ALL PARALLEL
OPERATIONS INTERNALLY WITHIN THEIR OWN DEVICE DATA STRUCTURES.

PARALLELISM IS ACCOMPLISHED BY HANDLING DRIVER-DEFINED CLASSES OF I/0
FOR EXAMPLE A FULL-DUPLEX
FUNCTION CODES IN PARALLEL WITH EACH OTHER.
DRIVER WOULD HANDLE INPUT REQUESTS IN PARALLEL WITH OUTPUT REQUESTS.
A DRIVER CALLS S$GSPKT WHEN IT WANTS TO DEQUEUE A PACKET WHOSE I/O
WHICH FUNCTIONS QUALIFY IS
FUNCTION CODE BELONGS TO A CERTAIN CLASS.
DETERMINED BY AN ACCEPTANCE ROUTINE IN THE DRIVER WHOSE ADDRESS IS

PASSED TO S$GSPKT IN R2.

FOLLOWING THREE ACTIONS:

RETURN WITH CARRY CLEAR IF THE PACKET SHOULD BE
1IN THIS CASE $GSPKT PROCEEDS AS S$GTPKT
DEQUEUED.

NORMALLY WOULD ON DEQUEUEING THE

%e
WE
W
e
e

THE ACCEPTANCE ROUTINE IS CALLED BY S$GSPKT

EACH TIME A PACKET IS FOUND IN THE QUEUE WHICH IS ELIGIBLE TO BE
THE ACCEPTANCE ROUTINE IS THEN EXPECTED TO TAKE ONE OF THE
DEQUEUED.

whk

We W

s W

PACKET.

RETURN WITH CARRY SET IF THE PACKET SHOULD NOT BE
IN THIS CASE S$GSPKT WILL CONTINUE THE SCAN
DEQUEUED.
OF

THE

I/O

QUEUE.

EXECUTIVE

SERVICES AVAILABLE

TO AN

I/O

DRIVER

SGTPKT
$GSPKT (Cont.)
s

ADD THE CONSTANT GS$S$SSPSA TO THE STACK POINTER TO ABORT
SCAN WITH

FURTHER

ACTION.

INTENDS

FOLLOWING

TO MODIFY.
WHEN A PACKET IS DEQUEUED VIA
NORMAL SGTPKT ACTIONS DO NOT OCCUR:

S$SGSPKT,

THE

THE ACCEPTANCE ROUTINE MUST SAVE AND RESTORE ANY REGISTERS WHICH IT

THE

FILLING

U.BUF,

AVAILABLE

FOR

U.BUF+2

AND

DRIVER-SPECIFIC

U.CNT.

THESE

FIELDS

USE.

ARE

BUSYING

UCB

AND

SCB.

EXECUTION OF

SCFORK TO GET TO PROPER PROCESSOR

(MULTI-

SYSTEMS)
.

NOTE:

SGSPKT MAY NOT BE
QUEUE

USED BY
A DRIVER WHICH SUPPORTS

OPTIMIZATION.

INPUTS:

DRIVER'S

R5=ADDRESS

THE

UCB

ACCEPTANCE ROUTINE
OF

THE

CONTROLLER

(IF CALL AT

TO GET A

S$GSPKT).

PACKET

OUTPUTS :

C=1

CONTROLLER

C=0

BUSY OR

REQUEST CAN

THE

UNIT

I/O

PACKET.

INDEX.
THE STATUS

R5=ADDRESS

THE

UNIT

CONTROL

BLOCK.

R3=CONTROLLER
R4=ADDRESS OF
OF

DEQUEUED.

NUMBER.

R2=PHYSICAL

SUCCESSFULLY

REQUEST WAS

R1=ADDRESS

FOR.

TM,

R2=ADDRESS

wms

-y

PROCESSOR

NOTE:

R4 AND R5

ARE

DESTROYED BY

THIS ROUTINE.

DEQUEUED.

EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER

$GTWRD
7.4.16

Get Word

Get Word is in the file BFCTL.
in

the

It manipulates words U.BUF and U.BUF+2

UCB.

Calling

Sequence:

SGTWRD

CALL

xxkeSCTWRDeGETY

w(ORD FrO“ USER

QBUFFER

THIS KOUTINE 15 CALLED TO GET THE NEXT wORD FROM THE USER BUFFER
AND RETURN IT 10 THE CALLE% ON THE STACK, AFTER THE WORD HAS BEEN
FETCHED, THE MNEXT wORD ADDRESS IS CALCULATED,
INPUTS?

RG2ADDRESS OF THE UCH THAT CONTAINS THE BUFFER POINTERS,
OUTPUTS:

THE NEXT wORD IS FETCHED FROM THE USER BUFFER AND RETURNED

TO THE CALLER ON TME STACK, THE NEXT wWORD ADDRESS IS CALCULATED,

ALL REGISTERS ARE PRESERVED ACROSS CaLlL,

we ol

%“F

“§

-l

Description:

7-23

EXECUTIVE

7.4.17

This

1Initiate

routine

Calling

SERVICES AVAILABLE TO AN

I/0O

DRIVER

I/O0 Buffering

the

file

IOSUB.

Sequence:

CALL

SINIBF

**-SINIBF-INITIATE I/0 BUFFERING
THIS

ROUTINE

INITIATES

I/O

BUFFERING

DOING

THE

FOLLOWING:

DECREMENT THE

TASK'S

I/0 COUNT.

INCREMENT

TASK'S

BUFFERED

INITIATE CHECKPOINTING

THE

I/O

COUNT

IF A REQUEST

INPUTS:

R3=ADDRESS

I/0

OUTPUTS:

%Ws

TMy

w§

Description:

PRESERVED.

PACKET

FOR

I/O

REQUEST.

PENDING

EXECUTIVE SERVICES AVAILABLE TO AN I/0 DRIVER

SINTSV
Interrupt Save

7.4.18

The recommended way to
Interrupt Save is in the file SYSXT.
d in Section 4.3.
describe
call
macro
INTSVS
the
use
SINTSV is to
Calling

use

Sequence:

SINTSV, PRn

CALL

n has a

range of 0-7.

5‘““‘Q‘.‘CQQ*'”N"‘HO“‘.“QOWI“.“““”%“‘Q‘C

Description:

*axwS INTSVe INTERRUPT

SAVE

x2e$INTSE=INTERRUPT SAVE FCR ERRORLOGGING DEVICES

THIS ROUTINE IS CALLED FROTM AN INTERRUPT SERVICE ROUTINE wHEN AN
INTERRUPT IS NOT GOING TO BE IMMEDIATELY OISMISSED, A SWITCH TO

THE SYSTEM STACKk 1S EXECUTED IF THE CURRENT STACK DEPTH I8 +1, WHEN

THE INTERRUPT SERVICE ROUTINE FINISHES ITS PROCESSING, IT EITHER FORKS
, JUMPS TO SINTXT, OR EXECUTES A& RETURN,
INPUTS

4(SP)SPS wORD PUSHED 8Y INTERRUPT,
2(SP)sPC WORD PUSHED RY INTERRUPT,
2(SP)=SAVED RS PUSHED BY *JSR RS,SINTSV®,
Q(R5)=NEw PROCESSOR PRIORITY,
OUTPUTS

A SWITCH TO THE SYSTEM STACK IS EXECUTED, THE NEw PROCESSOR
STATUS IS SET AND A CO=ROUTINE CALL TO THE CALLER IS EXECUTED
R4 IS SET WITH THE CONTROLLER INDEX%2, WHICH IS OETERMINED
FROM THE

PSW

ENTRY,

Note:

A system macro, INTSV$, is provided to
standard interrupt entry processing.

simplify

the

See Section 4.3.

<coding

EXECUTIVE

SERVICES AVAILABLE TO AN

I/0 DRIVER

SINTXT
7.4.19

Interrupt

Interrupt
Calling

Exit

Exit
in

the

file

SYSXT.

Sequence:

JMP

SINTXT

Description:
' e

;

**=SINTXT=INTERRUPT

EXIT

: THIS ROUTINE MAY BE CALLED VIA A JMP TO EXIT FROM AN INTERRUPT,
P INPUTS
;
3(SP)=INTERRUPT SAVE RETURN ADDRESS,
; OUTPUTS
;
A RETURN TO INTERRUPT SAVE 1S EXECUTED,

7-26

EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER

SIOALT/SIODON
7.4.20

I/0 Done Alternate Entry and I/0 Done

These routines are in the file IOSUB.
Calling

Sequences:

CALL
CALL

SIOALT
SIODON

x*=$I0ALT=1/0 DONE
xx«$J0ODCN=1/0

DONE

(ALTERNATE ENTRY)

THIS ROUTINE IS CALLED BY DEVICE DRIVERS AT TwE COMPLETION OF AN I/0 REGUEST
TO DO FINAL PROCESSING, THE UNIT AND CONTROLLER ARE SET IDLE AND SIOFIN IS
ENTERED TO FINISH THE PROCESSING,
INPUTS¢

wuE

Description:

ResFIKRST

170 STATUS

wWORD,

W§

R1=SECOND I/0 STATUS wORD,
R22STARTING AND FINAL ERROR RETRY

COUNTS

IF ERROR LOGGING

DEVICE,

RS=ADDRESS OF THE UNIT CONTROL BLOCK OF THE UNIT BEING COMPLETED,

) TM@9S

(SP)=RETURN ADDRESS TO DRIVER’S CALLER,

IF ENTRY IS AT SIOALT, THEN Ri IS CLEAR TO SIGNIFY THAT THE
SECOND STATUS w(QRD IS ZERO,

OJTPLTS

THE URKIT AND CONTROLLER AWE SET IDLE,
#~33ADCRESS 0OF

THE CUuRRENT

I/0 PACKET,

NOTE:

Note:

R4 is destroyed when either of these
routines
routines call $IOFIN, which destroys R4.

1is

«called.

The

These routines push the address of routine $SDQUMR onto the

stack

This precludes the use of the
the driver.
to
returning
before
these
stack for temporary data storage by drivers when calling
routines.

EXECUTIVE

SERVICES AVAILABLE

TO AN

I/0

DRIVER

$IOFIN
7.4.21

1I/0

Finish

I/0
but

Finish is in the file IOSUB.
Most drivers do not call I/0 Finish,
you
should
be aware that this routine is executed when a driver
calls SIOALT or SIODON.
A driver that references an I/0 packet before
it
is
queued
(bit UC.QUE set--see Section 8.3 for an example) calls
I/0 Finish if the driver finds an error while
preprocessing
the
1I/0

packet.

Calling

Sequence:

CALL

SIOFIN

Description:

’

*x=$JOFIN=e]/0

THIS

ROUTINE

CONTROLLER

170

HAS

HAD

FINISH

CALLEDL

ARE

NOT

RECENY

TO
BE

FINISH

I/0

OECLARED

MAPPING

PROCESSING

IDLE,

CHANGE

wWHICH

THE

MAY

CASES

TASK

HAVE

WHERE

THE

WHICH

ISSUED

UNMAPPED

ITS

UNIT

AND

THE

I/0

s STATUS BLOCK, THE 1/0 PACKET 1S QUEUED TO THE FRONT OF ITS AST QUEUE
s

COMPLETED

LATER

SFINBF

CALLING

SIOFIN

AGAIN,

. INPUTSI
’

REsFIRST

R{=SECOND

1/0

R3zADDRESS

STATUS

I/0 STATUS
OF

THE

WORD,

wWORD,

1/0

REQUEST

PACKET,

: OUTPUTS|
H

;
1

;

;
H

'
;

THE

FOLLOWING

1=THE

FINAL
ONE

2=ALL

ACTIONS

I/0 STATUS
WAS

T3,MPC

INDICATE

CHANGE,
3e1F

*TS,CKR’

THE

4eIF

TASK

CLEARED

THE

THAT

THE

I/0

SET,

THEN

TASK

COUNT

TASK,

ELSE

SIGNIFICANT

EVENT

EQUIVALENT

DESTROYED

THIS

NOTEs

I/0

WENT

CLEARED

SERVICE

SeA

1/0 STATUS BLOCK

COUNT

ZERO

GOES

AFTER

ZERO

MAPPING

AND CHECKPOINTING OF

INITIATED.,

THE

’
;

IN THE

ARE DECREMENTED AND TS,RDN IS
TASK WAS BLOCKED FOR I/0 RUNDOWN,

AST

;

’fl

ARE STORED

FOR

;

VALUES

ASSOCIATED I/0 COUNTS
CLEARED IN CASE THE

;

PERFORMED

SPECIFIED,

:
H

ARE

ROUTINE

wAS
THE

SPECIFIED,
1/0

PACKET

ROUTINE,

THEN
IS

AST

DEALLOCATED,

DECLARED.

GUEVED

EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER

$SMPUBM
Map UNIBUS to Memory

7.4.22

This routine is in the file MEMAP.
requiring

enabled.

UNIBUS

It is used only

for

NPR

devices

Registers when 22-bit memory addressing is

Mapping

See Section 7.3 for a discussion.

Sequence:

Calling

SMPUBM

CALL
Description:
3+

ak=SMPUBMeMAP UNIBUS

TO MEMORY

;

j THIS ROUTINE IS CALLED BY UNIBUS NPR DEVICE DRIVERS TO LOAD THE
$ NECESSARY UNIBUS MAP REGISTERS TO EFFECT A TRANSFER TO MAIN MEMe

§ ORY ON AN {1/70 PROCESSOR WITH EXTENDED MEMORY,
,

t
!

H
!

s
}

INPUTS1
RUmADDRESS

DEVICE SCB,

RSaADDRESS OF OEVICE ucCB,
OUTPUTSS

THE UNIBUS AP REGISTERS NECESSARY TO EFFECT THE
ARE

LOADED,

$ NOTEt REGISTER R3 IS PRESERVED ACROSS CaLL,
’J

TRANSFER

EXECUTIVE

SERVICES AVAILABLE TO AN

UNIBUS

Memory

I/O DRIVER

$MPUB1
7.4.23

Map

(Alternate

This routine is in file MEMAP.
require

UNIBUS

Mapping

enabled

and

Calling

Sequences:

for

support

CALL

Entry)

It is used only for NPR

Registers
when
22-bit
parallel operations.

devices

that

memory addressing

SMPUB1

Description:

’+

}
\‘Q“Q\.‘Q.{“\QQQ“"M‘.““»”

*we§MPUBI=MAP

UNIBUS

MEMORY

(ALTERNATE

ENTRY),

THIS ROUTINE IS CALLED BY UNIBUS NPR DEVICE DRIVERS TO LOAD
THE
NECESSARY UNIBUS MAP REGISTERS TO EFFECT A TRANSFER TO MAIN
MEMORY ON AN 11/72 PROCESSOR WITH EXTENDED MEMORY, THIS ALTERNATE
ENTRY POINT ALLOWS TWE DRIVER TO SPECIFY A NON=STANDARD UMR
MAPPING
ASSIGNMENT

RBLOCK,

INPUTS3
Re=ADDRESS

UMR

MAPPING

ASSIGNMENT

BLOCK,

DUTPUTS

NOTE:

THE UNIBUS TMMAP REGISTERS
TRANSFER ARE LOADED,

NECESSARY

"EGISTER

ACROSS

PRESERVED

EFFECT

THE

CALL,

EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER

$SPTBYT
Put

7.4.24

Byte

Put Byte is in the file BFCTL. Put Byte manipulates words

U.BUF

and

U.BUF+2 in the UCB.
Calling

Sequence:

SPTBYT

CALL

“"““”“fl“““““fl“fl““fl“

Description:

txe$PTRBYT=PUT NEXT BYTE

IN USER BUFFER

THIS ROUTINE IS CALLED TO PUT A BYTE IN THE NEXT LOCATION IN

USER BUFFER, AFTER THE BYTE HMAS BEEN STORED, THE NEXT BYTE ADDRESS
IS

INCREMENTED,

INPUTS

THE BUFFER POINTERS,
RSSADDRESS OF THE UCB THAT CONTAINS

2(SP)=BYTE TO BE STORED IN THE NEXT LOCATION OF THE USER BUFFER,

OUTPUTS:

THE BYTE IS STORED IN THE USER BUFFER AND REMOVED FROM
THE STACKX, THE NEXT BYTE ADORESS IS INCREMENTED,

ALL REGISTERS ARE PRESERVED ACROSS CALL.

7-31

EXECUTIVE SERVICES AVAILABLE TO AN I/0 DRIVER

$SPTWRD
7.4.25

Put Word

Put Word is in the file BFCTL.

the

Calling

UCB.

It manipulates words U.BUF and U.BUF+2

Sequence:

CALL

SPTWRD

«x=$PTWRD=PUT

WORD

USER

BUFFER

THIS ROUTINE IS CALED TO PUT A WORD IN THE NEXT LOCATION IN

USER BUFFER, AFTER
IS CALCULATED,

THE

WORD MAS

BEEN STORED,

THE

RS5®ADDRESS
2(SP)=WORD

OF THE UCB THAT CONTAINS
TO BE STORED IN THE NEXT

THE BUFFER POINTERS,
LOCATION OF THE BUFFER,

QUTPUTS
THE
THE

WORD IS STORED IN THE USER BUFFER AND REMOVED
STACK, THE NEXT WORD ADDRESS IS CALCULATED,

ALL

REGISTERS

ARE

PRESERVED

NEXT WORD ADORESS

INPUTS¢

NE NS WE N

WS W

BE W

e WS

Description:

7-32

ACROSS

CALL,

FROM

EXECUTIVE SERVICES AVAILABLE TO AN I/0 DRIVER

$QINSP
7.4.26

Queue Insertion by Priority

This routine is in the file QUEUE.

A driver may call $QINSP to insert

I/0 queue an I/0 packet that the Executive has not already
the
into
only by
wused
Queue Insertion by Priority is
placed in the queue.

drivers setting UC.QUE in U.CTL.
Calling

See Section 8.3 for an example.

Sequence:

SQINSP

CALL

x%e$QINSP=QUEUE INSERTION BY PRIORITY

AN ENTRY IN A PRIORITY ORDERED
THIS ROUTINE IS CALLED TO INSERT

LIST, THE LIST IS SEARCHED UNTIL AN ENTRY IS FOUND THAT HAS A
LOWER PRIORITY OR THE END OF THE LIST IS REACHED, THE NEW
ENTRY IS THEN LINKED INTO THE LIST AT THE APPROPRIATE POINT,

INPUTS 1

RPEADDRESS OF THE TWO WORD LISTHEAD.,
R1sADDRESS OF THE ENTRY TO BE INSERTED,

OUTPUTST

IS LINKED

R® AND R1

ARE PRESERVED ACROSS CaLL,

THE ENTRY

WME UN

BE BT

Description:

INTO THE LIST By PRIORITY.

EXECUTIVE

SERVICES AVAILABLE

TO AN

I/O DRIVER

SRELOC
7.4.27

Relocate

Relocate
task

in the

wvirtual

file MEMAP.

address

while

normally used only by drivers
8.3 for an example.
Calling

A driver may call

the

task

setting

the

$RELOC to

current

UC.QUE

task.

U.CTL.

relocate
a
Relocate

See

Section

Sequence:

CALL

SRELOC

‘.’i.‘t‘(“‘fl“”“.“.““““‘

Description:

*4=SRELOC-RELOCA
USER
TE

THIS

ROUTINE

INTO

CALLED

RELOCATION

BIAS

VIRTUAL

TO
AND

ADDRESS

TRANSFORM

DISPLACEMENT

BIT
IN

USER

BLOCK

VIRTUAL
RELATIVE

INPUTS
ROSUSER

VIRTUAL

ADDRESS

RELOCATE,

OUTPUTS?

R{zRELOCATION BIAS TO BE LOADED INTO PARG,

R22DISPLACEMENT
R3

AND

ARE

IN BLOCK PLUS

PRESERVED

ACROSS

14P@@@
CALL,

(PAR6 BIAS),

ADDRESS
TO

APReé,

EXECUTIVE SERVICES AVAILABLE TO AN I/0 DRIVER

SRELOP
7.4.28

This

Relocate UNIBUS

routine

Calling

in the

Physical Address

file MEMAP.

Sequence:

CALL

SRELOP

*xoSRELOP=RELOCATE

UNIBUS PHYSICAL

ADDRESS

THIS ROUTINE RELOCATES A UNIBUS PHYSICAL ADDRESS TO A KISARG

Description:

BIAS

DISPLACEMENT,

INPUTSS

ROsBYTE

OFFSET

RUsSCB

ADDRESS

AND

RSsUCB

ADDRESS

FROM

ADDRESS

U,BUF+1

ORDER

BITS

WS
S

UsBUF+2(RS)=LOwW
OUTPUTS:

KISAR6SCALCULATED

U,BUFe2

UsBUF+
1 (RS)=HIGH ORDER BITS OF PHYSICAL ADDRESS

RisREAL

AND

ADDRESS

BIAS

(MAPPED

DISPLACEMENT

SYSTEM)

PHYSICAL

ADDRESS

EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER

‘SREQUE
$REQU1
7.4.29
This

Queueqkernel AST to Task

routine

Calling

in module

IOSUB.

Sequence:

CALL

SREQUE

CALL

SREQU1

Description:
: +

(ALTERNATE ENTRY)

THESE ROUTINES ARE USED TO QUEUE A TASK KERNEL AST WHICH HAS BEEN
USED AS

~COUNT

REGION

THE

TASK

LOAD AST

BACK AS
A TASK AST. THE BUFFERED
DECREMENTED IF ENTRY AT S$REQUE.

RO0=TCB

R3=ADDRESS

ADDRESS

ASSOCIATED

PACKET

OUTPUTS:
NONE.

Tes WH

INPUTS:

WsH

WhH

; **-SREQUE-REQUEUE A REGION LOAD AST TO A TASK AST
; **-SREQU1-REQUEUE A REGION LOAD AST TO A TASK AST

7-36

TASK

QUEUED

I/O

EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER

$STMAP
Set Up UNIBUS Mapping Address

7.4.30

NPR devices
This routine is in the file MEMAP. It is used only for addressin
g 1is
memory
22-bit
when
Registers
Mapping
requiring UNIBUS
See Section 7.3 for a discussion.

enabled.

Sequence:

Calling

$STMAP

CALL

‘.”“*.“”“QW““*“‘.“““"““““”‘Q“‘.’l’““”

Description:

x*=$STMAP=SET UP UNIBUS MAPPING ADDRESS

THIS ROUTINE IS CALLED BY UNIBUS NPR DEVICE DRIVERS TO SET UP THE
UNIBUS MAPPING ADDRESS, FIRST ASSIGNING THE UMR’S, IF THE UMR’S
CANNOT BE ALLOCATED, THE DRIVER’S MAPPING ASSIGNMENT BLOCK IS PLACED

IN A WAIT QUEUE AND A RETURN TO THE DRIVER’S CALLER 18 EXECUTED,

THE

ASSIGNMENT BLOCK wILL EVENTUALLY BE DEQUEUED WHEN THE UMR®S ARE
AVAILABLE AND THE ORIVER WILL BE REMAPPED AND RETURNED TO WITH Ri=RS
PRESERVED AND THE NORMAL OUTPUTS QOF THIS ROUTINE, THE DRIVER’S
CONTEXT IS STORED IN THE ASSIGNMENT BLOCK AND FORK BLOCK WHMILE IT IS
BLOCKED AND IN THE WAIT QUEUE, ONCE A DRIVER’S MAPPING ASSIGNMENT
BLOCK IS PLACED IN THE UMR WAIT QUEUE, IT IS8 NOT REMOVED FROM THE
QUEUE UNTIL THE UMR’S ARE SUCCESSFULLY ASSIGNED, THIS STRATEGY
ASSURES THAT WAITING DRIVERS WILL BE SERVICED FIFO AND THAT DRIVER’S
WITH LARGE REQUESTS FOR UMR’S WILL NOT WAIT INDEFINATELY,
INPUTS
R4sADDRESS
RSsADDRESS

OF
OF

DEVICE
DEVICE

SC8,
uCB,

(SP)SRETURN TO DRIVER’S CALLER,

OUTPUTS
I

UNIBUS MAP ADDRESSES ARE SET UP IN THE DEVICE UCB AND THE
ACTUAL PHYSICAL ADDRESS IS MOVED TO THE SCB,

NOTE: REGISTERS R1, R2, AND R3 ARE PRESERVED ACROSS CALL,

Note:

the
routine $DQUMR+2 onto
This routine pushes the address of
This precludes the use of
stack before returning to the caller.
the stack for temporary data storage by drivers when calling this
routine.

7-37

EXECUTIVE

SERVICES AVAILABLE

TO AN

I/0

DRIVER

$STMP1
7.4.31

Set

Up UNIBUS Mapping Address

This routine is
require
UNIBUS

(Alternate

in file MEMAP.
It is used
Mapping
Registers
when

enabled

and

Calling

Sequence:

for

support

CALL

parallel

EntrY)

only for NPR
devices
that
22-bit memory addressing is

operations.

SSTMP1

tt“t&fi“q.‘snnfit-u

+»

“DQ“““Q“.Q'Q‘“"‘Q“O”“QC“‘“‘Qfl“

Description:

#4=§STMP1=SET

THIS
A

ENTRY

UMR

CODE

MAPPING

THE SAME

BLOCK

SETS

THE

bbb B

SCB,

MAPPING

ASSIGNMENT

MANNER

UNIBUS

ALTERNATE

BLOCK

AND

THE

FORMAT

DATA

CONTEXT

THE

|
|
|
|

|
|

ENTRY),

STRUCTURE
STORAGE

USED
BLOCK,

AS
IN

STRUCTURE

FOLLOWS}

ggp—

|
|

(ALTERNATE

$STMAP USES THE FORK BLOCK AND MAPPING

KRB,
L

ADDRESS

4 WORDS USED FOR SAVING
DRIVER’S CONTEXT IN CASE
UMRS CAN’T BE MAPPED
IMMEDIATELY,

& WORDS

USED

MAPPING

|
|

A UMR

ASSIGNMENT

BLOCK,

|
}
DA

)

INPUTS
R@sADDRESS

THE

RY=ADDRESS

DEVICE

RSsADDRESS

DATA

DEVICE

STRUCTURE

DEPICTED

ABOVE,

scs8,

uJCa,

QUTPUTS
s

DATA

STRUCTURE

POINTERS

SET

address

FOR

ENTRY

$STMP2

$STMAP,

Note:

This

routine

stack

the

before

stack

routine.

for

pushes

the

returning

the

temporary data

routine

caller.

storage

This

$DQUMR+2
precludes

by drivers

when

onto
the

the

use

calling

this

EXECUTIVE SERVICES AVAILABLE TO AN I/O DRIVER

$TSPAR
Test if Partition Memory Resident for Kernel AST

7.4.32

This routine
Calling

file REQSB.

Sequence:

CALL

STSPAR

**_STSPAR-TEST IF PARTITION IS IN MEMORY FOR KERNEL AST

THIS ROUTINE IS CALLED TO CHECK A REGION FOR MEMEORY RESIDENCE
TO DETERMINE IF IT IS SAFE TO SERVICE A KERNEL AST

A BUFFER)

INTO THE REGION,

(E.G.

COPY

IF THE REGION IS CHECKPOINTED OR

WNE

CURRENTLY BEING CHECKPOINTED, THEN A REGION LOAD AST IS QUEUED

AND THE REGION IS ACCESSED ON THE TASKS BEHALF.

WS ME

NG NS

Description:

INPUTS:

OUTPUTS:

C=0
C=1

IF REGION IS MEMORY RESIDENT
IF REGION IS NON-RESIDENT. IN THIS CASE THE REGION AST

HAS BEEN QUEUED,

ETC.

Mes

WME

RO=ADDRESS OF PACKET PEING PROCESSED
R1=PCB ADDRESS OF REGION
R5=TCB ADDRESS OF ASSOCIATED TASK

7-39

EXECUTIVE

SERVICES AVAILABLE

TO AN

I/O DRIVER

$TSTBF
7.4.33

This

Test

routine

Calling

for

I/0 Buffering

file

IOSUB.

Sequence:

CALL

STSTBF

**-STSTBF-TEST

I/0 BUFFERING CAN BE

INITIATED

THIS

b 1 ]

BUFFERING,

Description:

ROUTINE

WHICH

TRANSFER

IF A GIVEN

I/O

REQUEST

ELIGIBLE

STORES

THE

PCB

ADDRESS

THE

REGION

OCCUR

THE

I/0

PACKET.

PACKET

FOR

I.PRM+16

INPUTS:

R3=ADDRESS

I/O

I/0

REQUEST

OUTPUTS:

Ny we

-8

THE

DETERMINES

AND

C=0

I/O BUFFERING CAN BE

C=1

I/0 BUFFERING

PRESERVED.

INITIATED.

CAN NOT BE

INITIATED.

FOR

I/O

INTO

CHAPTER

SAMPLE DRIVER CODE

This chapter presents three sections of code. Sections 8.1 and 8.2
show the driver data base and driver code for a conventional driver.

Section 8.3 gives a coding example from a driver
queuing in QIO processing
packet
automatic
a special user buffer.
relocate
and
check
address-

drivers are in UFD [200,1] on the distribution kit.

that inhibits the
so that it might
Both of the sample

In addition to the examples shown in this chapter, you should review
the source code for one or more standard DIGITAL-supplied drivers.
You should also examine the files SYSTB.MAC and XXTAB.MAC, which
contain data structures created at system generation.

8.1

SAMPLE DRIVER DATA BASE

The following example shows the source code to create the data base
for the driver that supports the DL device. The data base allows for
one controller and one unit.
.TITLE

DLTAB

/09.0/

SYSTEM

TABLES

MACRO LIBRARY CALLS

-y

.IDENT

.MCALL
.MCALL
.MCALL
.MCALL

CLKDF$
HWDDF$

SCBDF$

,,SYSDEF

:DEFINE CLOCK BLOCK OFFSETS
;sDEFINE HARDWARE REGISTERS
;DEFINE SCB OFFSETS

;DEFINE UCB OFFSETS

“wE

wWE

UCBDFS

CLKDFS$
HWDDFS$
SCBDFS$
UCBDFS$

:
SDLDAT:

DL CTB

[

H
r

SCTBO:

+«WORD

;

L.ICB

«WORD
.ASCII
«WORD
+.BYTE

SCTB1
/DL/
.DCO
1

;
;
;
;

L.LNK
L.NAM
L.DCB
L.NUM

SAMPLE DRIVER CODE
+.BYTE

SDLCTB::

;

L.STS

;

L.KRB

SDLA

-WORD

DCB

SDLTBL=0

; LOADABLE

SDLDCB:
:

DLDRV

«.DCO:

«WORD
+WORD

+ASCII
.BYTE

-WORD

.DC1
.DLO
/DL/

;

D.NAM

0,0
DLND-DLST

:
;

D.UNIT
D.UCBL

:
;

D.LNK
D.UCB

SDLTBL; D.DSP
177477,70,0,177200,377,0,0,377
0
; D.PCB

-WORD
-WORD
-WORD

;

D.MSK

«WORD

« WORD

.DCO

- WORD

0”2

«.BYTE

UC.ALG!UC.NPR!UC.PWF!1,US.MNT

.BYTE

0,US.OFL

«WORD

DV.DIR!DV,.MSD!DV,UMD!DV.F11!DV,.MNT

«WORD
«WORD

0
50000

«WORD

512.

«WORD
-WORD

$DLO

.BYTE
-WORD

40., 2.
512.

UCB'S

TMy

DLND=.

KRB

DLA

:
SDLA:

.BYTE

PR5

.BYTE
«.BYTE

160/4
0*2,0

.WORD

0!KS.OFL
174400
DLA-SDLA

+WORD
«WORD

.BYTE

K.CON,

K.STS

;

K.CSR

;
:
;

K.OFF
K.HPU
K.OWN

K.PRI

K.VCT
K.IOC

«WORD

O,.-2

;

S.LHD AND

.WORD

0,0,90,0

-WORD
«WORD

;

S.FRK

0
0

;
;

S.KS5
S.PKT

L2]

wmy

CONTIGUOUS

L
rme

wms

.WORD

0,0
0

;
:
;

HERE

FOR

.BYTE

.BYTE
.BYTE

4
0

;
;
;

S.CTM
S.ITM
S.STS

«.BYTE
«WORD
.WORD

0
S2.L0OG!S2.CON

SDLA

;
;

S.ST3
S.ST2

S.KRB

.BYTE

7.
0
0
6
0

;
:
;

S.RCNT
S.ROFF
S.EMB

;
;

MAPPING
KE.RHB

.BYTE

«WORD
« BLKW

-WORD
DLA:

K.CRQ

ASSIGNMENT BLOCK

SAMPLE DRIVER CODE

!
-

'§

:
SDLEND:
e 1

.DC1 = 0

SCTB1 = O

END OF DCB LIST FOR DL:
END OF CTB LIST FOR DL:

« END

8.2

SAMPLE DRIVER CODE

The following example shows the source code for the DL isdriver.
being
tion
Comments beginning with ';;;' indicate that the instruc
to 5.
executed at a priority level greater than or equal
.TITLE

DLDRV

/O01/

RL11-RL01/02 DISK DRIVER

.IDENT

.MCALL

HWDDFS$,PKTDFS

HWDDF $

;:DEFINE HARDWARE REGISTERS

;DEFINE I/0 PACKET OFFSETS

EQUATED SYMBOLS

PKTDF$

RETRY=

512.*20.
15.

; CONTROLLER ERROR RETRY COUNT
;BYTES PER SURFACE
;TIME TO SPIN UP

RL11 DEVICE REGISTER OFFSETS

“_"E

-y

RLBPT=
RLSPU=

0
2
4
6

; CONTROL STATUS REGISTER
;BUS ADDRESS REGISTER
;DISK ADDRESS REGISTER
;MULTIPURPOSE REGISTER

RLCS BIT ASSIGNMENTS

-y

RLCS=
RLBA=
RLDA=
RLMP=

DE=
NXM=
DLT=
HNF =
DCK=
HCRC=

100000
040000
020000
010000
010000
004000
004000

;COMPOSITE ERROR

DRDY=

; DRIVE READY

ERR=

OPI=

WCHK=

WRITE=

GSTS=
SEEK=

RDH=
READ=

002000
2

10
14

;DRIVE ERROR
:NONEXISTENT MEMORY
; DATA LATE
; HEADER NOT FOUND
; DATA CHECK ERROR
; HEADER CRC ERROR

; OPERATION INCOMPLETE
sWRITE CHECK FUNCTION
;WRITE OFFSET

;:GET DRIVE STATUS FUNCTION
;SEEK FUNCTION

; READ HEADERS FUNCTION
:READ DATA FUNCTION

SAMPLE

100
200

CODE

; INTERRUPT

ENABLE

;sCONTROLLER

READY

RLDA

STATUS

CODES

IE=
CRDY=

DRIVER

MRK=

STS=

SN=

;GET

BIT
STATUS

RST=

;SIGN

BIT

HS=

REV=

200!MRK

sMARKER

BIT

FOR

SEEK

;DRIVE

RESET

BIT

s HEAD

SELECT

BIT

sREVERSE

DIFFERENCE

WORD

SEEK

FOR

GET

STATUS

BIT

ASSIGNMENTS

RLMP

WDE=

100000

CHE=

040000

;WRITE DATA ERROR
; CURRENT HEAD ERROR

WLS=

020000

SKTO=

sWRITE

010000

LOCK

SPD=

004000

sSEEK

TIMEOUT

; SPEED

ERROR
GATE

WGE=

002000

VC=

;WRITE

001000

; VOLUME

STATUS

ERROR

CHECK

DSE=

000400

DT=

000200

;DRIVE

SELECT

;DRIVE

TYPE

+HEAD

SELECT

;COVER

OPEN

s HEADS

HOME

HSS=

000100

CO=
HH=

000040
000020

BH=

000010

SLM=

000005

;BRUSHES

;DRIVE

ERROR

STATUS

HOME

SEEK-LINEAR MODE

STATE

’

;

LOCAL

CONTROLLER

DATA

THESE

ARE

IMPURE

DATA
BY

TABLES

THE

CONTROLLER

NUMBER

INDEXED

RTTBL:

.BLKW

PRMSV:

.BLKW

;RETRY

COUNT

; PARAMETER

FOR

SAVE

CURRENT

AREA

OPERATION

FOR WRITE

CHECK

’

;DRIVER

DISPATCH

TABLE

;

WE s we WE WE Wy Wy ws W W s % W % %s

s wmy

DDTS

DL,RSSL11,NEW=Y

;GENERATE

DISPATCH

TABLE

**-DLINI-RL11-RL01/02
THIS

ROUTINE

REQUEST

PROPAGATE

DISK

ENTERED

QUEUED AND AT
THE

EXECUTION

CONTROLLER

FROM

THE

QUEUE

THE

END

THE

INITIATOR
I/0O

DIRECTIVE

I/0

WHEN

OPERATION

I/0

DRIVER.

IF THE SPECIFIED CONTROLLER
TO DEQUEUE THE NEXT I/0 REQUEST.
ELSE A
CALLER IS EXECUTED.
1IF THE DEQUEUE ATTEMPT
IS SUCCESSFUL, THEN THE NEXT I/O OPERATION IS
INITIATED.
A RETURN
TO THE CALLER IS THEN EXECUTED.
IS

NOT

BUSY,

THEN AN
RETURN TO THE

ATTEMPT

MADE

THE

INPUTS:

R5=

ADDRESS

UCB

CONTROLLER

INITIATED.

OUTPUTS:

THE

WAITING

SPECIFIED
TO

CONTROLLER

PROCESSED,

THEN

NOT
THE

BUSY

AND AN

REQUEST

I/0

REQUEST

DEQUEUED

AND

1S
THE

SAMPLE DRIVER CODE

-y

DRIVER INITIATES THE REQUESTED I/O FUNCTION

-y Wy e W NS W WE %e N s s W Ns W e g W Yeg M ME WMe WE WE WE WS e Ws Wy s = “wyg wE wmy s %

DLINI:

GTPKTS

;GET NEXT I/O PACKET TO PROCESS

DL,R$SL11

THE FOLLOWING ARGUMENTS ARE RETURNED BY S$GTPKT:
R1= ADDRESS OF THE I/O REQUEST PACKET

R2= PHYSICAL UNIT NUMBER OF THE REQUESTED DRIVE
R3= CONTROLLER

INDEX

R4= ADDRESS OF THE STATUS CONTROL BLOCK

R5= ADDRESS OF THE UCB OF THE DRIVE TO BE INITIATED

RL11-RL0O1/02 DISK CONTROLLER I/O REQUEST PACKET FORMAT:
WD.

00 -- I/0O QUEUE THREAD WORD

WD. 01 -- REQUEST PRIORITY, EVENT FLAG NUMBER
WD. 02 -- ADDRESS OF THE TCB OF THE REQUESTOR TASK

WD. 03 —-- POINTER TO 2ND LUN WORD IN REQUESTOR TASK HEADER
WD.
WD.

04 —-- CONTENTS OF FIRST LUN WORD
05 -- I/0 FUNCTION CODE

WD.

07 -- RELOCATION BIAS OF I/O0 STATUS BLOCK

WD. 06 —- VIRTUAL ADDRESS OF I/O STATUS BLOCK

WD. 10 -- I/0 STATUS BLOCK ADDRESS (DISPLACEMENT + 140000)
WD. 11 -- VIRTUAL ADDRESS OF AST SERVICE ROUTINE
WD. 12 -- MEMORY EXTENSION BITS OF I/0 TRANSFER
WD. 13 -- BUFFER ADDRESS OF I/O TRANSFER
WD. 14 -- NUMBER OF BYTES TO BE TRANSFERRED
WD.

-- NOT USED.

WD. 16 -- LOW BYTE MUST BE ZERO AND HIGH BYTE IS NOT USED

WD. 17 -- LOW PART OF LOGICAL BLOCK NUMBER OF I/O REQUEST

WD. 20 -- RELOCATION BIAS OF REGISTER BUFFER ELSE NOT USED

WD. 21 -- REGISTER BUFFER ADDRESS (DISPLACEMENT + 140000) ELSE NOT USED
DRIVER USAGE OF WORDS IN I/O PACKET:

I1.PRM+6

(WD.

15)

- SEEK DIFFERENCE WORD

I.PRM+12

(WD.

17)

- BYTE COUNT FOR THIS TRANSFER

I.PRM+10 (WD. 16) - STARTING DISK ADDRESS FOR THIS TRANSFER

MOV
CALL
BCS
TST
BMI
TST
BPL
MOV

;SET INITIAL RETRY COUNT
$RETRY&377,RTTBL(R3)
;VALIDATE VOLUME VALID
$VOLVD
;IF CS WE FAILED
58
; TRANSFER FUNCTION?
RO
108
I.PRM+2 (R1)
58

; IF MI YES
;SIZE THE DISK?
:IF PL NO, ERROR

;RETRIEVE CSR ADDRESS
:RESET DRIVE AND GET STATUS
;RETRIEVE I/0 PACKET ADDRESS

MOV

S.CSR(R4) ,R2
DLRST
S.PKT (R4) ,R3

5$:

CALL
JMP

REGPAS
DLFIN

;sMOVE REGISTERS INTO BUFFER
;FINISH UP

10S:

CALL

SSTMAP.

:SET UP UNIBUS MAPPING ADDRESS

20$

i IF EQ YES

CALL

MOV
MOV

MOVB
MOV
BIS
CMPB

;SET CURRENT UNIT NUMBER
+1
R2,U.BUF(R5)
;ASSUME ILLEGAL FUNCTION
$IE.IFC&377,R0
;ASSUME READ LOGICAL FUNCTION
$READ!IE,U.BUF(R5)
;REALLY?
$10.RLB/256.,I1.FCN+1(R1)

CMPB
BNE

;;WRITE LOGICAL FUNCTION?
$I0.WLB/256.,I1.FCN+1(R1)
;IF NE NO, EXIT WITH ERROR
5$

BEQ

20S:

;SET BUFFER RELOCATION BIAS
I.PRM+14(R3),KISAR6
I1.PRM+16(R3),R3 ;GET REGISTER BUFFER ADDRESS

SUB
MOV

JWRITE,U.BUF(R5)
#RETRY,RTTBL(R3)

;CONVERT TO WRITE LOGICAL FUNCTION
;SET INITIAL RETRY COUNT

SAMPLE

MOV

I.PRM+12(R1),R0

CLR

;RETRIEVE

BITB

:CLEAR

#I0.WPB&377,I.FCN(R1)

358

CALL

; IF

$BLKCK

:CHECK

BNE
BITB
BNE
MOV
ADD

BLOCK
BLOCK

NUMBER
FUNCTION?

LOGICAL BLOCK NUMBER
#I0.WLB/256.,I.FCN
(R3)
+1
;WRITE FUNCTION?
308
;IF NE NO
#I0.WLT&377,I.FCN(R3)
;OK TO WRITE ON LAST TRACK?
30$
;:IF NE YES
RO,I.PRM+6(R3)

;YES,
#°D<20>,I.PRM+12(R3)

SAVE

STARTING

;ADD

;CHECK

MOV

I.PRM+6 (R3) ,R0

;RESTORE

BLOCK

TRACK'S

WRITE

ORIGINAL

NUMBER

WORTH

LAST

STARTING

RO
S.PKT (R4) ,R3

; CONVERT BLOCKS TO SECTORS
;RESET I/0 PACKET ADDRESS

ROR

ROL

;PUT

;sMERGE

#6,R2

; POSITION

BIS
MOV
MOV

SUB

SWAB
CMP
BLOS

MOV

MOVB
MUL

$SCVLBN

SURFACE

BIT

WITH

S.CON(R4),R1

# PRMSV, R1

INDEX

MOV

; POINT

U.BUF (R5),(R1)+ ;SAVE INITIAL
U.BUF+2(R5), (R1)+
;...
U.CNT(RS), (R1)+
;...

MOV

THE

CARRY

CYLIDER

I.PRM+10(R3)
(R1)+
,
I.PRM+12(R3),(R1)+

INTO

THIS

PARAMETER

SAVE

AREA

ENTRY
PARAMETERS

;...
;...

SECTION

WILL

INITIATE

THE

OPERATION

THIS

DLINIO:

CALL

SMPUBM

MOV

;MAP

S.CSR(R4),R2

UNIBUS

MOV

;GET

S.PKT (R4) ,R3

ADDRESS

;GET ADDRESS
;RESET DRIVE

CLRB
CLR
MOVB

CALL
MOV

BIC

#DRDY, (R2)

;IS

THE

108

;IF

20S:

DLGO:

30S:

BITB

TRANSFER
CSR

I/0
SETTLE

PACKET
DOWN FLAG
DIFFERENCE WORD

;RESET ERROR
S.ITM(R4),S.CTM(R4)
;SET DEVICE TIMEOUT COUNTER
DLRST
;RESET DRIVE AND GET STATUS
RLMP (R2) ,R1
;GET THE STATUS INFO
#WLS!DT!HSS,R1
;REMOVE IRRELEVANT BITS

BEQ
CMP

105:

U.CW2+1 (RS)
I.PRM+6 (R3)

BIT

BEQ

DISK

NUMBER

;RETRIEVE CONTROLLER INDEX

ADD

MOV

BLOCK

NUMBER
CYLINDER AND SURFACE
RO,R2
;MERGE SECTOR WITH CYLINDER AND SURFACE
R2,I.PRM+10(R3)
;SAVE STARTING DISK ADDRESS
U.CNT(RS5),I.PRM+12(R3)
;ASSUME ONLY ONE XFER NEEDED
$°D<40>,R1
; SET SECTORS/SURFACE
RO, R1
; CALCULATE SECTORS LEFT ON SURFACE
R1
;GET BYTES LEFT ON SURFACE
U.CNT(RS),R1
;ARE ADDITIONAL TRANSFERS REQUIRED?
40$
;:IF LOS NO
R1,I.PRM+12(R3)
;SET BYTE COUNT FOR FIRST TRANSFER
;FORM

MOV

BLOCKS
OF

;CONVERT BLOCK NUMBER TO DISK ADDRESS

#5,R1

MOV

TRACK

ASL
MOV

MOV

wmy

NUMBER

ORDER

YES

SBLKC1

ASH

CALL

408:

BLOCK

HIGH

;PHYSICAL

BNE

CMPB

30$:
35$:

DRIVER CODE

#HH!BH!SLM,R1
208

DRIVE

;HEADS,
;IF

#US.SPU,U.STS(R5)

BNE

DLPWF1

MOV

#IE.DNR&377,R0

JMP

DLFIN

BICB

$US.SPU,U.STS(R5)

;IS

;IF NE

BRUSHES

DRIVE
YES,

RETURN

;EXIT

WITH

;RESET

MOV

I.PRM+10(R3),R0

CALL

DLDIFF

BEQ
MOV

308
#SEEK,R1

CALL

;GET

DLXCT

BMI

DLEROR

; EXECUTE

ADD

#RLMP, R2

NO
CODE

FOR

ERROR

FATAL

OK?

UP?
IT

SPIN

CODE

ERROR

SPINNING

STARTING

; CALCULATE

STATE

SPINNING
WAIT

DRIVE

;RETRIEVE

;IF

AND

YES

;SET

;IF

READY?

DISK

UP
ADDRESS

DIFFERENCE

SEEK
FOR

THE

ERROR

SEEK
DURING

; POINT TO RLMP

8-6

WORD
NECESSARY
SEEK FUNCTION

SEEK

FUNCTION

SAMPLE DRIVER CODE

MOV

ROR

sALSO NEGATIVE
; LOAD WORD COUNT

R1
R1l, (R2)

MOV
CALL
MOV

; LOAD BUS ADDRESS
U.BUF+2 (R5) ,-(R2)
;SET I/0 ACTIVE BIT IN MAP
SBMSET
U.BUF(R5),-(R2) ;;;LOAD FUNCTION AND GO

;LOAD STARTING DISK ADDRESS

I.PRM+10(R3),-(R2)

CANCEL I/O OPERATION IS A NOP FOR FILE STRUCTURED DEVICES.

wWs

sMAKE IT A WORD COUNT

NEG
MOV

MOV

I.PRM+12(R3),R1 ;GET BYTE COUNT

;;;NOP FOR RL11

RETURN

POWERFAIL IS HANDLED VIA THE DEVICE TIMEOUT FACILITY AND
CAUSES NO IMMEDIATE ACTION ON THE UNIT. THE CURRENT TIMEOUT
COUNT IS EXTENDED, THUS IF A UNIT WAS BUSY IT WILL HAVE
SUFFICIENT TIME TO SPIN BACK UP. THE NEXT I/O REQUEST TO ANY
UNIT WILL BE SUSPENDED FOR AT LEAST THE EXTENDED TIMEOUT UNLESS

DLCAN:

Ses

THE UNIT IS CURRENTLY READY.

DLPWF:

TSTB
BEQ

MOVB

DLPWF1l: MOVB
DLPWF2: BISB
+

$#4,S.STS (R4)

: IS DRIVE CURRENTLY BUSY?

; IF EQ NO

;ALLOW FOR A FULL MINUTE TO SPIN UP

$RLSPU,S.CTM(R4) ;EXTEND TIMEOUT INCASE UNIT WAS BUSY
#US.SPU,U.STS(R5) ;SET UNIT SPINNING UP
;

** _$DLINT-RL11-RL01/02 DISK CONTROLLER
INTERRUPT AND ERROR SERVICE ROUTINES

RETURN

S.STS(R4)

DLPWF2

.ENABL

$DLINT::INTSV$S
CALL
MOV
ASRB
BCS

MOV
MOV

MOV
MOV
MOV
BMI

SAVE REGISTERS AND SET PRIORITY

SFORK
R4,R3
RTTBL+1 (R3)

; ; ;CREATE A SYSTEM PROCESS
; COPY CONTROLLER INDEX
:HOME SEEK IN PROGRESS?

U.SCB(R5) ,R4
S.CSR(R4) ,R2

;GET ADDRESS OF SCB
;GET ADDRESS OF CSR

208

;:IF MI AN ERROR OCCURRED

708

; IF EQ NONE LEFT

10$

; IF LOS YES

DLINIO

$IS.SUC&377,R0
S.PKT (R4) ,R3
(R2),R1

;IF CS YES

;ASSUME SUCCESSFUL OPERATION
;RETRIEVE I/0 PACKET ADDRESS
:GET CONTENTS OF RLCS

;CALCULATE BYTES LEFT TO XFER

I.PRM+12(R3),U.CNT(R5)

MOV
CMP

;ASSUME LAST XFER COMING
U.CNT(R5),I.PRM+12(R3)
U.CNT(R5),#RLBPT ;IS THIS THE LAST TRANSFER?

MOV
BIC
MOV

$RLBPT,I.PRM+12(R3) ;TRANSFER A WHOLE TRACKS WORTH
;CLEAR CRDY TO START FUNCTION
#CRDY,R1
; SAVE CURRENT FUNCTION AND ADDRESS BITS
R1,U.BUF(R5)

MOV

RO,R1

;COPY DISK ADDRESS

BIT

#DRDY, R1

: IS THE DRIVE READY?

BLOS

MOV
MOV

BIS
INC
MOV
CALL
JMP

208:

DL,PR5,RSSL11

SUB

BEQ

10$:

LSB

;SAVE CURRENT BUS ADDRESS
RLBA(R2) ,U.BUF+2(R5)
DISK ADDRESS
INITIAL
;GET
0
I.PRM+10(R3),R
#77,R0
RO
RO,I.PRM+10(R3)
DLDIFO
DLGO

; UPDATE CYLINDER AND SURFACE ...
;... LEAVING SECTOR BITS ZERO
;SAVE NEW DISK ADDRESS
;CALCULATE MID-TRANSFER DIFFERENCE
:GO DO THE OPERATION

SAMPLE DRIVER CODE

255:

BNE

DLEROR

;IF

MOVB
INCB

#3,S.CTM(R4)

sWAIT

s FLAG

SETTLE

U.CW2+1 (R5)

RETURN

DLEROR:

FOR

DOWN

;RETRIEVE

BIT

#NXM,R1

BNE

90$

:NON-EXISTENT
;IF

BIT

sDRIVE

BEQ

#DE, R1
40$

PROBLEMS?

CALL

;IF

DLGST

;EXECUTE

BIT

;WRITE

BEQ

$WGE, RLMP (R2)
90$

GATE

; IF

BIT

#WLS, RLMP (R2)

;IS

THE

BEQ

DLRTRY

:IF

CONTENTS

GET

:SET WRITE
r

#10,U.BUF (R5)

;WRITE

CHECK

DLRTRY

;IF

s OPERATION
;IF

BIT

#DCK, R1

BEQ

;sWRITE

CHECK

DLRTRY

; IF

#IE.WCK&377,R0

;YES,

DLRTRY

;GO

BITB

#I0.WLC&377,I.FCN(R3)
80$
;IF NE

BITB

#US.WCK,U.STS(R5)

BEQ

DLFIN

U.BUF (RS5) ,R1

ERROR

INCOMPLETE?
ERROR?

CHECK

OPERATION

;WRITE
EQ

ERROR CODE

REQUIRED

CHECK

ENABLED?

;GET CURRENT FUNCTION CODE

#WCHK, R1

;WRITE

OR WRITE

DLFIN

;IF

#10,R1

BEQ

sWAS

DLFIN

;IF

MOVB

S.CON(R4),R1

;RETRIEVE

MOV

CHECK

FUNCTION?

FUNCTION WRITE CHECK?
EQ

YES

CONTROLLER

MUL

#RETRY, RTTBL (R1) ;RESET RETRY COUNT
#5,R1
;FORM AN INDEX INTO

ADD

#PRMSV,
R1

MOV

(R1)+,U.BUF
(R5)

INDEX

SAVE

AREA

»
Freee

MOV

; RESTORE
(R1)+,U.BUF+2
(R5)
-

Fr e

MOV

(R1)+,U.CNT(RS)

(R1)+,I.PRM+10(R3)

MOV

(R1)+,I.PRM+12(R3)

#10,U.BUF (RS)

STARTING

PARAMETERS

MOV

BIC

CODE

;WRITE WITH WRITE CHECK?
YES

BIT

JMP

LOCKED?

FUNCTION?

SET WRITE

RETRY

;IF

FUNCTION

YES

STATUS

WRITE

LOCK

#OPI ,R1

MOV

ERROR

MEMORY?

DRIVE

$IE.WLK&377,R0

RLCS

DLFIN

ERROR?

DLRTRY

BEQ

e
-

; CONVERT TO WRITE CHECK
; START THE WRITE CHECK

DLINIO

FUNCTION

I/0

OPERATION

“s

FINISH

90$:

MOV

DLFIN:

$IE.VER&377,R0

; SET

UNSUCCESSFUL

MOV

S.PKT (R4),R2

;GET

ADDRESS

MOV

I.PRM+4 (R2),R1

SUB

;GET

TOTAL

U.CNT (R5) ,R1
S.CON(R4),R3

;CALCULATE

MOVB

RTTBL (R3),R2

OPERATION

I/0O

TRANSFER
BYTES

PACKET

SIZE

TRANSFERRED

CONTROLLER

INDEX

CALL
JMP

DLINI

; PROCESS

Wy
wp
wme
e

; RETRIEVE

;GET FINAL RETRY COUNT
#RETRY*"D<256>,R2
sMERGE STARTING RETRY COUNT
SIODON
;FINISH I/0 OPERATION

BIS

**-DLOUT-RL11-RL01/02
DEVICE

SETTLE

YES

BNE

BIT

PROGRESS

UNRECOVERABLE

BIT

MOV

ERRORS
DRIVE

;sASSUME

BNE

FOR
THE

’

(R2),R1

BNE

CHECK

$IE.VER&377,RO0

BIT

80S$:

SECONDS

MOV

70S$:

YES,

MOV

406:

TIMEOUT

DISK

CONTROLLER

ROUTINE

REQUEST

SAMPLE DRIVER CODE

-y

DEVICE TIMEOUT RESULTS IN THE OPERATION BEING REPEATED.
TIMEOUTS ARE USUALLY CAUSED BY A POWER FAILURE BUT MAY ALSO

-y

BE THE RESULT OF A HARDWARE MALFUNCTION.

DLOUT:

S.PKT (R4) ,R3

; ; ;RETRIEVE I/0 PACKET ADDRESS

DECB

S.STS(R4)

: ;;HAVE WE WAITED A MINUTE YET?

INCB
BR
MTPS
JMP

S.STS (R4)
30%
#0
DLINIO

; ;; LEAVE CONTROLLER BUSY
;;:LOG DEVICE TIMEOUT
: ;;ALLOW INTERRUPTS
;RETRY ENTIRE OPERATION

BEQ

308

MOV

BITB
BEQ
BNE

10S:

20S:

TSTB
MTPS

30$:

WE. Ny

;::;IF EQ NO

s+ :YES, ALLOW INTERRUPTS

: PROCESS THE ERROR

DLEROR

CALL
MOV

DLRST
$IE.DNR&377,R0

BITB
BNE
DECB
BLE
JMP

$10.X,I.FCN(R1)
DLFIN
RTTBL (R3)
DLFIN
DLINIO

MTPS

: : ;ALLOW INTERRUPTS

S.PKT (R4) ,R1

+:GET I/0 PACKET ADDRESS

:RESET DRIVE
;SET DEVICE NOT READY

;INHIBIT RETRIES?
;IF NE YES
;ANY MORE RETRIES LEFT?
:IF LE NO
;YES, RETRY ENTIRE OPERATION

**_DLXCT,DLGST,DLRST-RL11-RL01/02 DISK CONTROLLER
FUNCTION EXECUTION ROUTINES

s
Wy
s

:::1IS DRIVE SETTLING DOWN?

U.CW2+1 (RS)

THIS ROUTINE WILL EXECUTE A GET DRIVE STATUS OR ANY

NON-INTERRUPTABLE FUNCTION AND WAIT FOR ITS COMPLETION.

:IF NE NO

108

JMP

DLRTRY: MOV

;;;IS DRIVE SPINNING UP?
#US.SPU,U.STS(RS)
::;:IF EQ NO
208

;

INPUTS:

R1 = FUNCTION CODE
R2 = CSR ADDRESS
R5 = UCB ADDRESS

;
;
r

;

OUTPUTS:

R1 = CONTENTS OF RLCS
FUNCTION EXECUTED

H
;

(TESTED)

;

. ENABL
DLRST:

MOV

DLGST:

MOV

10$:

MOV

DLXCT:

MOV

CALL

MOVB
MOV

20S$:

BIT
BEQ
MOV
RETURN

R1,-(SP)

; SAVE FUNCTION CODE

(SP)+, (R2)
(R2)
#$ERR!CRDY,
208

; LOAD RLCS
;READY OR ERROR?
; IF EQ NEITHER

U.UNIT(RS),1(SP);MERGE CURRENT DRIVE BITS

(R2) ,R1

;:SAVE RLCS AND TEST FOR ERRORS

LSB

.DSABL

LSB

;SET MESSAGE CODES IN RLDA
#RST!STS!MRK,RLDA(R2)
;DO THE DRIVE RESET FIRST
108
;SET MESSAGE CODES IN RLDA
(R2)
#STSIMRK,RLDA
;SET GET STATUS FUNCTION
#GSTS,R1

** _DLDIFF-RL11-RL01/02 DISK CONTROLLER
CYLINDER ADDRESS DIFFERENCE CALCULATOR

THIS SUBROUTINE CALCULATES THE DIFFERENCE WORD USED IN THE
IF A HEADER CANNOT BE READ AFTER 16. RETRIES,

SEEK OPERATION.

AN ERROR WILL BE LOGGED AND A ONE CYLINDER REVERSE SEEK WILL BE
ISSUED.

THE SEEK IS FOLLOWED BY A READ HEADERS TO CAUSE AN

%
wg

INPUTS:

W Wy Wy

INTERRUPT.

s e

SAMPLE

DESIRED

I/0

WS NS

DIFFERENCE WORD
= LOADED WITH DIFFERENCE WORD
I.PRM+6 = LOADED WITH DIFFERENCE WORD
IF EQ NO SEEK IS NECESSARY

Wh B e

RLDA

MOV

10S:

MOV

#RETRY*2,
- (SP)
#RDH, R1

; SET

READ

HEADER

;SET

CODE

CALL

FOR

DLXCT

BPL

208

;EXECUTE

DEC

BGT

108

(SP)+, (SP)+

CALL

; REMOVE

DLRST

;RESET

MOV

#REV, RLDA (R2)
#SEEKR1
,

; LOAD REVERSE
iGET CODE FOR

#IE.VER&377,R0

DLDIFO:

DLFIN

BIC

#377,R1

;CLEAR

BIS

OUT

#IE!RDH,R1

MOVB

; LOAD

$1,RTTBL+1
(R3)

CODES

;sREMOVE

CLR

; RETRIEVE

I.PRM+6 (R3)

BIC

; RESET

#77,R0

sMASK

BIC

#77,R1

Feeose

TIMEOUT

THE

AND

PROGRESS
COUNTER

INTERRUPT

RETRY

COUNT

HEADER

WORD
DIFFERENCE WORD

OUT

SECTOR

408

;DO

NEED

;:IF

MOV

RO,
- (SP)

BIC

#7C<100>, (SP)
(SP)
(SP)

;SAVE

DESIRED

; ISOLATE

BITS

INTO

THE

DISK

SURFACE

SEEK?

ADDRESS

BIT

PROPER

POSITION

HIP

; REMOVE

SURFACE

BIT

HER

SUB

RO,R1

BCC

308

;IF

NEG

;ACTUAL

BIS

#SN,R1

;SET

SIGN

MARKER

;SUBTRACT

DESIRED FROM ACTUAL
ACTUAL >= DESIRED

DESIRED,

MAKE

FOR

MOVE

INC

BIS

;SET

(SP)+,R1

;sMERGE

MOV

R1,RLDA (R2)
R1,I.PRM+6(R3)

; LOAD

DIFFERENCE

; SAVE

DIFFERENCE WORD

RETURN

POSITIVE

CENTER

BIT

SURFACE

BIT

WORD

’

THE

CONTROLLER/DRIVE

REGISTERS

INTO

MOVE

[

CSR

ADDRESS

BUFFER

ADDRESS

INPUTS:

b 1 ]

DEVICE

RO,R1

MOV

HEADER

SEEK

CMP
BEQ

#100,R0

BITS

READ

REVERSE

FOR

(SP)+

#100,R1

REGPAS:

ADDRESS

FAIL

FOR

FUNCTION

RLMP(R2) ,R1

BIC

CALLERS

DIFFERENCE WORD
FUNCTION

FUNCTION

sWAIT

TST

BIC

SEEK
SEEK

; LOAD

;PUT

AND

SEEK
FAILED

MOV

ASR

COUNT

THE

; INDICATE
S.ITM(R4),S.CTM(R4)
;SET

ASR

406:

RETRY

BMI

R1, (R2)

DRIVE

;EXECUTE
;IF

FUNCTION

YES

;ASSUME WE WILL

RETURN

20$:

DLXCT

MOV

30$:

;IF

CALL

MOVB

COUNT

HEADERS

THE

CMP

MOV

RETRY

READ

FUNCTION
;IF PL FUNCTION EXECUTED
;ANY RETRIES LEFT?

(SP)

MOV

ADDRESS

PACKET ADDRESS

OUTPUTS:

DLDIFF:

DISK

DRIVER CODE

MOV

(R2) ,(R3)+

MOV

sMOVE

RLBA(R2) ,(R3)+

RLCS

;sMOVE

RLBA

THE

SPECIFIED

BUFFER.

DIFFERENCE
DISK

SAMPLE DRIVER CODE

MOV

RLDA(R2),(R3)+

;MOVE

MOV
CLR

RLMP(R2),(R3)+
(R3)+

;MOVE RLMP
;CLEAR PLACE

CLR

CALL

(R3)+

DLGST

;+++50 HRC/CON WILL WORK

MOV

RLMP(R2), (R3)

; SAVE

DRIVE

STATUS

e
NE

HOLDERS...

;EXECUTE GET DRIVE STATUS FUNCTION

RETURN

ON-LINE/OFF-LINE

ROUTINE

THIS ROUTINE WILL HANDLE RECONFIGURATION CALLS FOR ON-LINE
CONTROLLER AND OFF-LINE CONTROLLER FOR THE RL1l1.
INPUTS:
R2

KRB

ADDRESS

C=0

ON-LINE REQUEST

OUTPUTS:

NONE

W WE

WMe
WE

R3 = CTB ADDRESS
C=1 IF OFF-LINE REQUEST

**-.DLKRB-CONTROLLER

RLDA

BCS

DLOFL

; HANDLE

OFF-LINE

REQUEST

CONTROLLER

COMING

ON-LINE.

CODE

SPECIFIC

TO HANDLE

THE

DLKRB:

;EXIT

CODE

SPECIFIC TO HANDLE THE

CONTROLLER GOING

OFF-LINE

RETURN

DLOFL:

-y

** _DLUCB-UNIT ON-LINE/OFF-LINE ROUTINES

UNIT AND OFF-LINE

ROUTINE WILL

HANDLE

UNIT

RECONFIGURATION

FOR

RLO1l

AND

RLO2

CALLS

FOR

ON-LINE

DRIVES.

= CONTROLLER

INPUTS:

WeE

THIS

%Ne

WMe

RETURN

UCB

IF
IF

ADDRESS

OFF-LINE REQUEST
ON-LINE REQUEST

OUTPUTS:
NONE

WME

C=1
C=0

INDEX

SCB ADDRESS

BCS

DLOFLU

; IF

OFF-LINE

CODE

SPECIFIC

BRINGING

UNIT

ON-LINE.

-y

DLUCB:

CODE

SPECIFIC

RETURN

TO TAKING

UNIT

OFF-LINE.

8-11

REQUEST

SAMPLE

DRIVER CODE

DLOFLU:

-y

RETURN

« END

8.3

HANDLING SPECIAL USER BUFFERS

that

the

addition

Some drivers need to handle user buffers in

buffer

Executive address-checks and relocates in a normal transfer

the

place
take
Address-checking and relocation operations must
request.
the
because
request,
I/O
the
1issuing
task
the
of
context
the
in

the
in
However,
issuing task.
the
mapping registers are set for
normal driver interface, the task context after the call to S$SGTPKT is
not,

issuing task.

that of the

in general,

Thus, drivers that need to handle special
buffers
must
be
able
to
refer
to the I/0 packet before it is queued, while the context of the
issuing

task

still

intact.

The coding shown in this section is an

illustrates

handling

the

excerpt

from

a special user buffer.

driver

that

The key points

are:

The UC.QUE bit has been set in the control

The routine (ZZINI)

the UCB for

W
e
e
N
e
W
s
%We
me
ma
us
e
e
W

(U.CTL)

I/0

(DDT$)

initiation

macro call

Retrieves the user virtual address and address-checks itv

Relocates the virtual address and stores the result
into

the

Inserts the packet
inline

into

the

1I/0O

queue

and

the entry point BMINI,

continues
which calls

The driver propagates its own execution by branching back
to

back

packet

execution
SGTPKT

BMINI

the

that is defined

entry
point
in
the driver dispatch table
performs the following actions:

byte

each device/unit.

call

S$GTPKT.

.TITLE

BMTAB - DATA BASE FOR BLOCK MOVE DRIVER

. IDENT

/01/

ALL RIGHTS

RESERVED.

UNDER A LICENSE AND MAY BE USED
FURNISHED
IS
SOFTWARE
THIS
ACCORDANCE WITH THE TERMS OF SUCH LICENSE
ONLY IN
AND COPIED
THIS
COPYRIGHT NOTICE.
AND WITH THE INCLUSION OF THE ABOVE
THEREOF, MAY NOT BE PROVIDED OR
OR ANY OTHER COPIES
SOFTWARE
NO TITLE TO AND
OTHERWISE MADE AVAILABLE TO ANY OTHER PERSON.
OWNERSHIP OF THE SOFTWARE IS HEREBY TRANSFERRED.

TO CHANGE WITHOUT
1IN THIS DOCUMENT IS SUBJECT
THE INFORMATION
NOTICE AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL
EQUIPMENT CORPORATION.

8-12

SAMPLE DRIVER CODE

FOR THE USE OR RELIABILITY OF
DIGITAL ASSUMES NO RESPONSIBILITY

‘g

"ws

ITS SOFTWARE ON EQUIPMENT THAT IS NOT SUPPLIED BY DIGITAL.

LOADABLE DATA BASE FOR EXAMPLE BUFFERED I/O DRIVER
LIBRARY CALLS

MACRO

.MCALL
-MCALL
.MCALL

.MCALL

CLKDFS$
HWDDF$
SCBDF$
UCBDFS

CLKDF$
HWDDF$
SCBDFS$
UCBDFS$

;DEFINE CLOCK BLOCK OFFSETS
s + SYSDEF

;DEFINE HARDWARE REGISTERS
; DEFINE SCB OFFSETS
; DEFINE UCB OFFSETS

WE
W

SBMDAT:
BM

DCB

; LOADABLE

SBMTBL=0

BMDRV

.WORD

SBMTBL

+WORD

«WORD

0,1-1
BMND-BMST

/BM/

D.NAM

D.UNIT,D.UNIT+1
D.UCBL
D.DSP

D.MSK

FUNCTION MASKS

LEGAL

0-17

I0.KIL,IO0O.WLB,IO.ATT

CONTROL

0-17

IO.KIL,IO.ATT,IO.DET

I0.DET

WS
We

D.PCB

0-17
0-17
20-37
20-37
20-37
20-37

+WORD
.WORD

«WORD

«WORD
+WORD

NOOP
ACP
LEGAL
CONTROL
NOOP
ACP

-y

-WORD

.WORD
-WORD

OO OOOW

+BYTE

D.UCB

.ASCII

D.LNK

. BMO

W ws

«WORD

+«WORD

:
SBMDCB

I0.WVB

PRO=0
BMST=.

.IF

DF M$SSMUP

+WORD

. ENDC

SBMDCB

.WORD

« =2

.BYTE
.BYTE
-WORD

O
UC.QUE,
0,US.OFL
DV.REC

.WORD

«.BMQO::

U.DCB
U.RED

U.CTL,U.STS*
U.UNIT,U.ST2
U.CWl

8-13

UCB'S

SAMPLE

DRIVER CODE

.WORD

;

U.CW2

.WORD
.WORD
.WORD
.WORD
.WORD

0
72.
$BMO
O
0,0

;
:
;
;
;

U.CW3
U.CW4
U.SCB
U.ATT
U.BUF,U.BUF+2

.WORD

;

U.CNT

BMND=,

SCB'S

$BMO::

.WORD

0,.-2

;

S.LHD

.WORD
.WORD
.WORD

0,0,0,0
O
0

:
;
;

S.FRK
S.KS5
S.PKT

.BYTE

0,0

;

S.CTM,S.ITM

.BYTE
.WORD
.WORD

0,0
0
0

;
;
:

S.STS,S.ST3
S.ST2
S.KRB - NO KRB SINCE NO CONTROLLER

BMDRV

.IDENT

/01/

- BLOCK MOVE

DRIVER

.END
.TITLE

(c)

:
SBMEND:

ALL

RESERVED.

1981,1982 BY DIGITAL EQUIPMENT CORPORATION.
—

RIGHTS

FURNISHED UNDER A

LICENSE AND MAY BE

USED

OR COPIED ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE.,

I/0

DRIVERS.

THIS

DRIVER

DEMONSTRATES:

—

1) THE CHECKING OF ADDITIONAL USER BUFFERS PRIOR TO QUEUEING
AN

I/O

USE

USE OF THE BUFFERED I/0O MECHANISM

USE OF THE GENERAL BUFFERED I/0O KERNEL AST MECHANISM

USE

REGION

USE

BLXIO

PACKET.
THE

CLOCK QUEUE

FROM

DRIVER.

LOAD KERNEL ASTS

THIS DRIVER UNDERSTANDS

PRECISELY ONE QIO,

WHICH

IS:

“y

THIS IS A SAMPLE DRIVER WHICH DEMONSTRATES HOW TO USE SOME
OF THE MORE SOPHISTICATED EXECUTIVE SERVICES AVAILABLE TO

WTME

SOFTWARE

THIS

IO.WLB, .....,<DEST-BUFFER,LENGTH,
TIME, SRC-BUFFER>
OR
I0.WVB

THE DRIVER QUEUES A CLOCK BLOCK FOR TIME TICKS AND AT THE
END OF THAT TIME INTERVAL COPIES THE SOURCE BUFFER TO THE
8-14

SAMPLE DRIVER CODE

IF POSSIBLE, THE REQUEST IS BUFFERED
INTERNALLY WHILE THE CLOCK REQUEST 1S POSTED.

‘wg

DESTINATION BUFFER.

.MCALL

PKTDFS

CLKDFS,

;DEFINE CLOCK BLOCK OFFSETS
;DEFINE I/0 PACKET OFFSETS

CLKDF$

PKTDF$

DEFINE MAXIMUM TRANSFER LENGTH WHICH WILL BE BUFFERED

100.

BUFLIM

, ,NEW
BM, ,NONE,

*%*

- BMINI

I/0

INITIATION

ENTRY POINT

INPUTS:

REGISTERS

(BECAUSE THE UC.QUE BIT IS SET IN THE UCB)
TO THE

ADDRESS OF

DRQIO

WNE

DDTS$

ADDRESS
ADDRESS

I1I/0 PACKET
S5CB
UCB

OUTPUTS:

ATION

INITIATED.

I/0

REQUEST

PACKET FORMAT:

NG
W

IF THE SPECIFIED CONTROLLER IS NOT BUSY AND AN I/O REQUEST IS WAITING TO BE PROCESSED, THEN THE REQUEST IS DEQUEUED AND THE I/O OPER-

OF
OF

SETS THE

FOLLOWING:

e
e
WE
We

I.LN2

POINTER TO SECOND LUN WORD IN REQUESTER TASK HEADER.

WTME

I.UCB

UCB

I.FCN

I.I0SB

I1/0 FUNCTION CODE (IO.WLB).
VIRTUAL ADDRESS OF I/O STATUS
RELOCATION BIAS OF I/0O STATUS

I.I0OSB+2
I.I0SB+4
I.I0SB+6

ADDRESS

DEVICE

BLOCK.
BLOCK.

I/0 STATUS BLOCK ADDRESS

(DISPLACEMENT + 140000).

DESTINATION BUFFER

I.PRM+6
I.PRM+10
I.PRM+12

FILLED IN WITH DISPLACEMENT ADDRESS OF DESTINATION

I.PRM
I.PRM+2
I.PRM+4

BUFFER

I.PRM+16

USED TO STORE BUFFER/CLOCK BLOCK ADDRESS
FILLED IN WITH PCB ADDRESS OF OUTPUT BUFFER

I.PRM+14

“ws

%Wy

—-- REQUEST PRIORITY, EVENT FLAG NUMBER.
ADDRESS OF THE TCB OF THE REQUESTER TASK.

VIRTUAL ADDRESS OF AST SERVICE ROUTINE.
RELOCATION BIAS OF SOURCE BUFFER.
BUFFER ADDRESS OF I/O TRANSFER.
NUMBER OF BYTES TO BE TRANSFERED.
TIME DISPLACEMENT IN TICKS
VIRTUAL ADDRES (TO BECOME RELOCATION BIAS)

I.TCB

QUEUE THREAD WORD.

I.PRI/I.EFN

I/0

I.LNK

. ENABL

LSB

8-15

khkkdkkhkhkhkhkhkhkhkhkhkhkhkhkhkhhkhhkkhkkhkhkhkhkhhkhkkhkhkhhkhkhkhhkhkhkkhkhkhhkhhkhhkhkhkhkkkhhkhkhkk

NITIATTION

*
*

khkkhhhkdhkhkhkhkhkhkhkhhkhkhhhhkhbhhkhhkhhhkhhkhkhhhhhhhhkhhhhhhhkhhhkhkhkhkhkhkhhkhkhdk

;

PRE-QUEUING

INITIALIZE

ENTRY

POINT

PARAMETERS

THE

SOURCE

LOADED,

THE

I/O

BUFFER WHILE

FILL

THE

TASKS

NECESSARY

PACKET

AND

CHECK

CONTEXT

ADDRESS

khkhkkdhkhkhkhkhkkhhhhkhkhkhbhkhhkhrhhhkhhkhhkhhkkhdhhkhkhkhkhkhkhkhhhkhkhhhhhkhhkhkhkhhkthkhkhkhhkikhkki

W
WE
W
Wy
W
e

POINT

BMINI:

khhkhkhkhkhkhkkhkhkhkhdhkhkhhkhkhkhkhhkkhhkhhhhhkkhkhkhkhkhkhkhkhhkhhhkhhkhkhkhkhkhkhkhkhkhhhkkhkhkhhkk

MOV

R1,R3

;

COPY ADDRESS

MOV
MOV

I.PRM+10(R1l),R0
I.PRM+4 (R3),Rl1

;
;

GET VIRTUAL ADDRESS OF SOURCE BUFFER
AND LENGTH OF SOURCE BUFFER

I/0

PACKET

—

U
R
R

I/O

CHECKED

PACKET

DRQIO)

C =

DISPATCHER)
I

OUTPUT

DIRECTIVE

PARAMETERS ARE:

IF CHECK AND PACKET
I.AADA OR I.AADA IN

UPDATE
PACKET

SUCCESSFUL
POINTS TO

RELATED ADB,

A.IOC

INCREMENTED

ALREADY
e

o e o

P.IOC,

CHECK UNSUCCESFUL OR
FILLED

I. AADA,

I.AADA

s o

$CKBFR

;

CHECK

BUFFER,

10$

;
;

P.IOC
IF CC

FOR APPROPRIATE
ALL WAS OK

THE

R
R

TO BE

CHECKED

I.AADA

(ESTABLISHED

us
.y

BLOCK
TO

CURRENT TASK HEADER MUST BE MAPPED THROUGH APR

BCC

BLOCK

(ESTABLISHED

CALL

THE

SATTPT = ADDRESS

WE
Wh
T]
-

W
N
WE
S
TMS
WG
WE
WE
WM

LENGTH

STARTING ADDRESS

——

INPUT PARAMETERS FOR S$CKBFR ARE:

THE

ugy

ENTRY

‘wg

SAMPLE DRIVER CODE

o o 1 o oot +

INCREMENT A.IOC

XX222 X323 22223222 X222 222222 XXX A

2R 2

AND

REGIONS

Rt 2 22 2

22X 2
*

SOURCE BUFFER WAS

ILLEGAL,

FINISH I/0 HERE

**********4******************************************************

MOV

$IE.SPC&377,R0

;

SET COMPLETION STATUS

CLR

;

AND NUMBER

8-16

BYTES

TRANSFERRED

DRIVER CODE

SAMPLE

$IOFIN ARE:

INPUT PARAMETERS FOR

= ADDRESS

THE

OUTPUT

I/O

TO RETURN
TO RETURN

PACKET

————_

PARAMETERS

ARE:

DESTROYED

%We

————

S—————

STATUS
STATUS

I/O0O
I/0O

FIRST
WORD OF
SECOND WORD OF

WONMOI.

=
=

W
%Ny

RO
R1

THE

e ————————————— +

SIOFIN

;

COMPLETE

I/0 AND EXIT

DRIVER

dhkhkhkhkhkdhhkhkhhhkhkhkhkhkhkhhkhkhkhkhkhkhkhkhkkkkhkkhhkhkkhkhkhkhkhkdkhkhkhkhkhkhkhkhkhkhkhkdhkhkdhdkiidkkikk
*

BUFFER WAS

CALLR

ADDRESS

LEGAL,

CONVERT

STORE

PARAMETERS

khkhkhkhkkkhkhkkhkhkhkkhkkhkhhkhkhkkhkhkhkkhkhkhkkhkhkhkhhkkhkhkhkhhkhkkhkkhkkhkkhkhkhkkhkhkhkkkkhkkkkkik

W——
S

SRELOC ARE:

W——

INPUT PARAMETERS FOR
USER

VIRTUAL ADDRESS

TO RELOCATE

PARAMETERS

APR6

DISPLACEMENT

ARE:

OUTPUT

THE

RSB,

KBUIONND SAIE

THE

BLOCK

USER

BUFFER

BIAS

140000

ST,

RELOCATION

DOUBLEWORD AND

VIRTUAL ADDRESS

CALL

SRELOC

MOV

R1,I.PRM+10(R3)

MOV

CLR

BUFFER ADDRESS

SAVE

BIAS

R2,I.PRM+12(R3)

;

AND

I.PRM+16(R3)

;

INDICATE

APR

DISPLACEMENT

NOT

SOURCE

BUFFER

ADDRESS

BUFFERED

I/O

NOW

QUEUE

THE

PACKET

THE

DEVICE

QUEUE

kkhkhhkhkhkhhkhkhkhhkhkhkhkhkkhkhkhhkkhkhkhkhkhhhkhkhkhkhkhkhkhkhkhkhhkkhkhkhkkkhkkidhkkdkhkdkkikkkkkkk

R4,R0

;

COPY

R3,R1

;

AND

TO
OF

I/0
I/0

QUEUE

+
S

FOR

SQINSP ARE:

TWO WORD

THE

PACKET

LISTHEAD
BE

INSERTED

THE

ADDRESS

R1
NO

OUTPUT

PARAMETERS

INPUT

DO,

THE

CALL

LISTHEAD

PACKET

——

POINTER
ADDRESS

——

———

MOV
MOV
wy
NS
WE
WE
WE
WE
s

RELOCATE

;

kkkkhkhdkhhkhdkhkkhhhhhkhhhhhhkhkhhhhhkhhhhhhhhhhhkhhkhkhhhhkrkrkhkhhkkkhk

10$

SQINSP

;

INSERT PACKET

QUEUE

SAMPLE

DRIVER CODE

khkkhkhkhkhkhkhhkhkhkhhhhkhhkhkhhkhkhkhkhhhkhkkhkhhkhkhkkhkhkkhkhkhhhkhkhhkhkkhkhkkhkhkkkhkkkkkk

WTME

BEGIN SERIAL

PROCESSING

I/0

PACKETS

l
;

oe+

-e

khkhkhkhkhhhhhhkhkhhhhhhkhkhhkhkhkhkhkhkhkhkhkhkhkkhhkhkhkhhkhkhkhkhhhhkhkhkhkhkhkhkhkhkhkkhkhkhkhkhkhkkkk

THE
R5

PARAMETERS

= ADDRESS

THE

FOR
UCB

S$GTPKT ARE:
OF

THE

OUTPUT PARAMETERS ARE:

C =

REQUESTING

UNIT

l
|

l
t

= CONTROLLER

INDEX

R4
R5

= SCB ADDRESS
= UCB ADDRESS

OF
OF

|
|

BMIN1:

CALL
BCC

UNIT BUSY OR NO

CONTROLLER
UNIT

PACKETS

QUEUED

|
l
I

l
e

SGTPKT
208

RETURN

ATTEMPT TO GET A REQUEST
IF CC WE GOT ONE

;
;

DEVICE BUSY OR QUEUE
REFERENCE LABEL

EMPTY

kdkhhkhkhhdkkhhhdkhhkhhkhhkkhhhdhhkhhdhhhkhhhhhhhhhhhhhhhhhhhhhhhhhhhkrhthhk

ATTEMPT

TO ALLOCATE

CLOCK BLOCK

khkhkhkhkhkhkhkhkhkhkhkkhkhkhkhkhhkhkhkhkhhkhhkhkkhkhhkhkhkhkhkhhkkhkhkhkhkhkhkhkhkhkkkhkhkkkhkkhkhkhhkhkkhkkkk

R1,R3

;

COPY

I/0

MOV

$C.LGTH,R1

;

SET

LENGTH

CLOCK

BLOCK

SIZE

THE

BLOCK

FOR

S$ALOCB ARE:

TO ALLOCATE

WSS

PARAMETERS

(IN

BYTES)

PARAMETERS

(NI

OUTPUT

ARE:

LENGTH

NO BLOCK

CALL

SALOCB
308
$IE.NOD&377,R0

THE

ALLOCATED

BLOCK

ALLOCATED BLOCK

ISCURRENTLY AVAILABLE

ATTEMPT TO ALLOCATE

IF CC SUCCESSFUL
SET I/0 STATUS

WM
AMNE WNIGE

SUCCESSFULLY ALLOCATED

ADDRESS

A BLOCK WAS
R0

THE
Q

NININ

INPUT

THE

BCC
MOV

PACKET ADDRESS

A——

MOV

————————————

;
:

0S:

C =

WS
WS
WE

s
ME

|
|
|
|
|

IF A REQUEST WAS SUCCESSFULLY DEQUEUED
R1 = ADDRESS OF THE I/O PACKET
R2 = PHYSICAL UNIT NUMBER

INPUT

DRIVER CODE

AN, SN

INPUT

OUTPUT PARAMETERS ARE:

A, SR
SILINN
GO, BTN
TV
DTN

THE

DESTROYED

WME

$IOALT

;

AND COMPLETE THE

BMIN1

;

GO LOOK FOR MORE WORK

MOV

RO,I.PRM+14(R3)

;

SAVE ADDRESS OF CLOCK BLOCK

2 2R R

R 22

2X 2 X222 222322232223 X2 2

2222222 2

I/0

X2 2222 222

2 2 2

2 2 &

DETERMINE IF I/O REQUEST IS BUFFERABLE

khkhkhkdkhkhkhkhkhkhkhkhkhkhkhkhkhhkhkhkhhkhkhhkhkhkhhhkhkhkhhkhhkkhkhkhkhkhkhkhkhkkhkhkhkhkhhhhkhhkhkhkhkkkk

:
:

THE INPUT PARAMETERS FOR $TSTBF ARE:
R3 = ADDRESS OF I/0 PACKET TO TEST

:
}

C
= 1

;
}

THE OUTPUT PARAMETERS ARE:
C = 0 IF REQUEST MAY BE BUFFERED

:
}

IF REQUEST MAY NOT BE BUFFERED

e;
Y

s
wWe

——————————————————————————— +

CALL

CALL
BCS
R R R R

$TSTBF
403
LR R

;
;

222 X222 X223 3

TEST FOR BUFFERABLE I/O REQUEST
IF CS CAN'T ALLOCATE A BUFFER
22322222222 222 22222222222

a2 2

& & 1

ATTEMPT TO ALLOCATE A BUFFER

SIOALT ARE:

RO = FIRST
WORD OF I/O STATUS BLOCK
R1 = SECOND WORD OF I/O STATUS BLOCK
R2 = STARTING AND FINAL RETRY COUNTS
(IF AN ERROR LOGGING DEVICE)
RS = UCB ADDRESS OF UNIT TO COMPLETE

305

PARAMETERS FOR

WU,

THE

WTM

WTMy
My
ME

“E

SAMPLE

khkkkhkhkhkhkhhkhkhhkhkhkhhhhkhhkhkhkhkhkhhkhkhhhrhkhkhkhkhhhkhhhhhkhhhkhhhhhkhkhhhkhkhhkhhkhkhkk

MOV
CMP
BHI

I.PRM+4(R3),R1
R1l, #BUFLIM
408

;

;
;

GET

LENGTH OF BUFFER
BIGGER THAN BUFFER LIMIT ?
IF HI YES, DON'T BUFFER

8-19

DRIVER CODE

SN,
B SIS SN
NN

BLOCK

ALLOCATE

Wy
W

(IN

BYTES)

BLOCK WAS

SUCCESSFULLY

= ADDRESS

THE

ALLOCATED

BLOCK
LENGTH OF THE ALLOCATED BLOCK
BLOCK ISCURRENTLY AVAILABLE

CALL

SALOCB

;

TRY

BCS

40$

TO ALLOCATE

COULDN'T

BUFFER
GET ONE

khkhkdhkhkdhkhhkhkhkhhkhhhkhkhhkhkhhkhkhkhhhkhhkhhhkhhhhkhkhkhkhhkhkhhhkhhhhhhhhhhrhhhhkdhdkik

COPY USER BUFFER TO INTERNAL BUFFER

:
*

khkkkkhdhkhkhkhhkhkhkhhkhkhkhhhkhkhkhkhhkhkhhkhhkkhhkhkhhhhhkhkhkhhkhkhhkhhkhkhkhhkhhhkhkhhrhhhhkkhkk

MOV

RO,R4

;

SET

MOV

R3,R5

;

SAVE

ADDRESS

DESTINATION

I/0

MOV

I.PRM+4(R5),R0

;

SET

LENGTH

MOV

I.PRM+10(R5),Rl1

;

SET

BIAS

MOV

I.PRM+12(R5),R2

;

AND

DISPLACEMENT

;

STRIP

#140000,R2

BIS

$#120000,R2

MOV

R4,I.PRM+10(R5)

OFF

TRANSFER

SOURCE

APR6

SET

INTERNAL

BUFFER

ADDRESS

; AND SUBSTITUTE APR5
;

BUFFER

PACKET

BUFFER

BITS

ADDRESS

INTO

PACKET

RO
R1

=
=

R2
R3
R4

PARAMETERS

NUMBER

FOR

$BLXIO

OF BYTES TO MOVE
APR 5 BIAS

SOURCE

DISPLACEMENT

DESTINATION

APR6

DESTINATION

DISPLACEMENT

SOURCE

ARE:

GOSN

BIAS

AN U

LAST

BYTE

OF SOURCE/DESTINATION

POINT

SIS

-y

R2,R4

ARE

ALTERED
PRESERVED

R1,R3

PARAMETERS

OUTPUT

THE

myg

WNE

INPUT

THE

BT WS S,

T
S
—

OS], QO

%y
ws
My
g
N

THE

ARE:

my
mE
N
NE
WE

%N
N
WS

SALOCB

WE
e
W

BIC

SIZE

FOR

THE OUTPUT PARAMETERS ARE:

‘we

wmg

PARAMETERS

R,
DN Al

INPUT

ot W S—— —_ ST WS, A

3Omn

THE

AL SO

%§

SAMPLE

COPY

INTERNAL

BUFFER

;

************************************************************

SBLXIO

CALL

ee+

*****
%*

BUFFERED

I/0

REQUEST

CONVERT TO

khkdkhhkdkhhhhkhkhhkhkhkhhkhkhhkhkhhkhkhkhhhhhhhhhhhhbhhhkhhhhkdhhhhhhhhhhhkkhhddhd

MOV

R5,R3

;

COPY

I/0

PACKET

ADDRESS

BACK

TT
T
+

SAMPLE DRIVER CODE

THE

INPUT PARAMETERS

FOR

$SINIBF ARE:

{
R3 = ADDRESS OF THE I/0 PACKET TO BUFFER
:
}
NO OUTPUT PARAMETERS.
:
- SRS ;
CALL

SINIBF

;

INITIALIZE BUFFERED

I/0O

khkhkhkhkhkhhkhkhkhkhkhkhkhkhkhhkhkhkhkhkhkhhhkhkhkhkhkhkhhhkhkhhhkhkkhkkhkhkhkhkhkhkhkhhhkhkhkhkhkhkhkhkkkkkk
*

QUEUE THE CLOCK BLOCK

I.PRM+14(R3)
,R0 ;
#CLKSRV,C.SUB(RO)
R1
;

GET ADDRESS OF CLOCK BLOCK
; SET ADDRESS OF SUBROUTINE
HIGH ORDER DELTA TIME

MOV
MOV
MOV

I.PRM+6(R3),R2
#C.SYST,R4
R3,R5

LOW ORDER PART
SET REQUEST TYPE
USE PACKET ADDRESS AS

ee+
SO
SO
NN

= ADDRESS

OUTPUT

CLOCK

QUEUE

OF DELTA TIME
OF

DELTA

TIME

LOW ORDER HALF
REQUEST TYPE

BLOCK

OIS

=
=

THE

WSSOI

R2
R4

ORDER HALF

ADDRESS

REQUESTING

TASK

IDENTIFIER

SOV

R1 = HIGH

PARAMETERS.

SRS

W
TN

THE INPUT PARAMETERS FOR S$SCLINS ARE:

OVSSRORNIE SUNIE SMONIE SN SN

WE
WS
W
NS
N
WTMME
WME
WME

IDENTIFIER

-e

we
e

CLKSRV:

SCLINS

CALLR

QUEUE

-e

;
;
;

[t~

MOV
MOV
CLR

WNE

2024

b 2 ]

khkhkhkkhdkhdkhhkhhhkhhhhkhhhkhhhhhhhhhhrhhkhkhhhkhhhhhhhhhhhhhhhhhhhhhdkhkhkdhik

EXIT

CLOCK
THE

BLOCK

AND TEMPORARILY

DRIVER

*hhkhkhkhkhhkhhhkhkhkhhkhhhkhkhkhhhkhkhkhkhkhhkkhkhkhkhhkhkhkhkhkhkkhkhkhkhkhkhkhkhhhkhkhkkhkhkhkhkkkdkhkkkk
*

CLOCK

ENTRY

POINT

Y deddedededededdedhhhkhkhkdkddhddkhkdkhhkdhkdhdkkhddkdkdkkdkdhdkdkdhdkdkdkhkdkdkhkhdkdhkkhkhkkihkkkikkkkikk

Jdedede de de g de e de dede dede ek ek ke

ke ok odek ok ok dhok dk ok ok dkkkdkkdkkdkkkdkhkdkhkkdkkdkdhkkdkkdkkkdkkkikkkikikk

CHECK TO SEE

THE

I/0 WAS

BUFFERED

khkkkhkhkhkkkhkhhkkhkkhkhhkkhhkhkhkhkhkhkkhkhkhhkhhkhhkhkhkhkhkhhkhkhhkdhhkhkhkhkhkdkkhdhkkikkkhhdkikikk

MOV

C.TCB(R4) ,R5

;

GET ADDRESS

TST
BNE

I.PRM+16(RS)
508
|

;
;

WAS IT BUFFERED I/O
IF NE YES, GO QUEUE

I/O

PACKET
KERNEL

AST

Ly
T Ty Y”
*

¥*

COULDN'T

BUFFER,

PERFORM

COPY

HERE AND NOW

*
*

khhkhkhkkhkhkhkhkhkkhkhhkhkhhhhkhkkhkhkhkhkkhkhkhkhkkhkkkhkhkhkhkhkhkkhkkhkkhkkhkhkkhkkhkhkhkkhkkkkkkkk

8-21

SAMPLE

MOV
MOV
MOV
BIC
BIS
MOV

I.PRM+4 (R5),R0
I.PRM+10(R5),R1

SET LENGTH TO TRANSFER
BIAS OF SOURCE BUFFER
DISPLEACEMENT OF

SOURCE
STRIP OFF APR6 ADDRESS BITS
AND CONVERT TO APRS
SET BIAS

DESTINATION

SET DISPLACEMENT
o

o o

e o o

SHAUNAAE armioaiillL S

NUMBER OF BYTES TO MOVE
SOURCE APR 5 BIAS
SOURCE DISPLACEMENT
DESTINATION APR6 BIAS
DESTINATION DISPLACEMENT

=
=
=
=
=

THE

OUTPUT

ALTERED

PARAMETERS ARE

WA
SPCLS. ADN

R1,R3

PRESERVED

R2,R4 POINT TO LAST BYTE OF

SOURCE/DESTINATION +1

e e

I1.PRM+14(R5),R0
#C.LGTH,R1

;

;
s

o o

GET ADDRESS OF CLOCK BLOCK
GET LENGTH OF CLOCK BLOCK

e
eo

THE INPUT PARAMETERS FOR SDEACB ARE:

RO = ADDRESS OF BLOCK TO DEALLOCATE

;

NO OUTPUT

R1 = LENGTH OF BLOCK TO DEALLOCATE

|
‘

PARAMETERS.

e eS

CALL

SDEACB

;

DEALLOCATE

BMDON:

MOV
MOV
MOV
MOV

R5,R3
$1S.SUC&377,R0
I.PRM+4(R3),R1
I.UCB(R3),R5

:
;
;
:

COPY PACKET ADDRESS FOR $IODON
SET FINAL I/O STATUS
AND LENGTH OF TRANSFER = REQUESTED
GET UCB ADDRESS OF DEVICE

;

;
:
;
r

|
|
l

;

[

;

o————

RS = UCB ADDRESS OF UNIT TO COMPLETE
THE OUTPUT PARAMETERS ARE:

n——

RO = FIRST
WORD OF I/0 STATUS BLOCK
R1 = SECOND WORD OF I/O STATUS BLOCK
R2 = STARTING AND FINAL RETRY COUNTS
(IF AN ERROR LOGGING DEVICE)

VOO,

THE INPUT PARAMETERS FOR S$IODON ARE:

;

.o o

|
[
|
|

H
:
:
:

DESTROYED

— — ——— — — ——————————— " "

o e

BMSUC:

e e

COPY BUFFER

;

l
|
l

SBLXIO

o o

an—

;

NSO

ST,

RO
R1
R2
R3
R4

;
;
;

;

INPUT PARAMETERS FOR S$BLXIO ARE:

THE

MOV
MOV

;
;

CODE

g
s
WE
s
%y
A
WTME
WME
NG
ME
WE
NG
WE
W
WHE
W
WE

;

#140000, R2
#120000, R2

CALL

’

I.PRM+2(R5),R4

I.PRM+12(R5),R2

MOV
o

I.PRM(R5) ,R3

;
;
;
:
:
:

DRIVER

o
o "~

8-22

SAMPLE

s
s
s
Wy
s

50$:

Ahkkdkhkhdhhkhhhkhhkhhhhhkrrhhhhkhhhhhkhhkhkhkhhhhhhhkhhkhkhhhkhkhkkhkhhhkthhkhkhkhkkhhkkk
*

MOV

R4,R3

$AK.GBI, (R4)+

us
s
Ny
Wy
s
Wy
B
W
WS
WE

Wy
s
s
Ws
e

s
Wy
Wy

;

:
;
;

KISARS, (R4)+
#KATSRV, (R4)+
R5, (R4)+

POINT TO TCB OF TASK
SKIP LINK WORD
SET A.CBL=AK.GBI

SET APR BIAS OF SERVICE ROUTINE
OF PROCESSING ROUTINE
SET ADDRESS
SAVE I/O PACKET ADDRESS IN CLOCK BLOCK
———————— ————————————————— +

; COPY CLOCK BLOCK ADDRESS FOR $REQUE

;
;

I.TCB(R5),R0
(R4)+

MOV
TST

;

THE INPUT PARAMETERS FOR S$REQUE ARE:

l
I

RO = TCB ADDRESS TO QUEUE AST BLOCK TO
R3 = ADDRESS OF THE PACKET TO QUEUE

NO OUTPUT PARAMETERS.

l
|

|
l

o=
— +

CALLR

khkhkhhhkkkhhhhkhkhhhhhhhhhkhkhhkhhkhhkhkhhhkhhhhhkhhkhhhkhhkhhkhkhkkhhhkhkhhhhdkhhhik

MOV

*
*

BUFFERED I,/0, CONVERT I/O PACKET TO KERNEL
AST AND EXIT FROM DRIVER

*
*

MOV
MOV
MOV

;

$REQUE

QUEUE AST TO TASK

khkkhkhhkhkkhhkhhhkkhhkhhkdhhhhhkhthkhkhrkhhhhkhhhhkhhhhkhkhbhkhkhkhhkhkhkhkhkhkhkhkhkhkkhkhkhkhkhkk

KERNETL

A ST

ENTRY

POINT

*
|
*
hkhkdkhkhdkhkhhhhhkhhhhhhhhkhdkhhhhhhkhhkhhkhkrhhkhkdhhhhhkhdhhhhhhhkhkhdhhk
e

L X AR R 22 2222222232222 22332222 22222222 22 2 2 R a

st t t R 2 & 0 X2 &

GET PCB ADDRESS AND SEE IF PARTITION IS RESIDENT

MOV
MOV
BEQ

10(R3),R5
I.PRM+16 (R5),R1
708

*
hkhkhkhkhkhhkhkhhkhkhkdhhkdhhkhhkdkhkhhhhhhhhhhkhhkhhhkhkhhdhhhhhkhhhkhkdhhhkhkhhkhkhkhhhhhkk

;
;
;

GET I/0 PACKET ADDRESS
GET PCB ADDRESS OF BUFFER REGION
IF EQ THERE IS NO COPY TO PERFORM

INPUT PARAMETERS FOR STSPAR ARE:

S——— A——

THE
C

OUTPUT PARAMETERS ARE

0 IF REGION IS RESIDENT AND CAN BE ACCESSED

C =1

OF ASSOCIATED TASK

IF REGION IS NOT RESIDENT AND AST HAS

——

BEEN

QUEUED

CALL
BCC

e o
STSPAR
60S

; REGION IN MEMORY ?
; IF CC REGION IN MEMORY

SN S

R5 = TCB ADDRESS

PRTSE——————

RO = ADDRESS OF THE PACKET (THE KERNEL AST BLOCK)
R1 = PCB ADDRESS OF THE PCB CONTAINING THE BUFFER

THE

WME

KATSRV:

COMPLETE THE I/0
GO LOOK FOR MORE WORK

;
;

$10DON
BMIN1

CALL
BR

DRIVER CODE

HME

SAMPLE DRIVER CODE

Wy
s
Wy
wmy
s

*
R

22X

2SR 2 222 2 2 2 R AR R R R 2 222 2 0 & 21

*
by
2
222 R R0 R b S bbb
22 22222 2222
R 22222322

s
s
;
;
s
;

I.TCB(R5) ,R0
T.IOC(RO)
I.PRM+4 (R5),R0
I.PRM+10(R5),R2
P.REL (R1),R3
I.PRM(R5),R3

;

I.PRM+2(RS5),R4

GET TCB ADDRESS OF TASK
ADJUST REAL I/0O COUNT UPWARDS
GET COUNT OF BYTES
SET SOURCE BUFFER ADDRESS
GET STARTING BIAS OF PARTITION
AND ADD IN OFFSET
SET DISPLACEMENT

A—_ Su——
2

THE INPUT PARAMETERS FOR $BLXIO ARE:

onnti
S
S
SN
SADY
WIS
AN SO

THE
RO

OUTPUT PARAMETERS ARE
ALTERED

R1,R3

N
A

NUMBER OF BYTES TO MOVE
SOURCE APR 5 BIAS
SOURCE DISPLACEMENT
DESTINATION APR6 BIAS
DESTINATION DISPLACEMENT

=
=
=
=
=

RO
R1
- R2
R3
R4

PRESERVED

R2,R4 POINT TO LAST BYTE OF SOURCE/DESTINATION +1

my
NS
WA
ME
WS
e
e

g
e
We
e
me
We
We

EXIT AST SERVICE ROUTINE

— +
e ee

-y

;

X XXX

R R R

MOV
INCB
MOV
MOV
MOV
ADD

w
NS
Wy
N
NP
WG
WE
WP
WG
WE

GET TCB ADDRESS
BUMP BUFFERED I/O COUNT

PERFORM BUFFER COPY OPERATION

SBLXIO
I.PRM+10(R5),R0
I.PRM+4 (R5) ,R1
e

e e

o o

;
;
;

COPY THE BUFFER
GET BUFFER ADDRESS AGAIN
GET LENGTH OF BUFFER
o

eo oo

THE INPUT PARAMETERS FOR S$SDEACB ARE:

l
|

RO = ADDRESS OF BLOCK TO DEALLOCATE
R1 = LENGTH OF BLOCK TO DEALLOCATE

NO OUTPUT PARAMETERS.

eoo

SDEACB

ot o o o o o

I
|

l
eo

DEALLOCATE

e
:

e o

CALL
W

:
:

I.TCB(R5),R0
T.TIO(RO)

CALL
MOV
MOV

*****************************************************************

EXIT AST SERVICE ROUTINE.

MOV

BACK UP TO FORCE I/O RUNDOWN IN CASE OF ABORT AND

RETURN

BUMP BUFFERED I/O COUNT

A REGION AST WAS QUEUED.

MOV
INCB

60%

22 22222222223 22X X222 X2 2 22 2 s R a2 2l 2 A 22t bt hh dd b

***************w**************w****ww****************************
*

IF THIS WASN'T A REGION LOAD AST, FINISH THE I/0

*
*
**********
***********
***********
***********
***********
***********

SAMPLE DRIVER CODE

MOV

I.PRM+14(R5),R0

;

RETRIEVE

TST
BNE

(RO)
80$

;
;s

WAS THIS A
IF NE YES

REGION

MOV

#C.LGTH,R1

SET

SDEACB

ARE:

FOR

ADDRESS

LENGTH
OUTPUT

BLOCK

DEALLOCATE

PARAMETERS.

————

e ———————————————,— +

CALL

SDEACB

;

DEALLOCATE CLOCK BLOCK

MOV

I.IOSB(R5),R3

;

MOV

GET

#IS.SUC&377,-(SP)

;

(R3)+

;

VIRTUAL ADDRESS

SET

FIRST

I/0

WRITE

FIRST WORD OF

MTPDS

;

(R3)

SECOND WORD

CLR

;

I.IOSB(R5S)

WRITE SECOND WORD

;

PREVENT

MOV

R5,R3

;

COPY

JMP

BMSUC

;

FINISH

SET

SIODON

STATUS

I.PRM
(R5) ,-(SP)
+4

I/0

STATUS

BLOCK

WORD

I/O

(MAY TRAP)

STATUS

(MAY TRAP)

ATTEMPT

TO WRITE

STATUS

I/0

PACKET ADDRESS
IN COMMON CODE

*%***************************************************************

-~y

PARAMETERS

SONNEE SN

l
l
I

INPUT

RO
R1

BLOCK

MMM

|
|

MOV

RECONVERT REGION

LOAD AST

TO A

TASK AST

*
%

khkhkhhkhhhhkhhkhkhkhhhhhhhhhkhhhkhhkhkhhhkhkhhhhhhkhkhkhkhkhhhkhhhhhhhhkhhkdhkr

kdkkhhkik

MOV
CLR

RO, R3
10(RO)

;

COPY

;

INDICATE

MOV

I.TCB(R5),R0

GET

BLOCK

TCB

ADDRESS

BUFFER

TIME

ADDRESS

e e

TCB

ADDRESS

S$SREQUE

QUEUE

AST

BLOCK

THE

PACKET

QUEUE

FOR

ADDRESS

e e

PARAMETERS.

OUTPUT

SREQUE

RE-QUEUE

TASK AST AND

EXIT AST

;

*******************************************************

CALLR

WE
Whk

ARE:

PARAMETERS

RTINS SN

INPUT

THE

CLOCK

ee4

THE

MTPDS

80$

LENGTH

ADDRESS
LOAD AST ?

MMM

Wy
N
s
Wes
WE
-~

LT I T

l
!
l

AST BLOCK

708

SERVICE

**********
*

POINTS

khhkkhkhkkdhhkhkhhkhkhhhkhhhhkhhhkhkhkhhkhhhkhhhhkhhkhkhkhhhhkhkhhkhhhhhhkhdhhhh

khkkhkhkhkhhhhhhhkhkhhhhhkhhkhhkhkhhhkhkhhkhkhhhkhhhhhhhkhhkhkhhhhhhhhhhdhr

%*
hhhkhhhkk

krhhhhhdd

CANCEL

ENTRY

POINT

%
%

BUT WE

e wms

ENTRY

MISCELLANEOUS

COULD

DEQUEUE

DON'T,

PENDING

JUST

LET

CLOCK

REQUEST,

THEM

COMPLETE

ETC HERE,
LATER

khkkkhkhkhkhhhkhhhhkhkhkhkhkhhkhkhkhkhkhhhhhkhkhhhhkhkhkhkhhhkhhhhhhdkhhhhdkddhhhkdiik

*
*
*
*

SAMPLE

DRIVER CODE

kkhkhkhkhkhhhkdkhdhhhhhkhhhkhhhhhhhhhhkhhkhkhhkhkhkhhhhkhhhkhkhkhkhkhhhdhkhhkhkhhhhhkhk
%*

ENTRY

POINT

TIMEOUT

*
*

SINCE THERE'S NO PHYSICAL DEVICE TO TIME OUT, NO-OP

* R

Y Y

R 22222222223 XXX 232 X2 2 2 2 2 2 22

*
*

BMCAN:

222 2 2 R Rttt 2

POINT

ENTRY

POWERFATIL

POWERFAIL DOESN'T AFFECT NON-EXISTENT DEVICES

khkkhkhkhkhkhkhhkhkhhkhkhkhhkhhhhkhkhhhhhhhkhkhkhhhhhhkhkhhhhhkkhkhkhhkhhkhkhhkhhhhrkkhkkk

BMOUT:

R R

N Y .

R 2222222222232 X223 2222 22 222

a2 ottt b by

TMMe

khkhkhhhhhkhhhhkhkhdhhkhhhhhhhkhhhhhhhhhhhhkhkhhhhkhhhhhkhkhhkhhhkhkrhhhhdhkhhkhk
*

*
*

ENTRY

POINTS

DON'T NEED TO TOUCH NON-EXISTENT DEVICE, JUST LET
EXEC PUT DEVICE ON/OFF LINE

X 2 22 R R 2222222222222 X232 22 2 2 2 s R 2R ittt

BMKRB:

BMUCB:

RETURN

C HANGE

S TATUS

; ALL THESE ARE NO-OP FOR NOW

« END

8-26

WMy

BMPWF:

APPENDIX A

RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS

This appendix describes the RSX-11M-PLUS

system

macros

symbolic offsets for data structures listed in Table A-l.

that

supply

The data structures are defined by macros 1in the Executive macro
To reference any of the data structure offsets from your
library.
code, include the macro name in an .MCALL directive and invoke the

macro.

For example:

.MCALL DCBDFS$

:Define DCB offsets

DCBDFS

NOTE

All physical offsets and bit definitions
are subject to change in future releases

that
Code
system.
the operating
of
data structures should
system
accesses
rather
offsets
always use the symbolic
than the physical offsets.

The first two arguments, <:> and <=>, make all definitions global. If
they are 1left blank, the definitions will be local. The SYSDEF
argument causes the variable part of a data structure to be defined.
All

these

macros

are

also

LB:[1,1]EXEMC.MLB.
SHDDF$

All

are

except
the

the

Fl1DF$,

macro

library,

definition

library,

Executive

ITBDF$, MTADF$, OLRDF$, and

Executive

LB:[1,1]EXELIB.OLB.

Table

Summary of

Macro

Arguments

A-1

System Data

Structure Macros

Data Structures

ABODFS$ | <:>,<=>
|

Task abort and termination
notification message codes

ACNDFS | <:>,<=>

Accounting data structures

CLKDFS | <:>,<=>

| Clock queue control block

(user account block, task account
block, system account block)

(continued on next page)

RSX-11M-PLUS

SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS

Table

Summary

Macro

System

A-1

(Cont.)

Data

Structure

Arguments

Macros

Data

CTBDFS | <:>,<=>

Controller

DCBDFS$ | <:>,<=>,SYSDEF

Device

EPKDFS$ | <:>,<=>

Error

F11DF$ | <:>,<=>,SYSDEF

Files-11

Structures

table

control
message

(volume
entry,

block
block

data structures
control block, mount

file

control

window block,
node)

file

block

list

locked

HDRDFS | <:>,<=>

Task header

HWDDFS$ | <:>,<=>,SYSDEF

Hardware register addresses
feature mask definitions

ITBDFS | <:>,<=>,SYSDEF

Interrupt

transfer

block

KRBDFS | <:>,<=>

Controller

request

block

LCBDFS | <:>,<=>

Logical

MTADFS | <:>,<=>

ANSI magtape data structures
(volume set control block)

OLRDFS$

On-line

PCBDFS | <:>,<=>,SYSDEF

SCBDFS$ | <:>,<=>,SYSDEF

window block

assignment

control

reconfiguration

Partition
attachment

PKTDFS | <:>,<=>

and

list

block,

control

block

and

block

interface
and

descriptor

I/0 packet, AST control block,
offspring control block, group
global event flag control block,
and CLI parser block

Status

control

assignment

block

and

block

SHDDFS | <:>,<=>

Shadow

TCBDFS | <:>,<=>,SYSDEF

Task

control

block

UCBDFS |<:>,<=>,TTDEF, SYSDEF

Unit

control

block

recording

linkage

UMR

block

RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS

ABODF$

NONONONnnonmomununnmnonnov
NN U DU U
S S S

ABODFS

TASK ABORT CODES

NOTE:

S.COAD-S.CFLT ARE ALSO SST VECTOR OFFSETS
;TASK STILL ACTIVE
;TASK EXITED NORMALLY

. COAD=0.
.CSGF=2.
.CBPT=4.
.CIOT=6.
.CILI=8.
.CEMT=10.
.CTRP=12.

.CFLT=14.
.CSST=16.
.CAST=18.
.CABO=20.
.CLRF=22.
.CCRF=24.

. IOMG=26.
. PRTY=28.
.CPMD=30.
.CELV=32,
.CINS=34,
.CAFF=36.

S.CCSM=38.
S.COTL=40.

;ODD ADDRESS AND TRAPS TO 4

; SEGMENT FAULT
;BREAK POINT OR TRACE TRAP
; IOT INSTRUCTION
; ILLEGAL OR RESERVED INSTRUCTION
;NON RSX EMT INSTRUCTION
; TRAP INSTRUCTION
;11/40 FLOATING POINT EXCEPTION
;SST ABORT-BAD STACK
;AST ABORT-BAD STACK
;ABORT VIA DIRECTIVE
; TASK LOAD REQUEST FAILURE
;TASK CHECKPOINT READ FAILURE
;TASK EXIT WITH OUTSTANDING I/O
; TASK MEMORY PARITY ERROR

; TASK ABORTED WITH PMD REQUEST
;TI: VIRTUAL TERMINAL WAS ELIMINATED
; TASK INSTALLED IN 2 DIFFERENT SYSTEMS
; TASK ABORTED DUE TO BAD AFFINITY (REQUIRED
;BUS

RUNS ARE OFFLINE OR NOT PRESENT)
;BAD CSM PARAMETERS OR BAD STACK
;TASK HAS RUN OVER ITS TIME LIMIT

’

TASK TERMINATION NOTIFICATION MESSAGE CODES

T . NDNR=0

T.NDSE=2

T.NCWF=4
T.NCRE=6
T.NDMO=8.
T.NUER=10.
T.NLDN=12,

T.NLUP=14.

T.NCFI=16.
T.NUDE=18.
T.NMPE=20.

T.NKLF=22,
T.NAAF=24,

;DEVICE

NOT READY
:DEVICE SELECT ERROR
: CHECKPOINT WRITE FAILURE
:CARD READER HARDWARE ERROR
;DISMOUNT

COMPLETE

s UNRECOVERABLE ERROR
;LINK DOWN (NETWORKS)
;LINK UP (NETWORKS)
;CHECKPOINT FILE INACTIVE
; UNRECOVERABLE DEVICE ERROR
:MEMORY PARITY ERROR
;UCODE LOADER NOT INSTALLED
;ACCOUNTING ALLOCATION FAILURE

T.NRCT=30.

sACCOUTING TAB ALLOCATION FAILURE
;sTASK HAS NO DEBUGGING AID
:REPLACEMENT CONTROL TASK NOT INSTALLED

T.NWBL=32,

sWRITE BACK CACHING

T.NTAF=26.

T.NDEB=28.

;UNIT WRITE

LOCKED

DATA

LOST

RSX-11M-PLUS

SYSTEM

DATA

STRUCTURES AND SYMBOLIC

DEFINITIONS

ACNDF$

ACCOUNTING

ACNDFS$

FOR

BLOCK OFFSET AND STATUS

TRANSACTION

DEFINITIONS

TYPE.

HEADER COMMON TO ALL TRANSACTIONS

-y

EACH

.ASECT

000000
000002

B.LNK:
B.TYP:
B.LEN:
B.TIM:

.BLKW
.BLKB
.BLKB
.BLKW

1
1
1
3

;LINK TO NEXT

; TRANSACTION

TYPE

SYSLOG

; TRANSACTION

LENGTH

QUEUE

000003
000004
000012

B.HID=.

000012

B.UID:

.BLKW

; ENDING TIME OF TRANSACTION
;START OF HEADER IDENTIFICATION AREA
;UNIQUE SESSION IDENT

000016

B.ACN:

.BLKW

; ACCOUNT

000020

B.TID:

.BLKB

;ASCII TERMINAL TYPE (V,T,B OR C)
; (VIRTUAL,REAL,BATCH, OR CONSOLE)
;UNIT NUMBER

;FIRST WORD-RAD50,

000021
000022

000022

;END OF HEADER
;HEADER LENGTH

B.HEND=,

$SSHLN=.

SECOND-BINARY

NUMBER

ID AREA

ACCUMULATION FIELDS
000022

000026
000032
000036
000042

000050
000056
000062
000064
000065

B.CPU:
B.DIR:
B.QIO:
B.TAS:
B.MEM:
B.BEG:
B.CPUL:
B.PNT:
B.STM:

$SSTLN=.

.BLKW
.BLKW
.BLKW
.BLKW
.BLKW
.BLKW
.BLKW
.BLKW
.BLKB

FOR TAB,

UAB,

AND SAB

; TOTAL CPU

; TOTAL DIRECTIVE

2
2
3
3
2
1
1

TIME

USED

COUNT

: TOTAL QIO$ COUNT
: TOTAL TASK COUNT
; RESERVED

;BEGINNING/LOGIN TIME
;CPU

LIMIT

; POINTER TO HIGHER
: STATUS MASK
s TOTAL'S LENGTH

LEVEL TOTALS

;

USER ACCOUNT BLOCK

NOTE:

; START AFTER TOTALS

.=$$STLN

000070

B.USE:
B.ACT:
B.UUIC:

.BLKB
.BLKW
.BLKW

1
1
1

000072

B.UCB:

.BLKW

000074
000102

000104

B.LGO:
.BLKW
B.ULNK: .BLKW
B.RNA:
.BLKW

000112

B.NAM:

000065
000066

000130

000131

(UAB)

UAB'S MUST END ON A WORD BOUNDRY

.BLKB
. BLKB
.BLKB

000132

B.ULEN=,

000002

§88=<.+77>/100

;USE COUNT

:NUMBER OF CURRENTLY ACTIVE TASKS

; LOGIN

UIC

; POINTER TO UCB
; LOGOFF TIME
;LINK TO NEXT UAB

;LOC IN SYSTEM ACCNT FILE
; (OFFSET, VBN-HI, VBN-LO)

14,
1
1

;LAST NAME

;FIRST

; UNUSED BYTE
;UAB

USER

INITIAL
OF

LENGTH

;UAB LENGTH

USER

(ROUNDED UP TO 32 WORD BOUND)

RSX-11M-PLUS

SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS

TASK

ACCOUNT
NOTE:

BLOCK
THE

(TAB)

TAB

MUST

END

A WORD BOUNDRY

-y

ACNDF$ (Cont.)

«.=$S$STLN

; STARTS

AFTER

TOTALS

NAME

ADDRESS

. BLKW

; TASK

et et e

B.TNAM:

: TCB

= b

; HIGHEST RUNNING

; CURRENT UIC OF
; PROTECTION UIC

. BLKB

;sNUMBER

B.PRI:

; TIMES

TASK

HAS

000065
000066

sNUMBER

DI SK

000072

B.TCB:

- BLKW

000074
000076

B.TST3:

. BLKW

000100

B.CUIC:

« BLKW

000102

B.PUIC:

. BLKW

000104

B.CTXT:

. BLKW

000110

B.TCKP:

« BLKW

000114
000120

B.OVLY:

. BLKW
« BLKW

000124

B.TLEN=,

; TAB

000002

B.TBLK=<.+77>/100

; NUMBER

. BLKW

B.EXST:

;T.ST3 FROM TASK'S TCB
;RESERVED FOR FUTURE STATUS

;EXIT

; SYSTEM ACCOUNT BLOCK
=S$S$STLN

000065

B.SHDN:

.BLKB

000066

B.UHD:

.BLKW

000070
000072

B.ULO:

.BLKW

B.ULT:

.BLKW

000076

B.CKP:

.BLKW

000102
000106

B.SHF:

.BLKW

B.RND:

.BLKW

000112

B.FID:

.BLKW

000120
000122

B.DVNM:

,.BLKB

B.UNIT:

.BLKW

000124

B.EXTS:

.BLKW

000126
000134

B.LSCN:

.BLKW

B.SCNR:

.BLKW

000136

B.DSCN:

.BLKW

000140

B.STSP:

.BLKW

000144

B.SYSM:

.BLKW

000146
000154
000160

B.CKUS:

.BLKW

B.CKSP:

.BLKW

B.CKAL:

.BLKW

000162

B.SLEN=,

CONTEXT

STATUS

BITS

TASK
OF TASK
LOADS

BEEN

CHECKPOINTED

OVERLAY

AND ABORT

LOADS
CODE

LENGTH

SEC

POOL

BLOCKS

TAB

(SAB)

HRWRNFFHWRRFRDWRNNDRN
N

’

PRIORITY

;START AFTER

TOTALS

;sACCOUNTING

SHUTDOWN

;UAB

REASON

CODE

LISTHEAD

;NUMBER

USERS CURRENTLY
OF LOGONS

; TOTAL

NUMBER

; TOTAL

NUMBER

;s TOTAL

NUMBER

;NUMBER

;FILE-ID

CP U

;DEVICE

;EXTEND

SIZE

; SCAN

RATE

INTERVALS

ROUNDED

FILE

TRANSACTION FILE

- OF
OF

CHECKPOINTS
SHUFFLER RUNS

TRANSACTION

:UNIT
; TIME

OF
OF

LOGGED

TRANSACTION
FOR

LAST

FILE

SCAN

; STATISTICAL

FILE

TRANSACTION

SECONDS
SCAN

RATE

(IN

SEC)

; RESERVED
; RESERVED
; RESERVED
; RESERVED
; RESERVED
;SAB

LENGTH

NEW

FIELDS

FOR

EXTENDED ACCOUNTING

-y

wme

000162

B.CPUT:

« BLKW

;CPU

000202
000222

B.CTXP:

. BLKW

;NUMBER

CONTEXT

B.IDCT:

. BLKW

;NUMBER

IDLE

000242

B.QIOC:

« BLKW
« BLKW
. BLKW

;NUMBER

I/0

000262

B.MIOC:

000302

B.AIOC:

000322
000342
000362

B.IPSN:

000366
000372
000376

TIME

USE D

PROCESSOR

SWITCHES

LOOP

(PER

ENTRIES

INITIATIONS

(PER

B.CKEX:

;CHECKPOINT

B.CFCL:

. BLKW

;CALLS

; IP
; IP

INTERRUPTS
INTERRUPTS

B.CFRK:

« BLKW

; CFORK

B.TLOD:

« BLKW

; TASK

FORKS
LOADS

A-5

DUE

CFORK

RCYD

SENT

(PER
(PER

EXTEND

PROC)

(PER PROC)

;MASS STORE I/O COMPLETIONS (PER
;ALL I/0 COMPLETIONS (PER PROC)

. BLKW
« BLKW
. BLKW

B.IPRC:

PER

PROC)
PROC)
TASKS

PROC)

RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS

ACNDF$ (Cont.)
000402

B.RLOD:

LOADS

.BLKW

; REGION

. BLKB

82.

;BUMP SIZE TO NEXT

32 WORD BLOCK

sEXTRA LENGTH OF SYSTEM STATISTICS BLOCK

(ROUNDED UP TO 32 WORD BOUND)

;SAB LENGTH

$8$=<.+77>/100

000406
000346
000006

~e “e

SYSLOG STARTUP TRANSACTION

o
U

; START AFTER HEADER
; TRANSACTION LENGTH

S$SSHLN
L]

SSLN=,

000022

CRASH RECOVERY TRANSACTION

; START AFTER STANDARD HEADER
; TIME OF LAST SCAN BEFORE CRASH
; SCAN RATE BEFORE CRASH
;ASCII TEXT EXPLAINING CRASH

.=$SS$SHLN
000022
000030

B.CTLS:
B.CSRT:

. BLKW
. BLKW

000032
000126

B.CRSN:

. BLKB

60.

LENGTH

; TRANSACTION

INVALID LOGIN TRANSACTION

B.CLEN=,

+.=SSSHLN

’

000022

B.INAM:

.BLKB

14,

000040
000046
000054

B.IUIC:
B.IPSW:

.BLKB
.BLKB

6.
6.

;NAME FROM LOGIN LINE
;UIC FROM LOGIN LINE
; PASSWORD FROM LOGIN LINE
; TRANSACTION LENGTH

DEVICE TRANSACTIONS

(ALLOCATION,

DEALLOCATION,

MOUNT,

AND

DISMOUNT)

B.ILEN=,

.=SSSHLN

B.MLEN=.

B.DLBL:
B.DMST:
B.DUIC:

: UNUSED BYTE
: VOLUME LABEL

STATUS

BITS

FOR MOUNT

DEA,

AND

DMO

STATUS BITS
UIC
: VOLUME PROTECTION CODE
sNAME OF ACP FOR DEVICE

:MOUNT
;s OWNER

sLENGTH OF MOUNT TRANSACTION

STATUS MASK

(B.DMST)

TME

B.DVPR:

.BLKB
. BLKW
. BLKW
. BLKW
. BLKW
. BLKW

B.DACP:

000054

B.DLEN=,

DEVICE NAME
: OCTAL DEVICE UNIT NUMBER
s TRANSACTION LENGTH FOR ALL,

;ASCII

000050

B.DUNT:

- BLKW
.BLKB

B.DNAM:

000022
000024
000025
000025
000026
000042
000044
000046

;

BM.SHR=1
BM.NOS=2

BM.SYS=4

BM.FOR=10

;DEVICE
;DEVICE

IS MOUNTED SHARED
IS MOUNTED NOSHARE

;DEVICE

IS MOUNTED FOREIGN

sDEVICE IS MOUNTED FOR THE SYSTEM

(PUBLIC)

RSX-11M-PLUS

SYSTEM

DATA STRUCTURES AND SYMBOLIC

DEFINITIONS

ACNDFS$ (Cont.)
H

;

SYSTEM

TIME

CHANGE

.BLKB

B.TNEW: .BLKB
B.TMLN=,

;

000022
000030
000036

TRANSACTION

=$SSHLN

B.TOLD:

;OLD TIME
;NEW TIME

(YR,

MON,

DAY,

HR,

(YR,

MIN,

MON,

SEC)

DAY,

HR,

MIN,

SEC)

; TRANSACTION

LENGTH

’

DESPOOLER

TRANSACTION

.=$SSHLN

;START AFTER

B.PNAM:

.BLKW

000030
000032

B.PPGS:

.BLKW

B.PNFI:

.BLKW

000034 B.PFRM:

.BLKB

000035
000036

B.PPRI:

.BLKB

B.PDEV:

.BLKW

000040

B.PPUN:

.BLKB

000041

B.PLEN=,

HEADER

; PRINT JOB NAME

b
b
()

000022

; PAGE

(RAD50)

COUNT

; NUMBER

; FORM

FILES

PRINTED

NUMBER

; PRINT

PRIORITY

; PRINT

DEVICE

sUNIT

NUMBER

NAME

; TRANSACTION

(ASCII)

DEVICE

LENGTH

CARD READER

SPOOLING

TRANSACTION

-e

;

000030

B.RCDS:

000032
000034

.BLKW

B.RDEV:

.BLKW

B.RUNT:

.BLKB

000035

B.RSOP:

.BLKB

000036

B.RLEN=,

b b

.BLKW

; START AFTER HEADER
;BATCH
OR PRINT JOB
;NUMBER

; READER

DEVICE

;UNIT

CARDS

NUMBER

;SUBMIT

NAME

READ

READER

(ASCII)
DEVICE

(0=SUBMIT,

s TRANSACTION

LENGTH

;START AFTER

HEADER

1=PRINT)

TRANSACTION

B.RNAM:

.=$SSHLN

000022

.=S$$SHLN

000022

B.LUIC:

.BLKW

000024
000042

B.LNAM:

.BLKB

14.

;USER'S

000043

.BLKB

B.LLEN=,

;AND

; LOGIN

UIC

LAST

FIRST

NAME

INITIAL

s TRANSACTION

RESET

TRANSACTION

PARAMETERS

LENGTH

.=$$SHLN

;AFTER

B.OFID:

.BLKW

B.ODNM:
B.OUNT:

,BEKB
,BLKW

B.NFID:

B.NDNM:

.BLKW
.BLKB

B.NUNT:

.BLKW

000046

B.OEXS:

.BLKW

000050

000052

B.NEXS:
B.OSCR:

.BLKW
.BLKW

000054

B.NSCR:

.BLKW

000034
000042
000044

3
2

HHEHEHND
W

000022
000030
000032

HEADER
ULD

:DEVICE
;UNIT

B
TRN,.,

FILE

OLD TRN. FILE
OLD TRN. FILE

;FIL
OF
E-ID
NEW TRN. FILE

_;DEVICE OF NEW TRN.
;UNIT

NEW

TRN.

FILE

;EXT.

SIZE

FOR

OLD

TRN.

FILE

;EXT.

SIZE

FOR

NEW

TRN.

FILE

;OLD

SCAN

RATE

SECONDS

;NEW

SCAN

RATE

SECONDS

RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS

ACNDFS$ (Cont.)
B.ODSC:
B.NDSC:

000062

B.RTLN=,

.BLKW
.BLKW

;OLD STATISTICAL SCAN RATE

1
1

;NEW STATISTICAL SCAN RATE

TRANSACTION TYPES

000 THRU 127

000056
000060

128

RESERVED FOR DEC USE
RESERVED FOR CUSTOMER USE

255

THRU

BT.SAB=1
BT.UAB=2

BT.TAB=3

BT.SS=11
BT.INV=12
BT.TIM=13

BT.ALL=14
BT.DEA=15

BT.MOU=16
BT.DMO=17
BT.PRT=20

BT.DIR=21
- BT.VOL=22

BT.LOG=23
BT.CRH=24
BT.DST=25

BT.RTP=26

:DISMOUNT DEVICE TRANSACTION
; PRINT DESPOOLER TRANSACTION

;DISK ACCOUNTING BY DIRECTORY
;DISK ACCOUNTING BY VOLUME

(UNSUPPORTED)
(UNSUPPORTED)

; LOGIN TRANSACTION

;CRASH RECOVERY TRANSACTION
;DEVICE STATISTICS (UCB EXTENSION)
;RESET TRANSACTION PARAMETERS
;CARD READER SPOOLING TRANSACTION

STATUS MASK BIT DEFINITIONS

(B.STM)

-E

BT.INP=27

; SYSTEM ACCOUNT BLOCK (SAB)
;USER ACCOUNT BLOCK (UAB)
; TASK ACCOUNT BLOCK (TAB)
;SYSLOG STARTUP TRANSACTION
; INVALID LOGIN TRANSACTION
;SYSTEM TIME CHANGE TRANSACTION
;ALLOCATE DEVICE TRANSACTION
; DEALLOCATE DEVICE TRANSACTION
;MOUNT DEVICE TRANSACTION

’

BS.ACT=200

BS.CRH=100
BS.LGO=40
BS.CO=40
BS, TML=20
BS.ZER=10
BS.SCN=4

; CONTROL BLOCK ACTIVE
:RECORD FROM "TMP" FILE AFTER SYSTEM CRASH
; LOGGED OFF WITH OUTSTANDING ACTIVITY (UAB)
; TASK'S TI: IS CO: (TAB ONLY)
; TAB EXISTS ONLY FOR TIME LIMIT (TAB ONLY)
; LAST CPU INTERVAL WAS OF LENGTH ZERO
: TRANSACTION READY FOR WRITE TO SICAN FILE

ACCOUNTING FEATURE MASK

BF.DST=40000
BF .WRT=2000
BF,SCN=1000

BF.SLR=400
BF.ERR=200
BF.STR=100

BF.LSS=40

(SACNFE)

;STATISTICAL SCAN RATE
:FORCE SYSLOG TO WRITE ITS BUFFER

; SCAN REQUESTED

$SYSLOG I3 RUNNING (NOT STOPPED)
;ACCOUNTING STOPPED DUE TO FATAL ERROR

;ACCOUNTING IS STARTING UP / SHUTTING DOWN
;ACCUMULATE SYSTEM
; (POINT

BF.TRN=10
BF.XTK=4
BF.TSK=2
BF.XAC=1

UAB

STATISTICS

SAB)

; OUTPUT TO TRANSACTION FILE

;CHECKPOINT REQUEST IS DUE TO EXTKS

; TASK ACCOUNTING TURNED ON
; EXTENDED ACCOUNTING ASSEMBLED IN

RSX~-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS

ACNDFS$ (Cont.)

(B.SHDN)

SHUTDOWN CODES

’

MAINTENANCE

REBOOT

; 4
HE-

ACCOUNTING SHUTDOWN BY TASK "SHUTUP"
|
OTHER

SCHEDULED SHUTDOWN

;

B.MAXL=128.

;MAXIMUM TRANSACTION LENGTH

;sMINIMUM TRANSACTION LENGTH

B.MINL=$S$SSHLN
. PSECT

ACTDF$
ACTDFS$

.ASECT

000006
000014
000032
000046
000054
000056
000062
000064
000070
000074
000076

A.GRP:
A.MBR:
A.PSWD:
A.LNM:
A.FNM:

.BLKB
.BLKB
.BLKB
.BLKB
,BLKB

A.LDAT: .BLKB

A.NLOG:
A.SYDV:
A.ACN:

.BLKB
.BLKB
.BLKW

.BLKW
«BLKW
A.LPRV: .BLKW
.BLKW
A.SID:
A.LEN=128.

A.CLI:

}w- s wa

000000
000003

; GROUP CODE (ASCII)
;MEMBER CODE
; PASSWORD
; LAST NAME

3
3
6
14.

; FIRST NAME

12.

:DATE OF LAST LOG ON (DD/MM/YY HH:MM:SS

; TOTAL NUMBER OF LOGONS
; DEFAULT SYSTEM DEVICE
; ACCOUNT NUMBER (BINARY)

2
4
1

;RADS0 USER CLI
|
; UNUSED
; LOGIN PRIVILEGE WORD
; SESSION IDENTIFIER
;LENGTH OF CONTROL BLOCK

2
2
1
1

BIT DEFINITIONS ON A.LPRV - LOGIN PRIVILEGE BITS

L.SLV=1
« PSECT

;SLAVE TERMINAL ON LOGIN

'RSX-11M-PLUS SYSTEM DATA STRUCTURES AND
SYMBOLIC DEFINITIONS

CLKDF$

CONTROL

BLOCK

CLOCK

QUEUE

CONTROL

BLOCK

ARE

FIVE

HAS

THE

OFFSET

DEFINITIONS

QUEUE

THERE

W WP

CLOCK

BLOCK
THE

REMAINING

THREE.

WS Wy

g s -y

W W

CLKDFS$

THE

FOLLOWING

CONTROL BLOCK TYPES

TYPES

CLOCK

FORMAT

QUEUE
THE

C.MRKT=0

WORDS

EACH

AND

CONTROL

DIFFERS

DEFINED:

TIME REQUEST
REQUEST WITH PERIODIC RESCHEDULING
; SINGLE SHOT TASK REQUEST
; SINGLE SHOT INTERNAL SYSTEM SUBROU
TINE
; TASK

C.SYST=6

; (IDENT)

C.SYTK=8.

;SINGLE
;CLEAR

STOP
; SHUFFLING)

QUEUE

CONTROL

BLOCK

TYPE

INTERNAL SYSTEM
BIT

SUBROUTINE

(CONDITIONALIZED ON

INDEPENDENT

OFFSET

DEFINTIONS

)

.ASECT
000000
000002

.BLKW

.BLKB

C.EFN:

.BLKB

C.TCB:

,BLKW

C.TIM:

.BLKW

; CLOCK QUEUE THREAD WORD
;REQUEST TYPE
;EVENT FLAG NUMBER (MARK TIME ONLY)
; TCB ADR OR SYSTEM SUBROUTINE IDENTI
FICATION
;ABSOLUTE TIME WHEN REQUEST COMES
DUE

CLOCK

QUEUE

CONTROL

BLOCK-MARK

TIME

000003
000004
000006

C.LNK:

C.RQT:

.=C.TIM+4

; START

000012

C.AST:

000014
000016

C.SRC:

C.DST:

« BLKW

DEPENDENT

OFFSET

DEFINITIONS

AREA

_.BLKW

;AST

.BLKW

; FLAG MASK WORD FOR 'BIS' SOURCE
sADDRESS OF 'BIS' DESTINATION
; UNUSED

ADDRESS

000020

L.BLKW

CLOCK

;

DEFINITIONS

QUEUE

CONTROL

BLOCK-PERIODIC

;

RESCHEDULING

DEPENDENT

OFFSET

.=C.TIM+4

s START

000012

C.RSI:

.BLKW

000016
000020

C.UIC:

.BLKW

C.UAB:

.BLKW

OF DEPENDENT AREA
s RESCHEDULE INTERVAL IN CLOCK
; SCHEDULING UIC

; POINTER

TO ASSOCIATED

TICKS

UAB

CLOCK

QUEUE

CONTROL

BLOCK-SINGLE

SHOT

;

000012

. =C.TIM+4
|

« BLKW

; START

;

TWO

A-10

DEPENDENT

UNUSED

—

SHOT

; (TASK)

C.CSTP=10.

CLOCK

ARE

BLOCKS.

FIVE

;MARK

C.SCHD=2
C.SSHT=4

¢+

CONTROL

FIRST

SAME

WORDS

AREA

OFFSET

DEFINITIONS

RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS

CLKDFS$ (Cont.)
« BLKW
« BLKW

; SCHEDULING UIC
;C.UAB

1
1

DEFINITIONS

THERE ARE TWO TYPE CODES FOR THIS TYPE OF REQUEST:
TYPE 6 = SINGLE SHOT INTERNAL SUBROUTINE WITH A 16 BIT VALUE
AS AN

IDENTIFIER.

TYPE 8 = SINGLE SHOT INTERNAL SUBROUTINE WITH
A TCB ADDRESS
AS

CLOCK QUEUE CONTROL BLOCK-SINGLE SHOT INTERNAL SUBROUTINE OFFSET

000016
000020

IDENTIFIER.

’

000012
000014

000016
000020
000022

.=C.TIM+4

C.SUB:
C.AR5:
C.URM:

; START OF DEPENDENT AREA

.BLKW
.BLKW

1
1

; SUBROUTINE ADDRESS
;RELOCATION BASE (FOR LOADABLE DRIVERS)

. BLKW

; UNUSED
; LENGTH OF CLOCK QUEUE CONTROL BLOCK

.BLKW

C.LGTH=.
« PSECT

; URM TO EXECUTE ROUTINE ON
; (MP

SYSTEMS,

C.SYST ONLY)

RSX-11M-PLUS

SYSTEM

DATA

STRUCTURES

AND

SYMBOLIC

DEFINITIONS

CTBDF$

CONTROLLER

TABLE

(CTB)

THE

Wme

CTBDFS$

CONTROLLER

INDEX TAKEN

TABLE

ADDRESSES.

FROM

THIS

THE

CONTROL

BLOCK

VECTOR MAY

INTERRUPT

THAT CONTAINS

ADDRESSED BY

THE

VECTOR

CONTROLLER

SINTSV/SINTSE.

KRB

+ASECT
177756

L.CLK:

.BLKW

177776

L.ICB:

.BLKW

000000

L.LNK:

.BLKW

000002
000004

L.NAM:
L.DCB:

.BLKW
.BLKW

000006

L.NUM:

L.BLKB
.BLKB

.BLKW

CLOCK

; ICB

;START

CHAIN

FOR

;CTB

LINK WORD

BLOCK

THIS

(IF

ANY)

CTB

;GENERIC CONTROLLER NAME (ASCII)
;DCB ADDRESS OF THIS DEVICE
;NUMBER

OF KRB ADDRESSES
;CTB STATUS BYTE
; START OF KRB ADDRESSES

TABLE

NOTE: THE SYMBOL S$XYCTB:: IS DEFINED FOR EACH CTB; WHERE THE
CHARACTERS

SYMBOL
T HE

KRB

XY ARE
NOT THE

TABLE

THE

SAME AS THOSE STORED IN L.NAM.
THE
START OF THE CTB, BUT INSTEAD THE START

THE

END

THE

CTB

(L.KRB).

WTMe

e We

“s

‘g

L.STS:
L.KRB:

« PSECT

’

CONTROLLER

TABLE

STATUS

BYTE

BIT

DEFINITIONS

’

LS.CLK=1

;CLOCK

LS .MDC=2

;MULTIDRIVER

LS.CBL=4
LS.CIN=10

;CLOCK
;CONT.

LS.NET=20

; THIS

BLOCK

BLK
USE
IS

TOP

CTB

(1l=YES)

(1=YES)

LINKED
COMMON

INTO CLK Q (1=YES)
INT TABLE (1=YES)

DECNET

DEVICE.

ENTRY

POINTS

ENTRY

POINT

ICB'S

; (1=YES)

“ws

000007
000010

R
e )

«=177756

COMMON INTERRUPT

TABLE

DISPATCH

CI.CSR=-6

;CSR

TEST

CI.KRB=-4

; KRB

STATUS

CI.PWF=-2

; POWERFAIL

CI.INT=0
CI.DCB=2

; COMMON INTERRUPT ADDRESS
; START OF DCB TABLE (0 ENDS

A-12

CHANGE

ENTRY

POINT

TABLE)

K.PRM

RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS

DCBDF$
,,SYSDEF

DEVICE CONTROL BLOCK
THE DEVICE CONTROL BLOCK (DCB) DEFINES GENERIC INFORMATION ABOUT A
DEVICE TYPE AND THE LOWEST AND HIGHEST UNIT NUMBERS.
THERE IS AT
LEAST ONE DCB FOR EACH DEVICE TYPE IN A SYSTEM.
FOR EXAMPLE, IF
THERE ARE TELETYPES IN A SYSTEM, THEN THERE IS AT LEAST ONE DCB
WITH THE DEVICE NAME 'TT'.
IF PART OF THE TELETYPES WERE
INTERFACED VIA DL11-A'S AND THE REST VIA A DH1ll, THEN THERE WOULD
BE TWO DCB'S.
ONE FOR ALL DL11-A INTERFACED TELETYPES, AND ONE
FOR ALL DH1l1l INTERFACED TELETYPES.

WhE

TMME

Ny e

s Wy

DCBDF$

+ASECT

D.LNK:
D.UCB:

L.BLKW
.BLKW

; LINK TO NEXT DCB

000002

; POINTER TO FIRST UNIT CONTROL BLOCK

000004

D.NAM:

.BLKW

; GENERIC

000006
000007

D.UNIT:

000010

D.UCBL:

.BLKB
. BLKB

1
1

; LOWEST UNIT NUMBER COVERED BY THIS DCB
; HIGHEST UNIT NUMBER COVERED BY THIS DCB

000012

D.DSP:

.BLKW

; POINTER TO DRIVER DISPATCH TABLE

000014
000016
000020
000022
000024
000026
000030
000032

D.MSK:

.BLKW
. BLKW
- BLKW
. BLKW
- BLKW
« BLKW
- BLKW
. BLKW

1
1
1
1
1
1
1
1

; LEGAL FUNCTION MASK
CODES 0-15.
;CONTROL FUNCTION MASK CODES 0-15.
;NOP'ED FUNCTION MASK CODES 0-15.
;ACP FUNCTION MASK CODES 0-15.
; LEGAL FUNCTION MASK CODES 16.-31.
; CONTROL FUNCTION MASK CODES 16.-31.
;NOP'ED FUNCTION MASK CODES 16.-31.
;ACP FUNCTION MASK CODES 16.-31.

000034

D.PCB:

.BLKW

; LOADABLE

.BLKW

DEVICE NAME

; LENGTH OF EACH UNIT CONTROL BLOCK
IN BYTES

DRIVER

PCB ADDRESS

« PSECT

DRIVER

DISPATCH

TABLE

OFFSET

DEFINITIONS

000000

D.VDEB=-2

; DEALLOCATE

D.VCHK=-4

;ADDRESS OF ROUTINE CALLED TO VALIDATE
;AND CONVERT THE LBN.
USED BY DRIVERS
s THAT SUPPORT SEEK OPTIMIZATION.

BUFFER (S)

D.VNXC=-4

;ADDRESS

ROUTINE

sHAVE IT SEND THE
; TYPEAHEAD BUFFER
D.VINI=0

; DEVICE

D.VCAN=2

; CANCEL CURRENT

D.VOUT=4

; DEVICE

; POWERFAIL

; CONTROLLER

D.VUCB=12

;UNIT

D.VINT=14

I/0O FUNCTION

TIMEOUT

D.VPWF=6

TTDRV CALLED TO

INITIATOR

D.VKRB=10

«.IF

NEXT COMMAND
TO MCR...

RECOVERY

STATUS CHANGE

STATUS

CHANGE

ENTRY

SYSDEF

;BEGINNING OF

- ENDC

A-13

INTERRUPT STUFF

THE

RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS

EPKDF$

ERROR

MESSAGE

DEFINITIONS

BLOCK

EPKDFS

HEADER

SUBPACKET

SUBPACKET LENGTH

SUBPACKET FLAGS
e

OPERATING SYSTEM

FLAGS
o

|
e o s eo

e es s .

e .

}

CONTEXT CODE

e e e s o e e ee .e .

e e

e . e+

ENTRY SEQUENCE

Wy
w5
Wme
g
wS

|
et

e
——— +

-E

OPERATING SYSTEM CODE

IDENTIFICATION

et ittt

ERROR SEQUENCE
ENTRY TYPE

SUBCODE

ENTRY TYPE CODE

L Fmm e +

TIME STAMP

WTMy

PROCESSOR TYPE

PROCESSOR IDENTIFICATION

(URM)

l
+

-y

e it
et
L Pt +

————————— +

RESERVED

et Fm

l
l

WTMy

ee
————
e+

et
et
T Fmmm e+

‘ws

IDENTIFICATION

FORMAT

BYTES

|
e

e
—————— +

i ettt +

‘wy

+ASECT

':O

000002

000004
000005

000006
000012
000013
000014
000016

000020
000020
000021

ESHLGH:
ESHSBF:
ESHSYS:
ESHIDN:
ESHSID:
ESHCTX:
ESHFLG:
ESHENS:
ESHERS:
ESHENC:
ESHTYC:
ESHTYS:

000022
000030
000031

ESHTIM:
ESHPTY:

000032

ESHURM:

.BLKW
.BLKW

1
1

.
;

SUBPACKET
SUBPACKET

.BLKB
.BLKB
.BLKB
.BLKB
.BLKB
.BLKW
.BLKW

1
1
4
1

;
:
:
;

OPERATING SYSTEM CODE
FORMAT IDENTIFICATION
OPERATING SYSTEM IDENTIFICATION
CONTEXT CODE

FLAGS

1
1

:
;
:

ENTRY SEQUENCE NUMBER
ERROR SEQUENCE NUMBER
ENTRY CODE

.BLKB

.BLKB
.BLKB
.BLKB
.BLKB
. BLKW

ESHLEN:

IN BYTES

ENTRY TYPE CODE

;

6
1
1

;
:
;

TIME STAMP
PROCESSOR TYPE
RESERVED

;

PROCESSOR IDENTIFICATION
LENGTH

ENTRY TYPE

. EVEN
000034

LENGTH
FLAGS

-5

000000

SUBCODE

(URM)

R5X-11M-PLUS

SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS

EPKDF$ (Cont.)
’

;

SUBPACKET

;

FLAGS

FOR

ESHSBF

SM.ERR

;

ERROR

SM.HDR

SM.TSK

;

HEADER

;

PACKET

SM.DID

;

SM.DOP

SUBPACKET
SUBPACKET
DEVICE IDENTIFICATION

;

DEVICE

SM.DAC
SM.DAT

20
40

;

SM.MBC

DEVICE ACTIVITY
DATA SUBPACKET

SM.CMD

20000
40000

SM.ZER

;
;

=100000

;

ZERO

;

CURRENT

;

OPERATION

SUBPACKET

SUBPACKET
SUBPACKET

|
22-BIT MASSBUS CONTROLLER
ERROR LOG COMMAND PACKET
I/O

PRESENT

COUNTS

CODES

FOR

FIELD

ESHIDN

TASK

EHSFOR

FOR

ERROR

LOG

FLAGS

PACKET FORMAT

;

FLAGS

THE

BYTE

(SERFLA)

;

ES.INI

;

ERROR

ES.DAT

LOG

INITIALIZED

;

ES.LIM

ERROR

LOG

;

RECEIVING

ERROR

ES.LOG

LIMITING

;

ERROR

LOGGING

THE

DATA
ENABLED

EXEC

PACKETS

TYPE

AND

SUBTYPE

CODES

FOR

FIELDS

ES$HTYC

AND

SYMBOLS WITH NAMES

ESCXXX

SYMBOLS

ARE

TYPE

ENABLED

ES$SXXX

ARE

SUBTYPE

NAMES

ESCCPU
ESSMEM
ESSINT

W
Wy
s
s
WE
WE
WE

FILE
BACKUP

CHANGE

FILES
FILE

LIMITS

ERRORS

HARD

ERROR

STATUS

LOGGING

SOFT

ERROR

DEVICE
DEVICE

INTERRUPT TIMEOUT
UNSOLICITED INTERRUPT

- we

B W N

LOG

DEVICE

ESHTYC,

FIELD

DEVICE

W N -

FIELD
FOR

SHOW
CHANGE

" wWE WmE

FOR

CODES

I
|I
LI

DECLARE

APPEND

DEVICE

CODES

CONTROL

SWITCH

E$SSDMO
ESSRES
E$SRCT

LOG

ERROR

INFORMATION
DEVICE INFORMATION

DEVICE

DISMOUNT

DEVICE

COUNT

BLOCK

CPU

MESSAGE

CONTROL INFORMATION
DEVICE MOUNT

DETECTED

RESET
REPLACEMENT

ERRORS

E$CDCI
E$SMOU

N =W

ESCDVI
ESSDVI

ERROR

MEMORY

ESSTMO
ESSUNS

ESCERR
ESSDVH
E$SSDVS

ESSSHO
ESSCHL

ESSSTA
ESSSWI
ESSAPP
ESSBAC

|I 1

ESCCMD

YU
WA b

WITH

ESHTYS

UNEXPECTED

A-15

ERROR

INTERRUPT

ESHTYS

RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS

EPKDF$ (Cont.)
E$CSYS

6 ; SYSTEM CONTROL INFORMATION

E$CCTL

7 ; CONTROL INFORMATION

E$SCRS
ESSLOA
E$SUNL

=
=
=

2 ;
3 ;
4 ;

ESSMES

6 ;

10 ; SOFTWARE DETECTED EVENTS

ESCSDE
W
e

CODES

N
WE
s
s

1 ; NORMAL ENTRY
2 ; START ENTRY
3 ; CRASH ENTRY

=
=
=

FOR FLAGS ENTRY ES$HFLG

1 ; ADDRESSES ARE VIRTUAL
2 ; ADDRESSES ARE EXTENDED

=
=

EHSVIR
EHSEXT
EH$COU

4 ; ERROR COUNTS SUPPLIED

TASK SUBPACKET

TASK ABORT

FOR CONTEXT CODE ENTRY ESHCTX
EH$NOR
EH$STA
EH$CRS

CODES

RECONFIGURATION STATUS CHANGE

MESSAGE

1 ;

E$SABO

SYSTEM CRASH
DEVICE DRIVER LOAD
DEVICE DRIVER UNLOAD

5 ;

E$SHRC

TIME CHANGE

;

E$STIM

POWER RECOVERY

1 ;

E$SSPWR

e
e ee

;

| TASK SUBPACKET LENGTH

+
e
e e o ee

-s

| TASK UIC

—=—
ee

| TASK TI: DEVICE NAME

ee ———— e ————————— +

| FLAGS

| TASK TI: UNIT NUMBER +|

-E

fmm—————————————————— fom

e ——————————

’

.BLKW
« BLKW

1
2

; TASK SUBPACKET LENGTH
; TASK NAME IN RAD50

.BLKB

; TASK TI: DEVICE NAME

;

000010
000012
000013

ESTLGH:
ESTTSK:
ESTUIC:
ESTTID:
ESTTIU:
ESTFLG:

000014

ESTLEN:

.BLKW

.BLKB
.BLKB

; TASK UIC

;

TASK TI: UNIT

FLAGS

. EVEN

000000
000002
000006

FLAGS FOR ENTRY E$TFLG

ET$SPRV
ETSPRI

1 ; TASK IS PRIVILEGED

2 ; TERMINAL IS PRIVILEGED

A-16

RSX-11M-PLUS

SYSTEM

DATA

STRUCTURES AND

SYMBOLIC

DEFINITIONS

DEVICE

IDENTIFICATION

SUBPACKET

EPKDF$ (Cont.)

;

DEVICE

;

e e

e e
=
+

IDENTIFICATION
e e e e

SUBPACKET

LENGTH

;

trm e
————— +-——— - +

DEVICE MNEMONIC

NAME

;

Fom——— e
—————— te——rrr e,

;

From

PHYSICAL DEVICE MNEMONIC

;

tm———— e,
- te————rr

;

CONTROLLER NUMBER

| PHYSICAL SUBUNIT #
e

DEVICE

l
l
|
l
l

;

RESERVED

VOLUME NAME

(RSX~11M~PLUS ONLY)
e

FLAGS

S+

MOUNTED VOLUME

IDENTIFICATIDN

|
+

|
T

|
l
l
|
1

PACK

]

————— +

trm—— e
—— +

NUMBER

| PHYSICAL UNIT #

it e . e

;

;
;
;
;
;

UNIT

——————————————— +

;

e
e, —————————_——— +

]

;

e
e -+

DEVICE

;

|
o

e e

o
o o o e i i
+

TYPE

]

;

DEVICE TYPE CLASS

I/0

HARD

OPERATION

COUNT

LONGWORD

e e —————————————— +

ERROR COUNT
e

|
e e

SOFT

Fmmm

ERROR

COUNT

——————— +

;

Fr———— e
——————— +

;

BLOCKS

TRANSFERRED COUNT

CYLINDERS

CROSSED CDUNT

(RSX-11M-PLUS

(RSX 11M~PLUS

ONLY)

;

000000

ESILGH:
ESILDV:

.BLKW
.BLKW

000002

;
;

DEVICE IDENTIFICATION
DEVICE MNEMONIC NAME

000004
000005
000006

.BLKB
,.BLKB
.BLKB
.BLKB

1
1

;
;

DEVICE UNIT NUMBER
CONTROLLER NUMBER

N00007

ESILUN:
ESIPCO:
ESIPUN:
ESIPSU:

1
1

;
;

PHYSICAL
PHYSICAL

UNIT NUMBER
SUBUNIT NUMBER

000010
000012

ESIPDV:
ESIFLG:

.BLKW
.BLKB

1
1

;s
+

PHYSICAL
FLAGS

DEVICE MNEMONIC

000013
000014
000030

ESIVOL:
ESIPAK:

,BLKB
.BLKB
.BLKB

1
12,
4

;
;
;

RESERVED
VOLUME NAME
PACK IDENTIFICATION

——————————

000034

ESIDEV:

;

DEVICE TYPE

000034
000036

ESIDCL:
ESIDTY:

.BLKW
.BLKW

1
2

;

DEVICE

TYPE CLASS

;

DEVICE

TYPE

000042
000046
000047

ESIOPR:
ESIERS:
ESIERH:

.BLKW
.BLKB
.BLKB

2
1
1

;
;
;

I/0 OPERATION COUNT
SOFT ERROR COUNT
HARD ERROR COUNT

A-17

SUBPACKET

LONGWORD

LENGTH

RSX-11M-PLUS

SYSTEM DATA

STRUCTURES

AND SYMBOLIC

DEFINITIONS

EPKDFS$ (Cont.)

000054

ESIBLK:
ESICYL:

000060

ESILEN:

. BLKW

;

BLOCKS

.BLKW
. EVEN

CYLINDERS

TRANSFERRED COUNT
CROSSED COUNT

;

SUBPACKET

LENGTH

FLAGS

FOR

FIELD ESIFLG

000050

=
=

;

SUBCONTROLLER DEVICE
UCB EXTENSION, DATA

INVALID

DEVICE

OPERATION

SUBPACKET

EISSUB
EISNUX

TMy

Fe
——————— +

DEVICE OPERATION SUBPACKET LENGTH

TASK NAME

IN RADS50

TASK UIC

RESERVED

LOGICAL DEVICE MNEMONIC

| TASK TI:

$—————————————————————— ettt
P+
bt
T Le
e+

TMy

et&

WMy

TASK TI:

DEVICE UNIT

I/0 FUNCTION CODE

s
s

WMy

et e
o

RESERVED

OPERATION FLAGS

-e+

TRANSFER OPERATION ADDRESS

WNe

ettt +

TRANSFER OPERATION BYTE COUNT
CURRENT OPERATION

RETRY COUNT

Fmmm - +

'zo
000000

000002
000006
000010
000012
000013

000014

000016

ESOLGN:
ESOTSK:
ESOUIC:
ESOTID:
ESOTIU:
ESOFNC:
ESOFLG:

000017

000026

ESOADD:
ESOSIZ:
ESORTY:

000030

ESOLEN:

000020
000024

.BLKW
.BLKW
. BLKW

1
2
1

: SUBPACKET
; TASK NAME
: TASK UIC

LENGTH
IN RADS5O0

.BLKB
.BLKB
. BLKB
. BLKW
.BLKB

2
1
1

:
s+
:

TASK TI: LOGICAL DEVICE MNEMONIC
TASK TI: LOGICAL DEVICE UNIT
RESERVED

1
1

;
s

I/0 FUNCTION CODE
OPERATION FLAGS

.BLKB

RESERVED

.BLKW
.BLKW
.BLKW

2
1
1

;
s
;

TRANSFER OPERATION ADDRESS
TRANSFER OPERATION BYTE COUNT
CURRENT OPERATION RETRY COUNT

;

DEVICE

;
;

TRANSFER OPERATION
DMA DEVICE

. EVEN

SUBPACKET

FLAGS

FOR FIELD ESOFLG

‘aug

OPERATION

EOSTRA
EOSDMA

=
=

1
2

A-18

LENGTH

RSX-11M-PLUS SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS

EPKDF$ (Cont.)
=

EOSPIP

4
10

;
;

EXTENDED ADDRESSING DEVICE
DEVICE IS POSITIONING

I/0 ACTIVITY SUBPACKET

000000

l
I
|
|
|
(
i
i
|
|
{
|
|
i
|
|
|
|
|
|
|
|
|
+

WME

l
l

|
i

|
|
|
|
|
|
|
l
i
i
|
|
|
{
|
|
|
|
|

EOSEXT

ESALGH:

.BLKW

;

SUBPACKET

LENGTH

’

;

I1/0 ACTIVITY SUBPACKET

ENTRY

;
;

tm e,
e
— . ———— +

;

termr - Fom— - +

LOGICAL DEVICE NAME MNEMONIC

CONTROLLER NUMBER

;

e
e
——— o
———— +

trmmmer v
——— torr e
—————— +

|
P

;

LOGICAL DEVICE UNIT

;

PHYSICAL SUBUNIT

PHYSICAL UNIT NUMBER

PHYSICAL DEVICE MNEMONIC
e

TASK TI:

;

LOGICAL UNIT
D

REQUESTING

(RSX-11M-PLUS

———— Fomm

e e

TASK NAME

DEVICE

ONLY)

e e e e e

FLAGS

RADSO

I
e e e e

REQUESTING

e e

TASK

e e e

I/0 FUNCTION CODE

o s o si

RESERVED

o e

LOGICAL DEVICE NAME

s e e

|
e

e e e e

|
o e

e et
o e e +

FLAGS

———————— e,
e
——— +

;

TASK TI:

— — — — —— — — — —————_———

UIC

TMy
W
WME

UNIT

WUE

PHYSICAL

SUBUNIT

NUMBER

PHYSICAL

DEVICE

MNEMONIC

.BLKW
.BLKB

PHYSICAL

DEVICE

WME

ESAFNC:
ESAFLG:

MNEMONIC

CONTROLLER

TASK

000022
000024

UNIT

REQUESTING

.BLKW
.BLKW
.BLKW

NAME

DEVICE

REQUESTING

ESATSK:
ESAUIC:
ESATID:

DEVICE

LOGICAL

TASK

000012
000016
000020

LOGICAL

I/0

.BLKB

ESATIU:

e bt bt

000011

et N

.BLKW
.BLKB
.BLKB
.BLKB
.BLKB
.BLKW
.BLKB

bt bt b

ESALDV:
ESALUN:
ESAPCO:
ESAPUN:
ESAPSU:
ESAPDV:
ESADFG:

et et et et

000000
000002
000003
000004
000005
000006
000010

FLAGS

NUMBER

FLAGS

TI:

LOGICAL

UNIT

TASK

NAME

TASK

UIC

LOGICAL

FUNCTION CODE

DEVICE

RADSO0
NAME

RSX-11M-PLUS

SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS

ESALEN:

RESERVED

TRANSFER
TRANSFER

SUBPACKET ENTRY LENGTH

000034

.BLKW
.BLKW

OPERATION ADDRESS
OPERATION BYTE COUNT

« EVEN

FLAGS FOR FIELD ESADFG

EASNUX

SUBCONTROLLER
NO

UCB

DEVICE

EXTENSION,

DATA

INVALID

FLAGS

FOR FIELD ESAFLG

]

EASSUB

-y

‘s

ESAADD:
ESASIZ:

bt]

« BLKB

000026
000032

b 1 ]

000025

EPKDFS$ (Cont.)

EASTRA
EASDMA
EASEXT
EASPIP

=
=
=
=

;

2
4
10

;
;
;

TRANSFER OPERATION
DMA DEVICE
DEVICE HAS EXTENDED ADDRESSING
DEVICE IS POSITIONING

« PSECT

A-20

RSX-11M-PLUS

SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS

F11DF$
F11DF$
VOLUME

CONTROL

BLOCK

+ + SYSDEF

.ASECT
.=0

000000

V.TRCT:

.BLKW

;

TRANSACTION

COUNT

000002

V.TYPE:

.BLKB

;

VOLUME TYPE

DESCRIPTOR

VT.SL1=

;

FILES-11

VT.ANS=

;

ANSI

VT.UNL=
V.VCHA:

11
.BLKB

;
;

UNLABELED TAPE
VOLUME CHARACTERISTICS

VC.SLK=
VC.HLK=
VC.DEA=

;

CLEAR VOLUME VALID

2
4

;
;

VC.PUB=
V.LABL:
V.PKSR:

000004
000020
000024

V.SLEN:

000024
000026
000032

V.IFWI:
V.FCB:
V.IBLB:

.BLKW
.BLKW
.BLKB

000033

000003

;

.BLKB
.BLKW

LEVEL

LABELED TAPE

ON DISMOUNT
UNLOAD THE VOLUME ON DISMOUNT
DEALLOCATE THE VOLUME ON DISMOUNT

;
;

SET (CLEAR) US.PUB ON DISMOUNT
VOLUME LABEL (ASCII)
PACK SERIAL NUMBER FOR ERROR LOGGING

;

LENGTH

1
2
1

;
;
;

INDEX FILE WINDOW
FILE CONTROL BLOCK LIST HEAD
INDEX BIT MAP 1ST LBN HIGH BYTE

;

INDEX BIT

14
2

V.IBSZ:

.BLKB

000034
000036

V.FMAX:

.BLKW
.BLKW

1
1
1

000040

V.WISZ:

.BLKB

000041

V.SBCL:

.BLKB

000042

V.SBSZ:

.BLKW

000044
000045

V.SBLB:
V.FIEX:

.BLKB
.BLKB

000046

STRUCTURE

;
;

SHORT VCB

MAP SIZE IN BLOCKS
INDEX BITMAP 1ST LBN LOW BITS
MAX NO. OF FILES ON VOLUME

DEFAULT SIZE OF WINDOW
VALUE IS < 128.

;
;
;

STORAGE

BIT MAP CLUSTER

;

STORAGE

BIT MAP

1
1

;
;

STORAGE
DEFAULT

1ST

LBN

RTRV PTRS

FACTOR

BLOCKS
BIT MAP 1ST LBN HIGH BYTE
FILE EXTEND SIZE

« BLKW

;

STORAGE

000050

V.VOWN:

.BLKW

;

VOLUME

OWNER'S

000052

V.VPRO:

.BLKW

;

VOLUME

PROTECTION

000054
000056
000057

V.FPRO:
V.FRBK:
V.LRUC:

.BLKW
.BLKB
.BLKB

1
1
1

;
;
;

VOLUME DEFAULT FILE PROTECTION
NUMBER OF FREE BLOCKS ON VOLUME
COUNT OF AVAILABLE LRU SLOTS IN

- BLKW

;
;

NUMBER

.BLKB

000060

000062

V.STS:

VOL

BIT MAP

SIZE

;

INDEX

VS.BMW=

;

STORAGE

000063
000064

V.FFNU:
V.EXT:

.BLKB
.BLKW

;
;

FIRST FREE
POINTER TO

000066

V.LGTH:

;

SIZE

;

MOUNT

;

EACH

;

TO ALLOW

;

DEVICE

LIST

FILE

HIGH BYTE
FCB LIST
LOW BITS
FOLLOWING

ACCESSED

WRITE

ACCESSED

BLOCK

VCB

ENTRY

ENTRY ALLOWS

ACCESS

EXPANSION,

ACCESS

.BLKW

WRITE

INDEX FILE BITMAP
VCB EXTENSION

BYTES

ONLY

TO
THE

SPECIFIED
ONLY

BLOCKS

.ASECT
M.LNK:

BITMAP

000000

BITS

OF FREE BLOCKS ON VOLUME
STATUS BYTE, CONTAINING THE

VS.IFW= -1

1
1

LOW

UIC

;

LINK WORD

A-21

TYPE

USER
CODE

FOR

DEFINED

NON-PUB
IS

"1"

DEVICE
FOR

RSX-11M-PLUS

SYSTEM DATA STRUCTURES AND SYMBOLIC DEFINITIONS

000010

M.LEN:

FCB
FILE

-y

LENGTH

TI:

LIST

UCB

ENTRY

CONTROL BLOCK

FILE

ACCESSOR

M.TI:

ENTRY

000006

-y

M.ACC:
M.DEV:

‘up

000003
000004

TYPE

MOUNTED VOLUME USER ACCESS
NUMBER OF ACCESSES
DEVICE UCB

1
« BLKB
« BLKW
« BLKW

« BLKB

MT.MLS=

M.TYPE:

000002

“wg

F11DF$ (Cont.)

+ASECT
.=0

000026

F.SIZE:

000032

F.NACS:

« BLKW
.BLKB

000033

F.NLCK:

. BLKB

000012

S.STBK=, -F.LBN

000034
000034
000035

F.NWAC:

N
_E

SYSTEM

FILE

F.DRNM:

F.FEXT:
F.FVBN:
F.LKL:

. BLKW
. BLKW
. BLKW

000052

F.WIN:

.BLKW

000054

F.LGTH:

CONTROLLED

HEADER

CHARACTERISTICS

LOGICAL

BLOCK

LBN OF VIRTUAL BLOCK
0 IF NON CONTIGUOUS
NO.
NO.

SIZE

NUMBER

STATUS

BITS

FOR

SET

FILE

ACCESSED

SET

IF
IF

FCB IS IN
DIRECTORY

SIZE

FCB

SET

STATISTICS

FILE

ACCESSES

LOCKS

BLOCK
IF CONTIGUOUS

BLOCKS

STATISTICS

STATUS

NUMBER

BLOCK

WORD
WRITE

ACCESSORS

FCB

CONSISTING
FOR

WRITE

DIRECTORY
EOF NEEDS

LRU
UPDATING

SET IF TRYING TO FORCE DIRECTORY CONTIG

POINTER

WINDOW

BLOCK

SIZE