Also you could use other encoding than ASCII and you can convert them back
on the fly. So for example if you have English text with 28 letters you can
store it in 5 bits. Let's say b'00000' and b'11111' have special meaning (0
is for terminating, full 1 is for escaping. If you have other char than the
standard English ABC but not too often then you can apply the escape and a
full 8 bit value for that.

Calculus: let's say you have 4 char length in average, so 270*4 = 1080.
That's the size if you are using the upper bit as termination as suggested.
If you still using 0 as termination then you have 1350 bytes to store. It is
1350*5 bit in my suggestion, which is ~844 bytes.

You can go further by not storing each chars, but storing the first char
then the 'distance' between the chars. So that 'apple' is encoded in ASCII
as 0x61 0x70 0x70 0x6c 0x65, so you write down 0x61, then 0x0f 0x00 -0x04
-0x07. If you say that you store 3 bits and the sign bit then you can store
many things in 4 bits only and you can use 0 as an escape as not too many
double chars are there. Depending on the text you could store your stuff
around 7k.

If you combine it with a standard compression suggested then you could go
pretty much down.

Tamas


On 29/08/06, Timothy Weber <tw@timothyweber.org> wrote:
>
> Brent Brown wrote:
> > On 28 Aug 2006 at 23:29, Robert Ammerman wrote:
> >> What is the total length of all your menu text?
> >>
> >> I ask this question because it indicates the feasibility /
> >> desirability of using some Really Sneaky Tricks (TM) to crunch down
> >> the space required....
> >
> > About 270 characters at present, some in LCD display text, other's in
> serial
> > command strings and debug output. Mostly short strings 3-5 chars long,
> LCD is only
> > 2 x 8. That also seems to be why Hi-Tech PICC doesn't pack 2 into a word
> - strings
> > need to be about 30 chars or more long before it deems it efficient to
> do so (added
> > code overhead I guess). I like your ideas for compression. Will do my
> best though
> > to just do Sneaky Tricks for now and avoid the Really Sneaky Tricks
> because time
> > is against me.
>
> One Trick I've used that's only Slightly Sneaky is to use the high bit
> to indicate the last char of a string, instead of a terminating null.
> If you have 270 characters of ~4 char strings, that's a savings of 54
> bytes.  Not a lot, but maybe helpful.
>
> Not useful if you have other than ASCII characters in your strings, of
> course.
> --
> Timothy J. Weber
> http://timothyweber.org
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>



-- 
unPIC -- The PIC Disassembler
http://unpic.sourceforge.net
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist