Although perhap this is more than requested, while reading your request for information and help, I was working on a collection of 'The Best of 816 Central' from all of those issues - found the following and thought it might be useful. Hope somebody will find it of some value. Cheers, Tom ---------------------SEE BELOW: * XMODEM.INFO: Hard to find information on the details of the XMODEM protocol. Includes info on ProDOS extensions and variants (1K and 4K packets, etc.). ProDOS Extension to Xmodem and Xmodem-CRC For Apple II(R) computers Documented by Jim Ferr, September 9, 1990 Table of Contents 1. Introduction 2. ProDOS Extension to Xmodem 3. CRC and Checksum Calculation Source Code 1. Introduction The Xmodem protocol is a public domain file transfer protocol developed by Ward Christensen in August 1977. Because of its flexibility, Xmodem has become the standard file transfer protocol for micro to micro and micro to mainframe telecommunications. Since its initial release, many improvements and "extensions" have been added, among them: Extension/Option Existing Documentation by The 16-bit CRC option Chuck Forsberg ASCII Express Pro(tm) ProDOS Extension Bill Blue or this document Binary II Extension Apple Computer, Inc. MacBinary Extension Apple Computer, Inc. 1K block size option Chuck Forsberg 4K block size option Morgan Davis Ymodem Batch Protocol Chuck Forsberg Zmodem Streaming Batch Protocol Chuck Forsberg Apple II application programmers can support all of these extensions and options if desired. The purpose of this document is to describe the ASCII Express Pro(tm) ProDOS extension to Xmodem, which applies to standard (checksum) Xmodem and CRC Xmodem with 128 byte packets. Why I am writing this? I found that existing documentation was incomplete or contained inaccuracies, or simply wasn't available online anymore. In addition, I feel it is very sad to see new Apple II applications which support Xmodem but do not support the ProDOS Extension originally used by ASCII Express Pro(tm) and later emulated by so many others. Backward compatibility is such an important feature, yet many Apple II developers pretend that systems prior to the IIe Enhanced don't even exist. It is for those who DON'T feel that way that I have written this document. Finally, it took a great deal of time and connect time (ie. money) to gather all of this information. I have included my source code for CRC and Checksum calculation. You can include it in your own programs -- the CRC code was derived from code in the public domain which I downloaded from CompuServe a few years ago. I hate to see people waste a lot of time and money, and I trust others feel the same way about public domain information as valuable as file transfer protocols. Without further ado, then... 2. ProDOS Extension Definitions: ACK = $06 NAK = $15 EOT = $04 SYN = $16 ETB = $17 The ProDOS Extension to Xmodem includes a special startup packet and an additional information packet at the end of the transfer. The special startup packet isn't really a packet, as it is only three characters long: 81 00 FF (SOH+$80, 00 if ProDOS / File type if DOS 3.3, 2nd byte EOR #$FF) When prompted to begin the transfer by the receiver's NAK or C, the sender sends the special startup packet up to three times. If an ACK is not received, the sender flags the transfer as non-ProDOS and does not send the special final packet. If an ACK is received in response to the special startup packet, the transfer is conducted normally until the EOT is sent by the Sender. At that point, the following handshaking occurs: Sender Receiver EOT ACK + SYN ETB NAK packet ACK As you can see, the Sender responds to the SYN with ETB. If after sending ETB three times a NAK is not received, the sender aborts. Similarly, the final packet is sent up to three times. After the final ACK has been received, the transfer ends. Note: the SYN is never sent more than once. If the sender fails to see the SYN, it should send ETB anyway after the normal 10 second timeout. Format of special packet: The special packet is sent with the same error checking already selected, ie. Checksum or 16-bit CRC. The special packet usually has a special block number, $AA, but some implementations don't support this and may simply increment the block number. You should be prepared to accept both. <55> would be the normal start of the packet. Within the packet, the first 23 bytes are valid. The remainder of the bytes are unspecified; I recommend you set them to zero. The 23 bytes of the special packet are nothing more than the ProDOS Get_File_Info and Get_EOF commands and parameter lists, which the receiver can easily turn into Set_File_Info and Set_EOF parameter lists: Byte Description 0 parm count (usually $0A. Can also be $07. Don't count on anything.) 1 pathname pointer low byte (ALWAYS set to $D4 before sending) 2 pathname pointer high byte (ALWAYS set to $41 before sending) 3 file access attributes byte 4 file_type 5 aux_type low 6 aux_type high 7 storage_type 8 blocks_used low 9 block_used high 10 mod_date low 11 mod_date high 12 mod_time low 13 mod_time high 14 create_date low 15 create_date high 16 create_time low 17 create_time high 18 parm count for Get_EOF command (ALWAYS $02) 19 ref_num (usually set to $00 before sending) 20 EOF low 21 EOF mid 22 EOF high Receiver Notes: after receiving the special packet, check these bytes (assumes first byte is byte 0): byte 1 should be $D4 byte 2 should be $41 If these bytes are correct, you can assume that valid ProDOS Get_File_Info was received and you can use bytes 0 to 17 as parm list for the ProDOS Set_File_Info call. Now check byte 18. If byte 18 is $02 then valid EOF file info has been received and you can use bytes 18 to 22 as the Set_EOF parm list. Talk Is Cheap v2.03 (Shareware version) Bug: When TIC 2.03 sends the special ProDOS packet, the Get_EOF information starts at byte 17, overwriting the last byte of the create time (which you normally wouldn't use anyway, as you have already created the file with the current date/time.) To handle this bug in Talk Is Cheap v2.03, do the following: If byte 18 is not 02, check byte 17 to see if it is 02. If byte 17 is 02, check bytes 22 and 23, which will be $FF if sent by Tic 2.03. If the packet passes these tests, you can assume the packet was sent by TIC 2.03 and you can do the Set_EOF call based on bytes 17 to 21 (instead of bytes 18 to 22). 3. CRC and Checksum Calculation Source Code The following routines have been tested in Warp Six BBS v5.0, and calculate fast enough to eliminate any delay in transmission or reception at baud rates commonly used today. (Tested to 2400 bps only.) You may note that there is no requirement for a huge table, yet these routines perform just as well as table lookup routines for CRC calculation. (Checksum calculation is, of course, an insignificant task. I have included checksum source simply for your convenience.) Note: all the source code is written in standard 6502 assembly language, which will run on any Apple II. * CRCCALC: Call once per character. The CRC * is saved in 'CRC1' and 'CRC2'. * You must zero CRC1 and CRC2 before initial call. CRCCALC STA SAVEA STY SAVEY DOCRC STA HOLDCRC ;store it LDA #0 LDX #8 ;operate on all 8 bits CALC1 ASL HOLDCRC ;get next bit of HOLDCRC ROR A ;calculate CRC AND #$80 EOR CRC1 ASL CRC2 ROL A BCC NEXT PHA LDA CRC2 EOR #$21 STA CRC2 PLA EOR #$10 NEXT STA CRC1 DEX ;next bit BNE CALC1 LDA SAVEA LDY SAVEY RTS HOLDCRC DS 1 SAVEA DS 1 SAVEY DS 1 CRC1 DS 1 CRC2 DS 1 * CSUMCALC: calculate cumulative checksum * Call once per character. The checksum is * in 'CHECKSUM' when completed. * You must zero CHECKSUM before initial call. CSUMCALC STA ASAVE CLC ;always toss carry ADC CHECKSUM ;add data byte STA CHECKSUM ;save. LDA SAVEA RTS ASAVE DS 1 CHECKSUM DS 1 End of source code.