Enter your search terms Submit search form
	Web pdp-10.trailing-edge.com

.SD 60;.LOWER CASE;.AUTOPARAGRAPH;.FLAG CAP;.FLAG INDEX
.VARIABLE COVER @ %
.NONUMBER
.IF COVER
.TS 5,25
TO:	<DN60 ^INTEREST ^LIST	DATE: 31-^OCT-77
.I 5
#	FROM: ^MINOO ^MALHOTRA
.I 5
#	#######^KALMAN ^RETI
.I 5
#	#######^BARRY ^SUSSMAN
.I 5
#	DEPT: <COMM/NETS ^SOFTWARE ^ENGINEERING
.I 5
#	EXT: #6360
.I 5
#	LOC/MAIL STOP: ^^MR1-2/E89\\
.I 5
#	POLE: ^E15
.B 2
.LM 7;.TS 7;.I -7
SUBJ: ^MAINTENANCE ^MANUAL FOR <DN60 PROGRAM
.LM 0
 ^THE ENCLOSED MANUAL IS THE TENTH DRAFT OF THE
<DN60 ^MAINTENANCE ^MANUAL.
^THE NINTH DRAFT WAS SENT TO CUSTOMERS WITH RELEASE 3.0 OF MONITOR. 
^THE EIGHT DRAFT WAS SENT TO CUSTOMERS AS PART OF THE ^SEPTEMBER, 1977, FIELD
TEST OF THE <DN64.
^THE SEVENTH DRAFT WAS SENT TO CUSTOMERS AS PART OF THE ^JUNE, 1977,
FIELD TEST OF THE <DN64.
^THE SIXTH DRAFT WAS PART OF THE FIRST RELEASE 
OF THE <DN61.
^YOUR COMMENTS ARE SOLICITED.
 ^MAJOR CHANGES SINCE THE NINTH DRAFT: ADDED SECTIONS FOR <HASP-^MULTILEAVING AS PART OF THE <DN62 RELEASE. 
 ^MAJOR CHANGES SINCE THE EIGHTH DRAFT: CHANGED DOCUMENT
NUMBER FROM 130-952-066 TO <JBS-77-001.
 ^MAJOR CHANGES SINCE THE SEVENTH DRAFT: ADDED <KMC11/DUP11 AND <DN61-B.
 ^MAJOR CHANGES SINCE THE SIXTH DRAFT: UPDATED ^CHAPTER 14 TO INCLUDE 
SOME PERFORMANCE IMPROVEMENTS. 
 ^MAJOR CHANGES SINCE THE FIFTH DRAFT: ADDED CHAPTER 14.
^REWROTE THE TITLE PAGE.
^ADDED REFERENCES TO <DECSYSTEM-20, <DUP11 AND <DN64.
 ^MAJOR CHANGES SINCE THE FOURTH DRAFT: CHANGED THE NAME TO '<DN60'.
^REFRESHED THE DISTRIBUTION LIST.
 ^MAJOR CHANGES SINCE THE THIRD DRAFT: SOME REARRANGEMENT OF SECTIONS
TO ISOLATE THE <DQ11 CODE, TO PROVIDE FOR LATER SUBSTITUTION
OF <DUP11<'S.  ^BETTER HANDLING OF 0 TURN-AROUND-TIME
MODEMS.
^MANY STYLISTIC CHANGES.  ^ADDITION OF A CHAPTER ON
<BISYNC.
 ^MAJOR CHANGES SINCE THE SECOND DRAFT:
A COMPLETE REWRITE OF THE CHAPTER ON PERFORMANCE.
^ADDITION OF A FUNCTION TO DUMP THE <DN60<'S OUTPUT BUFFERS.
 ^MAJOR CHANGES SINCE THE FIRST DRAFT: EXPANDED INTRODUCTION AND
COMPLETION OF CHAPTERS <BSC, <DL10 AND <XL3780.
^INCLUSION OF <DTE20 FEATURES, ALTHOUGH THE <DTE CHAPTER IS
STILL INCOMPLETE.
^ADDITION OF THE CHAPTER ON THE <CAL11_. <UUO.
^MORE INFORMATION ON <DDT60.
^INFORMATION ON REGISTER CONVENTIONS.
^ADDITION OF AN INDEX.
^ADDITION OF A CHAPTER ON DIFFERENCES FROM THE <DAS78
AND ONE ON PERFORMANCE ESTIMATES.
.NONUMBER
.TITLE #
.PAGE
.ENDIF COVER
.ST #
#
.B 8
.CENTER
<DN60
.B 1
.CENTER
^MAINTENANCE ^MANUAL
.B 4
.CENTER
^DOCUMENT ^NUMBER: <JBS-77-001-02-U
.B 1
.CENTER
(FORMERLY 130-952-066)
.B 6
.CENTER
^OCTOBER 31, 1978
.B 6
.LM +8;.RM -8
^THIS MANUAL IS WRITTEN FOR THE PERSON WHO HAS THE
RESPONSIBILITY TO MAINTAIN THE <DN60 SOFTWARE ON
A <DEC<SYSTEM-10 OR <DECSYSTEM-20.
.B 1;.LM +4;.I -4
^OPERATING ^SYSTEM AND VERSION: <TOPS-10 6.03 OR
<TOPS-20 3.0.
.B 1;.I -4
^SOFTWARE VERSION: <DN61D VERSION 2,
<DN61S VERSION 2,
<DN61B VERSION 1. 
<DN64A VERSION 1.
<DN62S VERSION 1. 
<DN62D VERSION 1 AND  
<DN65S VERSION 1.
.LM -4;.LM -8;.RM +8
.B 11;.CENTER
DIGITAL EQUIPMENT CORPORTATION, MAYNARD, MASSACHUSETTS
.PAGE
.RIGHT
^FIRST ^PRINTING: ^JUNE 23, 1977
.RIGHT
^REVISED: ^SEPTEMBER 17, 1977
.RIGHT
^REVISED: ^OCTOBER 31, 1978
.B 3
"^THE INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT
NOTICE AND SHOULD NOT BE CONSTRUED AS A
COMMITMENT BY ^DIGITAL ^EQUIPMENT ^CORPORATION.
^DIGITAL ^EQUIPMENT ^CORPORATION ASSUMES NO RESPONSIBILITY
FOR ANY ERRORS THAT MAY APPEAR IN THIS DOCUMENT.
 ^THE SOFTWARE DESCRIBED IN THIS DOCUMENT IS FURNISHED
UNDER A LICENSE AND MAY BE USED OR COPIED ONLY IN
ACCORDANCE WITH THE TERMS OF SUCH LICENSE.
 ^NO RESPONSIBILITY IS ASSUMED
FOR THE USE OR RELIABILITY OF SOFTWARE ON
EQUIPMENT THAT IS NOT SUPPLIED BY <DIGITAL
OR ITS AFFILIATED COMPANIES."
.B 2
.CENTER
^COPYRIGHT (^C) 1980, 1978 BY ^DIGITAL ^EQUIPMENT ^CORPORATION
.B 2
.CENTER
^THE FOLLOWING ARE TRADEMARKS OF 
.CENTER
^DIGITAL ^EQUIPMENT ^CORPORATION:
.B 2
.TS 16,31,46,61
^^COMPUTER LABS\\	^^DECUS\\	^^FOCAL\\	^^MASSBUS\\
.BREAK
^^COMTEX\\	^^DEC\\SYSTEM-10	^^INDAC\\	^^RSTS\\
.BREAK
^^DDT\\	^^DIBOL\\	^^LAB-8\\	^^RSX\\
.BREAK
^^DEC\\	^^DIGITAL\\	^^OMNIBUS\\	^^TYPESET-8\\
.BREAK
^^DECCOMM\\	^^EDUSYSTEM\\	^^OS/8\\	^^DECSYSTEM-20\\
.BREAK
^^DEC\\TAPE	^^FLIP CHIP\\	^^PDP\\	^^TYPESET-11\\
.BREAK
#	#	^^PHA\\	^^UNIBUS\\
.PAGE
.CENTER
^TABLE OF ^CONTENTS
.TITLE TABLE OF CONTENTS
.B 6;.LM +15
.I -15
^CHAPTER#01#--#<INTRODUCTION
.I -15
^CHAPTER#02#--#<DATA <STRUCTURES <OVERVIEW
.I -15
^CHAPTER#03#--#<PREFIX <SECTIONS
.I -15
^CHAPTER#04#--#<SECTION "<MININT"
.I -15
^CHAPTER#05#--#<SECTIONS "<INIT1", "<INITDQ", "<INITUP"  AND "<INIT2"
.I -15
^CHAPTER#06#--#<SECTION "<STGMAN"
.I -15
^CHAPTER#07#--#<SECTION "<QUEING"
.I -15
^CHAPTER#08#--#<SECTIONS "<DQ11", "<DUP11" AND "<KMC11"
.I -15
^CHAPTER#09#--#<SECTION "<MDCODE"
.I -15
^CHAPTER#10#--#<SECTION "<MSGHDL"
.I -15
^CHAPTER#11#--#<SECTION "<DISPAT"
.I -15
^CHAPTER#12#--#<SECTION "<BSC"
.I -15
^CHAPTER#13#--#<SECTION "<DL10"
.I -15
^CHAPTER#14#--#<SECTIONS "<DTE10" AND "<DTE20"
.I -15
^CHAPTER#15#--#<SECTION "<XL3780"
.I -15
^CHAPTER#16#--#<SECTION "<XLHASP" 
.I -15
^CHAPTER#17#--#<SECTION "<CHK11<"
.I -15
^CHAPTER#18#--#<DEBUGGING <FACILITIES
.I -15
^CHAPTER#19#--#<ASSEMBLY <INSTRUCTIONS
.I -15
^CHAPTER#20#--#<THE <CAL11_. <UUO
.I -15
^CHAPTER#21#--#<DIFFERENCES <FROM <THE <DAS78
.I -15
^CHAPTER#22#--#<PERFORMANCE <ESTIMATES <FOR <THE <DN61
.I -15
^CHAPTER#23#--#<BINARY <SYNCHRONOUS <PROTOCOL (<BISYNC)
.I -15
^APPENDIX#^A#--#<DTE10 <FORMATS
.LM -15
.NUMBER
.CHAPTER INTRODUCTION
.HL 1 ^AUDIENCE
 ^THIS DOCUMENT IS INTENDED TO BE READ BY PERSONS HAVING
RESPONSIBILITY FOR MAINTENANCE AND/OR MODIFICATION OF THE
<>DN60 FRONT END SOFTWARE.
^THIS DOCUMENT IS INTENDED TO BE READ TOGETHER WITH THE LISTING
OF THE <>DN60 PROGRAM, AND, TO FACILITATE THIS, THE
INFORMATION IN THIS DOCUMENT IS GENERALLY PRESENTED IN
THE SAME ORDER AS THE READER WILL FIND IT IN THE LISTING.
 ^OTHER PERSONS MAY FIND THIS DOCUMENT INTERESTING BECAUSE OF
THE "INSIDE" INFORMATION IT PROVIDES ABOUT THE <>DN60 SOFTWARE,
BUT SUCH PERSONS ARE NOT THE INTENDED AUDIENCE.
 ^CHAPTER 23, WHICH IS A TUTORIAL ON <>BISYNC>, MAY BE READ
INDEPENDENTLY OF THE REST OF THIS MANUAL.
.HL 1 ^ORGANIZATION
 ^THE <>DN61-D<> HARDWARE PACKAGE CONSISTS OF A
<>PDP-11/40
PROCESSOR INTERFACED TO A <>DL10
AND FROM ONE TO 12 <>DQ11-D<>'S
OR <>DQ11-E<>'S.  ^ALSO INCLUDED IN THE PACKAGE ARE
16^K WORDS OF PARITY MEMORY, A <>KW11-L
LINE FREQUENCY CLOCK AND A <>KG11-A
<>CRC CALCULATOR.
^IT INTERFACES TO A <DEC<SYSTEM-1070, 1080 OR 1090.
.INDEX <DEC<SYSTEM-1070
.INDEX <DEC<SYSTEM-1080
.INDEX <DEC<SYSTEM-1090
 ^THE <>DN61-S<> IS THE SAME EXCEPT THAT IT HAS 32^K OF MEMORY
AND USES A <>DTE20<>
IN PLACE OF THE <>DL10<>.
^IT INTERFACES TO THE <DEC<SYSTEM-1090.
.INDEX <DEC<SYSTEM-1090
 ^THE <>DN61-B<> HARDWARE PACKAGE CONSISTS OF A
<>PDP-11/34 PROCESSOR INTERFACED TO A <>DTE20 AND FROM ONE
TO 12 <>DUP11<>'S.  ^ALSO INCLUDED IN THE PACKAGE ARE
32^K WORDS OF PARITY MEMORY, UP TO 3 <>KMC11<>
MICROPROCESSORS AND A <>KW11-L<> COMPATABLE
LINE FREQUENCY CLOCK.
^IT INTERFACES TO THE <DEC<SYSTEM-1091.
.INDEX <DEC<SYSTEM-1091
 ^THE <>DN64-A<> HARDWARE PACKAGE IS THE SAME AS THE
<>DN61-B<> HARDWARE PACKAGE.  ^IT INTERFACES TO THE
<>DECSYSTEM-20<>.
 ^THE <>DN61-D<> HARDWARE PACKAGE IS VERY SIMILAR TO THE
<>DN87<> HARDWARE PACKAGE.  ^IN THE SAME WAY, THE <>DN61-S<>
IS VERY SIMILAR TO THE <>DN87S<>.
^THE <>DN61-B<> AND <>DN64-A<> USE A SUBSET OF THE <>DN20<>
CONFIGURATIONS.
^THE <>DN62 AND <>DN65 USE SAME HARDWARE AS THE <>DN61 AND 
<>DN64 RESPECTIVELY. 
.TEST PAGE 8
 ^THE PURPOSE OF THE <>DN60 FRONT END SOFTWARE IS TO
PROVIDE THE FOLLOWING FUNCTIONS:
.LIST
.LE;^DRIVING THE SYNCHRONOUS LINES, WHICH MAY REQUIRE
SERVICE AT
UP TO 100,000 BITS PER SECOND.
.LE;^CONVERTING <DEC<SYSTEM-10/20
.INDEX <DEC<SYSTEM-10
.INDEX <DECSYSTEM-20
DATA FORMATS TO THE FORMATS
REQUIRED BY THE <IBM 360<, <IBM 370<, <HASP ^MULTILEAVING ^WORKSTATION,  <IBM 3780< AND <IBM 2780<.
.INDEX <IBM 360
.INDEX <IBM 370
.INDEX <HASP ^MULTILEAVING ^WORKSTATION
.INDEX <IBM 3780
.INDEX <IBM 2780
.LE;^CONVERTING THE DATA FORMATS USED BY THE 
<IBM 360<, <IBM 370<, <IBM 3780< AND
.INDEX <IBM 360
.INDEX <IBM 370
.INDEX <HASP ^MULTILEAVING ^WORKSTATION
.INDEX <IBM 3780
<IBM 2780< TO THE FORMAT USED BY THE <DEC<SYSTEM-10/20.
.INDEX <DEC<SYSTEM-10
.INDEX <DECSYSTEM-20
.INDEX <IBM 2780
.LE;^SCANNING THE MESSAGES RECEIVED FROM THE SYNCHRONOUS
LINES TO EXTRACT THE DATA EMBEDDED IN THE <>BSC PROTOCOL.
.LE;^PUTTING DATA INTO A <>BSC "ENVELOPE" TO TRANSMIT IT.
.END LIST
 ^TO ACCOMPLISH THESE TASKS EFFICIENTLY AND RELIABLY, THE
<>DN60 FRONT END SOFTWARE IS ORGANIZED AS SEVERAL
LOOSELY COUPLED TASKS.  ^THESE ARE:
.LIST
.LE;<>BSC - THE TASK THAT PERFORMS <>BSC INTERPRETATION.
.LE;<>XLATE - THE TASK THAT TRANSLATES DATA FORMATS.
.LE;<>XLHASP - THE TASK THAT TRANSLATES, COMPRESSES AND DECOMPRESSES DATA FOR <HASP ^MULTILEAVING. 
.LE;<>DL10 - THE TASK THAT COMMUNICATES WITH THE <>PDP<-10>.
.LE;<>IDLE - THE TASK THAT PERFORMS BACKGROUND FUNCTIONS.
.END LIST
(^SOME OF THESE TASK NAMES ARE ALSO SECTION NAMES.)
 ^IN ADDITION TO THE TASKS THERE ARE SUBROUTINES USED BY
SEVERAL TASKS, INTERRUPT ROUTINES, INITIALIZATION,
AND THE DISPATCHER THAT ALLOCATES TIME TO THE TASKS.
^ALL OF THESE ARE ORGANIZED INTO 
26 SECTIONS, AS FOLLOWS:
.LIST
.LE;<>>S - SYMBOL DEFINITIONS COMMON TO MANY ^DIGITAL
^EQUIPMENT ^CORPORATION PRODUCTS.
.LE;<>DN61D - PARAMETERS FOR THE <>DN61-DA AND <>DN61-DB<>.
.LE;<>DN61S - PARAMETERS FOR THE <>DN61-SA AND <>DN61-SB<>.
.LE;<>DN61B<> - PARAMETERS FOR THE <>DN61-BA<> AND <>DN61-BB<>.
.LE;<>DN62S<> - PARAMETER FOR THE <>DN62S
.LE;<>DN64A - PARAMETERS FOR THE <>DN64-AA AND <>DN64-AB<>.
.LE;<>MACROS - SOME USEFUL <>PDP-11 MACROS.
.LE;<>DEFINE - DEFINITIONS FOR THE <>DN60<>.
.LE;<>MININT - "MINOR" INTERRUPT ROUTINES.
.LE;<>INIT2 - SECTION 2 OF INITIALIZATION.
.LE;<>STGMAN - SUBROUTINES TO MANAGE "FREE STORAGE".
.LE;<>QUEING - SUBROUTINES TO SEND AND RECEIVE INTER-TASK 
DATA.
.LE;<>DQ11 - SUBROUTINES FOR DRIVING THE <>DQ11<>'S.
.LE;<>DUP11 - SUBROUTINES FOR DRIVING THE <>DUP11<>'S.
.LE;<>KMC11 - SUBROUTINES FOR DRIVING THE <>KMC11<>/<>DUP11<>
COMBINATION.
.LE;<>MSGHDL - SUBROUTINES FOR PROCESSING "MESSAGES".
.LE;<>DISPAT - THE TASK DISPATCHER.
.LE;<>BSC - THE <>BSC TASK.
.LE;<>DL10 - THE <>PDP-10 COMMUNICATIONS TASK, USING A <>DL10<>.
.LE;<>DTE10 - THE <>PDP-10 COMMUNICATIONS TASK, USING A <>DTE20<>
ON THE <DEC<SYSTEM-10.
.INDEX <DEC<SYSTEM-10
.LE;<>DTE20 - THE <>PDP-10 COMMUNICATIONS TASK, USING A <>DTE20<>
ON THE <DECSYSTEM-20.
.INDEX <DECSYSTEM-20
.LE;<>XLHASP - THE <HASP ^MULTILEAVING TRANSLATION, COMPRESSION AND DECOMPRESSION TASKS. 
.INDEX <HASP ^MULTILEAVING
.LE;<>XL3780 - THE <IBM 3780/2780 TRANSLATION AND BACKGROUND TASKS.
.INDEX <IBM 3780
.INDEX <IBM 2780
.LE;<>INITDQ - INITIALIZATION FOR THE <>DQ11<>'S.
.LE;<>INITUP - INITIALIZATION FOR THE <>DUP11<>'S AND <>KMC11<>'S.
.LE;<>MDCODE - A BINARY IMAGE OF THE <>KMC11<> MICROCODE.
.LE;<>INIT1 - SECTION 1 OF INITIALIZATION.
.LE;<>CHK11 - ONCE-ONLY HARDWARE TESTING.
.END LIST
 ^THIS DOCUMENT WILL DISCUSS EACH OF THESE SECTIONS.  ^FIRST,
HOWEVER, IT IS APPROPRIATE TO INTRODUCE THE DATA STRUCTURES.

.CHAPTER DATA STRUCTURES OVERVIEW
 ^THE DATA STRUCTURES ARE THE HEART OF THE <>DN60 FRONT END PROGRAM.
^DETAILED DISCUSSION OF SOME OF THE DATA STRUCTURES
WILL BE DEFERRED TO THE APPROPRIATE CHAPTER, BUT TO MAKE
THIS DOCUMENT COMPREHENSIBLE ON FIRST READING,
THE BASIC ONES
MUST BE GIVEN HERE.
.HL 1 ^CHUNKS
 ^INITIALLY ALL OF STORAGE BEYOND THE END OF THE OPERATIONAL
PROGRAM, INCLUDING THE ONCE-ONLY, GO-NOGO HARDWARE TEST,
<>CHK11<>, IS DIVIDED INTO "CHUNKS".
^A CHUNK IS 140 OR 300 OCTAL BYTES OF CORE STORAGE.
^INITIALLY ALL CHUNKS ARE ON THE "FREE LIST".
^WHEN A CHUNK IS ON THE FREE LIST IT CONTAINS A POINTER TO
THE CHUNK PRECEEDING IT ON THE FREE LIST AND TO THE
CHUNK FOLLOWING IT.  ^IN ADDITION, BIT 0 OF THE FIRST WORD
OF THE CHUNK IS SET AS A FLAG THAT THE CHUNK IS "FREE".
 ^A TASK OR INTERRUPT ROUTINE CAN OBTAIN CHUNKS FOR ITS USE FROM THE
FREE LIST, AND A TASK CAN RETURN CHUNKS TO THE FREE LIST.
^A TASK OR INTERRUPT ROUTINE CAN SEND CHUNKS TO A TASK, AND
A TASK CAN RECEIVE, IN THE ORDER SENT, CHUNKS SENT TO IT.
^IN ORDER TO ACCOMPLISH THIS, THE FIRST TWO WORDS OF A CHUNK
ARE RESERVED FOR A LINK WORD AND A LENGTH WORD.
^CHUNKS ARE USED INDIVIDUALLY TO STORE DATA RECEIVED FROM THE <>DQ11><'S
AND FROM THE <>PDP-10> THROUGH THE <>DL10> OR <>DTE20>.  
 ^FOR CONSTRUCTING TABLES, A NUMBER OF CONTIGUOUS CHUNKS CAN
BE OBTAINED FROM THE FREE LIST.
^THIS ABILITY IS USED TO CONSTRUCT
ALMOST ALL OF THE TABULAR DATA STRUCTURES, SUCH AS LINE CONTROL
BLOCKS, TASK CONTROL BLOCKS, ETC.
^IN THIS CASE, THE FIRST WORD OF THE FIRST CHUNK CONTAINS THE
LENGTH OF THE TABLE AND THE REST OF THE CHUNKS ARE CONSIDERED
PART OF THE TABLE, WITHOUT RESERVATION OF LINK OR LENGTH WORDS.
 ^IT IS POSSIBLE TO FREE A TABLE, BUT THE SUBROUTINE TO DO
THIS IS NOT USED ON THE <DN61 OR <DN64.
.HL 1 ^MESSAGES
 ^CHUNKS MAY BE COMBINED INTO MESSAGES.
^FOR THIS PURPOSE
CHUNKS ARE STRUNG TOGETHER BY THEIR LINK WORDS, AND EACH LENGTH
WORD INDICATES THE NUMBER OF MESSAGE CHARACTERS STORED IN THE CHUNK.
^THE FIRST CHUNK CONTAINS NO DATA; IT CONTAINS INFORMATION ABOUT
THE MESSAGE NEEDED FOR FURTHER PROCESSING, SUCH AS ITS TOTAL
LENGTH.  ^THE LAST CHUNK MAY NOT BE FULL IF THE MESSAGE
DOES NOT FIT EXACTLY IN THE CHUNKS PROVIDED.
^THE LAST CHUNK CAN BE RECOGNIZED BECAUSE ITS LINK WORD IS ZERO.
^IN ADDITION, IT IS POSSIBLE
FOR A MESSAGE TO HAVE SEVERAL EMPTY CHUNKS ALLOCATED TO ITS END
TO SIMPLIFY MESSAGE TRANSLATION.
^MESSAGES PRODUCED BY THE <>KMC11<> MAY HAVE ALL OF THEIR CHUNKS
LESS THAN COMPLETELY FULL TO DECREASE THE CHANCES OF THE <>KMC11<>
TRYING TO OVER-FILL ONE.
 ^MESSAGES MAY BE SENT FROM ONE TASK TO ANOTHER, AND A
TASK CAN RETRIEVE, IN ORDER, MESSAGES SENT TO IT.  ^THIS
ABILITY IS
USED TO SEND EXTRACTED DATA FROM THE <>BSC> TASK TO THE <>XLATE>
TASK,  TO SEND <>ASCII> DATA FROM THE <>XLATE> TASK TO THE <>DL10> OR <>DTE> TASK TO
BE PLACED IN <>PDP-10> MEMORY; AND TO SEND CONSTRUCTED MESSAGES
FROM THE <>XLATE> TASK TO THE <>BSC> TASK FOR OUTPUT.
^SOME SPACE IN THE FIRST CHUNK OF A MESSAGE
HAS BEEN RESERVED TO PROVIDE FOR
THE TRANSMITTING AND RECEIVING FUNCTIONS.
 ^THE CURRENT MESSAGE IS USUALLY POINTED TO BY <R0, BUT
