Bi-Sync Data Exchange

Microsell Systems
(Received 20 July 1984)

Dear Joe

I have used your mark-ups to update and expand my Bi-Sync comms documentation and I've enclosed a new copy for your perusal.

I would like to make a few proposals for the implementation of comms between the Epson QX10 and the Microsell till. I would appreciate your reaction to these proposals and any suggestions or modifications you might care to make.

  1. Since we will be using asynchronous modems, I feel there is no real need to include any SYN characters in the transmitted data stream. SYN can be treated exactly like any other data character.
  2. A known failing of Bi-sync is the lack of CRC characters on link control messages. It is possible (and we have had it happen) for a data block to be repeated any odd number of times without either end becoming aware of the error. This results from miss-interpretation of link messages – AK0, ACK1, NAK, etc. by one or the other ends when using low-grade telephone lines. This has forced us to use sequence numbers on all data transmissions to allow duplicated records to be discarded. By including CRCs on all transmitted messages, this problem should not arise.
  3. I do not know what character set the BCL uses, but I assume the EPSON uses ASCII. I propose that we use ASCII rather than EBCDIC characters for our data communications, if for no other reason than ease of debugging.
    The special characters I am proposing are as follows:
  4. For ease of coding, all transmitted characters (including SOH/STX) are included in the CRC calculation.
  5. All data will be non-transparent - i.e. printable.
  6. Software updates will probably be sent directly from Microsell rather than re-distributed as part of normal shop polling. The data formats will conform to the above however, by transmitting object code as two character hex equivalents of each byte.
  7. Data will be transmitted as eight bit data without parity. The CRC will provide more data integrity than parity bits would. It is necessary to use eight bit data to allow the CRC to be transmitted, since its range is not restricted to 7 bit values.
  8. Transmitted characters will have their sign bit set to zero, except, as noted above, for the CRC characters.

The actual format of data and update records to be sent is still to be determined by the other programmers who are coding the Staples software. If you have any particular requirements in this area, please do not hesitate to let me know.

Yours sincerely,

Jim Segrave

Bi-Sync Telecomms Description

BI-SYNC (binary synchronous communications) consists of a protocol for transmitting data in blocks with error-checking and recovery procedures. It is a half-duplex protocol in that one machine normally is transmitting data and the other is receiving. A special control sequence (line bidding) is used to reverse the direction of transmission. The protocol uses a set of control characters to format data blocks.

SOH01hDelimits the beginning of a header in a data block.
STX02hDelimits the start of data in a data block.
ETX03hMarks the end of data in a block. Data blocks ending with ETX are considered as end-of-file records.
ETB26hMarks the end of a data block that is not the end of a file.
ITB1FhMarks the end of an Intermediate Text (data) Block when more than one data block forms a single transmission record.
ENQ2DhIn data blocks, marks the end of an aborted data block - i.e. the sender will not be able to complete the transmission of this data block.
EOT37hMarks the end of transmission by a machine. The receiver may now enter a line bid state to send data back.
SYN32hA synchronising (pad) character.
DLE10hAn escape character allowing the following character to take on a special meaning.

Data Block Format

Data may be sent in one of two modes - transparent and non-transparent. In non-transparent mode, the special characters STX, SOH, ENQ, ETX, ETB, DLE, ITB, and SYN must not occur as part of the data to be transmitted. Transparent mode provides a mechanism for sending these characters and distinguishing them from control meanings.

The simplest data block contains one single data record:

SYN SYN <STX/SOH> <data - any length including 0> <ETB/ETX> <CRC>

Either STX or SOH may be used to mark the start of data. The CRC is a 16-bit block check character. The CRC is computed on all the data characters and the <ETX/ETB>. SYN characters may occur anywhere within the data portion and are ignored as data and not included in CRC calculation.

A data block may have both a header text and data:

SYN SYN SOH <header text> STX <data> <ETB/ETX> <CRC>

The header and or data text may be empty. SYN characters may be included anywhere within the header or data area and are ignored. The CRC includes all characters after the SOH up to and including the ETX/ETB (except SYNs),

