|Re: i lost my program on my 41cx|
Message #7 Posted by Eric Smith on 10 Dec 2005, 2:36 a.m.,
in response to message #6 by Garth Wilson
That would be a lot of work for no real gain. Writing microcode for the Nut processor is painful, and you don't write any more of it than you have to.
The "file chain" doesn't get corrupted all by itself, so what's the point in having a lot of microcode designed to recover from problems? Writing fancy recovery code would have taken longer to write, and much longer to test thoroughly - you'd have to ensure that for every possible corruption case the recovery code either successfully recovers (so the RAM contents afterward are fully valid), or that it clears memory. It wouldn't be acceptable to have any cases for which the recovery code thought it had recovered successfully, but in fact left any invalid code in memory.
And that's not easy, because it's difficult to fully validate 41 user code. There are many byte sequences that could appear in a program that will cause a crash. It was a non-negotiable requirement of the product design that after a cold start, there can't be any leftover junk in memory that might cause problems.
As it is, they overlooked the effects of possible corruption on one of the warm-start processes, and that made it possible to get an unrecoverable hang from an invalid buffer chain. It would have been better if they'd erred even further on the side of caution, as it would have saved people a lot of time with batteries removed and waiting for the capacitor to discharge. (They solved this by adding a hard reset feature in later versions of the Nut processor.)
I've been an embedded software developer for many years, and I think if I'd been one of the 41C designers I'd have had a hard time selling my manager on spending an extra several weeks to write and even more time to test fancier recovery code for conditions that aren't even supposed to happen. After all, users were supposed to store their programs and data on cards.