Software Design Notes Device Handling SECTION 4 Device Handling 4.1 INTRODUCTION The device handling features and conventions have been designed for simple but flexible operation, with few restrictions relating only to cooperation with system device operations, i.e. virtual memory on the disk. Each device is assigned a device type which is a small positive integer. Device type numbers are assigned at system build time. This section is aimed at describing the specific operation and the internal structures used by many of the devices in the system. First, the general scheme for handling I/O requests is presented, later sections detail specific devices. 4.2 DEVICE DECODING Each device in the system that requires interrupt processing maintains a Device Descriptor Block (see sectopn on interrupts). This descriptor block contains all the information that the system needs for processing requests and interrupts for this device. The Device Descriptor Block maintains information about the device state. A separate structure, the Request Block (RQB) is used to transfer request information. The first word in the Device Descriptor Block is used as a line word for the interrupt decoder and points to the next device descriptor on the same interrupt level. The second word is called the device information word. This word contains information needed to determine what type of processing is needed when an initiate I/O request is sent to the device and also what type of interrupt processing is required. The device type implicitly specifies the number of device specific words required. The details of some specific devices follow. The initiation and interrupt processors use the device specific portion of the block to maintain information pertaining to the device and the outstanding requests. Therefore, every device in the system that requires microcode handling must provide an entry point in the initiate dispatch table and an entry point in the interrupt handler dispatch table. The entries are placed in the tables according to device type. To initiate an I/O request the %IO miscop (miscellaneous operation) is used. The parameters are the device descriptor and 4-1 Device Handling Software Design Notes a request descriptor. There are two basic forms for the request descriptor. The first form is a fixnum. In this case, the single word specifies the operation being requested. The second form is a request block. The request block is an array. The specifics of the request block are defined by the device handler. To initiate a request the device type is fetched from the Device Descriptro Block and the device initiation handler is called for this device type. The device initiation handler is responsible for servicing this request by either starting the device operation or placing the request in a queue for later processing. To make the best use of the peripheral resources on the machine there is a mechanism to queue requests for I/O and continue processing. In any case, we would not want the processor to just sit idle during I/O requests, but rather run other processes that might be ready to run. To be able to do this some devices maintain a list of outstanding requests, and when one request has completed automatically start the next request. This requires that the interrupt handlers for a device must maintain the queue as part of its duties. 4.3 DEVICE-HANDLER DATA STRUCTURE ALLOCATION Memory references made by interrupt handlers must be to static, wired virtual emmory or to the phusical address space. Device- specific control registers are generally accessed as NuBus physical memory which has no mapping in the virtual address space. Other interrupt-handling data structures, however, generally are mapped into the Lisp virtual address space so that both the microcode and Lisp can access them as normal virtual memory. Allocation of these data structures follows the following conventions: - Device descriptor data structures as well as the interrupt servicing queue itself are allocated in the SYS:DEVICE-DESCRIPTOR-AREA. This is a special system-wired no-scavenge area in low virtual memory. The structures are allocated simply as segments of un-typed memory, hence are not viewed as Lisp objects; therefore, this area is not garbage collected or scavenged. Addresses within the data structures can only point to otehr data structures in the SYS:DEVICE-DESCRIPTOR-AREA or to objects in other static areas. - Actual I/O buffers themselves are generally allocated as Lisp arrays in static areas, and are wired down before the I/O starts using paging primitives such as SYS:WIRE-ARRAY or SYS:WIRE- PAGE. Examples of current static areas are: 4-2 Software Design Notes Device Handling SYS:DISK-BUFFER-AREA disk and tape RQBs and data buffers SYS:SERIAL serial and parallel port I/O Buffers CHAOS:CHAOS-BUFFER-AREA Ethernet packet buffers The remainder of this section describes specific devices and their I/O Interrupt handlers. 4.4 DEVICE DETAILS 4.4.1 The NuBus Peripheral Interface Board. The NUPI is used for interfacing to disk and tape devices. The NUPI recieves operation requests by writing the address of a NUPI Command Block to a special address in the NUPI address space designated as the Command Register. The NUPI then processes this command asynchronously from the Explorer processor. When the request has been completed, the NUPI stores the status of the operation back into the status word of the request block and, if specified in the request block, posts an event to the Explorer processor to signal completion of a command. (The Explorer convention is that all requests to the NUPI post the completion event.) This event posting is fielded by the processor as an interrupt. The device interrupt handler is called to process the completion of the current request and initiate the next one if required. Figure 4-1 shows the format of the Device Descriptor Block for the NUPI. The Link Word and Device Information Word are standard for all devices. The Control Space Word holds the NuBus address of the control space of the NUPI board. This is needed to correspond with the board. A NUPI may have several disk or tapes units under its control. Each disk or tape unit is connected to a formatter, which is a local controller. A formatter may have one or two devices connected to it. Each device, formatter and the NUPI itself is considered a unit, and all may simultaneously have a request in progress. The device handler maintains a request queue for each device. The request at the front of the queue is the one currently being processed. When a request comes to the front of the queue the Busy Bit in the Information Word (see Figure 4-2) is set to signify that the request is in progress. When the request in completed the Busy Bit is reset and the Done Bit is set. The request block is removed from the queue. If there are any other requests in the queue at this time, processing is started for them. 4-3 Device Handling Software Design Notes The Unit Busy Bitmap indicates which units have requests in progress. This is used because when a request completes and an interrupt is signalled all devices with requests in process must be checked to find which ones have completed. The bit map allows polling of only those units for which processing is possible. +----------------------------------------+ 0 | Link word | +----------------------------------------+ 1 | Information Word | +----------------------------------------+ 2 | NUPI control space address | +----------------------------------------+ 3 | Unit Busy Bitmap | +----------------------------------------+ 4 | Queue anchor for unit 0 | +----------------------------------------+ 5 | Queue anchor for unit 1 | +----------------------------------------+ | . | . | . | +----------------------------------------+ 15 | Queue anchor for unit 15 | +----------------------------------------+ Figure 4-1 NUPI Device Descriptor Block 7 6 5 4 3 2 0 +--------------------------+-+-+-+-+-+---+ | |I|A|S|D|B|PRI| +--------------------------+-+-+-+-+-+---+ I <7> : Illegal Command A <6> : Command Aborted S <5> : Suppress Sequence Break D <4> : Done Bit B <3> : Busy Bit PRI <2:0> : Priority Number Figure 4-2 NUPI Device Descriptor Information Word 4.4.2 The Keyboard. When a keyboard interrupt occurs, the keyboard character is copied from the hardware register into the keyboard buffer. The Lisp keyboard process notices that a character is available and 4-4 Software Design Notes Device Handling handles it. 4.4.3 CRT Vertical Retrace (Interrupt). An interrupt occurs when the CRT begins the vertical retrace interval. At this time, the mouse is checked to see if it has moved or if any of the buttons have changed state. Mouse button changes go into the mouse buttons buffer. If the mouse has moved, it is undrawn in its old position and redrawn in its new position. The mouse process then notices either mouse motion or mouse buttons. This interrupt also handles the timer on the Explorer I (the Explorer II has a microsecond timer on the processor). The short interval timer is read to determine the exact number of microseconds that have elapsed since the last TV vertical retrace interrupt. This value is then added to an internal microsecond timer and the short interval timer is reset. 4.5 SERIAL AND PARALLEL IO PORTS The Explorer has one serial port for bidirectional asynchronous communication, and one Centronix (tm) standard unidirectional parallel port for high speed datatransmission. (Centronix is a registered trademark of Centronics Data Computer Corporation.) Each has microcode support and can be used with a standard stream interface. 4.5.1 RS232 Serial Port. The Explorer serial port is based on a Zilog Z8530 Serial Communications Controller found on the System Interface Board (SIB). It can be configured to handle all asynchronous formats regardless of data size, number of stop bits, or parity requirements. It can also accomodate all synchromous formats including character, byte, and bit-oriented protocols. There is both microcode and Lisp support for the serial port. The microcode handles recieve and transmit interrupts for the chip. A stream interface to the serial port is provided to make it convenient to use. Although the chip supports synchronous modes, the sfotware currently provides support for asynchronous modes only. Microcode handling of serial port interrupts enables high speed transmission of characters. Characters to be sent out through the port are queued in a buffer. When the serial port signals a transmit ready interrupt, the microcode removes the next character from the buffer, if any, and sends it out. Similarly, 4-5 Device Handling Software Design Notes when the chip signals a recieve character ready, the microcode will remove the character from the chip's internal register and store it into another buffer where it can be accessed from Lisp when convenient. The microcode also has support for an XON/XOFF protocol. When enabled, this will allow external devices to control the transmission of data by the Explorer and will allow the Explorer to stop a device from sending data. When running in this mode, the reciept of an XOFF character will disable further transmission until an XON character is recieved. If the Explorer's serial input buffer comes within 10 characters of being full, it will automatically transmit an XOFF character to temporarily stop data transmission. Naturally, the external device must also support XON/XOFF protocol for this scheme to work correctly. The serial port is programmed by writing data into the 14 write registers of the chip. Received characters and chip status are available in seven read registers. For details on the function of these registers see the Explorer System Interface manual. _________________________ These registers are found within the NuBus address space of the SIB. It is therefore possible to program and use the chip directly from Lisp in polled mode, although this is not recommended. The port is intended to be used in interrupt driven mode provided by the microcode and serial streams. Serial streams provide a convenient way to initialize the operating parameters of the chip and to send and recieve characters. Operating parameters are normally specified in the call to SYS:MAKE-SERIAL-STREAM. Characters are transmitted with :TYO and recieved with :TYI. For more information on serial streams, see the Explorer ________ Input/Output Reference manual. ______________________ 4.5.2 Parallel Port. Like the serial port, the parallel port is also found on the System Interface Board. The programming interface consists of two registers found within the NuBus address space of the SIB. The data register is an 8-bit write-only register. The command register is also 8 bits wide. Writing to the command register allows you to initialize the port, cause data strobe, and enable auto linefeeds or interrupts. Reading from the command register returns port status including busy, paper out, online, and fault. There is microcode support for running the parallel port in interrupt mode. Data to be transmitted is placed into an output buffer. When the external device is ready to recieve a character, an event is posted by the SIB to the processor. The microcode will remove the next character from the output buffer and send it out. If a large number of characters are queued in 4-6 Software Design Notes Device Handling the output buffer, data can be transmitted at very high speeds. A stream interface is provided to make the parallel port easy to use. 4-7