<R0 IS OFTEN USED FOR OTHER PURPOSES.
.HL 1 ^LINE ^CONTROL ^BLOCKS
 ^THE LINE CONTROL BLOCK (<>LCB>)
IS BUILT FROM CHUNKS WHEN THE LINE
IS FIRST ENABLED BY A <PDP<-10 PROGRAM.
^IT IS THE ROOT OF THE DATA STRUCTURE FOR A PARTICULAR
<>DQ11> >SYNCHRONOUS> LINE.  ^THE <>LCB CONTAINS STATISTICAL
DATA FOR MONITORING LINE PERFORMANCE, "TRACKS" FOR
DEBUGGING THE <>DQ11><'S, AND POINTERS TO THE
<>BSC> AND <>XLATE> TASK CONTROL BLOCKS FOR PROCESSING DATA
TO AND FROM THIS LINE.
^THERE IS A <>GLOBAL<> TABLE CALLED "<>DQLCB>" WHICH POINTS TO
EACH LINE CONTROL BLOCK.
 ^THE CURRENT <>LCB> IS OFTEN POINTED TO BY <R4.
.HL 1 ^TASK ^CONTROL ^BLOCK
 ^AS WAS MENTIONED ABOVE, EACH LINE CONTROL BLOCK HAS
TWO TASK CONTROL BLOCKS: ONE FOR THE <>BSC> TASK AND ONE
FOR THE <>XLATE> TASK.  ^A TASK CONTROL BLOCK
REPRESENTS AN "INVOCATION" OF ONE OF THESE REENTRANT
TASKS.  ^THE TASK CONTROL BLOCK HOLDS THE INFORMATION 
SPECIFIC TO EACH INVOCATION: THE PROGRAM COUNTER,
A POINTER TO THE STACK, A POINTER TO THE LINE CONTROL
BLOCK, ETC.  ^IN A FRONT END WITH MORE THAN ONE >SYNCHRONOUS>
LINE, CONSIDERABLE SAVINGS IN PROGRAM STORAGE IS
ACHIEVED BY USING COMMON CODE TO DRIVE EACH LINE.
^ON A MACHINE WITH A FIXED MEMORY SIZE, DECREASED PROGRAM
STORAGE IS DIRECTLY TRANSLATED TO INCREASED DATA BUFFERING
AVAILABILITY, WHICH MEANS IMPROVED PERFORMANCE.
 ^THE <>TCB> OF THE CURRENT TASK IS ALWAYS POINTED TO BY <R5.
.HL 1 SILO
 ^WHEN READING DATA WITH THE HELP OF A <>KMC11<>, THE INPUT CHARACTERS
ARE PLACED IN A SILO.  ^EACH <>LCB<> HAS TWO SILOS, OF WHICH AT
MOST ONE IS ACTIVE.  ^A SILO POINTS TO THE CHUNK THAT IS BEING FILLED
AND HAS PROVISION FOR SIGNALING THE <>PDP-11<> WHEN THE NEXT
CHARACTER IS STORED (IN CASE THE PROCESS USING THE CHARACTERS IS
WAITING) AND FOR SIGNALING THE <>PDP-11<> WHEN THE SILO FILL POINT
HAS REACHED THE "WARNING LEVEL".  ^WHEN THIS WARNING LEVEL IS
REACHED THE <>PDP-11<> SWITCHES THE <>KMC11<> TO THE OTHER SILO
AND COMPLETES PROCESSING OF THE CHUNK POINTED TO BY THE OLD SILO.
^THE WARNING POINT IS SET SO THAT THE <>PDP-11<> WILL HAVE TIME
TO PERFORM THIS SWITCH BEFORE THE CHUNK IS FILLED TO CAPACITY,
SINCE IF IT IS FILLED THE <>KMC11<> IS FORCED TO DISCARD FURTHER
CHARACTERS.
.HL 1 REGISTER CONVENTIONS
 ^THERE ARE SOME "USUAL" REGISTER CONVENTIONS.  ^NO <CPU
TIME IS EVER WASTED IN MERELY CONFORMING TO THESE CONVENTIONS,
BUT WHEN THERE IS AN ARBITRARY CHOICE OF WHICH REGISTER
TO USE (AS IS ALMOST ALWAYS THE CASE), THE FOLLOWING
GUIDELINES ARE FOLLOWED:
.B 1;.LM +9;.TS 7;.I -9
<R0	POINTS TO THE CURRENT MESSAGE OR CHUNK
.I -9
<R1	CONTAINS THE CURRENT CHARACTER
.I -9
<R2	CONTAINS A CHARACTER COUNT
.I -9
<R3	POINTS TO THE <>CSR> FOR THE CURRENT <>DQ11<>/<>DUP11<>
OR TO THE CURRENT <>KMC11<> SILO
.I -9
<R4	POINTS TO THE CURRENT <>LCB>
.I -9
<R5	POINTS TO THE CURRENT <>TCB> (^WHEN IN A TASK, ALWAYS
POINTS TO THAT TASK'S <>TCB>.)
.I -9
<R6	ALWAYS POINTS TO THE CURRENT STACK
.B 1;.LM -9
^WHEN THE FUNCTION LISTED FOR A REGISTER IS NOT NEEDED,
THE REGISTER IS FREE TO BE USED FOR OTHER PURPOSES.
 ^IN A FEW "INNER LOOPS" THERE IS AN EXTENDED COMMENT
EXPLAINING REGISTER USAGE.  ^MAXIMUM USE IS MADE OF
REGISTERS IN THESE CASES FOR EFFICIENCY.

.CHAPTER PREFIX SECTIONS
 ^THE PREFIX SECTIONS ARE USED TO DEFINE SYMBOLS AND SET
PARAMETERS.  ^THEY ARE ASSEMBLED BEFORE THE CODE.  ^ONLY SECTION
<>DEFINE<> ALLOCATES ANY STORAGE.
.HL 1 SECTION "<>S<>"
 ^THE SECTION NAMED "<>S<>" CONTAINS DEFINITIONS FOR MANY
^DIGITAL ^EQUIPMENT ^CORPORATION PRODUCTS BUILT 
FROM THE SAME (OR SIMILAR) HARDWARE
BASE AS THE <>DN61> OR <>DN64>.  ^MANY OF THE DEFINITIONS HERE
ARE NOT USED BY THE <>DN60>.  "<>S<>" IS A CROSS-PRODUCT
FILE WHICH HAS BEEN EVOLVING SINCE THE <>DC76<>, SO DO NOT
ATTEMPT TO ASSEMBLE THE <>DN60> FRONT END SOFTWARE
WITH ANY COPY OF "<>S<>" OTHER THAN THE ONE SHIPPED WITH IT.
(^COMPARISON WITH OTHER VERSIONS MAY PROVE INTERESTING,
HOWEVER.)
 ^BECAUSE SECTION "<>S<>" IS A LIBRARY OF DEFINITIONS, IT
MAY SEEM TO IMPLY SUPPORT FOR, FOR EXAMPLE, A <>PDP-11/03<>;
THE OTHER SECTIONS, HOWEVER, ARE NOT WRITTEN IN AS MACHINE
INDEPENDENT A MANNER AS "<>S<>", WITH THE
RESULT THAT THE <>DN60> FRONT END
SOFTWARE IS SUPPORTED ONLY ON THE HARDWARE PROVIDED 
FOR IT BY
^DIGITAL ^EQUIPMENT ^CORPORATION.
.HL 1 SECTIONS "<>DN61D<>", "<>DN61S<>", "<>DN61B<>" AND "<>DN64A<>"
 ^SECTIONS "<>DN61D<>", "<>DN61S<>", "<>DN61B<>" AND "<>DN64A<>" SPECIFY
THOSE PARAMETERS WHICH HAVE DIFFERENT VALUES IN
VARIOUS VERSIONS
OF THE <>DN60>.  ^ONLY ONE OF THESE
SECTIONS IS ASSEMBLED FOR EACH PRODUCT.
^EVENTUALLY, OTHER SECTIONS WILL BE ADDED HERE:
"<>DN62B>", "<>DN62S>" AND "<>DN65A>" ARE CURRENTLY PLANNED.
.HL 1 SECTION "<>MACROS<>"
 ^THE "<>MACROS<>" SECTION IS A LIBRARY SIMILAR TO
"<>S<>".  ^IT IS SEPARATE SO THAT IT CAN BE CONDITIONALIZED
BASED ON "<>DN61D<>", "<>DN61S<>", "<>DN61B<>" AND "<>DN64A<>".
.HL 1 SECTION "<>DEFINE<>"
 ^THE "<>DEFINE<>" SECTION CONTAINS THE DEFINITIONS FOR THE
<>DN60> FRONT END SOFTWARE.  ^IT DEFINES PARAMETERS, DATA
STRUCTURES, THE LAYOUT OF THE <>DL10> WINDOW, AND THE
<>GLOBAL> STORAGE LOCATIONS.
^THE <>GLOBAL STORAGE LOCATIONS ARE AVAILABLE TO ALL
TASKS RATHER THAN DUPLICATED FOR EACH TASK.
^THE PARAMETERS ARE DEFINED SYMBOLICALLY ONLY FOR THE
PURPOSE OF MAKING THE READING OF THE PROGRAM EASIER;
THE ONLY SUPPORTED SETTINGS ARE THE ONES DISTRIBUTED.

.CHAPTER SECTION "<>MININT<>"
 ^THIS SECTION CONTAINS THE MINOR INTERRUPTS
AND MISCELLANEOUS SUBROUTINES.
.HL 1 MINOR INTERRUPTS
 ^THE MINOR INTERRUPTS ARE AS FOLLOWS:
.LIST
.LE;>^PARITY> ERROR
.LE;^BUS TRAP
.LE;^ILLEGAL INSTRUCTIONS, WHICH ARE:
^INVALID INSTRUCTIONS,
<IOT INSTRUCTION,
AND <EMT INSTRUCTION.
.LE;^TRACE TRAP:
<>BPT> INSTRUCTION
AND ^T-BIT TRAP.
.LE;^CLOCK
.LE;^POWER ^FAILURE
.LE;^UNKNOWN
.END LIST
 ^ALL OF THE MINOR INTERRUPTS EXCEPT CLOCK CAUSE AN ERROR
STOP.  (^SEE ^CHAPTER 18 ON DEBUGGING FOR MORE INFORMATION ON
THE ^T-BIT TRAP.)#
^THE CLOCK INTERRUPT IS COVERED IN ^CHAPTER 11, THE 
^DISPACHER CHAPTER.
.HL 1 MISCELLANEOUS
 ^SEVERAL MISCELLANEOUS SUBROUTINES, WHICH COULD NOT BE
REASONABLY CALSSIFIED AS BELONGING TO ANOTHER SECTION,
ARE HERE.  ^THESE INCLUDE ^T-BIT TRACING, CHUNK OWNERSHIP
RECORDING AND THE <KG11-A SIMULATOR.
^THE <>KG11-A SIMULATOR IS NEEDED ON THE <>DN64A
AND <>DN61B<> BECAUSE THE
<>DN20 CONFIGURATION DOES NOT INCLUDE A REAL <>KG11-A<>.

.CHAPTER SECTIONS "<>INIT1<>", "<>INITDQ<>", "<>INITUP<>" AND "<>INIT2<>"
 ^THESE SECTIONS CONSTITUTE THE INITIALIZATION CODE.
^ALTHOUGH THEY PERFORM ONLY ONE FUNCTION, THEY HAVE
BEEN DIVIDED INTO FOUR SECTIONS SO THAT <>INIT1<> CAN BE
OVERLAYED BY THE CHUNKS
AND TO PERMIT THE <>DQ11<>'S TO BE REPLACED BY <>DUP11<>'S
IN THE <>DN64A<> AND <>DN61B<>.  <>INIT1 AND <>INIT2 CONTAIN
THE PART
OF THE INITIALIZATION THAT IS DONE BEFORE CHUNKS ARE CREATED,
AND <>INIT2 CONTAINS THE CHUNK CREATION CODE AND THE PARTS
WHICH MUST BE DONE AFTER CHUNKS ARE CREATED.
.HL 1 <>INIT1
 <>INIT1 CONSISTS OF MESSAGE PRINTING AND A CALL TO <>CHK11<>.
^THE PURPOSE OF <>CHK11 IS TO VERIFY THAT THE HARDWARE
IS OPERATIONAL.  ^SEE ^CHAPTER 17 ON <>CHK11 FOR MORE
DETAILS.
.HL 1 <>INITDQ
 <>INITDQ CONSISTS OF A SUBROUTINE CALLED BY <>CHK11 TO
TEST THE <>DQ11<>'S.
.HL 1 <>INITUP
 <>INITUP CONSISTS OF TWO SUBROUTINES CALLED BY <>CHK11 TO
TEST THE <>DUP11<>'S AND <>KMC11<>'S.
^THIS SECTION REPLACES <>INITDQ<>
IN THE <>DN64A<> AND <>DN61B<>.
.HL 1 <>INIT2
 <>INIT2 CREATES THE CHUNKS, PUTS THEM ON THE
FREE LIST BY CALLING THE SUBROUTINE <>FRECHK WHICH RETURNS CHUNKS
TO THE FREE LIST,
AND CREATES ONE PERMANENT TASK CONTROL BLOCK FOR THE
<>IDLE<> TASK AND ONE FOR <>PDP-10> COMMUNICATION.
^FINALLY <>INIT2 INITIALIZES THE <>DL10> OR <>DTE20>,
WAITING AS LONG AS NECESSARY
FOR THE <>PDP-10> TO COME ON LINE, AND BRANCHES TO THE DISPATCHER,
WHICH WILL DISTRIBUTE TIME BETWEEN THE TASKS.  ^THE BRANCH
TO THE DISPATCHER IS DONE USING THE "<RTI" <>PDP-11>
INSTRUCTION TO SET THE <CPU PRIORITY LEVEL TO ZERO, THUS
ENABLING INTERRUPTS.

.CHAPTER SECTION "<>STGMAN<>"
 ^THE STORAGE MANAGEMENT SECTION CONSISTS OF A SET OF
SUBROUTINES WHICH MAY BE CALLED FROM ANY TASK OR FROM THE
INITIALIZATION CODE.  ^THESE SUBROUTINES MAY NOT BE CALLED
FROM AN INTERRUPT ROUTINE.  (^THE TECHNIQUE USED BY AN
INTERRUPT ROUTINE TO OBTAIN A CHUNK FROM THE FREE LIST
WILL BE DISCUSSED LATER.)
.HL 1 <>GETTCB>
 ^THIS SUBROUTINE ALLOCATES A TASK CONTROL BLOCK.
<>GETTCB IS USED BY INITIALIZATION (SEE ABOVE) AND WHEN A LINE
IS ENABLED FOR THE FIRST TIME.
^IT CONSISTS MOSTLY OF CALLS TO <>GETSTG> (SEE BELOW) AND
OF STORING LINKAGE POINTERS IN THE TASK CONTROL BLOCK.
^THIS IS A SUBROUTINE BECAUSE A TASK CONTROL BLOCK CONSISTS
OF TWO NON-CONTIGUOUS PARTS: THE <>TCB> ITSELF AND THE STACK.
.HL 1 <>GETSTG>
 ^THIS SUBROUTINE OBTAINS CONTIGUOUS SPACE
FROM FREE STORAGE.  ^IT WORKS BY SCANNING THE FREE
STORAGE LIST LOOKING FOR ENOUGH CONTIGUOUS FREE STORAGE TO
SATISFY THE REQUEST.  ^THE ALGORITHM IS COMPLICATED BY
TWO FACTORS:
.LIST
.LE;^TO SAVE TIME, THE FREE LIST IS NOT SORTED.
.LE;^INTERRUPT ROUTINES MAY OBTAIN A CHUNK AFTER THIS SUBROUTINE
DECIDES IT NEEDS IT BUT BEFORE IT GETS IT.
.END LIST
<>GETSTG> MUST THUS SCAN THE FREE LIST FOR THE CHUNK IT WANTS
AND BE PREPARED TO FREE ALL OF THE STORAGE IT HAS
OBTAINED AND TO TRY AGAIN IF IT MISSES A CHUNK.
.HL 1 <>FRESTG>
 ^THIS SUBROUTINE RETURNS A BLOCK OF STORAGE OBTAINED BY
<>GETSTG> TO THE FREE LIST BY BREAKING IT UP INTO CHUNKS AND
CALLING <>FRECHK>.
.HL 1 <>GETCHK>
 ^THIS SUBROUTINE GETS A CHUNK FROM THE FREE LIST.  ^UNLIKE
THE TRADITIONAL CALLING SEQUENCE FOR THIS SUBROUTINE, THIS
VERSION OF <>GETCHK> TAKES A PARAMETER: THE ADDRESS OF THE CHUNK
TO GET.  ^THIS PARAMETER IS FOR <>GETSTG>, WHICH WANTS A PARTICULAR CHUNK;
ALL OTHER CALLERS JUST GET THE ADDRESS OF A FREE CHUNK FROM
<>CHLST>, ONE OF THE <>GLOBAL<> CELLS.
 ^THE FREE LIST IS STRUCTURED AS A DOUBLY-LINKED LIST.
^CHUNKS ARE ON THE FREE LIST IN NO PARTICULAR ORDER.
^GLOBAL CELL <>CHFST> POINTS TO THE FIRST CHUNK AND
<>CHLST> POINTS TO THE LAST.
^AT LEAST ONE CHUNK IS ALWAYS ON THE FREE LIST.
 ^EVERY CHUNK ON THE FREE LIST HAS BIT 0 OF ITS FIRST
WORD SET SO THAT <>GETCHK> CAN DETECT THAT AN INTERRUPT
ROUTINE HAS TAKEN THE CHUNK IT IS WORKING ON.
.HL 1 <>FRECHK>
 ^THIS SUBROUTINE RETURNS A CHUNK TO THE FREE LIST.  ^IT
ALSO CLEARS THE CHUNK, SINCE IT IS CONVENIENT TO HAVE A JUST-GOTTEN
CHUNK BE CLEAR.
^BECAUSE CLEARING A CHUNK IS TIME CONSUMING, MOST FREEING
OF CHUNKS
IS DONE BY THE <>IDLE<> TASK.  ^OTHER TASKS PASS CHUNKS
TO BE FREED TO THE <>IDLE<> TASK.

.CHAPTER SECTION "<>QUEING<>"
 ^THIS SECTION CONTAINS SUBROUTINES TO SEND AND RECEIVE MESSAGES
AND INDIVIDUAL CHUNKS BETWEEN TASKS.
^A CHUNK CAN BE SENT BY AN INTERRUPT ROUTINE, BUT ALL
OTHER FUNCTIONS CAN BE PERFORMED ONLY BY TASKS.
.HL 1 <>QUEMSG>
 ^THIS SUBROUTINE SENDS A MESSAGE TO A SPECIFIED TASK.  ^A TASK
IS SPECIFIED BY ITS TASK CONTROL BLOCK, SINCE A SPECIFICATION
OF "THE <>BSC> TASK" WOULD BE AMBIGUOUS IF THERE WERE MORE THAN
ONE ENABLED LINE AND THEREFORE MORE THAN ONE INVOCATION OF
THE <>BSC> TASK.
.HL 1 <>DEQMSG>
 ^THIS SUBROUTINE OBTAINS FOR A TASK THE OLDEST MESSAGE SENT
TO IT.
.HL 1 <>DEQMID>
 ^THIS SUBROUTINE OBTAINS FOR A TASK THE OLDEST MESSAGE SENT
TO IT WHICH HAS A CERTAIN IDENTIFICATION.  ^THIS IS
USED BY THE <>DL10> TASK TO GET A MESSAGE FROM A PARTICULAR
LINE TO SATISFY A <>PDP-10> PROGRAM'S REQUEST
FOR DATA FROM A PARTICULAR LINE.  ^THIS IS NECESSARY BECAUSE
THERE IS ONLY ONE <>DL10> TASK (SINCE THERE IS ONLY
ONE <>DL10> OR <>DTE20>) AND ALL MESSAGES FOR THE <>PDP-10> MUST BE SENT
TO IT.
 ^NOTE THAT THE <>DL10 TASK DRIVES EITHER THE <>DL10
OR THE <>DTE20> DEPENDING ON WHICH IS PRESENT
IN THE CONFIGURATION.
.HL 1 <>QUECHK>
 ^THIS SUBROUTINE SENDS A CHUNK TO A TASK.  <>QUECHK CAN BE 
CALLED FROM AN INTERRUPT ROUTINE.  ^THE <>DQ11>
AND <>DUP11<> INTERRUPT
ROUTINES USE <>QUECHK TO SEND CHUNKS
CONTAINING RECEIVED DATA TO THE <>BSC> TASK.
.HL 1 <>DEQCHK>
 ^THIS SUBROUTINE OBTAINS FOR A TASK THE OLDEST CHUNK SENT
TO IT.  ^THE ALGORITHM IS COMPLICATED BY TWO FACTORS:
.LIST
.LE;^SUBROUTINE <>QUECHK> MAY BE CALLED BY AN INTERRUPT ROUTINE
TO PLACE A CHUNK ON A TASK'S LIST JUST AS THIS
SUBROUTINE IS TRYING TO GET A CHUNK OFF THE LIST.
.LE;^FOR EFFICIENCY, A CHUNK CONTAINS ONLY ONE LINK,
SO THE LIST CAN BE LINKED ONLY ONE WAY.
.END LIST

.CHAPTER SECTIONS "<>DQ11<>", "<>DUP11<>" AND "<>KMC11<>"
 ^THESE SECTIONS CONTAIN SUBROUTINES TO DRIVE THE <>DQ11>,
<>DUP11<> OR <>KMC11<>/<>DUP11<>.
^THEY ARE COVERED IN ONE CHAPTER BECAUSE THEY
SUBSTITUTE FOR ONE ANOTHER DEPENDING ON THE HARDWARE CONFIGURATION.
^MOST OF THE REST OF THE <>DN60 SOFTWARE IS UNAWARE OF THE
SUBSTITUTION.  ^FOR THIS REASON THEY HAVE THE SAME ENTRY POINTS.
 ^EACH SECTION CONTAINS DRIVER SUBROUTINES,
INTERRUPT SUBROUTINES,
MODEM STATUS SUBROUTINES, THE <>TRAPDQ<> SUBROUTINE,
THE "ONCE PER CLOCK
TICK" SUBROUTINE (NEEDED FOR HIGH-PERFORMANCE <>BSC>
INTERPRETATION ON A <>DQ11>),
AND THE CONTROL MESSAGES <>ACK-0<>, <>ACK-1<>, <>NAK<>, ETC_.
USED BY <>BISYNC<>.
^SEE ^CHAPTER 23 FOR MORE INFORMATION ON <BISYNC.
 ^THE THREE SECTIONS WILL BE DISCUSSED TOGETHER, WITH DIFFERENCES
POINTED OUT AS THEY OCCURR.
^THE PHRASE "LINE DRIVER" WILL BE USED TO REFER TO THE <>DQ11<>,
<>DUP11<> OR <>KMC11<>/<>DUP11<> AS APPROPRIATE.
.HL 1 DRIVING SUBROUTINES
 ^THE DRIVING SUBROUTINES ARE AS FOLLOWS:
.LIST
.LE;<>DQINIT - INITIALIZES THE LINE DRIVER.
.LE;<>DQREAD> - CONDITIONS THE LINE DRIVER FOR INPUT.
.LE;<>DQWRIT> - CONDITIONS THE LINE DRIVER TO OUTPUT A DATA MESSAGE.
.LE;<>DQCNTL> - CONDITIONS THE LINE DRIVER TO OUTPUT A CONTROL MESSAGE.
.LE;<>DQINWQ<> - CHECKS FOR MORE CHARACTERS TO BE PROCESSED.
.LE;<>DQKILL<> - TERMINATES ANY LINE DRIVER ACTIVITY.
.END LIST
 ^THESE SUBROUTINES ARE ALL HIGHLY DEVICE DEPENDENT.
^COMPLICATING THE OUTPUT-TYPE CALLS IS THE
POSSIBILITY THAT THE PROGRAM MUST WAIT A FEW MILLISECONDS
BETWEEN
THE RAISING OF THE REQUEST TO SEND SIGNAL AND THE START OF DATA SO
THAT THE <>IBM> EQUIPMENT CAN GET READY TO READ THE DATA.
^THIS IS DONE, WHEN REQUIRED, BY WAITING ONE OR MORE >JIFFIES>
AFTER ASSERTING
"REQUEST TO SEND" BEFORE BELIEVING "CLEAR TO SEND".  ^THUS,
IF THE >MODEM> DOES NOT PROVIDE THE REQUIRED DELAY, THE SOFTWARE
WILL, AND IF THE >MODEM> NEEDS A LONGER DELAY, THE SOFTWARE WILL
WAIT FOR IT.
 ^THE DELAY IS REQUIRED BECAUSE THE <IBM 360<'S CHANNELS ARE HALF-DUPLEX,
