Sorry, I mean 7 hundred, not K :-)

On 29/08/06, Tamas Rudnai <tamas.rudnai@gmail.com> wrote:
>
> 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
>



-- 
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