UUXFER Documentation for version 1.1
---------------------------------------------------------------------------
 
I figure a lot of you C64 UseNetters out there could make use of a
uuencode / decode program for the C64, so here's my latest version.
 
This program is easy enough to use.  It can encode or decode multiple
files at once, and you have your choice of line terminator (CBM, IBM, or
Unix style).  It encodes files in straight ASCII, although the uuencode
process makes this immaterial.  Filenames are generated automatically,
and you can encode or decode using single or multiple disk drives.
(Multiple drives help a lot, since encoded files are 35% larger than the
original).
 
The only thing this program won't do is separate encoded files into
multiple parts, nor will it combine multiple parts into one file.  You
still have to do that on your own, using a text editor of some sort,
hopefully on your host system that you are downloading from.

Some people are confused about line-ending encoding and file transfer
modes.  The modes are very important and depends entirely on what
programs you are using to transfer the files around.

First of all, I should think that anyone who does Telecomm work on C64's
knows the problem of encoding with ASCII and PETASCII.  UUXFER will
ALWAYS ALWAYS ALWAYS encode its files in ASCII, and *NOT* in PETASCII!
This means that when you upload the file, you must specify either ASCII
or BINARY file transfer, or at least specify that you are turning
translation OFF.  I hope this is clear.

When decoding files with UUXFER, the program should cope properly if you
accidentally leave translation turned on, but I won't swear to that.  It
will properly handle end-of-line encodings of all kinds.

Speaking of end-of-line codes, which one you choose depends on where you
are sending the file (when encoding files).  The coding determines what
characters are placed at the end of each line of output.  If you are
uploading the file using Kermit in ASCII mode, you should specify
CR-only translation, which means each line ends with a carriage return.
If you are using Kermit Binary or Xmodem with no translation, then you
should specify CR+LF if the file is to be used on an MS-DOS machine, or
LF-only if you are uploading to a Unix machine (such as Free-Net).  If
you don't know which to use, I suggest using LF encoding, and uploading
in BINARY mode in your terminal program.  That should give the least
trouble.

If anyone has trouble, just tug my tail and I'll try to help you out.
Have fun!

                                        Fuzzy Fox
                                        aka David DeSimone