.INDEX <IBM 360
AND UNDER SOME OF <>IBM><'S OPERATING SYSTEMS THERE MAY BE A DELAY
OF SEVERAL MILLISECONDS BETWEEN THE TIME THE COMMUNICATIONS
ADAPTER FINISHES A WRITE AND THE TIME THE SOFTWARE INSTRUCTS
THE ADAPTER TO START THE READ.
^SOME <>IBM> SYSTEMS MAY NEED NO DELAY, SO THERE ARE PROVISIONS
TO START OUTPUTTING DATA AS SOON AS <>CTS> COMES UP, EVEN IF
THAT IS IMMEDIATELY.
 ^ON ZERO TURN-AROUND-TIME MODEMS THE <>DQ11<> IS GIVEN ITS
"READ" COMMAND WITHOUT WAITING FOR THE CARRIER SIGNAL,
TO AVOID MISSING THE FIRST CHARACTER OF A REPLY DUE TO
INTERRUPT OVERHEAD.
^THE <DUP11 IS ALWAYS GIVEN ITS "READ" COMMAND WITHOUT WAITING FOR
THE CARRIER SIGNAL BECAUSE SOME <>DUP11<>'S DON'T INTERRUPT
UPON TRANSITION OF THE CARRIER SIGNAL.
 ^IN THE <>KMC11<>/<>DUP11<>, WHEN THE WRITE IS COMPLETE THERE IS A
SPECIAL CASE CHECK FOR A READ, AND THE READ IS STARTED IMMEDIATELY
BY THE <>KMC11<> IF IT IS REQUESTED.
(^SEE ^CHAPTER 9 FOR MORE INFORMATION ON THE <>KMC11<> MICROCODE.)
 ^THE <>DQINWQ<> SUBROUTINE IS USED TO CHECK FOR MORE CHARACTERS
TO BE PROCESSED.  ^ON THE <>DQ11<>, THE HARDWARE REGISTERS ARE
CHECKED TO SEE IF THE CURRENT CHUNK HAS HAD UNPROCESSED CHARACTERS
STORED IN IT.  ^ON THE <>DUP11<>, SINCE IT GIVES AN INTERRUPT PER
CHARACTER, THERE ARE NEVER MORE CHARACTERS TO BE PROCESSED.
^ON THE <>KMC11<>/<>DUP11<>, THE SILO IS CHECKED FOR THE PRESENCE
OF UNWANTED CHARACTERS.
^IF WE ARE RUNNING SHORT OF <CPU TIME (WHICH CAN HAPPEN IF THE
LINE IS RUNNING FASTER THAN WE CAN PROCESS THE CHARACTERS)
WE WAIT FOR THE CHUNK TO FILL EVEN IF IT CONTAINS UNPROCESSED
CHARACTERS.
.HL 1 ^INTERRUPT ^ROUTINE
 ^THE INTERRUPT ROUTINE USES THE FOUR CONDITION CODE BITS IN
THE <PS TO SELECT AMONG THE TWELVE POSSIBLE LINE DRIVERS.
^THUS THE INTERRUPT ROUTINE IS COMMON TO
ALL THE LINES.  ^THIS ROUTINE DOES ERROR RECORDING, CHAINING
OF WRITES FROM CHUNK TO CHUNK OF A MESSAGE (EXCEPT WHEN
USING A <>KMC11<>) AND CHAINING
OF READS TO CHUNKS OBTAINED FROM THE FREE LIST.  ^MODEM
INTERRUPTS ARE ALSO PROCESSED BY THIS ROUTINE.
^THE ALGORITHM IS COMPLICATED BY THE DOUBLE BUFFERED
NATURE OF THE <>DQ11>; SINCE THE <>DQ11> CONTAINS NO >SILO>
(AS THE <>DV11<>, FOR EXAMPLE, DOES),
IT MUST HAVE A NEW BUFFER AVAILABLE
IMMEDIATELY WHEN IT FINISHES WITH AN OLD BUFFER.
^THIS MEANS THAT THE PROGRAM MUST ALWAYS STAY ONE BUFFER
AHEAD OF IT, SINCE A BUFFER INTERRUPT MEANS THAT THE
<>DQ11> HAS ONE BUFFER LEFT.
 ^THE <>DUP11 IS WORSE SINCE IT IS A CHARACTER-AT-A-TIME INTERRUPT
DEVICE RUNNING AT LOW PRIORITY.  ^THE INTERRUPT ROUTINE
MUST ALLOW OTHER <>DUP11<>'S TO INTERRUPT IN CERTAIN CASES
IN WHICH AN INTERRUPT TAKES A LONG TIME TO PROCESS.
 ^IN THE <>KMC11<>/<>DUP11<> MUCH OF THE WORK IS DONE BY THE <>KMC11<>
MICROPROCESSOR.
^THE <>KMC11<> PROVIDES TWO INTERRUPTS.  ^THE "^A" OR "<XX0"
INTERRUPT IS USED TO INFORM THE <>PDP-11<> OF A SILO CONDITION.
^A SILO CAN BE FLAGGED TO CAUSE AN INTERRUPT WHEN THE NEXT
CHARACTER IS STORED IN IT.  ^EVEN IF IT IS NOT SO FLAGGED
IT WILL CAUSE AN INTERRUPT WHEN IT REACHES THE WARNING LEVEL
AND WHEN IT IS ABOUT TO OVERFLOW.  ^THE INTERRUPT CODE GOES
THROUGH ALL THE SILOS PROCESSING ANY THAT NEED ATTENTION.
^THIS PROCESSING IS DONE BY SUBROUTINE <>MDSLEM<>, WHICH USUALLY
JUST UPDATES THE LENGTH FIELD IN THE CHUNK BEING FILLED SO THAT
THE <>BSC<> TASK CAN "SEE" THE NEW CHARACTER(S).  ^IF, HOWEVER,
THE CHUNK HAS BEEN FILLED TO ITS WARNING LEVEL, THEN A NEW CHUNK
IS OBTAINED AND THE SILO POINTER IS CHANGED SO THAT SUBSEQUENT
CHARACTERS WILL BE PLACED IN IT.
 ^THE "^B" OR "<XX4" INTERRUPT IS USED TO INFORM THE <>PDP-11<>
OF THE COMPLETION OF A WRITE OR KILL OPERATION, OR OF AN ERROR.
^AS FOR THE SILO INTERRUPT, THE INTERRUPT CODE SCANS THE <>LCB<>'S
AND PROCESSES EACH <>LCB<> WHICH IS MARKED AS "COMPLETE"
OR "KILL COMPLETE".
 ^THE <>GETCHK> SUBROUTINE CANNOT BE CALLED FROM AN INTERRUPT
ROUTINE; TO GET A CHUNK THE INTERRUPT CODE REMOVES A
CHUNK FROM THE FREE LIST BY EXECUTING THE SEQUENCE:
.B 1;.TS 9,17,25,33,41
^^
#	MOV	CHFST,R0	;FIRST CHUNK ON FREE LIST
.BREAK
#	CMP	R0,CHLST	;ONLY ONE CHUNK LEFT?
.BREAK
#	BEQ	ERROR		;YES, OUT OF CHUNKS
.BREAK
#	MOV	(R0),R1		;NO, GET NEXT CHUNK
.BREAK
#	BIC	_#1,R1		;ZAP FREE FLAG
.BREAK
#	MOV	R1,CHFST	;NEXT IS NOW FIRST CHUNK
.BREAK
#	CLR	(R0)		;CLEAR "FREE" BIT
.BREAK
#	#	#	#	;#AND FORWARD POINTER
.BREAK
#	CLR	2(R1)		;CLEAR BACK POINTER
.BREAK
#	DEC	CHFREC		;ONE FEWER FREE CHUNK
\\
.B 1
^R0 NOW CONTAINS A POINTER TO THE CHUNK OBTAINED FROM
THE FREE LIST.
.HL 1 SUBROUTINES FOR MODEM SIGNALS
 ^THREE SUBROUTINES ARE USED TO MANIPULATE MODEM SIGNALS:
.HL 2 <>DQDTR0<>
^THIS SUBROUTINE CLEARS ^DATA ^TERMINAL ^READY (<>DTR<>).
.HL 2 <>DQDTR1<>
^THIS SUBROUTINE SETS ^DATA ^TERMINAL ^READY (<>DTR<>).
.HL 2 <>DQMDMS<>
^THIS SUBROUTINE RETURNS THE VALUES OF <>DTR<> AND <>DSR<>.
.HL 1 <>TRAPDQ<>
 ^IF THE DEBUGGING ASSEMBLY-TIME SWITCH HAS BEEN SET, THIS
SUBROUTINE IS USED IN THE EVENT OF A FATAL ERROR TO STORE
THE <>DQ11<>'S OR <>DUP11<>'S REGISTERS IN THE LINE BLOCK (<>LCB<>).
^THIS INFORMATION CAN SOMETIMES BE VALUABLE FOR DEBUGGING.
.HL 1 ^ONCE A >^JIFFY>
 ^ONCE EACH CLOCK TICK (>JIFFY>) THE DISPATCHER CALLS
THE <>DQ11> SECTION TO FLUSH OUT ANY CHARACTERS THAT MIGHT BE
"CAUGHT" IN THE CURRENT RECEIVE BUFFER.  ^THIS IS NEEDED BECAUSE
A MESSAGE MIGHT BE VERY SHORT (FOR EXAMPLE, <>EOT>) AND
IF NO DATA ARRIVES AFTER THE MESSAGE ENDS (WHICH HAPPENS WITH
SOME MODEMS), A DELAY WOULD OCCUR FOR THE RECEIVER >TIMEOUT>
BEFORE PROCESSING OF THE MESSAGE COULD PROCEED.
^THUS, ONCE PER >JIFFY>,
ANY UNPROCESSED CHARACTERS IN THE CURRENT RECEIVE BUFFER ARE
MADE AVAILABLE TO THE <>BSC> TASK FOR PROCESSING.
 ^ON THE <>DUP11<> THIS SUBROUTINE MEARLY CHECKS THE MODEM SIGNALS
AND PROCESSES ANY TRANSITIONS WHICH MAY HAVE OCCURRED.  ^SINCE
THE <>DUP11<> INTERRUPTS FOR EACH CHARACTER THE <>BSC<> TASK
IS AWAKENED, IF NECESSARY, AT INTERRUPT LEVEL.
 ^ON THE <>KMC11<>/<>DUP11<>, THIS SUBROUTINE ALSO OPERATES
THE KEEP-ALIVE COUNTERS.
.HL 1 CONTROL MESSAGES
 ^THE CONTROL MESSAGES ARE THE FIXED MESSAGES USED BY <>BSC<>
TO ACKNOWLEDGE MESSAGES, REQUEST RETRANSMISSION,
DELAY, AND SO ON.

.CHAPTER SECTION "<>MDCODE<>"
 ^THE <>KMC11<> MICROCODE IS NOT INTENDED TO BE MAINTAINED
IN THE FIELD.  ^WE ARE NOT RELEASING ITS SOURCE CODE,
ASSEMBLER OR DEBUGGING TOOLS.
^IN THIS CHAPTER WE PRESENT ITS INTERFACE SPECIFICATIONS
AND FLOW OF CODE TO ASSIST IN THE UNDERSTANDING
OF THE <>KMC11<> DRIVER.
.TS 5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100
 ^THE <>KMC11 IS A <>UNIBUS COMPATIBLE GENERAL PURPOSE MICROPROCESSOR
WITH WRITABLE CONTROL STORE. ^IT IS USED TO REDUCE THE INPUT/OUTPUT
LOAD OF THE <>PDP-11 <CPU BY PUTTING CHARACTERS FROM
THE <>DUP11 INTO A SILO IN <>PDP-11 MEMORY AND OUTPUTING CHARACTERS
FROM "CHUNKS" IN THE <>PDP-11 TO THE <>DUP11<>. ^IT IS THE <>PDP-11 THAT
UNDERSTANDS THE <>BISYNC PROTOCOL AND NOT THE <>KMC11<>.
 ^THE <>KMC11 HAS 4 16-BIT REGISTERS WHICH ARE ON THE <>PDP-11 <>UNIBUS<>.
^SOME BITS IN <>SEL0 (THE FIRST REGISTER) ARE FOR MAINTENANCE FUNCTIONS.
^THE <>KMC11 DRIVER STORES IN <>SEL2 (THE SECOND REGISTER)
A POINTER TO THE <>KMC11 ^CONTROL ^BLOCK FOR THIS <>KMC11<>.
<>SEL4 AND <>SEL6 ARE UNUSED.
.HL 1 <>KMC11 CONTROL BLOCK
^THE <>KMC11 ^CONTROL ^BLOCK LOOKS AS FOLLOWS (ONE PER <>KMC11<>):
.SKIP 1
.LM +30
.TS 15,30
.INDENT -25;OFFSET	MEANING
.SKIP 1
.I -25;0	11 FLAGS	BIT 0 SET = <>PDP-11 RUNNING. ^SET ON STARTUP, CLEARED ON CRASH.
.BREAK
BIT 4 = ACTIVE TOGGLE
.BREAK
BITS 1-3 AND 5-15 UNUSED
.I -25;2	<KMC FLAGS	BIT 0 SET = <>KMC11 RUNNING
.BREAK
BIT 4 = ACTIVE RESPONSE
.BREAK
BITS 1-3 AND 5-15 = UNUSED
.INDENT -25;4	11-ALIVE	COUNTED BY THE <>PDP-11 ONCE A SECOND
.INDENT -25;6	<>KMC11 ALIVE	COUNTED BY THE <>KMC11 ONCE A SECOND
.INDENT -25;10	<>LCB 0	POINTER TO FIRST <>LCB
.INDENT -25;12	<>LCB 1	POINTER TO SECOND <>LCB
.INDENT -25;14	<>LCB 2	POINTER TO THIRD <>LCB
.INDENT -25;16	<>LCB 3	POINTER TO FOURTH <>LCB
.LM -30
.HL 1 LINE CONTROL BLOCK (<>LCB<>)
 ^THE FIRST WORD OF EACH LINE CONTROL BLOCK (<>LCB<>) HAS THE FOLLOWING
FLAGS:
.SKIP 1
.LM +15;.RM -5
.SKIP 1
.INDENT -10;BIT	MEANING
.SKIP 1
.INDENT -10;12	KILL COMPLETE (SET BY <>KMC11<>)
.INDENT -10;9	RECEIVER RUNNING
.INDENT -10;8	TRANSMITTER RUNNING
.INDENT -10;7	ERROR HAS BEEN DETECTED BY THE <>KMC11
.INDENT -10;4	TRANSMISSION IS OF A CONTROL MESSAGE
.INDENT -10;1	FUNCTION COMPLETE (SET BY <>KMC11<>)
.INDENT -10;0	KILL
.LM -15;.RM +5
 ^THE FOLLOWING OFFSETS INTO THE <>LCB ARE RELAVENT TO THE <>KMC11<>:
.SKIP 1
.LM +15;.RM -5
.INDENT -10;OFFSET	MEANING
.SKIP 1
.INDENT -10;4	ADDRESS OF <>DUP11<>'S <>CSR
.INDENT -10;10	POINTER TO DATA MESSAGE TO BE SENT
.INDENT -10;12	POINTER TO CONTROL MESSAGE TO BE SENT
.INDENT -10;14	LENGTH OF CONTROL MESSAGE TO BE SENT
.INDENT -10;16	POINTER TO INPUT SILO CONTROL BLOCK
.LM -15;.RM +5
.TEST PAGE 20
.HL 1 SILO CONTROL BLOCK (<>SCB<>)
 ^THE INPUT ^SILO ^CONTROL ^BLOCK (<>SCB<>) IS FORMATTED AS FOLLOWS:
.LM +30;.SKIP 1
.INDENT -25;OFFSET	MEANING
.SKIP 1
.INDENT -25;0	SILO FLAGS	BIT 0 SET = GIVE AN <XX0 INTERRUPT ON NEXT CHANGE OF THE SILO POINTER
.SUBINDEX <KMC11>^X^X0#INTERRUPT
.BREAK
BIT 1 SET = SILO FULL
.BREAK
BIT 2 SET = SILO HAS OVERFLOWED
.BREAK
BIT 4 SET = WARNING LEVEL REACHED
.BREAK
BIT 7 SET = <>KMC11 HAS FETCHED THE POINTERS BELOW
.INDENT -25;2	SILO POINTER	NEXT CHARACTER GOES HERE
.INDENT -25;4	SILO WARNING	GIVE THE <>PDP-11 AN <XX0 INTERRUPT
.SUBINDEX <KMC11>^X^X0#INTERRUPT
WHEN THIS IS REACHED AND SET BIT 4 IN THE SILO FLAGS
.INDENT -25;6	SILO LIMIT	MAXIMUM SIZE OF SILO. GIVE
THE <>PDP-11 AN <XX0 INTERRUPT WHEN THIS IS REACHED AND
.SUBINDEX <KMC11>^X^X0#INTERRUPT
SET BIT 1 IN THE SILO FLAGS.
.LM -30
.HL 1 <>KMC11 INTERRUPTS
 ^THE <>KMC11 WILL INTERRUPT THE <>PDP-11 FOR THE FOLLOWING REASONS:
.LM +15;.RM -5;.SKIP 1
.INDENT -10;VECTOR	REASON
.SKIP 1
.INDENT -10;<XX0	SILO NON-EMPTY
.SUBINDEX <KMC11>^X^X0#INTERRUPT
.INDENT -10;<XX4	FUNCTION COMPLETE
.SUBINDEX <KMC11>^X^X4#INTERRUPT
.INDENT -10;<XX4	ERROR
.SUBINDEX <KMC11>^X^X4#INTERRUPT
.LM -15;.RM +5
 ^BIT 4 OF 11-FLAGS CHANGING MEANS THAT THE <>PDP-11 HAS SOMETHING FOR
THE <>KMC11 TO DO.  ^THE ACTION IS SPECIFIED BY THE FIRST WORD OF THE
<>LCB<>; BIT 0 = KILL, BIT 8 = TRANSMIT, BIT 9 = RECEIVE. ^THE <>KMC11
MUST CHECK ALL FOUR <>LCB<>'S AND INITIATE THE SPECIFIED ACTION, THEN
COPY BIT 4 OF 11-FLAGS INTO BIT 4 OF <>KMC11 FLAGS.  ^IF MORE THAN
ONE BIT IS SET IN THE FIRST WORD OF THE <>LCB<>, ONLY THE FIRST ACTION
IS INITIATED.
 ^WHEN A WRITE OPERATION IS COMPLETE BIT 1 IS SET IN THE <>LCB STATUS AND
A CHECK IS MADE FOR BIT 9.  ^IF IT IS SET THEN START A RECEIVE IMMEDIATELY.
.TEST PAGE 30
.HL 1 FLOW OF <>KMC11 CODE
 ^THIS DESCRIPTION IS AN UPDATED VERSION OF THE ORIGINAL ^DETAILED
^DESIGN ^SPECIFICATION.  ^SOME OF THE STEPS IN THE ORIGINAL DESIGN
WERE FOUND TO BE UNNECESSARY; THESE ARE CALLED "REMOVED".
.TS 5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80
.TEST PAGE 20
.HL 2 SECTION ^A: ^INITIALIZATION
.LM +10
.SKIP 1
.INDENT -5;1.	^VERIFY THAT EACH LOCATION OF MEMORY CAN CONTAIN
ALL ONES AND ALL ZEROS.
.SKIP 1
.INDENT -5;2.	^WAIT FOR <>BSEL2 AND <>BSEL3 TO BE SET NON ZERO BY
THE <>PDP-11<>.
.SKIP 1
.INDENT -5;3.	^READ <>BSEL2 AND <>BSEL3 AGAIN WHICH IS THE ADDRESS
OF THE <>KMC11 ^CONTROL ^BLOCK IN <>PDP-11 MEMORY AND SAVE
A COPY IN "<>KMCCBA<>" IN <>KMC11 MEMORY.
.SKIP 1
.INDENT -5;4.	^TELL THE <>PDP-11 THAT THE <>KMC11 IS RUNNING BY
SETTING <>KF.RUN (BIT 0) IN THE <>KMC11 ^FLAGS WORD IN THE
<>KMC11 ^CONTROL ^BLOCK.
.SKIP 1
.INDENT -5;5.	^SET THE TIMER COUNTER (SCRATCH PADS <>SP.TCL AND
<>SP.TCH<>) TO 20.
.SKIP 1
.INDENT -5;6.	^ENTER THE <IDLE LOOP.
.LM -10
.TEST PAGE 20
.HL 2 SECTION ^B: ^IDLE ^LOOP
.SKIP 1
.LM +10
.I -5;1.	^LOOK AT THE ACTIVITY WORD IN EACH LINE BLOCK IN A
ROUND ROBIN MANNER. ^IF AFTER LOOKING AT ALL 4 LINES AND NONE OF THEM
WERE FLAGGED ACTIVE (BIT <>LA.ACT SET IN <>L.ACT<>) GO TO STEP 2. ^IF AN
ACTIVE LINE IS FOUND DO THE FOLLOWING:
.LM +5;.SKIP 1
.I -5;A.	^FETCH THE ACTIVITY WORD (<>L.ACT<>) FROM THE LINE BLOCK
AND IF BIT <>LA.XMT IS CLEAR FETCH THE <>DUP11 RECEIVER STATUS AND
IF BIT 7 IS SET (RECEIVER DONE) GO TO ^SECTION ^D. ^OTHERWISE GO TO
STEP 2.
.SKIP 1
.I -5;B.	^IF BIT <>LA.XMT IS SET FETCH THE <>DUP11 TRANSMIT STATUS
AND IF BIT 7 IS SET (TRANSMIT DONE) GO TO ^SECTION ^E.
.SKIP 1
.I -5;C.	^GO TO STEP 1.
.LM -5;.SKIP 1
.I -5;2.	^FETCH THE <>PDP-11 FLAGS FROM THE <>KMC11 ^CONTROL ^BLOCK
IN THE <>PDP-11<>. (^LAST <>NPR<>)
.SKIP 1
.I -5;3.	^IF THE <>PDP-11 FLAGS (BITS 0-7) HAVE CHANGED, GO
TO ^SECTION ^C.
.SKIP 1
.I -5;4.	^WAIT FOR THE 50 MICROSECOND TIMER TO SET IN
THE ^MISCELLANEOUS ^REGISTER.
.SKIP 1
.I -5;5.	^READ THE ^MISCELLANEOUS ^REGISTER AND IF <BUS <RQ
(BIT 7) IS SET GO TO STEP 9.
.SKIP 1
.I -5;6.	^IF THE <>KMC11<>'S "<BR CYCLE WANTED ON <XX0" FLAG
.SUBINDEX <KMC11>^X^X0#INTERRUPT
IS SET (<>SPF.X0 IN <>SP.FLG<>) SET <BUS <RQ IN THE ^MISCELLANEOUS
^REGISTER AND CLEAR <>SPF.X0 IN <>SP.FLG AND GO TO STEP 8.
.SKIP 1
.I -5;7.	^IF THE <>KMC11<>'S "<BR CYCLE WANTED ON <XX4" FLAG
.SUBINDEX <KMC11>^X^X4#INTERRUPT
IS SET (<>SPF.X4 IN <>SP.FLG<>) SET <BUS <RQ AND <XX4 IN THE ^MISCELLANEOUS
.SUBINDEX <KMC11>^X^X4#INTERRUPT
^REGISTER AND CLEAR <>SPF.X4 IN <>SP.FLG<>.
.SKIP 1
.I -5;8.	^IF EITHER OF THE <>KMC11<>'S "<BR CYCLE WANTED
ON <XX0 OR <XX4" FLAGS WERE SET GO TO STEP 1.
.SUBINDEX <KMC11>^X^X4#INTERRUPT
.SUBINDEX <KMC11>^X^X0#INTERRUPT
.SKIP 1
.I -5;9.	^DECREMENT THE DOUBLE PRECISION COUNTER CONTAINED
IN <>SP.TCH AND <>SP.TCL AND IF IT GOES TO ZERO GO TO ^SECTION ^F.
^OTHERWISE GO TO STEP 1.
.LM -10
.HL 2 SECTION ^C: <>PDP-11 ^FLAGS ^HAVE ^CHANGED
.SKIP 1
.LM +10

