What do you do when you've run out of program space in a PIC16F88? I'm looking
through the Microchip website but can't find anything ideal yet. The perfect solution
would be a drop in pin compatible chip with all the same features but 8K words of
Flash instead of 4K.
Features I need are self writable Flash for bootloader, internal RC oscillator, some
EEPROM, PWM, USART, 28 pin QFN package, more than 4K words of program
space (probably 6-8K). PIC16F886 looks like a contender but it doesn't apprear to
be available yet (who knows when?), also not pin-compatible but could do a PCB
re-design (don't really want to). Is there another chip out there I just haven't seen
yet? eg. What is a PIC16F89 and why can't I find it on the Microhip site? Google
finds a few references to it but I have no hard facts.
For my prototypes I think I can just squeeze in enough of the program to get them
running, but there will be some extra features required for production units. I need
to add LCD menu's for installer setup options etc, which eats up code space I don't
have. Program is written in Hi-Tech PICC, and I'm not blaming that for my code size
problems. I'm doing all the things I can think of to minimise space used.
--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail: spam_OUTbrent.brownTakeThisOuTclear.net.nz
Brent Brown wrote:
> What do you do when you've run out of program space in a PIC16F88? I'm looking
> through the Microchip website but can't find anything ideal yet. The perfect solution
> would be a drop in pin compatible chip with all the same features but 8K words of
> Flash instead of 4K.
>
> Features I need are self writable Flash for bootloader, internal RC oscillator, some
> EEPROM, PWM, USART, 28 pin QFN package, more than 4K words of program
> space (probably 6-8K). PIC16F886 looks like a contender but it doesn't apprear to
> be available yet (who knows when?), also not pin-compatible but could do a PCB
> re-design (don't really want to). Is there another chip out there I just haven't seen
> yet? eg. What is a PIC16F89 and why can't I find it on the Microhip site? Google
> finds a few references to it but I have no hard facts.
>
> For my prototypes I think I can just squeeze in enough of the program to get them
> running, but there will be some extra features required for production units. I need
> to add LCD menu's for installer setup options etc, which eats up code space I don't
> have. Program is written in Hi-Tech PICC, and I'm not blaming that for my code size
> problems. I'm doing all the things I can think of to minimise space used.
>
If nothing else presents itself, I would examine the listing to check
for extra unneeded instructions. For example, bank switching when it's
not needed, etc. But that's a long shot in terms of getting much from
it. Maybe factoring the program to eliminate redundant code...
I'm not sure, but you might want to try compiling the code for the 18F1320.
As far as I can tell, C is more efficient on the 18F series compared to the
16F, and you might be able to fit more into the same amount of memory. I
glanced over the datasheets, and it seems the 18F1320 and the 16F88 are QFN
pin compatible and both have a PWM and USART and 256 bytes of EEPROM.
At least try it: the instruction set of the 18F series is broader, and it
also has 16 bit/word, instead of 14-bit, which can make a difference when
storing data in program memory.
> I'm looking
> through the Microchip website but can't find anything ideal yet.
> The perfect solution
> would be a drop in pin compatible chip with all the same features
> but 8K words of
> Flash instead of 4K.
>
> Features I need are self writable Flash for bootloader, internal
> RC oscillator, some
> EEPROM, PWM, USART, 28 pin QFN package, more than 4K words of program
> space (probably 6-8K). PIC16F886 looks like a contender but it
> doesn't apprear to
> be available yet (who knows when?), also not pin-compatible but
> could do a PCB
> re-design (don't really want to).
you could try the 18F1320, no more instruction words but its 18 series which
should be able to do the same C code in less words (and since your coding in
C migration to the pic18 core shouldn't be too hard). The pinout differs in
what ports are where but not in the vital stuff like power ground and which
pins are in use. If you go for this chip though make sure you get as recent
a rev as possible. There are a lot of horror stories about it particularlly
the early revs.
Failing that it doesn't look like you have much choice but to go for
something with more used pins. my parametric searching revealed the
following possibilities
If you can tweak the board how about adding an external serial memory chip?
The menus probably won't be accessed often so loading them over a serial link may not be bad?
>be available yet (who knows when?), also not pin-compatible but could do a PCB
>re-design (don't really want to).
>
>For my prototypes I think I can just squeeze in enough of the program to get them
>running, but there will be some extra features required for production units. I need
>to add LCD menu's for installer setup options etc, which eats up code space I don't
>have. Program is written in Hi-Tech PICC, and I'm not blaming that for my code size
>problems. I'm doing all the things I can think of to minimise space used.
>
> Brent Brown wrote:
> > What do you do when you've run out of program space in a PIC16F88? I'm looking
> > through the Microchip website but can't find anything ideal yet. The perfect solution
> > would be a drop in pin compatible chip with all the same features but 8K words of
> > Flash instead of 4K.
> >
> > Features I need are self writable Flash for bootloader, internal RC oscillator, some
> > EEPROM, PWM, USART, 28 pin QFN package, more than 4K words of program
> > space (probably 6-8K). PIC16F886 looks like a contender but it doesn't apprear to
> > be available yet (who knows when?), also not pin-compatible but could do a PCB
> > re-design (don't really want to). Is there another chip out there I just haven't seen
> > yet? eg. What is a PIC16F89 and why can't I find it on the Microhip site? Google
> > finds a few references to it but I have no hard facts.
> >
> > For my prototypes I think I can just squeeze in enough of the program to get them
> > running, but there will be some extra features required for production units. I need
> > to add LCD menu's for installer setup options etc, which eats up code space I don't
> > have. Program is written in Hi-Tech PICC, and I'm not blaming that for my code size
> > problems. I'm doing all the things I can think of to minimise space used.
> >
> If nothing else presents itself, I would examine the listing to check
> for extra unneeded instructions. For example, bank switching when it's
> not needed, etc. But that's a long shot in terms of getting much from
> it. Maybe factoring the program to eliminate redundant code...
>
Jinx wrote:
>> What do you do when you've run out of program space in a
>> PIC16F88?
>> look for something bigger of course. Some compromise may
>> be needed though.
>>
>
> www.microchip.com/ParamChartSearch/chart.aspx?branchID=1035&mid=10&la
> ng=en&pageId=74
>
> 18-pin, 18F1320
>
> 28-QFN, 16F876A / 916, 18F24xx / 25xx / 26xx
>
>
You COULD switch to assembler, of course...
You can sometimes find a few routines or data structures that are taking up
an inordinate amount of space....
Some common candidates:
1. The floating point routines. Many (most?) apps that use floating point
will work very well with fixed point arithmetic and a little bit of care.
2. The 'printf' routine and its relatives. This is a real hog, especially
when combined with support for floats! You can avoid these routines by
using simpler ones like itoa(), or even one written by yourself (it isn't
hard!).
3. Inefficient data structures for things like menus (in code space). Look
out for fixed length string buffers:
char menu_choices[4][21] = {
"La la",
"Do de do",
"Moonshine",
"Happy!"
};
This uses 68 bytes of memory to hold 4 20-character menu options.
char *menu_choices[4] = {
"La la",
"Do de do",
"Moonshine",
"Happy!"
};
This uses 8 bytes for 4 pointers, plus 32 bytes for text and nulls for a
total of 40 bytes.
Or, even better, since accessing menu choices is a "human speed" action...
char menu_choices[] = {
"La la\0"
"Do de do\0"
"Moonshine\0"
"Happy!\0"
};
Which uses only 33 bytes. Note that there are no commas, and each entry is
terminated with an explicit null. The last entry is terminated with a double
null. It is easy to write a function:
char *find_menu_entry( char *menu, int n )
{
while (n--)
{
/* point to next menu item */
menu = strchr(menu,0) + 1;
/* next two lines are optional to protect from */
/* invalid values of 'n' */
if (*menu == 0)
return 0; /* ran off the end */
}
return menu;
}
(where n is a number in the range 0..number of substrings - 1)
> Add another 16F88 - or something smaller just to look after (eg) the
> LCD dispay etc.?
Already doing that as the LCD display and keypad is remote and it has it's own
PIC16F88, with comms over an RS232 like interface. I send instructions like "put
this string of characters on line 2".
> If you can tweak the board how about adding an external serial memory
> chip? The menus probably won't be accessed often so loading them over a
> serial link may not be bad?
Not keen on that (hardware wise), but could use on chip EEPROM to store some
strings I guess, but really that would only be a saving of a few hundred bytes max.
> you could try the 18F1320, no more instruction words but its 18 series
> which should be able to do the same C code in less words (and since your
> coding in C migration to the pic18 core shouldn't be too hard).
Interesting idea... so I did a quick test to try it.
Compiling for PIC16F88 --> 3669 words (89.6% of 4096 words).
Compiling for PIC18F1320 --> 3511 words (85.7% of 4096 words).
Used Hi-Tech PICC and PICC-18 Compilers. Commented out about a dowzen lines
that wouldn;t compile without some tweaking. Not a huge difference in code size
although it does at least tend to confirm that 18F programs can be more size
efficient as one might expect.
Other bit's and pieces... I'm not using floats, printf or any large data structures. My
menu structure is not great but not obese either. The one thing that pushed me over
the top was adding CRC checking for my 1 wire temperature sensors - needed it
because I'm getting the occasional erroneous result. This adds about 300 program
words.
Having made some improvements and nips/tucks in other areas I think I will keep
plodding along and get as much code as possible squeeezed in to my prototype(s) -
gotta be working by the end of this week! After that I'll have to look at a bigger
micro, new PCB, seems like there are a few possibilities.
It's a shame I can't find anything about a PIC16F89. A couple of ICE vendors make
pods described as being for PIC16F87/88/89 so perhaps this is something
scheduled for the future, and just maybe the difference is it has larger Flash? Can't
help the feeling that I've read about it somewhere.
Thanks all for the tips.
--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail: brent.brownKILLspamclear.net.nz
>What do you do when you've run out of program space in a PIC16F88? I'm looking
>through the Microchip website but can't find anything ideal yet. The perfect solution
>would be a drop in pin compatible chip with all the same features but 8K words of
>Flash instead of 4K.
>
>Features I need are self writable Flash for bootloader, internal RC oscillator, some
>EEPROM, PWM, USART, 28 pin QFN package, more than 4K words of program
>space (probably 6-8K). PIC16F886 looks like a contender but it doesn't apprear to
>be available yet (who knows when?), also not pin-compatible but could do a PCB
>re-design (don't really want to). Is there another chip out there I just haven't seen
>yet? eg. What is a PIC16F89 and why can't I find it on the Microhip site? Google
>finds a few references to it but I have no hard facts.
>
>For my prototypes I think I can just squeeze in enough of the program to get them
>running, but there will be some extra features required for production units. I need
>to add LCD menu's for installer setup options etc, which eats up code space I don't
>have. Program is written in Hi-Tech PICC, and I'm not blaming that for my code size
>problems. I'm doing all the things I can think of to minimise space used.
>
>
>
Made my C program a chunk smaller by re-using strings in messages
(stored as tables in program memory....). I wrote it with C18 in mind,
but will probably be useful for HitechC as well.
(Especially if you say your menu system is obese).
> My comments below on various replies..
>
>
> [snip]
> Interesting idea... so I did a quick test to try it.
> Compiling for PIC16F88 --> 3669 words (89.6% of 4096 words).
> Compiling for PIC18F1320 --> 3511 words (85.7% of 4096 words).
> Used Hi-Tech PICC and PICC-18 Compilers. Commented out about a dowzen lines
> that wouldn;t compile without some tweaking. Not a huge difference in code size
> although it does at least tend to confirm that 18F programs can be more size
> efficient as one might expect.
>
> Other bit's and pieces... I'm not using floats, printf or any large data structures. My
> menu structure is not great but not obese either. The one thing that pushed me over
> the top was adding CRC checking for my 1 wire temperature sensors - needed it
> because I'm getting the occasional erroneous result. This adds about 300 program
> words.
>
> Having made some improvements and nips/tucks in other areas I think I will keep
> plodding along and get as much code as possible squeeezed in to my prototype(s) -
> gotta be working by the end of this week! After that I'll have to look at a bigger
> micro, new PCB, seems like there are a few possibilities.
>
> It's a shame I can't find anything about a PIC16F89. A couple of ICE vendors make
> pods described as being for PIC16F87/88/89 so perhaps this is something
> scheduled for the future, and just maybe the difference is it has larger Flash? Can't
> help the feeling that I've read about it somewhere.
>
> Thanks all for the tips.
>
Brent Brown wrote:
> The one thing that pushed me over the top was adding CRC
> checking for my 1 wire temperature sensors - needed it
> because I'm getting the occasional erroneous result.
> This adds about 300 program words.
Huh!?
CRC is a really simple algorithm that shouldn't take more than a few
instructions. For each bit you shift it in one end. If the bit that
shifted out the other end is 0 you're done. If it is 1, you XOR the
accumulated checksum with a fixed value. That's it. There are some
variations about which end to shift into, whether you do the XOR on a 0 or
1, what the accumulator is initialized to, etc. However, none of these
should change the basic algorithm or the number of instructions required.
I just checked some recent code I wrote that computed a 16 bit CRC on bits
in a buffer. It takes 29 instructions, which includes the initialization,
checking for end condition, advancing to the next bit, etc. The actual CRC
update calculation is only 8 instructions once the bit is in STATUS,C.
******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014. #1 PIC
consultant in 2004 program year. http://www.embedinc.com/products
> Have a look at:
>
> file:///C:/Repository/NikonSB/StringFormat.html
>
> Made my C program a chunk smaller by re-using strings in messages
> (stored as tables in program memory....). I wrote it with C18 in mind,
> but will probably be useful for HitechC as well.
>
> (Especially if you say your menu system is obese).
>
> Rolf
>
> Brent Brown wrote:
>
>> My comments below on various replies..
>>
>>
>> [snip]
>> Interesting idea... so I did a quick test to try it.
>> Compiling for PIC16F88 --> 3669 words (89.6% of 4096 words).
>> Compiling for PIC18F1320 --> 3511 words (85.7% of 4096 words).
>> Used Hi-Tech PICC and PICC-18 Compilers. Commented out about a dowzen lines
>> that wouldn;t compile without some tweaking. Not a huge difference in code size
>> although it does at least tend to confirm that 18F programs can be more size
>> efficient as one might expect.
>>
>> Other bit's and pieces... I'm not using floats, printf or any large data structures. My
>> menu structure is not great but not obese either. The one thing that pushed me over
>> the top was adding CRC checking for my 1 wire temperature sensors - needed it
>> because I'm getting the occasional erroneous result. This adds about 300 program
>> words.
>>
>> Having made some improvements and nips/tucks in other areas I think I will keep
>> plodding along and get as much code as possible squeeezed in to my prototype(s) -
>> gotta be working by the end of this week! After that I'll have to look at a bigger
>> micro, new PCB, seems like there are a few possibilities.
>>
>> It's a shame I can't find anything about a PIC16F89. A couple of ICE vendors make
>> pods described as being for PIC16F87/88/89 so perhaps this is something
>> scheduled for the future, and just maybe the difference is it has larger Flash? Can't
>> help the feeling that I've read about it somewhere.
>>
>> Thanks all for the tips.
>>
>>
>
>
On Mon, 2006-08-28 at 21:00 +1200, Brent Brown wrote:
>> You COULD switch to assembler, of course...
>
> COULD but WONT! :-)
Hmm?
> The one thing that pushed me over the top was adding CRC checking
> for my 1 wire temperature sensors - needed it because I'm getting
> the occasional erroneous result. This adds about 300 program words.
300 words is very excessive for a CRC routine. My one-wire CRC
routines takes only 19 instructions and no table:
>What do you do when you've run out of program space in a PIC16F88? I'm looking
>through the Microchip website but can't find anything ideal yet. The perfect solution
>would be a drop in pin compatible chip with all the same features but 8K words of
>Flash instead of 4K.
>
>Features I need are self writable Flash for bootloader, internal RC oscillator, some
>EEPROM, PWM, USART, 28 pin QFN package, more than 4K words of program
>space (probably 6-8K). PIC16F886 looks like a contender but it doesn't apprear to
>be available yet (who knows when?), also not pin-compatible but could do a PCB
>re-design (don't really want to). Is there another chip out there I just haven't seen
>yet? eg. What is a PIC16F89 and why can't I find it on the Microhip site? Google
>finds a few references to it but I have no hard facts.
>
>For my prototypes I think I can just squeeze in enough of the program to get them
>running, but there will be some extra features required for production units. I need
>to add LCD menu's for installer setup options etc, which eats up code space I don't
>have. Program is written in Hi-Tech PICC, and I'm not blaming that for my code size
>problems. I'm doing all the things I can think of to minimise space used.
>
>--
>Brent Brown, Electronic Design Solutions
>16 English Street, St Andrews,
>Hamilton 3200, New Zealand
>Ph: +64 7 849 0069
>Fax: +64 7 849 0071
>Cell: 027 433 4069
>eMail: .....brent.brownKILLspam.....clear.net.nz
>
>
2006/8/28, Scott Dattalo <EraseMEscottspam_OUTTakeThisOuTdattalo.com>:
>
> On Mon, 2006-08-28 at 21:00 +1200, Brent Brown wrote:
>
> >> You COULD switch to assembler, of course...
> >
> > COULD but WONT! :-)
>
> Hmm?
Basically I have the feeling the design stage for this project was cut
short. I enjoy making a design before I code anything, even if it is on
pieces of scrap paper. From this design I can then tell what kind of
PICmicro I will need, and what the approximate code sizes are for the
various features. I would not get a 16F88 if I didn't have I2C or SPI, and
if my design indicated it would benefit from coding in C, I would probably
look towards the 18F family immediately. This is how I ended up with the
16F628A for my NTSC system, which worked very well (better than any other
16F series would have worked, although the bug in the EEPROM write routines
was a bit unfortunate).
Generally, when I have a good design, I don't really care about coding the
entire project again. The coding phase for an 4-8 Kword PICmicro should be
very short (2-4 days), especially if the design covers what needs to be done
where, and how it can be tested quickly. Also, rewriting everything tends to
improve the quality of my code.
I would be worried about redesigning the PCB though, and I can see why this
would be a major concern of Brent. I was happy that he told us the
difference in code efficiency between the 16F and 18F series, I thought it
would've been better, but at least we now have one sample.
>
> Try this LCD controller:
>
> http://www.myke.com/lcd.htm
>
> Less code and pins, using just a cheap CI 74LS174.
Please explain how serial access to an LCD reduces the code size compared to
full parallel access? I know it reduces the number of pins (though I would
go for a three pin interface with a normal shift register, and not Myke's
two pin interface... I never had much luck with that) but in my experience,
it increases the code size: instead of a simple "move data to port, toggle
enable" you now have to shift each bit separately and then toggle enable.
In Brent's case it doesn't really help either, as it would still result in a
redesign of his PCB, which is the thing he is trying to avoid.
I do appreciate seeing the old example from Myke Predko coming back, though
(I liked his book a lot).
>> Try this LCD controller:
>>
>> http://www.myke.com/lcd.htm
>>
>> Less code and pins, using just a cheap CI 74LS174.
>>
>
>
> Please explain how serial access to an LCD reduces the code size compared to
> full parallel access? I know it reduces the number of pins (though I would
> go for a three pin interface with a normal shift register, and not Myke's
> two pin interface... I never had much luck with that) but in my experience,
> it increases the code size: instead of a simple "move data to port, toggle
> enable" you now have to shift each bit separately and then toggle enable.
>
> In Brent's case it doesn't really help either, as it would still result in a
> redesign of his PCB, which is the thing he is trying to avoid.
>
> I do appreciate seeing the old example from Myke Predko coming back, though
> (I liked his book a lot).
>
> Greetings,
> Maarten Hofman.
>
>>
>> Try this LCD controller:
>>
>> http://www.myke.com/lcd.htm
>>
>> Less code and pins, using just a cheap CI 74LS174.
>
>
>Please explain how serial access to an LCD reduces the code size compared to
>full parallel access? I know it reduces the number of pins (though I would
>go for a three pin interface with a normal shift register, and not Myke's
>two pin interface... I never had much luck with that) but in my experience,
>it increases the code size: instead of a simple "move data to port, toggle
>enable" you now have to shift each bit separately and then toggle enable.
>
>In Brent's case it doesn't really help either, as it would still result in a
>redesign of his PCB, which is the thing he is trying to avoid.
>
>I do appreciate seeing the old example from Myke Predko coming back, though
>(I liked his book a lot).
>
>Greetings,
>Maarten Hofman.
>
> >I do appreciate seeing the old example from Myke Predko coming back,
> though
> >(I liked his book a lot).
>
>
> Which book did you like? He has lots in print, and I would like to
> choose a good starting point.
The book is called "Programming and Customizing PICmicro Microcontrollers".
I wouldn't use it as a starting point, though. It is similar to another
thought provoking book I read, "Effective C++: 55 Specific Ways to Improve
Your Programs and Designs". Both require you to have a reasonable amount of
background knowledge before you can use them. Here is a partial list of pros
and cons:
- Many bugs in both code and circuit diagrams, which require thinking.
+ Many bugs in both code and circuit diagrams, which require thinking.
- Rather old (18F only covered to a limited extent, too much 17F and no
16-bit PICmicros).
+ Very clever circuits, like the one resistor RS-232 level converter.
- Focuses on the 16F84A (please use the 16F628A or higher as replacement).
+ He writes down his line of thought as well as his mistakes, allowing you
to follow/avoid.
Try to get the newest revision of the book. Do not build the included "El
Cheapo" programmer, unless you enjoy restricting yourself to a rather small
sample of PICmicros. A JDM programmer from eBay will be cheaper (and will be
fine, if your serial port is compliant), and a PICkit 2 will make you much
happier.
Note that my preference for this book stems from the fact that I have no
problems with code, but occasional difficulties with the electrical
circuits. Myke's circuits are worth looking at, his code might not be.
>
> "and not Myke's two pin interface... I never had much luck with that"
> What kind of problems did you experience with this implementation?
First of all wiring it compared to a simple shift register is much more
complicated. In the circuit diagram they put all the connections to the
74LS174 next to each other, but in reality you need to connect the lines all
over the place. Also, the diode and resistor increase the number of points
that need to be soldered and designed for on your board even larger.
My second problem with the system is that the "shift" register needs to be
cleared after each operating, which basically doubles the number of cycles
spent shifting. If you just wait for 160us afterwards anyway this doesn't
really matter, of course, but if you're updating the LCD every 160us from an
ISR the double length really impacts the speed of your code.
The third problem is that I never was able to get that E pulse happen quite
the way it is supposed to. Even Myke himself is a bit confused whether it is
high level active or falling edge active. By keeping the enable completely
separate I never ran into problems with this.
Finally, if you keep the enable separate, you can use the shift register
output data for multiple purposes. you just need another enable line, and
you can have the data go to multiple locations, thereby increasing the
number of pins you can output to drastically.
> > What is a PIC16F89
>
> Dunno, but this looks to have been lifted from a d/s
>
> http://micropic.free.fr/16F89.jpg
>
> Same as an F88 with C0 and C1 in the middle
Yes, interesting. Google finds parts suppliers that list a PIC16F89, although I'm
wondering if they're just typo's.
--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail: @spam@brent.brownKILLspamclear.net.nz
> Yes, interesting. Google finds parts suppliers that list a PIC16F89,
> although I'm wondering if they're just typo's.
Showing pin-outs is a major typo !! Could be someone's idea of
a joke of course. Or escaped info on a planned product that never
got off the drawing board
I'm enquiring at Microchip. 16F89 doesn't appear in any of
the drop-downs, so the answer will probably be what we think
it's going to be
I was using a table driven CRC routine, which takes 256 words of code space just
for the table plus about 26 words of code. Many thanks to Steve Baldwin who sent
me a nice little CRC function, no table, uses a total of 34 words program space
including call to function and testing the result. Obviously slower than the lookup
table method but that's fine for me and saves a useful amount of code psace.
String packing (2 characters per word) is something Hi-Tech PICC is supposed to
do for midrange PIC's that can read their own program memory "if it is efficient to
do so". So far it seems to not be doing this, don't know why yet so I will look at that
a bit closer. At this stage const strings uses 290 words, or about 7.1% of total Flash.
--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail: KILLspambrent.brownKILLspamclear.net.nz
> > Yes, interesting. Google finds parts suppliers that list a PIC16F89,
> > although I'm wondering if they're just typo's.
>
> Showing pin-outs is a major typo !! Could be someone's idea of
> a joke of course. Or escaped info on a planned product that never got
> off the drawing board
>
> I'm enquiring at Microchip. 16F89 doesn't appear in any of
> the drop-downs, so the answer will probably be what we think
> it's going to be
In that case don't forget to tell them what we want it to be. 8K words of Flash
please! Oh, and it would also be nice if we could run it at more than 4MHz at low
voltage.
--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail: RemoveMEbrent.brownTakeThisOuTclear.net.nz
On 8/28/06, Jinx <spamBeGonejoecolquittspamBeGoneclear.net.nz> wrote:
> > Yes, interesting. Google finds parts suppliers that list a PIC16F89,
> > although I'm wondering if they're just typo's.
>
> Showing pin-outs is a major typo !! Could be someone's idea of
> a joke of course. Or escaped info on a planned product that never
> got off the drawing board
>
> I'm enquiring at Microchip. 16F89 doesn't appear in any of
> the drop-downs, so the answer will probably be what we think
> it's going to be
>
Remember the 8-pin 18F010 and 18F020? I even had the
printed datasheet but it never hits the market...
www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2018&mcparam=en013478
The confident use of the present tense would make one
assume they were a done deal. Pity they never did go
ahead with a high speed 8-pin. Maybe not cost-effective
or justified compared with something like a 1220 or 675
I ask this question because it indicates the feasibility / desirability of
using some Really Sneaky Tricks (TM) to crunch down the space required. You
run a program on a PC to take your library of strings and compress it (many
different algorithms can be used). This program then outputs a sequence of
DB statements that just look like gibberish. A decompressor written for the
PIC then extracts the data you want. Obviously you need to take into account
the size of the decompression routine to determine if this is a win or not.
Remember, that you have incredibly powerful resources on the PC to crunch
and optimize the data. You just have to do so into a form that can be
cheaply decoded on the PIC.
An example of a compression scheme that has the characteristic that
compression is expensive but decompression is almost free is LZSS.
Another example is one I used to be able to pack about 15 pounds of text
onto a 5 pound floppy disk:
- The basic idea was to crunch the text into a sequence of one and two byte
codes that an interpreter could use to recreate the text. -
The one-byte codes always had the MSBit set, the two-byte codes had it
clear.
Some of the one-byte codes represented short stringns that had a very high
occurance rate in the input data. They were string (not byte) indexes into a
pseudo-array of strings that was stored as one long string with nulls
between the pseudo array elements.
Other one-byte codes were used to indicate runs of a single character, or
the start of a counted string of characters that couldn't be effectively
compressed.
The two-byte codes represented a word and possibly characters following it.
In my particular data, words were nearly always followed by either:
(1) a space
(2) a comma
(3) a comma and a space
(4) the end of a "record"
I represented the four cases above using two bits out of the 16 bits in the
two-byte code. After deducting the top bit that is always clear in the
two-byte codes this leaves 13 bits or 8192 values to indicate a particular
word. These 8192 values Then served as an index into two tables. The first
table defined the offset into a large string (the dictionary) where the word
begain, the second (which was defined as nibbles instead of bytes) deifned
the length of the word. One neat aspect was that the compression program on
the PC could look for ways to nest words in the dictionary. This reduced the
raw size of the dictionary by about 20%. For example: if one of the words
was "internationalize" and others were "interrn', "nation", "national" and
"nationalize" then the latter four could all be embedded n the first one!
"So, this sentence might be coded using the above system as something like
this."
1 byte code indicating that four uncomprssed btyes are to follow:
The uncompressed 4 bytes "So, "
2 byte code for dictionary word "this "
2 byte code for dictionary word "sentence "
2 byte code for dictionary word "might "
1 byte code for common string "be "
2 byte code for dictionary word "coded "
2 byte code for dictoinary work "using"
1 byte code for common string
1 byte code for common string "as "
2 byte code for dictionary word "something "
2 byte code for dictionary word "liike "
2 byte code for dictionary word "this"
1 byte code for common string "."
Thus, this string compresses down from 79 characters to 18 bytes (not
counting resources shared by many strings like dictionary and the pointers
to it and the table of "very common strings"
>> What is a PIC16F89
>
> Dunno, but this looks to have been lifted from a d/s
>
> http://micropic.free.fr/16F89.jpg
>
> Same as an F88 with C0 and C1 in the middle
>
> --
> Already doing that as the LCD display and keypad is remote and it has it's
> own
> PIC16F88, with comms over an RS232 like interface. I send instructions
> like "put
> this string of characters on line 2".
Why not change the interface to "Display strinig 1 on line 2" and store all
your strings in the other PIC.
>> If you can tweak the board how about adding an external serial memory
>> chip? The menus probably won't be accessed often so loading them over a
>> serial link may not be bad?
>
> Not keen on that (hardware wise), but could use on chip EEPROM to store
> some
> strings I guess, but really that would only be a saving of a few hundred
> bytes max.
>
>> you could try the 18F1320, no more instruction words but its 18 series
>> which should be able to do the same C code in less words (and since your
>> coding in C migration to the pic18 core shouldn't be too hard).
>
> Interesting idea... so I did a quick test to try it.
> Compiling for PIC16F88 --> 3669 words (89.6% of 4096 words).
> Compiling for PIC18F1320 --> 3511 words (85.7% of 4096 words).
> Used Hi-Tech PICC and PICC-18 Compilers. Commented out about a dowzen
> lines
> that wouldn;t compile without some tweaking. Not a huge difference in code
> size
> although it does at least tend to confirm that 18F programs can be more
> size
> efficient as one might expect.
>
> Other bit's and pieces... I'm not using floats, printf or any large data
> structures. My
> menu structure is not great but not obese either. The one thing that
> pushed me over
> the top was adding CRC checking for my 1 wire temperature sensors -
> needed it
> because I'm getting the occasional erroneous result. This adds about 300
> program
> words.
>
> Having made some improvements and nips/tucks in other areas I think I will
> keep
> plodding along and get as much code as possible squeeezed in to my
> prototype(s) -
> gotta be working by the end of this week! After that I'll have to look at
> a bigger
> micro, new PCB, seems like there are a few possibilities.
>
> It's a shame I can't find anything about a PIC16F89. A couple of ICE
> vendors make
> pods described as being for PIC16F87/88/89 so perhaps this is something
> scheduled for the future, and just maybe the difference is it has larger
> Flash? Can't
> help the feeling that I've read about it somewhere.
>
> Thanks all for the tips.
> --
> Brent Brown, Electronic Design Solutions
> 16 English Street, St Andrews,
> Hamilton 3200, New Zealand
> Ph: +64 7 849 0069
> Fax: +64 7 849 0071
> Cell: 027 433 4069
> eMail: brent.brownEraseME.....clear.net.nz
>
>
On 28 Aug 2006 at 23:35, Robert Ammerman wrote:
> > Already doing that as the LCD display and keypad is remote and it
> > has it's own PIC16F88, with comms over an RS232 like interface. I
> > send instructions like "put this string of characters on line 2".
>
> Why not change the interface to "Display strinig 1 on line 2" and
> store all your strings in the other PIC.
I guess that's a possibility. So far I've kept the keypad/display unit as much like a
"dumb terminal" as possible, so it's less likely to need firmware updates when things
change. Source code is also easier to read, eg. LCD_Line2("Hello") compared to
LCD_(STRING1, LINE2).
--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail: EraseMEbrent.brownclear.net.nz
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.
--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail: RemoveMEbrent.brownEraseMEEraseMEclear.net.nz
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
I used a form of RLE to save space on a PIC12C672.
It turns out that I had to store IR control codes into a variable-length
table. On a hunch, I
grabbed an 40Khz IR Receiver and stored the bits into 1's or 0's,
captured every 100uS,
then stored into a RAMTRON 32Kx8. I noticed that I could reduce every
code down to
about 10 bytes average, by indicating in a single byte a '1'(+ count
remaining in that state)
or a '0' (+ count remaining in that state). I then squeezed it into an
8-bit simple RETLW table
for each IR code. I was able to store a large set of IR
codes that way.
> 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. You
> run a program on a PC to take your library of strings and compress it (many
> different algorithms can be used). This program then outputs a sequence of
> DB statements that just look like gibberish. A decompressor written for the
> PIC then extracts the data you want. Obviously you need to take into account
> the size of the decompression routine to determine if this is a win or not.
>
> Remember, that you have incredibly powerful resources on the PC to crunch
> and optimize the data. You just have to do so into a form that can be
> cheaply decoded on the PIC.
>
> An example of a compression scheme that has the characteristic that
> compression is expensive but decompression is almost free is LZSS.
>
> Another example is one I used to be able to pack about 15 pounds of text
> onto a 5 pound floppy disk:
>
> - The basic idea was to crunch the text into a sequence of one and two byte
> codes that an interpreter could use to recreate the text. -
>
> The one-byte codes always had the MSBit set, the two-byte codes had it
> clear.
>
>
> Some of the one-byte codes represented short stringns that had a very high
> occurance rate in the input data. They were string (not byte) indexes into a
> pseudo-arry of strings that was stored as one long string with nulls
> between the pseudo array elements.
> Other one-byte codes were used to indicate runs of a single character, or
> the start of a counted string of characters that couldn't be effectively
> compressed.
>
> The two-byte codes represented a word and possibly characters following it.
> In my particular data, words were nearly always followed by either:
>
> (1) a space
> (2) a comma
> (3) a comma and a space
> (4) the end of a "record"
>
> I represented the four cases above using two bits out of the 16 bits in the
> two-byte code. After deducting the top bit that is always clear in the
> two-byte codes this leaves 13 bits or 8192 values to indicate a particular
> word. These 8192 values Then served as an index into two tables. The first
> table defined the offset into a large string (the dictionary) where the word
> begain, the second (which was defined as nibbles instead of bytes) deifned
> the length of the word. One neat aspect was that the compression program on
> the PC could look for ways to nest words in the dictionary. This reduced the
> raw size of the dictionary by about 20%. For example: if one of the words
> was "internationalize" and others were "interrn', "nation", "national" and
> "nationalize" then the latter four could all be embedded n the first one!
>
> "So, this sentence might be coded using the above system as something like
> this."
>
> 1 byte code indicating that four uncomprssed btyes are to follow:
> The uncompressed 4 bytes "So, "
> 2 byte code for dictionary word "this "
> 2 byte code for dictionary word "sentence "
> 2 byte code for dictionary word "might "
> 1 byte code for common string "be "
> 2 byte code for dictionary word "coded "
> 2 byte code for dictoinary work "using"
> 1 byte code for common string
> 1 byte code for common string "as "
> 2 byte code for dictionary word "something "
> 2 byte code for dictionary word "liike "
> 2 byte code for dictionary word "this"
> 1 byte code for common string "."
>
> Thus, this string compresses down from 79 characters to 18 bytes (not
> counting resources shared by many strings like dictionary and the pointers
> to it and the table of "very common strings"
>
> Bob Ammerman
> RAm Systems
>
>
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.
>
> 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
>
> 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 < RemoveMEtwKILLspamtimothyweber.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
> > --
On 8/27/06, Brent Brown <brent.brownSTOPspamspam_OUTclear.net.nz> wrote:
>
> What do you do when you've run out of program space in a PIC16F88? I'm
> looking
> through the Microchip website but can't find anything ideal yet. The
> perfect solution
> would be a drop in pin compatible chip with all the same features but 8K
> words of
> Flash instead of 4K.
> change. Source code is also easier to read, eg. LCD_Line2("Hello")
> compared to
> LCD_(STRING1, LINE2).
>
> --
> Brent Brown, Electronic Design Solutions
With a simple PC-based tool you could generate the code for the slave system
and at the same time generate a header file for the master that would give
you meaningful symbols (#defines) for the strings.
> I've tried four CRC8 routines in Keil C51 for a 8051 core:
Hi Dennis,
Thanks for trying this out. The 30 instruction Keil rendition of the
crc_bits() routine would probably be closer to 20 instructions if the
8051 had a "bit test and skip" type instruction like the PIC.
On Aug 28, 2006, at 9:02 PM, William Chops Westfield wrote:
> PIC12F635 and PIC12F683 seem to be real, and have the nanowatt
> oscillator that goes 8MHz...
>
Hmm. And the f683 (with lead) is on sale at microchip direct,
for cheaper than the 675 sells for normally (despite having more
flash and eeprom as well as the nanowatt clock, timer2, and pwm.)
I think I'll buy some!
> for example if you have English text with 28 letters you can
> store it in 5 bits.
And of course there is a standard 5-bit code that handles most
numerics and punctuation as well ("Baudot"), as well as semi-standard
mechanisms for 6 "symbol" characters in 32bits ("Radix50"); stuff
from the days when mainframes had a whole megabyte of core and
space mattered. It's a common enough problem that developing a
full custom solution is probably something that should only be
done when you're REALLY desparate.
(now, decoding radix50 and writing to an ascii LCD on a processor
without divide might be a good topic for a coding challenge...)
Looks like the PIC16F886 might be available now. I just got a quote from Arrow
showing a lead time of 11 weeks. They are not listed on MicrochipDirect yet.
Points of interest are that they have 8K words of Flash (yeah!), and can run at
8MHz at 2V. Not sure if they lack anything compared to a PIC16F88. It doesn't say
"Enhanced Flash" but apparently can read/write it's own Flash.
--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail: spamBeGonebrent.brownSTOPspamEraseMEclear.net.nz
> > Looks like the PIC16F886 might be available now.
>
> but ww1.microchip.com/downloads/en/DeviceDoc/41287A.pdf
> decsribes it as an 28-pin device, so I don't see how it would help
> somone running out of F88 code space (or at least, not better than a
> 16F876A).
True, I forgot to mention that. It helps me in this case because I'm already using the
PIC16F88 in a 28 pin QFN package, so a PIC16F886 won't take up any more board
space. The PIC16F876A is nice but doesn't have the internal oscillator.
--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail: KILLspambrent.brownspamBeGoneclear.net.nz
>The one thing that pushed me over the top was adding CRC
>checking for my 1 wire temperature sensors - needed it
>because I'm getting the occasional erroneous result.
>This adds about 300 program words.
How often does this code run? Could you set a compiler switch to optimise
for size (but it may run a bit slower) for this section?
> >The one thing that pushed me over the top was adding CRC
> >checking for my 1 wire temperature sensors - needed it
> >because I'm getting the occasional erroneous result.
> >This adds about 300 program words.
>
> How often does this code run? Could you set a compiler switch to
> optimise for size (but it may run a bit slower) for this section?
Executes every 750ms (DS18B22 temp sensor in 12 bit mode). But I've got that
section sorted now thanks. I took out the table driven CRC routine (256 words were
used by the table) and used a full CRC calculator routine... more machine cycles
but much less code space (approx 34 words now).
--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: 027 433 4069
eMail: EraseMEbrent.brownEraseMEclear.net.nz
Yes, Baudot if you have to be compatible :-) but as Baudot code was
organized to have less stress on the TTY writer that is no any sense for the
human (like ASCII uses a human based ABC ordered encoding). But still I
think with 2 * 32 table it can be done without too much effort. If you would
like to avoid those tables (to save space) you have to use ABC orders with
the same principals so that few simple instruction could convert it to
ASCII.
Tamas
On 30/08/06, Alan B. Pearce <@spam@A.B.Pearce@spam@spam_OUTrl.ac.uk> wrote:
>
> >So for example if you have English text with
> >28 letters you can store it in 5 bits.
>
> Oh, you mean like Baudot ... In Brents case he could then have the Baudot
> to
> ASCII translation done in the second chip that controls the LCD ...
>
> -
> >
> > Try this LCD controller:
> >
> > http://www.myke.com/lcd.htm
> >
> > Less code and pins, using just a cheap CI 74LS174.
>
>
> Please explain how serial access to an LCD reduces
> the code size compared to
> full parallel access? I know it reduces the number
> of pins (though I would
> go for a three pin interface with a normal shift
> register, and not Myke's
> two pin interface... I never had much luck with
> that) but in my experience,
> it increases the code size: instead of a simple
> "move data to port, toggle
> enable" you now have to shift each bit separately
> and then toggle enable.
>
> In Brent's case it doesn't really help either, as it
> would still result in a
> redesign of his PCB, which is the thing he is trying
> to avoid.
>
> I do appreciate seeing the old example from Myke
> Predko coming back, though
> (I liked his book a lot).
>
> Greetings,
> Maarten Hofman.
>
> On Aug 29, 2006, at 9:38 AM, Tamas Rudnai wrote:
>
> > for example if you have English text with 28 letters you can
> > store it in 5 bits.
>
> And of course there is a standard 5-bit code that handles most
> numerics and punctuation as well ("Baudot"), as well as semi-standard
> mechanisms for 6 "symbol" characters in 32bits ("Radix50"); stuff
> from the days when mainframes had a whole megabyte of core and
> space mattered.
Errr - when I got my first job on a mainframe (1974) Baudot was already ancient (it was used on teleprinters long before computers) - and that
mainframe had 96k of memory! After a couple of years it was upgraded to 320k - megabytes were only a dream on commercial computers :-)
clear.net.nz
