⟦6e867d47a⟧

TextFileVerbose

>tc $
>hc %
>a1 Functional Description.
>a2 HDLC Protocol.
The RC3502 HDLC driver implements a packet switching data transmission
in accordance with CCITT revised Recommendation X.25 level 2 lapB. (1)
The driver supports both the DCE and the DTE selectable by the user
process, see section 1.3 .
>sp0
An HDLC driver incarnation supports one DTE or DCE, hereafter called
one
>ul
line
consisting of a receive and a transmit
>ul
link_channel
.
>a2 Driver Structure.
The HDLC driver process consists of three processes:

- An HDLC driver process, which is the main process
created by the user and which executes on level 0.

- A receiver interrupt process, created by the main
driver process, which executes on the receiver
interrupt level.

- A transmitter interrupt process, created by the main driver
process, which executes in the transmitter interrupt
level.

The HDLC driver is identified to the user by the HDLC request
semaphore, which is a process parameter supplied by the user when
the driver process incarnation is created. All messages from the
user to the HDLC driver is sent to this semaphore.
>ne 33
>sp 31
>ms tegning!
>fg HDLC Driver Structure.
>a2 Line States.
At any time a line will be in one of the following states:

- Disconnected, there is no connection with the other
end and no attempt is made to obtain a connection.

- Connecting, there is no connection with the other
end but attempts are made to obtain a connection.

- Connected, there is a physical and logical connection
with the other end.

Initially the line state is disconnected. The line state is changed
to connecting (@and, when possible, connected@) by means of a
connect message. A disconnect message will change the line state to
disconnected. Detection of a fatal error on the transmission line or
protocol logic will also change the line state to disconnected or
connecting depending on whether autoconnect has been specified or not.
>sp0
A connect message may specify autoconnect, which causes the line to
enter connecting state as result of a fatal error instead of disconnected
state.
>sp0
A connect message also specifies which role the driver should play in the
communication:

- DTE,

- DCE, or

- alternating DTE / DCE until the connection
has been completed successfully and the line
state connected entered.

>a2 General Description of Driver Functions.
The HDLC driver maintains a binary transparent point-to-point transport
facility. This implies that the driver will not return answers to
transput messages until the data transportation to / from the other end
has been acknowledged properly or until the user explicitly requests the 
driver to return unacknowledged message buffers.
>sp1
A number of control message types enables the user to supervise and
control driver functions:
>sp1
- Line control messages are used to control
the line state.

- Buffer control messages are used to control
premature returnal of transput messages queued
at the driver.

- Modem control messages are used to control
the modem signals generated by the COM201
line adaptor.

- Sense messages are used to obtain status
information, i.e. incoming modem signals,
statistic information. A special sense line
speed causes the driver to measure the modem
clock frequency by transmitting a number of
illegal data packages while measuring the
transmission time.

- Event messages are used to report changes in
the line state. Event messages are, as the
only control messages, queued at the driver
until a line state change occurs.

- Testoutput messages are used to control
collection of testoutput and to obtain a
copy of the collected driver testoutput.

All control messages, except event messages and some testoutput messages, are executed and returned
immediately.

Transput messages are executed with a maximum data stack depth of 3.
>br
The first databuffer of an inputmessage
must have a capasity of at least 3 bytes, i.e. 
last-first>=2.

Output messages are executed according to their priority. The priority, 
however, has significance only until the data has been transmitted
once. Input messages are executed sequentially.

The user should make no assumptions on the order of returnal of
transput messages.
>a2 Modem Signal Considerations.
Although The CCITT har recommended certain standards for the utilization
of modem signals in X.25, these standards are not always followed at the
various installations using X.25 . Therefore the driver considers
incoming modem signals during normal traffic (@line state connected@) 
as informative only, e.g. Data Carrier Detect going low does not cause
the driver to initiate error recovery.
>br
The modem signals are examined at termination of transmission and
reception and the statistics updated accordingly.

Outgoing modem signals are controlled using modem control messages.

In line state connecting, however, the following modem signal
protocol is maintained by the driver prior to the logical
connection action:

>tb3 a.
Data Terminal Ready and Request To Send is set.

>tb3 b.
Data Set Ready and Clear To Send = high is awaited.
>a2 Testoutput.
The driver enables collection of testoutput, which consists of a trace
of protocol level events for the line.
>br
testoutput is collected in
a local area in the driver process. The testoutput can be read using
a testoutput message, which may also be used to 
set a testmask whitch control the collection.
>br
Note however that collection of testoutput will increase the PU-load
of the driver slightly.

