>From: "Jinx" > I don't think this would be such a problem. It would probably > be less of a problem if you used a PIC that can read its own > Flash memory, eg the 877, which will give you a lot of 14-bit > storage. snip Yes, that's the plan. I've created a small VC++ application that reads a text file with all the strings and packs them into the 14 bit locations, then generates a header file with a set of #rom directives such as: #rom 0x1008 = { 0x3F42 , 0x3CA0, 0x25E5, 0x3720, etc. } The input file looks similar to: #C --- Replace all '!' with NULL --------------- #REPLACE ! WITH 0x00 #C --- ROM starting address is set to 0x1000 --- #STARTADDRESS = 0x1000 #C Screen 2 BAUDRATE~1200@2400@4800@9600@14400@! I'm using the "~" as a separator between Line1 and 2 data, the "@" is a field separator and the "!" gets replaced with a null to indicate end of line 2 data. This works ok, except that there is no way to index into the data as all fields are variable length. You have to start at the beginning and count nulls to find the record you want to display. That's sort of ugly, and it doesn't include linkages to either commands or sub menus. I'm thinking some sort of state machine with the states embedded in the text is what I want, but again I might be overlooking a much simpler solution. >As for the data location calculation, having > the data stored in groups of 16 (assuming a 16x2 LCD) would > make for a fairly easy offset and retrieval algorithm, and using > the free bits would keep all the data and action flags contained > with that 16-byte block. I'll have to think about that. It would require padding, however overall it may be more efficient than using the field separators etc, as outlined above. Thanks for your input. Ken -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.