I'll first describe the vanilla xmodem protocol as originated by Ward
Christensen for data exchange between CP/M microcomputers.  Then I'll
touch on a couple of refinements that have been added over the years to
allow for better error checking, faster transfers, and transfers of
multiple files.  
    All these protocols assume that eight-bit data is to be sent, and that
no 8-bit pattern has any special significance.  That's the idea, to
transfer any file whatsoever, be it data, a program or text.  The COM:
settings will be 8N1D:  8 bits, no parity, 1 stop bit, X-on X-off disabled.
...........
    Glossary of signals used in xmodem exchanges:
    signal name    ascii character    CHR$(.)             meaning
        NAK             ^U              21              non-acknowledge
        ACK             ^F               6              acknowledge
        SOH             ^A               1              start of header
        EOT             ^D               4              end of transmission
        CAN             ^X              24              cancel exchange
...........
    In a vanilla Xmodem exchange each packet sent by the transmitter
consists of 132 bytes.  The actual data is preceded by three bytes: first
the SOH character, then the packet number, then the onesU complement of
the packet number.  Then come the 128 data bytes.  That accounts for 131
bytes.  The 132nd byte is the checksum, which is simply the arithmetic
sum, modulo 256, of all the 128 data bytes.  The packet number commences
with 1 for the first packet and increases modulo 256. If N is the packet
number, then its ones' complement is calculated as (N XOR 255).
    The receiver checks the 132 bytes to see that the first character is
in fact  SOH, that the packet number and its complement agree and are in
sequence, and that the checksum as computed by the receiver agrees with
that sent by the transmitter.  After checking the packet and handling its
filing, the receiver responds by sending either ACK, to acknowledge
correct reception, or NAK to signal an error, or CAN to cancel the
exchange.
    The transmitter accordingly retransmits the previous packet, or a new
one, or stops.
    To commence the exchange and get the transmitter to send its first
packet, the receiver sends out the NAK character.  It repeats sending the
NAK at ten second intervals until the transmitter responds, or until a
time limit is reached (usually one minute).
     To finish off the exchange, after acknowledgement of the final
packet, the transmitter sends the EOT character and waits for the receiver
to respond with ACK and then goes on to its next task.  If the receiver
responds with anything but ACK or CAN the transmitter tries again (up to a
time limit) to send EOT until it does receive the ACK or CAN.
    The ACK, NAK and EOT signals sent are repeated at ten second intervals
(up to 6 or so tries) until the expected response occurs.

    The xmodem protocol is not without faults.  Transmitted data can be
corrupted and still yield a match in the checksum.  In a channel with high
levels of normally distributed noise, the error rate can theoretically
approach 4%, and even worse for burst noise.  Error checking using a CRC
(cyclic redundancy check) is more effective.  A variation of xmodem
implements CRC error checking.  Sometimes the CRC is not at all necessary.
 Phone channels are sometimes very, very good, and you can safely transfer
data in longer packets, say, 1028 bytes instead of 128.  The transfer is
then faster.  A variant of xmodem enables that.  Another optional feature
allows you to transfer a bunch of files at once.  That is Ymodem, which in
many ways is very much like xmodem.  These are topics for chapter 2 of
these notes.  Usually, the programs are set up to recognize and respond to
these alternative forms of xmodem automatically.
    All of the  versions of xmodem assume an 8-bit channel for
transferring data.  That is no insurmountable problem in transfers of data
between microcomputers. But minis and mainframes are often very rigid and
allow you only a seven bit channel, and even then they treat certain of
the control characters in special ways.  In such cases, Kermit is the
protocol of choice, rather than xmodem.  Another disadvantage of xmodem is
that the packets are all of fixed length.  The final packet of a
transmission may have to be padded at the end with some garbage.  The
receiver or the operating system on the receiving end has to know how to
deal with that.  Variable length packets also allow the packet length to
adjust to the amount of noise on the line.  Kermit allows for variable
length packets.


    

by Tracy Allen, 2018 Parker St., Berkeley, CA 94704     (415)848-5725
CIS 76670,326         Date  3/27/89   draft.