Lately I've been playing around with finding ways to check the battery level on my TI-84+SE. Just for fun, I put in some carbon-zinc batteries, which are infamous for not lasting very long. They've been sitting on my desk for way too long and I want to drain them in a non-wasteful way before I dispose of/recycle them. (Don't worry, I am making sure physical leaks aren't happening.) Avg voltage output from all 4 batteries is ~1.45V, according to my multimeter. Anyway, methods of checking the battery level:

Method 1 is by using this code and running it with `Asm(`:

Code:

Then just type `Ans` into the home screen and a value of 0-4 will indicate the battery level. Pretty simple.

Method 2 works by, well, opening DCS 7.4 and checking the battery meter on the bottom right.

The thing is, DCS7 and the little assembly program have different outputs. As of now, the assembly program outputs 4 (100%) and DCS7 is showing what looks like the level just below 100% on the graphical battery meter. What's even more confusing is that the higher I set my display contrast, the lower the battery meter gets in DCS7 when I close and open it again; but the output of the asm program remains the same.

That's... interesting. And it seems there are no comments in source code hosted on the GitHub repository for DCS7 that have anything to do with the battery meter. There's just a single mention, that's in TODO.txt. What is up with the programming behind this seemingly cursed mechanism?

This block from RenderDesktop looks like the battery meter implementation.

Code:

It does just seem to treat the current contrast setting as a proxy for battery level (I believe under the theory that maintaining constant actual contrast as battery voltage drops requires a higher setting), but it doesn't seem very useful.

It does also poll port 2 to check for a low-battery condition:
Code:
I assume your code is also working with port 2, but using the high bits of port 4 (which aren't available on the regular 83+) to improve the resolution beyond 1 bit.

Tari has correctly reversed-engineered the way that Doors CS 7.4 detects battery level. Per Tari's explanation, it uses two separate mechanics for the level of the battery meter and for the low battery pop-up. The former is indeed guessed based on LCD contrast: at least when Doors CS was written, the calculators' LCDs became markedly lighter with depleted batteries, and users would typically adjust their contrast to compensate. The low battery pop-up, by contrast, indeed checks if the lowest bit of Port 02 is set, which indicates low batteries.

Okay, thank you. Thanks Tari as well.

But I'm curious: is it possible to execute the battery checking assembly code inside an Axe program by embedding it? I tried doing it with `Asm(` but the resulting Axe Fusion program unceremoniously crashed.