Required Routines

which insures the controller is not placed in an unim-plemented mode (77-80). This is also the place where interrupts from the 270 are enabled (78).

i2700pen (165) is called for every open of the 270 device. In line 176 ensures that if the 270 controller was not found at boot time, all opens will fail with a

2-160 280041-001

inter

o

~ PROTOCOL ROUTINES ' - - ' " TTY.C

iIII111IIo. DRIVER WRITER ROUTINES

'fiII/IV (NOT REQUIRED)

0>

Figure 11. iSBXTM 270 Video Terminal Controller Board Driver Routine Dependancies Calling Sequences.

'nonexistent device' (ENXIO). Line 185 sets up a pointer to the status record for the device. If the device has an active exclusive open, line 191 ar-ranges an open failure with a busy return. Line 201 sets a pointer for use by the protocol routines to start output. Line 207 arranges that the 270 looks to the kernel like a 9600 baud terminal with characteristics suited to the device. Line 213 sets a flag to note the device is open for later. Note that ISOPEN is set by ttyopen.

2-161

i270close (221) is called on the last close of the device. It just calls the protocol routine ttyclose, then removes the I/O address of the 270 from the tty structure.

i270read (231) and i270write (240) respond. to reads and writes by simply calling the protocol routines 'ttread' and 'ttwrite', respectively.

280041-001

AP-184

i270iintr (249) responds to an input interrupt by simply getting the character, and calling the protocol routine 'ttyinput' with it if' it caqte from the keyboard.

i2700intr (262) responds to an output interrupt by checking if there was output in progress. If so, line 269 c1earsthe BUSY flag (in case there are no more characters to output). The protocol routine 'ttstart' wilI send the next character and set BUSY if there is more output to do. If a process is sleeping because the output queue was at the high water mark, and the queue is now below the low water mark, all such processes are awakened(271-273).

i270start (279) is called after output interrupts and by the protocol routines to initiate output to the 270.

This routine sets a cpu priority high enough to pre-vent reentrancy problems caused by the fact it can be called by interrupts (285). The high cpu priority is used to insure the BUSY bit does not change, so that it may be used as a lock to prevent more than one flow of control from getting into the switch state-ment of line 293. Once this lock is obtained, the cpu priority is lowered. The interrupt priority should remain raised for no more than the 100 microsecond. If the driver is doing output, this rou-tine will return(Iine 286). It is necessary that all paths out of this routine lower the cpu priority (note lines 287, 292, and 394) within the time constraint.

Line 290 uses the 'getc' routine to get the next char-acter from the output c1ist. The way interrupt driven output to tty devices is performed is by maintaining been started and the output device is ready to accept the next output character. A call to i270start, then should force the terminal into the BUSY state except in the case that the output c1ist is empty (lines 290 and 394). At the next output interrupt the termi-nal goes from BUSY to idle (line 269), and protocol routine ttstart calls the appropriate start routine (set by line 201 to be i270start) to attempt to put the device back into the BUSY state.

A major reason for the bulk of this routine is that it maintains a finite state machine which controls the disposition of characters sent to the 270. This ma-chine implements certain escape sequences which do device control operations. Some of these device con-trol operations cannot be done by writing to the data port, and so require special code. There is also code implementing an escape for graphic attribute bytes

which prevents them from being mistaken for device control escape sequence lead ins. A state tran-sition diagram, shown in figure 12, details the con-trol character sequences and other input sequences expected by the device. The code for the default 295 through 301 implement a transition to state one in the event an escape character is written to the 270.

The graphic attribute escape is in state 0 at lines 302 through 305 and in state 8 at lines 383 through 392.

An escape is followed by a character which deter-mines which escape sequence is involved. At state 1 lines 317 through 324 we see a transition to state 2 if a cursor motion sequence (<: ESC> =) is found, , after sending an ASCII NUL to the 270 controller to abort the escape sequence. State 2 sends a set cursor position (I270SCP) command to the status port and sends us to state 4 (Jines 352 and 353). State 4 then sends a data byte minus an ASCII '0' (the X axis position), and sends us to state 5 (lines 363 and 364). State 5 then sends another data byte minus an ASCII '0' (the Y axis position), and sends us back to state 0 (Jines 367 and 368). State 1 lines 325 through 332 abort the escape sequence and move to state 3 to implement a 'set attributes' «ESC> G) command. State 3 sends the character after masking it to insure a valid attribute byte (Jine 359), the re-turns to state O. State 1 lines 333 through 337 abort the escape sequence and move to state 6 to initiate a 'set mode' command. State 6 sends a 'set mode' to the controller's status port and moves to state 7 (Jines 371 and 372). State 7 shifts the output byte's low bit into the 'page mode' bit, sends the new mode to the data port and returns to state 0 (Jines 375 through 38J). Note that an <ESC> M sequence followed by a character other than an ASCII '0' or '1' is not guaranteed to result in a valid mode. The remaining state 1 code (Jines 338 through 347) implement the default action, which is to send the escape sequence on to the device and return to state zero. Note that this works because no 270 hardware escape sequence is over two characters (the escape and the command). Longer escape sequences would probably need a protection similar the protection by state 8 of attribute bytes, to prevent them from being mistaken for lead-in characters. If all escape se-quence support were implemented by the device via the data port, as is the case for terminals on a serial and rejecting all others since the board does not

sup-port baud rates. .

2-162 280041-001

AP-184

ESCAPE SEQUENCE

GRAPHIC CHARACTER 1979

Figure 12. State Transition Diagram for iSBXTM 270 Terminal Controller Board.

Used by the Driver.