.I -5;1.	^FETCH THE <>PDP-11 FLAGS FROM THE <>KMC11 ^CONTROL
^BLOCK IN THE <>PDP-11<>. (^NOT LAST <>NPR<>)
.SKIP 1
.I -5;2.	^SAVE A COPY OF THE <>PDP-11 FLAGS IN A <SP.
.SK 1;.I -5;3.	^IF THE <>PDP-11 RUNNING BIT (BIT 0) IN THE <>PDP-11
FLAGS IS CLEAR GO TO ^SECTION ^G.
.SK 1;.I -5;4.	^IF THE ACTIVE TOGGLE BIT IN THE <>PDP-11 FLAGS IS THE
SAME AS THE ACTIVE RESPONSE BIT IN THE <>KMC11 FLAGS GO TO STEP 7.
.SK 1;.I -5;5.	^CHECK THE FOUR ^LINE ^CONTROL ^BLOCKS (<>LCB<>) IN
THE <>PDP-11 AS FOLLOWS:
.SK 1
.LM +5
.I -5;A.	^FETCH THE <>LCB POINTER FROM THE <>KMC11 ^CONTROL BLOCK
(^NOT LAST <>NPR<>)
.SK 1;.I -5;B.	^IF THE POINTER IS ZERO GO TO STEP 5J.
.SK 1;.I -5;C.	^SAVE A COPY OF THE <>LCB POINTER IN THE <>KMC11
^LINE ^BLOCK <>L.LCB SO THE <>LCB CAN BE REFERENCED WITHOUT HAVING
TO FETCH THE POINTER TO THE <>LCB FROM THE ^SILO ^CONTROL ^BLOCK
EACH TIME.
.SK 1;.I -5;D.	^FETCH THE <>LCB STATUS (^NOT LAST <>NPR<>)
.SK 1;.I -5;E.	^IF ^KILL WANTED (BIT 0) GO TO STEP 9.
.SK 1;.I -5;F.	^IF ^FUNCTION ^COMPLETE GO TO STEP 5J.
.SK 1;.I -5;G.	^IF THE LINE IS ACTIVE (BIT <>LA.ACT SET IN <>L.ACT<>) GO TO
STEP 5J.
.SK 1;.I -5;H.	^IF ^WRITE WANTED (BIT 8) GO TO STEP 15.
.SK 1;.I -5;I.	^IF ^READ WANTED (BIT 9) GO TO STEP 17.
.SK 1;.I -5;J.	^GO DO NEXT <>LCB<>. ^IF DONE ALL FOUR THEN STEP 6.
.LM -5

.SK 1;.I -5;6.	^COPY THE <>PDP-11 FLAGS BIT 4 INTO <>KMC11 FLAGS
BIT 4 AND STORE IN THE <>KMC11 ^CONTROL ^BLOCK. (^NOT ^LAST <>NPR<>)
.SK 1;.I -5;7.	^CLEAR BIT 1 OF <>KMC11 FLAGS AND STORE IN THE
<>KMC11 ^CONTROL ^BLOCK IN THE <>PDP-11<>.
.SK 1;.I -5;8.	GO TO <IDLE (^SECTION ^B)
.SK 1;.I -5;9.	[^HERE FOR KILL] ^IF ^KILL ^COMPLETE IS SET (BIT 12)
IN THE <>LCB STATUS GO TO STEP 5J.
.SK 1;.I -5;10.	^SET KILL COMPLETE (BIT 12) IN THE <>LCB STATUS WORD
IN THE <>PDP-11<>. (^LAST <>NPR<>)
.SK 1;.I -5;11.	^CLEAR <>SEND (BIT 4) IN THE <>DUP11 ^TRANSMIT ^STATUS
REGISTER IF <>LA.XMT IS SET IN <>L.ACT<>, OR CLEAR ^RECEIVER ^ENABLE
(BIT 4) IF <>LA.XMT IS CLEAR IN <>L.ACT<>.
.SK 1;.I -5;12.	^CLEAR THE ^ACTIVITY WORD <>L.ACT IN THE <>KMC11
^LINE BLOCK.
.SK 1;.I -5;13.	^FLAG THAT WE WANT A <BUS <RQ ON <XX4 BY
.SUBINDEX <KMC11>^X^X4#INTERRUPT
SETTING <>SPF.X4 IN <>SP.FLG<>.
.SK 1;.I -5;14.	^GO TO <IDLE (^SECTION ^B).
.SK 1;.I -5;15.	[^HERE IF ^WRITE ^WANTED] ^SETUP FOR ^DATA OR ^CONTROL
^MESSAGE BASED ON <>LCB STATUS BIT 4 AND FLAG THE LINE IS ACTIVE BY
SETTING <>LA.ACT IN <>L.ACT<>. ^IF THIS IS A ^CONTROL ^MESSAGE ALSO SET
<>LA.CM<>.
(^LAST <>NPR<>)
.SK 1;.I -5;16.	^GO TO <IDLE (^SECTION ^B).
.SK 1;.I -5;17.	[^HERE IF ^READ ^WANTED] ^SETUP FOR READING AND FLAG THE
LINE IS ACTIVE BY SETTING <>LA.ACT IN <>L.ACT<>.
(^LAST <>NPR<>)
.SK 1;.I -5;18.	^GO TO <IDLE (^SECTION ^B).
.LM -10
.TEST PAGE 20
.HL 2 SECTION ^D: ^RECEIVER ^DONE
.LM +10
.SK 1;.I -5;1.	^FETCH A CHARACTER FROM THE <>DUP11 ^RECEIVER ^BUFFER.
.SK 1;.I -5;2.	^IF THE ^ERROR BIT (BIT 15) IS SET GO TO STEP 20.
.SK 1;.I -5;3.	^IF THE <>KMC11 IS HOLDING A CHARACTER (<>LA.XME SET IN
THE ACTIVITY WORD <>L.ACT<>) FLAG THAT THE <>KMC11 IS NO LONGER HOLDING A
CHARACTER (IN <>L.CHR<>) AND GO TO STEP 4.  ^IF THE <>KMC11 IS NOT HOLDING
A CHARACTER STORE THE CHARACTER FETCHED FROM THE <>DUP11 IN THE LINE BLOCK IN THE <>KMC11 (IN <>L.CHR<>)
AND FLAG THE <>KMC11 IS HOLDING A CHARACTER (<>LA.XME SET IN <>L.ACT<>) AND
GO TO <IDLE (^SECTION ^B STEP 1.).
.SK 1;.I -5;4.	^FETCH THE POINTER TO THE INPUT ^SILO ^CONTROL ^BLOCK (<>SCB<>) FROM THE <>LCB<>,
AND SAVE THE POINTER IN <>KMC11 MEMORY.
(<>LCB POINTER WAS PUT IN <>KMC11 MEMORY <>L.LCB ON
ACTIVATION OF A READ.)
.SK 1;.I -5;5.	^FETCH A COPY OF THE SILO FLAGS FROM THE <>SCB<>,
AND IF THE SILO FULL BIT IS SET (BIT 1) GO TO STEP 19.
.SK 1;.I -5;6.	^IF THE <>KMC11 ALREADY HAS A COPY OF THE SILO POINTER,
WARNING LIMIT ADDRESS, AND END LIMIT ADDRESS (BIT 7 SET IN THE SILO FLAGS)
GO TO STEP 7. ^FETCH THE SILO POINTER, WARNING LEVEL ADDRESS, AND
END LIMIT ADDRESS AND STORE IN THE LINE BLOCK IN <>KMC11 MEMORY AND
SET BIT 7 IN THE SILO FLAGS INDICATING THE POINTERS HAVE BEEN
FETCHED.
.SK 1;.I -5;7.	^FETCH THE POINTER TO THE SILO FROM THE FROM THE LINE BLOCK IN THE <>KMC11<>.
.SK 1;.I -5;8.	^PUT IN THE <>KMC11<>'S ^OUTPUT <BA REGISTER.
.SUBINDEX <KMC11>^B^A#REGISTER
.SK 1;.I -5;9.	^INCREMENT THE SILO POINTER BY 2 AND STORE IN <>KMC11
MEMORY.
.SK 1;.I-5;10.	^STORE THE CHARACTER FETCHED FROM THE <>DUP11
AND THE SAVED CHARACTER FROM THE LINE BLOCK IN THE <>KMC11 IN THE SILO. (^NOT LAST <>NPR<>)
.SK 1;.I-5;11.	^STORE THE INCREMENTED SILO POINTER IN THE <>SCB<>.
(^LAST <>NPR<>)
.SK 1;.I -5;12.	^IF THE WARNING LEVEL REACHED BIT (BIT 4) IS SET IN
THE SILO FLAGS GO TO STEP 14.
.SK 1;.I -5;13.	^FETCH THE SILO WARNING LEVEL FROM THE LINE BLOCK IN THE <>KMC11 AND IF THE
POINTER EQUALS THE WARNING LEVEL SET BIT 4 AND GO TO STEP 16.
.SK 1;.I -5;14.	[^HERE IF PASSED THE WARNING LEVEL] ^FETCH THE END
LIMIT ADDRESS OF THE SILO FROM THE LINE BLOCK IN THE <>KMC11 AND IF THE POINTER EQUALS THE
END LIMIT ADDRESS, SET SILO FULL (BIT 1) AND GO TO STEP 16.
.SK 1;.I -5;15.	^IF THE <>PDP-11 DOESN'T WANT A <XX0 INTERRUPT (BIT 0
.SUBINDEX <KMC11>^X^X0#INTERRUPT
CLEAR) GO TO STEP 17.
.SK 1;.I -5;16.	^FLAG THAT WE WANT A <XX0 INTERRUPT BY SETTING
.SUBINDEX <KMC11>^X^X0#INTERRUPT
<>SPF.X0 IN <>SP.FLG AND CLEAR BIT 0 IN THE <>KMC11 COPY OF THE SILO FLAGS.
.SK 1;.I -5;17.	^IF THE <>KMC11<>'S COPY OF THE SILO FLAGS DIFFER
FROM THE SILO FLAGS FETCHED IN STEP 5, STORE THEM IN THE <>SCB<>.
(^LAST <>NPR<>)
.SK 1;.I -5;18.	^GO TO <IDLE. (^SECTION ^B)
.SK 1;.I -5;19.	[^HERE IF THE ^SILO IS FULL] ^SET BIT 2 IN THE
SILO FLAGS AND STORE IN THE <>PDP-11<>.
.SK 1;.I -5;20.	[^HERE TO ^KILL THE ^RECEIVER] ^CLEAR ^RECEIVER ^ENABLE
IN THE <>DUP11 ^RECEIVE ^STATUS REGISTER. (^NOT LAST <>NPR<>)
.SK 1;.I -5;21.	^ZERO THE ACTIVITY WORD FOR THE LINE. (<>L.ACT<>)
.SK 1;.I -5;22.	^SET <>KMC11 ^ERROR AND ^FUNCTION ^COMPLETE (BITS 1 AND 7)
IN THE <>LCB STATUS. (^LAST <>NPR<>)
.SK 1;.I -5;23.	^FLAG THAT WE WANT A <XX4 INTERRUPT BY SETTING
.SUBINDEX <KMC11>^X^X4#INTERRUPT
<>SPF.X4 IN <>SP.FLG<>.
.SK 1;.I -5;24.	^GO TO <IDLE (^SECTION ^B).
.LM -10
.TEST PAGE 20
.HL 2 SECTION ^E: ^TRANSMIT ^DONE
.LM +10
.SK 1;.I -5;1.	^IF THE TRANSMISSION IS ENDING (BIT <>LA.XME SET IN <>L.ACT<>)
GO TO STEP 25. ^IF THE DATA LATE BIT IS SET (BIT 15) GO TO ^SECTION ^D STEP 21.

.SK 1;.I -5;2.	^FETCH THE POINTER TO THE DATA IN THE CHUNK FROM
<>L.DPNT IN THE LINE BLOCK. (^INITIALLY IT WAS PUT THERE ON ACTIVITATION
OF A WRITE).
.SK 1;.I -5;3.	^IF THE POINTER POINTS TO AN ODD ADDRESS GO TO STEP 7.
.SK 1;.I -5;4.	^FETCH 2 CHARACTERS FROM THE CHUNK IN <>PDP-11 MEMORY
USING THE POINTER.
.SK 1;.I -5;5.	^SAVE THE CHARACTER IN THE HIGH BYTE (ODD ADDRESS) IN
THE LINE BLOCK (<>L.CHR<>).
.SK 1;.I -5;6.	^GO TO STEP 8.
.SK 1;.I -5;7.	^FETCH THE CHARACTER FROM THE LINE BLOCK (<>L.CHR<>)
.SK 1;.I -5;8.	^PUT THE CHARACTER IN THE <>DUP11 ^TRANSMIT ^BUFFER.
.SK 1;.I -5;9.	^INCREMENT THE <>KMC11<>'S COPY OF THE DATA
POINTER (<>L.DPNT<>).
.SK 1;.I -5;10.	^DECREMENT THE <>KMC11<>'S COPY OF THE DATA COUNT.
.SK 1;.I -5;11.	^IF THE COUNT WENT TO ZERO AND THIS WAS A ^CONTROL
^MESSAGE (BIT <>LA.CM SET IN <>L.ACT<>) GO TO STEP 21.
^IF THE COUNT DIDN'T GO TO ZERO GO TO STEP 17.
.SK 1;.I -5;12.	^FETCH THE <>KMC11 COPY OF THE POINTER TO
THE NEXT CHUNK (<>L.CPNT<>) AND IF ZERO GO TO STEP 21.
.SK 1;.I -5;13.	^FETCH THE POINTER TO THE NEXT CHUNK+1 AND SAVE A
COPY IN <>KMC11 MEMORY (<>L.CPNT<>).
.SK 1;.I -5;14.	^FETCH THE DATA COUNT FROM THE NEXT CHUNK AND IF
ZERO GO TO STEP 12.
.SK 1;.I -5;15.	^SAVE A COPY OF THE DATA COUNT IN <>KMC11 MEMORY (<>L.DCNT<>).
.SK 1;.I -5;16.	^SAVE A COPY OF THE POINTER TO THE DATA IN THE NEXT
CHUNK IN <>KMC11 MEMORY (<>L.DPNT<>).
.SK 1;.I -5;17.	^GO TO <IDLE (^SECTION ^B).
.SK 1;.I -5;18.	^REMOVED
.SK 1;.I -5;19.	^REMOVED
.SK 1;.I -5;20.	^REMOVED
.SK 1;.I -5;21.	[^HERE BECAUSE ^TRANSMISSION IS ^ENDING]
^SET <>TEOM (BIT 9) IN THE <>DUP11 ^TRANSMIT ^DATA ^BUFFER.
.SK 1;.I -5;22.	^CLEAR <>SEND (BIT 4) IN THE <>DUP11 ^TRANSMIT ^STATUS REGISTER.
.SK 1;.I -5;23.	^FLAG THE TRANSMISSION IS ENDING BY SETTING BIT
<>LA.XME IN <>L.ACT<>.
.SK 1;.I -5;24.	^GO TO <IDLE (^SECTION ^B).
.SK 1;.I -5;25. [^HERE BECAUSE TRANSMISSION HAS ENDED]
^SET ^FUNCTION ^COMPLETE
(BIT 1) IN THE <>LCB STATUS. (^NOT LAST <>NPR<>)
.SK 1;.I -5;26.	^IF A ^READ IS WANTED (BIT 9 SET <>LCB STATUS)
GO TO STEP 28.
.SK 1;.I -5;27.	^GO TO ^SECTION ^C STEP 13.
.SK 1;.I -5;28.	^SETUP FOR A ^READ BY CLEARING <>LA.XMT AND <>LA.CM
IN THE ACTIVITY WORD <>L.ACT<>.
.SK 1;.I -5;29.	^SET ^RECEIVER ^ENABLE IN THE <>DUP11 ^RECEIVE ^STATUS
REGISTER. (^LAST <>NPR<>)
.SK 1;.I -5;30.	^GO TO ^SECTION ^C STEP 13.
.LM -10
.TEST PAGE 20
.HL 2 SECTION ^F: ^TIMER HAS EXPIRED (USUALLY ONE SECOND)
.LM +10
.SK 1;.I -5;1.	^SET THE TIMER COUNTER TO 20000 (DECIMAL).
.SK 1;.I -5;2.	^REMOVED
.SK 1;.I -5;3.	^INCREMENT THE <>KMC11 ^ALIVE COUNTER IN <>KMC11 MEMORY,
AND STORE IN THE <>KMC11 ^CONTROL ^BLOCK.
.SK 1;.I -5;4.	^IF BITS 0, 1, AND 2 OF <KMC ALIVE ARE ALL 0, GO
TO STEP 7.
.SK 1;.I -5;5.	^REMOVED.
.SK 1;.I -5;6.	^GO TO ^SECTION ^B.
.SK 1;.I -5;7.	[^HERE EVERY 8 SECONDS] ^FETCH 11 ^ALIVE FROM
THE <>KMC11 ^CONTROL ^BLOCK.
.SK 1;.I -5;8.	^IF THE SAME AS LAST TIME (OLD VALUE STORED IN
<>KMC11 MEMORY) GO TO ^SECTION ^G.
.SK 1;.I -5;9.	^STORE THIS VALUE OF 11 ^ALIVE AS THE OLD VALUE
IN <>KMC11 MEMORY.
.SK 1;.I -5;10.	^GO TO <IDLE (^SECTION ^B)
.LM -10
.TEST PAGE 10
.HL 2 SECTION ^G: ^COME HERE WHEN SOMETHING IS ^WRONG
.LM +10
.SK 1;.I -5;1.	^CLEAR BIT 0 (<>KMC11 RUNNING) OF <>KMC11 FLAGS AND
STORE IN THE <>KMC11 ^CONTROL ^BLOCK. (^LAST <>NPR CYCLE)
.SK 1;.I -5;2.	^CLEAR BIT 7 IN <>BSEL1 AND BRANCH TO SELF.
.LM -10

.CHAPTER SECTION "<>MSGHDL<>"
 ^THIS SECTION CONTAINS SUBROUTINES WHICH MANIPULATE MESSAGES.
.HL 1 <>MSGGTC>
 ^THIS SUBROUTINE GETS A CHARACTER FROM THE INPUT STREAM.
<>MSGGTC IS
USED BY THE <>BSC> TASK TO GET A CHARACTER FROM THE DATA BEING
RECEIVED BY THE <>DQ11> OR <>DUP11<> INTERRUPT ROUTINE.
^IT INTERACTS WITH THE INTERRUPT ROUTINE AND THE ONCE
PER >JIFFY> SUBROUTINE TO KEEP DATA FLOWING TO THE
<>BSC> TASK.  ^THE SUBROUTINE WAITS IF NECESSARY 
FOR A CHARACTER FROM THE LINE.
^SEE ^CHAPTER 11 ON THE DISPATCHER FOR A DISCUSSION OF WAITING.
 ^IF THE INTERRUPT LEVEL DETECTS AN ERROR THE MESSAGE IS TRUNCATED.
.HL 1 <>MSGGTE>, <>MSGGTT>, AND <>MSGGT2
 ^THESE SUBROUTINES TERMINATE THE INPUT STREAM.
^THEY ARE CALLED
WHEN THE <>BSC> TASK RECOGNIZES THE END OF A MESSAGE OR A >TIMEOUT>.
.HL 1 <>MSGAPC>
 ^THIS SUBROUTINE APPENDS A CHARACTER TO A MESSAGE.
<>MSGAPC IS
CALLED BY THE <>BSC> TASK TO ASSEMBLE THE DATA PORTION OF A <>BSC>
MESSAGE FOR THE <>XLATE> TASK AND BY THE <>XLATE>
TASK TO BUILD A <>BSC> MESSAGE FOR THE <>BSC> TASK.
^THE REGISTER CONVENTIONS OF THIS SUBROUTINE AND <>MSGGTC>
HAVE BEEN ARRANGED TO MAKE THE <>BSC> TASK EFFICIENT.
^THIS SUBROUTINE WILL ALLOCATE CHUNKS AND APPEND THEM TO THE
MESSAGE, IF NECESSARY, AND WILL OBSERVE PRE-ALLOCATED
CHUNKS.
.HL 1 <>MSGAPE>
 ^THIS SUBROUTINE RETURNS ANY UNUSED PRE-ALLOCATED CHUNKS
FROM A MESSAGE.  <>MSGAPE IS CALLED BY THE <>XLATE> TASK
WHEN A MESSAGE IS COMPLETE.

.CHAPTER SECTION "<>DISPAT<>"
 ^THIS SECTION IS THE DISPATCHER.  ^ITS FUNCTION IS TO ALLOCATE TIME
AMONG THE TASKS.  (^TIME IS GIVEN TO THE INTERRUPT
ROUTINES INDEPENDENTLY BY MEANS OF HARDWARE INTERRUPTS.)
 ^THIS SECTION HAS TWO ENTRY POINTS: <>DISPATCH<> AND <>WAIT<>.
.HL 1 <>DISPATCH<>
 ^THIS ENTRY POINT IS USED AFTER INITIALIZATION TO START UP THE
DISPATCHER AND AFTER <>WAIT<> HAS FINISHED PROCESSING
TO RESTART THE DISPATCHER.  ^THE TASK CONTROL BLOCKS ARE
SCANNED IN PRIORITY ORDER; THE HIGHEST PRIORITY,
NON-BLOCKED TASK IS GIVEN CONTROL OF THE <CPU.
^IF A TASK IS BLOCKED SOME TESTS ARE MADE TO SEE IF THE DISPATCHER
CAN UNBLOCK IT.  ^THESE ARE TESTS ON <>GLOBAL<> VARIABLES.
^NORMALLY A TASK IS UNBLOCKED BY ANOTHER TASK OR BY THE TIMER.
^IF ALL TASKS ARE IDLE THE DISPATCHER CHECKS THE LINE FREQUENCY
CLOCK AND, IF IT HAS TICKED, DOES THE ONCE-A->JIFFY> 
FUNCTIONS.  ^THESE ARE:
.LIST
.LE;^UPDATE EACH WAITING TASK'S TIMER.
.LE;^DO THE ONCE-A->JIFFY> LINE DRIVER FUNCTIONS 
(SEE CHAPTER 8)
.LE;^DO THE ONCE-A->JIFFY> <>DL10> OR <>DTE20> FUNCTIONS
(SEE CHAPTERS 13 AND 14)
.LE;^ONCE A SECOND:
.LIST
.LE;^IF WE HAVE A <>DL10> OR <>DTE20>, DO THE ONCE-A-SECOND 
<>DL10> OR <>DTE20> FUNCTIONS
(SEE CHAPTERS 13 AND 14)
.LE;^OTHERWISE, TRY TO BRING THE <>DL10> OR <>DTE20> ON LINE.
.END LIST
.END LIST
 ^IF THE DISPATCHER DOESN'T GET ANY IDLE TIME FOR ABOUT TWO
SECONDS, THE CLOCK INTERRUPT (BACK IN THE <>MININT> SECTION)
WILL INDICATE A FATAL ERROR.  ^SIMILARLY, IF THE CLOCK
DOESN'T TICK FOR A LONG WHILE (MEASURED IN DISPATCHER IDLE
CYCLES), THE DISPATCHER WILL INDICATE A FATAL ERROR.
^IN THIS WAY THE CLOCK KEEPS WATCH OVER THE TASKS, AND THE
DISPATCHER KEEPS WATCH OVER THE CLOCK.
^NOTE, HOWEVER, THAT A LARGE INCREASE OR DECREASE IN <CPU
SPEED COULD CAUSE AN ERROR TO BE DETECTED FALSELY.  ^IF
THE <CPU IS VERY FAST, THE DISPATCHER WILL GET TOO MANY
IDLE CYCLES AND WILL THINK THE CLOCK HAS STOPPED.  ^IF THE <CPU
IS VERY SLOW, A TASK WHICH OUGHT TO TAKE A SHORT TIME MAY TAKE
SO LONG THAT THE CLOCK INTERRUPT CODE WILL THINK THAT
THE TASK IS LOOPING.
.HL 1 <>WAIT
 ^THE <>WAIT<> ENTRY POINT IS USED BY A TASK TO WAIT FOR AN
EVENT TO OCCUR.  ^THE TASK INDICATES IN ITS <>TCB> THAT IT
IS BLOCKED AND INDICATES THE EVENT OR EVENTS IT IS WAITING
FOR.  ^THE CALL TO <>WAIT<> CAUSES THE TASK'S <PC TO BE
SAVED IN THE <>TCB> AND THE TASKS TO BE SCANNED AS DESCRIBED
ABOVE FOR THE HIGHEST PRIORITY UNBLOCKED TASK.
^NOTE THAT THE TASK'S REGISTERS ARE NOT SAVED, EXCEPT FOR
ITS STACK POINTER.  ^THUS, IF A TASK NEEDS TO SAVE
ANY REGISTERS OVER THE CALL TO <>WAIT<>, IT MUST PUSH
THEM INTO THE STACK.
^WHEN ONE OR MORE OF THE EVENTS SPECIFIED IN THE <>TCB>
HAPPEN, THE TASK IS UNBLOCKED AND
THE DISPATCHER WILL EVENTUALLY FIND IT AND RUN IT.
^WHEN A TASK IS RUN, ^R5 POINTS TO ITS <>TCB>, ^R6
IS RESTORED TO THE STATE AS OF THE LAST CALL TO <>WAIT<>
AND ^R0 THROUGH ^R4 ARE UNDEFINED.
 ^NOTE THAT THE REQUIREMENT THAT A TASK MUST CALL <>WAIT<>
