What is your opinion on this change by TI?

We haven't seen them doing something that stupid since the TI signing key legal mess a decade ago. They've truly outdone themselves this time. Throwing their community off a cliff without a warning by removing an advertised feature and deciding that the squeaky toy that is their Python port shall be a replacement of ASM/C, no take-backs.

Vote with your wallet. Don't buy TI. They do not care about anything but money.

From what I could understand, a TI-83 Premium CE python program cannot be larger than 17.7 KB of executable code and there are a few commands that are proprietary rather than actual python.

You'd be lucky to get a Python script bigger than ~5 KiB running. MicroPython scripts on calculators tend to require 2 to 4 times their size in heap in order not to run out of memory.

Turns out there's an easy way to trigger the diagnostics tool: replace the FirstRunApp key value inside FIRSTRUN.INI with \\.\DIAGNOSE.ROM. This file is located inside the PRIME_APP.DAT's FAT32 partition, offset 8192 bytes.

Still no response to keyboard input. The firmware doesn't seem to scan the keypad matrix once booted.

By combining the data part of your image with the firmware bits of an old update file I got something that booted to this:

$ dd if=flash_dump of=dat.raw bs=1024 skip=$((256+1024+4096+32768)) seek=$((256+1024+4096+32768))
It's not responding to the keyboard and the clock on the upper right is hung. The firmware doesn't seem to be hung after a quick look with GDB, but obviously something prevents it from fully ticking. The UART has a whole bunch of yaffs logs, I assume the firmware got stuck because homemade images don't have a yaffs filesystem. I do wonder if the "Format Disk C" option in the diagnostic tools would've fixed that.

Do you happen to know on what pin is the reset switch on the prime?

I assume nRESET. I remember being able to boot the calculator straight into recovery mode by holding the SYMB button down and hooking an USB cable without the battery, so I would expect to be able to drop into the diagnostic tools by holding down C-F-O the same way.

With the emulator, I seem to be able to drop into the recovery (which just hangs with a black screen), but not into the diagnostics program. Odd...

Impressive!

I think really old firmwares don't have the slide-to-unlock at first boot. Might be worth trying one out, I vaguely recall the flash having the following layout: BXCBOOT0.BIN (256KiB) | PRIME_OS.ROM (1MiB) | PRIME_MASTER.DAT (4MiB) | PRIME_APP.DAT (32MiB) | data (remainder). Perhaps you can double-check with your existing image if this matches?

Does the diagnostics tool (C-F-O) work? It's likely to be useful for troubleshooting/reverse-engineering, there's test modes for the touch screen.

I'm not tooled for bus sniffing unfortunately, but maybe I can jury-rig something with a Raspberry Pi. Not going to happen right now though, I'm on vacation and I left my equipment behind...

I checked and I have everything at hand in my flat. I'll perform the hex dumps tomorrow.

Currently no, since Rip'Em can't access the NAND so it's limited by the 1 MiB that BXCBOOT0.BIN loads.

However, with the recently-created, QEMU-based emulator (https://github.com/Gigi1237/qemu) I can now rewrite Rip'Em to include such functionality. If you can use the emulator, you can use its -kernel option to load large ELF files (limited by RAM capacity).

So I took a quick look at your branch and I've already submitted a pull request (mostly just cleanups to make it work on my Linux box).

Soon I'll finally be able to work on Rip'Em without losing my sanity in the process. Yay!

Thanks for giving the link to the UART log, it was helpful. The output qemu is giving me is slightly different: https://gist.github.com/Gigi1237/0a5c3bd41f53bea14434c6673e6f0cbf#file-gistfile1-txt. Mainly becaus it spams me with "B"s right after printing start. I haven't figured out why yet though. Probably some mistake in the UART implementation.

Wow, you've reached PRIME_OS.ROM, that's impressive! That means the first stage of the bootloader actually worked.

Right now I'm a bit stuck with it, don't really know what exactly to do next to get it working. I'm especially in a hard spot because I don't have acess to my IDA Pro databases of both the OS and the bootloader which would help a ton with debugging at this stage.

I would try to make Rip'Em work. Since it's vastly simpler and the source code is available (unlike the official firmware), figuring out why stuff is not working should be much easier. Next goal would be the diagnostics utility.

Today is the last day of my internship, so I'll be able to take a closer look at your QEMU tree real soon^TM.