Each testoutput record contains information about:
>sp1
- Time (@relative in 100 millisec.@)

- Address and control byte transmitted or received.

- u1 and u3 of received messages.

- Hardware status information.

>a1 Driver Interface.
This section describes the interface between the user process and the
HDLC driver.
>a2 Driver Process Creation.
The HDCL driver name ( used in LINK call ) is

    hdlc

The HDLC driver incarnation should be created with following parameters:

    ( req_sem: semaphore; rec_level: integer )

>tb10 req_sem
is the semaphore to which all messages to the driver should be
signalled.

>tb10 rec_level
is the interrupt level for the COM201 receiver; the transmitter
level is hardware defined as receiver level@+@1.

See section 3 for required stack size.

The driver may be started with any priority, but in order to minimize
retransmissions caused by receiver overrun a high coroutine priority
is recommended.
>a2 Driver Messages.
Messages signalled to the driver semaphore (req_sem) should observe
the standard for driver interfaces (2,3,4), especially the result
byte, u2, should always be set to 7 enabling the driver to distinguish
user messages from answers to own messages.

Note that messages signalled to the driver with wrong parameters
may cause an exception inside the driver process complex.

When messages are returned from the driver, u3 is always set to level,
which for all messages except write data messages is equal to the
driver process parameter rec_level. For write data messages u3 is set
to rec_level@+@1.

The result byte, u2, in messages returned from the driver will have the
result set according to standard (2). Where nothing else is mentioned,
the result modification will be zero.

In the description of user field contents for each message to and from
means user field contents when the message is signalled to / returned
from the driver.
A dash,@-@, means unused contents, and unch. means unchanged.
>ne14
>a3 Control Messages.
>a4 Sense Status message.
>ul
User Fields:
>sp1
     to          from
 u1  0+0         0+0
 u2  7           result
 u3  -           level
 u4  -           unch.

>ul
Data buffer:
Not used.
>sp1
>ul
Function:

Returns the line status in result (u2) in below format.

>ul
Result:

 result:= (line_state*8)@+@(modem_state*16)

 line_state:   0: disconnected,
               1: connected.

 modem_state: +1: DSR is on,
              +2: DCD is on,
              +4: SQD is on,
              +8: CI is on.
>ne10
>a4 Connect Message.
>ul
User@Fields:
>sp1
     to          from
 u1  0+4         0+4
 u2  7           result
 u3  -           level
 u4  -           unch.
>sp1
>ne10
>ul
Data@buffer@to@driver:
>in2
record
>in2
na1, na2, na3: integer;
>br
mode: packed record
>in8
na4:   0..3;
>br
no_s_commands,
>br
no_poll,
>br
delay_i_frames,
>br
delay_rr_frames,
>br
final_alarm,
>br
auto_connect:   boolean;
>in-2
end;
>in-6
connect_ident,
>br
t1,
>br
n2,
>br
k:             integer;
>in-2
end;
>in-2

>ul
Data@buffer@from@driver:
Unchanged.

>ul
Function:

System parameters for the line are set to the values in the data buffer.
>br
If the current line state is disconnected, it is set to connecting;
otherwise the line state is unchanged.

>ul
Parameters:

>in2
na1, na2, na3, na4: not used.

>tb15 no_s_commands:
s_commands is not transmittet in case of timeout.

>tb15 no_poll:
poll_bit is not transmittet in case of timeout, nither is s-commands.

>tb15 delay_inf:
no i_frame is transmittet after a rnr_frame is received.

>tb15 delay_rr:
rr_frame is not transmittet before 2 input_buffers are present and 
rnr_frame is transmittet when only 1 input_buffer is left.

>tb15 final_alarm:
cmdr is transmittet if an unsolicited responce with f_bit set to 1
is recieved.

>tb21 autoconnect:   true
means that the line will enter connecting state after a fatal error.
>ti-6
false@means that it will enter disconnected state after
having tried to reset n1 times.

>tb19 connect_ident: 0
means that the line will play the DTE-role in the X.25 protocol.
>ti-4
1@@@means the DCE-role.
>ti-4
n>2@means alternating DTE@/@DCE role with alternation each n*100@mSec.
>ti-4
n<0@is invalid.

>tb15 t1:
System timer t1 (retransmission timer), unit@=@100@mSec.
See (1) section 2.4.11.1@. t1<=0 is invalid.

