Inside the TI-84 Plus: A Complete Reverse Engineering of Its Z80 Operating System

The TI-84 Plus has been sitting in classrooms since 2004, quietly running a proprietary Z80 operating system that Texas Instruments never fully documented. A new open reverse-engineering project by siraben changes that: a complete, structured teardown of ti84plus.rom (OS version 2.55MP) covering every major subsystem, published as a navigable mdBook with a companion Ghidra project.

For systems programmers, this is a rare complete picture of a real-world embedded OS — paging schemes, syscall dispatch, memory management, and a BCD floating-point engine — all on hardware constrained to 64 KiB of visible address space at a time.

The Core Problem: 64 KiB Windows into 1 MiB of Flash

The Z80 has a 16-bit address bus. That means any one moment the CPU can only see 64 KiB of memory. The TI-84+ ships with 1 MiB of flash and 128 KiB of RAM. Bridging that gap is the central engineering problem the OS must solve.

The solution is a 4-slot paging scheme controlled via hardware I/O ports 6 and 7. Flash is divided into 16 KiB pages (64 pages total), and up to four of them can be mapped into the logical address space simultaneously. Flash page 0 is permanently mapped at the low end and holds the boot/kernel core — the code that can never be paged out. Everything else — the bulk of OS routines — lives on the remaining pages and is reached through a mechanism called bcall.

ROM layout is documented page-by-page. Notable: most boot bcall bodies live on page 3F, while USB boot routines (_AttemptUSBOSReceive, _ReceiveOS_USB, _InitUSB, _KillUSB) reside on page 2F.

The bcall Mechanism: A Single-Instruction Syscall ABI

The bcall system is the OS's entire cross-page calling convention. It's invoked via rst 28h — a single-byte Z80 restart instruction — followed by a 2-byte call number. The dispatcher looks up that number in a jump table and handles the page switch before transferring control to the target routine.

Two jump tables are documented:

• Main bcall table at 0x4xxx — the primary OS API surface
• Retail boot bcall table at 0x8xxx — boot-layer routines with TI-OS type annotations

The full alphabetical bcall index is one of the most practically useful outputs of the project: a reference for every system call with confirmed or inferred signatures, covering display, keyboard, link, math, VAT access, and more.

For homebrew developers and shellcode authors alike, understanding that every cross-page call flows through this single dispatch path has major implications for both capability and attack surface.

The Four Pillars of the OS

The project identifies four subsystems that everything else is built on:

1. Paging + bcalls

Covered above. The interaction between port-mapped page registers and the bcall dispatch table is the bedrock of the whole system.

2. The Floating-Point Engine

All arithmetic on the TI-84+ runs through a 9-byte BCD (Binary Coded Decimal) format stored in six named registers: OP1 through OP6. Real and complex numbers are both represented this way. The engine handles transcendental functions, formatting, and error propagation. Notably, the project documents not just the data format but the calculation engine's handling of edge cases and the paths through which errors bubble up.

Using BCD rather than IEEE 754 binary floats is a deliberate design choice for a calculator: it avoids the class of decimal representation errors that would be visible to a student checking their arithmetic by hand.

3. The Variable Allocation Table (VAT)

Named objects — reals, lists, matrices, strings, programs, appvars — are catalogued in the Variable Allocation Table. The project documents object types, the layout of VAT entries, and how Sto/Rcl map to underlying VAT operations. It also covers the flash archive: variables can be archived to flash (making them read-only but persistent across RAM resets), and flash garbage collection is documented as part of the memory management subsystem.

4. The Tokenizer and TI-BASIC Parser

TI-BASIC programs are not stored as text. They're stored as 1- and 2-byte tokens. The project documents the token tables and traces through how the parser executes them — a token-dispatch interpreter rather than a compiled or tree-walking design. The deep-dive docs include fixture traces, a smoke runner, and coverage anchors for testing.

Memory Management and the RAM Layout

Beyond paging, the project documents the fixed RAM region that holds live system state: flags, FP registers (OP1–OP6), display buffers, and the VAT. A dedicated chapter covers the RAM heap, VAT/userMem boundary, and flash archive GC.

RAM paging gets its own treatment as well — including RAM page 83 and the rules for saving and restoring page state. The IM1 interrupt service routine (ISR) handles timers, the automatic power-down (APD) feature, cursor blinking, and the ON key, and is fully documented including the conditions under which it fires and what state it touches.

Methodology and Confidence Flags

One of the more rigorous aspects of the project is its explicit confidence tagging system:

This discipline — clearly distinguishing what's been proven from what's been assumed — makes the notes genuinely useful as a reference rather than just interesting to read. The 99-open-questions.md file is a prioritized roadmap of what remains to be confirmed.

The tooling is reproducible: the Ghidra project (ti84.gpr) is included and the full analysis can be rebuilt with tools/build.sh.

Why It Matters Beyond Nostalgia

This isn't purely a retro computing exercise. The patterns here — a paged address space with a software dispatch layer for cross-segment calls, a fixed syscall ABI on top of a single-tasking monitor, BCD arithmetic for human-visible precision — show up in embedded and constrained environments across the industry. The TI-84 Plus just happens to be a clean, self-contained instance of all of them.

For practical purposes:

• Homebrew/app developers get the most complete bcall reference ever assembled
• Security researchers get a documented attack surface: the bcall dispatch, the VAT parser, and the link/USB transport layer are all mapped
• Embedded systems engineers get a case study in making 64 KiB feel like 1 MiB without an MMU
• Toolchain authors can use the token tables and parser traces to build better TI-BASIC tooling

The project is structured as a browsable mdBook and is actively expanding — the sub-* deep-dive documents cover statistics, matrix operations, the numeric solver, equation display, and the link protocol. It's the most complete public documentation of this OS that exists.