BEFORE ANOTHER TASK WILL RUN MAKES THIS A "NON-PREEMPTIVE"
SCHEDULER.  ^THIS DECREASES THE REAL-TIME RESPONSE, BUT
GREATLY SIMPLIFIES THE CODING OF THE TASKS, SINCE THE
SHARED DATA STRUCTURES CAN BE MANIPULATED
WITHOUT FEAR THAT ANOTHER TASK WILL TAKE CONTROL AWAY
FROM THE MANIPULATING TASK WHILE THE DATA STRUCTURE
IS IN AN INTERMEDIATE STATE.
.HL 1 T-BIT - RTI INSTRUCTION
 ^BECAUSE A TASK MAY BE RUNNING WITH THE ^T-BIT SET (SEE 
^CHAPTER 18 ON DEBUGGING) <>WAIT AND <>INIT2 BRANCH TO THE
DISPATCHER BY USING THE <RTI INSTRUCTION.  ^THIS INSTRUCTION
BOTH LOWERS THE PRIORITY LEVEL OF THE <CPU TO 0 AND
CLEARS THE ^T-BIT.  ^THIS IS THE SAFEST WAY TO CLEAR THE
^T-BIT, SINCE SOME <>PDP-11> MODELS HAVE RESTRICTIONS ON
DIRECT MANIPULATION OF THE <PS REGISTER.
 ^TO SET THE PRIORITY OF THE <CPU PROPERLY AND SET THE ^T-BIT,
IF REQUIRED, THE DISPATCHER BRANCHES TO A TASK USING THE
<RTI INSTRUCTION.

.CHAPTER SECTION "<>BSC<>"
 ^THIS SECTION CONTAINS THE <>BSC> (OR <>BISYNC>) TASK.
^THIS TASK USES THE LINE DRIVER SUBROUTINES TO COMMUNICATE WITH
AN <>IBM><-COMPATIBLE <>BSC> DEVICE, POINT-TO-POINT.
^MANY ERROR AND STATISTICAL COUNTERS ARE KEPT.
^COMMUNICATION WITH THE TRANSLATE TASK IS BY SENDING AND
RECEIVING MESSAGES AND BY CHANGING AND OBSERVING STATUS
BITS IN THE TASK CONTROL BLOCK.
 ^THIS SECTION IS DIVIDED INTO FOUR PARTS: ^CONTROL,
^OUTPUT, ^INPUT AND ^SUBROUTINES.
.HL 1 ^CONTROL
 ^THE CODE IMPLEMENTING THE CONTROL FUNCTIONS OF <>BSC>
EXTENDS FROM THE LABEL <>DQDRVR> TO, BUT NOT INCLUDING,
THE LABEL <>DQXMIT>.
^FOR <>HASP ^MULTILEAVING> THE CONTROL STARTS AT THE SAME PLACE 
BUT BRANCHES OFF TO <>HSPLIN> FOR <HASP LINES. 
.HL 2 <>HASP> ^CONTROL
^THE <HASP ^MULTILEAVING CONTROL SECTION ALSO STARTS AT 
<>DQDRVR>, SKIPS OVER THE <IBM 3780 PART ALL THE WAY TO 
<>HSPLIN>, AND ENDS BEFORE <>HSRECV> LABEL. 
^THE <HASP BID SEQUENCE IS <SOH-ENQ AND IS DIFFRENT FROM THE 
<IBM 3780/2780 BIDS. ^THE LINE ONCE BID REMAINS SO AND THE 
<DECSYSTEM-10/20 WILL MAINTAIN COMMUNICATIONS BY TRANSMITTING 
AN <>ACK0> MESSAGE EVERY 2 SECONDS. ^INITIALLY IF THE RESPONSE 
TO BID WAS AN <>ACK0>, <DN62 CAN START SENDING SENDING DATA 
STARTING AT <>HPXMIT>. ^HOWEVER IF THE RESPONSE TO 
THE BID WAS ANOTHER BID, <>DN62> WILL SEND AN <>ACK0> AND THE
REMOTE HAS THE CHOICE OF SENDING DATA OR <>ACK0> 
AS THE REQUIREMENTS MAY BE. ^THE RECEIVE DATA ROUTINE BEGINS 
AT <>HSRECV>. 
.HL 2 <>IBM 3780/2780> ^CONTROL
^THIS SUBSECTION SENDS AND RECEIVES THE <>BSC> "BID" 
MESSAGE, AND BRANCHES TO ^INPUT OR ^OUTPUT AS REQUIRED.
^IT IS IN THE FORM OF A LOOP WHICH BIDS IF REQUIRED
AND THEN LISTENS FOR A RESPONSE.  ^IF THE RESPONSE IS
AN ACKNOWLEDGMENT OF THE BID, THEN IT CALLS THE
OUTPUT SUBROUTINE, <>DQXMIT>.  ^IF THE RESPONSE
IS ANOTHER BID, THEN IT CALLS THE INPUT SUBROUTINE, <>DQRECV>.
 ^PLEASE RECOGNIZE THAT THIS IS A SIMPLIFIED DESCRIPTION.
^MORE DETAILS ARE AVAILABLE IN THE LISTING.
.HL 1 ^OUTPUT
 ^THE OUTPUT SUBSECTION IS THE SUBROUTINES
<>DQXMIT>, <>DQXRSP>, AND <>DQXNAV>.
.HL 2 <>DQXMIT>
 ^THIS SUBROUTINE SENDS MESSAGES >QUEUED> TO IT FROM THE
TRANSLATE TASK.  <>DQXMIT RETURNS WHEN ALL THE MESSAGES HAVE
BEEN SENT OR WHEN THERE HAS BEEN AN UNRECOVERABLE ERROR.
^THE TRANSLATE TASK HAS BUILT THE OUTPUT MESSAGES TO HAVE THE
PROPER FORM FOR THE <>DQ11> OR <>DUP11<>,
SO THE <>BSC> TASK HAS NO NEED TO
MANIPULATE THEM.
.HL 2 <>DQXRSP>
 ^THIS SUBROUTINE IS USED BY <>DQXMIT> TO READ THE RESPONSE TO
A TRANSMITTED MESSAGE.  ^IF THE OTHER COMPUTER LIKED THE
MESSAGE, IT WILL RESPOND WITH POSITIVE ACKNOWLEDGE.  ^IF IT
DIDN'T LIKE IT, THEN THE OTHER COMPUTER WILL
RESPOND WITH NEGATIVE ACKNOWLEDGE.
^IT IS POSSIBLE FOR THE OTHER COMPUTER TO MISS THE
MESSAGE ENTIRELY, IN WHICH CASE THERE IS NO RESPONSE.
 ^IF THE OTHER COMPUTER LIKED THE MESSAGE BUT HAS NO
ROOM FOR ANY MORE MESSAGES, IT WILL RESPOND WITH WAIT
ACKNOWLEDGE.  ^IN THIS CASE THE OTHER COMPUTER MUST BE POLLED
OCCASIONALLY TO SEE WHEN IT IS READY.
.HL 2 <>DQXNAV>
 ^THIS SUBROUTINE IS CALLED BY <>DQXMIT> WHEN THERE IS NO DATA
TO SEND.  <>DQXNAV> DETERMINES IF THIS IS DUE TO THE MESSAGE
STREAM BEING >ABORT>ED OR ENDED AND RETURNS IF THIS IS THE
CASE.  ^OTHERWISE IT SENDS A SPECIAL MESSAGE TO THE
OTHER COMPUTER INDICATING THAT NO DATA EXISTS FOR IT AS YET.
^THE OTHER COMPUTER WILL RESPOND WITH A NEGATIVE 
ACKNOWLEDGE, AND THE POSSIBILITY OF ADDITIONAL MESSAGES
TO BE SENT CAN THEN BE CONSIDERED.
.HL 1 ^INPUT
 ^THE INPUT SUBSECTION IS COMPRISED OF SEVERAL SUBROUTINES
LISTED BETWEEN <>DQRQIP> AND <>DQRBCC>.  ^ONLY THE MOST IMPORTANT
OF THESE ARE DISCUSSED HERE.
.HL 2 <>DQRQIP>
 ^THIS SUBROUTINE IS CALLED BY THE ^CONTROL CODE TO SEE IF
THE <>PDP-10> WILL ALLOW THE OTHER COMPUTER TO SEND DATA TO IT.
.HL 2 <>DQRECV>
 ^THIS SUBROUTINE RECEIVES A STREAM OF MESSAGES FROM THE
OTHER COMPUTER.  ^IT RETURNS WHEN THE STREAM IS ENDED EITHER BY THE
END-OF-FILE SEQUENCE OR BY BEING >ABORT>ED.
.HL 2 <>DQRPRP>
 ^THIS SUBROUTINE IS USED BY <>DQRECV> TO ACKNOWLEDGE A MESSAGE.
.HL 2 <>DQRNRP>
 ^THIS SUBROUTINE IS USED BY <>DQRECV> TO NEGATIVELY
ACKNOWLEDGE A MESSAGE.  ^THIS WILL USUALLY CAUSE IT TO BE
SENT AGAIN.
.HL 2 <>DQRNRM>
 ^THIS SUBROUTINE IS USED BY <>DQRECV> TO PROCESS A
NORMAL (NON->TRANSPARENT>) MESSAGE.  <>DQRNRM<> WATCHES
FOR "<>ETX>" AND "<>ETB>" TO END THE MESSAGE AND
CHECKS AND REMOVES BLOCK CHECKING CHARACTERS.
.HL 2 <>DQRXPM>
 ^THIS SUBROUTINE IS USED BY <>DQRECV> TO PROCESS A >TRANSPARENT>
MESSAGE.  ^IT SERVES THE SAME PURPOSES AS <>DQRNRM>, BUT IT MUST WORK
A BIT HARDER, BECAUSE IT MUST ALSO STRIP
THE <>DLE> CHARACTERS.
.HL 2 <>DQRBCC>
 ^THIS SUBROUTINE IS USED BY <>DQRNRM> AND <>DQRXPM> TO READ
THE <>BCC> SEQUENCE WHICH FOLLOWS EACH MESSAGE.  ^SOMETIMES
<>DQRBCC<> IS ALSO USED TO READ AN "INTERMEDIATE <>BCC>".
.HL 1 ^SUBROUTINES
 ^THE FOURTH SUBSECTION CONTAINS THE SUBROUTINES USED BY
THE CODE DESCRIBED ABOVE.  ^THE MOST IMPORTANT
SUBROUTINES ARE DESCRIBED.
.HL 2 <>CTLMSG>
 ^THIS SUBROUTINE SENDS A CONTROL MESSAGE SUCH AS <>ACK-0<> OR
<>NAK> AND INITIATES A READ FOR THE RESPONSE, UNLESS
REQUESTED NOT TO.
.HL 2 <>STOBCC>
	 ^THIS SUBROUTINE STORES THE ACCUMULATED <>BCC> INTO
A MESSAGE.
.HL 2 <>DQABRO>
 ^THIS SUBROUTINE >ABORT>S THE OUTPUT STREAM.
.HL 2 <>DQABRI>
 ^THIS SUBROUTINE >ABORT>S THE INPUT STREAM.
.HL 2 <>DQSEOT>
 ^THIS SUBROUTINE CONDITIONALLY SENDS THE "<>EOT>"
CONTROL MESSAGE.
^IT DOES NOT READ ANY RESPONSE.
.HL 1 <HASP ^MULTILEAVING
 ^THE FOLLOWING SECTIONS DESCRIBE THE SUBROUTINES USED 
BY THE <HASP ^MULTILEAVING PROTOCOL FOR DOING INPUT AND OUTPUT. 
^THE INPUT AND OUTPUT ARE INTERLEAVED. ^A DATA MESSAGE MAY BE 
POSITIVELY ACKNOWLEDGED BY SENDING DATA OR AN <>ACK0>. 
^THE MESSAGES MAY BE IN THE FORM OF DATA LESS RECORDS AND MAY INDICATE A REQUEST TO TRANSMIT A FILE, PERMISSION 
TO TRANSMIT A FILE, SIGNON, OR A BLOCK SEQUENCE ERROR. ^THERE CAN ALSO BE STATUS-ONLY BLOCKS WHICH INDICATE WHETHER THE TRANSMITTING STATION 
IS ABLE TO RECEIVE DATA RECORDS AND IF READY, ON WHICH DEVICES. 
THESE KIND OF BLOCKS MAY BE USED TO SLOW DOWN THE DATA TRANSMISSION TO ITSELF. ^THE "INFORMATION" PART OF THE BLOCK MAY APPEAR AFTER THE 
STATUS (<>FCS>) BYTES IN THE FORM OF DATA RECORDS WITH SOURCE 
OR DESTINATION INFORMATION (<>RCB> AND <>SRCB>). ^EACH DATA 
RECORD MAY HAVE A SERIES OF COMPRESSED DATA CONTROLS (<>SCB>).  
^THE <>RCB> DEFINES THE SOURCE OR DESTINATION AND <>SRCB> MAY 
HAVE CARRIAGE CONTROL INFORMATION OR INDICATION THAT A RECORD 
IS IN BINARY MODE. 
 ^THE POSITIVE ACKNOWLEDGEMENT IS USED WHEN PRECEDING BLOCK TRANSMISSION IS ACCEPTABLE. ^THE STATUS ONLY BLOCK MAY ALSO BE USED AS MAY THE 
STATUS-DATA BLOCK TO INDICATE POSITIVE RESPONSE. 
^THE CURRENT RELASE SUPPORTS RECEPTION OF DATA IN 
TRANSPARENT AND NON-TRANSPARENT MODE. ^THE OUTPUT IS 
ALWAYS IN NON-TRANSPARENT MODE. 
.HL 1 <HASP <INPUT
 ^THE INPUT SECTION COMPRISES OF VARIOUS SUBROUTINES WHICH 
ALSO OVERLAP WITH OUTPUT SUBROUTINES IN THEIR FUNCTIONALITY.
^THE MAJOR RECEIVE ROUTINES ARE <>HSRECV>, <>HSPXM5>, 
<>HSARSP> AND THEY ARE DESCRIBED WITH OTHER HELPER ROUTINES. 
.HL 2 <>HSRECV>
 ^THIS SUBROUTINE CHECKS FOR ENOUGH (30.) CHUNKS AND GOES TO 
<>HSPXM5> TO READ THE INCOMING DATA. ^SHORTAGE OF CHUNKS WILL 
RESULT IN SUSPENDING THE INCOMING STREAMS FROM THE REMOTE. 
.HL 2 <>HSPXM5>
 ^THIS SUBROUTINE CALLS <>HSARSP> TO READ THE DATA COMING IN 
ON THE BISYNC LINK. ^THIS COULD BE RESPONSE TO TRANMITTED 
MESSAGE. ^AN <>ACK0> OR "GOOD" DATA MAY BE 
CONSIDERED AS POSITIVE ACKNOWLEDGEMENT TO TRANSMITTED DATA. 
^IN TURN, DATA OR <>ACK0> MAY BE SENT TO THE REMOTE TO 
ACKNOWLEDGE HIS DATA. ^THUS THEIR IS A TWO WAY DATA 
TRANSFER THOUGH ONLY IN ONE DIRECTION AT A TIME. 
.HL 2 <>HSARSP> 
 ^THIS SUBROUTINE PERFORMS MOST OF THE VITAL ROLE OF 
RECEIVING THE DATA AND ANALYSING IT AND THEN REPORTING IT TO 
<>HSPXM5>. ^ALL <>NAKS>, <>ACK0>, TRANSPARENT TEXT AND 
SPECIAL REQUESTS ARE <HANDLED BY CALLING <HSRXPM. 
.HL 2 <>HSRXPM> 
 ^THIS SUBROUTINE RECEIVES DATA WHICH IS MORE THAN <>ACK0> AND <>NAK>. 
^IT RECOGNIZES SPECIAL RECORDS FOR DEVICE REQUEST, DEVICE PERMISSION 
GRANTED, <BCB ERROR AS WELL AS DATA FOR THE INPUT MODE 
DEVICES LIKE CONSOLE, CARD READER, LINE PRINTER OR PUNCH. 
^THE RECORDS ARE COLLECTED IN MESSAGES OF THE SAME DEVICE TYPE 
AND IF <>BCC> CHECKS CORRECTLY AT THE END OF THE MESSAGE, THE 
DATA MESSAGES FORMED BY <>HSRXPM ARE DISTRIBUTED TO THE 
VARIOUS DEVICE'S TRANSLATE TASKS FOR PROCESSING. 
.HL 2 <>HSRQMS>
 ^THIS SUBROUTINE ANALYZES THE REQUESTS A STEP FURTHUR AND MARKS INPUT REQUEST OR OUTPUT PERMISSION GRANTED AND ALSO WAKES 
UP THE RELEVANT <>XLATE> TASK WHO MUST NOTICE THE REQUESTS 
OR GRANTS JUST ARRIVED. ^IT ALSO MAKES A CHECK OF THE INCOMING DATA
FORMATS AND RETURN  AN ERROR IF FORMAT IS FOUND IN ERROR. 
.HL 2 <>HSRSON>
 ^THIS SUBROUTINE IS CALLED BY <>HSRXPM> WHEN A 
<>SIGNON> CONTROL RECORD IS DETECTED. ^THE <>SIGNON> RECORD 
IS SPECIAL IN THE SENSE THAT IT IS THE ONLY RECORD TRANSMITTED 
WITH NO COMPRESSION AND MUST BE 80. CHARACTERS LONG. <>HSRSON> ASSEMBLES THIS RECORD WITH APPROPRIATE MESSAGE I.D. OF 
SIGNON. 
.HL 2 <>HSEOB>
 ^THIS SUBROUTINE IS CALLED WHEN AN END-OF-BLOCK IS ENCOUNTERED 
IN THE INCOMING STREAM. ^THIS SIGNALS ARRIVAL OF <>ETB> 
CHARACTER AFTER RECEIVING WHICH A <>BCC> CHECK IS MADE 
AND DATA DISTRIBUTED TO VARIOUS DEVICES. ^IT MUST BE NOTED THAT 
THE ALL RECEIVED DATA IS SEPARATED INTO MESSAGES FOR 
THE DIFFRENT DEVICES AND THESE MESSAGES ARE CHAINED TOGETHER 
WITH THE MOST CURRENT POINTER BEING IN <>TCRMSG> OFFSET 
IN THE <>BSC> <>TCB>. ^THIS GREATLY EASES THE JOB OF 
RELEASING THE RECEIVED MESSAGES IN THE EVENT OF ERRORS LIKE 
THE <>BCC> ETC.. 
.HL 2 <>HMSGTC>
 ^THIS SUBROUTINE GETS A RECEIVED CHARACTER FROM THE RECEIVER 
AND CHECKS IT FOR <>DLE> OR <>SYN>, EATS THEM AND EXCLUDES THEM 
FROM <>BCC> ALSO. ^IT ALSO MARKS <>ETB> RECEIVED IF ONE WAS 
ENCOUNTERED. ^IF THE CHARACTER IS NOT <>DLE> OR <>SYN>, IT 
IS INCLUDED IN THE <>BCC> CHECK. 
.HL 2 <>HSTRCB>
 ^THIS SUBROUTINE IS CALLED TO PICK UP THE INCOMING RECORD'S 
<>RCB> (RECORD CONTROL BYTE) AND <>SRCB> (SUB-RECORD CONTROL BYTE) 
WHICH ARE USED IN IDENTIFYING THE RECORD FOR A DEVICE. 
.HL 2 <>HSTFCS>
 ^THIS SUBROUTINE GETS THE RECEIVED <>FCS> BYTE 1 AND 2 
AND SETS IT IN <>TCRFCS> WHERE THE STATUS RECOGNIZER 
ROUTINE CAN LOOK AT IT TO FIND OUT WHAT DEVICES THE REMOTE HAS 
SUSPENDED OR UNSUSPENDED. 
.HL 2 <>HSCHST>
 ^THIS SUBROUTINE PROCESSES THE STATUS JUST RECEIVED IN 
THE <>FCS> (FUNCTION CONTROL SEQUENCE). ^IT MARKS THE DEVICES OR THE SYSTEM SUSPENDED AS INDICATED BY THE FUNCTION CONTROL BYTE1 AND BYTE2 RECEIVED FROM THE REMOTE. 
.HL 2 <>HSDRIP>
 ^THIS SUBROUTINE IS CALLED BY <>HSRQMS> WHEN AN INPUT REQUEST 
HAS BEEN RECEIVED FOR A DEVICE. ^IT IS ALSO CALLED BY <>HSEOB> 
WHEN IT DETECTS AN INCOMING DATA FOR A DEVICE. 
.HL 2 <>HSAWXL>
 ^THIS SUBROUTINE AWAKENS THE <>XLATE> TASK WHOSE DEVICE NUMBER IS IN <R1. 
.HL 2 <>HSWALX>
 ^THIS SUBROUTINE AWAKENS ALL THE <>XLATE> TASKS 
CONFIGURED ON THE LINE.
.HL 2 <>HSABRI>
 ^THIS SUBROUTINE ABORTS THE INPUT STREAM FOR A DEVICE.
.HL 2 <>HSABTI>
 ^THIS SUBROUTINE ABORTS INPUT STREAMS FOR ALL THE DEVICES 
CONFIGURED ON THE LINE.
.HL 1 <>HASP OUTPUT>
 ^THIS SECTION WILL DESCRIBE ALL THE SUBROUTINES 
INVOLVED IN TRANSMISSION OF A MESSAGE. ^THE OUTPUT SECTION 
STARTS AT <>HPXMIT> AND HAS EMBEDDED IN IT THE READING LOGIC 
USED BY THE RECEIVER ROUTINES TO FIND OUT THE RESPONSE TO THE 
TRANSMITTED MESSAGE. ^OUTPUT OF DATA IS DONE AT <>HSPXM1> BUT 
ALL THE MESSAGE BUILDING IS DONE BY <>HSGTMS>. 
.HL 2 <>HPXMIT>
 ^THIS ROUTINE IS CALLED BY RECEIVER AND TRANSMITTER LOGIC TO 
LOOK FOR MORE DATA TO TRANSFER. ^IF DATA IS NOT AVAILABLE, 
AN <>ACK0> IS USED AS FILLER EVERY SECOND. <>HSPXM1 TAKES OVER 
IF DATA IS AVAILABLE AND CALLS <>DQWRIT> TO DO ACTUAL TRANSMISSION OF DATA ON THE <>BISYNC> LINK. 
^ANY ABNORMAL CONDITIONS OR UNRECOVERABLE ERRORS WILL 
RESULT IN OUTPUT BEING ABORTED FOR ALL DEVICES. ^THE RESPONSE TO 
THE TRANSMITTED MESSAGE IS READ BY FALLING THRU TO <>HSPXM5> 
AND DEPENDING UPON THE RESPONSE THE MESSAGE IS RETRANSMITTED 
(FOR <>NAK> OR BAD <>BCC>) OR A NEW MESSAGE SENT OVER. 
.HL 2 <>HSMSAK>
 ^THIS SUBROUTINE PROCESSES THE ACKNOWLEDGEMENT RECEIVED FOR 
A MESSAGE SENT OVER. ^IT RELEASES ANY MESSAGES SENT AND FOR
SIGNON MESSAGE FAKES COMPLETION OF <>EOF> OUTPUT BY CLEARING 
<>TCOTC> BIT IN <>TCFG2> FLAG WORD FOR THE CARD REDAER.
.HL 2 <>HSGTMS>
 ^THIS SUBROUTINE IS CALLED BY <>HPXMIT> 
TO GET A BLOCK OF DATA. ^IT IN TURN CALLS <>HSONB>
TO LOOK FOR SIGNON MESSAGE AND IF NONE GOES TO LOOK FOR ANY 
PENDING REQUESTS TO BE SERVICED BY THE REMOTE. <>HSMTBK> IS 
THE ROUTINE WHICH BUILDS THE REAL DATA MESSAGE IF ANY AVAILABLE 
FOR OUTPUT. ^THE POINTER TO THE MESSAGE IS PASSED IN 
<>LB.MSG> IN THE LINE CNTROL BLOCK FOR <>HPXMIT> 
TO LOOK AT. 
.HL 2 <>HSONB>
 ^THIS SUBROUTINE IS CALLED BY <>HSGTMS> TO 
CHECK FOR ANY <>SIGNON> BLOCK TO BE SENT OVER TO REMOTE. 
^IF ONE IS FOUND, A SIGNON BLOCK IS BUILT 
AND MESSAGE POINTER PASSED IN THE <>LCB> CELL <>LB.MSG>. 
.HL 2 <>HSRQPT>
 ^THIS SUBROUTINE IS CALLED BY <>HSGTMS> TO LOOK FOR ANY 
OUTSTANDING PERMISSIONS FOR DEVICES TO BE SENT TO REMOTE. ^IF 
A DEVICE IS FOUND WITH REQUEST FLAG ON, ITS <>RCB> IS SAVED IN 
<>TCRQPT> CELL WHERE BUILDING MESSAGE ROUTINE CAN LOOK AT IT. 
.HL 2 <>HSDPG>
 ^THIS SUBROUTINE IS ALSO CALLED BY <>HSGTMS> TO LOOK FOR 