>tb15 n2:
Maximum number of transmissions of a package, see (1) section 2.4.11.1@.
n2<1 is invalid.

>tb15 k:
Maximum number of outstanding frames, see (1) section 2.4.11.4@. Valid
vhen 0<k<8@.
>in-2

>ul
Result:
>in5
>ti-3
0:@@ok.
>ti-4
12:@@connection inpossible becourse linespeed%-measurement is going on.
>in-5

>ne10
>a4 Disconnect Message.
>ul
User Fields:

     to          from
 u1  0+8         0+8
 u2  7           result
 u3  -           level
 u4  -           unch.

>ul
Data Buffer:
Not used.

>ul
Function:

The line state is set to disconnected. The internal variable: autoconnect
is cleared.
>ne10
>a4 Return All Buffers Message.
>ul
User Fields:

     to          from
 u1  0+12        0+12
 u2  7           result
 u3  -           level
 u4  -           unch.

>ul
Data Buffer:
Not used.

>ul
Function:

The line state is set to disconnected. All transput messages
and event messages queued at
the driver are returned with result: not@processed and finally the
Return%-All%-Buffers message is returned with result: ok.
>ne10
>a4 Return Unused Buffers Message.
>ul
User Fields:

     to          from
 u1  0+16        0+16
 u2  7           result
 u3  -           level
 u4  -           unch.

>ul
Data buffer:
Not used.

>ul
Function:

All transput messages queued at the driver, which have not yet been used
(i.e. not yet transmitted@/ set up for reception) are returned with
result: not@processed. Finally the Return%-Unused%-Buffers message is
returned with result: ok.
>ne10
>a4 Modem Control Message.
>ul
User Fields:

     to          from
 u1  0+24        0+24
 u2  7           result
 u3  -           level
 u4  -           unch.

>ul
Data buffer to driver:

  record
    na1, na2, na3: integer;
    update_RTS,
    RTS,
    update_DTR,
    DTR:           boolean
  end;

>ul
Data buffer from driver:
Unchanged.

>ul
Function:

The modem signals are set as follows:

  if update_RTS then set_RTS(RTS);
  if update_DTR then set_DTR(DTR);
>ne10
>a4 Read Statistics Message.
>ul
User Fields:

     to          from
 u1  0+28        0+28
 u2  7           result
 u3  -           level
 u4  -           unch.

>ul
Data buffer to driver:
Not used.

>ul
Data buffer from buffer:

 dpinteger= record
              msb,
              lsb:  integer
            end;

 record
   na1, na2, na3: integer;
   received,                (* D.P. no of rec. infos *)
   transmitted,             (* D.P. no of xmit. infos *)
   skipped,                 (* D.P. no of err. rec. packages *)
   retransmitted:           (* D.P. no of re-xmit. infos *)
                  dpinteger;
   rec_RNR,                 (* no of rec. RNR *)
   xmit_RNR,                (* no of xmit. RNR *)
   rec_REJ,                 (* no of rec. REJ *)
   xmit_REJ,                (* no of xmit. REJ *)
   ack_timeouts,            (* no of timeout retrans. *)
   DSR_off,                 (* no of detected DSR off *)
   DCD_off,                 (* no of detected DCD off *)
   SQD_off,                 (* no of detected SQD off *)
   CI_on:                   (* no of detected CI on *)
                  integer;
   last_FRMR_data: packed record
                     rej_fc_field:    byte;
                     VR:              0..7;
                     responce:        boolean;
                     VS:              0..7;
                     na1:             bit;
                     na2,na3,na4,na5: bit
                     Z, Y, X, W:      boolean;
                   end;
   receiver_overrun,        (* no of receiver overrun *)
   transmit_underrun,       (* no of xmit. underrun *)
   receiver_abort,          (* no of receiver abort *)
   time,                    (* time in units of .1 sec *)
   rate:                    (* bytes/sec in sense linespeed *)
                  integer;
   future_use:    array (1..3) of integer
 end; (* statistic record *)

>ul
Function:

Read statistic information without resetting the counters to zero.
>ne10
>a4 Read and Clear Statistics Message.
>ul
User Fields:

     to          from
 u1  0+32        0+32
 u2  7           result
 u3  -           level
 u4  -           unch.

>ul
Data Buffer:
As Read Statistics Message above.

>ul
Function:

