Full Reverse Engineering of the TI-84 Plus Operating System

Full Reverse Engineering of the TI-84 Plus Operating System(siraben.github.io)

98 points by siraben 3 hours ago | 13 comments

asveikau 16 minutes ago |

> TI-BASIC programs are stored as tokens, not text: every command, function, and variable is a token of 1 or 2 bytes. The OS detokenizes (token→display string) to show a program and tokenizes (keypress/text→token) on entry; the parser walks tokens to execute.

From my memory of using a TI-83 in the late 90s, I would not be surprised if the keypad UI injects tokens directly based on your keypress, rather than "tokenizing the text". I seem to recall, for example, you could not position the cursor in the middle of a BASIC token, and if you managed to type out the tokens it would not work; you needed to find the right menu item to inject the correct token.

duskwuff 2 minutes ago | |

I can confirm that. On the TI-83, many of the TI-BASIC tokens contained lowercase characters which couldn't be typed at all - you could only type uppercase letters on the keyboard. (There were a few lowercase letters available as tokens for special purposes, but it wasn't a full set.)

analogpixel 2 hours ago |

I couldn't tell, is a person doing this? or was this an LLM dissecting it?

siraben 2 hours ago | |

This was made collaboratively by me directing coding agents at the binary, using Ghidra MCP extensively, disassembly and also dynamic analysis with an emulator. I don't have a writeup of the process but it was definitely not fully automatable (I wish though). I might prepare a blog post with transcripts and session history and things I learned along the way.

Broad takeaways:

- Ghidra MCP is not a silver bullet. Lots of opportunities for mis-decoding especially on older instruction sets (e.g. conflating code + data), which requires user input to flag data layout/structs.

- Agents still need a lot of user direction otherwise the RE production is just kind of a random walk. With Z80 it's decent at reading code but I expect that it has much worse performance than reading x86 or ARM for instance. The TI-84+ has a bunch of hardware quirks as well.

- GPT 5.5 is better than Opus 4.8 at RE. Opus 4.8 loves plausible-sounding RE'd logic without any checking. The gold standard is actually dynamically executing the binary and comparing the logic against the prose.

- Maintaining consistency in style and prose is a PITA across the wiki. Hard to reconcile prose <-> code. Can be somewhat mitigated by agent loops.

Was also in discussions with people in the TI calculator programming space who helped provide guidance as well. We previously did not have a catalogue of every subsystem in TI-OS yet alone most subroutines in the OS.

RgrTheShrubbr 9 minutes ago | | |

Having just recently heard about Ghidra and started using it with Claude. I am absolutely blown away how little resistance it has decompiling old Win95/98 binaries. It's turning into a bit of a hobby of mine to take old software, decompile and find hidden treasures like images or messages.

hedgehog 2 hours ago | | |

Do you have plans to generate a buildable version of the sources, and do you know the original implementation language (C?).

analogpixel 2 hours ago | | |

how much have you spent so far on this (for tokens)?

xkcd-sucks 2 hours ago | |

> Confidence is flagged: .....

> The big picture

> The structural reverse-engineering is comprehensive (every subsystem mapped, both cross-page mechanisms resolved ...

> Confidence summary / open items

Probably an LLM wrote the docs.

> (the GhidraMCP plugin reconnects for interactive work)

Probably LLM+Ghidra for the actual RevEng. Ultimately does it matter if the end product is works though

tadfisher 2 hours ago |

I love that this project produced so much info, and also I'm disappointed with the prose. You probably didn't mean to explain the typographic nuances of em vs. en-dashes to the reader: https://siraben.github.io/ti84p-re/conventions.html#typograp...

siraben 2 hours ago | |

Thanks for the feedback, fixing.