i lost my program on my 41cx


i lost a valuable program on my 41cx whan i left it too long without charging the battery. is there anyone who knows how to get it back or is it lost forever. boo hoo it was a very trusty sun shot program for surveyors navigation.



if you get something like

you certainly lost it for good. There is no way to recover it from the calculatorĀ“s memory once it is cleared. Is there any chance that yo have a listing with the program contents? If so, chances are you can key it back in.

Let us know.

Best regards.

Luiz (Brazil)

Edited: 8 Dec 2005, 6:21 p.m.



Try this forum, maybe you will be able to inquire as a guest. Membership is open I think.

Anyway, there is a section on Astronomy and navigation which might have a member with your program or one in another language you might easily transform into your own 41cx. There are other sections in various applied math which might interest you.

Good luck,



I expect that even the "Memory lost" message indicates only that the calculator couldn't make sense of the file chain, and only re-initialized it but did not write over everything. One way to find out would be to use the RAM editor in the Zenrom module. It would be kind of a big job to make sense of what you find though, even if significant parts of the program are still intact.


When it says "MEMORY LOST", it has zeroed all of main memory. It's a defensive measure; if the memory doesn't look valid it could contain any random junk that could cause a crash later.

The code that does this is at label "coldst" at line 809 of cn0b.asm.
In fact, it looks like the code will zero extended memory too. Sigh.


That's amazing that they would do that. It's totally unnecessary. I haven't gotten into HP-41 Mcode and other internals (except for a small level of synthetic programming), but I've designed and used file chains in RAM on small embedded computers based on what I understood to be happening in the HP handhelds. Instead of using a FAT, I had a header at the beginning of each file, and the header included information on how long the file is so the OS can link to the beginning of the next file to find it, and so on. The location pointed to by the last link should equal the address pointed to by a system variable telling where the .END. byte is, and that address should contain the .END. byte value. Every file except the first one should be immediately preceded by the END byte of the previous file. There is a system variable telling how many files there are, so the OS can check and see if it finds that many, all ending with an END byte, before reaching the .END. byte. The file-length record in the header may be changed and the rest of the chain was scooted up or back and the expected address of the .END. byte changed as necessary when you edit the file. It worked great. Beyond this info, the embedded computer's routine that checked the file chain integrity didn't care what was in a file, so long as it could make sense of the chain and find the right number of files with all their END bytes, and finally the .END. byte at the expected location. This constitutes several safeguards to be sure the file chain is good even if there could be a problem in one file that does not affect any others and should not be a cause to wipe them all out. If there was a file chain problem (which in the final product only resulted from removing the batteries for too long), it would just reset the number of files to 0, and store the .END. byte where the first file would start. The rest of the memory was untouched, and its contents didn't matter to the computer. This worked out well during debugging in the development since I was able to quickly pick through and reconstruct the file chain and recover the information. (We're definitely not talking about tens of thousands of files like you get on a desktop computer.)

Edited: 9 Dec 2005, 2:37 p.m.


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.


I never wrote any recovery code. I picked through the headers by hand a couple of times only in the debugging, which didn't take more than a few minutes when there were probably less than six files there. The computer only looked at header bytes and the end-of-file and end-of-chain bytes, plus the two variables telling how many files it should find and what the address of the .END. should be; and this was only to determine the integrity of the chain. It took about 40 lines of assembly code. If something there didn't make sense there, it re-initialized the chain by writing into the one variable that there were no files, and into the other variable that the address of the .END. byte would be where the first file will start, and it wrote the .END. byte there. This all took 8 lines of assembly code. It did not do anything else to any other memory locations, and it didn't care what was in the old file space. It's like deleting files on a disc and just marking the space available instead of completely re-initializing every sector that a file had used before being deleted. There's simply no reason to write over those sectors unless you're trying to keep enemies from getting some data off a computer they've captured.


Sure, but you only get to the MEMORY LOST code if it has detected a serious problem. So at that point it can't be assumed that any of the memory contents are valid. Aside from clearing all memory (which is what they do), the only way to guarantee that memory doesn't contain nasty stuff that can cause a serious crash later would be to do some sort of validation process on *everything*, not just the END chain.

That validation of everything is what I am claiming would require much work to write, and even more to debug.


the only way to guarantee that memory doesn't contain nasty stuff that can cause a serious crash later
If it ever gets there to try execute those bytes, it has already crashed.

Possibly Related Threads…
Thread Author Replies Views Last Post
  More Prime problems - lost Apps key again Michael de Estrada 10 2,989 11-16-2013, 12:46 PM
Last Post: Michael de Estrada
  HP Prime: run a program in another program Davi Ribeiro de Oliveira 6 2,687 11-11-2013, 08:28 PM
Last Post: Davi Ribeiro de Oliveira
  Lost formulas David Goldstein 5 1,996 05-08-2013, 03:39 AM
Last Post: Katie Wasserman
  [41CL] Rescue from 'Lost Y Functions' Dan Grelinger 18 4,368 02-16-2013, 02:08 PM
Last Post: Diego Diaz
  Package lost-stolen Artur-Brazil 12 3,011 03-22-2012, 12:29 PM
Last Post: Antonio Petri (UK)
  Lost parcel? Matthias Wehrli 12 3,322 02-29-2012, 02:18 AM
Last Post: Nick_S
  41CV Fullnut shows "Memory Lost" consantly John Robinson 7 2,213 05-27-2011, 05:51 PM
Last Post: John Robinson
  Wp34s: word size lost? Cristian Arezzini 5 1,760 05-26-2011, 12:29 AM
Last Post: Cristian Arezzini
  Re: The lost formula Csaba Tizedes (Hungary) 5 1,860 01-26-2011, 05:59 AM
Last Post: Csaba Tizedes (Hungary)
  Re: The lost formula John B. Smitherman 11 2,868 01-18-2011, 08:47 PM
Last Post: Dan W

Forum Jump: