- 1 - XMODEM/YMODEM PROTOCOL REFERENCE A compendium of documents describing the XMODEM and YMODEM file transfer Protocols Edited by Chuck Forsberg Please distribute as widely as possible. Questions to Chuck Forsberg Omen Technology Inc 17505-V Sauvie Island Road Portland Oregon 97231 Voice: 503-621-3406 Modem (Telegodzilla): 503-621-3746 Speed 1200,300 Compuserve: 70715,131 UUCP: ...!tektronix!reed!omen!caf XMODEM/YMODEM Protocol Reference 1 - 2 - Chapter 1 1. TOWER OF BABEL ?? In the interest of fostering compatibility among communications programs, part of of the Professional-YAM manual is reproduced here to minimize the Electronic Tower of Babel. The YMODEM Protocol is supported by the public domain programs YAM (CP/M), YAM(CP/M-86), YAM(CCPM-86), rb/sb (Unix, Berkeley Unix, Venix, Xenix, Coherent, IDRIS, Regulus) as well as Professional-YAM. These programs have been in use since 1981. The protocols described below are enhancements to Ward Christensen's XMODEM protocol, and are public domain. The 1k packet length capability described below may be used in conjunction with the Batch Protocol, or with single file transfers identical to the XMODEM/CRC protocol except for minimal changes to support 1k packets. To complete this tome, Ward Christensen's original protocol document and John Byrns's CRC-16 document are included for reference. References to the MODEM or MODEM7 protocol have been changed to XMODEM to accommodate the vernacular. Watch for an article describing the YMODEM protocol in a more coherent fashion later this year. This article will include some interesting history on the development of file microcomputer file transfers. 1.1 Some Messages from the Pioneer #: 130940 S0/Communications 25-Apr-85 18:38:47 Sb: my protocol Fm: Ward Christensen 76703,302 (EDITED) To: all Be aware the article1 DID quote me correctly in terms of the phrases like "not robust", etc. It was a quick hack I threw together, very unplanned (like everything I do), to satisfy a personal need to communicate with "some other" people. ONLY the fact that it was done in 8/77, and that I put it in the public domain immediately, made it become the standard that it is. __________ 1. Infoworld April 29 p. 16 2 Vsn 13.09 05-05-85 TurboDial 1.02 - 3 - Chapter 1 I think its time for me to (1) document it; (people call me and say "my product is going to include it - what can I 'reference'", or "I'm writing a paper on it, what do I put in the bibliography") and (2) propose an "incremental extension" to it, which might take "exactly" the form of Chuck Forsberg's YAM protocol. He wrote YAM in C for CP/M and put it in the public domain, and wrote a batch protocol for Unix called rb and sb (receive batch, send batch), which was basically XMODEM with (a) a record 0 containing filename date time and size (b) a 1K block size option (c) CRC-16. He did some clever programming to detect false ACK or EOT, but basically left them the same. People who suggest I make SIGNIFICANT changes to the protocol, such as "full duplex", "multiple outstanding blocks", "multiple destinations", etc etc don't understand that the incredible simplicity of the protocol is one of the reasons it survived to this day in as many machines and programs as it may be found in! Consider the PC-NET group back in '77 or so - documenting to beat the band - THEY had a protocol, but it was "extremely complex", because it tried to be "all things to all people" - i.e. send binary files on a 7-bit system, etc. I was not that "benevolent". I (emphasize > I < ) had an 8-bit UART, so "my protocol was an 8-bit protocol", and I would just say "sorry" to people who were held back by 7-bit limitations. ... Block size: Chuck Forsberg created an extension of my protocol, called YAM, which is also supported via his public domain programs for UNIX called rb and sb - receive batch and send batch. They cleverly send a "block 0" which contains the filename, date, time, and size. Unfortunately, its UNIX style, and is a bit weird2 - octal numbers, etc. BUT, it is a nice way to overcome the kludgy "echo the chars of the name" introduced with MODEM7. Further, chuck uses CRC-16 and optional 1K blocks. Thus the record 0, 1K, and CRC, make it a "pretty slick new protocol" which is not significantly different from my own. Also, there is a catchy name - YMODEM. That means to some that it is the "next thing after XMODEM", and to others that it is the Y(am)MODEM protocol. I don't want to emphasize that too much - out of fear that other mfgrs might think it is a "competitive" protocol, rather than an __________ 2. The Unix style stuff (time, file mode) is optional. The pathname and file length may be sent alone if desired. XMODEM/YMODEM Protocol Reference 3 - 4 - Chapter 1 "unaffiliated" protocol. Chuck is currently selling a much-enhanced version of his CP/M-80 C program YAM, calling it Professional Yam, and its for the PC - I'm using it right now. VERY slick! 32K capture buffer, script, scrolling, previously captured text search, plus built-in commands for just about everything - directory (sorted every which way), XMODEM, YMODEM, KERMIT, and ASCII file upload/download, etc. You can program it to "behave" with most any system - for example when trying a number for CIS it detects the "busy" string back from the modem and substitutes a diff phone # into the dialing string and branches back to try it. 4 Vsn 13.09 05-05-85 TurboDial 1.02 - 5 - Chapter 2 XMODEM Protocol Enhancements 2. XMODEM PROTOCOL ENHANCEMENTS Professional-YAM uses several compatible extensions and logic enhancements to the widely used Ward Christensen XMODEM protocol. This chapter discusses the protocol extensions to Ward Christensen's 1982 XMODEM protocol description document. YAM does not ask the operator whether he wishes to keep retrying after 10 attempts have failed to correctly transfer a packet. Virtually all correctable errors are corrected within the first few retransmissions. If the line is so bad that ten attempts are insufficient, there is a significant danger of undetected errors. In that case, it's better to redial for a better connection. 2.1 CAN-CAN Abort YAM recognizes a sequence of two consecutive CAN (Hex 18) characters without modem errors (overrun, framing, etc.) as a transfer abort command.1 The check for two consecutive CAN characters virtually eliminates the possibility of a line hit aborting the transfer. YAM sends five CAN characters when it aborts a XMODEM protocol file transfer, followed by five backspaces to delete the CAN characters from the remote's keyboard input buffer (in case the remote had already aborted the transfer). 2.2 CRC-16 Option The XMODEM protocol uses an optional two character CRC-16 instead of the one character arithmetic checksum used by the original protocol and by most commercial implementations. CRC-16 guarantees detection of all single and double bit errors, all errors with an odd number of error bits, all burst errors of length 16 or less, 99.9969% of all 17-bit error bursts, and 99.9984 per cent of all possible longer error bursts. By contrast, a double bit error, or a burst error of 9 bits or more can sneak past the XMODEM protocol arithmetic checksum. The XMODEM/CRC protocol is similar to the XMODEM protocol, except that the receiver specifies CRC-16 by sending C (Hex 43) instead of NAK when requesting the FIRST packet. A two byte CRC is sent in place of the one byte arithmetic checksum. YAM's c option to the r command enables CRC-16 in single file reception, corresponding to the original implementation in __________ 1. This is recognized when YAM is waiting for the beginning of a packet or for an acknowledge to one that has been sent. XMODEM/YMODEM Protocol Reference 5 - 6 - XMODEM Protocol Enhancements Chapter 2 the MODEM7 series programs. Many commercial communications programs and bulletin board systems still do not support CRC-16, especially those written in Basic or Pascal. XMODEM protocol with CRC is accurate provided both sender and receiver both report a successful transmission. The protocol is robust in the presence of characters lost by buffer overloading on timesharing systems. Professional-YAM add several proprietary logic enhancements to XMODEM's error detection and recovery. These compatible enhancements eliminate most of the bad file transfers other programs make when using the XMODEM protocol under less than ideal conditions. 2.3 1024 Byte Packet Option If YAM is sending with the k option, the transmitted packet contains 1024 bytes of data. An STX (02) replaces the SOH (01) at the beginning of the transmitted block to notify the receiver of the longer packet length. The r...
Amiga7878