[LMH]%IO instruction and Device Descriptors

[Steve Krueger]

Alastair,

I've looked some at %IO.  The device is passed to %IO as a device 
descriptor in the second argument.  This should be the same data 
structure that is in the device interrupt table.  As an argument to %IO, 
it probably is a displaced array.  If so, the displacement must be 
followed.  The device type is at the offset 
SYS:%IO-DEVICE-DESCRIPTOR-WORD into the device descriptor array's data. 
 %IO finds the device type by examining the INTERRUPT-TYPE field.  The 
values of this field are defined in microcode and I can't find where 
it's values are exported to macrocode.  I'll give you the values for 
microcode ~208, they might have changed in Elroy.

    0    Illegal*
    1    NuPI
    2    reserved for NuPI special requests (I don't know whether we 
ever used this)*
    3    Keyboard
    4    TV Vertical Retrace*
    5    Serial Port
    6    Parallel Port
    7 - 15    Illegal*

* = traps because can't initiate I/O

The Interrupt-Type field is defined as (BYTE 4 0).

When the device descriptor has INTERRUPT-TYPE = 1,  jumps to 
NUPI-INITIATE-IO.

Here are some comments from that routine:
;;; The following code implements the NUPI disk and tape controller 
queued request system
;;;
;;; Special note:  the unit number field in the request block is 6 bits 
wide.
;;;    The most significant 3 bits specifiy the formatter unit, the 
least significant
;;;     3 bits specify which drive on the specified formatter to use. 
 This IO driver will
;;;     provide a queue per formatter since the board supports a request 
per formatter.

;;; Called from the initiate IO dispatch
;;; Clear the busy and done bits.
;;; Setup RQB for the NUPI completion event required for the device IO 
system.
;;; Set interupt request for the NUPI slot.
;;; Set the EVENT bit in the command word.
;;; Fetch the unit number of the request.  Read the request command word.
;;; Computing the request queue address.  Compute the base address of 
the queue
;;; section in the device descriptor as
;;; DESCRIPTOR + %NUPI-QUEUE-BASE + REQUEST-QUEUE-NUMBER(RQ-CMD-WORD).
;;; NOTE: REQUEST-QUEUE-NUMBER is defined as (BYTE 3 3)
;;; Check for queue empty.  If so then insert, and start request processing.
;;; If not search queue and insert before first with lower priority or 
at the end and then return
;;; as this command won't be performed until it gets to the head of the 
queue.

To start NUPI request processing:
;;; Set the busy bit in the RQB
;;; Get the NUPI control space address from the device descriptor + 
%NUPI-CONTROL-SPACE-ADDRESS
;;; Start the command by sending the address of the control block to the 
NUPI at the NUPI control space
;;; address + %NUPI-COMMAND-REGISTER (as an unmapped write) of the RQB 
command word,
;;; converted to a NuBus byte address).
;;; Note the RQB must be in either temporarily or permanently wired memory.
;;; Set the bit map to indicate that the unit is busy.
;;; The bit map is in the device descriptor block's %NUPI-INFORMATION word.

IO proceeds asynchronously and eventually produces an interrupt.  The 
interrupt handler again dispatches on the Interrupt Type field of the 
device descriptor found at that interrupt level.  NuPI doesn't share an 
interrupt level with any other device.

Its late now.  I'll type some about the NUPI interrupt handler in a 
couple of days.

By the way, most the symbols related to NUPI are defined in
    ucode/lroy-qdev.lisp
and
    disk-io/ disk-definitions.lisp

None of the above seems to contradict SSDN2 in any way.

  -Steve


Nyef wrote:

>Hello all.
>
>I've managed to coax EXP1.LOAD through to somewhere in BLOCK-NUPI-RUN,
>under NUPI-STATUS-WIRED, where it signals an error because I cheated
>massively when implementing the %IO instruction. Now I'm trying to figure
>out how to make the %IO instruction behave a little more correctly, but...
>
>How do I figure out what device the %IO instruction is for? I can't find 
>anything in the common section of the device descriptor block that appears 
>to indicate which device it is for.
>
>---------------------------
>All programming can be viewed as an exercise.
>---------------------------
>Alastair Bridgewater
>e-mail: nyef@softhome.net
>
>http://lists.unlambda.com/mailman/listinfo/lispm-hackers
>
>  
>