More than one data block may occur within a record:

SYN SYN STX <data> ITB <CRC 1> ... STX <data> <ETX/ETB> CRC-n

Any number of data blocks terminated by ITB's may occur. The first data block CRC is accumulated after the STX through and including the ITB. Subsequent data blocks include their STX/SOH characters.

Transparent Data Transmission:

Data record formats are identical to non-transparent blocks except that:

  1. STX and SOH characters in non-transparent data are replaced by the two-character sequence DLE STX, DLE SOH.
  2. SYN characters supplied as pads are replaced by DLE SYN.
  3. The data character DLE is sent as DLE DLE
  4. End of data is represented by DLE ITB, DLE ETB, or DLE ETX as appropriate.

DLE characters added as escapes are not included in CRC accumulation. CRC characters are never escaped by DLEs.

In line bid stateRepresents a request by the sending machine to enter the transmit state.
In transmit stateRequests the receiving end to repeat its last response to the transmitting end.
In receive modeNever sent.
In line bid stateThe sending end is ready to enter receive state.
In transmit stateNever used.
In receive stateAn acknowledge of the last even numbered data block received – the initial line bid <ENQ> is considered as message number 0.
In line bid stateNever used.
In transmit stateNever used.
In receive stateAn acknowledge of the last odd numbered data block received.
In line bid stateNever used.
In transmit stateNever used.
In receive stateRejects the last data block received. This message is only sent once for each data block received. Subsequent ENQs from the transmitting end are responded to by repeating the appropriate AK0 or AK1 for the last good data block.
In line bid stateNever used.
In transmit stateNever used.
In receive stateThis message is sent by the receiver as an ack of a data block and a request for the transmitting end to stop sending and enter the line bid state to allow the receiving end to transmit some urgent data. The transmitting end takes this message as being either an AK0 or AK1, whichever is expected. The transmitting end is not obliged to honour the line turn around request. This message should only be sent in reply to a single data block. If the transmitting end does not cede the line, the receiver should revert to the AK0 AK1 response sequence for subsequent data blocks.
In line bid stateNever used
In transmit stateNever used.
In receive stateThis message is sent by a receiver to acknowledge a data block received and request that the transmitter pause in sending, perhaps because the receiver’s buffers are all filled. The transmitter then replies with ENQs and the receiver with WAKs until the condition is cleared, at which point the receiver replies to the ENQ with an AK0 or AK1 (appropriate to the data block which caused the buffer full condition).
In line bid stateNever used.
In transmit stateThe transmitting end sends this message when it is not ready with the next data block for transmission. It keeps the comms line open while the next data block is being prepared. The receiving end responds to a TTD with a NAK. When the transmitter finally has data ready, it resumes normal sending.
In receive stateNever used.
In line bid stateNever used.
In transmit stateInstructs the receiving end to terminate comms immediately. Used at the end of a comms session or as a last resort during fatal errors.
In receive stateAs transmit state.
In line bid stateNever used.
In transmit stateSent by the transmitting end to indicate that it is unable to complete sending of this data block. Used, for example, if the transmitter discovers a special character in a non-transparent data block. The receiver replies with a NAK.
In receive stateNever used.
In line bid stateMay be sent by the machine that last had transmit status. It indicates that that end has completed transmitting and is expecting the end that was receiving to begin bidding for the line by sending ENQs.
In transmit stateIndicates that sending end has completed transmission of all its data and is ready to enter line bid state. This only applies if the last data block sent ended with an ETX and not an ETB. ETX is an end-of-file mark and it is assumed that the line will only turn around at the end of files. If the last data block sent ended with an ETB, this indicates an unrecoverable error and comms should be abandoned. A transmitting station which has just gained transmit state from a line bid may send an EOT if it has no data to send.
In receive modeUsed to indicate an unrecoverable error at the receiving end. Comms should be abandoned.

Basic Bi-Sync Comms Structure:

