Trailing-Edge
-
PDP-10 Archives
-
SRI_NIC_PERM_SRC_3_19910112
-
stanford/5-swskit/klcom.mem
There are 6 other files named klcom.mem in the archive. Click here to see a list.
PDM : 200-205-034-00
File: <DOC-FRONT-END> KLCOM.MEM
KL10/PDP-11 DTE20 Protocol
Author: E. Socci
Date:30-Jan-76
Copyright (C) 1975
Digital Equipment Corporation, Maynard, Mass.
This software is furnished under a license for use only on a single
computer system and may be copied only with the inclusion of the above
copyright notice. This software, or any other copies thereof, may not
be provided or otherwise made available to any other person except for
use on such system and to one who agrees to these license terms.
Title to and ownership of the software shall at all times remain in
DEC.
The information in this document is subject to change without notice
and should not be construed as a commitment by Digital Equipment
Corporation.
DEC assumes no responsibility for the use or reliability of its
software on equipment which is not supplied by DEC.
Page 2
1.0 INTRODUCTION
1.1 Version
This document reflects the KL10/PDP-11 DTE20 protocol as of version 1,
and the communications region as of version 2.
1.2 General Description
The KL10/PDP-11 DTE20 protocol is a tightly coupled communications
protocol designed for use between the processors in a KL10 based
system and their PDP-11 front end computers. These PDP-11s include
one "master" 11 per KL10 processor (required for KL10 operation) and
up to three "non-privileged" 11s (optional). The protocol was
designed around the DTE20 byte transfer hardware, DTE20
examines/deposits, and DTE20 doorbell. This protocol was designed for
use between KL10s and all 11s connected to it through DTE20s,
regardless of the application of those 11s. For this reason, the
protocol is very general and has most the features necessary for 10/11
communications. It is easily extended to obtain any additional
features that will be required.
There are two "sub-protocols" within this protocol. One of these
sub-protocols is called the secondary protocol, which is used to
operate the CTY during bootstrap or emergency situations. It uses
only the examine/deposit feature of the DTE20. The locations it uses
for -10/-11 communication are located in the EPT of each processor in
the system. Only the privileged -11, that is, the -11 connected to a
non-restricted DTE, runs the secondary protocol, since the secondary
protocol requires privileged examines of the -10s EPT. The "primary
protocol" is the main protocol used for -10/-11 communications, and
used both the examine/deposit and byte transfer features of the DTE20.
Page 3
2.0 COMMUNICATIONS REGION
2.1 Format
!=========================================================================!
\ \ ;START OF COMMUNCATIONS HEADER
\ HEADERS FOR OTHER PROCESSORS \
\ \
!-------------------------------------------------------------------------!
! HEADER WORD FOR PROCESSOR 2 !
!-------------------------------------------------------------------------!
! HEADER WORD FOR PROCESSOR 1 !
!-------------------------------------------------------------------------!
! MBZ ! PROC. NUMBER ! ! RELATIVE ADDRESS OF THIS PROCESSORS AREA ! ;END OF COMMUNICATIONS HEADER
!=========================================================================!
PIDENT !X! VR ! !PROTO. VER.! # PROC. !SIZE ! NAME ! ;START OF COMM REGION, FIRST COMM AREA, OWNING SECTION
!-------------------------------------------------------------------------!
CHNPNT ! POINTER TO NEXT COMM AREA !
!-------------------------------------------------------------------------!
! !
!-------------------------------------------------------------------------!
! !
!-------------------------------------------------------------------------!
! !
!-------------------------------------------------------------------------!
KPALIV ! ! KEEP ALIVE COUNT !
!-------------------------------------------------------------------------!
\ \
\ UNUSED \
\ \
\ \ ;END OF OWNER'S SECTION OF AREA
!=========================================================================!
FORPRO !X!D!DT#! UNASSIGNED !BSIZE! "TO" PROCESSOR NUMBER ! ;START OF FIRST "TO" SECTION OF AREA
!-------------------------------------------------------------------------!
PROPNT ! POINTER TO "TO" PROCESSOR'S OWNED COMM AREA !
!-------------------------------------------------------------------------!
STATUS ! !L! !V! UNUSED !Q! !F!@!2! TO10IC ! TO11IC !
!-------------------------------------------------------------------------!
QSIZE ! UNUSED ! QUEUE SIZE !
!-------------------------------------------------------------------------!
RELOAD !0! RELOAD PARAMETER FOR "TO" PROCESSOR !
!-------------------------------------------------------------------------!
CPKPLV !0! OWNING PROCESSOR'S COPY OF "TO" PROCESSORS KEEP ALIVE COUNT ! ;END OF FIRST "TO" SECTION OF AREA
!=========================================================================!
\ \
\ OTHER SECTIONS FOR "TO" PROCESSORS \
\ \ ;END OF FIRST AREA
!=========================================================================!
\ \
\ OTHER COMMUNICATIONS AREAS \
\ \
!=========================================================================!
Page 4
2.2 Description Of Communications Region
All processors have read access to the entire communications "region".
There is a negative extension to the communications region called the
header, which exists so that the -11 processors represented in the
communications region can determine what their protocol processor
number is. The communications region is composed of sequential
"areas", each processor (both -10s and -11s) owning one and only one
area, which is the only part of the communications region the
processor is allowed to write into. During comm region
initialization, however, a -10 processor is responsible for setup of
the entire region, which means that this -10 processor must have write
access to the entire comm region. After this operation, the rules for
accessing the region apply. Each area has a single "section" for the
processor owning the area, and a section for each processor that the
processor owning the area will communicate to. Thus, each pair of
processors that communicates with each other using the queued protocol
utilizes four sections of the comm region; the processors' own
sections of their respective areas (this is where the keep alive count
is kept), and each processor's section in its area designated for
communcation to the other processor.
2.3 HEADER Definitions
The header is considered to be a negative extention to the
communications region. It exists to provide a means for the -11
processors to determine what protocol processor number they have been
assigned. The -11 can simply examine the first word of its relocated
examine space to determine what its protocol processor number is and
where in the communications region its own area is located. The -11
also knows that the first word of the communications region itself is
at location N+1 in its relocated examine space, where N is the -11s
protocol processor number. From there, it can scan the areas in the
communcations region to find any areas owned by processors with which
the -11 will communicate. Communications region word 0 starts
immediately after the last header word.
2.3.1 MBZ - Must be zero
2.3.2 PROC. NUMBER - Processor number
2.3.3 RELATIVE ADDRESS - Offset, relative to communications region
word 0, of the area owned by the processor to which this header word
belongs.
Page 5
2.4 PIDENT Definitions
2.4.1 X - One if this area belongs to a 10
2.4.2 VR - Communications area version number. The handling of this
value is unresolved.
2.4.3 PROTO. VER. - Protocol version number. The handling of this
value is unresolved.
2.4.4 # PROC. - Number of processors represented in this area
including the owning processor
2.4.5 SIZE - Size of the entire owning processor's area in 8 word
blocks. Note that this defintion of this field makes it difficult for
the -11 to scan the communications areas looking for specific "to"
sections, since the -11 does not know how big the owner's section of
an area is. A better definition would be the size of the owner's
section in 8 word blocks. The -11 does not need to know how big the
entire area is, since 1)each area is linked to the next area by the
CHNPNT word; 2)the -11 can find out how many "to" sections there are
in an area from the # PROC. field in the PIDENT word. Since the size
of each "to" section in 8 word blocks is included in each "to" section
in the area, there is enough information to determine where the area
ends.
2.4.6 NAME - Name of processor owning this area (serial number)
2.5 CHNPNT Definitions
2.5.1 CHNPNT - Pointer (relative to word 0 of entire comm region) to
next communications area, circular list
2.6 KPALIV Definitions
Page 6
2.6.1 KPALIV - Keep alive count owning processor increments. The
processor responsible for monitoring this count examines the count
periodically to make sure it has changed. A word in the owner's
section of each area is reserved to remember the last value of the
keep alive, although it is not required that this word be used. It
would be impractical for an -11 to remember the last count in the
-10's memory, since it would have to do examines and deposits through
the DTE20 to access the cell. The keep alive count should be
incremented at least once a second by the processor owning the area,
and the monitoring processor should allow the keep alive count to
remain the same for at least 6 seconds before declaring the monitored
processor dead.
2.7 FORPRO Definitions
FORPRO is the first location in each "to" processor section.
2.7.1 X - Set to 1 if this block will be used to communitcate to a 10
2.7.2 D - Set to one if there is a DTE connection between this and
owning processor
2.7.3 DT - DTE number if D bit is set
2.7.4 BSIZE - Size of this block in multiples of 8
2.7.5 "TO" PROC. NUM. - Number of the processor which owning
processor will communicate through this block
2.8 PROPNT Definitions
2.8.1 PROPNT - Pointer to "to" processors own comm area
2.9 STATUS Definitions
The status word is set up so that it is the only word a processor has
to examine when it receives a doorbell interrupt. This is especially
useful to the 11, for whom an examine of 10 memory is painful.
Page 7
2.9.1 L - If a processor wishes to be reloaded by a second processor,
the first processor sets the L bit in the first processor's section of
the second processor's comm area and rings the second processor's
doorbell. The second processor then examines the STATUS word, sees
the L bit set, and performs a reload operation for the first
processor. The L bit gets set by a processor whenever it knows that
it has crashed (i.e. inside its crash reporting routine). See the
section on bootstrap procedures for the details of this reload
operation.
2.9.2 V - Valid examine bit - If the examine protection word of a DTE
is zero and the -11 connected to the other end of the DTE is either
privileged or non-privileged with the PI0 enable bit on, any examine
done by the connected -11 will appear to succeed, returning a data
value of zero. The valid examine bit is a bit that is always
guaranteed to be non-zero so that the -11 can be sure that its
examines are succeeding. If 11 finds this to be zero after an examine
or deposit, it will leave primary protocol.
2.9.3 Q - Queued protocol in use. Set up by the 10 in all
communications areas on initialization.
2.9.4 F - This flag is set by the sending processor to indicate that
the transfer is to be done in word (16 bit) mode.
2.9.5 @ - Set to 1 in receiver's section of sender's comm area if
indirect packet is being sent. The sender should not set this bit and
increment the queue count. This bit tells the receiver that the
doorbell is for the start of the indirect portion of an indirect
message transfer.
2.9.6 2 (TOIT) - Set to 1 by the receiver in sender's section of
receiver's comm area after sender sets the @ bit or increments the
queue count, and the receiver processes the doorbell. Cleared by
receiver after receipt of to-receiver done. This bit exists so that
the sender can make sure the receiver has not lost a done interrupt.
2.9.7 TO10IC - A wrap around counter which is incremented in 11's
comm area every time a direct transfer request is initiated by the 11.
The 10 keeps the last known value of TO10IC in the to-11 section of
its own comm area, and if this value differs from the current copy in
the 11's area, the 10 will start a to-10 packet transfer. The
difference between the 10's copy and the copy the 11 increments should
Page 8
be either zero or one. If this difference is greater than one, the 11
has tried to send a packet before the previous packet was finished.
This count is not incremented for to-10 indirect packets. The @ bit
is used to indicate doorbells for indirect packets.
This counter is also useful in case a doorbell interrupt is missed by
the 10 (or 11 if TO11IC). If a doorbell is missed, the counters will
be noticed at the next doorbell.
2.9.8 TO11IC - Same as TO10IC, but with 10 and 11 reversed
2.10 QSIZE Definitions
2.10.1 QSIZE - Number of 8 bit bytes written into current packet by
the transmitting processor to the receiving ("to") processor. Note
that there may be more than one message in a given packet.
2.11 RELOAD Definitions
2.11.1 RELOAD - Copy of "to" processor's reload word, saved by owning
processor in case "to" processor crashes. Currently this word is sent
to 11 inside 11 bootstrap code to select device.
2.12 CPKPLV Definitions
2.12.1 CPKPLV - Owning processor's copy of "to" processor's keep
alive count
Page 9
3.0 MESSAGE HEADERS
3.1 From-11 Message Header
3.1.1 Format -
!=========================================================================!
! LOW COUNT ! HIGH COUNT ! LOW FUNCTION !@!HIGH FUNCTION! !
!-------------------------------------------------------------------------!
! LOW DEVICE ! HIGH DEVICE ! LOW SPARE ! HIGH SPARE ! !
!-------------------------------------------------------------------------!
!LOW FIRST WORD !HIGH FIRST WORD! LOW DATA ! HIGH DATA ! !
!=========================================================================!
COUNT is setup by the 11 to be the length of the entire message.
The bit designated by the character "@" is the indirect bit. It is
set if this message will be followed by an indirect message containing
data for the function. If an indirect message is sent, by definition
it must terminate the current packet.
FUNCTION is the function number of the message.
DEVICE is the number of the device that this message is being sent
for.
FIRST WORD varies according to the function code, as does data.
SPARE is currently unused.
3.1.2 Modes - The to-10 message header is always sent in byte mode.
3.2 To-11 Message Header
3.2.1 Format -
!=========================================================================!
! HIGH COUNT ! LOW COUNT !@!HIGH FUNCTION ! LOW FUNCTION ! !
!-------------------------------------------------------------------------!
! HIGH DEVICE ! LOW DEVICE ! HIGH SPARE ! LOW SPARE ! !
!-------------------------------------------------------------------------!
!HIGH FIRST WORD!LOW FIRST WORD ! HIGH DATA ! LOW DATA ! !
!=========================================================================!
See the description of the from-11 message header for explanation of
the fields.
Page 10
3.2.2 Modes - The to-11 message header is always sent in byte mode.
Page 11
4.0 PROTOCOL MESSAGES
The basic unit of information transferred between the 10 and 11 is the
packet. Each packet can contain one or more messages. Which function
a given message will effect is selected by the function code specified
in the message header. If an indirect message is sent in a packet
with other messages, the indirect message must be the last message in
the packet. No more than one indirect message can be in a given
packet.
The following is a list of all currently implemented message
functions.
4.1 To-11 Initial Message (#1)
4.1.1 Format -
!=========================================================================!
!5! ! NUMBER OF ! ! ! !
!0! ! TTY LINES ! ! ! !
!=========================================================================!
4.1.2 Modes - Byte direct mode only
4.1.3 Effect Of Function - Tells the 11 what the power line frequency
for this processor is and how many TTY lines the 10 expects the 11 to
have. Currently, the number of TTY lines in the message is ignored by
the 11. In future versions of the protocol, this message may contain
other introduction information.
This should be the first message sent by the 10 after entering primary
protocol for the first time.
4.1.4 Involvement With Other Functions - As a result of the 10
sending this message, the 11 sends the 10 its introductory message
(to-10 function #2) and the reload information message (to-10 function
#24).
Page 12
4.1.5 Valid Devices - The device field is ignored.
4.1.6 Other Notes -
Page 13
4.2 From-11 Cty Dls Alias (#2)
4.2.1 Format -
!=========================================================================!
!DLS LINE NUMBER! ! ! ! !
! OF CTY ! ! ! ! !
!=========================================================================!
4.2.2 Modes - Byte direct mode only.
4.2.3 Effect Of Function - The CTY is accessible to the 10 in two
ways; through the CTY device code, and through the DLS device. This
function informs the 10 to which DLS line the CTY is "connected".
4.2.4 Involvement With Other Functions - The 11 sends this message
after the 10 sends its initial message (#1).
4.2.5 Valid Devices - The device field should be ignored by the 10.
4.2.6 Other Notes -
Page 14
4.3 To-11 String Data (#3)
4.3.1 Format -
!=========================================================================!
! LINE ! BYTE ! ! ! !
! NUMBER ! COUNT ! ! ! !
!=========================================================================!
!=========================================================================!
\ \
\ TO-11 STRING DATA (EITHER 8 OR 16 BIT MODE TO 11) \
\ \
!=========================================================================!
BYTE COUNT COUNT OF 8 BIT BYTES IN FOLLOWING INDIRECT PACKET
4.3.2 Modes - Can be either byte or word mode, depending on the
nature of the data. If the data is send in byte mode, it can also
come direct; if the data must be sent in word mode, the data must be
sent indirect because the header is always sent in byte mode.
4.3.3 Effect Of Function - This is the general data transferring
mechanism of the protocol.
4.3.4 Involvement With Other Functions - After a processor (10 or 11)
receives the data and is again ready to receive the full line
allocation for the specified device, a device acknowledge (function
code 17) must be sent. a processor (10 or 11) must not send more than
the current allocation for the device (see line allocation message and
device dependent section.)
4.3.5 Valid Devices - TTYs, LPT, FE device.
Page 15
4.3.6 Other Notes -
Page 16
4.4 From-11 String Data (#3)
4.4.1 Format -
!=========================================================================!
! BYTE ! LINE ! ! ! !
! COUNT ! NUMBER ! ! ! !
!=========================================================================!
!=========================================================================!
\ \
\ FROM-11 STRING DATA (EITHER 8 OR 16 BIT MODE FROM 11) \
\ \
!=========================================================================!
4.4.2 Modes - See to-11 string data, above.
4.4.3 Effect Of Function - See to-11 string data, above.
4.4.4 Involvement With Other Functions - See to-11 string data,
above.
4.4.5 Valid Devices - TTYs, CDR, FE device.
4.4.6 Other Notes -
Page 17
4.5 To-11 Character Data (#4)
4.5.1 Format -
!=========================================================================!
! LINE ! DATA ! LINE ! DATA !. . . !
! NUMBER ! ! NUMBER ! !. . . !
!=========================================================================!
Note that this message can have an arbitrary number of line
number-data pairs.
4.5.2 Modes - Always byte direct.
4.5.3 Effect Of Function - This is a special data transfer message,
which allows the protocol to handle multiple line data transfers
within a specific device. This allows the device service routine to
make better use of the DTE by cutting down the relative overhead of
the transfer, since more data can be sent.
4.5.4 Involvement With Other Functions - Acknowledge, line
allocation.
4.5.5 Valid Devices - This message is only used for teletype devices
(CTY, DLS, etc.).
4.5.6 Other Notes -
Page 18
4.6 From-11 Character Data (#4)
4.6.1 Format -
!=========================================================================!
! DATA ! LINE ! DATA ! LINE !. . . !
! ! NUMBER ! ! NUMBER !. . . !
!=========================================================================!
Note that this message can have an arbitrary number of line
number-data pairs.
4.6.2 Modes - Always byte direct.
4.6.3 Effect Of Function - See to-11 character data above.
4.6.4 Involvement With Other Functions - See to-11 character data
above.
4.6.5 Valid Devices - See to-11 character data above.
4.6.6 Other Notes -
Page 19
4.7 To-11 Request Device Status (#5)
4.7.1 Format -
!=========================================================================!
! UNIT ! !
! NUMBER ! !
!=========================================================================!
This message consists of a header only.
4.7.2 Modes - Always byte direct.
4.7.3 Effect Of Function - Requests the 11 to send the status of a
device.
4.7.4 Involvement With Other Functions - Normally causes a device
status message to be sent in return.
4.7.5 Valid Devices - FE, LPT, CDR.
4.7.6 Other Notes -
Page 20
4.8 From-11 Request Device Status (#5)
4.8.1 Format -
!=========================================================================!
! ! UNIT ! !
! ! NUMBER ! !
!=========================================================================!
This message consists of a header only.
4.8.2 Modes - Always byte direct
4.8.3 Effect Of Function - Causes the 10 to send a device status
message (function number 7).
4.8.4 Involvement With Other Functions - Device status message,
function 7.
4.8.5 Valid Devices - LPT, FE, CDR.
4.8.6 Other Notes -
Page 21
4.9 To-11 Device Status (#7)
4.9.1 Format -
!=========================================================================!
! UNIT ! BYTE ! ! ! !
! NUMBER ! COUNT ! ! ! !
!=========================================================================!
!=========================================================================!
! !F!L!E!I!S!H!O!N! ! ! !
! !E!G!F!P!E!E!F!X! ! ! !
!=========================================================================!
FE FATAL ERROR
LG ERROR LOG REQUEST
EF END OF FILE
IP I/O IN PROGRESS
SE SOFT ERROR
HE HARD ERROR
OF OFF LINE
NX NON-EXISTANT DEVICE
UNIT NUMBER is the unit number of the device specified in the header
for which this status applies. BYTE COUNT is the number if eight bit
bytes in the indirect data portion of the message.
4.9.2 Modes - Word indirect only.
4.9.3 Effect Of Function - Provides device status. This message may
come either upon request or upon a device status change. This
function is also used to cause the 10 to log errors in the 10 system
error file for devices which belong to the 11 and are not directly
accessible to the 10.
4.9.4 Involvement With Other Functions - Request device status.
Page 22
4.9.5 Valid Devices - All but CLK
4.9.6 Other Notes -
Page 23
4.10 From-11 Device Status (#7)
4.10.1 Format -
!=========================================================================!
! BYTE ! UNIT ! ! ! !
! COUNT ! NUMBER ! ! ! !
!=========================================================================!
!=========================================================================!
! !F!L!E!I!S!H!O!N! ! ! !
! !E!G!F!P!E!E!F!X! ! ! !
!=========================================================================!
See to-11 device status for explanation of general status bits.
4.10.2 Modes - See to-11 device status, above.
4.10.3 Effect Of Function - See to-11 device status, above.
4.10.4 Involvement With Other Functions - See to-11 device status,
above.
4.10.5 Valid Devices - See to-11 device status, above.
4.10.6 Other Notes -
Page 24
4.11 To-11 Request Date/time (#11)
4.11.1 Format -
!=========================================================================!
! !
! !
!=========================================================================!
This message consists of a header only
4.11.2 Modes - Always byte direct
4.11.3 Effect Of Function - This function causes the 11 to send the
10 the "here is date/time" message. Request date/time also causes the
11 to send the "here is line speeds message" and the "here is status"
message relating the reason for the last crash (unless the KLERR file
does not exist).
This message is normally sent to the 11 when the 10 monitor first
comes up. If the 11's response is that it has no valid date/time, the
10 must then ask the operator for this information. The 10 should
then send the 11 the "here is date/time" information so that the 11
will have a valid date/time.
4.11.4 Involvement With Other Functions - Here is date/time, here are
line speeds, here is device status.
4.11.5 Valid Devices - CLK. However, the 11 ignores the device field
in this message, as it is only relevant to the CLK device.
4.11.6 Other Notes -
Page 25
4.12 From-11 Request Date/time (#11)
4.12.1 Format -
!=========================================================================!
! !
! !
!=========================================================================!
This message consists of a header only.
4.12.2 Modes - Always byte direct
4.12.3 Effect Of Function - This message causes the 10 to send the 11
the "here is date/time" message. The 11 sends the 10 this message at
midnight, since the 11 currently stops incrementing its copy of the
time at midnight and requires the 10 to send the new time. If the 10
does not send the 11 a response immediately, the 11 will lose the
amount of time by which the 10 was late in its response, and if the 10
requests the time from the 11 after such a delay in the 10's response,
the 11 will still return a valid date/time message.
4.12.4 Involvement With Other Functions - Here is date/time.
4.12.5 Valid Devices -
4.12.6 Other Notes -
Page 26
4.13 To-11 Here Is Date/time (#12)
4.13.1 Format -
!=========================================================================!
! 0 ! BYTE ! ! ! !
! ! COUNT (=^D10) ! ! ! !
!=========================================================================!
!=========================================================================!
! NON-ZERO IF DATE/TIME VALID ! YEAR ! !
!-------------------------------------------------------------------------!
! MONTH ! DAY ! DAY OF WEEK !NON-0 IF D.S.T! !
!-------------------------------------------------------------------------!
! SECONDS/2 SINCE MIDNIGHT ! ! !
!=========================================================================!
The valid field must be non-zero to specify that this message contains
a valid date/time. (D.S.T. is daylight savings time). The month,
day and day of week fields all start with zero; that is, January is
0, February is 1, etc. The first day of a month is represented by a 0
in the day field. Zero in the day of week field represents Monday.
4.13.2 Modes - Always word indirect.
4.13.3 Effect Of Function - The 10 sends this message to the 11
either in response to a request date/time message (which is
automatically send by the 11 at midnight) or whenever it cares to
update the time in the 11. If the 10 has no valid date/time, it
should just send the message with the valid field set to zero.
4.13.4 Involvement With Other Functions - Request date/time.
4.13.5 Valid Devices - CLK.
4.13.6 Other Notes -
Page 27
4.14 From-11 Here Is Date/time (#12)
4.14.1 Format -
!=========================================================================!
! ! ! ! !
! ! ! ! !
!=========================================================================!
!=========================================================================!
! NON-ZERO IF DATE/TIME VALID ! YEAR ! !
!-------------------------------------------------------------------------!
! MONTH ! DAY ! DAY OF WEEK !NON-0 IF D.S.T! !
!-------------------------------------------------------------------------!
! SECONDS/2 SINCE MIDNIGHT ! ! !
!=========================================================================!
(D.S.T. is Daylight Savings Time).
4.14.2 Modes - Always word indirect.
4.14.3 Effect Of Function - This message is sent either at the 10's
request or after reentering primary protocol (i.e. when leaving
EDDT). It may come at other times as well. The 11 also sends the
"here are line speeds" message along with this one when the 10
requests date/time.
4.14.4 Involvement With Other Functions - Request date/time, here are
line speeds.
4.14.5 Valid Devices - CLK.
4.14.6 Other Notes -
Page 28
4.15 To-11 Flush Output For Line (for ^O) (#13)
4.15.1 Format -
!=========================================================================!
! ! LINE ! ! ! !
! ! NUMBER ! ! ! !
!=========================================================================!
4.15.2 Modes - Always byte direct.
4.15.3 Effect Of Function - This function causes the 11 to flush any
characters waiting to be output to the specified TTY line. It is used
by the 10 for the control-O function. It does not flush any pending
send all output for the line.
4.15.4 Involvement With Other Functions - String output to TTYs.
4.15.5 Valid Devices - DLS, CTY, etc.
4.15.6 Other Notes -
Page 29
4.16 To-11 Send All (#14)
4.16.1 Format - Same as string data.
4.16.2 Effect Of Function - Types out specified string on all TTY
type devices connected to the 11. The clear output message function
(#13) has no effect on send all messages.
4.16.3 Involvement With Other Functions - Send all messages come out
as an unbroken string of characters. Any user output is temporarily
stopped when the line is busy with a send all message. Maximum send
all string length is ?? bytes.
4.16.4 Valid Devices - TTY type devices only.
4.16.5 Other Notes -
Page 30
4.17 From-11 Dataset Connected (#15)
4.17.1 Format -
!=========================================================================!
! LINE ! ! LINE ! !. . . !
! NUMBER ! ! NUMBER ! !. . . !
!=========================================================================!
4.17.2 Modes - Always byte direct. This message is multi-line.
4.17.3 Effect Of Function - The 11 sends the 10 this message after a
dataset TTY line (connected to a modem) rings and is answered by the
11. The 10 may then treat this TTY in the same way as if it were a
local TTY, i.e. clear to send and data terminal ready have been
asserted to the local modem by the 11.
4.17.4 Involvement With Other Functions - To-11 hang up dataset,
from-11 dataset hung up, to-11 dataset control. From-11 line speed
message informs the 10 as to whether or not the line is a dataset
line.
4.17.5 Valid Devices - DLS.
4.17.6 Other Notes -
Page 31
4.18 To-11 Hang Up Dataset (#16)
4.18.1 Format -
!=========================================================================!
! ! LINE ! ! ! !
! ! NUMBER ! ! ! !
!=========================================================================!
4.18.2 Modes - Always byte direct. This is not a multi-line
function, although its counterpart (from-11 dataset hung up) is.
4.18.3 Effect Of Function - This message will cause the 11 to hang up
the specified dataset line. The message is ignored if it is sent with
a line number not corresponding to a dataset line.
4.18.4 Involvement With Other Functions - From-11 dataset connected,
from-11 here are line speeds. From-11 dataset hung up is not (?) sent
to the 10 after the 10 sends the to-11 hang up dataset message.
From-11 here are line speeds message indicates which lines are dataset
lines.
4.18.5 Valid Devices - DLS.
4.18.6 Other Notes -
Page 32
4.19 From-11 Dataset Hung Up (#16)
4.19.1 Format -
!=========================================================================!
! LINE ! ! LINE ! !. . . !
! NUMBER ! ! NUMBER ! !. . . !
!=========================================================================!
4.19.2 Modes - Always byte direct. This message is multi-line.
4.19.3 Effect Of Function - The 11 sends this message to the 10 after
carrier detected drops for more than approx. 6 seconds. The delay is
necessary in order to protect the terminal user from interrmittent
line noise or failure. When the 10 receives this message for a line
or lines, it can assume the dataset has been hung up (i.e. data
terminal ready has been dropped) , freeing the dataset for further
use.
4.19.4 Involvement With Other Functions - The dataset control
messages.
4.19.5 Valid Devices - DLS.
4.19.6 Other Notes -
Page 33
4.20 To-11 Acknowledge (#17)
4.20.1 Format -
!=========================================================================!
! ! LINE ! ! LINE !. . . !
! ! NUMBER ! ! NUMBER !. . . !
!=========================================================================!
4.20.2 Modes - Always byte direct.
4.20.3 Effect Of Function - The 10 sends this message to the 11 for a
device when the 10 has again made the entire "device allocation"
available. This device allocation can be initially setup with the
to-11 and from-11 here is line allocation messages, or the driver can
use the default allocation for the device.
4.20.4 Involvement With Other Functions - Here is line allocation,
messages that send data to the 11.
4.20.5 Valid Devices - TTY devices, LPT, CDR, FE device, any other
device capable of accepting data from the 10.
4.20.6 Other Notes - The device sending data should never send more
data until the acknowledge message comes back. Thus, if any
look-ahead is to be done, it is done by the device receiving the data,
and the sending processor never tries to send data before the ack for
the purpose of keeping the receiving device busy. See the section on
device dependent protocol elements for default allocations for the
devices.
If the -11 has sent less that the allocation to the -10, it may choose
to wait for a to-11 ack before sending more data. Thus, the -10
should send an ack and reset its pointers to the to-10 buffer it is
using whenever it has processed all the data from the -11, as opposed
to waiting until the -11 has sent a full allocations worth.
Because the -10 cannot prevent the -11 from sneaking in more to-10
data between the time the -10 resets its buffer pointers and the time
the -11 gets the to-11 ack, the actual buffer size must be setup to be
twice the allocation for the given device. (This condition is likely
Page 34
to occur if to-10 data is coming in while the byte transfer for the
to-11 ack is taking place in the to-11 direction. The -11 will think
that the full allocation is available on receiving the ack, while the
actual buffer space available is the allocation less the size of the
data just transferred.)
For devices that have to be started such as the CDR, this function
starts the device going, as if the allocation for the device was
assumed to be partly in use when the device was initialized.
Page 35
4.21 From-11 Acknowledge (#17)
4.21.1 Format -
!=========================================================================!
! LINE ! ! LINE ! !. . . !
! NUMBER ! ! NUMBER ! !. . . !
!=========================================================================!
4.21.2 Modes - See the from-11 acknowledge function.
4.21.3 Effect Of Function - See the from-11 acknowledge function.
4.21.4 Involvement With Other Functions - See the from-11 acknowledge
function.
4.21.5 Valid Devices - See the from-11 acknowledge function.
4.21.6 Other Notes -
Page 36
4.22 To-11 Xoff Line (#20)
4.22.1 Format -
!=========================================================================!
! ! LINE ! ! ! !
! ! NUMBER ! ! ! !
!=========================================================================!
4.22.2 Modes - Always byte direct.
4.22.3 Effect Of Function - This message is used by the 10 to
temporarily stop any pending output for a line. This message is
necessary for the 10 to be able to stop output in response to a
special control function (control-s on TOPS10).
4.22.4 Involvement With Other Functions - To-11 xon.
4.22.5 Valid Devices - This message is ignored for all but TTY
devices.
4.22.6 Other Notes -
Page 37
4.23 To-11 Xon Line (#21)
4.23.1 Format -
!=========================================================================!
! ! LINE ! ! ! !
! ! NUMBER ! ! ! !
!=========================================================================!
4.23.2 Modes - Always byte direct.
4.23.3 Effect Of Function - This function allows the 10 to resume TTY
output suspended by the to-11 xoff function.
4.23.4 Involvement With Other Functions - to-11 xoff.
4.23.5 Valid Devices - TTY devices only.
4.23.6 Other Notes -
Page 38
4.24 To-11 Here Are Line Speeds (#22)
4.24.1 Format -
!=========================================================================!
! LINE ! BYTE ! ! ! !
! NUMBER ! COUNT (=^D6) ! ! ! !
!=========================================================================!
!=========================================================================!
! INPUT SPEED ! OUTPUT SPEED ! !
!-------------------------------------------------------------------------!
!D! !STP! ! !
!=========================================================================!
D ONE IF THIS LINE IS A DATASET.
STP NUMBER OF STOP BITS FOR LINE
4.24.2 Modes - Always word indirect.
4.24.3 Effect Of Function - This message causes the 11 to set the
line speed to the specified value. The arguments are set to the
actual numerical baud rate (e.g. D9600 indicates 9600 baud, D134
indicates 134.5 baud). The dataset bit is ignored by the 11. The
number of stop bits is used by the 11 to set the DH11 line up for the
specified number of stop bits, which varies with line speed.
Normally, there are two stop bits for 110, 134.5, and 300 baud, and
all higher speed lines have one stop bit.
4.24.4 Involvement With Other Functions - From-11 here are line
speeds.
4.24.5 Valid Devices - TTY devices only.
4.24.6 Other Notes - An output speed of zero is ignored due to a DH11
hardware characteristic. In fact, the output speed for a DH11 line is
never set to zero, even if the 10 specifies that a line is turned off.
Page 39
4.25 From-11 Here Are Line Speeds (#22)
4.25.1 Format -
!=========================================================================!
! BYTE ! LINE ! ! ! !
! COUNT ! NUMBER ! ! ! !
!=========================================================================!
!=========================================================================!
! INPUT SPEED ! OUTPUT SPEED ! !
!-------------------------------------------------------------------------!
!D! !STP! ! !
!=========================================================================!
D DATASET LINE
STP NUMBER OF STOP BITS
4.25.2 Modes - Always word indirect.
4.25.3 Effect Of Function - This function informs the 10 as to the
status of the TTY lines. This message is sent by the 11 after the 10
has been reloaded, triggered by entering primary protocol for the
first time.
4.25.4 Involvement With Other Functions - to-11 here are line speeds.
4.25.5 Valid Devices - TTY devices only. The CTY device accepts
this, but currently does nothing with the information since the
DL11',S line speed is not programmable.
4.25.6 Other Notes -
Page 40
4.26 To-11 Here Are Line Buffer Allocations (#23)
4.26.1 Format -
!=========================================================================!
! LINE ! ALLOCATION ! LINE ! ALLOCATION !. . . !
! NUMBER ! ! NUMBER ! !. . . !
!=========================================================================!
4.26.2 Modes - Always byte direct. This message is multi-line.
4.26.3 Effect Of Function - The allocation for a device is the
maximum amount of data, measured in bytes or words depending on the
device) that can be sent to the device after the last ack and before
the next ack.
4.26.4 Involvement With Other Functions - Data transfer messages.
4.26.5 Valid Devices - All devices capable of data transfer.
4.26.6 Other Notes -
Page 41
4.27 From-11 Here Are Line Buffer Allocations (#23)
4.27.1 Format -
!=========================================================================!
! ALLOCATION ! LINE ! ALLOCATION ! LINE !. . . !
! ! NUMBER ! ! NUMBER !. . . !
!=========================================================================!
4.27.2 Modes - See to-11 here are line buffer allocation message.
4.27.3 Effect Of Function - See to-11 here are line buffer allocation
message.
4.27.4 Involvement With Other Functions - See to-11 here are line
buffer allocation message.
4.27.5 Valid Devices - See to-11 here are line buffer allocation
message.
4.27.6 Other Notes -
Page 42
4.28 From-11 Here Is 11 Reboot Information (#24)
!=========================================================================!
! 11 ROM WORD ! ! !
!=========================================================================!
4.28.1 Modes - Always byte direct
4.28.2 Effect Of Function - The ROM word is a copy of what the switch
register of the 11 was set to when the 11 front end monitor was last
loaded. If the floppy disk or RP04 button was used to reload the 11,
the ROM word is set to what the switch register would have had to be
set to in order to load the 11 front end monitor from the floppy or
RP04. This message is triggered by the 10 sending the to-11 initial
message function (#1).
4.28.3 Involvement With Other Functions - To-11 initial message (#1).
4.28.4 Valid Devices -
4.28.5 Other Notes -
Page 43
4.29 To-11 Acknowledge All Devices (#25)
4.29.1 Format -
!=========================================================================!
! !
! !
!=========================================================================!
4.29.2 Modes - Always byte direct.
4.29.3 Effect Of Function - This message is used by the 10 to start
the from-11 I/O data again after the 10 has temporarily left primary
protocol (happens when the 10 goes into EDDT, does parity sweep,
etc.).
4.29.4 Involvement With Other Functions - Data transfers
4.29.5 Valid Devices - Any device that does data transfer.
4.29.6 Other Notes -
Page 44
4.30 From-11 Acknowledge All Devices (#25)
4.30.1 Format -
!=========================================================================!
! !
! !
!=========================================================================!
4.30.2 Modes - Always byte direct.
4.30.3 Effect Of Function - Same as to-11 acknowledge all devices,
except that the direction is reversed.
4.30.4 Involvement With Other Functions - Data transfer messages.
4.30.5 Valid Devices - All devices capable of doing data transfers.
4.30.6 Other Notes -
Page 45
4.31 To-11 Turn Device On/off Line (#26)
4.31.1 Format -
!=========================================================================!
! LINE ! 0=OFF LINE ! ! ! !
! NUMBER ! 1=ON LINE ! ! ! !
!=========================================================================!
4.31.2 Modes - Always byte direct.
4.31.3 Effect Of Function - This function turns the specified device
on or off line. Its main use is with TTY devices, where the message
has the effect of zeroing or restoring the input speed for the TTY
line. It is ignored for devices that the 11 is incapable of turning
on or off (LPT, CDR).
4.31.4 Involvement With Other Functions -
4.31.5 Valid Devices - TTY devices only.
4.31.6 Other Notes -
Page 46
5.0 DEVICE DEPENDENT INFORMATION
5.1 TTYs
5.1.1 Line Allocations - The to-11 allocations (output) are initially
set to 120 characters. This is also the maximum
The 11 assumes that the to-10 line allocations are infinite, so the 10
does not have to respond with an ack for input characters coming from
the 11.
5.1.2 CTY0 -
5.1.3 DL11C Or DL11E -
5.1.4 DH11 -
5.1.5 DLS - The DLS device is a pseudonym for all TTY lines on a
given 11. This device is convenient if the program does not wish to
remember which lines are on which device. Current TTY hardware
covered by the DLS device is the DH11 lines, the DL11s for CTY and
KLINIK, and the CTY device. The initial message that the 11 sends to
the 10 when the primary protocol is entered specifies which DLS line
corresponds to the primary DL11 driven 11 console.
5.2 LPT
5.2.1 Line Allocations -
5.3 CDR
5.3.1 Line Allocations -
5.4 F.E. Device
Page 47
5.4.1 Line Allocations -
5.5 Clock
5.6 Crash Information
5.7 KLERR
Page 48
6.0 INITIALIZATION SEQUENCE
Which 10 clears out the 11 comm areas if there is more than one 10
represented in the area?
1. Find privileged DTE with the lowest device code. This is the
DTE connected to the master 11.
2. Enter secondary protocol
3. Setup communications areas, headers.
4. Clear all STATUS words in all communications areas
5. Set valid examine (V bit) and queued protocol in use bit (Q
bit) in each STATUS word.
6. setup EPT locations for DTE (examine, deposit relocation,
protection).
7. issue secondary protocol command to enter primary protocol,
setting bit 35 of DTECMD which specifies that the
communications region is reset.
8. The 11 will immediately send an ack-all. The ack-all causes
a to-10 date/time message. The to-10 date/time messages
causes line speed messages for all lines on that 11 if and
only if the date/time message previously sent was valid.
9. The 10 need not send a date/time request to the 11. Instead,
it can wait for the automatic message to arrive.
10. The 10 sends its initial message, containing the number of
TTY lines it believes the 11 to have.
11. The 11 responds by sending the to-10 initial message (CTY
/DLS alias) followed by the 11 reload information. KLINIT
will send any error data from a previous crash of the 10 at
this point.
12. Protocol initial handshaking is now complete.
7.0 SECONDARY PROTOCOL
Page 49
7.1 Format Of DTECMD
!=========================================================================!
! UNUSED ! FN ! DATA !
!=========================================================================!
FN FUNCTION CODE
DATA DATA FOR FUNCTION
7.2 Purpose
10 bootstrap programs, EDDT, and 10 operating system emergency
routines (parity error scan and recovery) need an extremely simple
mechanism for running the CTY which does a minimum number of 10
instructions and 10 memory operations. The secondary protocol is used
to fulfill this need. No keep alive count is kept while in secondary
protocol. Only privileged front ends may use the secondary protocol.
Restricted front ends always use the primary (queued) protocol.
7.3 EPT Relative Locations
Note that even if paging is turned off, the EPT address register still
defines where the EPT is considered to be, and thus where these EPT
locations are in physical memory.
The following EPT relative locations are used by the secondary
protocol:
1. DTEFLG=444, operation complete flag. Set to non-zero value
when a secondary protocol command is complete. Must be set
to zero before every secondary protocol command by the 10.
2. DTEF11=450, from-11 data. 11 puts character data in this
location.
3. DTECMD=451, secondary protocol 10 to 11 command word.
Commands are done by setting this word up with the function
code and the data (see format section above) and ringing the
11s doorbell.
4. DTEMTD=455, CTY output done complete flag. The 11 sets this
flag to a non-zero value and rings the 10s doorbell when the
CTY has finished output after a CTY output command. Note
that this is distinct from DTEFLG being set on a teletype
output command, which happens immediately after the 11
receives the command. Must be cleared by the 10 eiter before
CTY output command or after the 10 doorbell interrupt which
discovers that DTEMTD is non-zero occurs.
Page 50
5. DTEMTI=456, CTY input present flag. The 11 sets this flag to
a non-zero value and rings the 10s doorbell when a character
is typed on the CTY. The character data is found in DTEF11.
This flag must be cleared by the 10 after the interrupt
routine has completely processed the input character and is
again ready for another. Clearing this flag allows the 11 to
store another character into DTEF11 and to set DTEMTI to a
non-zero value again.
7.4 Function Codes
7.4.1 Code 10, CTY Output - CTY output function, data in DTECMD is
the eight bit output character. Note: in RSX10 and RSX20, this
command does not set DTEFLG after command completion. Only DTEMTD is
set after the output is complete. KLDCP sets DTEFLG after it
completes this command.
7.4.2 Code 11, Enter Secondary Protocol - This function must be
performed in order to use any of the other secondary protocol
functions.
7.4.3 Code 12, Enter Primary Protocol - This secondary protocol
function is used to enter the primary protocol. Bit 35 set to one in
the data field of DTECMD for this function specifies that the
communication region in the 10 has been reset.
Page 51
8.0 TEMPORARILY LEAVING PRIMARY PROTOCOL
To temporarily leave primary protocol, the examine protection word in
the EPT for the 11's DTE should be cleared, and the 11's doorbell
should be rung. This will cause the valid examine bit in the STATUS
word of the communications area to become zero. Usually the 10
program will immediately enter secondary protocol by issuing the
appropriate secondary protocol command.
9.0 REENTERING PRIMARY PROTOCOL
To reenter primary protocol, the reenter primary protocol command
should be issued through secondary protocol. If the communications
region should be re-scanned by the 11, bit 35 of the secondary
protocol command (low order bit of the data field) should be set to
one. Aside from the effect of bit 35, reentering primary protocol is
identical to entering the first time, that is, the 11 will send
date/time and line speeds if the date/time is valid.
See the section on the secondary protocol for further details.
Page 52
10.0 DIRECT TRANSFER SEQUENCE
In the following, "S" indicates the sender, and "R" indicates the
receiver.
1. S and R idle.
2. S sets up packet, containing one or more messages, with count
equal total byte count in packet
3. S sets up to-"R" communications section in S's area for byte
mode (if 11, hardware too)
4. S sets up QSIZE to size of entire packet
5. S sets up byte pointer or address
6. S increments to-"R" count and rings doorbell (should be
uninterruptable)
7. R notices to-"R" count has increased by exactly one
8. R sets up correct pointer or address to receive message
9. R sets up correct mode if R is an 11
10. R if this is the last fragment, R sets the I bit in the DTE.
11. R starts DTE by setting up its byte count. This count may be
less than QSIZE or less than message header counts. R may
fragment the packet as much as he pleases.
12. S gets to-"R" done interrupt, clears 2 bit in STATUS in s's
comm area
13. Direct transfer completed.
Page 53
11.0 INDIRECT TRANSFER SEQUENCE
1. S and R idle
2. S initiates direct transfer of packet, function word of last
message in packet (last message is the only message in a
packet that can be indirect) has indirect bit set
3. When R gets to-"R" done after the transfer of the direct
packet, R may set up the byte pointer, or R may wait until
the doorbell.
4. When S gets to-"R" done, S sets up QSIZE in the to-"R"
section of S's communications area
5. S sets up byte pointer or address
6. S sets up word or byte mode (F field in STATUS in to-"R"
section of S's communications area)
7. S ensures no interrupts happen
8. S sets indirect transfer (@) bit in the STATUS word in the
to-"R" section of S's comm area
9. S rings R's doorbell
10. R clears to-"R" doorbell
11. R notices that @ bit is set
12. R sets TOIT bit in to-"S" section of R's area
13. R sets up byte pointer or address
14. R starts up DTE transfer by setting up byte count. Byte
count need not be entire value of QSIZE or message header
count; R may fragment the message as much as he pleases by
not setting the "I" bit in the DTE status. This way, R gets
an interrupt each time a fragment to him completes, while S
still considers the transfer in progress. R leaves the TOIT
bit set in R's area for as long as data is being transferred.
15. Before the last fragment is to be received by R, R will set
the I bit in the DTE status so as to interrupt S at the
termination of the transfer.
16. S gets to-"R" done
17. S clears @ bit in his to-"R" section
18. R clears 2 bit in his to-"S" section on the last to-"R" done
interrupt
Page 54
19. Indirect transfer completed.
Page 55
12.0 BOOTSTRAP PROCEDURES
12.1 Bootstrap Procedure For 11
The 10 follows this procedure to bootstrap the 11 after it has
crashed:
1. Hit "electronic finger" to activate 11 ROM
2. Wait for power failure indication in DTE CONI word
3. Turn off "finger" and retry if power failure indication does
not appear in 5000 ms.
4. Wait 5000 ms. for power failure to reset. Turn off finger
if power failure does not reset and retry.
5. Wait 150 ms
6. Turn off 11 reload "finger", set up to-10 byte count in DTE
to magic number ^O1365
7. Ring to-11 doorbell
8. Wait up to 2000 ms. for to-11 doorbell to clear. Retry if
it did not clear.
9. Clear to-10 done and to-10 error.
10. If dump is not desired, go to step 14
11. Setup byte pointer and count for dump.
12. Wait for to-10 done or to-10 error
13. Loop until 28K of 11 core has been dumped.
14. Setup byte pointer,count for proper bootstrap program (floppy
or RP04). Maximum length of this program is 256 16 bit
words.
15. Ring 11 doorbell
16. Wait 5000 ms for to-11 done or to-11 error, retry if to-11
error occurs.
17. Wait for 10 doorbell; clear 10 doorbell, ring 11 doorbell
again, reestablish protocol To-10 doorbell signifies that the
front end was successfully started.
18. End of 11 bootstrap procedure
Page 56
12.2 Bootstrap Procedure For 10
Page 57
13.0 ERROR CONDITIONS
13.1 Power Failure
After a power failure occurs, the front end initializes the KL10 and
restarts it at exec virtual location 70. The 10 must then reestablish
the level of protocol it desires, starting at initialization.
13.2 11 Keep Alive Count Expires
The 10 is responsible for dumping and reloading the 11. The 10 can
cause the 11 to load the front end monitor again from either the
floppy disk, RP04, or through the DTE. The 10 should allow this
feature to be defeated for the purposes of debugging.
13.3 10 Keep Alive Count Expires
The 11 will load the 10's bootstrap program into core and start it in
such a way as to cause it to dump 10 core into a pre-specified file in
the 10 file system. The bootstrap will then load a new copy of the 10
operating system into 10 memory using a pre-specified filename. The
11 should allow this feature to be defeated for debugging purposes.
13.4 To-10 Error
13.5 To-11 Error
13.6 I/O Page Fail
13.7 Protocol Breakdown
Page Index-1
INDEX
Bootstrap procedures . . . . . . . 55
Communications region . . . . . . 3
Device dependent information . . . 46
Direct transfer sequence . . . . . 52
Error conditions . . . . . . . . . 57
From-11 Acknowledge (#17) . . . . 35
From-11 Acknowledge All Devices (#25) 44
From-11 Character Data (#4) . . . 18
From-11 CTY DLS Alias (#2) . . . . 13
From-11 Dataset Connected (#15) . 30
From-11 Dataset Hung Up (#16) . . 32
From-11 Device Status (#7) . . . . 23
From-11 Here Are Line Buffer Allocations (#23) 41
From-11 Here Are Line Speeds (#22) 39
From-11 Here Is 11 Reboot Information (#24) 42
From-11 Here Is Date/time (#12) . 27
From-11 Request Date/time (#11) . 25
From-11 Request Device Status (#5) 20
From-11 String Data (#3) . . . . . 16
Indirect . . . . . . . . . . . . . 7, 9, 11, 14, 21, 26 to 27,
38 to 39, 53 to 54
Indirect transfer sequence . . . . 53
Initialization sequence . . . . . 48
Introduction . . . . . . . . . . . 2
Message headers . . . . . . . . . 9
Protocol messages . . . . . . . . 11
Reentering primary protocol . . . 51
Secondary protocol . . . . . . . . 48
Temporarily leaving primary protocol 51
To-11 Acknowledge (#17) . . . . . 33
To-11 Acknowledge All Devices (#25) 43
To-11 Character Data (#4) . . . . 17
To-11 Device Status (#7) . . . . . 21
To-11 Flush Output For Line (for ^O) (#13) 28
To-11 Hang Up Dataset (#16) . . . 31
To-11 Here Are Line Buffer Allocations (#23) 40
To-11 Here Are Line Speeds (#22) . 38
To-11 Here Is Date/time (#12) . . 26
To-11 Initial Message (#1) . . . . 11
To-11 Request Date/time (#11) . . 24
Page Index-2
To-11 Request Device Status (#5) . 19
To-11 Send All (#14) . . . . . . . 29
To-11 String Data (#3) . . . . . . 14
To-11 Turn Device On/off Line (#26) 45
To-11 Xoff Line (#20) . . . . . . 36
To-11 Xon Line (#21) . . . . . . . 37
[End of KLCOM.RNO]