BBS: Inland Empire Archive
Date: 01-04-56 (01:04) Number: 1466
From: BRENT ASHLEY Refer#: NONE
To: ALLAN ZACHARY Recvd: NO
Subj: LoCode 1/5 Conf: (2) Quik_Bas
Hi Allan;
When you wondered aloud recently how UUENCODE did its thing
with only a ~3/2 expansion ratio, it set me to thinking. Four
hours later, I had these two programs finished - LoCode and UnLoc.
The text files produced by LoCode consist of only low-ascii codes,
specifically only upper and lower alpha, numbers, round brackets
and CR/LF pairs. No @ signs for fido to choke on. In the
interests of keeping overhead low, there is very little
error-checking, but I think enough to flag problems.
The programs are based on the idea that using 6 bits of each
byte, it will take four such bytes to accumulate 24 bits, which
can in turn be re-split to represent 3 8-bit bytes. This should
thoeretically give a 4/3 expansion ratio, but overhead bytes
(CR/LF, flags, identifiers) push that closer to 3/2.
Below are the 4 coded bytes, with the Xs as unused bits (0s) and
the bit positions for the three original bytes marked by number.
byte 1 byte 2 byte 3 byte 4
|X X 3 3 3 3 3 3|X X 3 3 2 2 2 2|X X 2 2 2 2 1 1|X X 1 1 1 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The six bits represent 64 codes, and I use a character set
made up of 64 of the most innocuous characters to represent those
64 choices.
The code follows in the next few messages.
-----
Brent
-----
___
X DeLuxe2 1.12 #10383 X
--- Maximus 2.00
* Origin: Durham Systems (ONLINE!) (1:229/110)
