Table of Contents1. DEFINITIONS2. TRANSMISSION MEDIUM LEVEL PROTOCOL3. MESSAGE BLOCK LEVEL PROTOCOL4. FILE LEVEL PROTOCOL5. DATA FLOW EXAMPLE INCLUDING ERROR RECOVERY6. PROGRAMMING TIPS.-------- 1. DEFINITIONS.  <soh> 01H   <eot> 04H   <ack> 06H   <nak> 15H   <can> 18H-------- 2. TRANSMISSION MEDIUM LEVEL PROTOCOLAsynchronous, 8 data bits, no parity, one stop bit.    The protocol imposes no restrictions on the contents of thedata being transmitted.  No control characters are looked forin the 128-byte data messages.	Absolutely any kind of data maybe sent - binary, ASCII, etc.  The protocol has not formallybeen adopted to a 7-bit environment for the transmission ofASCII-only (or unpacked-hex) data , although it could be simplyby having both ends agree to AND the protocol-dependent datawith 7F hex before validating it.  I specifically am referringto the checksum, and the block numbers and their ones-complement.    Those wishing to maintain compatibility of the CP/M filestructure, i.e. to allow modemming ASCII files to or from CP/Msystems should follow this data format:  * ASCII tabs used (09H); tabs set every 8.  * Lines terminated by CR/LF (0DH 0AH)  * End-of-file indicated by ^Z, 1AH.  (one or more)  * Data is variable length, i.e. should be considered a    continuous stream of data bytes, broken into 128-byte    chunks purely for the purpose of transmission.  * A CP/M "peculiarity": If the data ends exactly on a    128-byte boundary, i.e. CR in 127, and LF in 128, a    subsequent sector containing the ^Z EOF character(s)    is optional, but is preferred.  Some utilities or    user programs still do not handle EOF without ^Zs.  * The last block sent is no different from others, i.e.    there is no "short block".-------- 3. MESSAGE BLOCK LEVEL PROTOCOL Each block of the transfer looks like:<SOH><blk #><255-blk #><--128 data bytes--><cksum>    in which:<SOH>	    = 01 hex<blk #>     = binary number, starts at 01 increments by 1, and	      wraps 0FFH to 00H (not to 01)<255-blk #> = blk # after going thru 8080 "CMA" instr, i.e.	      each bit complemented in the 8-bit block number.	      Formally, this is the "ones complement".<cksum>     = the sum of the data bytes only.  Toss any carry.-------- 4. FILE LEVEL PROTOCOL---- 4A. COMMON TO BOTH SENDER AND RECEIVER:    All errors are retried 10 times.    Some versions of the protocol use <can>, ASCII ^X, tocancel transmission.  This was never adopted as a standard, ashaving a single "abort" character makes the transmissionsusceptible to false termination due to an <ack> <nak> or <soh>being corrupted into a <can> and cancelling transmission.    The protocol may be considered "receiver driven", that is,the sender need not automatically re-transmit, although it doesin the current implementations.---- 4B. RECEIVE PROGRAM CONSIDERATIONS:    The receiver has a 10-second timeout.  It sends a <nak>every time it times out.  The receiver's first timeout, whichsends a <nak>, signals the transmitter to start.  Optionally,the receiver could send a <nak> immediately, in case the senderwas ready.  This would save the initial 10 second timeout.However, the receiver MUST continue to timeout every 10 secondsin case the sender wasn't ready.    Once into a receiving a block, the receiver goes into aone-second timeout for each character and the checksum.  If thereceiver wishes to <nak> a block for any reason (invalidheader, timeout receiving data), it must wait for the line toclear.	See "programming tips" for ideas    Synchronizing:  If a valid block number is received, itwill be: 1) the expected one, in which case everything is fine;or 2) a repeat of the previously received block.  This shouldbe considered OK, and only indicates that the receivers <ack>got glitched, and the sender re-transmitted; 3) any other blocknumber indicates a fatal loss of synchronization, such as therare case of the sender getting a line-glitch that looked likean <ack>.  Abort the transmission, sending a <can>---- 4C. SENDING PROGRAM CONSIDERATIONS.    While waiting for transmission to begin, the sender hasonly a single very long timeout, say one minute.  In thecurrent protocol, the sender has a 10 second timeout beforeretrying.  I suggest NOT doing this, and letting the protocolbe completely receiver-driven.	This will be compatible withexisting programs.    When the sender has no more data, it sends an <eot>, andawaits an <ack>, resending the <eot> if it doesn't get one.Again, the protocol could be receiver-driven, with the senderonly having the high-level 1-minute timeout to abort.-------- 5. DATA FLOW EXAMPLE INCLUDING ERROR RECOVERYHere is a sample of the data flow, sending a 3-block message.It includes the two most common line hits - a garbaged block,and an <ack> reply getting garbaged.  <xx> represents thechecksum byte.SENDER					RECEIVER				times out after 10 seconds,			<---		<nak><soh> 01 FE -data- <xx> --->			<---		<ack><soh> 02 FD -data- xx	--->	(data gets line hit)			<---		<nak><soh> 02 FD -data- xx	--->			<---		<ack><soh> 03 FC -data- xx	--->   (ack gets garbaged)  <---            <ack><soh> 03 FC -data- xx	--->		<ack><eot>			--->			<---		<ack>-------- 6. PROGRAMMING TIPS.* The character-receive subroutine should be called with aparameter specifying the number of seconds to wait.  Thereceiver should first call it with a time of 10, then <nak> andtry again, 10 times.  After receiving the <soh>, the receiver should call thecharacter receive subroutine with a 1-second timeout, for theremainder of the message and the <cksum>.  Since they are sentas a continuous stream, timing out of this implies a seriouslike glitch that caused, say, 127 characters to be seen insteadof 128.* When the receiver wishes to <nak>, it should call a "PURGE"subroutine, to wait for the line to clear.  Recall the sendertosses any characters in its UART buffer immediately uponcompleting sending a block, to ensure no glitches were mis-interpreted.  The most common technique is for "PURGE" to call thecharacter receive subroutine, specifying a 1-second timeout,and looping back to PURGE until a timeout occurs.  The <nak> isthen sent, ensuring the other end will see it.* You may wish to add code recommended by John Mahr to yourcharacter receive routine - to set an error flag if the UARTshows framing error, or overrun.  This will help catch a fewmore glitches - the most common of which is a hit in the highbits of the byte in two consecutive bytes.  The <cksum> comesout OK since counting in 1-byte produces the same result ofadding 80H + 80H as with adding 00H + 00H.--------------------------------------------------------------MODEM PROTOCOL OVERVIEW,  CRC OPTION ADDENDUM1/13/85 by John Byrns.Please pass on any reports of errors in this document or suggestionsfor improvement to me via Ward's/CBBS at (312) 849-1132, or by voiceat (312) 885-1105.Last Rev: (preliminary  1/13/85)This document describes the changes to the Christensen Modem Protocolthat implement the CRC option. This document is an addendum toWard Christensen's "Modem Protocol Overview". This document andWard's document are both required  for a complete description of theModem Protocol.	Table of Contents1.  DEFINITIONS7.  OVERVIEW OF CRC OPTION8.  MESSAGE BLOCK LEVEL PROTOCOL, CRC MODE9.  CRC CALCULATION10. FILE LEVEL PROTOCOL, CHANGES FOR COMPATIBILITY11. DATA FLOW EXAMPLES WITH CRC OPTION---- 1B. ADDITIONAL DEFINITIONS<C>	43H-------- 7. OVERVIEW OF CRC OPTIONThe CRC used in the Modem Protocol is an alternate form of block checkwhich provides more robust error detection than the original checksum.Andrew S. Tanenbaum says in his book, Computer Networks, that theCRC-CCITT used by the Modem Protocol will detect all single and doublebit errors, all errors with an odd number of bits, all burst errors oflength 16 or less, 99.997% of 17-bit error bursts, and 99.998% of18-bit and longer bursts.The changes to the Modem Protocol to replace the checksum with the CRCare straight forward. If that were all that we did we would not beable to communicate between a program using the old checksum protocol