diff options
Diffstat (limited to 'com32/sysdump/ymodem.txt')
-rw-r--r-- | com32/sysdump/ymodem.txt | 2108 |
1 files changed, 0 insertions, 2108 deletions
diff --git a/com32/sysdump/ymodem.txt b/com32/sysdump/ymodem.txt deleted file mode 100644 index 2264ff78..00000000 --- a/com32/sysdump/ymodem.txt +++ /dev/null @@ -1,2108 +0,0 @@ - - - - - 1 - - - - - XMODEM/YMODEM PROTOCOL REFERENCE - A compendium of documents describing the - - XMODEM and YMODEM - - File Transfer Protocols - - - - - This document was formatted 10-14-88. - - - - - - - - Edited by Chuck Forsberg - - - - - - - - - - This file may be redistributed without restriction - provided the text is not altered. - - Please distribute as widely as possible. - - Questions to Chuck Forsberg - - - - - - Omen Technology Inc - The High Reliability Software - 17505-V Sauvie Island Road - Portland Oregon 97231 - VOICE: 503-621-3406 :VOICE - TeleGodzilla BBS: 503-621-3746 Speed 19200(Telebit PEP),2400,1200,300 - CompuServe: 70007,2304 - GEnie: CAF - UUCP: ...!tektronix!reed!omen!caf - - - - - - - - - - - - - - - - 2 - - - - - 1. TOWER OF BABEL - - A "YMODEM Tower of Babel" has descended on the microcomputing community - bringing with it confusion, frustration, bloated phone bills, and wasted - man hours. Sadly, I (Chuck Forsberg) am partly to blame for this mess. - - As author of the early 1980s batch and 1k XMODEM extensions, I assumed - readers of earlier versions of this document would implement as much of - the YMODEM protocol as their programming skills and computing environments - would permit. This proved a rather naive assumption as programmers - motivated by competitive pressure implemented as little of YMODEM as - possible. Some have taken whatever parts of YMODEM that appealed to them, - applied them to MODEM7 Batch, Telink, XMODEM or whatever, and called the - result YMODEM. - - Jeff Garbers (Crosstalk package development director) said it all: "With - protocols in the public domain, anyone who wants to dink around with them - can go ahead." [1] - - Documents containing altered examples derived from YMODEM.DOC have added - to the confusion. In one instance, some self styled rewriter of history - altered the heading in YMODEM.DOC's Figure 1 from "1024 byte Packets" to - "YMODEM/CRC File Transfer Protocol". None of the XMODEM and YMODEM - examples shown in that document were correct. - - To put an end to this confusion, we must make "perfectly clear" what - YMODEM stands for, as Ward Christensen defined it in his 1985 coining of - the term. - - To the majority of you who read, understood, and respected Ward's - definition of YMODEM, I apologize for the inconvenience. - - 1.1 Definitions - - ARC ARC is a program that compresses one or more files into an archive - and extracts files from such archives. - - XMODEM refers to the file transfer etiquette introduced by Ward - Christensen's 1977 MODEM.ASM program. The name XMODEM comes from - Keith Petersen's XMODEM.ASM program, an adaptation of MODEM.ASM - for Remote CP/M (RCPM) systems. It's also called the MODEM or - MODEM2 protocol. Some who are unaware of MODEM7's unusual batch - file mode call it MODEM7. Other aliases include "CP/M Users' - Group" and "TERM II FTP 3". The name XMODEM caught on partly - because it is distinctive and partly because of media interest in - - - __________ - - 1. Page C/12, PC-WEEK July 12, 1987 - - - - - Chapter 1 - - - - - - - - X/YMODEM Protocol Reference June 18 1988 3 - - - - bulletin board and RCPM systems where it was accessed with an - "XMODEM" command. This protocol is supported by every serious - communications program because of its universality, simplicity, - and reasonable performance. - - XMODEM/CRC replaces XMODEM's 1 byte checksum with a two byte Cyclical - Redundancy Check (CRC-16), giving modern error detection - protection. - - XMODEM-1k Refers to the XMODEM/CRC protocol with 1024 byte data blocks. - - YMODEM Refers to the XMODEM/CRC (optional 1k blocks) protocol with batch - transmission as described below. In a nutshell, YMODEM means - BATCH. - - YMODEM-g Refers to the streaming YMODEM variation described below. - - True YMODEM(TM) In an attempt to sort out the YMODEM Tower of Babel, Omen - Technology has trademarked the term True YMODEM(TM) to represent - the complete YMODEM protocol described in this document, including - pathname, length, and modification date transmitted in block 0. - Please contact Omen Technology about certifying programs for True - YMODEM(TM) compliance. - - ZMODEM uses familiar XMODEM/CRC and YMODEM technology in a new protocol - that provides reliability, throughput, file management, and user - amenities appropriate to contemporary data communications. - - ZOO Like ARC, ZOO is a program that compresses one or more files into - a "zoo archive". ZOO supports many different operating systems - including Unix and VMS. - - - - - - - - - - - - - - - - - - - - - - - - Chapter 1 - - - - - - - - X/YMODEM Protocol Reference June 18 1988 4 - - - - 2. YMODEM MINIMUM REQUIREMENTS - - All programs claiming to support YMODEM must meet the following minimum - requirements: - - + The sending program shall send the pathname (file name) in block 0. - - + The pathname shall be a null terminated ASCII string as described - below. - - For those who are too lazy to read the entire document: - - + Unless specifically requested, only the file name portion is - sent. - - + No drive letter is sent. - - + Systems that do not distinguish between upper and lower case - letters in filenames shall send the pathname in lower case only. - - - + The receiving program shall use this pathname for the received file - name, unless explicitly overridden. - - + When the receiving program receives this block and successfully - opened the output file, it shall acknowledge this block with an ACK - character and then proceed with a normal XMODEM file transfer - beginning with a "C" or NAK tranmsitted by the receiver. - - + The sending program shall use CRC-16 in response to a "C" pathname - nak, otherwise use 8 bit checksum. - - + The receiving program must accept any mixture of 128 and 1024 byte - blocks within each file it receives. Sending programs may - arbitrarily switch between 1024 and 128 byte blocks. - - + The sending program must not change the length of an unacknowledged - block. - - + At the end of each file, the sending program shall send EOT up to ten - times until it receives an ACK character. (This is part of the - XMODEM spec.) - - + The end of a transfer session shall be signified by a null (empty) - pathname, this pathname block shall be acknowledged the same as other - pathname blocks. - - Programs not meeting all of these requirements are not YMODEM compatible, - and shall not be described as supporting YMODEM. - - Meeting these MINIMUM requirements does not guarantee reliable file - - - - Chapter 2 - - - - - - - - X/YMODEM Protocol Reference June 18 1988 5 - - - - transfers under stress. Particular attention is called to XMODEM's single - character supervisory messages that are easily corrupted by transmission - errors. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Chapter 2 - - - - - - - - X/YMODEM Protocol Reference June 18 1988 6 - - - - 3. WHY YMODEM? - - Since its development half a decade ago, the Ward Christensen modem - protocol has enabled a wide variety of computer systems to interchange - data. There is hardly a communications program that doesn't at least - claim to support this protocol. - - Advances in computing, modems and networking have revealed a number of - weaknesses in the original protocol: - - + The short block length caused throughput to suffer when used with - timesharing systems, packet switched networks, satellite circuits, - and buffered (error correcting) modems. - - + The 8 bit arithmetic checksum and other aspects allowed line - impairments to interfere with dependable, accurate transfers. - - + Only one file could be sent per command. The file name had to be - given twice, first to the sending program and then again to the - receiving program. - - + The transmitted file could accumulate as many as 127 extraneous - bytes. - - + The modification date of the file was lost. - - A number of other protocols have been developed over the years, but none - have displaced XMODEM to date: - - + Lack of public domain documentation and example programs have kept - proprietary protocols such as Blast, Relay, and others tightly bound - to the fortunes of their suppliers. - - + Complexity discourages the widespread application of BISYNC, SDLC, - HDLC, X.25, and X.PC protocols. - - + Performance compromises and complexity have limited the popularity of - the Kermit protocol, which was developed to allow file transfers in - environments hostile to XMODEM. - - The XMODEM protocol extensions and YMODEM Batch address some of these - weaknesses while maintaining most of XMODEM's simplicity. - - YMODEM is supported by the public domain programs YAM (CP/M), - YAM(CP/M-86), YAM(CCPM-86), IMP (CP/M), KMD (CP/M), rz/sz (Unix, Xenix, - VMS, Berkeley Unix, Venix, Xenix, Coherent, IDRIS, Regulus). Commercial - implementations include MIRROR, and Professional-YAM.[1] Communications - - - - - - - - Chapter 3 - - - - - - - - X/YMODEM Protocol Reference June 18 1988 7 - - - - programs supporting these extensions have been in use since 1981. - - The 1k block length (XMODEM-1k) described below may be used in conjunction - with YMODEM Batch Protocol, or with single file transfers identical to the - XMODEM/CRC protocol except for minimal changes to support 1k blocks. - - Another extension is the YMODEM-g protocol. YMODEM-g provides batch - transfers with maximum throughput when used with end to end error - correcting media, such as X.PC and error correcting modems, including 9600 - bps units by TeleBit, U.S.Robotics, Hayes, Electronic Vaults, Data Race, - and others. - - To complete this tome, edited versions of 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. In Australia, it is properly called the - Christensen Protocol. - - - 3.1 Some Messages from the Pioneer - - #: 130940 S0/Communications 25-Apr-85 18:38:47 - Sb: my protocol - Fm: Ward Christensen 76703,302 [2] - To: all - - Be aware the article[3] 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. Available for IBM PC,XT,AT, Unix and Xenix - - 2. Edited for typesetting appearance - - 3. Infoworld April 29 p. 16 - - - - - Chapter 3 - - - - - - - - X/YMODEM Protocol Reference June 18 1988 8 - - - - 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[4] 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 weird[5] - 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 - - - __________ - - 4. VAX/VMS versions of these programs are also available. - - 5. The file length, time, and file mode are optional. The pathname and - file length may be sent alone if desired. - - - - - Chapter 3 - - - - - - - - X/YMODEM Protocol Reference June 18 1988 9 - - - - 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 - "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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Chapter 3 - - - - - - - - X/YMODEM Protocol Reference June 18 1988 10 - - - - 4. XMODEM PROTOCOL ENHANCEMENTS - - This chapter discusses the protocol extensions to Ward Christensen's 1982 - XMODEM protocol description document. - - The original document recommends the user be asked whether to continue - trying or abort after 10 retries. Most programs no longer ask the - operator whether he wishes to keep retrying. 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. If the connection is that bad, it's better to - redial for a better connection, or mail a floppy disk. - - - 4.1 Graceful Abort - - The YAM and Professional-YAM X/YMODEM routines recognize a sequence of two - consecutive CAN (Hex 18) characters without modem errors (overrun, - framing, etc.) as a transfer abort command. This sequence is recognized - when is waiting for the beginning of a block or for an acknowledgement to - a block that has been sent. The check for two consecutive CAN characters - reduces the number of transfers aborted by line hits. YAM sends eight CAN - characters when it aborts an XMODEM, YMODEM, or ZMODEM protocol file - transfer. Pro-YAM then sends eight backspaces to delete the CAN - characters from the remote's keyboard input buffer, in case the remote had - already aborted the transfer and was awaiting a keyboarded command. - - - 4.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 block. 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 the MODEM7 series - programs. This remains the default because 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 - - - - Chapter 4 XMODEM Protocol Enhancements - - - - - - - - X/YMODEM Protocol Reference June 18 1988 11 - - - - both report a successful transmission. The protocol is robust in the - presence of characters lost by buffer overloading on timesharing systems. - - The single character ACK/NAK responses generated by the receiving program - adapt well to split speed modems, where the reverse channel is limited to - ten per cent or less of the main channel's speed. - - XMODEM and YMODEM are half duplex protocols which do not attempt to - transmit information and control signals in both directions at the same - time. This avoids buffer overrun problems that have been reported by - users attempting to exploit full duplex asynchronous file transfer - protocols such as Blast. - - Professional-YAM adds 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. - - - 4.3 XMODEM-1k 1024 Byte Block - - Disappointing throughput downloading from Unix with YMODEM[1] lead to the - development of 1024 byte blocks in 1982. 1024 byte blocks reduce the - effect of delays from timesharing systems, modems, and packet switched - networks on throughput by 87.5 per cent in addition to decreasing XMODEM's - 3 per cent overhead (block number, CRC, etc.). - - Some environments cannot accept 1024 byte bursts, including some networks - and minicomputer ports. The longer block length should be an option. - - The choice to use 1024 byte blocks is expressed to the sending program on - its command line or selection menu.[2] 1024 byte blocks improve throughput - in many applications. - - An STX (02) replaces the SOH (01) at the beginning of the transmitted - block to notify the receiver of the longer block length. The transmitted - block contains 1024 bytes of data. The receiver should be able to accept - any mixture of 128 and 1024 byte blocks. The block number (in the second - and third bytes of the block) is incremented by one for each block - regardless of the block length. - - The sender must not change between 128 and 1024 byte block lengths if it - has not received a valid ACK for the current block. Failure to observe - - - __________ - - 1. The name hadn't been coined yet, but the protocol was the same. - - 2. See "KMD/IMP Exceptions to YMODEM" below. - - - - - Chapter 4 XMODEM Protocol Enhancements - - - - - - - - X/YMODEM Protocol Reference June 18 1988 12 - - - - this restriction allows transmission errors to pass undetected. - - If 1024 byte blocks are being used, it is possible for a file to "grow" up - to the next multiple of 1024 bytes. This does not waste disk space if the - allocation granularity is 1k or greater. With YMODEM batch transmission, - the optional file length transmitted in the file name block allows the - receiver to discard the padding, preserving the exact file length and - contents. - - 1024 byte blocks may be used with batch file transmission or with single - file transmission. CRC-16 should be used with the k option to preserve - data integrity over phone lines. If a program wishes to enforce this - recommendation, it should cancel the transfer, then issue an informative - diagnostic message if the receiver requests checksum instead of CRC-16. - - Under no circumstances may a sending program use CRC-16 unless the - receiver commands CRC-16. - - Figure 1. XMODEM-1k Blocks - - SENDER RECEIVER - "sx -k foo.bar" - "foo.bar open x.x minutes" - C - STX 01 FE Data[1024] CRC CRC - ACK - STX 02 FD Data[1024] CRC CRC - ACK - STX 03 FC Data[1000] CPMEOF[24] CRC CRC - ACK - EOT - ACK - - Figure 2. Mixed 1024 and 128 byte Blocks - - SENDER RECEIVER - "sx -k foo.bar" - "foo.bar open x.x minutes" - C - STX 01 FE Data[1024] CRC CRC - ACK - STX 02 FD Data[1024] CRC CRC - ACK - SOH 03 FC Data[128] CRC CRC - ACK - SOH 04 FB Data[100] CPMEOF[28] CRC CRC - ACK - EOT - ACK - - - - - - Chapter 4 XMODEM Protocol Enhancements - - - - - - - - X/YMODEM Protocol Reference June 18 1988 13 - - - - 5. YMODEM Batch File Transmission - - The YMODEM Batch protocol is an extension to the XMODEM/CRC protocol that - allows 0 or more files to be transmitted with a single command. (Zero - files may be sent if none of the requested files is accessible.) The - design approach of the YMODEM Batch protocol is to use the normal routines - for sending and receiving XMODEM blocks in a layered fashion similar to - packet switching methods. - - Why was it necessary to design a new batch protocol when one already - existed in MODEM7?[1] The batch file mode used by MODEM7 is unsuitable - because it does not permit full pathnames, file length, file date, or - other attribute information to be transmitted. Such a restrictive design, - hastily implemented with only CP/M in mind, would not have permitted - extensions to current areas of personal computing such as Unix, DOS, and - object oriented systems. In addition, the MODEM7 batch file mode is - somewhat susceptible to transmission impairments. - - As in the case of single a file transfer, the receiver initiates batch - file transmission by sending a "C" character (for CRC-16). - - The sender opens the first file and sends block number 0 with the - following information.[2] - - Only the pathname (file name) part is required for batch transfers. - - To maintain upwards compatibility, all unused bytes in block 0 must be set - to null. - - Pathname The pathname (conventionally, the file name) is sent as a null - terminated ASCII string. This is the filename format used by the - handle oriented MSDOS(TM) functions and C library fopen functions. - An assembly language example follows: - DB 'foo.bar',0 - No spaces are included in the pathname. Normally only the file name - stem (no directory prefix) is transmitted unless the sender has - selected YAM's f option to send the full pathname. The source drive - (A:, B:, etc.) is not sent. - - Filename Considerations: - - - - __________ - - 1. The MODEM7 batch protocol transmitted CP/M FCB bytes f1...f8 and - t1...t3 one character at a time. The receiver echoed these bytes as - received, one at a time. - - 2. Only the data part of the block is described here. - - - - - Chapter 5 XMODEM Protocol Enhancements - - - - - - - - X/YMODEM Protocol Reference June 18 1988 14 - - - - + File names are forced to lower case unless the sending system - supports upper/lower case file names. This is a convenience for - users of systems (such as Unix) which store filenames in upper - and lower case. - - + The receiver should accommodate file names in lower and upper - case. - - + When transmitting files between different operating systems, - file names must be acceptable to both the sender and receiving - operating systems. - - If directories are included, they are delimited by /; i.e., - "subdir/foo" is acceptable, "subdir\foo" is not. - - Length The file length and each of the succeeding fields are optional.[3] - The length field is stored in the block as a decimal string counting - the number of data bytes in the file. The file length does not - include any CPMEOF (^Z) or other garbage characters used to pad the - last block. - - If the file being transmitted is growing during transmission, the - length field should be set to at least the final expected file - length, or not sent. - - The receiver stores the specified number of characters, discarding - any padding added by the sender to fill up the last block. - - Modification Date The mod date is optional, and the filename and length - may be sent without requiring the mod date to be sent. - - Iff the modification date is sent, a single space separates the - modification date from the file length. - - The mod date is sent as an octal number giving the time the contents - of the file were last changed, measured in seconds from Jan 1 1970 - Universal Coordinated Time (GMT). A date of 0 implies the - modification date is unknown and should be left as the date the file - is received. - - This standard format was chosen to eliminate ambiguities arising from - transfers between different time zones. - - - - - - __________ - - 3. Fields may not be skipped. - - - - - Chapter 5 XMODEM Protocol Enhancements - - - - - - - - X/YMODEM Protocol Reference June 18 1988 15 - - - - Mode Iff the file mode is sent, a single space separates the file mode - from the modification date. The file mode is stored as an octal - string. Unless the file originated from a Unix system, the file mode - is set to 0. rb(1) checks the file mode for the 0x8000 bit which - indicates a Unix type regular file. Files with the 0x8000 bit set - are assumed to have been sent from another Unix (or similar) system - which uses the same file conventions. Such files are not translated - in any way. - - - Serial Number Iff the serial number is sent, a single space separates the - serial number from the file mode. The serial number of the - transmitting program is stored as an octal string. Programs which do - not have a serial number should omit this field, or set it to 0. The - receiver's use of this field is optional. - - - Other Fields YMODEM was designed to allow additional header fields to be - added as above without creating compatibility problems with older - YMODEM programs. Please contact Omen Technology if other fields are - needed for special application requirements. - - The rest of the block is set to nulls. This is essential to preserve - upward compatibility.[4] - - If the filename block is received with a CRC or other error, a - retransmission is requested. After the filename block has been received, - it is ACK'ed if the write open is successful. If the file cannot be - opened for writing, the receiver cancels the transfer with CAN characters - as described above. - - The receiver then initiates transfer of the file contents with a "C" - character, according to the standard XMODEM/CRC protocol. - - After the file contents and XMODEM EOT have been transmitted and - acknowledged, the receiver again asks for the next pathname. - - Transmission of a null pathname terminates batch file transmission. - - Note that transmission of no files is not necessarily an error. This is - possible if none of the files requested of the sender could be opened for - reading. - - - - __________ - - 4. If, perchance, this information extends beyond 128 bytes (possible - with Unix 4.2 BSD extended file names), the block should be sent as a - 1k block as described above. - - - - - Chapter 5 XMODEM Protocol Enhancements - - - - - - - - X/YMODEM Protocol Reference June 18 1988 16 - - - - Most YMODEM receivers request CRC-16 by default. - - The Unix programs sz(1) and rz(1) included in the source code file - RZSZ.ZOO should answer other questions about YMODEM batch protocol. - - Figure 3. YMODEM Batch Transmission Session (1 file) - - SENDER RECEIVER - "sb foo.*<CR>" - "sending in batch mode etc." - C (command:rb) - SOH 00 FF foo.c NUL[123] CRC CRC - ACK - C - SOH 01 FE Data[128] CRC CRC - ACK - SOH 02 FC Data[128] CRC CRC - ACK - SOH 03 FB Data[100] CPMEOF[28] CRC CRC - ACK - EOT - NAK - EOT - ACK - C - SOH 00 FF NUL[128] CRC CRC - ACK - - Figure 7. YMODEM Header Information and Features - - _____________________________________________________________ - | Program | Length | Date | Mode | S/N | 1k-Blk | YMODEM-g | - |___________|________|______|______|_____|________|__________| - |Unix rz/sz | yes | yes | yes | no | yes | sb only | - |___________|________|______|______|_____|________|__________| - |VMS rb/sb | yes | no | no | no | yes | no | - |___________|________|______|______|_____|________|__________| - |Pro-YAM | yes | yes | no | yes | yes | yes | - |___________|________|______|______|_____|________|__________| - |CP/M YAM | no | no | no | no | yes | no | - |___________|________|______|______|_____|________|__________| - |KMD/IMP | ? | no | no | no | yes | no | - |___________|________|______|______|_____|________|__________| - - 5.1 KMD/IMP Exceptions to YMODEM - - KMD and IMP use a "CK" character sequence emitted by the receiver to - trigger the use of 1024 byte blocks as an alternative to specifying this - option to the sending program. This two character sequence generally - works well on single process micros in direct communication, provided the - programs rigorously adhere to all the XMODEM recommendations included - - - - Chapter 5 XMODEM Protocol Enhancements - - - - - - - - X/YMODEM Protocol Reference June 18 1988 17 - - - - Figure 4. YMODEM Batch Transmission Session (2 files) - - SENDER RECEIVER - "sb foo.c baz.c<CR>" - "sending in batch mode etc." - C (command:rb) - SOH 00 FF foo.c NUL[123] CRC CRC - ACK - C - SOH 01 FE Data[128] CRC CRC - ACK - SOH 02 FC Data[128] CRC CRC - ACK - SOH 03 FB Data[100] CPMEOF[28] CRC CRC - ACK - EOT - NAK - EOT - ACK - C - SOH 00 FF baz.c NUL[123] CRC CRC - ACK - C - SOH 01 FB Data[100] CPMEOF[28] CRC CRC - ACK - EOT - NAK - EOT - ACK - C - SOH 00 FF NUL[128] CRC CRC - ACK - - Figure 5. YMODEM Batch Transmission Session-1k Blocks - - SENDER RECEIVER - "sb -k foo.*<CR>" - "sending in batch mode etc." - C (command:rb) - SOH 00 FF foo.c NUL[123] CRC CRC - ACK - C - STX 01 FD Data[1024] CRC CRC - ACK - SOH 02 FC Data[128] CRC CRC - ACK - SOH 03 FB Data[100] CPMEOF[28] CRC CRC - ACK - EOT - NAK - EOT - - - - Chapter 5 XMODEM Protocol Enhancements - - - - - - - - X/YMODEM Protocol Reference June 18 1988 18 - - - - ACK - C - SOH 00 FF NUL[128] CRC CRC - ACK - - Figure 6. YMODEM Filename block transmitted by sz - - -rw-r--r-- 6347 Jun 17 1984 20:34 bbcsched.txt - - 00 0100FF62 62637363 6865642E 74787400 |...bbcsched.txt.| - 10 36333437 20333331 34373432 35313320 |6347 3314742513 | - 20 31303036 34340000 00000000 00000000 |100644..........| - 30 00000000 00000000 00000000 00000000 - 40 00000000 00000000 00000000 00000000 - 50 00000000 00000000 00000000 00000000 - 60 00000000 00000000 00000000 00000000 - 70 00000000 00000000 00000000 00000000 - 80 000000CA 56 - - herein. Programs with marginal XMODEM implementations do not fare so - well. Timesharing systems and packet switched networks can separate the - successive characters, rendering this method unreliable. - - Sending programs may detect the CK sequence if the operating enviornment - does not preclude reliable implementation. - - Instead of the standard YMODEM file length in decimal, KMD and IMP - transmit the CP/M record count in the last two bytes of the header block. - - - 6. YMODEM-g File Transmission - - Developing technology is providing phone line data transmission at ever - higher speeds using very specialized techniques. These high speed modems, - as well as session protocols such as X.PC, provide high speed, nearly - error free communications at the expense of considerably increased delay - time. - - This delay time is moderate compared to human interactions, but it - cripples the throughput of most error correcting protocols. - - The g option to YMODEM has proven effective under these circumstances. - The g option is driven by the receiver, which initiates the batch transfer - by transmitting a G instead of C. When the sender recognizes the G, it - bypasses the usual wait for an ACK to each transmitted block, sending - succeeding blocks at full speed, subject to XOFF/XON or other flow control - exerted by the medium. - - The sender expects an inital G to initiate the transmission of a - particular file, and also expects an ACK on the EOT sent at the end of - each file. This synchronization allows the receiver time to open and - - - - Chapter 6 XMODEM Protocol Enhancements - - - - - - - - X/YMODEM Protocol Reference June 18 1988 19 - - - - close files as necessary. - - If an error is detected in a YMODEM-g transfer, the receiver aborts the - transfer with the multiple CAN abort sequence. The ZMODEM protocol should - be used in applications that require both streaming throughput and error - recovery. - - Figure 8. YMODEM-g Transmission Session - - SENDER RECEIVER - "sb foo.*<CR>" - "sending in batch mode etc..." - G (command:rb -g) - SOH 00 FF foo.c NUL[123] CRC CRC - G - SOH 01 FE Data[128] CRC CRC - STX 02 FD Data[1024] CRC CRC - SOH 03 FC Data[128] CRC CRC - SOH 04 FB Data[100] CPMEOF[28] CRC CRC - EOT - ACK - G - SOH 00 FF NUL[128] CRC CRC - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Chapter 6 XMODEM Protocol Enhancements - - - - - - - - X/YMODEM Protocol Reference June 18 1988 20 - - - - 7. XMODEM PROTOCOL OVERVIEW - - 8/9/82 by Ward Christensen. - - I will maintain a master copy of this. Please pass on changes or - suggestions via CBBS/Chicago at (312) 545-8086, CBBS/CPMUG (312) 849-1132 - or by voice at (312) 849-6279. - - 7.1 Definitions - - <soh> 01H - <eot> 04H - <ack> 06H - <nak> 15H - <can> 18H - <C> 43H - - - 7.2 Transmission Medium Level Protocol - - Asynchronous, 8 data bits, no parity, one stop bit. - - The protocol imposes no restrictions on the contents of the data being - transmitted. No control characters are looked for in the 128-byte data - messages. Absolutely any kind of data may be sent - binary, ASCII, etc. - The protocol has not formally been adopted to a 7-bit environment for the - transmission of ASCII-only (or unpacked-hex) data , although it could be - simply by having both ends agree to AND the protocol-dependent data with - 7F hex before validating it. I specifically am referring to the checksum, - and the block numbers and their ones- complement. - - Those wishing to maintain compatibility of the CP/M file structure, i.e. - to allow modemming ASCII files to or from CP/M systems 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. - - - - - - Chapter 7 Xmodem Protocol Overview - - - - - - - - X/YMODEM Protocol Reference June 18 1988 21 - - - - + The last block sent is no different from others, i.e. there is no - "short block". - Figure 9. XMODEM 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. - - 7.3 File Level Protocol - - 7.3.1 Common_to_Both_Sender_and_Receiver - All errors are retried 10 times. For versions running with an operator - (i.e. NOT with XMODEM), a message is typed after 10 errors asking the - operator whether to "retry or quit". - - Some versions of the protocol use <can>, ASCII ^X, to cancel transmission. - This was never adopted as a standard, as having a single "abort" character - makes the transmission susceptible to false termination due to an <ack> - <nak> or <soh> being corrupted into a <can> and aborting transmission. - - The protocol may be considered "receiver driven", that is, the sender need - not automatically re-transmit, although it does in the current - implementations. - - - 7.3.2 Receive_Program_Considerations - The receiver has a 10-second timeout. It sends a <nak> every time it - times out. The receiver's first timeout, which sends a <nak>, signals the - transmitter to start. Optionally, the receiver could send a <nak> - immediately, in case the sender was ready. This would save the initial 10 - second timeout. However, the receiver MUST continue to timeout every 10 - seconds in case the sender wasn't ready. - - Once into a receiving a block, the receiver goes into a one-second timeout - for each character and the checksum. If the receiver wishes to <nak> a - block for any reason (invalid header, timeout receiving data), it must - wait for the line to clear. See "programming tips" for ideas - - Synchronizing: If a valid block number is received, it will be: 1) the - expected one, in which case everything is fine; or 2) a repeat of the - previously received block. This should be considered OK, and only - indicates that the receivers <ack> got glitched, and the sender re- - transmitted; 3) any other block number indicates a fatal loss of - synchronization, such as the rare case of the sender getting a line-glitch - - - - Chapter 7 Xmodem Protocol Overview - - - - - - - - X/YMODEM Protocol Reference June 18 1988 22 - - - - that looked like an <ack>. Abort the transmission, sending a <can> - - - 7.3.3 Sending_program_considerations - While waiting for transmission to begin, the sender has only a single very - long timeout, say one minute. In the current protocol, the sender has a - 10 second timeout before retrying. I suggest NOT doing this, and letting - the protocol be completely receiver-driven. This will be compatible with - existing programs. - - When the sender has no more data, it sends an <eot>, and awaits an <ack>, - resending the <eot> if it doesn't get one. Again, the protocol could be - receiver-driven, with the sender only having the high-level 1-minute - timeout to abort. - - - Here 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 the checksum byte. - - Figure 10. Data flow including Error Recovery - - 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> ---> - <--- <anything except ack> - <eot> ---> - <--- <ack> - (finished) - - 7.4 Programming Tips - - + The character-receive subroutine should be called with a parameter - specifying the number of seconds to wait. The receiver should first - call it with a time of 10, then <nak> and try again, 10 times. - - After receiving the <soh>, the receiver should call the character - receive subroutine with a 1-second timeout, for the remainder of the - message and the <cksum>. Since they are sent as a continuous stream, - timing out of this implies a serious like glitch that caused, say, - 127 characters to be seen instead of 128. - - - - Chapter 7 Xmodem Protocol Overview - - - - - - - - X/YMODEM Protocol Reference June 18 1988 23 - - - - + When the receiver wishes to <nak>, it should call a "PURGE" - subroutine, to wait for the line to clear. Recall the sender tosses - any characters in its UART buffer immediately upon completing sending - a block, to ensure no glitches were mis- interpreted. - - The most common technique is for "PURGE" to call the character - receive subroutine, specifying a 1-second timeout,[1] and looping - back to PURGE until a timeout occurs. The <nak> is then sent, - ensuring the other end will see it. - - + You may wish to add code recommended by John Mahr to your character - receive routine - to set an error flag if the UART shows framing - error, or overrun. This will help catch a few more glitches - the - most common of which is a hit in the high bits of the byte in two - consecutive bytes. The <cksum> comes out OK since counting in 1-byte - produces the same result of adding 80H + 80H as with adding 00H + - 00H. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - __________ - - 1. These times should be adjusted for use with timesharing systems. - - - - - Chapter 7 Xmodem Protocol Overview - - - - - - - - X/YMODEM Protocol Reference June 18 1988 24 - - - - 8. XMODEM/CRC Overview - - Original 1/13/85 by John Byrns -- CRC option. - - Please pass on any reports of errors in this document or suggestions for - improvement to me via Ward's/CBBS at (312) 849-1132, or by voice at (312) - 885-1105. - - The CRC used in the Modem Protocol is an alternate form of block check - which provides more robust error detection than the original checksum. - Andrew S. Tanenbaum says in his book, Computer Networks, that the CRC- - CCITT used by the Modem Protocol will detect all single and double bit - errors, all errors with an odd number of bits, all burst errors of length - 16 or less, 99.997% of 17-bit error bursts, and 99.998% of 18-bit and - longer bursts.[1] - - The changes to the Modem Protocol to replace the checksum with the CRC are - straight forward. If that were all that we did we would not be able to - communicate between a program using the old checksum protocol and one - using the new CRC protocol. An initial handshake was added to solve this - problem. The handshake allows a receiving program with CRC capability to - determine whether the sending program supports the CRC option, and to - switch it to CRC mode if it does. This handshake is designed so that it - will work properly with programs which implement only the original - protocol. A description of this handshake is presented in section 10. - - Figure 11. Message Block Level Protocol, CRC mode - - Each block of the transfer in CRC mode looks like: - <SOH><blk #><255-blk #><--128 data bytes--><CRC hi><CRC lo> - in which: - <SOH> = 01 hex - <blk #> = binary number, starts at 01 increments by 1, and - wraps 0FFH to 00H (not to 01) - <255-blk #> = ones complement of blk #. - <CRC hi> = byte containing the 8 hi order coefficients of the CRC. - <CRC lo> = byte containing the 8 lo order coefficients of the CRC. - - 8.1 CRC Calculation - - 8.1.1 Formal_Definition - To calculate the 16 bit CRC the message bits are considered to be the - coefficients of a polynomial. This message polynomial is first multiplied - by X^16 and then divided by the generator polynomial (X^16 + X^12 + X^5 + - - - __________ - - 1. This reliability figure is misleading because XMODEM's critical - supervisory functions are not protected by this CRC. - - - - - Chapter 8 Xmodem Protocol Overview - - - - - - - - X/YMODEM Protocol Reference June 18 1988 25 - - - - 1) using modulo two arithmetic. The remainder left after the division is - the desired CRC. Since a message block in the Modem Protocol is 128 bytes - or 1024 bits, the message polynomial will be of order X^1023. The hi order - bit of the first byte of the message block is the coefficient of X^1023 in - the message polynomial. The lo order bit of the last byte of the message - block is the coefficient of X^0 in the message polynomial. - - Figure 12. Example of CRC Calculation written in C - - The following XMODEM crc routine is taken from "rbsb.c". Please refer to - the source code for these programs (contained in RZSZ.ZOO) for usage. A - fast table driven version is also included in this file. - - /* update CRC */ - unsigned short - updcrc(c, crc) - register c; - register unsigned crc; - { - register count; - - for (count=8; --count>=0;) { - if (crc & 0x8000) { - crc <<= 1; - crc += (((c<<=1) & 0400) != 0); - crc ^= 0x1021; - } - else { - crc <<= 1; - crc += (((c<<=1) & 0400) != 0); - } - } - return crc; - } - - 8.2 CRC File Level Protocol Changes - - 8.2.1 Common_to_Both_Sender_and_Receiver - The only change to the File Level Protocol for the CRC option is the - initial handshake which is used to determine if both the sending and the - receiving programs support the CRC mode. All Modem Programs should support - the checksum mode for compatibility with older versions. A receiving - program that wishes to receive in CRC mode implements the mode setting - handshake by sending a <C> in place of the initial <nak>. If the sending - program supports CRC mode it will recognize the <C> and will set itself - into CRC mode, and respond by sending the first block as if a <nak> had - been received. If the sending program does not support CRC mode it will - not respond to the <C> at all. After the receiver has sent the <C> it will - wait up to 3 seconds for the <soh> that starts the first block. If it - receives a <soh> within 3 seconds it will assume the sender supports CRC - mode and will proceed with the file exchange in CRC mode. If no <soh> is - - - - Chapter 8 Xmodem Protocol Overview - - - - - - - - X/YMODEM Protocol Reference June 18 1988 26 - - - - received within 3 seconds the receiver will switch to checksum mode, send - a <nak>, and proceed in checksum mode. If the receiver wishes to use - checksum mode it should send an initial <nak> and the sending program - should respond to the <nak> as defined in the original Modem Protocol. - After the mode has been set by the initial <C> or <nak> the protocol - follows the original Modem Protocol and is identical whether the checksum - or CRC is being used. - - - 8.2.2 Receive_Program_Considerations - There are at least 4 things that can go wrong with the mode setting - handshake. - - 1. the initial <C> can be garbled or lost. - - 2. the initial <soh> can be garbled. - - 3. the initial <C> can be changed to a <nak>. - - 4. the initial <nak> from a receiver which wants to receive in checksum - can be changed to a <C>. - - The first problem can be solved if the receiver sends a second <C> after - it times out the first time. This process can be repeated several times. - It must not be repeated too many times before sending a <nak> and - switching to checksum mode or a sending program without CRC support may - time out and abort. Repeating the <C> will also fix the second problem if - the sending program cooperates by responding as if a <nak> were received - instead of ignoring the extra <C>. - - It is possible to fix problems 3 and 4 but probably not worth the trouble - since they will occur very infrequently. They could be fixed by switching - modes in either the sending or the receiving program after a large number - of successive <nak>s. This solution would risk other problems however. - - - 8.2.3 Sending_Program_Considerations - The sending program should start in the checksum mode. This will insure - compatibility with checksum only receiving programs. Anytime a <C> is - received before the first <nak> or <ack> the sending program should set - itself into CRC mode and respond as if a <nak> were received. The sender - should respond to additional <C>s as if they were <nak>s until the first - <ack> is received. This will assist the receiving program in determining - the correct mode when the <soh> is lost or garbled. After the first <ack> - is received the sending program should ignore <C>s. - - - - - - - - - - Chapter 8 Xmodem Protocol Overview - - - - - - - - X/YMODEM Protocol Reference June 18 1988 27 - - - - 8.3 Data Flow Examples with CRC Option - - Here is a data flow example for the case where the receiver requests - transmission in the CRC mode but the sender does not support the CRC - option. This example also includes various transmission errors. <xx> - represents the checksum byte. - - Figure 13. Data Flow: Receiver has CRC Option, Sender Doesn't - - SENDER RECEIVER - <--- <C> - times out after 3 seconds, - <--- <C> - times out after 3 seconds, - <--- <C> - times out after 3 seconds, - <--- <C> - times out after 3 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> - times out after 10 seconds, - <--- <nak> - <soh> 03 FC -data- <xx> ---> - <--- <ack> - <eot> ---> - <--- <ack> - - Here is a data flow example for the case where the receiver requests - transmission in the CRC mode and the sender supports the CRC option. This - example also includes various transmission errors. <xxxx> represents the - 2 CRC bytes. - - - - - - - - - - - - - - - - - Chapter 8 Xmodem Protocol Overview - - - - - - - - X/YMODEM Protocol Reference June 18 1988 28 - - - - Figure 14. Receiver and Sender Both have CRC Option - - SENDER RECEIVER - <--- <C> - <soh> 01 FE -data- <xxxx> ---> - <--- <ack> - <soh> 02 FD -data- <xxxx> ---> (data gets line hit) - <--- <nak> - <soh> 02 FD -data- <xxxx> ---> - <--- <ack> - <soh> 03 FC -data- <xxxx> ---> - (ack gets garbaged) <--- <ack> - times out after 10 seconds, - <--- <nak> - <soh> 03 FC -data- <xxxx> ---> - <--- <ack> - <eot> ---> - <--- <ack> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Chapter 8 Xmodem Protocol Overview - - - - - - - - X/YMODEM Protocol Reference June 18 1988 29 - - - - 9. MORE INFORMATION - - Please contact Omen Technology for troff source files and typeset copies - of this document. - - - 9.1 TeleGodzilla Bulletin Board - - More information may be obtained by calling TeleGodzilla at 503-621-3746. - Speed detection is automatic for 1200, 2400 and 19200(Telebit PEP) bps. - TrailBlazer modem users may issue the TeleGodzilla trailblazer command to - swith to 19200 bps once they have logged in. - - Interesting files include RZSZ.ZOO (C source code), YZMODEM.ZOO (Official - XMODEM, YMODEM, and ZMODEM protocol descriptions), ZCOMMEXE.ARC, - ZCOMMDOC.ARC, and ZCOMMHLP.ARC (PC-DOS shareware comm program with XMODEM, - True YMODEM(TM), ZMODEM, Kermit Sliding Windows, Telink, MODEM7 Batch, - script language, etc.). - - - 9.2 Unix UUCP Access - - UUCP sites can obtain the current version of this file with - uucp omen!/u/caf/public/ymodem.doc /tmp - A continually updated list of available files is stored in - /usr/spool/uucppublic/FILES. When retrieving these files with uucp, - remember that the destination directory on your system must be writeable - by anyone, or the UUCP transfer will fail. - - The following L.sys line calls TeleGodzilla (Pro-YAM in host operation). - TeleGodzilla determines the incoming speed automatically. - - In response to "Name Please:" uucico gives the Pro-YAM "link" command as a - user name. The password (Giznoid) controls access to the Xenix system - connected to the IBM PC's other serial port. Communications between - Pro-YAM and Xenix use 9600 bps; YAM converts this to the caller's speed. - - Finally, the calling uucico logs in as uucp. - - omen Any ACU 2400 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp - - - - 10. REVISIONS - - 6-18-88 Further revised for clarity. Corrected block numbering in two - examples. - 10-27-87 Optional fields added for number of files remaining to be sent - and total number of bytes remaining to be sent. - 10-18-87 Flow control discussion added to 1024 byte block descritpion, - minor revisions for clarity per user comments. - - - - Chapter 10 Xmodem Protocol Overview - - - - - - - - X/YMODEM Protocol Reference June 18 1988 30 - - - - 8-03-87 Revised for clarity. - 5-31-1987 emphasizes minimum requirements for YMODEM, and updates - information on accessing files. - 9-11-1986 clarifies nomenclature and some minor points. - The April 15 1986 edition clarifies some points concerning CRC - calculations and spaces in the header. - - - 11. YMODEM Programs - - ZCOMM, A shareware little brother to Professional-YAM, is available as - ZCOMMEXE.ARC on TeleGodzilla and other bulletin board systems. ZCOMM may - be used to test YMODEM amd ZMODEM implementations. - - Unix programs supporting YMODEM are available on TeleGodzilla in RZSZ.ZOO. - This ZOO archive includes a ZCOMM/Pro-YAM/PowerCom script ZUPL.T to upload - a bootstrap program MINIRB.C, compile it, and then upload the rest of the - files using the compiled MINIRB. Most Unix like systems are supported, - including V7, Xenix, Sys III, 4.2 BSD, SYS V, Idris, Coherent, and - Regulus. - - A version for VAX-VMS is available in VRBSB.SHQ. - - Irv Hoff has added 1k blocks and basic YMODEM batch transfers to the KMD - and IMP series programs, which replace the XMODEM and MODEM7/MDM7xx series - respectively. Overlays are available for a wide variety of CP/M systems. - - Questions about Professional-YAM communications software may be directed - to: - Chuck Forsberg - Omen Technology Inc - 17505-V Sauvie Island Road - Portland Oregon 97231 - VOICE: 503-621-3406 :VOICE - Modem: 503-621-3746 Speed: 19200(Telebit PEP),2400,1200,300 - Usenet: ...!tektronix!reed!omen!caf - CompuServe: 70007,2304 - GEnie: CAF - - Unlike ZMODEM and Kermit, XMODEM and YMODEM place obstacles in the path of - a reliable high performance implementation, evidenced by poor reliability - under stress of the industry leaders' XMODEM and YMODEM programs. Omen - Technology provides consulting and other services to those wishing to - implement XMODEM, YMODEM, and ZMODEM with state of the art features and - reliability. - - - - - - - - - - Chapter 11 Xmodem Protocol Overview - - - - - - - - - - - - CONTENTS - - - 1. TOWER OF BABEL................................................... 2 - 1.1 Definitions................................................. 2 - - 2. YMODEM MINIMUM REQUIREMENTS...................................... 4 - - 3. WHY YMODEM?...................................................... 6 - 3.1 Some Messages from the Pioneer.............................. 7 - - 4. XMODEM PROTOCOL ENHANCEMENTS..................................... 10 - 4.1 Graceful Abort.............................................. 10 - 4.2 CRC-16 Option............................................... 10 - 4.3 XMODEM-1k 1024 Byte Block................................... 11 - - 5. YMODEM Batch File Transmission................................... 13 - 5.1 KMD/IMP Exceptions to YMODEM................................ 16 - - 6. YMODEM-g File Transmission....................................... 18 - - 7. XMODEM PROTOCOL OVERVIEW......................................... 20 - 7.1 Definitions................................................. 20 - 7.2 Transmission Medium Level Protocol.......................... 20 - 7.3 File Level Protocol......................................... 21 - 7.4 Programming Tips............................................ 22 - - 8. XMODEM/CRC Overview.............................................. 24 - 8.1 CRC Calculation............................................. 24 - 8.2 CRC File Level Protocol Changes............................. 25 - 8.3 Data Flow Examples with CRC Option.......................... 27 - - 9. MORE INFORMATION................................................. 29 - 9.1 TeleGodzilla Bulletin Board................................. 29 - 9.2 Unix UUCP Access............................................ 29 - - 10. REVISIONS........................................................ 29 - - 11. YMODEM Programs.................................................. 30 - - - - - - - - - - - - - - - - - i - - - - - - - - - - - - - - - - LIST OF FIGURES - - - Figure 1. XMODEM-1k Blocks.......................................... 12 - - Figure 2. Mixed 1024 and 128 byte Blocks............................ 12 - - Figure 3. YMODEM Batch Transmission Session (1 file)................ 16 - - Figure 4. YMODEM Batch Transmission Session (2 files)............... 16 - - Figure 5. YMODEM Batch Transmission Session-1k Blocks............... 16 - - Figure 6. YMODEM Filename block transmitted by sz................... 16 - - Figure 7. YMODEM Header Information and Features.................... 16 - - Figure 8. YMODEM-g Transmission Session............................. 19 - - Figure 9. XMODEM Message Block Level Protocol....................... 21 - - Figure 10. Data flow including Error Recovery........................ 22 - - Figure 11. Message Block Level Protocol, CRC mode.................... 24 - - Figure 12. Example of CRC Calculation written in C................... 25 - - Figure 13. Data Flow: Receiver has CRC Option, Sender Doesn't........ 27 - - Figure 14. Receiver and Sender Both have CRC Option.................. 28 - - - - - - - - - - - - - - - - - - - - - - - ii - |