Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!ncis!helios.ee.lbl.gov!nosc!ucsd!rutgers!tut.cis.ohio-state.edu!osu-cis!killer!elg
From: elg@killer.DALLAS.TX.US (Eric Green)
Newsgroups: comp.sys.amiga
Subject: Re: Atalk III 1.0e
Message-ID: <6842@killer.DALLAS.TX.US>
Date: 19 Jan 89 05:19:28 GMT
References: <5707@cbmvax.UUCP>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 30

in article <5707@cbmvax.UUCP>, sterling@cbmvax.UUCP (Rick Sterling QA) says:
> In article <6818@killer.DALLAS.TX.US> elg@killer.DALLAS.TX.US (Eric Green) writes:
>> Let's say that your file length is an exact multiple of 128 bytes.
>> Further, let's say that your file ends with fifteen NUL characters.
>> Xmodem will not create an extra empty padding block. Thus an
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> autochopper will chop off 15 bytes of your file.
>> 
>  According to my reading of the protocol it should create the extra padding
>  block with ^Z's ... This is how I implemented it in several term progs in
>  the past....

History: Ward Christenson needed to transfer binary files from one
CP/M system to another. CP/M binary files are all a multiple of 128
bytes long. So all files he transferred were a multiple of 128 bytes
long -- with no padding, and with no padding block.

If I called your system (which creates the extra padding blocks) with
my CP/M system (a Commodore 128 running MEX), and uploaded a binary
file, then downloaded it back to myself, what I got back would be
incorrect.

CP/M is the ultimate test of whether an Xmodem protocol is "right" or
not. If it don't work under CP/M, it ain't Real Xmodem.

--
Eric Lee Green    ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg
          Snail Mail P.O. Box 92191 Lafayette, LA 70509              
Netter A: In Hell they run VMS.
Netter B: No.  In Hell, they run MS-DOS.  And you only get 256k.