[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Null modem transfers
- Subject: Re: Null modem transfers
- From: cturley2@aol.com (Cturley2)
- Date: 2000/05/29
- Newsgroups: comp.sys.apple2
- Organization: AOL http://www.aol.com
- References: <SWyY4.4632$Zm5.349264@bgtnsc06-news.ops.worldnet.att.net>
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. <SOH> <AA> <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.