ANY PERMISSION GRANT MESSAGES TO BE SENT TO REMOTE IN RESPONSE 
TO AN EARLIER REQUEST SENT BY THE REMOTE. ^FLAG <>TCIPH> IS 
USED TO INDICATE IF PERMISSION HAS BEEN SENT ALREADY SO THAT 
IT IS NOT SENT REPEATEDLY. 
^THE <>RCB> OF THE DEVICE WHOSE PERMISSION HAS BEEN GRANTED 
IS 
SAVED IN <>TCDPG> FOR MESSAGE BUILDER TO LOOK AT. 
.HL 2 <>HSMTBK> 
 ^THIS SUBROUTINE BUILDS MESSAGES (DATA + REQUESTS) FOR HPXMIT TO SEE.
^THE DATA MESSAGE MAY CONTAIN DATA RECORDS FROM SAME OR DIFFRENT DEVICES 
^THE LAST RECORD MAY BE A DEVICE PERMISSION GRANTED OR A 
REQUEST FOR A DEVICE TO BE SENT TO REMOTE. ^THE DEVICES ARE POLLED 
FOR DATA IN THE FOLLOWING ORDER OF PRIORITIES: CONSOLE OUTPUT, 
CARD READER OUTPUT, LINE PRINTER OUTPUT, PUNCH DATA OUTPUT. 
.HL 2 <>HSCDOT>
 ^THIS SUBROUTINE CHECKS ON ALL DEVICES FOR DATA TO OUTPUT 
AND MAKES A MESSAGE BLOCK FOR TRANSMISSION IF IT FINDS DATA
TO OUTPUT. ^THE <>BCB> ERROR REPORTING 
,REQUEST TO GO OUT AND STATUS FOR SYSTEM SUSPEND TAKE 
PRECEDENCE IN GOING OUT AS MESSAGES. 
.HL 2 <>HSCKTP>
 ^THIS SUBROUTINE CHECKS FOR TRANSPARENT MODE ON OUTPUT 
AND INSERTS <>DLE> BEFORE A DATA <>DLE> OR <>SYN>. 
.HL 2 <>HSCKRQ>
 ^THIS SUBROUTINE IS CALLED BY THE MESSAGE BUILDER AT THE END 
TO ACCOMODATE ANY REQUESTS, GRANTS TO GO OUT AS LAST RECORD 
IN THE TRANSMISSION BLOCK. ^IT MAY ALSO BE CALLED IF <>HSMTBK> 
FINDS THAT <>BCB> ERROR HAS TO BE REPORTED WHICH IS SENT AS 
A LONE RECORD. <>HSTRL> ROUTINE IS CALLED TO 
APPEND THE <>ETB>, <>CRC> AND <>PADS> AT THE END OF THE MESSAGE. 
.HL 2 <>HSCKDO>
 ^THIS SUBROUTINE IS CALLED BY <>HSCDOT> AND <>HSCKAB> TO 
CHECK IF A DEVICE IS PERMITTED TO OUTPUT AND AS SUCH ANY 
ABORTS NOTICED ARE TAKEN CARE IN THIS TASK.
.HL 2 <>MSGHDR>
 ^THIS SUBROUTINE IS CALLED BY <>HSMTBK> MESSAGE BUILDER 
TO PUT <>BCB, <>FCS1>, <>FCS2> IN THE TRANSMISSION 
BLOCK BEING BUILT. ^NOTE <>STX> IS INCLUDED IN THE 
<>BCC> FOR NON-TRANSPARENT MODE.
.HL 2 <>HSRLOM>
 ^THIS SUBROUTINE RELEASES ALL OUT GOING 
MESSAGES WHICH MAY REMAIN STUCK IN BETWEEN THE TASKS. 
^IT IS CALLED BY THE ABORTS PROCEDURES WHEN <>DSR> DROPS 
OR A LINE IS DISABLED. 
.HL 2 <>HSUSPD>
 ^THIS SUBROUTINE IS CALLED BY THE <>HSDRIP> 
ROUTINE TO SEND SUSPEND THE DEVICE'S STREAM FROM REMOTE 
WHEN INPUT PERMISSION IS NOT SEEN AS GRANTED. 
.HL 2 <>HSUNSP>
 ^THIS SUBROUTINE IS CALLED BY THE >HSDPG> SUBROUTINE 
WHEN PERMISSION IS GRANTED FOR THE DEVICE.
TO ALLOW THE DEVICE STREAM TO CONTINUE. 
.HL 2 <>HSABRO>
 ^THIS SUBROUTINE ABORTS THE OUTPUT STREAM FOR THE DEVICE.
.HL 2 <>HSABTO>
 ^THIS SUBROUTINE ABORTS ALL THE OUTPUT STREAMS FOR ALL OUTPUT DEVICES. 
 ^A NUMBER OF OTHER SUBROUTINES ARE USED WHICH ARE 
PART OF THE <>IBM 3780> PROTOCOL AND THEIR DESCRIPTION IS NOT 
REPEATED HERE. 

.CHAPTER SECTION "<>DL10<>"
 ^THIS SECTION CONTAINS THE <>DL10> MEMORY-SHARING INTERFACE
CODE.
^INCLUDED ARE THE INTERRUPT ROUTINE, THE INITIALIZATION SUBROUTINE,
<>STOPCODE STORING SUBROUTINE,
A ONCE-A->JIFFY> SUBROUTINE, A ONCE-A-SECOND SUBROUTINE
AND THE <>DL10> DRIVER TASK.
^FIRST, HOWEVER, IT IS APPROPRIATE TO DISCUSS THE <>DL10>
WINDOW LAYOUT.
.HL 1 <>DL10> WINDOW
 ^EARLY IN SECTION "<>DEFINE<>" IS THE LAYOUT OF THE <>DL10> WINDOW.
^SECTION "<>DEFINE<>" DEFINES SYMBOLS WHICH FACILITATE DIRECT
REFERENCE BY THE <>DL10> SECTION TO VARIOUS LOCATIONS IN THE <>DL10>
WINDOW.  ^THE FIRST PART OF THE WINDOW IS MOSTLY
THE INTERFACE TO <>TOPS-10 ROUTINES WHICH ARE COMMON TO ALL
<>DL10> INTERFACES: <>DLXNAM> IS USED TO IDENTIFY THE PROGRAM
RUNNING ON THE <>PDP-11>, <>DLXOK> AND <>DLXTA> ARE "KEEP ALIVE"
COUNTERS, <>DLXHLT> AND <>DLXDWN> CONTROL THE "NOT RUNNING" MESSAGES
THAT PRINT ONCE A MINUTE, <>DLXSWD>, <>DLXADR> AND <>DLXSWD> ARE THE
EXAMINE/DEPOSIT INTERFACE, AND SO ON.
^THE PART WHICH IS IMPORTANT TO THE <>DN61> IS THE END OF
THE WINDOW FROM <>DLXOPE> TO <>DLEND>.  ^THIS HANDLES THE
PASSING OF DATA, STATUS AND CONTROL ACROSS THE <>DL10> INTERFACE.
.HL 2 11-INITIATED FUNCTIONS
 ^LOCATIONS <>DLXOPE>, <>DLXLNE> AND <>DLXDVE> ARE USED BY THE <>DN61>
TO ALERT THE <>PDP-10> TO A CONDITION WHICH IT SHOULD CHECK.
^NO CONDITION IS CURRENTLY DEFINED, SO THESE LOCATIONS
ARE NOT USED.
.HL 2 10-INITIATED FUNCTIONS
 ^LOCATIONS <>DLXOPX>, <>DLXLNX> AND <>DLXDVX> ARE USED BY THE
<>PDP-10> TO SIGNAL TO THE <>DN61>.  ^LOCATIONS <>DLXRST>
AND <>DLXXFR> ARE USED BY THE <>DN61> TO INDICATE THE
RESULTS OF THE SIGNAL.  <>DLXCBP> IS STORAGE FOR THE
COUNTS AND BYTE POINTERS WHICH DESCRIBE THE AREA OF
<>PDP-10> MEMORY TO BE READ OR WRITTEN.
 ^WHEN THE <>PDP-10> WISHES TO READ DATA FROM THE <>DN61>, IT
SETS <>DLXCBP> TO POINT TO THE USER'S BUFFER
(WHICH MAY BE SPLIT ACROSS NON-CONTINUOUS PAGE BOUNDRIES,
HENCE THE ALLOWANCE FOR UP TO SIXTEEN SEPARATE
AREAS).  ^THEN <>DLXLNX> AND <>DLXDVX> ARE SET TO THE USER-SPECIFIED
LINE NUMBER AND DEVICE NUMBER.  (^THE DEVICE NUMBER IS
NOT USED IN THE <>DN61>; THIS NUMBER IS EXPECTED TO BE USED
IN THE <>DN62<>.)
^LAST, THE <>PDP-10> SETS <>DLXOPX> TO 1 AND INTERRUPTS THE
<>DN61>.
^THE <>DN61> FETCHES <>DLXOPX>, CLEARS IT, AND ATTEMPTS TO PERFORM THE READ.
^EITHER THE READ SUBROUTINE SUCCEEDS IN PASSING SOME DATA,
NO DATA WAS AVAILABLE, OR THE INPUT STREAM HAS BEEN
ENDED.  ^THESE THREE POSSIBLE CONDITIONS ARE INDICATED
BY SETTING <>DLXRST> TO 1, 2 OR 3, RESPECTIVELY.  ^ALSO,
<>DLXXFR> IS SET TO THE NUMBER OF BYTES TRANSFERED OVER THE
<>DL10>.  ^THIS IS USED BY THE <>PDP-10> TO KNOW HOW MANY BYTES
TO PROCESS IN ITS BUFFER.  ^IF THE RESULT IS 2 OR 3,
<>DLXXFR> IS ALWAYS SET TO ZERO.
	 ^READING STATUS WORKS JUST THE SAME WAY EXCEPT FOR SETTING
A DIFFERENT VALUE INTO <>DLXOPX>.
 ^WRITING DATA IS THE SAME IN THE <>PDP-10>; LOCATIONS
<>DLXCBP>, <>DLXLNX>, <>DLXDVX> AND <>DLXOPX> ARE ALL SET UP
AS DESCRIBED ABOVE.  ^IN THE <>DN61> THE ^WRITE ^DATA
SUBROUTINE IS CALLED.  ^IT MAY SUCCEED IN PASSING
ALL THE DATA, IT MAY PASS SOME OF IT, OR THE OUTPUT
STREAM MAY HAVE BEEN >ABORT>ED.  ^AT THE END OF THE OPERATION
LOCATION <>DLXRST> IS SET TO 1, 2 OR 3, RESPECTIVELY,
DEPENDING ON WHICH OF THESE THINGS HAPPENS.  ^LOCATION
<>DLXXFR> IS SET TO THE NUMBER OF BYTES TRANSFERED
SO THAT THE <>PDP-10> PROGRAM CAN RE-ISSUE THE ^WRITE ^DATA
COMMAND, IF NECESSARY, STARTING AT THE BYTE FROM WHICH
THE LAST COMMAND ENDED.
^IF NO DATA IS PASSED, <>DLXRST> IS SET TO 2 AND <>DLXXFR> IS SET
TO 0, INDICATING THAT THE COMMAND SHOULD BE RE-ISSUED
JUST AS IT WAS.
 ^THE OTHER WRITE-TYPE COMMANDS WORK JUST LIKE
^WRITE ^DATA EXCEPT FOR A DIFFERENT VALUE IN <>DLXOPX>.
^NONE OF THE OTHER COMMANDS CAN SET <>DLXRST> TO 2 EXCEPT
THE >SUBFUNCTION> OF ^WRITE ^LINE ^COMMAND
WHICH ENABLES A LINE.  ^IF THERE IS NOT ENOUGH CORE
AVAILABLE TO CREATE THE TABLES NECESSARY TO ENABLE A LINE
FOR THE FIRST TIME, <>DLXRST> IS SET TO 2.
.HL 1 ^INTERRUPT ^ROUTINE
 ^THE INTERRUPT CODE IS VERY SIMPLE; IT MERELY AWAKENS THE
<>DL10> TASK IF THAT TASK IS WAITING FOR A <>DL10> INTERRUPT.
^THE REAL-TIME RESPONSIVENESS OF THE <>DN61> IS
KEPT HIGH BY KEEPING THE NUMBER OF INSTRUCTIONS
EXECUTED AT INTERRUPT LEVEL SMALL.
.HL 1 <>STOPCODE STORING
 ^THE STOPCODE STORING SUBROUTINE STORES THE <>STOPCODE
IN THE <>DL10 WINDOW SO THAT <>TOPS-10 CAN PRINT IT
FOR THE OPERATOR'S INFORMATION.  ^THIS SUBROUTINE IS
CALLED ONLY AFTER A FATAL ERROR IS DETECTED.
^SEE ^CHAPTER 18 ON DEBUGGING FACILITIES FOR MORE INFORMATION
ON <>STOPCODE><S.
.HL 1 ^INITIALIZATION
 ^THE INITIALIZATION SUBROUTINE ATTEMPTS TO BRING THE
<>PDP-10> ON-LINE BY REQUESTING AN INTERRUPT THROUGH THE
CLOSED WINDOW.  ^THIS CAUSES <>TOPS-10 TO OPEN THE WINDOW
SO THAT THIS SUBROUTINE CAN STORE THE NAME "<>DN60>##".
<>TOPS-10 THEN INITIALIZES ITSELF FOR THE <>DN61>.
^THIS SUBROUTINE IS FULL OF TIMERS AND TRAPS SO THAT
IT WILL NOT RUN FOREVER IF THE -10 IS NOT WORKING.
^IT IS CALLED FROM THE INITIALIZATION CODE AND FROM THE
DISPATCHER IF THE -10 IS DOWN.
.HL 1 ^ONCE-A->^JIFFY>
 ^THE ONCE-A->JIFFY> CODE PERFORMS THE EXAMINE AND DEPOSIT
FUNCTIONS, MAINTAINS THE LIGHTS AND SENDS AN INTERRUPT
TO THE <>PDP-10> IF REQUESTED.  ^THE FUNCTION OF INTERRUPTING
THE <>PDP-10> IS USED BY THE <>DL10> TASK WHEN AN OPERATION IS
COMPLETE.
^THE LIGHTS SHOW THE AMOUNT OF UNUSED CAPACITY IN THE <>DN61>
USING THE TOP ROW OF LIGHTS IN THE <>DL10>.
.HL 1 ^ONCE-A-^SECOND
 ^THE ONCE-A-SECOND SUBROUTINE WATCHES OUT
FOR THE <>PDP-10> HALTING.  ^THE PURPOSE OF THE CODE IS
NOT ONLY TO
ALLOW THE <>PDP-10> TO REACH A <>DDT> BREAKPOINT AND CONTINUE
FROM IT WITHOUT HURTING THE <>DN61>, BUT ALSO TO STOP
DOING ALL WORK IF THE <>PDP-10> IS RELOADED.  ^THESE CASES CAN
BE DISTINGUISHED FROM ONE ANOTHER BECAUSE THE WINDOW WILL BE CLOSED IF
THE <>PDP-10> IS RELOADED AND 
WILL REMAIN OPEN IF IT SIMPLY HITS A BREAKPOINT.
 ^IF THE <>PDP-10> IS RELOADED, A FLAG IS SET SO THAT ALL
OUTSTANDING <>BSC> STREAMS WILL BE >ABORT>ED.
 ^THIS ONCE-A-SECOND SUBROUTINE ALSO SETS A FLAG
IN THE <>DL10> WINDOW TO REASSURE THE
<>PDP-10> THAT THE <>DN61> HAS NOT HALTED.
.HL 1 ^TASK
 ^MOST OF THE CODE IN THIS SECTION IS THE <>DL10> TASK.
^IT IS DIVIDED INTO THREE PARTS: THE <>DL10> INTERFACE SUBROUTINES,
THE COMMAND INTERPRETERS, AND THEIR SUBROUTINES.
.HL 2 <>DL10> INTERFACE SUBROUTINES
^THIS TASK IS MOSTLY TABLE DRIVEN.  ^THE FIRST TABLE IS
FOR THE COMMAND CODE FROM THE <>PDP-10>.
^FOLLOWING THIS IN THE LISTING ARE SEVERAL SUBROUTINES USED TO
DISCOVER THE COMMAND CODE AND DISPATCH BASED ON IT
AND TO FETCH AND STORE DATA THROUGH THE WINDOW.
.HL 3 <>DLENDO>
^THIS SUBROUTINE DOES THE POST-COMMAND CLEAN UP.
<>DLENDO<> STORES <>DLXRST> AND <>DLXXFR> AND REQUESTS A <>PDP-10>
INTERRUPT.
.HL 3 <>DLDISP>
^THIS SUBROUTINE DOES THE DISPATCHING FOR THE COMMAND CODE.
<>DLDISP<> IS ALSO USED DURING THE PROCESSING OF SOME COMMANDS.
.HL 3 <>DLGOPR>
^THIS SUBROUTINE GETS THE COMMAND CODE FROM THE <>PDP-10>.
^THE TASK SPENDS MOST OF ITS TIME HERE, WAITING FOR THE
NEXT COMMAND FROM THE <>PDP-10>.
.HL 3 <>DLGBYT>
^THIS SUBROUTINE FETCHES A BYTE THROUGH THE <>DL10> WINDOW.
<>DLGBYT<> OBSERVES THE COUNTERS STORED IN <>DLXCBP> SO THAT IT
CAN GO FROM ONE BYTE POINTER TO THE NEXT, THUS CROSSING
USER'S PAGE BOUNDRIES EVEN IF THE USER'S BUFFER IS CHECKERBOARDED
IN PHYSICAL CORE.
.HL 3 <>DLPBYT>
^THIS SUBROUTINE STORES A BYTE THROUGH THE <>DL10> WINDOW.
<>DLPBYT<> ALSO OBSERVES THE COUNTERS IN <>DLXCBP>.
.HL 3 <>DLPWRD>
^THIS SUBROUTINE STORES A 16-BIT WORD THROUGH THE <>DL10> WINDOW.
<>DLPWRD<> WORKS BY CALLING <>DLPBYT>.
.HL 3 <>DLPSTR>
^THIS SUBROUTINE STORES A STRING OF WORDS THROUGH THE
<>DL10> WINDOW.
<>DLPSTR<> WORKS BY CALLING <>DLPWRD>.
.HL 2 COMMAND INTERPRETERS
 ^THE FIRST PART OF THIS SUBSECTION CONSISTS OF EIGHT SUBROUTINES,
ONE FOR EACH OF THE EIGHT COMMANDS.  ^THE SECOND
PART CONSISTS OF SUBROUTINES FOR INTERPRETING >SUBCOMMANDS>
OF TWO OF THE EIGHT MAJOR COMMANDS.
.HL 3 <>DLTRDT>
^THIS SUBROUTINE PERFORMS THE "READ DATA" FUNCTION.
<>DLTRDT<> COPIES TO THE <>PDP-10> DATA FROM THE OLDEST MESSAGE RECEIVED
OVER THE SPECIFIED LINE BY THE TRANSLATE TASK.
^THE MESSAGE IS THEN SENT TO THE <>IDLE<> TASK TO BE BROKEN
DOWN INTO CHUNKS AND FREED.  <>DLTRDT<> HANDLES THE CASES OF NO
MESSAGE BEING AVAILABLE AND OF THE INPUT STREAM BEING >ABORT>ED.
.HL 3 <>DLTWDT>
^THIS SUBROUTINE PERFORMS THE "WRITE DATA" FUNCTION.
<>DLTWDT<> COPIES DATA FROM THE <>PDP-10> INTO CHUNKS WHICH IT THEN
SENDS TO THE TRANSLATE TASK FOR THE SPECIFIED LINE.  ^IF IT
RUNS OUT OF CHUNKS WHILE COPYING DATA, IT SO INFORMS
THE <>PDP-10> SO THAT THE <>PDP-10> CAN RESTART THE TRANSFER AT
A LATER TIME.
.HL 3 <>DLTRDS>
^THIS SUBROUTINE PERFORMS THE "READ DEVICE STATUS" FUNCTION.
^THE STATUS INFORMATION IS OBTAINED FROM THE <>TCB> OF THE
TRANSLATE TASK.
.HL 3 <>DLTWDC>
^THIS SUBROUTINE PERFORMS THE "WRITE DEVICE COMMAND"
FUNCTION.  <>DLTWDC<> DOES MOST OF ITS WORK BY CALLING SUBROUTINES
USING THE SAME DISPATCH SUBROUTINE THAT WAS USED TO CALL IT.
^THESE SUBROUTINES ARE DESCRIBED BRIEFLY BELOW.
.HL 3 <>DLTRLS>
^THIS SUBROUTINE PERFORMS THE "READ LINE STATUS" FUNCTION.
<>DLTRLS<> COPIES DATA FROM THE <>LCB> TO THE <>PDP-10>.
.HL 3 <>DLTWLC>
^THIS SUBROUTINE PERFORMS THE "WRITE LINE COMMAND" FUNCTION.
<>DLTWLC<> DOES MOST OF ITS WORK BY CALLING SUBROUTINES.
^THESE SUBROUTINES ARE DESCRIBED BRIEFLY BELOW.
.HL 3 <>DLTRES>
^THIS SUBROUTINE PERFORMS THE "READ <>DN60> STATUS" FUNCTION.
<>DLTRES<> SIMPLY COPIES SOME DATA FROM THE <>GLOBAL<> AREA TO THE <>PDP-10>
USING <>DLPSTR>.
.HL 3 <>DLTWEC>
^THIS SUBROUTINE PERFORMS THE "WRITE <>DN60> COMMAND" FUNCTION.
<>DLTWEC<> IS A DUMMY, SINCE NO USE IS YET DEFINED FOR THIS FUNCTION.
.HL 3 <>DLTEXM>
 ^THIS SUBROUTINE PERFORMS THE "EXAMINE OF 
A ELEVEN LOCATION" FUNCTION (#9).
.HL 3 <>DLTDEP>
 ^THIS SUBROUTINE PERFORMS THE "DEPOSIT IN ELEVEN MEMORY" 
