Zilog Z16C30 - Manual (Page 81)

5-14
Z16C30 USC ®
U SER ' S M ANUAL
UM97USC0100
Z ILOG
5.11 TRANSPARENT BISYNC MODE
This mode is more specific to the Transparent Mode option
of IBM Corp.’s Binary Synchronous Communications pro-
tocol than is the Bisync mode described above. Software
can select this mode for the Transmitter and the Receiver,
by programming the TxMode and RxMode fields of the
Channel Mode Register (CMR11-8 and CMR3-0) to 0111.
In Monosync and Bisync modes the Sync characters are
programmable, but in this mode a channel uses the fixed
characters “DLE” for the first of a sync pair, and “SYN” for
the second of a pair. (Software can make the Transmitter
send only SYNs for closing and idle Syncs.) The LSBits of
the TxSubMode and RxSubMode fields (CMR12 and CMR4)
control whether the Transmitter and Receiver use the
ASCII or EBCDIC codes for control characters, with a 1
specifying EBCDIC.
Besides using DLE before an opening and possibly a
closing SYN, the Transmitter can check whether each data
character coming out of the TxFIFO is a DLE and insert
another DLE if so. This feature allows any kind of data to be
sent “transparently”. The Transmitter doesn’t include such
an inserted DLE in its CRC calculation. Software can
selectively enable and disable this function using the
Enable DLE Insertion and Disable DLE Insertion com-
mands, as described later in the 'Commands' section. In
general software should enable DLE insertion for sending
data and disable it for sending a control sequence that
starts with DLE. The channel routes the state controlled by
these commands through the TxFIFO with each character,
so that software can change the state as needed.
Similarly, in Transparent Bisync mode the Receiver checks
whether each character coming out of its shift register is a
DLE. If so, it sets a state bit. If the next character is also a
DLE, the Receiver doesn’t include it in the RxFIFO nor in the
CRC calculation.
If the character after a DLE is a SYN, the Receiver excludes
both the DLE and the SYN from the CRC calculation, but
places both characters in the FIFO so that they will appear
in the received data stream.
If the character after a DLE is any of the terminating codes
“ITB”, “ETX”, “ETB”, “EOT”, or “ENQ”, the Receiver places
the terminating character in the RxFIFO marked with
RxBound status. As described in later sections, this mark-
ing may set the channel’s Received Data Interrupt Pending
bit and thus force an interrupt request on its /INT pin, and/
or it may force a DMA request on the /RxREQ pin.
The first “DLE-SOH” or “DLE-STX” in a message makes the
Receiver enable its CRC generator for subsequent data.
Therefore, the CRC in Transparent Bisync mode covers all
the data after the first DLE-SOH or DLE-STX.
The Receiver doesn’t take any other special action based
on received DLE’s.
A Transmitter in Transparent Bisync mode sends a DLE-
SYN pair at the start of a message, but a Receiver in this
mode syncs up to SYN-SYN. This is so that software can
determine “transparency” separately for each message,
by testing whether the first character of the message in the
RxFIFO is a DLE.
The following table shows the ASCII and EBCDIC codes
that a channel recognizes in this mode:
Character ASCII Code
16
EBCDIC Code
16
DLE 10 10
ENQ 05 2D
EOT 04 37
ETB 17 26
ETX 03 03
ITB 1F 1F
SOH 01 01
STX 02 02
SYN 16 32
Given the dedicated nature of the Sync characters, the
Transmitter interprets the three MSBits of the TxSubMode
field similarly to the way it does so in Bisync mode. If
CMR15 is 1, it sends a CRC when a Tx Underrun condition
occurs. If CMR14 is 1, the Transmitter sends one or more
DLE-SYN pairs after a message, else it just sends SYNs. If
CMR13 is 1, it sends a Preamble sequence before the
opening Sync at the start of each message.
The same data checking options apply to this mode as in
Monosync and Bisync, but since we’re quite protocol-
specific here, we can say that character parity is not used
while CRC-16 checking is. While the Receiver can detect
the end of the frame in Transparent Bisync mode, the
Receive Status Block feature can’t be used to capture the
CRC Error status of the frame, for reasons discussed later
in the 'Cyclic Redundancy Checking' section. But the
selective inclusion/exclusion of received data in the CRC
calculation, that’s typical of this mode, precludes the kind
of automatic reception that the RSB feature allows in
modes like HDLC/SDLC anyway.
The USC doesn’t use the three MSBits of the RxSubMode
field (CMR7-5) in Transparent Bisync mode, but Zilog
reserves these bits for future enhancements and software
should always program them as 000 in this mode.
UM009402-0201