⟦d9eaef405⟧

TextFile

>a1 INTRODUCTION
The GCI driver is written in PASCAL80. The driver runs on a 3502- computer
and controls a RC35-210 device controller @1@.

The functions supported by the driver are formed according to the
PASCAL80 Driver Conventions @2@, 
>ul
except
for the format of a databuffer in a write and read operation, see
section 3.6.

The driver is capable of handling a databuffer stack.

The driver consists of two independent parts, a transmitter part and
a receiver part. Transfer messages to one of the driver parts can
require information being sent in both directions. The RC35-210
hardware consists of two hardware channels, a pure read channel and
a pure write channel. As a consequence, both hardware channels must
be available for both of the driver parts.

In order to support one RC35-210 controller you need one incarnation
of the GCI210 driver.

The two GCI210 drivers (one in each 3502 computer) exchange
information using the hardware write channel and the hardware
read channel, alternately. Synchronization of the two drivers
is secured either by giving the two drivers two different process
timeout values (see section 4) or by giving them the same values,
and then hope that they will synchronize at some time.

>np
The datablocks exchanged have the following format:

 Word no.     Content

   1          Destinator, destination status
   2          User's data
   .
   .
   .
   .
   .
   N-1
   N          Control word

The destinator can be

 - the receiver part of the driver
 - the transmitter part of the driver
 - no destinator

   This situation will arise when no application
   message has been sent to the GCI210
   driver for some time (2 * delay time,
   where delay time is a trimmable 
   CONST variable).

The destination status is message dependent, see section 2.

The control word can be used freely by the application
(u3 in the topmost header message is transferred).

>a1 FUNCTIONS SUPPORTED BY THE GCI DRIVER
The receiver and the transmitter part of the driver supports
the same functions:

 - control:
   - sense the status of the driver part
   - send a status to the other computer
     - reset: The driver part transfers
              a reset status to the oppo-
              site driver part in the other
              computer (destination status
              field is used).

     -autoload:
              The driver part transfers an
              autoload status to the oppo-
              site driver part in the other
              computer (destination status
              field is used).

  - read data
  - write data
  - write and read data
>np

The driver returns the following type of results to the application:

 -processed successfully (basic result 0)
 -rejected (basic result 1)
 -soft error,  (basic result 2)
       combined write error (32)
       block length error (64)
       receiver_not_ready (128)
     
       One or more of these 3 kinds of soft errors
       can be returned at the same time.

 -hard error (basic result 3)
  
       disconnected (8)
       reset (16)
       combined write error (32)
       autoload received (64)
   
       One or more of the 4 kinds of hard errors can
       be returned at the same time.
    
 -unintelligible (basic result 4)

If more than one of these 5 kinds of basic result occur
during the treatment of one request the basic result with
the highest priority is returned.

The priority of the basic result can be trimmed in the CONST_declaration
part of the driver. At the present time the priority is as follows:

  hard error,              highest priority
  rejected
  unintelligible
  soft error
  processed successfully,  lowest priority

Both the driver   starts in rejecting mode. A driver part enters  processing
mode, when a control function is processed successfully. A driver part
enters rejecting mode, when a hard error occurs.

>a1 DRIVER INTERFACE
Each request supported by the driver is described in one section.

>a2 Sense
The status of the driver part is returned.

Function code 0 (control + 0 * 4).

Possible results:
>sp0
0 processed successfully, the driver enters
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@@processing mode.
>sp0
11 (hard error + 1 * 8), disconnected
>sp0
19 (hard error + 2 * 8), reset received 
>sp0
67 (hard error + 8 * 8), autoload received 
>sp0
3 + x * 8 (hard error combinations),
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@where x is 3, 9, 
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@10, or 11

>a2 Reset
The driver part will transfer a reset status to the other computer.

Function code 4 (control + 1 * 4).

Possible results:
>sp0
0 processed successfully, the driver enters 
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@@processing mode.
>sp0
11 (hard error + 1 * 8), disconnected.
>sp0
19 (hard error + 2 * 8), reset received 
>sp0
67 (hard error + 8 * 8), autoload received 
>sp0
3 + x * 8 (hard error combinations),
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@where x is 3, 9,
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@10, or 11

>a2 Autoload
The driver part will transfer the status to the other computer.

Function code 8 (control + 2 * 4).

Possible results:
>sp0
0 processed successfully, the driver enters 
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@@processing mode.
>sp0
11 (hard error + 1 * 8), disconnected.
>sp0
19 (hard error + 2 * 8), reset received 
>sp0
67 (hard error + 8 * 8), autoload received 
>sp0
3 + x * 8 (hard error combinations),
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@where x is 3, 9,
>sp0 
@@@@@@@@@@@@@@@@@@@@@@@@@10, or 11

>a2 Read data
Data is transferred from the hardware into the data buffer(s). The
control word received is stored in u3 of the topmost header message.

Function code 1 (read + 0 * 4).