Stations communicating in BI-SYNC are considered to be in one of three states: line bid, transmit, or receive. Comms sessions always begin in line bid state from which one end exits to transmit state, the other to receive state. At the end of transmission from the unit in transmit state, line bid state is re-entered and the unit which was in receive state now bids for transmit state (line turn-around).

The unit which has transmit state has complete control of the comms line. The receive state end only sends messages in reply to data or link control messages from the transmit end. The only exception to this is the unsolicited sending of EOT or DSC to terminate comms on fatal errors. The normal processing consists of the transmit end sending a message and the receive end sending a reply. The transmit end allows the receive end three seconds from sending the message to getting a valid reply. Seven attempts are made to get a successful exchange, then the call is abandoned.

In line bid state, neither end controls the line. Both ends may attempt to assume transmit state by sending ENQs. To resolve this conflict, one station - the called one in switched networks - is designated as a master and the other end as a secondary station. Master stations wait only two seconds for an AK0 to their ENQ bid, secondaries wait three. If a secondary station receives an ENQ after it has sent an ENQ, this indicates that the master station also wants to assume transmit status. The secondary must respond with AK0 and cede transmit status to the master. Up to fifteen bid tries are allowed before abandoning the line - 30 seconds for a master, 45 for a secondary.

Line Bid - Master Station




Abandon call
Others (including no reply)
Decrement retry count and go again.

Line Bid - Secondary Station




Abandon call
Others (including no reply)
Decrement error count and try again

Transmit State:



  1. If data is ready:
    Send data block.
    Get response:
    If this is expected ack, toggle expected ack, prepare to send the next data block.
    If this is the wrong ack and the last transmission was a data block, fatal error - wrong acknowledge - the receiver is out of step with the transmitter.
    If this was the wrong ack and the last transmission was ENQ, (not in response to a WAK), the receiver did not see the last data block. Decrement error count and re-send data.
    Decrement error count and re-send data.
    Fatal error at receive end - abandon comms.
    Abandon comms.
    Treat as if it were the expected ACK and toggle the expected ACK flag. The transmitter can either wrap up transmission, send EOT and enter line bid state - honouring the RVI - or it may ignore the RVI and continue by sending the next data block.
    Reset error count, send ENQ immediately. The receiver will (within three seconds) either send another WAK if it is still not ready or send the expected ack. No limit is set on the amount of time a receiver may take as long as it sends WAKs.
    DATA block
    Fatal error - abandon comms - the receiver disagrees on its current state and seems to think it is in transmit state.
    Other (including no response)
    Send ENQ, decrement error count, and get reply again.
  2. If data is not ready:
    Send TTD
    Get response:
    Abandon comms
    Abandon comms
    Reset error count, allow up to two seconds for a transmit block to become available. If, at the end of two seconds, a data block is ready for transmission, go to the normal data transmission routine, otherwise re-send TTD.
    Other (including no response)
    Decrement error count, wait up to two seconds for data to become available. If data becomes ready within the two-second time, send it as normal, otherwise re-send TTD.
  3. If all data is sent:
    Send EOT
    Get response:
    Abandon comms.
    Abandon comms - this could be a normal ending if both ends have completed whatever transmissions were expected.
    Enter LINE BID STATE - the receiver has seen the EOT and is bidding to transmit.
    Other (including no response)
    Decrement error count and re-send EOT. For reasons not made clear, IBM mainframes only allow EOT to be sent twice at the end of transmitting data.

Receive State:

ERROR COUNT = 7, TIMEOUT = 3 seconds.


Get a message:

If last data received ended in ETX or if no data has been sent, send ENQ and enter LINE BID STATE. If last data ended in ETB, abandon comms - unrecoverable error at transmit end.
Abandon comms.
Toggle current ack and send it. If no further receive buffers are available, send WACK. If the last response sent was a WACK, abandon comms (transmitter did not honour WACK).
Send NAK, reset error count.
Send NAK immediately, reset error count.
Send current ack if ready to receive data. If last response from receiving end was WACK and no data buffers are available, re-send WACK.
Garbled data
Send NAK, decrement error count.
No data
Decrement error count, send nothing.

The Protocol Handbook