Google
 

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]