FUNCTION (#10) AND IS QUITE USEFUL FOR DEBUGGING.
.HL 3 <>DLTRBN>
 ^THIS SUBROUTINE IS ESSENTIALLY THE SAME AS THE READ DATA 
FUNCTION WITH THE EXCEPTION THAT THE DATA IS IN BINARY MODE. 
^SINCE THE TEN DOES NOT KNOW THAT 11 HAS BINARY DATA, THE 
-11 WILL REJECT A WRONG MODE READ DATA OPERATION WITH CODE 6 
WHICH THE TEN USES TO REISSUE THE <CALL11.UUO IN THE 
CORRECT MODE.
.HL 3 <>DLTWBN>
 ^THIS SUBROUTINE WILL BE SIMILAR TO THE WRITE DATA 
WITH MODE CONSIDERATIONS SIMILAR TO ABOVE. (THIS FUNCTION 
IS NOT YET IMPLEMENTED)
.HL 2 COMMAND INTERPRETER SUBROUTINES
 ^THERE ARE TWO SETS OF COMMAND INTERPRETER SUBROUTINES:
ONE SET FOR THE LINE COMMANDS
AND ONE SET FOR THE DEVICE COMMANDS.  ^THE LINE
COMMAND SUBROUTINES ARE NAMED <>DLTL<NN> WHERE NN IS THE
NUMBER OF THE COMMAND.  ^THE DEVICE SUBROUTINES ARE NAMED
<>DLTD<NN> WHERE NN IS, AGAIN, THE NUMBER OF THE
COMMAND.  ^IT WOULD BE TEDIOUS TO LIST ALL OF THE SUBROUTINES
HERE; THEY ARE ALL VERY SHORT AND EACH IS HEADED
BY A COMMENT SPECIFYING ITS FUNCTION.  ^THESE FUNCTIONS ARE
ALSO LISTED IN ^CHAPTER 20 WHICH SPECIFIES HOW TO USE
THE <>CAL11_.> <>UUO>.
 ^AFTER THE LINE AND DEVICE SUBROUTINES ARE SOME
SUBROUTINES WHICH THEY USE.  ^THE MOST IMPORTANT ONES
ARE LISTED HERE.
.HL 3 <>DLDRAI>
^THIS SUBROUTINE DRAINS THE MESSAGE >QUEUE> FROM THE
TRANSLATE TASK.  <>DLDRAI<> IS USED WHEN A MESSAGE STREAM IS >ABORT>ED.
.HL 3 <>DLNWCK>
^THIS SUBROUTINE SENDS THE CURRENT CHUNK TO THE TRANSLATE
TASK AND OBTAINS A NEW ONE FROM FREE STORAGE.  <>DLNWCK<> IS USED
WHEN DOING THE "WRITE DATA" FUNCTION AND IS
RESPONSIBLE FOR MAKING SURE THAT THE OUTPUT STREAM FROM THE
<>PDP-10> DOES NOT USE UP ALL THE CHUNKS.
^IF THE <>PDP-10> WERE PERMITTED TO USE UP ALL THE CHUNKS
THEN DATA COULD NOT BE RECEIVED AND ONE LINE MIGHT
"HOG" CHUNKS, THUS PREVENTING OTHER LINES FROM
TRANSMITTING.

.CHAPTER SECTIONS "<>DTE10<>" AND "<>DTE20<>"
 ^THIS SECTION CONTAINS THE <>DTE20> INTERFACE CODE WHICH SERVES
AS A SUBSTITUTE FOR THE <>DL10> SECTION IN THE <>DN61-SA>,
<>DN61-SB>, <>DN64-AA>, AND <>DN64-AB>.
^MOST OF THE OTHER SECTIONS ARE UNAWARE OF
THE SUBSTITUTION, SINCE THIS SECTION HAS THE SAME
FUNCTIONS AND ENTRY POINTS AS THE <>DL10> SECTION.
.HL 1 COMMUNICATIONS REGION
 ^THE COMMUNICATIONS REGIONS ARE DEFINED BY THE
<>RSX-20F<> ^QUEUED (<>KL10/PDP-11<>-<>DTE20<>)
^PROTOCOL, ^DOCUMENT ^NO. 200-205-034-00,
TO EASE THE EXCHANGE OF STATUS AND OTHER
INFORMATION BETWEEN THE <>KL10<> ^PROCESSORS AND THEIR
<>PDP-11<> ^FRONT ^ENDS.
 ^COMMUNICATIONS REGIONS ARE COMPOSED OF SEQUENTIAL AREAS,
EACH PROCESSOR OWNING ONE AND ONLY ONE AREA WHICH IS THE ONLY
PART OF THE COMMUNICATIONS REGION
THE PROCESSOR IS ALLOWED TO WRITE INTO.
^DURING INITIALIZATION, HOWEVER, A TEN PROCESSOR IS RESPONSIBLE
FOR SETUP OF 
THE ENTIRE REGION.  ^EACH AREA HAS A SINGLE SECTION FOR THE PROCESSOR
OWNING THE AREA, AND A SECTION FOR EACH PROCESSOR THAT THE PROCESSOR
THAT THE PROCESSOR OWNING THE AREA WILL COMMUNICATE TO.

^EACH SECTION HAS CELLS TO HOUSE NAME OF THE OWNING PROCESSOR,
SIZE OF COMMUNICATIONS AREA, KEEP-ALIVE COUNTER, STATUS WORD,
TRANSFER SIZE WHICH ARE FREQUENTLY ACCESSED TO PERFORM
ALMOST ANY FUNCTION.  ^KEEP-ALIVE COUNTER IS INCREMENTED BY
THE OWNING PROCESSOR ONCE A SECOND (AT LEAST) AND THE MONITORING
PROCESSOR MAY EXAMINE IT PERIODICALLY TO SEE THAT IT HAS CHANGED.
^IF NO CHANGE IS NOTICED FOR 6 SECONDS, THE OWNING PROCESSOR IS
DECLARED DEAD AND A REBOOT REQUESTED BY SETTING THE LOAD BIT IN
the comm. area.  ^word <>dtepca<> is the first location
IN EACH "TO" PROCESSOR SECTION.
.HL 1 <>DTE20 ^INTERRUPT ^ROUTINE:
^THIS ROUTINE IS ENTERED AS A RESULT OF <>DTE20<>
HARDWARE INTERRUPTS.  ^<>DT.INT<> SAVES THE STATUS (REGISTER
34 (OCTAL)) IN <>DLSSAV<> FOR DEBUGGING PURPOSES AND THEN CHECKS FOR THE
CONDITIONS WHICH CAUSED THE INTERRUPT.  ^THE THREE
RELEVANT CONDITIONS OR EVENTS ARE:

^the eleven done (when the -11 is done receiving data from -10)

^the ten done (when the -10 is done receiving data from -11)

^THE DOORBELL (WHEN THE -10 WANTS -11'S ATTENTION IT INTERRUPTS)

^THESE EVENTS CAUSING THE INTERRUPT ARE RECORDED IN THREE
DIFFERENT WORDS <>DTIEDN<>, <>DTIXDN<>
, <>DTIDBL<> FOR ELEVEN DONE, TEN-DONE AND DOORBELL RESPECTIVELY,
BY INCREMENTING THE RELEVANT WORD.  ^IN THE EVENT OF A HARDWARE
ERROR, THE ROUTINE EXECUTES A ^STOP ^CODE <DL10(02).  ^OTHERWISE
THE ROUTINE SIMPLY RECORDS THE INTERRUPT CONDITION AND AWAKENS THE 
<>DTE20<> DRIVER TASK (BY TURNING BITS OFF IN THE <>TCB<> OF DRIVER
task) if the task happens to be waiting for that condition.  ^the
ACTUAL PROCESSING IS DONE BY TASKS SCHEDULED AND THEREFORE THE 
RESPONSE TIME IS IMPROVED BY DOING MINIMUM WORK AT INTERRUPT LEVEL.
.HL 1 STOPCODE STORING:
^the stopcode storing subroutine
STORES THE STOPCODE IN A CELL AT LOCATION <>TRPCOD<> SO THAT IT 
CAN BE EXAMINED BY THE <>TEN<> -USER (<>TOPS-10/20<>).
^THE <>PC<> OF LOCATION +1 WHICH EXECUTED THE STOPCODE IS STORED
AT <>TRPERR<>.  ^OTHER IMPORTANT INFORMATION STORED INCLUDES
THE REGISTERS STARTING AT LOCATION <>STOPRO<>.
^OF SPECIAL INTEREST MAY BE <>STOPR5<>
WHICH NORMALLY POINTS TO THE <>TCB<> OF THE TASK AND ONCE THAT'S
KNOWN IT IS EASIER TO EXAMINE VARIOUS <>TCB<>
OFFSETS FOR MESSAGE HEADERS RECEIVED AND SENT ACCROSS THE <>DTE20<>.
^IF THE <>DEBUG<> SWITCH IS ON,ALL THE <>DTE20<> REGISTERS ARE
SAVED IN GLOBAL LOCATIONS STARTING AT <>DTESAV<>.
^THE STATUS IS IN LOCATION <>DTESAV<> +34(OCTAL).  ^THIS SUBROUTINE
IS CALLED ONLY AFTER A FATAL ERROR IS DETECTED.  ^REFER TO 
^chapter 18 for details on debugging facilities and more information on
stopcodes.  ^the meaning of various stopcodes
IS LISTED IN ^SECTION "^S".
.HL 1 ^INITIALIZATION:
^THE INITIALIZATION SUBROUTINE <>INITDL<> IS CALLED AT STARTUP
FROM THE INITIALIZATION CODE (AND ALSO FROM THE DISPATCHER IF THE 
-10 IS DOWN) TO INITIALZE THE <>DTE20<> ^QUEUED ^PROTOCOL
^INTERFACE.  ^IT MAKES SURE THAT THE -10 IS OUT OF PRIMARY
PROTOCOL BEFORE RESTARTING THE ^QUEUED ^PROTOCOL.  ^TEN'S
doorbell is rung and after waiting for a while the -10 should
GET BACK INTO PRIMARY PROTOCOL AGAIN WHICH MEANS WE CAN DO 
EXAMINES OF THE COMMUNICATION REGION. ^AFTER WE GET INTO
PRIMARY PROTOCOL, THE COMMUNICATION REGION DATA BASE IS
SET UP AND INITIALIZED BY CALLING <>DLINDB<>.
^FOR INFORMATION ON ^QUEUED ^PROTOCOL, ^PRIMARY ^PROTOCOL AND 
COMMUNICATION REGIONS, THE READER IS REFERED TO ^APPENDIX ^A.
.HL 1 ^ONCE-^A-^JIFFY
^THIS SUBROUTINE (<>DSPDLT<>) IS A DUMMY SUBROUTINE PROVIDED 
FOR COMPATABILITY WITH REST OF THE <>DN60<> SERIES SOFTWARE.
.HL 1 ONCE-A-SECOND 
^THE ONCE-A-SECOND SUBROUTINE (<>DSPDLS<>) WATCHES OUT
for <>KL10<>-halting, by monitoring the keep-alive counter
of the ^ten in the ^eleven's area.  ^in addition it
performs examines of ^ten's communication area to confirm
that ^ten is really up.  ^failure to perform an examine means that
^ten has just gone down and <>dlgone<> is set to -1 to tell the
WORLD ABOUT THE CATASTROPHE.  ^FOLLOWING THIS THE DISPATCHER WILL
notice that ^ten's gone down and it will call initialization
subroutine <>initdl<> to pull ^ten out of primary protocol.  ^UNTIL
the ^ten comes up with valid examine (after hearing ^eleven
ringing ^ten's doorbell), the initialization will not put the ^ten
BACK IN PRIMARY PROTOCOL.  <>DSPDLS<> ALSO INCREMENTS ITS OWN KEEP-
ALIVE-COUNTER WHICH THE -10 MAY BE MONITORING.
.hl 1 ^task:
^MOST OF THE CODE IN THIS SECTION IS THE <>DTE20<> TASK WHICH CONSISTS
OF THREE DIFFERENT PARTS:
.LIST
.LE;^THE <>DTE20 ^TASK ^INTERFACE ^SUBROUTINES
.LE;^THE ^QUEUED ^PROTOCOL ^INTERFACE ^SUBROUTINES
.LE;^THE ^COMMAND ^INTERPRETER AND THEIR SUBROUTINES
.END LIST
 ^BEFORE WE PROCEED ANY FURTHER, IT IS VERY PERTINENT TO GIVE A 
VERY SIMPLE BACKGROUND OF THE PROCEDURE OR DISCIPLINE FOR
COMMUNICATING BETWEEN THE -10 AND THE -11 USING THE ^QUEUED
^PROTOCOL.  ^THIS DISCIPLINE (<>DN60<> ^COMMUNICATIONS ^PROTOCOL)
IS ONE LEVEL HIGHER PROTOCOL
THAN THE QUEUED PROTOCOL AND BASICALLY ASSUMES THE
^TEN AS THE MASTER AND THE ^ELEVEN AS THE SLAVE DRIVER THROUGH THE
<>dte20<>.  ^the ^ten initiates all operations like examine/
deposit of ^eleven memory, data reads/writes and line/device status
checks/writes/etc.  ^the ^ten always requests the operation
by sending a ^header (<>feh<>) to the ^eleven.  ^the header format is
DESCRIBED IN ^APPENDIX ^A.  ^ALL THE PERTINENT INFORMATION ABOUT
THE FUNCTION REQUESTED IS INCLUDED IN THE HEADER.  ^AFTER PERFORMING
the function, the ^eleven sends a response back to the ^ten
returning result code (1=successful, 2=delayed, 3=rejected) to
INFORM THE ^TEN ABOUT THE STATUS OF THE OPERATION.  ^THE EXACT
MESSAGE FORMAT OF RESPONSE FOR EACH FUNCTION IS GIVEN IN ^APPENDIX ^A,
WHICH ALSO DEFINES THE <>DN60<> ^COMMUNICATION ^PROTOCOL.

.HL 2 <>DTE20<> ^TASK ^INTERFACE ^SUBROUTINES:
 ^THE <>DLDRVR<> SUBROUTINE INTERFACES THE <>DTE20<> TASK
TO THE EVENTS OCCURING AT THE HARDWARE LEVEL.  ^IT CHECKS FOR
OCCURANCE OF THE ^ELEVEN-DONE, THE ^TEN-DONE, AND DOORBELL BY 
EXAMINING LOCATIONS <>DTIEDN<>, <>DTIXDN<>, <>DTIDBL<>, RESPECTIVELY IN THE
ORDER INDICATED.  ^EVEN IF ^ELEVEN-DONE AND DOORBELL OCCUR
SIMULTANEOUSLY, ^ELEVEN DONE MUST BE
HONORED FIRST AND THEN ^TEN DONE
AND LASTLY DOORBELL TO IMPLEMENT QUEUED PROTOCOL CORRECTLY.  ^A NON
-ZERO EVENT COUNT IN THE ABOVE THREE CELLS WOULD CAUSE THE
APPROPRIATE PROCESSING ROUTINE TO BE DISPATCHED.  ^TIME LIMITS ARE SET
SO THAT ANY LOOPS OR WILD CODE JUMPS ARE NOT EXECUTED INDEFINITELY.
^THE THREE INTERRUPT PROCESSING ROUTINES THE DRIVER DISPATCHES TO ARE
^THE SUBROUTINE
<>DLTXDN<> FOR ^TEN-DONE, <>DLELDN<> FOR ^ELEVEN DONE, AND
<>DLDRBL<> FOR THE DOORBELL EVENT.
.HL 3 <>DTE10<>
^THE FOLLOWING PARAGRAPHS ARE RELEVANT IF THE 
MODULE "<>DTE10.P11<>" HAS BEEN INCLUDED IN THE <>DN61<> ASSEMBLY.
.HL 4 <>DLTXDN<>:
^THIS ROUTINE PERFORMS THE ^TO ^TEN-DONE PROCESSING WHICH MAY BE
AS A RESULT OF DIRECT ^HEADER OR ^INDIRECT DATA RECEIVED
BY THE -10 (AND SENT BY THE -11 TO THE -10).  ^AS MENTIONED
IN THE ^APPENDIX ^A., THE -11 HAS TO SEND A RESPONSE BACK TO -10 AFTER
COMPLETING THE REQUESTED FUNCTION FROM THE -10.  ^THE DIRECT 
MESSAGE MAY BE AS A RESULT OF THE RESPONSE HAVING BEEN SENT TO
THE -10.  ^IN ADDITION IF THE REQUESTED FUNCTION WAS A READ DATA OR
READ STATUS (LINE/DEVICE/<>DN60<>), AN INDIRECT DATA MESSAGE
WOULD FOLLOW THE HEADER AFTER THE -10 HAS ACKNOWLEDGED THE -10 
THE RECEIPT OF THE HEADER BY A -10 DONE.  ^THE STATE VARIABLE
USED HERE IN THE ^PROTOCOL ^FUNCTION WORD <>DT10FN<> OF
THE MESSAGE BEING SENT.  ^THE HEADER STARTS
AT OFFSET <>DT10HD<> IN THE <>TCB<> OF THE <>DTE20<> DRIVER
TASK.  ^ON DIRECT MESSAGES, LIKE HEADER, <>DT10FN<> WILL BE
POSITIVE AND AFTER DIRECT PORTION OF THE INDIRECT MESSAGE, IT WILL
BE NEGATIVE.  ^IN THE LATTER CASE THE INDIRECT PORTION WILL BE SENT TO 
THE ^TEN AND THE STATE VARIABLE <>DT10FN<> CLEARED TO
^THE ^TEN AND THE STATE VARIABLE <>DT10FN<>
INDIRECT MESSAGE.
.HL 4 <>DLELDN<>:
^THIS SUBROUTINE PERFORMS THE ^TO-11 DONE
PROCESSING.
^THE ^TO -11 TRANSFERS ARE CONTROLLED BY BOTH THE 11-DONE AND
THE DOORBELL EVENTS AND EVERYTHING IS SYNCHRONIZED
BY STATE VARIABLE <>DT11ST<>.  ^THIS STATE VARIABLE MAY ASSUME ONE
OF THE FOLLOWING VALUES:
<>DTSTDB<> = 0;IDLE STATE, WAITING FOR DIRECT DOORBELL
;11-DONE AND 10-DONE ARE INVALID.
.SKIP 1
<>DTSTHD<> = 2  ;WAITING FOR 11-DONE FOR HEADER
;                 DOORBELL AND 10-DONE INVALID
.SKIP 1

<>DTSTDD<> = 4  ; IS NOT USED.
.SKIP 1

<>DTSTIB = 6  ; WAITING FOR INDIRECT DOORBELL
                (FOR IND. DATA) ;  11-DONE, 10-DONE ARE INVALID.
.SKIP 1
<>DTSTID = 10  ;WAITING FOR TO 11-DONE FOR INDIRECT DATA
;                DOORBELL AND 10-DONE INVALID.

 ^THE ROUTINE DECREMENTS THE 11-DONE
COUNT (<>DTIEDN<>) AND CALLS A SUBROUTINE DEPENDING ON CURRENT STATE OF
VARIABLE <>DT11ST<>  ^IF 11-DONE OCCURS IN A STATE
WHEN IT IS INVALID, A STOPCODE (64) WILL BE EXECUTED.

.HL 4 <>DLDRBL<>:
^THIS ROUTINE PERFORMS THE PROCESSING FOR THE
DOORBELL RUNG BY THE ^TEN.
^IF VALID EXAMINE IS OFF, THE DOORBELLS ARE IGNORED.  ^DOORBELL COUNT
IS DECREMENTED (<>DTIDBL<>) AND STATUS WORD IN COMMUNICATION
AREA (^HIS TO ME I.E. 11 AREA IN 10'S) IS EXAMINED TO SEE IF INDIRECT
TRANSFER IS IN PROGRESS.  ^IF IT IS, THE DOORBELL IS INTERPRETED AS
INDIRECT DATA DOORBELL AND <>DTINST<> IS CALLED TO INITIATE INDIRECT DATA TRANSFER.
^IN CASE IT IS A DIRECT-DOORBELL, ROUTINE <>DTHDST<> IS CALLED TO 
INITIATE TRANSFER THE HEADER.  ^THE HEADER IS PLACED IN <>TCB<> AREA
STARTING AT OFFSET <>DT11HD<>.  ^INDIRECT DATA IS STORED IN CHUNKS FOR
WRITE FUNCTION.  ^IF THE 11-DONE IS IN A STATE WHEN THE DOORBELLS
ARE INVALID, A STOPCODE (61) WILL BE EXECUTED.
.HL 4 <>DTHDIN<>:
^THIS SUBROUTINE IS CALLED AFTER THE HEADER OF THE TO-11 MESSAGE
IS SAFELY IN THE <>TCB<> AREA STARTING AT OFFSET <>DT11HD<>.
^THEN CHECKS ARE MADE TO SEE IF PROTOCOL FUNCITON AND DEVICE
CODES ARE LEGAL.  ^THEN DEPENDING ON THE FUNCTION REQUESTED (IN BYTE
<>DT11DF<>) BY THE TEN, APPROPRIATE ROUTINE IS CALLED TO PERFORM
THE FUNCTION.  ^AFTER RETURNING FROM THE FUNCTION PERFORMING ROUTINES
STATE OF 11-DONE (VARIABLE <>DT11ST<>) IS UPDATED TO EXPECT EITHER AN INDIRECT DATA
DOORBELL IF THE FUNCTION <>DT11FN<> WAS INDIRECT OR DIRECT DATA DOORBELL FOR
NEXT POSSIBLE HEADER.
.HL 4 <>DTDIND<>:
^THIS SUBROUTINE IS CALLED WHEN 11-DONE OCCURS AND THE STATE VARIABLE FOR
11-DONE IS EXPECTING INDIRECT DATA.  ^THIS MAY BE AS A RESULT OF FILLING UP A CHUNK
OR REACHING THE END OF THE TO-11 MESSAGE.  ^SINCE FOR STATUS WRITES THERE IS ONLY ONE
BLOCK TRANSFER, THESE FUNCTIONS ARE DISPATCHED TO
APPROPRIATE ROUTINES FOR COMMAND
INTERPRETING AND STATUS SETTING AND 11-DONE IS INITIALIZED BACK TO <>DTSTDB<> WHILE
EXITING FROM THE ROUTINES VIA <>DTIPDN<>.  ^FOR WRITE DATA FUNCTION, IF MORE
DATA IS LEFT (<>DLMCTL<>=0) TO TRANSFER TO-ELEVEN,  CALL IS MADE TO
<>DLTEDN<> TO OBTAIN A NEW CHUNK
AND THEN <>DTSRT<> IS CALLED TO FILL DATA IN THE CHUNK
^IF NOTHING IS LEFT TO TRANSFER, THEN <>DLTEDN<> RETURNS A ZERO
IN REGISTER <R0
IMPLYING THAT DATA TRANSFER IS COMPLETE AND STATE VARIABLE <>DT11ST<> IS
INITIALIZED AND A SUCCESS CODE (=1 IN <>DT10DF<>+1) IS SENT TO THE TEN ALONG
WITH AMOUNT OF BYTES IT WAS ABLE TO ACCEPT (IN <>DT10DT<>).
.HL 3 <>DTE20<>
^THE FOLLOWING 
HOLDS IF "<>DTE20.P11<>" HAS BEEN INCLUDED IN <>DN64 ASSEMBLY.
.HL 4 ^INTERFACE ^BETWEEN HARDWARE AND <>DTE20 ^TASK:
^THE INTERFACE BETWEEN THE <>DTE20<> HARDWARE
EVENTS AND THE <>DTE20<> TASK IS DEFINED BY <>DTE20<> PROCESSOR. 
^THE <>DTE20<> PROCESSOR IS DRIVEN BY TWO FINITE STATE
LOOSELY COUPLED, STATE MACHINES "^A" AND "^B" DESCRIBED BELOW.
^THE THREE
HARDWARE EVENTS AS MENTIONED EARLIER ARE THE 11-DONE, THE 10-DONE
AND THE DOORBELL INTERRUPS.  ^THE 11-DONE AND DOORBELL 
DRIVE THE FINITE STATE MACHINE "^A".  ^THE 10-DONE DRIVES THE
OTHER STATE MACHINE "^B" FOR THE <>DTE<> PROCESSOR.
.SKIP 2
^THE FOLLOWING COMMENTS DESCRIBE THE STATES FOR THE STATE-
DRIVEN <>DTE<> PROCESSOR.
 ^ABBREVIATIONS USED IN THE DESCRIPTION BELOW ARE AS FOLLOWS:
.B 1;.LM 6;.I -6
<>FEH<> - ^FRONT-END HEADER.  ^THIS IS A DIRECT MESSAGE THAT
DESCRIBES THE INDIRECT DATA THAT FOLLOWS AS "STRING DATA".
^FOR DETAILS ON <>FEH FORMAT, REFER TO 
THE MISCELLANEOUS NOTES IN SECTION 14.8.
.B 1;.I -6
<>EH<> - <>ED<> HEADER.  ^THIS IS AN INDIRECT MESSAGE THAT
DESCRIBES THE FOLLOWING INDIRECT MESSAGE (IF ANY) 
AS "WRITE DATA",
"WRITE LINE COMMAND", "READ DATA", ETC.
.B 1;.I -6
<>ED<> - <>ED<> DATA.  ^THIS IS THE INDIRECT MESSAGE
DESCRIBED BY THE <>EH<> MESSAGE ABOVE.
.B 1;.I -6
<>ACK<> - ACKNOWLEDGE. ^THIS MESSAGE ACKNOWLEDGES THE
RECEIPT AND PROCESSING OF THE LAST INDIRECT MESSAGE.
.B 1;.LM -6
 ^A PROPER SEQUENCE CONSISTS OF <>FEH<>, <>EH<>, <>FEH<>, <>ED<>.
^WHERE RELAVENT, AN <>FEH IS REFERRED TO AS "<>FEH FOR
<>EH<>" OR "<>FEH FOR <>ED<>" BASED ON THE MESSAGE THAT FOLLOWS
THE <>FEH
 ^EACH MESSAGE IS PRECEEDED BY A DOORBELL.
 ^BEFORE AN <>FEH<> MAY BE SENT THE PREVIOUS <>FEH<> AND ITS 
FOLLOWING <>EH<> OR <>ED<> MUST BE ACKNOWLEDGED.
^THIS IS A SIMPLIFICATION OF THE <>TOPS-20<> RULE.
 ^A COMPLETE TRANSACTION IS ALWAYS INITIATED BY THE -20 WITH AN 
<>FEH<> FOLLOWED BY AN <>EH<>.  ^DEPENDING ON THE CONTENTS
OF THE <>EH<>, IT MAY BE FOLLOWED BY <>FEH<>, <>ED<>.
^THE <>PDP-11<> REPLIES WITH <>FEH<> <>EH<> AND,
DEPENDING ON THE CONTENTS
OF THE FIRST <>EH<>, MAY FOLLOW THIS BY <>FEH<>, <>ED<>.
^EXAMINE
AND DEPOSIT DO NOT USE <>ED<> IN EITHER DIRECTION.
^NO FUNCTIONS USE
<>ED< IN BOTH DIRECTIONS.
 ^BELOW THE DESCRIPTION OF EACH STATE IS A BRIEF DESCRIPTION
OF THE 
ACTION TAKEN WHEN THE APPROPRITE EVENT OCCURS.
.HL 4 ^STATE ^MACHINE "^A":
^STATE ^MACHINE
"^A" IS
DRIVEN BY 11-DONE INTERRUPTS AND BY DOORBELLS.
.B 1
.LM +4;.I -4
0:#WAITING FOR INITIAL DOORBELL.  11-DONE IS INVALID.
.LM +4;.I -2
READ <>FEH<> FOR <>EH<>.
.B 1;.LM -4;.I -4
2:#^WAITING FOR <>FEH<> FOR <>EH<>.  ^DOORBELL IS INVALID.
.LM +4;.I -2
^IF DEVICE IS WRONG, GO TO STATE 34.
.I -2
^IF ALLOCATION MESSAGE, GO TO STATE 34.
.I -2
^OTHERWISE, READ <>EH<>.
.B 1;.LM -4;.I -4
4:#^WAITING FOR DOORBELL FOR <>EH<>.  11-DONE IS INVALID.
.LM +4;.I -2
^READ <>EH<>.
.B 1;.LM -4;.I -4
6:#^WAITING FOR <>EH<>.  ^DOORBELL IS INVALID.
.LM +4;.I -2
SEND <>ACK<> ONLY IF AN <>ED<> TO COME.  ^SET MACHINE ^B FROM STATE 0 TO 2.
.I -2
^IF THE FLAG <>DT10AK<> INDICATES THAT THERE IS NO <>ED<>, THEN SEND <>ACK<> + <>FEH<>,  GO TO STATE
20, ELSE GO TO STATE 10.
.B 1;.LM -4;.I -4
10:#^WAITING FOR DOORBELL FOR <>FEH<> FOR <>ED<>.
11-DONE IS INVALID.
.LM +4;.I -2
^READ <>FEH<> FOR <>ED<>.
.B 1;.LM -4;.I -4
12:#^WAITING FOR <>FEH<> FOR <>ED<>.  ^DOORBELL IS INVALID.
.LM +4;.I -2
^GO TO STATE 14.
.B 1;.LM -4;.I -4
14:#^WAITING FOR DOORBELL FOR <>ED<>.  11-DONE IS INVALID.
.LM +4;.I -2
^READ <>ED<>.
.B 1;.LM -4;.I -4
16:#^WAITING FOR <>ED<>.  ^DOORBELL IS INVALID.
.LM +4;.I -2
^IF MACHINE "^B" IS AT STATE 4, SEND <>ACK<>+<>FEH<> AND SET
MACHINE "^B" TO STATE 10, THEN GO TO STATE 22.
.I -2
^IF MACHINE "^B" IS NOT AT STATE 4, GO TO STATE 20.
.B 1;.LM -4;.I -4
20:#^WAITING FOR <>ACK<> OF <>EH<> TO COMPLETE.  (I.E.,
FOR MACHINE "^B" TO GO FROM STATE 2 TO STATE 6 OR 10.)
^NEITHER 11-DONE NOR DOORBELL ARE VALID.
.B 1;.I -4
22:#^WAITING FOR DOORBELL FOR <>ACK<> FOR <>EH<>.
11-DONE IS INVALID.
.LM +4;.I -2
^READ <>ACK<> FOR <>EH<>.
.B 1;.LM -4;.I -4
24:#^WAITING FOR <>ACK<> FOR <>EH<>.  ^DOORBELL IS INVALID.
.LM +4;.I -2
^IF THE <>EH<> INICATES THAT NO <>ED<> WILL BE RETURNED,
AND MACHINE "^B" IS IN STATE 14, SET BOTH STATES TO ZERO.
.I -2
^IF MACHINE "^B" IS NOT IN STATE 14,
GO TO STATE 32.
.I -2
^IF THE <>EH<> INDICATES THAT AN <>ED<> WILL BE RETURNED,
AND MACHINE "^B" IS IN STATE 14, 
SEND <>FEH<> FOR <>ED<>, SET MACHINE "^B" TO STATE 16
AND GO TO STATE 26.
.I -2
^IF MACHINE "^B" IS NOT IN STATE 14, JUST GO TO STATE 26.
.B 1;.LM -4;.I -4
26:#^WAITING FOR DOORBELL FOR <>ACK<> FOR <>ED<>.
11-DONE IS INVALID.
.B 1;.I -4
30:#^WAITING FOR <>ACK<> FOR <>ED<>.  ^DOORBELL IS INVALID.
.LM +4;.I -2
^IF MACHINE "^B" IS IN STATE 22, SET THE STATES OF BOTH MACHINES
TO 0.
.I -2
^IF MACHINE "^B" IS NOT IN STATE 22, GO TO STATE 32.
.B 1;.LM -4;.I -4
32:#^GOT FINAL <>ACK<>.  11-DONE AND DOORBELL ARE INVALID.
.B 1;.I -4
34:#^IGNORING 11-DONE.
.LM +4;.I -2
^IF WE GET AN 11-DONE, IGNORE IT.
.I -2
^IF WE GET A DOORBELL, TREAT IT THE SAME AS FOR STATE 0.
.LM -8
.HL 4 ^STATE ^MACHINE "^B":
^STATE MACHINE "^B" IS DRIVEN BY 10-DONE.
.B 1;.LM +4;.I -4
0:#IDLE.  10-DONE IS INVALID.
.B 1;.I -4
2:#^WAITING FOR COMPLETION OF <>ACK<> FOR <>EH<> OR <>ACK<>+<>FEH<> .
.LM +4;.I -2
^IF MACHINE "^A" IS NOT IN STATE 20, JUST GO TO STATE 4.
.I -2
^IF MACHINE "^A" IS  IN STATE 20, SET IT TO STATE 22.
.I -2
^IF THE <>EH<> INDICATES THAT AN <>ED< WILL FOLLOW IT,
SEND AN <>ACK<>+<>FEH<>  (MACHINE "^A" HAS ALREADY PROCESSED THE <>ED<>
OR IT WOULD NOT BE IN STATE 20) AND GO TO STATE 10.
.I -2
^IF THE FLAG <>DT10AK<> INDICATES THAT AN <ED WILL NOT FOLLOW, SEND 
AN <>EH<> AND GO TO STATE 10.
.B 1;.LM -4;.I -4
4:#^GOT COMPLETION OF <>ACK<> (OR <ACK + <FEH)  FOR <>EH<>.
.LM +4;.I -2
10-DONE IS INVALID.
.B 1;.LM -4;.I -4
6:#^UNUSED STATE FOR NOW.
.B 1;.I -4
10:#^WAITING FOR COMPLETION OF <>ACK<> FOR <>ED<> +<>FEH<> FOR <>EH<>.
.LM +4;.I -2
^SEND <>EH<>.
.B 1;.LM -4;.I -4
12:#^WAITING FOR COMPLETION OF <>EH<>.
.LM +4;.I -2
^IF MACHINE "^A" IS IN STATE 26 THEN SEND <>FEH<> FOR <>ED<>
AND GO TO STATE 16.  
.I -2
^IF MACHINE "^A" IS NOT IN STATE 26 THEN GO TO STATE 14.
.B 1;.LM -4;.I -4
14:#^WAITING FOR <>ACK<> FOR <>EH<>.  10-DONE IS INVALID.
.B 1;.I -4
16:#^WAITING FOR COMPLETION OF <>FEH<> FOR <>ED<>.
.LM +4;.I -2
^SEND <>ED<>.
.B 1;.LM -4;.I -4
20:#^WAITING FOR COMPLETION OF <>ED<>.
.LM +4;.I -2
^IF MACHINE "^A" IS IN STATE 32 THEN SET BOTH STATES TO 0,
OTHERWISE GO TO STATE 22.
.B 1;.LM -4;.I -4
22:#^WAITING FOR <>ACK<> FOR <>ED<>.  10-DONE IS INVALID.
.B 1;.LM -4
.HL 4 <>DLTXDN<>:
^THIS SUBROUTINE DECIDES WHAT TO DO WHEN A TO-10
INTERRUPT IS RECOGNIZED.  ^IT IMPLEMENTS THE STATE MACHINE "^B" AS 
DESCRIBED ABOVE.
.HL 4 <>DLELDN<>:
^THIS SUBROUTINE DECIDES WHAT TO
DO WHEN AN 11-DONE
INTERRUPT IS RECOGNIZED.  ^IT IMPLEMENTS PART OF STATE
MACHINE "^A" DESCRIBED
ABOVE.
.HL 4 <>DLDRBL<>:
^THIS SUBROUTINE
DECIDES WHAT TO DO
WHEN A DOORBELL (RUNG BY THE TEN FOR ELEVEN) IS
RECOGNIZED.  ^IT IMPLEMENTS THE
REMAINDER OF MACHINE "^A".
.HL 4 <>DTSACK<> AND <>DTSAK<>:
^THE SUBROUTINE <DTSACK SENDS AN <ACK ALONGWITH <FEH HEADER 
,THE <ACK RIDING PIGGYBACK ON THE <FEH IN CONFORMANCE TO 
THE CONCATENATION RULES OF ^QUEUED ^PROTOCOL ^SPECIFICATIONS. 
^THE SUBROUTINE <DTSAK SENDS AN <ACK ONLY TO THE ^TEN IN RESPONSE TO 
THE DATA RECEVED BY THE ^ELEVEN. 
^THE REASON FOR CONCATENATION IS TO REDUCE THE NUMBER OF 
<DTE20 TRANSACTIONS AND SPEED UP THE COMMUNICATIONS THEREBY. 
.HL 2 ^QUEUED ^PROTOCOL ^INTERFACE ^SUBROUTINES:
.HL 3 <>DTHDST<>:
^THIS SUBROUTINE IS CALLED BY THE DOORBELL PROCESSOR
TO INITIATE A TO-11 TRANSFER 
OF A HEADER IN RESPONSE
TO A DIRECT DOORBELL RECEIVED WHEN
11-DONE STATE (<>DT11ST<>) WAS IN STATE <>DTSTDB<>.  ^THE NEXT 11-DONE WILL CONTINUE
PROCESSING BY EXAMINING THE HEADER AFTER SWAPPING BYTES 
TO CORRECT DIRECTION OF TRANSFER.
^THE HEADER IS STORED AT THE <>TCB<> STARTING AT OFFSET <>DT11HD<>.

.HL 3 <>DTINST<>
^THIS ROUTINE INITIATES AN INDIRECT DATA TRANSFER
TO THE <>PDP-11<> WHEN THE DOORBELL REQUESTING INDIRECT DATA RINGS.
^BYTE SIZE OF TRANSFER IS FOUND BY EXAMINING COMMUNICATION AREA
(STATUS WORD) AND SETS THE SIZE IN <>DTEQSZ<>, <>DLMBCT<>
AND <>DLMCTL<>. ^SIZE INFORMATION IS ALSO PASSED (IN <R0) ON TO <>DLEDBL<> SUBROUTINE.
<>DLEDBL<> RETURNS THE ADDRESS (OF EITHER A CHUNK FOR DATA WRITES
OR STATUS BLOCK FOR STATUS WRITE FUNCTION) OF BLOCK WHERE DATA MUST BE 
SENT, FOR FURTHER PROCESSING.  ^NOTICE THAT IT ISNOT NECESSRY TO ALLOCATE
SPACE FOR ENTIRE MESSAGE BECAUSE GATHER-WRITE IS IMPLEMENTED ON THE 
THE ^ELEVEN WRITES.  ^A TO-11 TRANSFER IS INITIATED BY CALLING SUBROUTINE
<>DTSTRT<>, AND A NEW STATE IS ENTERED TO WAIT
FOR INDIRECT DATA DONE.
.HL 3 <>DTSTRT<>:
^THIS SUBROUTINE IS RESPONSIBLE FOR STARTING
A TO-11 TRANSFER AND IT REQUIRES TWO ARGUMENTS:  ^NO. OF BYTES TO
TRANSFER IN ^R0, AND ADDRESS OF WHERE TO PUT THE DATA IN ^R1. 
^IF THIS TRANSFER WOULD COMPLETE THE TO-11 TRANSFER IN
IN PROGRESS, BOTH PROCESSORS ARE INTERRUPTED TO GIVE -11 DONE, OTHERWISE
ONLY THE ^ELEVEN IS INTERRUPTED BY 11-DONE FOR GATHER WRITE
OPERATION.  ^IF THE CHUNK OBTAINING ROUTINES FAILS TO GET A CHUNK
, OPERATION DELAYED FLAG IS UP, A DUMMY TO-11 TRANSFER OF ONE BYTE IS DONE
TO GET AN 11-DONE FOR BOTH PROCESSORS TO FINISH THE DELAYED
TO-11 TRANSFER.  ^THIS ROUTINE KEEPS A COUNT OF NUMBERS
OF BYTES LEFT TO TRANSFER FOR THE NEXT TRANSFER (IN WORD <>DLMCTL<>).  ^IF
THE DEBUG SWITCH IS ON, THE ADDRESS AND BYTE COUNT ARE
SAVED IN <>DT11AS<> AND <>DT11BS<> OFFSETS IN THE <>TCB<>.
.HL 3 <>DLEDBL<>:
^THIS SUBROUTINE IS CALLED  WHEN
QUEUED PROTOCOL FINDS IT RECEIVED AN INDIRECT DATA DOORBELL.
<>DLEDBL<> SETS UP THE ADDRESS OF A BLOCK TO RECEIVE THE INDIRECT
DATA.  ^FOR STATUS (LINE/DEVICE ON <>DN60<>) WRITES IT
SIMPLY PASSES THE ADDRESS OF DEDICATED BLOCK <>DTTTSB<> IN
GLOBAL AREA WHILE FOR DATA WRITE REQUESTS, IT FETCHES A CHUNK
FROM FREE STORAGE AND PASSES ADDRESS ONTO CALLING SUBROUTINE. ^IF IT FAILS
TO GET A CHUNK, FLAGS ARE SET TO INDICATE THE DELAYED OPERATION.


.HL 3 <>DLTEDN<>:
^THIS SUBROUTINE QUEUES THE PREVIOUSLY
FILLED CHUNK (BY DATA WRITE OPERATION) FOR <>XLATE<> AND
OBTAINS A NEW CHUNK TO PASS ON TO 11-DONE 
INTERRUPT ROUTINE.  ^IT KEEPS TRACK OF COUNT LEFT (IN CELL
<>DLMCTL<>) FOR NEXT TRANSFER AND IN CASE THE COUNT IS EXHAUSTED, 
CLEARS <R0 TO SO INDICATE TO THE CALLING ROUTINE.  ^IF UNABLE TO 
OBTAIN NEW CHUNK, IT FLAGS OPERATION DELAYED AND SHORTAGE 
OF CHUNKS FOR CALLING ROUTINES TO SEE.

.HL 3 <>DLSERR<>:
^THIS ROUTINE IS CALLED TO SET REJECT FLAGS
(3 IN <>DT10DF<>+1, AND <>DT11GW<>=-1) FOR CALLING ROUTINES TO SEE
.HL 3 <>DLSDLY<>:
^THIS ROUTINE IS CALLED TO FLAG "OPERATION
DELAYED: FOR CALLING ROUTINES TO SEE (2 IN <>DT10DF<>+1,
<>DT11GW<>=-1)
.HL 3 <>DTSHDR<>:
^THIS SUBROUTINE SETS UP HEADER FOR SENDING 
IT TO THE ^TEN.  ^THE HEADER IS IN <>TCB<> AREA STARTING
AT OFFSET <>DT10HD<>.  ^THE PROTOCOL FUNCTION, DEVICE, LINE
NO. AND <>DN60<> FUNCTION ARE SET UP PROPERLY.  ^THE INDIRECT TRANSFER
BIT AND RESULT CODE ARE SET BY THE OPERATION RESPONDING TO 
THE REQUESTED FUNCTION.  ^THE HEADER IS 16 (OCTAL) BYTES LONG EXCEPT
FOR DEPOSIT FUNCTION WHEN IT IS ONLY 12 (OCTAL) BYTES LONG.
.HL 3 <>DTCMRT<>:
^THIS SUBROUTINE SETS UP THE REMAINING
INFORMATION IN THE HEADER BEING SENT TO THE ^TEN LIKE
NUMBER OF BYTES TRANSFERED AND CALLS <>DTXMSD<> TO SEND TO THE
HEADER TO ^TEN.  ^IT ALSO INITIALIZES THE VALUE (TO <DTSTDB) OF 11-DONE STATE
VARIABLE <>DT11ST<>).
.HL 3 <>DTIPDN<>:
^THIS ROUTINE IS CALLED TO CLEAR PROCESSING IN QUEUE
STATUS TO INDICATE TO ^TEN THAT 11 IS DONE WITH THE CURRENT
TRANSFER, AND RETURN TO EITHER THE ELEVEN DONE OR DOORBELL PROCESSING.
.HL 2 FUNCTION DEPENDENT SUBROUTINES:
.HL 3 <>DLTWDT<>:
^THIS SUBROUTINE IS 
CALLED THEN THE ^TEN HAS REQUESTED A WRITE
DATA FUNCTION MEANING THAT THE ^ELEVEN IS
IS READY TO RECEIVE DATA FROM THE TEN.  ^THE SUBROUTINE 
ESSENTIALLY CHECKS VALIDITY OF LINE NUMBER PASSED IN THE
HEADER AND OTHER CONDITIONS (ARE  ALL RIGHT) FOR TRANSFER
TO PROCEED.  ^IF <>XLATE<> TASK  (TO WHICH DATA CHUNKS
ARE PASSED ON) IS RUNNING BEHIND, THE OPERATION IS DELAYED
UNLESS IT WAS DUE TO AN ABORT OR <>EOF<> IN WHICH CASE OPERATION
IS REJECTED.
.HL 4 <>DLTWD1<>:
^TO SET DEVICE STATUS, THE STATUS IS WRITTEN
INTO A GLOBAL BLOCK STARTING AT LOCATION <>DTTTSB<>.
^THIS IS A ONE BLOCK TRANSFER AND AMOUNT OF DATA FROM THE ^TEN
MUST NOT EXCEED THE SIZE OF STATUS BLOCK AREA.  ^THE STATUS
BLOCK IS THEN EXAMINED FOR DEVICE COMMAND FUNCTIONS BY
THE COMMAND INTERPRETER  ROUTINES AND CONTROL IS TRANSFERRED
TO APPROPRIATE DEVICE ROUTINES TO SET UP THE STATUS CONDITIONS
AT THE DEVICE LEVEL.
.HL 3 <>DLTRDT<>:
^THIS SUBROUTINE PERFORMS "^READ
^DATA" FUNCTION <>DLTRDT<> EXAMINES THE QUEUE FOR THE OLDEST
MESSAGE RECEIVED OVER THE SPECIFIED LINE BY THE TRANSLATE TASK.
^IF  ONE IS FOUND, IT BECOMES THE CURRENT
MESSAGE.  ^THE USER MAY ASK FOR MAXIMUM OF ONE CHUNK AND REQUEST
FOR ANY MORE WILL RESULT IN TRANSMITTING ONLY THE
CURRENT CHUNK OR RATHER WHAT IS LEFT IN THE CURRENT CHUNK.
^IF THE USER ASKS FOR LESS THAN A CHUNK THEN THE BYTE 
POINTER IN THE CHUNK IS UPDATED AFTER THE DATA IS SENT TO THE ^TEN.
^THE DATA IS ALWAYS SENT AS INDIRECT PACKET.  ^THE MESSAGE IS NOT 
FREED TILL THE END OF THE CURRENT MESSAGE IS ENCOUNTERED WHEN IT
IS SENT TO THE <>IDLE<> TASK TO BE BROKEN DOWN INTO CHUNKS AND
FREED.  ^<>DLTRDT<> HANDLES CASES OF NO MESSAGE BEING AVAILABLE AND
THAT OF INPUT BEING ABORTED.
.HL 3 <>DLTRLS<>:
^THIS SUBROUTINE PERFORMS THE "^READ
^LINE ^STATUS" FUNCTION.  ^IT COPIES DATA FROM THE 
^L^C^B INTO THE STATUS BLOCK WHICH IS PASSED ONTO THE TEN 
AS AN INDIRECT DATA PACKET.
.HL 3 <>DLTWLC<>:
^THIS SUBROUTINE PERFORMS THE "^WRITE ^LINE
COMMANDS" FUNCTION.  <>DLTWLC CHECKS FOR VALIDITY OF RELEVANT ARGUEMENTS
PASSED IN HEADER BUT THE REAL WORK IS PERFORMED BY THE SUBROUTINES WHICH
ARE CALLED BY <>DLTWL1<>.
^THE SUBROUTINES ARE DESCRIBED BRIEFLY BELOW.
.HL 4 <>DLTWL1<>:
IS CALLED WHEN INDIRECT
DATA HAS BEEN RECEIVED
FOR SETTING UP THE LINE STATUS.  ^THE OPERATION IS SIMILAR TO ONE IN
<>DLTWD1<> EXCEPT AT THE END CONTROL IS TRANSFERRED TO LINE STATUS ROUTINES.
.HL 3 <>DLTEXM<>:
^THIS SUBROUTINE PERFORMS THE ACTUAL EXAMINE/DEPOSIT FUNCTION
OF THE ^ELEVEN MEMORY AND IS CALLED AFTER THE <>DN60<> PROTOCOL HEADER HAS BEEN RECEIVED
AND REQUESTED FUNCTION RECOGNIZED TO BE
AN EXAMINE OR DEPOSIT.  ^FOR EXAMINES, THE ADDRESS PASSED IS USED TO
LOOK INTO CONTENTS OF THE CELL AND RESULT STORED INTO <>DT10DT<>
TO PASS DATA BACK TO THE ^TEN.  ^FOR DEPOSIT FUNCTION, THE DATA
(IN <>DT11T<>) IS STORED INTO THE ADDRESS (IN <>DT11AD<>) PASSED
IS THE HEADER.  ^ANY ILLEGAL ADDRESSES WILL BE TRAPPED AND
A REJECT CODE WILL BE SENT BACK TO THE ^TEN.

.HL 3 <>DLTRES<>:
^THIS SUBROUTINE PERFORMS THE "^READ <>DN60<> STATUS" FUNCTION.
<>DLTRES<> SIMPLY COPIES SOME DATA FROM GLOBAL AREA TO
THE STATUS BLOCK USING <>DLPSTR<> AND THEN THIS DATA IS SENT INDIRECTLY
TO THE ^TEN FOLLOWING THE HEADER.  ^INDIRECT TRANSFER BITS  ARE SET 
IN PROTOCOL FUNCTION CODE AND AMOUNT OF DATA TO BE TRANSFERRED IN INDIRECT
PACKET IS SET IN <>DT10DT<>.
.HL 3 <>DLTWEC<>:
^THIS SUBROUTINE PERFORMS THE "^WRITE <>DN60<>
^COMMAND" FUNCTION <>DLTWEC<> IS A DUMMY SINCE NO USE IS YET
DEFINED FOR THIS FUNCTION.
.HL 4 <>DLTWS1<>:
^THIS SUBROUTINE IS CALLED FOR SETTING <>DN60<> STATUS - USE OF WHICH HAS NOT BEEN
DEFINED YET.  ^ANY CALL TO IT SHOULD BE INVALID.

.HL 3 <>DLGBYT<>:
^IS A SUBROUTINE TO GET A BYTE OF TRANSFER
FROM THE BLOCK POINTED TO BY ^R2.  ^COUNT OF NO. OF BYTES MUST
SET IN ^R4.  ^IT KEEPS COUNT OF BYTES FETCHED IN CELL
<>TCXFR<> IN <>TCB<>.  ^IT IS CALLED BY STATUS ROUTINES.

.HL 3 <>DLPBYT<>:
^THIS SUBROUTINE STORES A BYTE
OF DATA IN THE BLOCK POINTED TO BY ^R2.  ^COUNT NUMBER OF
NUMBER OF BYTES IN ^R4 AND BYTE TO STORE MUST BE PASSED
IN ^R1.  ^THE COUNT OF BYTES TRANSFERED IS KEPT IN <>TCB<>
OFFSET <>TCXFR<>.
.HL 3 <>DLPWRD<>:
^THIS SUBROUTINE STORES A 16-BIT
WORD INTO THE BLOCK POINTED TO BY ^R2.  <>DLPWRD<> WORKS
BY CALLING <>DLPBYT<>.
.HL 3 <>DLPSTR<>:
STORES A STRING OF WORDS IN THE AREA POINTED TO BY ^R2.
<>DLPSTR<> WORKS BY CALLING <>DLPWRD<>.
.HL 3 <>DTCERR<>:
^IS A COMMON ERROR RETURN ROUTINE CALLED WHEN A FATAL ERROR OCCURS LIKE
ABORT OR ^TEN ERROR OR PROTOCOL BREAKDOWN.  ^IF  DEBUG
SWITCH IS ON IT EXECUTES A STOPCODE <>TER<> (54)
MEANING ^TEN ERROR.  ^IF THE DEBUG SWITCH IS OFF, ALL 
OUTSTANDING DATA STREAMS ARE ABORTED.
.HL 2 COMMAND INTERPRETER SUBROUTINES
 ^THERE ARE TWO SETS OF COMMAND INTERPRETER SUBROUTINES:
ONE SET FOR THE LINE COMMANDS
AND ONE SET FOR THE DEVICE COMMANDS.  ^THE LINE
COMMAND SUBROUTINES ARE NAMED <>DLTL<NN> WHERE NN IS THE
NUMBER OF THE COMMAND.  ^THE DEVICE SUBROUTINES ARE NAMED
<>DLTD<NN> WHERE NN IS, AGAIN, THE NUMBER OF THE
COMMAND.  ^IT WOULD BE TEDIOUS TO LIST ALL OF THE SUBROUTINES
HERE; THEY ARE ALL VERY SHORT AND EACH IS HEADED
BY A COMMENT SPECIFYING ITS FUNCTION.  ^THESE FUNCTIONS ARE
ALSO LISTED IN ^CHAPTER 20 WHICH SPECIFIES HO