Read statistic information and reset the counters to zero.
>ne10
>a4 Sense Line Speed Message.
>ul
User Fields:

     to          from
 u1  0+36        0+36
 u2  7           result
 u3  tolerance   level
 u4  -           unch.

>ul
Data buffer:
Not used.

>ul
Function:

The modem clock frequency is measured by transmission of a number of
dummy blocks and the result (u2) is set accordingly.
This message is valid only when the line state is disconnected.
>br
The dummy blocks are transmitted with illegal address byte and terminated
with abort.
>br
The execution of this message will take one second.
>br
Note: A high PU-load may cause an inaccurate measurement.

tolerance=rel*16+abs gives the accepted deviation from nominal rate
>br
if cnt= no@of@byte transmittet in one sec. then a deviation of
>br
>ul
+
(@cnt@*@rel@/@100@+@abs@)
>br
from the nominal byte-rate is accepted.

>ne14
>ul
Result (u2):

 2+0   Line state not connected.
 0+8    110 bps.
 0+16   300 bps.
 0+24   600 bps.
 0+32  1200 bps.
 0+40  2400 bps.
 0+48  4800 bps.
 0+56  9600 bps.
 0+64  19.2 kbps.
 0+72  48   kbps.
 0+80  64   kbps.
 0+88  Not measurable.
>ne10
>a4 Event Message.
>ul
User Fields:

     to          from
 u1  0+40        0+40
 u2  7           result
 u3  -           level
 u4  -           unch.

>ul
Data buffer:
Not used.

>ul
Function:

Event messages are queued at the driver until a line state change occurs.
Then it is returned with result (u2) set accordingly.
>br
If no event message is present at the driver when a line state change
occurs, the last state change is saved and returned when an event message
arrives at the driver.
>br
Note: Only one line state change (i.e. the last) is saved for future
returnal.

>ul
Result:
>br
result:= cause*8+event_lost*128

>ne17
 cause:
  0:  connected.
  1:  disconnected by user.
  2:  DISC_frame received.
  3:  SABM_frame received.
  4:  UA_frame received.
  5:  DM_frame received.
  6:  CMDR_frame received.
  7:  controlfield uninteligible.
  8:  unsolicided response with f-bit.
  9:  size-error.
 10:  sequense error.
 11:  timeout, driver try to reset.
 12:  timeout, driver gives up.
 13:  receiver malfunction.
 14:  transmitter malfunction.
 15:  exception.
>ne10
>a4 Testoutput Message.
>ul
User Fields:

     to          from
 u1  0+44        0+44
 u2  7           result
 u3  tp_control  level
 u4  -           unch.

>ul
Data buffer to driver:
Not used.

>ul
Data buffer from driver:

 record
   first, last:   integer;
   next_cyclic:   integer;
   testbuffer:    array (0..30) of testellement
 end;

a testelement is 4 words
( 8 words in case of extended testoutput )

>ul
Function:

The function of a testoutput message is controlled by

>ce
tp_control = u3 = func+mask*4

as follows:
first the mask is saved and used to control whitch ellements
will be collected from now
then the action controled by func is performed.

>ne9
>in5
>ul
@mask@@@@@@@func@
>in-5
>br
u3:@
>ul
!5@4@3@2@1@0!x@x!

>ul
mask:

>tb7 bit0:
on/off bit: if=0 then no collecton takes place

>tb7 bit1:
collect answers from controler

>tb7 bit2:
collect messages from the aplication

>tb7 bit3:
collect messages to the transmitter

>tb7 bit4:
not used

>tb7 bit5:
collect during fifo sense

>ul
>tb6 func
action

>in1
>tb5 0:
the mask is saved only.

>tb5 1:
the testoutput buffer is copied into the message buffer.

>tb5 2:
the message is queued internal. Eatch time the testoutput
buffer is filled and this queu is not empty the testoutput buffer
is copied to the message buffer from the queue and returned.

>tb5 3:
all messages in the internal queu is returned with result=1. Then
action 1 is performed.

>in-1
The format of the collected testoutput is described in section 2.3@.
>br
Since the testoutput is collected cyclic, the testoutput buffer will
always be filled
with 31 testellements and the returned value of last points
to the last stored ellement in the cyclic buffer.
>np
>a3 Transput Messages.
>a4 Receive Message.
>ul
User Fields:

     to          from
 u1  1           1
 u2  7           result
 u3  -           level
 u4  -           unch.

>ul
Data buffer: Used according to standard.

>ul
Function:

