⟦2ed5674a9⟧

TextFile

>a1 INTRODUCTION
The FPA driver is written in PASCAL80. The driver runs on a 3502-machine
and controls a FPA100 device controller @1@.

To support one FPA100 controller you need two incarnations of the
driver code, a transmitter incarnation and a receiver incarnation.

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.

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

 - control:
   - sense the statusword of the hardware
   - send a controlword to the hardware:
     -reset: The hardware is reset.
             The transmitter transfers
             a reset status to the receiver in
             the other computer.

     -autoload:
             The transmitter transfers an
             autoload status to the receiver
             in the other computer. The con-
             trol word is dummy for  the
             receiver.


   - 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)
       parity error (8)
       process timeout (16)
       combined write error (32)
       block length error (64)
       receiver_not_ready (128)
     
       One or more of these 5 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.
    
       If the receiver receives an autoload
       request in its status word, a switch
       in the RAM memory is inspected. If
       the switch is set, the 3502 machine
       is autoloaded, else an autoload
       result is returned to the application.
  

 -unintelligible (basic result 4)

       bad message (8)
       combined write error (32)
  
       Zero or more of these 2 kinds of unintelli-
       gible errors can be returned at the same time.

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:

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

The driver starts in rejecting mode. The driver enters processing
mode, when a control function is processed successfully. The driver
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 hardware is returned.

Function code 0 (control + 0 * 4).

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

>a2 Reset
A reset control command is sent to the hardware. The hardware will 
transfer a reset status to the other computer (transmitter only).

Function code 4 (control + 1 * 4).

Possible results:
>sp0
0 processed successfully, the driver enters 
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@@processing mode.
>sp0
11 (hard errror + 1 * 8), disconnected.
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@@Maybe possible, depending
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@@on hardware reaction.
>sp0
19 (hard error + 2 * 8), reset received 
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@(receiver only).
>sp0
67 (hard error + 8 * 8), autoload received 
>sp0
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@(receiver only).
>sp0
3 + x * 8 (hard error combinations),
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@where x is 10
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@(receiver only).

>a2 Autoload
An autoload control command is sent to the hardware. The hardware
will transfer the status to the other computer (transmitter only).

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
@@@@@@@@@@@@@@@@@@@@@@@@@Maybe possible, depending
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@on hardware reaction.
>sp0
19 (hard error + 2 * 8), reset received 
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@(receiver only).
>sp0
67 (hard error + 8 * 8), autoload received 
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@(receiver only).
>sp0
3 + x * 8 (hard error combinations),
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@where x is 10
>sp0 
@@@@@@@@@@@@@@@@@@@@@@@@@(receiver only).

>a2 Read data
Data is transferred from the hardware into the data buffer(s). The
first byte 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
10 (soft error + 1 * 8), parity error.
>sp0
18 (soft error + 2 * 8), driver process 
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@timed out.
>sp0
66 (soft error + 8 * 8), block length error:
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@data buffer(s) too small.
>sp0
2 + x * 8 (soft error combinations),
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@where x is 3, 9, or 10.
>sp0
11 (hard error + 1 * 8), disconnected.
>sp0
19 (hard error + 2 * 8), reset received
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@(receiver only).
>sp0
67 (hard error + 8 * 8), autoload received 
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@(receiver only).
>sp0
3 + x * 8 (hard error combinations),
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@where x is 10
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@(receiver only).

>a2 Write data
Data is transferred from the data buffer(s) to the hardware.
The first byte transferred is taken from u3 in the topmost
header message.

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
10 (soft error + 1 * 8), parity error.
>sp0
18 (soft error + 2 * 8), process timeout.
>sp0
130 (soft error + 16 * 8), receiver
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@@@not ready.
>sp0
2 + x * 8 (soft error combinations),
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@@@where x is 
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@@@3, 17, or 18.
>sp0
11 (hard error + 1 * 8), disconnected.
>sp0
19 (hard error + 2 * 8), reset received 
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@(receiver only).
>sp0
66 (hard error + 8 * 8), autoload received 
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@(receiver only).
>sp0
3 + x * 8 (hard error combinations),
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@where x is 10
>sp0
@@@@@@@@@@@@@@@@@@@@@@@@@(receiver only).

>a2 Write and read data
Data is transferred from the databuffer(s) to the hardware.
The first byte transferred is u3 of the topmost header message.

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 first
byte transferred 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 1, 2, 3,
>sp0
@@@@@@@@@@@@@@@@@@@@@@16, 17, or 18.
>sp0
2 + x * 8 (soft error in read),
>sp0
@@@@@@@@@@@@@@@@@@@@@@where x is 1, 2, 3,
>sp0
@@@@@@@@@@@@@@@@@@@@@@8, 9, or 10.
>sp0
35 + x * 8 (hard error in write),
>sp0
@@@@@@@@@@@@@@@@@@@@@@where x is 1 or
>sp0
@@@@@@@@@@@@@@@@@@@@@@2,8,10 (receiver only).
>sp0
3 + x * 8 (hard error in read),
>sp0
@@@@@@@@@@@@@@@@@@@@@@where x is 1 or
>sp0
@@@@@@@@@@@@@@@@@@@@@@2,8,10 (receiver only).
>a1 PARENT RESPONSIBILITIES
The PASCAL80 process heading of the driver is as follows:

PROCESS fpadriver (var sem: semaphore;
>sp0
@@@@@@@@@@@@@@@@@@@level, blocktime: integer
>sp0
@@@@@@@@@@@@@@@@@@@receiver: boolean);

where sem is the driver's request semaphore, level is the hardware
interface level number.
Blocktime is the maximum number of seconds used to process a single
driver request.

Receiver is true for the receiver incarnation of the driver, else
false.

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-AA359
>sp0
    FPA100 FRONT PROCESSOR ADAPTOR
>sp0
    for RC3500, Reference Manual.

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

RC4000/8000/9000

⟦2ed5674a9⟧ TextFile

Derivation

TextFile
