The Clibs break the Ti-84 Plus CE Python Edition

[leandromaxwell2012-max]

The c libs, probably the graphics ones (graphx and lcddrvce) break the TI-84+CE Python Edition.
anything that does this:
import ti_graphics
when trying to exit, it gets stuck.
here's my mycalcs
somebody tried to tell you: CE-Programming/libraries#48

[adriweb]

I'm not able to repro this here (at least on emu, I'll try on hardware later).

before and after launching a graphx program for the first time, I'm able to import ti_graphics and exit Python just fine.

What are your steps to reproduce the issue exactly, and when/where does it get stuck?

[adriweb]

I made various attempts on a TI-84 Plus CE Python (hw revision S, boot 5.6.1 OS 5.8.4), before and after using some GraphX and lcddrvce programs, and testing the import ti_graphics from the Python app's shell and in a standalone script, and I'm not able to encounter any freeze.

🤷‍♂️

[leandromaxwell2012-max]

On second thought, try importing all of the c libraries.

---

(When I select Cesium's USB thing and then hit cancel, then try to run python, nothing odd happens.
It only uses the following C libraries:

• FATDRVCE
• MSDDRVCE
• USBDRVCE
• and LibLoad.

but…)

---

I first encountered this problem with CEleste when importing all the libraries.
Specifically,

1. I install the C libraries.
2. I get CEleste.
   At this point nothing goes wrong.
   But then i run CEleste, and then close it out, back out all the way from cesium to get to python, (it doesn't matter how you run it) and then run import ti_graphics and:

(pushes 5)

uh wait...
let me try ti_image:

pushes run
prgm ends


and now it's stuck
pushes on

and now it's officially softlocked.
Now, I have to push the reset button in the back, do a Ram reset, and that's it. I just don't use anything that uses the C libraries now. :(

---

I did notice something in Ti-boy about- wait that's it!
v0.3.1 says:

Changed

…

• LCD SPI initialization for Python models now uses a direct method instead of reinitializing all hardware.
  …

Even though it's made using mostly raw assembly code, that must be the problem!
That's enough info now, right? ;)

[calc84maniac]

Just to put my two cents in, my first thought was also the LCD SPI stuff because I had so much trouble with that related to Python models in the past, but LCDDRVCE should be the only library that touches SPI, and both the previous issue and CEleste were created prior to LCDDRVCE's existence, so I think it's probably something else.

[leandromaxwell2012-max]

oh…

[adriweb]

OK, some more AI-assisted automated testing determined it is timing related, as suspected by @calc84maniac in another channel.

Timer 1 is left counting upward. There’s a cleanup gap in the toolchain CRT, exposed by Python’s timer initialization.
CEleste sets bit 9 of F20030 and leaves it set on exit. More significantly, a tiny program containing only clock() does the same—no graphics libraries involved.
Python calls os.SetTimer1, which enables countdown interrupts but never clears that direction bit. Its intended ~100 ms callback then waits roughly 36 hours for upward overflow. Python still receives serial output and ON presses, but its Files/exit transitions stop progressing.

Unfortunately this is in the CRT and not the libs :/

six-byte CRT exit patch:

; Python's Timer 1 waits expect countdown mode.
ld  hl, ti.mpTmrCtrl + 1
res ti.bTmr1CountUp - 8, (hl)

[leandromaxwell2012-max]

So how do I fix it?
I reset the calc already
but how do I add that to CEleste
do I add a pull request or something