The receive message is queued at the driver until an errorfree data
package has been received and acknoledged or until a Return Buffers
control message is signalled to the driver.

>ul
Result:

 0   The data buffer contains a legal data package.
 1   The message returnal is caused by a Return
     Buffers control message.
>ne10
>a4 Transmit Message.
>ul
User Fields:

     to         from
 u1  2          2
 u2  7          result
 u3  priority   level
 u4  -          unch.

>ul
Data buffer:
Used according to standard.

>ul
Function:

The transmit message is queued at the driver according to the priority
(u3)@. Priority is a value between 0 and 7 both incl. with increasing
value giving increasing priority.
The message is returned, when the data package has been
transmitted and acknoledged, or, when a Return Buffers control message
has been signalled to the driver.

>ul
Result:

 0+0  The data has been transmitted and
      acknoledged succesfully.
 1+0  The message returnal is caused by a
      Return Buffers control message. The
      data has not been transmitted.
 1+8  As result 1 except that the data has
      been transmitted one or more times.
>np
>a2 Testoutput Formats.
testoutputellement= packed record
  aux,
  kind:    byte;
  time:    integer;
  adr,
  command: byte;
  status:  integer;
  (* extended testoutput *)
    bstate:         0..4;
    rstate,
    xstate:         0..15;
    ystate:         0..2;
    j:              0..7;

    vi,
    tn:             0..7;
    t:              0..63;
    mstate,
    send,
    sending_i_frame,
    aborting:       boolean;
    rec_pointer,
    xmt_pointer:    array(0..3) of 0..15;
  (* end extended testoutput *)
 end;
>a3 Normal Testoutput.
Time is relative time in units of 0.1 sec. (@modulo 10000@).

status is the latest read status from the controler (@hexadecimal@).

The meaning of aux, adr, command depend of kind as follow's:

>ta 31 39 48
>nf
>ne12
kind$adr$command$aux

0 receiver answer$adr$cmd$alternate
$$$@@1  2
1 transmitter answer$adr$cmd$0
2 message$u1$RR(0)$u3
3 send to transmitter$adr$cmd$0
4 message(u2<>7)$u2$RR(0)$0
5 cmdr$cause$I(VS,VR)$0
6 cmdr$cause$cmd$0
7 read fifo$flags$0$0
8 exception$excause$DISC*$0
>fi
>a3 Extended Testoutput.
>tb13 bstate:
inputbuffer state. 0 means no buffers, 4 means many buffers.
>in-13
>tb13 rstate:
Receiver state. 0..2 means connected, 3,4,6 means connecting,
7,8 means alternating connect,
5,9,10 means disconnectet.
>in-13
>tb13 xstate:
xmt state. reflects next frame to be send.
>in-13
>tb13 ystate:
your state: ystate>0 means rnr has been received.
>in-13
>tb13 mstate:
my state true if rnr has been transmitted.
>in-13
>tb13 j:
number of blocks in latest received or transmitted frame.
>in-13
>tb13 vi:
number of i_frames transmitted but not acknoleged yet.
>in-13
>tb13 tn:
number of timeouts.
>in-13
>tb13 t:
timer in units of .2 sec.
>in-13
>tb13 send:
transmitter busy.
>in-13
sending_i_frame: transmitter is sending iframe.
>tb13 aborting:
current frame is aborted.
>in-13
>tb13 rec_pointer
and
>in-13
>tb13 xmt_pointer:
fifo pointers in controler.

>a1 Performance and Ressource Requirements.
>a2 performance
To be supplied later.
>a2 Program and Stacksize.
>ta 10 40R
$Programsize:
$8524
>br
$Stacksize:
$1024
>br
$Pools and Children:
$724
>br
>a1 References.
>in5
>ti-5
(1)  CCITT Draft Revised Recommendation X.25@.
>sp0
Computer Communication Review, vol. 10, no. 1&2.
>sp1
>ti-5
(2)  Konventioner for drivere til NY og LAMBDA.
>sp0
UDV-NYSK[RM.EL.68 (danish).
>sp1
>ti-5
(3)  Konventioner for PASCAL80 driver interfacer.
>sp0
UDV-PASCAL80.EL.1 (danish).
>sp1
>ti-5
(4)  Addendum til konvensioner for PASCAL80 Driver Interfaces.
>sp0
UDV-PASCAL80.HLV.12 (danish).
«eof»
DataMuseum.dk

RC3500

⟦6e867d47a⟧ TextFileVerbose

Derivation

TextFileVerbose
