Device code corruption

[DrD]

Over the course of about a year, I have had several times when the memory state of the device has become corrupt to the extent certain features would not work. This problem is very obscure, because most of the functions still do work properly, and there is no outward sign that anything is wrong.

The latest of this occurred yesterday when a program I was building would run just fine on the emulator but would not work on my physical calc. It turned out there were two predominant problems, one involving the MAKELIST() command, and another involving the length() command. After doing a "C-F-O" ON reset the problems cleared and all was well.

So I am wondering, and it is a bit beyond my knowledge of how practical this might be, but, could the 'normal' state of the machine be captured using a CRC or checksum, and somehow be tracked as a moving target as one uses the calc over time? This way if the CRC, of the firmware changed, for example, it could be a clue that trouble is present, and reset is needed (garbage collection somehow).

I use the help feature a lot. Lord knows, I make a lot of entry mistakes along the way, and perhaps these things conspire to cause this problem, but in any event, I have had to reset the machine too many times to get past problems. It's almost to the point that the 'Debug' feature should just include the 'reset', for use when all else seems to have been tried to no avail.

Maybe the idea of CRC / checksum is too much of a burden to implement, but the calculator seems otherwise almost haunted by a Prime Poltergeist, which, in humble frustration, I suggest: needs exorcised!

-Dale-