Possible results:
>sp0
0 processed successfully.
>sp0
1 rejected. 
>sp0
4 unintelligible, the size of one of the 
>sp0
@@@@@@@@@@@@@@@@@@databuffers
>sp0
@@@@@@@@@@@@@@@@@@is not supported by the driver.
>sp0
66 (soft error + 8 * 8), block length error:
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@data buffer(s) too small.
>sp0
11 (hard error + 1 * 8), disconnected.
>sp0
19 (hard error + 2 * 8), reset received
>sp0
67 (hard error + 8 * 8), autoload received 
>sp0
3 + x * 8 (hard error combinations),
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@where x is 3, 9,
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@10, or 11

>a2 Write data
Data is transferred from the data buffer(s) to the hardware.
U3 in the topmost header message is transferred in the control word.

Function code 2 (write + 0 * 4).

Possible results:
>sp0
0 transferred successfully.
>sp0
1 rejected.
>sp0
4 unintellegible, the size of one of the 
>sp0
@@@@@@@@@@@@@@@@@@databuffers
>sp0
@@@@@@@@@@@@@@@@@@is not supported by the driver
>sp0
@@@@@@@@@@@@@@@or first in one of the databuffers
>sp0
@@@@@@@@@@@@@@@@@@is less than 6
>sp0
@@@@@@@@@@@@@@@or last in one of the databuffers
>sp0
@@@@@@@@@@@@@@@@@@is greater than the size of the 
>sp0
@@@@@@@@@@@@@@@@@@buffer.
>sp0
130 (soft error + 16 * 8), receiver
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@@@not ready.
>sp0
11 (hard error + 1 * 8), disconnected.
>sp0
19 (hard error + 2 * 8), reset received 
>sp0
66 (hard error + 8 * 8), autoload received 
>sp0
3 + x * 8 (hard error combinations),
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@where x is 3, 9,
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@10, or 11

>a2 Write and read data
Data is transferred from the databuffer(s) to the hardware.
U3 of the topmost header message is transferred in the control word.

Note that there is a violation upon the 'driver conventions' @2@
for a databuffer. The conventions suggest that the write part of
a buffer is from FIRST to NEXT, both included. But the driver uses
NEXT as a top so that the datapart is from FIRST to NEXT-1, both
included.

Then data is transferred from hardware to the databuffer(s). The 
control word received is put into u3 of the topmost header message.

Function code 3 (writeread + 0 * 4).

Possible results:
>sp0
0 proceed successfully.
>sp0
1 rejected.
>sp0
4 unintelligible, see section 3.4
>sp0
36 (unintelligible + 4 * 8),
>sp0
@@@@@@@@@@@@@@@@@@@@@@unintelligible write,
>sp0
@@@@@@@@@@@@@@@@@@@@@@see section 3.5
>sp0
34 + x * 8 (soft error in write),
>sp0
@@@@@@@@@@@@@@@@@@@@@@where x is 16
>sp0
2 + x * 8 (soft error in read),
>sp0
@@@@@@@@@@@@@@@@@@@@@@where x is 8
>sp0
35 + x * 8 (hard error in write),
>sp0
@@@@@@@@@@@@@@@@@@@@@@where x is 1, 2,  3,
>sp0
@@@@@@@@@@@@@@@@@@@@@@8, 9, 10, or 11
>sp0
3 + x * 8 (hard error in read),
>sp0
@@@@@@@@@@@@@@@@@@@@@@where x is 1, 2, 3,
>sp0
@@@@@@@@@@@@@@@@@@@@@@8, 9, 10, or 11
>a1 PARENT RESPONSIBILITIES
The PASCAL80 process heading of the driver is as follows:

PROCESS fpadriver (var x_sem, r_sem: semaphore;
>sp0
@@@@@@@@@@@@@@@@@@x_level, r_level: integer;
>sp0
@@@@@@@@@@@@@@@@@@blocktime: integer);

where x_sem is the request semaphore of the transmitter part and r_sem
is the request semaphore of the receiver part. x_level is the hardware
level number  for the write channel, and r_level is the hardware level 
number for the read channel.
   
Blocktime (the process timeout value) is the maximum number of seconds
that is used to transfer a datablock. Blocktime should be greater than
2 * delay time.

An incarnation of the driver uses max. 500 b stack-storage. The driver
code occupies approximately 3 Kb of storage. This amount can be 
considerably reduced when dynamic types has been implemented in
PASCAL80.

The driver will then be more flexible, too. At the time being
the driver only supports three different buffer sizes (small_size,
medium_size, and large_size). These sizes can bee trimmed in the
CONST_declaration part of the driver.

>ap
>a1 REFERENCES

@1@ RCSL No. 52-AA309
>sp0
    GENERAL INFORMATION 
>sp0
    for RC35-210, Reference Manual.

@2@ RCSL No. 31-D617
>sp0
    PASCAL80 Driver Conventions
▶EOF◀
DataMuseum.dk

RC4000/8000/9000

⟦d9eaef405⟧ TextFile

Derivation

TextFile
