Download MPA Multi-Protocol Terminal Emulation Adapter Using the DP8344

session then determines the current state of that session
and what action(s) need to be performed.
Like the twÐclearÐcmd routine, twÐresetÐcmd actually
calls the subroutine twÐpor which performs a POR on the
current session. The routine twÐpor first places the current
session OFFLINE by signaling to the background receiver
interrupt (via the RXÐRESET bit) that it is not to respond to
the host until further notice for this station address. Once
this is done, the twÐpor routine can begin changing memory locations normally updated by the background receiver
interrupt without disabling interrupts because the RXÐRESET bit effectively disables the receiver interrupt when
working with this physical session. Next the exception
status is changed, notifying other tasks that this session is
in POR. The time count for this session is cleared and a bit
is set (in the twÐporÐwaitedÐsession byte on the DCP)
informing the other tasks that the 5 second POR timeout
has commenced. The twÐtask routine will use this time
count and this session’s POR wait bit to determine when to
bring the session back on line. Other tasks use the POR
wait bit when interpreting the meaning of the time count for
the current session. The action stack is cleared next, along
with the smart alec task handshake bits. Then, the screen
buffer for this session is cleared via a call to twÐclearÐroutine, which issues an action stack entry reflecting the
cleared screen. (This allows the PC to accurately reflect the
POR state.) Finally, the remaining SCP variables are set to
their appropriate values, except for the variables controlled
by the smart alec task, (i.e., Model ID, Keyboard ID, etc . . . ),
which are left unchanged.
The End Of Queue command does not actually have a command routine, for at this point in the command decoding
process of the MPA-II it does not provide any additional
information. As far as the command processor is concerned, the queue load complete flag, set by the background receiver interrupt, indicates the actual end of queue.
So the act of popping the EOQ command off the queue
completed this command’s execution, no call to a command
routine is required.
The program flow of twÐsession proceeds as follows. First,
twÐsession checks for the ACTIVATE WRITE command
for the current session completed in the background. If one
has occurred, twÐsession performs an action stack push,
which notifies the Smart Alec interface of the screen update. Next, the command processor checks for actions requested by other tasks. Currently, two actions are defined:
the ‘‘forced’’ POR and the ‘‘requested’’ POR. The ‘‘forced’’
POR is usually issued by the smart alec interface task and it
forces a POR regardless of the current session status. After
the POR is initiated control returns to the calling routine
(twÐtask). The ‘‘requested’’ POR is usually issued by twÐ
task when an Auto-POR is desired. A POR is only performed if the current session is not already in the POR exception state or if an error condition does not exist. Otherwise, this request is ignored. In this way, the twinax session
will not unnecessarily POR. Again, after a POR is initiated
control returns to the calling routine.
Once all the requested actions from other tasks have been
handled, the command processor attempts to process the
internal command queue of the current session. Rather then
holding off the command processor from processing commands on the queue until a queue load is complete, we
opted to exploit the power of the BCP by using a parallel
processing approach where both the background receiver
interrupt and the foreground command processor have access to the command queue simultaneously. This enables
the command processor to execute commands even while
the queue is still being loaded by the host. To avoid conflicts, the command processor twÐsession takes a ‘‘snap
shot’’ of the current internal command queue and current
exception status (in the poll response byte). The command
processor then works from the ‘‘snap shot’’ while the background receiver task updates in real time.
The ‘‘snap shot’’ involves the following steps. Interrupts are
disabled to prevent background tasks from updating the
command queue. The command queue is then checked to
see if another task has marked it as ‘‘corrupt’’. When a
background task determines that the command queue may
contain invalid data (for example, due to a line parity error or
the detection of an exception) it marks the queue as corrupt
and schedules that session. The twÐsession routine then
flushes the queue when it gets control. Flushing the command queue resets all the queue pointers and flags. This
marks the command queue as empty. It also signals the
background tasks that twÐ session has acknowledged the
error and cleaned up the command queue. This handshake
is required since background tasks are only allowed to push
onto the internal command queue, never flush it. (At the
next poll to this session, the background receiver interrupt
will indicate ‘‘not busy’’ to signal the host that this device
has completed error recovery.) After the command queue is
flushed, twÐsession will deschedule this twinax session
and return to the calling routine (twÐtask). If the internal
command queue is not corrupt, twÐsession checks to see if
it is ‘‘ready’’ for processing. The command queue is marked
as ‘‘not ready’’ while the background receiver interrupt is in
the middle of pushing a multi-byte command (for example
the LOAD ADDRESS COUNTER command) onto the
The Twinax Session Command Processor
The twinax session command processor, twÐsession, is located in module TWÐSESS.BCP. Its job is to perform all
non time-critical functions related to sustaining an active
twinax session. This includes processing the internal command queue, error recovery, and performing a POR. In addition, twÐsession and its subordinate routines are responsible for communicating important events (like screen updates) to the emulation interface routine (i.e., the smart alec
task), which operates asynchronously to twinax session activity.
The command processor, twÐsession, and its subordinate
routines are written with ‘‘reusable’’ code. That is, all the
information regarding a given twinax session’s state is kept
in the SCP (the data memory Session Control Page) attached to that physical session. There is no dependency
between twÐsession and an active session’s state from
one call to the next. At any time, any SCP may be passed to
twÐsession. In other words, the current state of a given
physical twinax session exists only in its SCP, not in the
command processor. This gives one set of routines
(twÐsession and its subordinates) the ability to process all
the active twinax sessions concurrently. The twinax task
twÐtask simply passes the pointer of the scheduled session’s SCP (via the IZ register) to twÐsession and twÐ
62