A very useful scheme I have made for compacting textual data is to take advantage of the fact that text (in many places at least) can be represented by ASCII or some other 7-bits codes. I have used an off-line tool that analyzes the text data base and compresses it in several simple ways. Then the packed version of the text is placed into non-volatile memory and read out at run time and decoded. The coding scheme works according to this set of rules:

1) If an byte has bit 7 clear then the lower 7 bits are the text character value.

2) If the upper bit is set and lower 7 bits are 0 (i.e == 0x80) then the following byte is a special character from the upper 128 character page of the font set.

3) If the upper bit is set and the lower 7 bits are 1 (i.e. == 0x81) then the following two bytes are an index to a token dictionary table of where to find the text token to be inserted at this point.

4) If the upper bit is set and the lower 7 bits are 2 (i.e. == 0x82) then the following two bytes are an index to the token dictionary table of where to find the text token to be inserted at this point then followed by a space.

5) If the upper bit is set and the lower 7 bits are 3 (i.e. == 0x83) then the following two bytes are an extended character code into a secondary font table used for example when western text is mixed with Chinese characters.

6) If the upper bit is set and the lower 7 bits are a value >= 4 then the following single byte is the a text character to repeat the number of times specified by the count in the lower 7 bits.

This scheme may take more than 1 or 2 bytes of internal RAM to decode but for a typical product user interfaces where I have used this scheme I have been able to realize text compressions of greater than 2.5 to 1. On one product I recall a menu system that has about 25 menus (hundreds of strings) that occupied about 45K bytes of straight text that was reduced to less than 20K bytes. Using this process I was able to gain enough memory space in the product to permit embedding the menu data sets for up to ten translations (different languages) so that the users could change product country selection on the fly at runtime.

If anybody wants more info on this idea I would let you look at the decoding tool (in C code) and the off-line tool that makes the compressed dataset (also in C code). I made this scheme for use on a different type of processor platform but there is no reason that it could not be used on an 8052 type processor as well. There is also reason to believe that the run time decoding could easily be done in assembler.

Michael Karas