When you pull the batteries out of the calculator it shuts off after a secondlr two, if it was in the middle of executing a program the ram resets however if it's at the home screen it doesn't reset. From what I know if the calculator TI-OS is aware that the batteries are missing it creates a checksum of the ram then shuts of. If this happens while executing a program then it probably doesn't get the chance of making the checksum. When the calculator is powered back on, it validates the contents of the ram and resumes if the check completes but clears the ram if the checks fail. I'm looking for a way to have it resume even when the checksum validation fails, even if some of the ram was lost while there was no power.

You are correct about what causes the RAM clear. The calculator does indeed check that checksum on power-on to decide whether to reset or not. The most obvious answer to how to prevent this is to update and store the checksum yourself. Although you could also consider making the calculator skip the checksum check on power-on, that checksum serves an important purpose, so you don't want to do that. If you did, you risk corruption, not to mention the inability to fix your calculator if an ASM program rampages through your memory.

You're almost correct. In the case of pulling the batteries, the TI-OS doesn't have time to properly calculate the checksum (potentially), so instead it stores a special value -- 0A55Ah. It checks for this specific value when turning back on, and if so, it assumes it's correct. Otherwise, it checks the "real" RAM checksum, and if that's not right, it resets RAM.

What you can do is store this value yourself, or you can enable interrupts and set a specific flag that the TI-OS uses for this logic, that way you don't have to do it yourself -- I can't recall what it is off the top of my head, but by disassembling the OS you can find it.

If disabling the checksum check is dangerous, then maybe a way to turn off all non core functions of the calculator like the screen, link, USB. And with all those turned off run the ram on a large capacitor.

The TI-OS also does those things when a battery is pulled. In addition to setting that special RAM checksum value, it turns off the LCD by writing 2 to port 0x10, disables the USB controller by writing 2 to port 0x54, and (I could be wrong, can't remember) disables the I/O link assist via port 0x08.

But what happens when power is completely cut (as in the back-up battery is dead)? Is there a capacitor that gives the OS enough time to do all this before the power dies?

I think an interesting thing would be for, if the checksum is invalid, to prompt the user what they want to do. That way, if they know it's safe to not reset everything, they can say "don't reset". If they're unsure, they can reset.

I agree, is there a way to do this?

That's not a bad idea for an OS patch. Yes, it's do-able.

If the power's completely cut, yes, there's a capacitor (somewhere) that gives the OS enough time to shut down "cleanly." But, since RAM won't be preserved, it's going to reset anyway when you do supply power again.

HP calcs do something like that—after a crash it asks “Try to recover memory?”. It then searches for signatures of various objects and directories and tries to recover them. Needless to say, it's not always successful; often not much gets recovered because the RAM contents is mostly destroyed. The ability to easily save backups to flash and SD cards on recent models makes this a bit superfuous, though.

I'm curious if older models (TI-81, 82, 85, etc.) have the ability to run code for a brief period on power loss too or if they had to use a different approach since they presumably didn't have low battery detection hardware. Has anyone ever explored that?

The ram will be preserved for about 20-40 seconds even after the power is completely cut since the ram is actually a bunch of capacitors. However after the 20-40 seconds the ram will fade off, causing memory loss but if we prompt the user and the user chooses yes, then the calculator can proceed to boot from a slightly damaged ram. That could work if the ram is not badly damaged. It would be interesting to see it try and mend the faded off ram. Also, better some damaged memory than no memory
Heres how a text file stored in ram probably could be after it was damaged.

###ASCII Image###
(Sorry if its terrible, its hard to do ASCII art on the internet for some reason now.)

Code:

Well, I haven't studied much about TI hardware, but I know that most DRAM has to be refreshed every 64 milliseconds in order to guarantee it stays intact. Even when the AAA batteries are pulled out, the little button cell keeps the refresh cycle going on a TI calc. Now, when you yank the AAAs out when the calculator is running, the hardware only provides a few milliseconds of processing time. During TI-OS routines, it can usually use this time to validate RAM. During ASM code execution though, it can't guarantee that the RAM is still safe. This actually benefits the user though. If an ASM program starts an endless loop, you'd want a RAM reset. The TI-OS has decades of testing behind it though, and is guaranteed to get stuck in a never ending loop.

That's a great idea! I'm not surprised that it's not something built into the OS, since it would completely baffle the average end-user, but I think that would be a very nifty OS patch.

I agree too with Kerm and merthsoft, that way you could still reset if an asm prog gets stuck.