From: Rick_Michael_Cortese@cup.portal.com
Newsgroups: comp.sys.atari.8bit
Subject: Re: My ego VS UUE
Date: Wed, 30 Dec 92 13:33:59 PST
Organization: The Portal System (TM)

Well, if anybody is still lurking.  I used some of the files
I created with a Basic encoder/decoder to run some checks.  I
used Express on the Atari end & First Choice (an integrated
package equivalent to our HomePak) on my clone.  Turns out
you run into a number of problems with this set up.  Not the
least of which is the `'.  If your reading this on an Atari,
those two characters will<may> look identical. This isn't
just a problem with my encryption scheme since the existing
schemes use those characters, it's a problem with
Atari/Express.  Atari uses a diamond <control .> as character
96 so every time Express sees a 96 in ASCII, it translates it
to a CHR$(39). Needless to say, this wrecks havoc with the
file integrity. There are two work arounds for this; [Xmodem,
go to ATASCII].  ATASCII works fine for captures & send from
disk *IF* you just remember to use <control>M instead of
hitting the return key & you can always switch back to ASCII
after the transfer/capture.  I never bothered to check what
the Atari version of UUDECODE does to avoid it (assume
Xmodem?).  One other problem I ran into with Express, it
doesn't start the "CAPTURE" immediately. I had to send it one
Atari <CR> to get it to save the first part of the file.  I'm
not sure what people do now since what little I do now is
done on my ST or clone.  It turns out just about EVERYTHING
adds line feeds to carriage returns.  This means that my
encoding/decoding scheme had to allow for LF's just so you
could "CAPTURE" posts in addition to Xmodem.  The bottom
line.  It works, but has to suffer a little on efficiency
because instead of just an single <CR>, you get [<CR>, <LF>]
for every line. I kept my test lines short, 35 characters, so
I could print out everything while it was being decoded so
this adds 2 bytes for every 35 to the file size.  Not really
a problem since I could just increase the line length to 75
or so.  My test file was 425 bytes long & ended up being 581
bytes or 1.37X the original.  This works out because of the
overhead & <LF's> the BBS's added: .BEGIN<CR><LF> 15
lines*(35 bytes/line+<CR><LF>) 1 line *10 bytes+<CR><LF>
.END<CR><LF> I used UUENCODE.EXE on my clone for a 540 byte
file & it went to 958 bytes or 1.77X.  Since this was too
fair to me, I used some larger files with the clone & got the
following: original UUE   X
 34816  49707 1.43
  7168  10389 1.45
So I don't think I was out of line saying UUE produces files
1.5 times their original size. The best it will do with an
infinitely large file would be about 1.43X original & when
you get down to files around 8k (The kind that concern us)
most of the stuff will be in the 1.5X range.  I haven't run
any long programs through my encoding scheme yet since it's
still in BASIC & runs at a snails pace, but assuming a large
file such that the [".BEGIN", ".END", checksum, file size]
become relatively small, mine would do: 5/4*37/35 or 1.32
times the original file size. If I pick a more reasonable
line length for the final version, like 75, it's only 1.28
times the original.  I'm not sure what the maximum line
length is on the net, but that seems reasonable (I think I
only said about 15% after adding checksum etcetera).  I guess
it all comes down to what you feel is significant.  If
there's 2 million people on the net & they spend an average
of 6 minutes a year down loading UUE files, it only saves
them a minute each.  If they're paying an average of $6/hour
it's only worth about a dime each, but 2 million dimes is
$200,000/year.  Besides, who's the last guy to save you a
dime without asking for a dollar in return?  Anyway, the next
3 messages in this conference will be a SLOW basic program to
encode files, one to decode, and the demo file.  When I
compiled the demo file I was using SDX & forgot to move the
program above where DOS 2.5 & DUP.SYS like to go before I
compiled it!  It'll still load from the menu, & won't trash
much if it's done as an AUTORUN.SYS file. I certainly
wouldn't use the programs for anything other then testing.
They're a pretty bad example & illustrate why I mainly use
Action!  (warning; confusing code here!).  I used a D9:
ramdisk for the test, so you'll have to change those lines
appropriately for your system & hope I got the right versions
of the programs.  Thanks in advance to anybody that tries to
get this thing to work or let's me know the reason why it
didn't.  Seems like there's more interest for curiosity sake,
but at least I feel like I've proved my point.  Besides, I
think I just came up with a text compression routine <grin>.
Newsgroups: comp.sys.atari.8bit