4 ms·

Full Reverse Engineering of the TI-84 Plus Operating System

149 points by siraben 4mo ago

analogpixel 4mo ago
I couldn't tell, is a person doing this? or was this an LLM dissecting it?
- xkcd-sucks 4mo 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
  - markus_zhang 4mo ago
    I think it’s fine as long as it works. Personally I prefer doing everything manually because that’s where the fun is, but everyone has their own fun.
- deleted 4mo ago
  [deleted]
- siraben 4mo 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.
  - analogpixel 4mo ago
    how much have you spent so far on this (for tokens)?
    - siraben 4mo ago
      The plans are heavily subsidized by the AI companies so I didn't end up needing to do API usage or buy another subscription. I have ChatGPT Pro and Claude Code Max.
      - xyst 4mo ago
        [flagged]
        vitally3643 4mo ago
        That's not at all how that works
  - deleted 4mo ago
    [deleted]
  - hedgehog 4mo ago
    Do you have plans to generate a buildable version of the sources, and do you know the original implementation language (C?).
    - siraben 4mo ago
      It's highly likely that the original implementation language was assembly. The code is very idiomatic. Regarding source build, I think reverse engineering it to the point where you can reconstruct the source is possibly legally problematic, so I don't plan to do this, but maybe for certain subsystems like MathPrint (equation display) which was especially fun to RE. I have a PR up for it and it will be live at https://siraben.github.io/ti84p-re/mathprint https://siraben.github.io/ti84p-re/mathprint
tadfisher 4mo 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#typography https://siraben.github.io/ti84p-re/conventions.html#typograp...
- siraben 4mo ago
  Thanks for the feedback, fixing.
asveikau 4mo 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 4mo 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.) Interestingly, you could print tokens in strings - e.g. you could Disp "Disp ".
  - suburban_strike 4mo ago
    The 83+ let you type the full set of lowerchase chars as well, but they used 2x as many bytes per character for storage.
  - 7jjjjjjj 4mo ago
    There's actually a hidden lowercase feature, you can use an assembly program to enable it.
- siraben 4mo ago
  Yes, to type a TI-BASIC program you have to go through the calculator menus which directly insert the tokenized input into the buffer. The weird thing about TI-BASIC is how seemingly innocent changes in the input can cause huge performance regressions e.g. https://siraben.github.io/ti84p-re/sub-tibasic-for-paren.html https://siraben.github.io/ti84p-re/sub-tibasic-for-paren.htm... For(I,1,N If 0 1 End is much slower than For(I,1,N) If 0 1 End
thwgrw 4mo ago
I am sure you did a lot of hardwork here. But with all the LLM smell in the text, my mind zoned out after few lines. I'd rather read a flawed but human written text than a perfect one written or co-written with an LLM.
boricj 4mo ago
Isn't the information in this already largely known and documented? There have been over 30 years of tinkering, reverse-engineering work and assembly programs on the (e)z80 TI graphing calculators. Incidentally, that lineage has finally come to an end as TI has released the TI-84 Evo-T, which uses an ARM Cortex-M core and a firmware apparently rewritten from the ground up.

149 points by siraben 4mo ago

analogpixel 4mo ago

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

xkcd-sucks 4mo 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
- markus_zhang 4mo ago
  I think it’s fine as long as it works. Personally I prefer doing everything manually because that’s where the fun is, but everyone has their own fun.
deleted 4mo ago
[deleted]
siraben 4mo 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.
- analogpixel 4mo ago
  how much have you spent so far on this (for tokens)?
  - siraben 4mo ago
    The plans are heavily subsidized by the AI companies so I didn't end up needing to do API usage or buy another subscription. I have ChatGPT Pro and Claude Code Max.
    - xyst 4mo ago
      [flagged]
      - vitally3643 4mo ago
        That's not at all how that works
- deleted 4mo ago
  [deleted]
- hedgehog 4mo ago
  Do you have plans to generate a buildable version of the sources, and do you know the original implementation language (C?).
  - siraben 4mo ago
    It's highly likely that the original implementation language was assembly. The code is very idiomatic. Regarding source build, I think reverse engineering it to the point where you can reconstruct the source is possibly legally problematic, so I don't plan to do this, but maybe for certain subsystems like MathPrint (equation display) which was especially fun to RE. I have a PR up for it and it will be live at https://siraben.github.io/ti84p-re/mathprint https://siraben.github.io/ti84p-re/mathprint

tadfisher 4mo 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#typography https://siraben.github.io/ti84p-re/conventions.html#typograp...

siraben 4mo ago
Thanks for the feedback, fixing.

asveikau 4mo 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 4mo 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.) Interestingly, you could print tokens in strings - e.g. you could Disp "Disp ".
- suburban_strike 4mo ago
  The 83+ let you type the full set of lowerchase chars as well, but they used 2x as many bytes per character for storage.
- 7jjjjjjj 4mo ago
  There's actually a hidden lowercase feature, you can use an assembly program to enable it.
siraben 4mo ago
Yes, to type a TI-BASIC program you have to go through the calculator menus which directly insert the tokenized input into the buffer. The weird thing about TI-BASIC is how seemingly innocent changes in the input can cause huge performance regressions e.g. https://siraben.github.io/ti84p-re/sub-tibasic-for-paren.html https://siraben.github.io/ti84p-re/sub-tibasic-for-paren.htm... For(I,1,N If 0 1 End is much slower than For(I,1,N) If 0 1 End

thwgrw 4mo ago

I am sure you did a lot of hardwork here. But with all the LLM smell in the text, my mind zoned out after few lines. I'd rather read a flawed but human written text than a perfect one written or co-written with an LLM.

boricj 4mo ago

Isn't the information in this already largely known and documented? There have been over 30 years of tinkering, reverse-engineering work and assembly programs on the (e)z80 TI graphing calculators. Incidentally, that lineage has finally come to an end as TI has released the TI-84 Evo-T, which uses an ARM Cortex-M core and a firmware apparently rewritten from the ground up.