top - download
⟦cd22339b1⟧ Wang Wps File
Length: 50600 (0xc5a8)
Types: Wang Wps File
Notes: CPS/SDS/028
Names: »3984A «
Derivation
└─⟦adc1a7714⟧ Bits:30006180 8" Wang WCS floppy, CR 0361A
└─ ⟦this⟧ »3984A «
WangText
E…00……00……00……00……10……0a……00……00……10……0b……10……06……0f……0c……0f……00……0f……06……0e……0e……0e… …0d……09……0d……0c……0d……0d……0d……01……0d……05……0c……09……0c……0a……0c……0c……0c……01……0c……05……0b……08……0b……0c……0b……0e……0b…
…0b……05……0b……06……0b……07……0a……86…1 …02… …02… …02…
…02…CPS/SDS/028
…02…840501…02……02…
I/O CONTROL
…02……02…CAMPS
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
4.2.4.3 Subpackage LTUX-LSL Specification ......
4.2.4.3.1 Functional Specification ...........
4.2.4.3.2 Software Structure .................
4.2.4.3.3 Data Flow and Control Logic Within
Subpackage .........................
4.2.4.3.4 Module Specifications ..............
4.2.4.3.4.1 Module INILSL Specifications
...
4.2.4.3.4.1.1 Functional Specification
...
4.2.4.3.4.1.2 Module Interface ..........
4.2.4.3.4.1.3 Module Components ..........
4.2.4.3.4.1.4 Data Description ..........
4.2.4.3.4.1.5 Module Design .............
4.2.4.3.4.2 Module PROCESSES Specification
.
4.2.4.3.4.2.1 Functional Specification
..
4.2.4.3.4.2.2 Module Interface ..........
4.2.4.3.4.2.3 Module Components .........
4.2.4.3.4.2.4 Data Description ..........
4.2.4.3.4.2.5 Module Design .............
4.2.4.3.4.3 Module CMDINT Specification ....
4.2.4.3.4.3.1 Functional Specification
..
4.2.4.3.4.3.2 Module Interface ..........
4.2.4.3.4.3.3 Module Components .........
4.2.4.3.4.3.4 Data Description ..........
4.2.4.3.4.3.5 Module Design .............
4.2.4.3.4.4 Module LINKPRO Specification
...
4.2.4.3.4.4.1 Functional Specification
..
4.2.4.3.4.4.2 Module Interface ..........
4.2.4.3.4.4.3 Module Components .........
4.2.4.3.4.4.4 Data Description ..........
4.2.4.3.4.4.5 Module Design .............
4.2.4.3.4.5 Module OUTBHAND Specification
..
4.2.4.3.4.5.1 Functional Specification
..
4.2.4.3.4.5.2 Module Interface ..........
4.2.4.3.4.5.3 Module Components .........
4.2.4.3.4.5.4 Data Description ..........
4.2.4.3.4.5.5 Module Design .............
4.2.4.3.4.6 Module INBHAND Specification
...
4.2.4.3.4.6.1 Functional Specification
..
4.2.4.3.4.6.2 Module Interface ..........
4.2.4.3.4.6.3 Module Components .........
4.2.4.3.4.6.4 Data Descriptions .........
4.2.4.3.4.6.5 Module Design .............
4.2.4.3.4.7 Module MSTPSYNT Specification
..
4.2.4.3.4.7.1 Functional Specification
..
4.2.4.3.4.7.2 Module Interface ..........
4.2.4.3.4.7.3 Module Components .........
4.2.4.3.4.7.4 Data Description ..........
4.2.4.3.4.7.5 Module Design .............
4.2.4.3.4.8 Module ACP127 Specification ....
4.2.4.3.4.8.1 Functional Specification
..
4.2.4.3.4.8.2 Module Interface ..........
4.2.4.3.4.8.3 Module Components .........
4.2.4.3.4.8.4 Data Description ..........
4.2.4.3.4.8.5 Module Design .............
4.2.4.3.4.9 Module INTERRUPT Specification
.
4.2.4.3.4.9.1 Functional Specification
..
4.2.4.3.4.9.2 Module Interface ..........
4.2.4.3.4.9.3 Module Components .........
4.2.4.3.4.9.4 Data Description ..........
4.2.4.3.4.9.5 Module Design .............
4.2.4.3.4.10 Module V24 DRIVER Specification
4.2.4.3.5 Common Subpackage Data .............
4.2.4.3.6 Common Subpackage Procedures .......
4.2.4.3.7 Subpackage Interfaces ..............
4.3 Memory Layout LTUX ̲LSL .........................
4.2.4.3 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲L̲T̲U̲X̲-̲L̲S̲L̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.4.3.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The LTUX-LSL supports the interface between the CAMPS
host computer and one or more of the following devices:
o Medium speed tele printer (MSTP)
o Paper tape read/paper tape punch (PTR/PTP)
o Low speed tele printer/tape relay center print
to print (TRC)
The different devices are supported in the following
ways:
M̲e̲d̲i̲u̲m̲ ̲S̲p̲e̲e̲d̲ ̲T̲e̲l̲e̲ ̲P̲r̲i̲n̲t̲e̲r̲
o ASCII character transfer
o 1200 bps output speed
o Printer status reporting (key on/off, paper in/out)
o Optional usage of V-24 lines 105/106 and 108.2/107
o Optional flow control
o Optional usage of even/odd/none parity
o 1 - 1 1/2 - 2 stop bits
o Cancel specified output LDU
P̲a̲p̲e̲r̲ ̲T̲a̲p̲e̲ ̲R̲e̲a̲d̲/̲P̲a̲p̲e̲r̲ ̲T̲a̲p̲e̲ ̲P̲u̲n̲c̲h̲
o ASCII or BAUDOT character transfer (input and output).
o Characters transferred with 7 bit/character
(+ start, parity and stop bits) independent on
chosen alphabet
o 50, 75, 100, 110, 150, 165, 200, 300, 600 or 1200
bps input/output speed.
o Optional usage of V-24 lines 105/106 and 108.2/107
o Optional flow control
o Optional usage of even/odd/none parity
o 1 - 1 1/2 - 2 stop bits
o Cancel specified output LDU
L̲o̲w̲ ̲S̲p̲e̲e̲d̲ ̲T̲e̲l̲e̲,̲ ̲T̲a̲p̲e̲ ̲R̲e̲l̲a̲y̲ ̲a̲n̲d̲ ̲P̲o̲i̲n̲t̲ ̲t̲o̲ ̲P̲o̲i̲n̲t̲
o ASCII or BAUDOT character transfer
o 50, 75, 110, 300 or 600 bps. character transfer
o Characters transferred with 5 bits/char + start,
parity and stop
o Optional usage of V24-lines 105/106 and 108.2/107
o Optional flow control
o Optional usage of even/odd/none parity
o 1 - 1 1/2 - 2 stop bits
o Cancel specified output LDU
For more details please refer to CAMPS LTUX-S V24 interfaces
(CPS/TCN/031) and I/O control detailed design specification
(CPS/SDS/028) figure 2.2.1.2-1.
Each LTUX-LSL may support different devices (max. 4
devices). The devices may be combined as desired only
observing the rule that jack 1 and jack 2 must run
at the same band rate and so must jack 3 and jack 4.
The actual usage of the LTUX-LSL is specified by the
enable command as described in section 4.2.4.3.7 Subpackage
interfaces.
4.2.4.3.2 S̲o̲f̲t̲w̲a̲r̲e̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The following modules are defined:
INILSL : Initializes data structures such as queue
and buffer headers. Initializes scheduling
system.
PROCESS : Main routine activated by scheduling system
(one special section defined per channel).
Each section activates the subroutine needed
for service of actual channel.
LDUSCH : Main routine activated by scheduling system
(one special section defined per channel).
Each section activates the LDUDEMUX and
buffer release module of actual channel.
LDUREL : Buffer release module. Returns empty buffer
to queue indicated in buffer header byte
0 and 1.
LDUDEM : Reads LDU - buffer from TDX-I/F queue,
specified subdevice. The LDU's are verified
with respect to LDU-type, command codes
or data content. Data LDU's are delivered
in a special queue, command LDU's in an
other.
CMDINT : Reads command LDU's from the LDUDEM module.
The commands are verified and executed.
In most cases a completion code is returned.
The module generates asynchronous status
reports and transmission/reception status
reports too.
LINKPRO : This is the "master" module controlling
the input and output of data. The control
is based on V24-line state and commands
received by CMDINT.
OUTBHAND : Controls the transmission of data packets.
Whenever a LDU is finished a "transmission
status report" request is flagged to the
module CMDINT.
INBHAND : Controls the transport of LDU's from device
to CR80. The module will wait for device
ready and input request before releasing
any buffer for transmission on the TDX-system.
The module is only used when device is
TRC (Tape relay center) or PTP/PTR (Paper
tape punch/read).
ACP127 : Detecting ACP127 "Start of transmission",
"End of line" and "End of message" functions.
Based on this information input data are
packed in LDU's and IOC records. The module
is only used when device is TRC or PTP/PTR.
MSTPSYNT : Reads the status reports received from
the MSTP (medium speed tele printer) and
reports or changes to LINKPRO and CMDINT.
The module is only used when device is
MSTP.
INTERRUPT : Interrupt routines used by serial interface
(SIO). Following interruptions are serviced:
TX-buffer empty, RX-character available,
external status interruption and special
receiver condition.
V24DRV : General subroutines used for initialization
and operation of serial interfaces (SIO's).
KERNEL : An assembly of subroutines used by one
or more of the other modules.
An overview of the firmware structure and the data
flow is shown in fig. 4.2.4.3.3-1. The figure shows
one channel, up to 4 channels may be used in each LTUX-LSL.
The figure does not show the scheduling system nor
the initialization modules.
4.2.4.3.3 D̲a̲t̲a̲ ̲F̲l̲o̲w̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲o̲g̲i̲c̲ ̲W̲i̲t̲h̲i̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲
For each channel used a number of queues are defined.
INFTQ : Data buffers ready for transmission. IOC-record
separators have been strupped off and replaced
with a device dependent no. of (CR) (LF)
characters.
Enqueing module: LDUDEM
Dequeing module: OUTBHAND
Initial no. of elements: 0
INTCQ : Command buffers with commands from the
CR80 or locally generated commands. The
CR80 commands are validated with respect
to command code and buffer size.
Enqueing module: LDUDEM
Dequeing module: CMDINT
Initial no. of elements: 0
INETQ : Empty packet buffers for outbound data.
Enqueing module: OUTBHAND
Dequeing module: LDUDEM
Initial no. of elements: 2
INFRQ : Data buffer with inbound data ready for
delivery to the CR80. Data are packed in
LDU's and IOC records. The queue is not
used when device is MSTP.
Enqueing module: ACP127
Dequeing module: INBHAND
Initial no. of elements: 0
INERQ : This queue is not used in LTUX-LSL
INWRQ : Empty pocket buffers for inbound data.
Enqueing module: LDUREL, INBHAND
Dequeing module: ACP127
Initial no. of elements: 3
INFIQ : This queue is not used in LTUX-LSL
INEIQ : Empty buffers for asynchronous reports
for the CR80.
Enqueing module: LDUREL
Dequeing module: CMDINT
Initial no. of elements: 3
INTRQ : "Output request" buffers received from
LDUDEM by CMDINT. The buffers are for transmission
to complete, and are used for the generation
of transmission status report.
Enqueing module: CMDINT
Dequeing module: CMDINT
Initial no. of elements: 0
INWCQ : Command buffer received from LDUDEM by
CMDINT. The buffers are waiting for the
completion of actual command (open/close
protocol), and are used for the generation
of completion code.
Enqueing module: CMDINT
Dequeing module: CMDINT
Initial no. of elements: 0
Fig. 4.2.4.3.3-1
4.2.4.3.4 M̲o̲d̲u̲l̲e̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲
4.2.4.3.4.1 M̲o̲d̲u̲l̲e̲ ̲I̲N̲I̲L̲S̲L̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲s̲
4.2.4.3.4.1.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This module cleares all RAM and initializes buffer-
and queue-headers. RAM areas are reserved for control
tables (LSLCTAB 1-4). Process scheduling is initialized.
The resulting schedule list is:
LSJAK 1 (LDUDEM, LDUREL)
SCANIN (TDX-service)
SCANOUT (TDX-service) JACK 1 service
PROCESS 1 (CMDINT, OUTBHAND,
LINKPRO, MSTPSYNT,
ACP127, INBHAND)
SCANIN
SCANOUT
LSJAK 2
SCANIN
SCANOUT JACK 2 service
PROCESS2
SCANIN
SCANOUT
LSJAK3
SCANIN
SCANOUT
PROCESS3 JACK 3 service
SCANIN
SCANOUT
LSJAK4
SCANIN
SCANOUT
PROCESS4 JACK 4 service
SCANIN
SCANOUT
The process INILSL is passivated, when init is finished.
V24-driver tables are initialized
4.2.4.3.4.1.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Module is activated as process no. 4 and must be situated
a PROM location 6000H
4.2.4.3.4.1.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
N.A.
4.2.4.3.4.1.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Actual buffer and queue layout are determined by the
tables BETA 1 (JACK 1 - JACK 4), and table BRAM. Resulting
buffer layout per JACK are:
QUEUE NO. OF SIZE OFF-SET
BUFFERS
TDX-outbound
empty buffer 3 128 0
INETQ 2 131 3
INEIQ 3 16 0
INWRQ 3 128 0
4.2.4.3.4.1.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The lables LMRSPK, TBAVAI, LMPHNT, LDUMUX, LIITHL,
LMCENT are dummy subroutines called by the module LDUSCH
in the LTUX common subpackage.
I̲n̲i̲t̲i̲a̲l̲i̲z̲e̲ ̲L̲S̲L̲
Clear all RAM
Create application processes
Passivate init processes
Evaluate buffers
Initialize V24-driver
Schedule
FIGURE 4.2.4.3.4.1.5-1
4.2.4.3.4.2 M̲o̲d̲u̲l̲e̲ ̲P̲R̲O̲C̲E̲S̲S̲E̲S̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.4.3.4.2.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This module defines 4 processes, PROCESS1-4, each serving
the corresponding jack no.
When activated the first time the process performs
the final initialization of control table and V24 driver.
4.2.4.3.4.2.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Module is using control table, LEVEL2PR field, to determine
which modules to call.
4.2.4.3.4.2.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Module consist of 4 sections, each serving one JACK.
The sections are scheduled individually.
4.2.4.3.4.2.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
N.A.
4.2.4.3.4.2.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
An overall flowgram is shown (fig. 4.2.4.3.4.2.5-1)
Processes
Init control table of JACK1
Loop
Call relevant modules
Schedule
End loop
Init control table of JACK2
Loop
Call relevant modules
Schedule
End loop
Init control table of JACK3
Loop
Call relevant module
Schedule
End loop
Init control table of JACK4
Loop
Call relevant module
Schedule
End loop
FIGURE 4.2.4.3.4.2.5-1
4.2.4.3.4.3 M̲o̲d̲u̲l̲e̲ ̲C̲M̲D̲I̲N̲T̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.4.3.4.3.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The command interpreter module receives commands from
the LDU demultiplex modules. Commands may be init commands,
input request or error reports. Another function of
the command interpreter is the generation of command
responses, TX and RX completion codes and asynchronous
error reports.
4.2.4.3.4.3.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Command buffers are received on queue INTCQ. Empty
buffer for reports etc. are fetched from INEIQ. Reports
etc. are delivered for the TDX-bus for transmission
(JACK1 uses subdevice 2, JACK2 uses subdevice 3 etc.).
Two control bytes, CMDCONT1 and CMDCONT2, are used
to indicate reports to generate. Error codes are returned
in other 8 bytes, for details refer section 4.2.4.3.5:
Common subpackage data.
4.2.4.3.4.3.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Module contain a sequential code area and a section
with the fixed part of the responses/reports to be
used.
4.2.4.3.4.3.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The data formats used corresponds to the formats specified
in section 4.1.4 Common package data.
4.2.4.3.4.3.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
C̲o̲m̲m̲a̲n̲d̲ ̲i̲n̲t̲e̲r̲p̲r̲e̲t̲e̲r̲
Command queue empty?
Get command/error report
Internale report? I̲n̲t̲e̲r̲n̲a̲l̲e̲ figure 4.2.4.3.4.3.5-2
Case of command code
Input request? Signal to INBHAND
Cancel inp. req.? Command not allowed
Report status? L̲i̲n̲e̲ ̲c̲o̲m̲m̲a̲n̲d̲s̲ figure
4.2.4.3.4.3.5-3
Open channel? Signal to LINKPRO
Close channel? Signal to LINKPRO
End command case
Get control bytes
Test flags
Generate reports accordingly
End
FIGURE 4.2.4.3.4.3.5-1
I̲n̲t̲e̲r̲n̲a̲l̲e̲
ASYNC status report?
Completion code NE 0? Send buffer to host
Queue buffer to TX-status
FIGURE 4.2.4.3.4.3.5-2
L̲i̲n̲e̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲
Case of subcommand
Enable? Verify enable command
Init table accordingly
Signal to LINKPRO
Open Protocol? Signal to LINKPRO
Close Protocol? Signal to LINKPRO
Statistic? Generate statistic report
Status ? Generate status report
Device status? Generate device status
report
End subcommand case
FIGURE 4.2.4.3.4.3.5-3
4.2.4.3.4.4 M̲o̲d̲u̲l̲e̲ ̲L̲I̲N̲K̲P̲R̲O̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.4.3.4.4.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This module is the "master" module in the LTUX-LSL.
It controls all data transfer based on the state of
the V24-lines and based on the commands received from
the command interpreter.
4.2.4.3.4.4.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Thru the control table the module receives the necessary
information from the other modules. The module receives
no data pockets from any module.
4.2.4.3.4.4.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Module consists of a program part, a state/event table,
a number of actions and some special subroutines.
4.2.4.3.4.4.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The module refers to a number of fields in the control
table, the most important being the control byte (LINKCONT)
and the timer fields. For more details refer to section
4.2.4.3.5 Common subpackages data.
4.2.4.3.4.4.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
L̲i̲n̲k̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲
Update all active timers
Get V24 state of JACK
Update V24-event-field
Get link control byte
No flags set? Event based on V24 state
Determine event
Determine new state
Determine action
A̲c̲t̲i̲o̲n̲s̲ figure 4.2.4.3.4.4.5-2
End
FIGURE 4.2.4.3.4.4.5-1
A̲c̲t̲i̲o̲n̲s̲
Case of action
LINKA000? no action
LINKA010? open out of sequence
LINKA020: close out of sequence
LINKA030: start open protocol
LINKA040: complete open protocol
LINKA050: open failed
LINKA060: open command overrided
LINKA070: drop V24-line 106 and 107
LINKA080: drop V24-line 106
LINKA090: drop V24-line 107
LINKA100: device failure due to drop 106 and
107
LINKA110: clean-up for restart
LINKA120: device failure due to close protocol
LINKA130: device failure due to paper out
LINKA140: recover after device failure
LINKA150: device failure due to drop 106
LINKA160: device failure due to drop 107
LINKA170: device failure due to unexpected action
LINKA180: V24-OK but paper out
LINKA190: error restart (master clear LTUX)
LINKA200: 106, low, check for timeout
LINKA210: 107 low, check for timeout
LINKA220: 106 and 107 low, check for timeout
LINKA230: waiting for V24-OK, check open timer
End action case
FIGURE 4.2.4.3.4.4.5-2
C̲l̲o̲s̲e̲ ̲d̲o̲w̲n̲ ̲a̲f̲t̲e̲r̲ ̲d̲e̲v̲i̲c̲e̲ ̲e̲r̲r̲o̲r̲
Disable transmitter
Disable receiver
Drain receiver registers
Close V24 line
Update state of V24
Stop used timer
Signal dev. fail for OUTBHAND
Device EQ MSTP?
Signal dec. fail to INBHAND
Return
FIGURE 4.2.4.3.4.4.5-3
V̲2̲4̲-̲l̲i̲n̲e̲ ̲1̲0̲6̲ ̲t̲i̲m̲e̲o̲u̲t̲ ̲o̲r̲ ̲1̲0̲7̲ ̲t̲i̲m̲e̲o̲u̲t̲
Get state of timer
No timeout?
Signal timeout to LINKPRO
Reset timeout
Return
FIGURE 4.2.4.3.4.4.5-4
Fig. 4.2.4.3.4.4.5-5…01…Determination of V24-event
Fig. 4.2.4.3.4.4.5-6…01…LINKPRO state/action tables
4.2.4.3.4.5 M̲o̲d̲u̲l̲e̲ ̲O̲U̲T̲B̲H̲A̲N̲D̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.4.3.4.5.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This module controls the transmission of data. When
a LDU is finished (or transmission repeated) a transmission
status report is generated (completion forwarded to
CMDINT and corresponding flag set).
4.2.4.3.4.5.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Information status about changes in the link protocol
(LINKPRO) are received in the control table by OUTBCONT.
Full data buffers are received in queue INFTQ. The
buffers are "ready to transmit", i.e. IOC - records
have been processed and carriage return/line feed have
been inserted.
Buffers are delivered for transmission by interrrupt
routine thru the control table. The pointer and byte
count areas (TXBYTES, TXNEXTL, TXNEXTM) are loaded
with the current values. Whenever a buffer has to be
cancelled it is returned as empty in the queue INETQ.
4.2.4.3.4.5.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Module contains 4 parts: Event determination, state/action-tables,
action programs and special subroutines. 4 subroutines
are defined, ref. overleaf.
4.2.4.3.4.5.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
The module uses the common control table. Most important
is the OUTBCONT byte in which events are received from
other modules. The transmission control section storing
buffer links element, current position and bytes lift
is important too. For details refer 4.2.4.3.5.
4.2.4.3.4.5.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The module is state/event controlled with the first
part used to determine actual event.
Outbound Handler
Get outbound control byte
No flags set? Transmission active?
Buffer ready? Event EQ LDU type
Not cancel on this
LDU?
Event EQ cancel
MSTP status
req. timeout Event EQ status request
Determine new state
Determine action
O̲u̲t̲b̲o̲u̲n̲d̲ ̲A̲c̲t̲i̲o̲n̲s̲
Return
FIGURE 4.2.4.3.4.5.5-1
O̲u̲t̲b̲o̲u̲n̲d̲ ̲a̲c̲t̲i̲o̲n̲s̲
case action of
OUTBA000? no action
OUTBA010? start TX of buffer, POL or LOL
OUTBA020? cancel buffer
OUTBA030? generate TX-status = OK
OUTBA040? not used (spare)
OUTBA050? cancel buffer, gen. device error
OUTBA060? cancel buffer, gen device status errror
OUTBA070? release buffer, gen. device error
OUTBA080? release buffer, gen. device status
error
OUTBA090? release buffer due to cancel cmd
OUTBA100? cancel SOL/EOL due to cancel cmd
OUTBA110? Unexpected start of LDU
OUTBA120? Restart status request timer
OUTBA130? Output MSTP status request
OUTBA140? Stop TX of status request
OUTBA150? Error restart (master clear LTUX)
OUTBA160? Start TX of buffer, SOL or EOL
OUTBA170? Clean-up for restart
end of action cases.
FIGURE 4.2.4.3.4.5.5-2
Copies of state/action table are shown below.
Fig. 4.2.4.3.4.5.5-3
OUTBHAND state and action tables
OUTBHAND subroutines
FIGURE 4.2.4.3.4.5.5-4
4.2.4.3.4.6 M̲o̲d̲u̲l̲e̲ ̲I̲N̲B̲H̲A̲N̲D̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.4.3.4.6.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
Controls the transport of LDU's from device to CR80.
The module will wait for device ready and input request
before releasing any buffer for transmission on the
TDX-system. The module is only called when device is
TRC/point ̲to ̲point or PTP/PTR.
4.2.4.3.4.6.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
External events are signalled to the module in the
control table, byte INBCONT. The current LDU no. to
insert in case of LDU-TYPE = SOL/EOL is read from control
table too (byte RLDU ̲NO). For details ref. section
4.2.4.3.5.
Bufer ready to transmission on the TDX-bus are received
in queue INFRQ. When a buffer is released for transmission
on TDX-bus, subdevice no. (1 + JACK no.) is used.
When a buffer is descarded it is inserted as empty
in the queue INWRQ.
4.2.4.3.4.6.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
As many of the other modules this contains 4 parts:
event determination, state/action table, action programs
and special subroutines. Only one subroutine is defined;
ref. below.
SUBROUTINE RESET ACP 127 ANALYSER ACPRESET
PROGRAMMER: CAH
DESCRIPTION: The subroutine reset the ACP 127 syntax
analyser in case of device (status) error. Current
buffer used is released, stack is reset and all other
relevant areas in control table are reset too. Current
LDU-type is set to start of LDU. Syntax analyser state
is set to 0.
ENTRY: IX: Start of Jack control table.
EXIT: -
REGISTERS AFFECTED: AF, BC, DE, HL
RESTRICTIONS: None
EXECUTION TIME: Long
4.2.4.3.4.6.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲s̲
The module uses the common control table. The INBCONT
byte is the most important part (as in any other module).
For details ref. section 4.2.4.3.5.
4.2.4.3.4.6.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The module is state/event controlled with the first
part used to determine actual event.
INBHAND
Get control byte
No flags set? Receiver timeout? Full receiver
queue not empty?
Event EQ 8
Dequeue full receiver queue
Buffer not available?
Event EQ LDU-type
Determine new state
Determine action
I̲n̲b̲o̲u̲n̲d̲ ̲a̲c̲t̲i̲o̲n̲s̲
Return
FIGURE 4.2.4.3.4.6.5-1
I̲n̲b̲o̲u̲n̲d̲ ̲a̲c̲t̲i̲o̲n̲
Case action of
INBA000: No action
INBA010: Discard buffer
INBA020: Transmit buffer as SOL/EOL*
INBA030: Transmit buffer as POL/LOL*
INBA040: Clean-up after device error
INBA050: Clean-up after dev. status error
INBA060: SOTF-interruption*
INBA070: Reset when device ready
INBA080: Generate reciver timeout report
INBA090: Clean-up for restart
End of action case
* A̲b̲b̲r̲e̲v̲i̲a̲t̲i̲o̲n̲:
LDU: Logical data unit
SOL: Start of LDU
POL: Part of LDU
LOL: Last of LDU
ENL: Entire LDU
SOTF: Start of transmission function (ACP127 sequence:
VZCZC).
FIGURE 4.2.4.3.4.6.5-2
4.2.4.3.4.7 M̲o̲d̲u̲l̲e̲ ̲M̲S̲T̲P̲S̲Y̲N̲T̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.4.3.4.7.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
The Medium Speed Tele Printer syntax analyser is responsible
for the supervision of the MSTP status. Module reads
the status reports received from the printer and signal
any changes to the link protocol and to the command
interpreter if a report has to be generated.
4.2.4.3.4.7.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Reports are read character by character from the receiver
FIFO. Information about changes are forwarded to relevant
modules thru the control table. When the status reports
are read and interpreted the characters are discarded.
The MSTP transmit at status report whenever a change
has occurred (paper in/out, key on/off, audio on),
when a status polling has been received (issued by
OUTBHAND) or as a response to a control command (tabset
etc.). For details ref. Tracor Document Number T-81-AU-9806-U
Rev. C: Vertical Tabulation Format Specification for
Medium Speed Printer Program.
4.2.4.3.4.7.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Module consists of a code part reading the actual report
from RXFIFO and an action table by which it states
changes and relevant action are determined. A special
table is defined for system start.
4.2.4.3.4.7.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Module uses the control table for signalling of MSTP
status changes (bytes CMDCONT1, CMDCONT2, LINKCONT,
OUTBCONT and FAILCODE). For details ref. section 4.2.4.3.5.
4.2.4.3.4.7.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
MSTP Syntax Analyser
Character not available?
Syntax state EQ 0? Character EQ 7FH? Set syntax state
to 1
Char EQ 10H, 20H
or 40H? Report to CAMPS
Set sentax state
to 0
Character not
valid? Report to CAMPS: Unexpected device
action
First report after
open protocol? Get special state table
Get state table
Combine new state with old
Save new state
Get and do action
Return
FIGURE 4.2.4.3.4.7.5-1
4.2.4.3.4.8 M̲o̲d̲u̲l̲e̲ ̲A̲C̲P̲1̲2̲7̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.4.3.4.8.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
When device type is paper tape reader or TRC/point
̲to ̲point messages are received in ACP127 formats. Each
message will be forwarded to CAMPS as one LDU. This
module uses the ACP127 start-of-transmission function
and end-of-message function to detect start and end
of message. In case of error (missing end-of-message)
a receiver timeout is generated. An unexpected start
of transmission report may be generated to.
The modules store the message as IOC-records using
either ends of-line function or character type shift
to terminate current IOC.
The definitions used for start-of-message, end-of-line
and end-of-message are shown overleaf.
The IOC-record types used are:
0: Letter characters, no end-of-line
1: Letter characters, end-of-line detected
4: Control characters
Start of message: VZCZC and ZCZC sequence. The sequence
is recognized anywhere in the input sequence.
End of line: Any combination of up to 20 carriage return/line
feed characters. End of line are detected when both
a carriage return and a line feed has been received
(any sequence). Additional CR LF are transferred
to the CR80 as control characters. If 20
CR have been received without LF (or vice versa)
the search for end of line are stopped (for this sequence)
and the characters are transferred to the CR80 as a
control record. Examples:
"CR" "LF" "LF" "result in "EOL" + "LF"
"LF" "LF" "CR" result in "EOL"
"LF" "CR "LF" "CR" "LF" result in "EOL" + "LF" "CR"
"LF
End of message (EOM):
"EOM" = "EOL" CTRL "NNN" CHAR CTRL
"EOL" = as above
CTRL = control character (ASCII LT #20)
CHAR = character (ASCII #20 to #7E)
Only the optional control characters are transferred
to the CR80.
4.2.4.3.4.8.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
Characters are received one by one in the RX-fifo.
Completed buffers (full or end-of-message/RX-timeout
detected) are delivered in queue INFRQ. Empty buffers
are fetched from INWRQ.
As usual the control table is used for information
exchange with other modules.
This module is only activated if device type is TRC/point-to-point
or PTP/PTR.
4.2.4.3.4.8.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Module is state/event controlled with one section determing
actual event, one section with the event, state and
action table, one with the action code-segments and
one with the special subroutines. The subroutines used
are described below.
Fig. 4.2.4.3.4.8.3-1
ACP127 subroutines
Fig. 4.2.4.3.4.8.3-2
ACP127 subroutines
4.2.4.3.4.8.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
In excess of the usual control table usage this module
uses a stack for the ACP127 analysis. Characters are
stored on stack one by one as they are read from the
RX-FIFO. Whenever an IOC-record is identified (e.g.
due to end ̲of ̲line) IOC-type, byte-count and record
separator is inserted in the b̲o̲t̲t̲o̲m̲ of the stack. Then
the actual no. of bytes plus IOC-header are flashed
to the current buffer. If buffer i running full the
full buffer is released (inserted in INFRQ) and the
rest of the bytes are inserted in a new buffer. Due
to this ACP127 analysis is only executed when at least
one empty buffer is available in INWRQ.
The bytes used in the control table are shown below.
Also ref. section 4.2.4.3.5
Fig. 4.2.4.3.4.8.4-1
ACP127 part of control table
4.2.4.3.4.8.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
ACP127:
Less than min. no. of buffer in INWRQ?
Some special events? Determine event
Read char. from FIFO
Char. not available?
Determine event
Get new state
Determine action
A̲C̲P̲1̲2̲7̲ ̲a̲c̲t̲i̲o̲n̲s̲
Return
FIGURE 4.2.4.4.8.5-1
A̲C̲P̲1̲2̲7̲ ̲a̲c̲t̲i̲o̲n̲s̲
Case actions of
ACPAC000? Dummy action
ACPAC010? Stack character
ACPAC020? IOC type 0
ACPAC030? IOC type 4
ACPAC040? Stack character
ACPAC050? IOC type 4
ACPAC060? 69 characters to IOC type 0
ACPAC070? 69 characters to IOC type 4
ACPAC080? Stack "CR" or "LF"
ACPAC090? Stack character, char. cnt.=Stack
counter
ACPAC100? Char. cnt.=stack counter, stack
character
ACPAC110? Start of transmission detected
ACPAC120? Stack "CR" or "LF"
ACPAC130? Stack "CR" or "LF"
ACPAC140? "EOLF" detected
ACPAC150? "EOLF" not accepted
ACPAC160? Stack to IOC type 0 and type 4
ACPAC170? Stack to IOC type 0 and type 4
ACPAC180? "EOM" detected
ACPAC190? RX-timeout
ACPAC200? RX-timeout
ACPAC210? RX-timeout
ACPAC220? RX-timeout
ACPAC230? "CR" "LF" counter GT 20
ACPAC240? Error loop
End of action case
FIGURE 4.2.4.4.8.5-2
SUBROUTINES XFTOFOC Transfer bytes from stack
to IOC record
SUBROUTINES GTBUFFER Get buffer from INWRQ
SUBROUTINES RELBUF Releace buffer to INFRQ
SUBROUTINES STACK Transfer characters to
top of stack
SUBROUTINES RXTIMOUT Receiver timeout cleanup
Fig. 4.2.4.3.4.8.5-3
ACP state/action tables…01…(f(event, old ̲state), g (event, old ̲state)
4.2.4.3.4.9 M̲o̲d̲u̲l̲e̲ ̲I̲N̲T̲E̲R̲R̲U̲P̲T̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.4.3.4.9.1 F̲u̲n̲c̲t̲i̲o̲n̲a̲l̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
This is the low level communication module. The subroutines
defined are all interrupt activated (except for TXSTOP)
and deal with character I/O and SIO control.
4.2.4.3.4.9.2 M̲o̲d̲u̲l̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The subroutines defined are called from the corresponding
interrupt routine in the V24DRV module. The routines
uses the general control table, ref. section 4.2.4.3.5.
4.2.4.3.4.9.3 M̲o̲d̲u̲l̲e̲ ̲C̲o̲m̲p̲o̲n̲e̲n̲t̲s̲
Module contains 5 subroutines, ref. section module
design.
4.2.4.3.4.9.4 D̲a̲t̲a̲ ̲D̲e̲s̲c̲r̲i̲p̲t̲i̲o̲n̲
Two bytes in the control table are of special interest:
TXTEMP and TXRQBTS. TXTEMP is used as a temporary storage
location when characters are converted from ITA5 to
ITA2. Whenever a shift character has to be transmitted
before the actual character, the latter is stored in
TXTEMP.
TXRQBTS is a special byte count field used when a status
request is transmitted to the MSTP.
4.2.4.3.4.9.5 M̲o̲d̲u̲l̲e̲ ̲D̲e̲s̲i̲g̲n̲
The subroutines are shown on the following pages.
Transmitter interrupt ()()
Restart status request timer
Have a temporary char. ?
Nest TX-byte valid? More bytes to send? Update
pointer
Convert
TX-character
(char.)(convertedchar.)
Release buf. to INETQ
Clear bytes in cont. table
Don't sending sta. req.?
All bytes send? Indicate
buffer
finish
Udate bytes left counter Stop transmitter
()()
Counter EQ zero? Get char. "CR"
Get char. "S"
Send character
Return
FIGURE 4.2.4.3.4.9.5-1
Receiver char. interrupt ()()
Restart receiver timer
Read character
Receiver char. convert (char.)(converted char.)
Parity error? Load replace character
Device not MSP? Char. EQ zero? Stop receiver timer
Write char. to RX-FIFO
RX-FIFO full? Indicate error
Return
FIGURE 4.2.4.3.4.9.5-2
Special Receiver Conditions ()()
Read Error Status ()(status byte)
Framing error? Indicate RX char. error
Increment no. of framing error
Receiver overrun? Indicate receiver error
Send error report
Increment no. of RX overrun
Parity error? Indicate RX char. error
Increment no. of parity error
Return
FIGURE 4.2.4.3.4.9.5-3
Externale Status Interrupt (status byte)()
Break/abort? Indicate receiver error
Send error report
Return
FIGURE 4.2.4.3.4.9.5-4
Stop Transmitter ()()
Reset TX interrupt pending
Indicate transmission stopped
Return
FIGURE 4.2.4.3.4.9.5-5
4.2.4.3.4.10 M̲o̲d̲u̲l̲e̲ ̲V̲2̲4̲ ̲D̲R̲I̲V̲E̲R̲ ̲S̲p̲e̲c̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
4.2.4.3.5 C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲D̲a̲t̲a̲
To ensure that modules may be used reentrant all variables
are assembled in a control table. The variables are
addressed by use of the Z80 index register IX plus
on offset. The variable is defined by the value of
this offset. In the actual design 4 control tables
are defined, one table per JACK. The tables are completely
independent.
A number of constants are used which are specific to
the LTUX-LSL subpackage. Their names, values and usage
are shown in the listing of LSL ̲NAMES.
4.2.4.3.6 C̲o̲m̲m̲o̲n̲ ̲S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
The subroutines are assembled in the module KERNEL.
On the following pages they are described by their
subroutine headers. The following subroutines are defined:
GENRESPO
GENASYNC
RANGE
RESFIFO
GETFIFO
PUTFIFO
SWTIM
LOOKUP
TX ̲CONV
RX ̲CONV
INIT QUARE
CASE
FIGURE 4.2.4.3.6-1
FIGURE 4.2.4.3.6-2
FIGURE 4.2.4.3.6-3
FIGURE 4.2.4.3.6-4
4.2.4.3.7 S̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲s̲
refer section 4.2.4.1.7
IKKE BRUGT I ISSUE 2.
*********************************
The operation of the LTUX-LSL is controlled by a no.
of commands issued by the CR80. The LTUX generates
responser and asynchronous status reports telling about
the current state of the LTUX or the connected devices.
The command layout is shown on the following pages
(ref. I/0 control detailed design specification). A
few comments are given below.
o Open channel command. Establishes the communication
between the CR80 and the LTUX on said subdevice.
o Enable protocol. A detailed specification of the
device connected to the jack corresponding to actual
subdevice. The command contains information about
device type, band rate, V24-usage, parity and stop
bits, timer presets and alphabet used.
o Open protocol. The final activation of the device.
When this command has been executed data may be
output to/read from the device.
Whtn data are transferred to/from the LTUX, the standard
LDU/IOC principle is used. For further details ref.
CR80 LTU I/F functional specification (CSS-MIC/040/FNC/0001)
section 3.2 and 3.4. Moreover ref. I/O control detailed
design specification (CPS/SDS/028) section 4.1.7.2.2:
Data transport interfaces.
When operating as PTP/PTR or TRL the LTUX performs
a basic ACP127 analysis, recognizing start of message,
end of line and end of message as specified below.
The start of message detection results in the generation
of a start of LDU. The actual pattern is thus always
transferred as the first characters in a start of LDU.
The end of line detection results in the termination
of the current IOC-record. The end of line characters
are deleted. The end of message detection results in
the termination of the current LDU (last of LDU or
entire LDU). The end of message characters are not
transferred
Start of message: VZCZC and ZCZC sequence. The sequence
is recognized anywhere in the input sequence.
End of line: Any combination of up to 20 carriage return/line
??? characters. End of line are detected when both
a carriage return and a line ??? has been received
(any sequence). Additional CR LF are transferred
to the CR80 as control characters. If 20
CR have been received without LF (or vice versa)
the search for end of line are stopped (for this sequence)
and the characters are transferred to the CR80 as a
control record. Examples:
CR LF LF EOL +
LF LF CR EOL
LF CR LF CR LF EOL + LF CR LF
End of message (EOM):
EOM : : = EOL CTRL NNN char CTRL
EOL : : = as above
CTRL : : = control character (ASCII #20)
CHAR : : = character (ASCII = #20)
Only the optional control characters are transferred
to the CR80.
All handlers interface to the LTUX function subpackage
as specified below.
L̲T̲U̲X̲ ̲H̲a̲n̲d̲l̲e̲r̲ ̲-̲ ̲L̲T̲U̲X̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲ ̲s̲u̲b̲p̲a̲c̲k̲a̲g̲e̲ ̲i̲n̲t̲e̲r̲f̲a̲c̲e̲.̲
The interface is as specified in TDX handler based
on the LDU concept.
byte 0 specifies CONTROL or DATA plus
START ̲OF ̲LDU, END ̲OF ̲LDU,
PART ̲OF ̲LDU, ENTIRE ̲LDU
For DATA the second byte in the first buffer of
an LDU gives the LDU sequence number.
For CONTROL outgoing the second byte gives the
control type:
INPUT ̲REQUEST, CANCEL ̲OUTPUT,REPORT ̲STATUS ̲REQUEST,
OPEN ̲CHANNEL, CLOSE ̲CHANNEL.
For incoming CONTROL (also called STATUS) the second
byte gives the STATUS type
TRANSMISSION ̲STATUS, RECEPTION ̲STATUS,
INTERRUPT( A synchronous report), PROTOCOL ̲STATUS
Data input/output is performed with the standard
requests as follows:
I̲n̲p̲u̲t̲
INPUT ̲REQUEST has following format
byte 0-1 Standard
byte 2 LDU identification for input
Input data is transferred in LDU's consisting of buffers
of type.
START ̲OF ̲LDU, PART ̲OF ̲LDU, END ̲OF ̲LDU or ENTIRE ̲LDU.
END ̲OF ̲LDU or ENTIRE ̲LDU means that the LDU has been
read with no error. If an error occurs these types
are not returned, but the LTUX returns (after last
good data) an
RECEPTION ̲STATUS with following format:
byte 0-1 Standard
byte 2 LDU identification
byte 3 Completion code:
DEVICE ̲STATUS ̲ERROR,
DEVICE ̲ERROR
TIME ̲OUT
SOTF ̲INTERRUPTION
For each handler the input interface specification
are:
T̲R̲C̲ ̲T̲P̲
LDU's are normally terminated on reception of "NNN"
in the beginning of a line (and includes the full line).
Abnormal termination is on cancel, Halted Message timeout,
dual occurrence of Start of Transmisson Function (and
parity error if so specified).
IOC records are of type LINE ̲FLAG, DATA ̲FLAG or
CONTROL ̲FLAG.
P̲T̲P̲ ̲P̲T̲R̲
Termination as TRC ̲TP
IOC records are generated as of TRC ̲TP.
O̲U̲T̲P̲U̲T̲
Output data is transferred in LDU's consisting of buffer
types
START ̲OF ̲LDU, PART ̲OF ̲LDU, END ̲OF ̲LDU and
ENTIRE ̲LDU
The output data is either straight for output (when
CONVERTER ̲STATE = OFF) or recorded in IOC records (when
CONVERTER ̲STATE = ON)
The output is completed by the LTUX returning an TRANSMISSION
̲STATUS to the handler
byte 0-1 Standard
byte 2 LDU
byte 3 Completion Code
OK, CANCELLED
DEVICE ̲STATUS ̲ERROR
DEVICE ̲ERROR,
BAD ̲DATA
The codes may in general occur as follows:
CANCELLED when cancel requested
DEVICE ̲STATUS ̲ERROR e.g. paperout on MSTP.
DEVICE ̲ERROR
The state of the protocol is not running possibly due
to timeout on 106, 107, or due to VDU retransmission
count overrun.
ILLEGAL ̲DATA
The occurrence of control characters in output records
of type DATA ̲FLAG or LINE ̲FLAG
The specialities for each device are
M̲S̲T̲P̲
An output LDU needs not to be on a IOC record boundary
Conversion of LINE ̲FLAG records to "CR, CR, LF"
T̲R̲C̲ ̲T̲P̲
An output LDU needs not to be on IOC record boundary
Conversion of LINE ̲FLAG records to "CR, CR, CF"
P̲T̲P̲/̲P̲T̲R̲
As for TRC ̲TP
C̲O̲N̲T̲R̲O̲L̲ ̲I̲N̲T̲E̲R̲F̲A̲C̲E̲
Commands to the LTUX
ENABLE
byte 0-1 Standard
byte 2 Identifier
byte 3 Command Code = ENABLE
byte 4-15 Level 1 parameters
byte 4 Spare
byte 5-9 Parameters for selected
mode
byte 5 USE ̲105 ̲106
byte 6 TIME ̲OUT ̲106
byte 7 USE ̲108 ̲107
byte 8 TIME ̲OUT ̲107
byte 9 Spare
byte 10-15 Other level 1
byte 10 LTUX ̲BAUDRATE
byte 11 STOP ̲BITS
byte 12 PARITY
byte 13 CHAR ̲SIZE
byte 14-15 Spare
byte 16-22 Level 2 parameters
byte 16 L2 ̲PROTOCOL
byte 17-22 Protocol parameters
For MSTP ̲PROTOCOL
byte 17 Spare
byte 18 Key Status request repeat
rate (1..255) x 128 msec.
(when no LDU in output)
byte Spare
For TRC ̲TP PROTOCOL
byte 17 ALPHABET
byte 18 Halted Message Timeout
1..255) x 128 msec.
byte 19 Parity error replace character
byte 20-22 Spare
For PTP ̲PTR PROTOCOL
as for TRC ̲TP
OPEN ̲PROTOCOL
byte 0-1 Standard
byte 2 Identifier
byte 3 OPEN ̲PROTOCOL
Open means: Setup interface lines according to ENABLE,
wait for 106, 107 if included (DTE). Furthermore for
VDU attempt to set VDU in block mode and request status
(error if status not available).
Furthermore for MSTP attempt to request status (error
if status not available).
During OPEN ̲PROTOCOL, CLOSE ̲PROTOCOL is accepted by
the LTUX.
CLOSE ̲PROTOCOL
byte 0-1 Standard
byte 2 Identifier
byte 3 CLOSE ̲PROTOCOL
Takes down V24 as opposed to OPEN ̲PROTOCOL
STATISTICS
byte 0-1 Standard
byte 2 Identifier
byte 3 STATISTICS
All statistics are collected in 16 bit counters and
reset upon request.
For all DTE protocols following can be requested:
Number of 106 drops (if included)
Number of 107 drops (if included)
For VDU
Number of parity errors
Number of framing errors
Number of RX overrun errors
STATUS
byte 0-1 Standard
byte 2 Identifier
byte 3 STATUS
STATUS may be requested any time
DEVICE ̲STATUS
byte 0-1 Standard
byte 2 Identifier
byte 3 DEVICE ̲STATUS
The DEVICE ̲STATUS is only relevant when PROTOCOL ̲STATE
= RUNNING
and only for VDU, MSTP and PTP ̲PTR Protocols.
Responses to commands ("Channel Status")
ENABLE response
byte 0-1 Standard
byte 2 Identifier (as of ENABLE)
byte 3 ENABLE
byte 4 = 0 OK
Else error
OPEN ̲PROTOCOL response
byte 0-1 Standard
byte 2 Identifier (as of OPEN
̲PRO-
TOCOL)
byte 3 OPEN ̲PROTOCOL
byte 4 = 0 OK
= 1 Close during open
1 other error
CLOSE ̲PROTOCOL response
byte 0-1 Standard
byte 2 Identifier (as of CLOSE
̲PRO-
TOCOL)
byte 3 CLOSE ̲PROTOCOL
byte 4 = 0 OK
= 1 error
STATISTICS response
byte 0-1 Standard
byte 2 Identifier
byte 3 STATISTICS
byte 4 = 0
byte 5 Spare
byte 6-7 No of 106 drops
byte 8-9 No of 107 drops
byte 10-11 No of parity errors
byte 12-13 No of parity errors
byte 14-15 No of RX overview errors
For MTSP
No more bytes used.
For TRC ̲TP
No more bytes used.
For PTP ̲PTR
No more bytes used
STATUS response
byte 0-1 Standard
byte 2 Identifier
byte 3 STATUS
byte 4 = 0
byte 5 PROTOCOL ̲STATE
byte 6 Spare
byte 7 Spare
byte 8 S 105 = (OFF, ON)
byte 9 S 106 = (OFF, ON)
byte 10 S 107 = (OFF, ON)
byte 11 S 108 = (OFF, ON)
DEVICE ̲STATUS response
byte 0-1 Standard
byte 2 Identifier
byte 3 DEVICE ̲STATUS
byte 4 = 0 OK
= 4 Protocol not RUNNING
byte 5State (see below)
MSTP keylock, paper and audio alarm status
0 status all off
1 key locked
2 audio alarm
4 paper out
Status summed to give combined status.
Asynchronous reports
General format
byte 0 Control, Entire LDU
byte 1 INTERRUPT
byte 2 Code (see below)
byte 3 Data (if any, code depended)
General interrupts (only in state RUNNING)
Code IT ̲DEVICE ̲FAILURE A serious error on device
interface bringing the interface
from state RUNNING to state
ENABLED
byte 4 Error Code
DROP ̲106, DROP ̲107,
OUT ̲RETRANSMISSION, IN ̲RE-
TRANSMISSION
UNEXPECTED ̲CONTROL ̲CHAR ̲SEQUENCE
UNEXPECTED ̲DEVICE ̲ACTION
DROP ̲106 ̲AND ̲107
Code IT ̲S/W ̲ERROR
byte 4 Error code
LDU ̲ERROR,
IOC ̲RECORD ̲ERROR,
COMMAND ̲OUT ̲OF ̲SEQUENCE,
MISSING ̲INPUT ̲REQUEST
Code IT ̲TDX ̲ERROR
byte 4 Error Code
O4H = RECEIVE ̲TIME ̲OUT,
OCH = BUFFER ̲OVERRUN
Code IT ̲F/W ̲ERROR
byte 4 Error code
RECEIVER ̲OVERRUN ̲ERROR
Specific interrupts
M̲S̲T̲P̲ byte 2 IT ̲MSTP
Error codes from printer
byte 3 ITE
byte 4 the code (Hex 10, 20, 40)
Rub-out + status: Change of status on printer is reporter
as follows:
When keylock goes on or off
byte 3 ITL
byte 4 (OFF, ON)
When paperout goes on or off
byte 3 ITP
byte 4 (OFF, ON)
When audion alarm goes on
byte 3 ITA
