Trailing-Edge
-
PDP-10 Archives
-
AP-4178E-RM
-
swskit-documentation/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 -
!==============================