TI-84 Plus OS — Reverse-engineering notes: system overview

Target: ti84plus.rom (1 MiB flash dump). OS self-identifies as 2.55MP. CPU: Zilog Z80 (16-bit address bus, 64 KiB logical space) with hardware flash/RAM paging. Ghidra project: ti84.gpr (rebuild: tools/build.sh).

Confidence is flagged: [confirmed] = verified in disassembly/decompiler; [standard] = matches documented TI-83+/84+ architecture and is consistent with the disassembly; [hypothesis] = inferred, not yet verified.

The big picture

The TI-84+ is a Z80 machine that can only see 64 KiB at once, but has 1 MiB of flash and 128 KiB of RAM. It bridges that gap with a 4-slot paging scheme and a system-call (“bcall”) mechanism that lets code on one 16 KiB flash page call routines on any other page. The OS is a single-tasking monitor: a boot/kernel core on flash page 0 (always mapped low), a large body of OS routines spread across the other flash pages and reached via bcalls, and a fixed RAM region holding the system state (flags, floating-point registers, display buffers, the variable table).

Everything the user interacts with — the homescreen, TI-BASIC programs, graphing, the catalog — is built on four pillars:

1. Paging + bcalls — how code and data beyond 64 KiB are reached. (see 02-paging.md, 03-bcall-mechanism.md)
2. The floating-point engine — 9-byte BCD reals/complex in the OP1–OP6 registers; all math flows through these. (06-floating-point.md)
3. The variable system (VAT) — named objects (reals, lists, matrices, strings, programs, appvars…) catalogued in the Variable Allocation Table. (05-variables-vat.md)
4. The tokenizer/parser — TI-BASIC is stored as 1- and 2-byte tokens; the parser executes them. (07-tokenizer-basic.md)

Around those sit the I/O subsystems: the IM1 interrupt that drives timing/APD/cursor/ON-key (04-interrupts.md), the LCD driver, the keypad scanner, and the link port.

Subsystem index

Each row maps a documentation page to the subsystem it covers and its analysis status.

(The sub-* docs are deep dives covering user-facing functionality and I/O internals: calculation, graphing, TI-BASIC, VAT/archive, apps, stats, matrices, solver, table, equation display, link, and USB/link assist.)

New to these notes? Start with Conventions & Methodology (how to read the addresses and confidence flags) and the Glossary; the bcall Index is the full alphabetical system-call reference.

The main 0x4xxx bcall table and the retail boot bcall table (0x8xxx, from the local complete ROM) both carry TI-OS types. Most boot bcall bodies are on page 3F; USB boot routines such as _AttemptUSBOSReceive, _ReceiveOS_USB, _InitUSB, and _KillUSB are on page 2F. Rebuild: tools/build.sh.

10 — Subsystem map (bcall API surface)

This page categorizes the ~600 named bcall entry points (the OS’s public API) by subsystem, so the whole OS surface is visible at once. This is the surface area user code and the OS itself program against.

(Counts approximate — keyword buckets overlap; ~170 “misc” are mostly more math/int helpers.)

Reading the map

The dominant fact: this is a calculator — roughly two-thirds of the API is numeric. Everything else is comparatively small glue. The architecture flows:

flowchart TD
    KP([keypad]) --> GK["_GetKey"] --> P[parser] --> TD[token dispatch]
    TD --> VAT["VAT · _FindSym<br/>variables"]
    TD --> FP["FP engine · OP1..6<br/>arithmetic / transcendentals"]
    TD --> DISP["display · _PutMap<br/>homescreen / graph"]
    VAT --> R["result in OP1<br/>shown via _DispOP1A / _PutS"]
    FP --> R
    DISP --> R

Cross-cutting services used by all of the above: bcall/paging (03), interrupts/APD (04), error handling (_JError + TIError codes), and the system flags (SystemFlags @ flags).

How the pieces connect (the through-line)

1. Interrupt keeps time, scans the keypad into kbdScanCode, runs APD.
2. _GetKey turns scan codes into key codes (TIKeyCode), driving menus and the homescreen.
3. The parser reads tokenized input/programs, dispatching each TIToken.
4. Number tokens → FP engine (OP1–OP6, BCD); name tokens → VAT (_FindSym).
5. Results land in OP1 and are rendered by the display subsystem.
6. bcall + paging is the substrate that lets steps 3–5 live on different flash pages; errors unwind via _JError/onSP.

See per-subsystem docs 01–09 for detail.

Conventions & methodology

How to read these notes, and how they were produced.

Suggested reading order

1. Overview — the four pillars and the system through-line.
2. Subsystem map — see the whole API surface at once.
3. Substrate: Memory map → Paging → The bcall mechanism → Interrupts.
4. Pick a core subsystem (Floating-point, VAT, Tokenizer/TI-BASIC, Display…), then its feature deep-dive (sub-*).
5. Glossary for any unfamiliar term.

Address notation

• pp:addr — flash page pp (00–3F), logical address addr. Banked pages run in the 4000–7FFF window, so e.g. _PutS at 01:5C39 means page 1, address 0x5C39. Example: 3D:6745.
• ram:addr — page 0 (the always-mapped kernel) and the RAM window; Ghidra keeps page 0 in its ram space, so ram:229E ≡ 00:229E.
• Ghidra’s overlay space writes flash addresses as page_pp:addr (e.g. page_38:4000); the wiki normalizes these to the short pp:addr form, so page_38:4000 is written 38:4000.
• A bare 0x…. (no page) is a RAM data address or an unpaged value (e.g. flags 0x89F0, the bcall-ID ranges 0x4xxx/0x8xxx, a page number like 0x3B).
• bcall ID ≠ address. A bcall has an ID (the 2-byte word after rst 28h, e.g. _FindSym = 42F4h) and a body address (00:0E65). The ID indexes the jump table; it is not where the code lives.

Confidence flags

Every non-obvious claim is tagged:

Some early deep-dive docs use shorthand [C]/[H]/[I] ≈ [confirmed]/[standard]/[hypothesis]; read them against this three-tier scheme.

Function naming

• _CamelCase — an official TI bcall/equate name (from ti83plus.inc, the full 2007 TI-83 Plus SDK equates file, or the TI SDK), e.g. _FindSym, _FPAdd. High confidence.
• snake_case — a name inferred during this RE from a routine’s behavior (which named routines it calls, which RAM/ports it touches), e.g. findsym_scan, fp_normalize. Accurate in aggregate; any single low-level helper name is a best-effort guess.

Math notation

Formulas are written in LaTeX and rendered by KaTeX (offline, client-side): $…$ for inline math and $$…$$ for display. Algorithms render as pseudocode blocks and data/control-flow diagrams as Mermaid.

How this RE was produced

• The Ghidra database is rebuilt from the ROM by tools/build.sh (a 10-stage headless pipeline). It loads all 64 flash pages (page 0 + overlays at 4000), then resolves and names routines from the main OS bcall table.
• bcall table resolution. The main jump table page was found by scoring all 64 flash pages: for each candidate, count how many of the known bcall IDs produce a valid (addr, page) entry. Page 0x3B scored highest for the 0x4xxx table — more known bcall IDs resolve to a valid (addr, page) entry there than on any other page — and is confirmed by the documented RST shortcuts (all six matched) and by every entry resolving and live-confirming once 0x3B is applied. 0x8xxx bcall IDs index a retail boot table on page 3F (with the USB boot entries on retail page 2F). This rom.bin is a BootFree image — page 3F carries the BootFree prefix 3E 3F D3 06 … and page 2F is blank (all FF) — so these 0x8xxx body targets do not resolve and are left unnamed (tools/bcalls8x_targets.txt has no body rows); only their SDK equate names are known.
• Decompiler caveats. Ghidra’s Z80 decompiler mis-renders some idioms — SET b,(IY+d) flag ops, the CALL cross_page_jump (ram:2B09) trampolines, and register-passed arguments on banked pages. Where the decompiler is unreliable the notes are grounded in the raw disassembly (and several deep-dives used a small custom Z80 decoder over the ROM to verify addresses byte-exactly).
• Parallel multi-agent passes. The feature deep-dives (sub-*) and the final 100%-naming pass were produced by multiple agents working on isolated copies of the database, each owning a disjoint set of pages, then merged.

See the repository README.md for the exact build pipeline and tooling.

Glossary

Quick definitions for the terms and key RAM symbols used throughout this wiki.

Core concepts

Floating point

Variables & memory

Registers & RAM symbols

Conventions

• Addresses: written pp:addr where pp is the flash page (00–3F) — e.g. 3D:6745. Page 0 (the always-mapped kernel) is also written ram:addr since Ghidra keeps it in the ram space. A bare 0x…. with no page is a RAM/data address. See Conventions.
• bcall IDs vs addresses: a bcall has both an ID (the 2-byte value after rst 28h, e.g. _FlashToRam = 5017h) and a body address (3D:6745). The ID is not an address.
• Confidence flags: [confirmed] (seen in disassembly), [standard] (matches documented TI-83+/84+ behavior), [hypothesis] (inferred). See Conventions.
• Function names: official TI bcalls are _CamelCase (_FindSym); RE-inferred names are snake_case (findsym_scan).

01 — Memory map

The Z80 sees a flat 64 KiB logical space, divided into four 16 KiB slots. Hardware paging (ports 6/7) decides which physical flash page or RAM page is visible in the two middle slots. See 02-paging.md for the banking detail and 14-ram-pages.md for RAM page 83 and restore rules.

Logical address space (what the Z80 sees)

In this OS the system RAM variables all live at 8000+, so the static RE model treats 8000–FFFF as one RAM block (see tools/BuildTI84Full.java).

Flash layout (physical, 1 MiB = 64 × 16 KiB pages)

Pages 01–3F are loaded in Ghidra as overlays page_01 … page_3F (each at 4000). Goto e.g. 01:5b4c for _PutC.

The assembled tools/rom.bin (the Ghidra build input) is a BootFree image — pages 2F and 3F are blank or BootFree-substituted there. The 2F/3F rows above describe the retail USB/boot content from the local D84PBE2.8Xv / D84PBE1.8Xv segment files (the page-3F retail boot is also applied in ti84plus_patched.rom); those bodies are byte-decoded from those files, not from rom.bin.

Key RAM regions (named & typed)

IY is held at flags (0x89F0) almost everywhere, so (IY+off) accesses index SystemFlags fields (appFlags, kbdFlags, …).

Principal I/O ports [standard, cross-checked vs code]

A curated selection of the ports most relevant to the memory map and paging; the kernel touches many more (timer/crystal, USB-assist, and ASIC-control ports).

02 — Memory paging

The Z80’s banked 16 KiB slots are windows onto physical memory selected by I/O ports.

0000–3FFF is hardwired to flash page 0. C000–FFFF is RAM in the static OS model and is normally the stack/user-RAM window; the 84+ hardware banks the high RAM slot through MemC/port 5. The dynamic trace in RAM pages confirms port-5 restores to RAM page 80 during normal OS execution. [confirmed]

How code uses it

• bcalls to a paged body set port_mapBankA (port 6) to the target routine’s page, run it at 4000+, then restore the previous page; bcalls whose body lives on page 0 run it in place below 4000 (e.g. _JErrorNo→00:2799). See 03-bcall-mechanism.md. The helper ram:181c is the page-set primitive used by the dispatcher.
• A routine that runs banked into 4000 must therefore be written position-fixed for 4000 — which is exactly why every overlay page in Ghidra is based at 4000.
• cross_page_jump (ram:2b09) is the common cross-page jump trampoline: many page-0 entries and inline OS calls use it with a following .dw addr; .db page payload to reach a body on another page. [confirmed]

Modeling in Ghidra

Each physical flash page 1–63 is an overlay block page_NN based at 4000, so the same logical 4000–7FFF window exists once per page without collision. Bank B/RAM is the single RAM block 8000–FFFF. This loses the runtime “only one page visible” semantics (intentionally) so all code is statically present.

03 — The bcall system-call mechanism

This is the heart of how the OS spans 1 MiB with a 64 KiB CPU. A routine on any page calls a routine on any other page by bcall without knowing where it physically lives.

The call site

RST 28h          ; opcode 0xEF
.dw  <bcall_id>   ; 2-byte little-endian ID immediately after

rst 28h is a 1-byte Z80 call 0028h. So the return address pushed on the stack points at the 2-byte ID. The dispatcher reads the ID through the return address, then fixes the return to skip those 2 bytes — i.e. execution resumes at call_site + 3. [confirmed] (modeled in Ghidra by setting each rst 28h’s fall-through to +3 and typing the ID as a word.)

The dispatcher — bcall_dispatcher @ ram:2a2f [confirmed]

From the decompiler:

1. Read the 2-byte ID dw from the caller’s return address.
2. Decode the ID’s high bits: bit15/bit14 select the address class; the low bits form the table offset.
3. Bank the bcall table page into slot A (via the helper at ram:181c, which sets port_mapBankA).
4. Read the 3-byte table entry: target address (2) + target page (1).
5. Bank the target page into slot A (port_mapBankA = page), save the previous page.
6. call the target. On return, restore the previous page and resume the caller at +3.

The jump table — flash page 0x3B [confirmed]

• Located at the start of physical flash page 0x3B (file offset 0x3B*0x4000 = 0xEC000).
• 3-byte entries: addr_lo, addr_hi, page. IDs step by 3 from 0x4000, so entry for ID X is at table offset X-0x4000.
• Resolution method (tools/ Python): scored all 64 pages by how many of the named .inc IDs produced a valid (addr∈4000..7FFF or page-0, page<0x40) entry; page 0x3B scored highest (the page-selection heuristic uses a conservative validity filter chosen only to pick the table). Once 0x3B is selected and applied, all 535 .inc IDs plus 61 RE-named entries (596 total) resolve and are live-confirmed.
• Validation: known bcalls land exactly where expected — _PutS→01:5C39, _GetKey→06:491E, _ClrLCDFull→01:60E4, _GetCSC→00:04B2, _CreateReal→00:10B8.

tools/bcall_targets.txt holds 596 resolved main-table bcall rows. tools/bcalls8x_targets.txt holds the retail boot-table (0x8xxx) rows only when the local ROM has the retail page 3F and USB support page 2F installed; with the checked-in BootFree rom.bin it has no body rows — only skip comments (the resolver refuses to emit 0x8xxx bodies from a BootFree-substituted page 3F). tools/ApplyBcalls.java disassembles and names the confirmed bodies it can resolve.

Jump-table ID ranges

The dispatcher (bcall_dispatcher) decodes the ID’s top two bits to pick the table page: bit 15 set → page-byte 0x7F (masked & 0x3F → page 0x3F); bit 14 set → 0x7B (→ page 0x3B); with neither bit set it falls through to lookup_bcall_table_page (ram:2ADA). The two tables real bcall IDs use:

• 0x4xxx–0x7FFF (bit 14 set): the main table on flash page 0x3B, entry at offset ID − 0x4000 (596 live-confirmed bcalls: 535 from the .inc + 61 RE-named).
• 0x8xxx (bit 15 set): the retail boot table is on physical page 3F, indexed by ID & 0x7FFF. D84PBE1.8Xv supplies the retail page 3F; D84PBE2.8Xv supplies the companion USB boot support page 2F. Most entries resolve to 3F:addr; USB entries such as _AttemptUSBOSReceive (80E4) and _InitUSB (8108) resolve to 2F:addr. tools/resolve_bcalls.py refuses to emit these targets from a BootFree-substituted page. [confirmed]

Both resolved table formats are 3-byte entries: target address (little endian) plus page byte masked with & 0x3F.

RST shortcuts (fast inlined bcalls) [confirmed]

Five of the RST vectors are 1-byte fast paths for the hottest routines (each JPs to its page-0 handler, which is also reachable as a bcall — the table maps the same address). rst 28h is the bcall dispatcher itself (not a shortcut, and ram:2A2F is not a bcall target); it is listed here only to complete the vector set:

All six match the documented TI-83+/84+ RST assignments — strong cross-confirmation of the table resolution.

bjump — the sibling mechanism (OS-internal cross-page calls)

Besides bcalls, the OS calls its own cross-page routines via bjump: CALL cross_page_jump (= CALL ram:2B09) followed inline by .dw addr; .db page. cross_page_jump reads the stacked return address (its caller’s, via an SP-relative load — it does not POP it), fetches the 2-byte target + 1-byte page from the inline descriptor there, rewrites the return frame past those 3 bytes, banks the page (& 0x3F), and returns into the target. The target’s RET then returns to the bjump’s caller, so it behaves like a call that consumes the 3 inline bytes.

There is a trampoline table in the page-0 address range ram:3B01–ram:3D0A: 87 packed 6-byte entries, each a bjump to a hot OS routine on another page (ram:3D0B already begins a separate CALL ram:2B49 table). The static Ghidra DB models it in the page-0/ROM address space; whether the table is copied to RAM at runtime is a hypothesis, not MCP-confirmed. Code invokes a routine by CALL ram:3Bxx into the table. tools/bjumps.txt lists every entry’s (offset → page:addr); tools/RamRoutines.java marks the inline .dw/.db as data and comments each target.

Example: _PutMap’s glyph blitter is reached via the trampoline at ram:3B3D → 07:4588.

Inline bjumps: besides this trampoline table, CALL cross_page_jump; .dw; .db appears in other packed dispatch tables (e.g. a page-3D dispatch table near ram:2B6B) and inline within OS routines. Because cross_page_jump consumes the 3 inline bytes and tail-jumps (the target returns to the bjump’s caller), the bytes after must be data and the call is non-returning. tools/FixInlineBjumps.java marks all 355 such sites in the complete local ROM, which substantially improved OS-wide disassembly coverage.

Limitations

• Keep the BootFree guard in place when regenerating from emulator-derived ROM images.
• Some bcalls are thunks: e.g. _FindSym’s page-0 entry uses cross_page_jump to reach the real body on page 0x07.

04 — Interrupts (IM1)

The Z80 runs in interrupt mode 1: every maskable interrupt vectors to 0038h. There is no vector table — one handler services all sources by polling status ports.

Vector → handler [confirmed]

0038:  JR  0x006d        ; RST 38h vector
006d:  int_entry_save_alt_regs ; shadow-register save prologue
006f:  int_dispatch_sources    ; live interrupt-source dispatcher

int_dispatch_sources @ ram:006F runs after the two-byte prologue at ram:006D, with IY = flags (0x89F0), so (IY+off) reads/writes SystemFlags fields.

What it does [confirmed from decompiler]

Entry saves context (ex af,af' / exx — the Z80 shadow registers, the classic TI ISR convention) then polls:

1. port_usbIntStatus (0x55) — the 84+ USB Interrupt State port. This OS overloads it as the ISR’s master “anything pending?” gate: (val ^ 0xFF) & 0x1F tests the 5 active-low sources.
2. port_usbLineEvents (0x56) — the USB Line Events port; a read-only event bitmap whose bits select the timer/link sub-handlers. (Port 0x56 is read-only, so it is not an interrupt mask.)
3. Branches per source:
   • ON key — sets an ON-flag; onSP (0x85BC) holds the SP to unwind to for the ON-break path.
   • First/second timer — drives the APD (auto-power-down) countdown and cursor blink; ACKs via the interrupt-mask port 0x03.
   • Link activity — services the link port.
4. Hardware-mode housekeeping: checks port_mapBankB == 0x81 (84+ mode), and on one path sets port_cpuSpeed = 1 (15 MHz) and port_mapBankB = 0x81.
5. Restores context and EI / RET.

(IY+off) → SystemFlags fields the ISR touches [confirmed from disassembly]

int_dispatch_sources reads/writes these flag bits via BIT/SET/RES b,(IY+d). Offsets are confirmed against the standard ti83plus.inc group layout; the anchor apdFlags = IY+0x08 is confirmed in code (_DisableApd/_EnableApd @ 3B:7AA8/3B:7AAD do RES/SET 2,(IY+0x8)), curFlags = IY+0x0C is confirmed (_CursorOn/_CursorOff @ 06:7D34/06:7C5F).

The byte _GetCSC (00:04B2) clears is (IY+0) bit3 (*flags & 0xF7) — the kbdSCR/“new scan code ready” flag in the keyboard group.

Timer reprogramming, APD timeout, and cursor blink [confirmed mechanism; exact tick value [hypothesis]]

Interrupt sources & ACK. The dispatcher polls the 84+ USB-interrupt ports first, then the two crystal hardware timers: it reads port 0x37 (crystal timer 3 status — IN A,(0x37) @ ram:012D, BIT 1,A @ ram:012F) and port 0x31 (crystal timer 1 status — IN @ ram:013B, BIT 1 @ ram:013D). (Per the WikiTI port map the three crystal timers are 0x30–0x32 = timer 1, 0x33–0x35 = timer 2, 0x36–0x38 = timer 3.) Each maskable interrupt is ACKed by rewriting the int-mask port 0x03. The common exit (ram:00E4) writes 0x0B, or 0x0F when (IY+0x16) bit0 is set (the second value re-enables the on-key + both timer sources at the higher CPU speed). The master ACK at ram:00DC writes 0x08 then the saved mask. Port 0x04 is loaded with 6 (ram:09B5/ram:0C8C) to re-arm the legacy 83+ timer line.

APD (auto-power-down) countdown. APD is a software down-counter decremented by the timer interrupt:

• apdSubTimer (0x8448) / apdTimer (0x8449) hold the APD down-counter. _ApdSetup (00:03AE) writes the reload constant 0x74 to 0x8449 (apdTimer). The per-tick decrement is in page 0 at ram:036C (LD HL,0x8448; DEC (HL); RET NZ; INC HL; DEC (HL) — decrement apdSubTimer, and on its underflow apdTimer); a key press reloads the counter, so any key keeps the calc awake. The crystal-timer interrupt rate remains unreadable from this DB: when a timer-status bit is set the ISR dispatches to an unanalyzed handler — 35:4792 (via the ram:3FB1 bjump) for timer 3 / port 0x37, and 33:5EB4 (via ram:3FB7) for timer 1 / port 0x31 — so the wall-clock timeout cannot be derived from this DB. By the standard 83+/84+ design this yields the documented ~2–5 minute idle power-down. [reload constant + counter addresses + decrement site ram:036C confirmed; tick rate / absolute seconds [hypothesis]]
• The unrelated indicCounter/indicBusy pair (0x8476/0x8477) drives the run indicator (the moving-dashes busy spinner), not APD: _RunIndicOn (01:6518) seeds it (0x8477 = 0xF0, 0x8476 = 1) and the tick routine at ram:027B (dec_apd_timer in the symbol map, though it decrements the run-indicator counter) does DEC (0x8476); RET NZ each timer tick, advancing the spinner via the expiry path (ram:3FE1) only on underflow. [confirmed]

Cursor blink cadence. The blink is the same kind of software down-counter, driven off the same timer interrupt:

• 0x844A (curTime) is the blink down-counter; _CursorOn/_CursorOff (06:7D34/06:7C5F) reload it with 0x32 (50) (LD A,0x32; LD (0x844A),A).
• The ISR tests curAble (IY+0x0C bit 2) at ram:019B and, if enabled, calls the cursor tick through the ram:3FCF bjump to 06:7C45, which decrements 0x844A; on underflow it toggles curFlags (IY+0x0C) bit 3 (curOn) to flip the glyph and reloads 0x32. So the cadence is “toggle every 50 timer ticks”; only the absolute rate (the crystal-timer tick frequency) is ungrounded, which by the WikiTI-documented rate is ≈ 2 blinks/second. [reload value 0x32, counter 0x844A, and tick site 06:7C45 confirmed; Hz [hypothesis]]

Notable details

• This OS keys off the 84+ USB-interrupt ports 0x55/0x56 as the primary interrupt-state source, rather than the classic 0x03/0x04. Port 0x55 is the USB Interrupt State (read; (v^0xFF)&0x1F masks the active sources) and 0x56 is USB Line Events (read-only) — both are read sources, not a status/mask pair, despite the dispatch role. The legacy mask 0x03 is still written to ACK. [confirmed in code; ports per WikiTI]
• The ISR is where APD (auto power down) and the blinking cursor timing originate — both are software down-counters (apdTimer 0x8449/curTime 0x844A) ticked by the crystal timers (ports 0x37/0x31). The separate run-indicator spinner uses indicCounter/indicBusy (0x8476/0x8477), seeded by _RunIndicOn. [confirmed]
• _GetCSC (00:04B2) cooperates with the ISR: the ISR (or keypad path) updates kbdScanCode; _GetCSC atomically reads and clears it with interrupts masked, also clearing (IY+0) bit3. [confirmed]

Timer tick rate (ungrounded)

• The crystal-timer tick period (and therefore the APD timeout in seconds and cursor blink in Hz) depends on the unanalyzed timer-status handlers 35:4792 (timer 3 / port 0x37, via ram:3FB1) and 33:5EB4 (timer 1 / port 0x31, via ram:3FB7), which are data in this DB, so the absolute tick rate is not derivable here. The reload constants (apdTimer 0x8449 = 0x74, curTime 0x844A = 0x32), the counter addresses, and the page-0 / page-06 decrement sites (ram:036C, 06:7C45) are confirmed; only the absolute tick rate is ungrounded. [hypothesis]

11 — Boot, contexts, and error handling

Three cross-cutting mechanisms that tie the OS together: how it starts, how it switches “modes” (contexts), and how it aborts on error.

Boot [confirmed, partial]

0000 reset:  IN A,(2); AND 0x80; JP 0x028C   ; test port 2 bit7, go to boot continuation
028c:        port_mapBankA = 0x1F             ; bank a flash page into 4000
             (cond) DAT_io_000E = 3; port_mapBankA = 0x7F   ; configure RAM/exec paging (port 0x0E)
             port_memMapMode = 7              ; OUT (4): memory-map mode 1 + slow timer rate
             JP 0x812C                        ; into the boot page (3F:412C) — BootFree substitute here; retail boot in D84PBE1.8Xv

Boot configures the paging hardware (OUT (6),0x7F selects flash page 3F, the boot page) and the memory-map/timer mode (OUT (4)), then ends JP 0x812c into the banked window where page 3F sits — 3F:412C. In this BootFree rom.bin page 3F is a substitute placeholder (3F:412C re-maps paging rather than running the retail sequence); the retail boot page carries the real continuation (D84PBE1.8Xv / ti84plus_patched.rom, 3F:412C = IM 1; LD B,0; LD SP,0xFDFA; …). The boot page eventually initializes RAM, the VAT, system flags, the LCD, and enters the main context (the homescreen).

The boot page (3F) and its version queries are exposed to the OS through ti83plus.inc bcalls: _getBootVer (bcall 0x80B7 → 3F:477C) and _getHardwareVersion (bcall 0x80BA → 3F:4781). The USB boot support entry points route through the same table but land on page 2F, for example _AttemptUSBOSReceive (0x80E4 → 2F:4145) and _InitUSB (0x8108 → 2F:52A4).

RAM clear / re-init (ram_reset_wipe → ram:0BD9) [confirmed]

The RAM-init proper is ram_reset_wipe (35:719F, reached on a full reset; the same routine backs the [2nd]+[+] · 7 · 1 · 2 RAM-reset and the post-boot RAM clear). It zero-fills RAM in two blocks, preserving a handful of flag bits and 0x9B73 across the wipe:

ram_reset_wipe (35:719f):
  ; save flags to preserve: (9B73), (IY+34).6, (IY+35).0, (IY+35).1, (IY+3F)&0x7F
  DI
  LD HL,0x8000 ; LD DE,0x8001 ; LD BC,0x1BC3 ; LD (HL),0 ; LDIR   ; clear 8000..9BC3
  ... restore the saved flag bits ...
  LD HL,0x9BD0 ; LD DE,0x9BD1 ; LD BC,0x642F ; LD (HL),0 ; LDIR   ; clear 9BD0..FFFF
  JP 0x0BD9
ram_init_after_reset (ram:0BD9):
  LD A,0xC0 ; OUT (0),A        ; port 0 = memory-map control
  LD SP,0xFFF7                 ; reset stack to top of RAM
  CALL 0x3EC1                  ; continue init (page-0 kernel): VAT, sysflags, LCD …

So RAM is wiped in two LDIR runs (0x8000–0x9BC3, then 0x9BD0–0xFFFF, leaving the 0x9BC4–0x9BCF window and the explicitly-saved flag bytes intact), then ram:0BD9 resets the memory map (port 0) and the stack and hands off through ram:3EC1. This ram:0BD9 entry is the same RAM re-init point cross-referenced from 12-memory-management. The ram:3EC1 continuation (VAT/sysflag/LCD bring-up) is page-0 kernel code and is statically present (ram:3EC1 = CALL 0x2B09; …). Residual: JP 0x812c targets the boot page (3F:412C); this rom.bin carries a BootFree substitute there, with the retail boot code in D84PBE1.8Xv.

The main event loop [confirmed]

main_event_loop @ ram:05e6 (page 0) is the OS root dispatcher. Structure:

05e6: LD B,8;  LD HL,0x84BE        ; iterate an 8-entry event/context stack
05eb: INC HL                       ; first slot is 0x84BF
05ec: LD A,(HL); OR A; JR Z,...    ; skip empty slots
05f5: CALL 0x3f3f                  ; per-entry dispatch (event/key router)
0601: CP 0x7F / 0xFE / 0xFC / 0xFB ; branch on the handler's return code
...
0690: LD A,0x7F; CALL call_context_main   ; run the active context's handler
0699: POP AF; JP Z,0x05e6                 ; loop

So the loop pumps an event/context stack (8 slots from 0x84BF, after the INC HL), routes each via the dispatcher at ram:3F3F, and ultimately runs the active context’s cxMain handler through call_context_main, looping forever.

The ram:3F3F router is a bjump trampoline → event_key_router (07:4539): given a key code, it scans key→context dispatch tables (07:4099, ~105 entries, for 1-byte keys; 07:422C/4426 for extended 2-byte keys, using _LdHLind/_CpHLDE) and returns a routing code:

• 0xFE — normal: hand the key to the active context’s handler.
• 0xFB / 0xFC — context switch / app launch (the key maps to a different context — recall cxCurApp is a key code, so e.g. [GRAPH] → the graph context).
• 0xFF/0x7F — quit / no-op.

So the router classifies a mode key before the active context sees it and returns a context-switch code (0xFB/0xFC); the caller then swaps the cx* vectors. The router itself only writes keyExtend (0x8446, the extended-key state) — its body holds no store to the cx* block. [confirmed]

Contexts — how the OS implements “modes”/apps [confirmed — key concept]

The OS is single-tasking but multi-context. A context is the set of handler routines for whatever is currently in front of the user (homescreen, an editor, the graph screen, a Flash App). The active context’s vectors live in RAM at cxMain (and friends), with cxPage holding which flash page their code is on.

• _AppInit (ram:0936) installs a context: copies 12 bytes of handler vectors → cxMain, sets flags.appFlags, and saves cxPage = port_mapBankA (the page the app runs from). [confirmed]
• The dispatched handlers include things like a key handler, (re)display/paint handler, and a PutAway (suspend) handler — the OS calls them through the cx* vectors, paging in cxPage first.
• _PutAway (ram:08AF) calls the current context’s PutAway handler (cxPPutAway) to suspend/clean up — used on APD, when switching apps, or on 2nd+QUIT. [confirmed]

This is the backbone of the UI: the main event loop reads a key (_GetKey), then calls the active context’s key handler; switching screens swaps the cx* vectors.

Context block layout [confirmed, from ti83plus.inc + xrefs]

The active context lives at a fixed RAM block (Context struct, base cxMain=0x858D):

_AppInit copies the 6 vectors (12 bytes, +0..+11) from an app’s header into this block, then sets cxPage. Because cxCurApp is a key code, a mode-switch key naturally selects the context to load.

The full _AppInit body confirms the offsets directly — HL points at the app’s 12-byte vector header, LDIR lands them at cxMain=0x858D, and the byte that follows the 12 vectors becomes a flags byte; cxPage is then loaded from the live bank-A page-select (port 6), not copied from the header:

_AppInit (ram:0936):
  ; HL = source (12-byte vector header) on entry
  LD DE,0x858D            ; -> cxMain
  LD BC,0x000C            ; 12 bytes = the 6 handler vectors
  LDIR                    ; cxMain..cxSizeWind+1  (+0..+11)
  LD A,(HL)               ; the 13th header byte (appFlags)
  LD (0x89FD),A           ; -> appFlagsAddr (system flag byte)
  IN A,(0x6)              ; current bank-A flash page
  LD (0x8599),A           ; -> cxPage  (+12, the page the handlers run from)
  RET

The destination 0x858D and length 0x000C pin the six 2-byte handler slots cxMain(+0) cxPPutAway(+2) cxPutAway(+4) cxRedisp(+6) cxErrorEP(+8) cxSizeWind(+10), and the explicit LD (0x8599),A writes cxPage at +12 from port 6. _AppInit installs a context, but it is not the only writer: _POPCX (bcall 0x49E1, body 07:6D1C) restores a suspended context by LDIRing 14 bytes cxPrev→cxMain (0x859B→0x858D) and copying a 15th byte into the app-flags, and a matching save path (the LDIR at 07:5A8C) copies cxMain→cxPrev. cxCurApp(+13, 0x859A) is the current context id (a key code); the shadow at cxPrev(0x859B) holds the suspended context.

How a context handler is invoked [confirmed]

call_context_main (ram:08fa):   set_bankA_page(cxPage); call (cxMain) via jp_hl; ret   ; run handler on its page, control returns here
call_context_savepage (ram:08e9): save port6; set_bankA_page(cxPage); jp_hl; restore port6

Primitives: set_bankA_page (ram:078c, port6 = page) and jp_hl (ram:090b, jp (hl) dynamic dispatch). The OS pages the handler in, runs it, and (for the savepage variant) restores the caller’s page.

Error handling [confirmed]

Errors use a non-local exit, not return codes:

• A routine detects a fault and calls _JError (ram:2793) with an error code in A (the TIError enum: E_Domain, E_DivBy0, E_Memory, … each ORed with E_EDIT=0x80 if re-editable). _JError stores the code to errNo (0x86DD); the sibling entry _JErrorNo (ram:2799) raises the already-stored errNo without taking a new code.
• The handler restores the stack from errSP (0x86DE, LD SP,(errSP) at ram:27BB), restores a sane state, and displays the error screen (ERR: + message, with 1:Quit 2:Goto). errSP is the current error frame; _resetStacks seeds it from onSP (0x85BC, the context-level saved SP) at context/parse start.
• The E_EDIT bit (0x80) tells the handler the error is editable (offer “2:Goto” to jump to the offending token).

So errSP + _JError together implement try/catch: a context seeds errSP (from onSP) at entry, and any depth of nested calls can abort straight back to it.

Error-message table [local data-table trace]

The error screen shows ERR:<MESSAGE> (the ERR: prefix is on 01:4008). A local data-table trace shows the handler masking the code (AND 0x7F), then for codes below 0x3A indexing a little-endian pointer table at 07:6ACC by (code) − 1 (LD HL,0x6ACC; ADD HL,DE; ADD HL,DE; CALL _LdHLind) to fetch each message pointer; the message strings themselves sit consecutively from 07:6B3C as null-terminated text. Codes ≥ 0x3A (and the special-cased 0x36/0x37/0x39) bypass the table and fall back to the ? message at 07:6C5A. The current MCP function/xref view does not prove this data-only table directly, so treat the addresses as a data trace rather than live function symbols:

The Code column is each error’s low 7 bits. Re-editable errors set the E_EDIT (0x80) bit on top — E_Overflow equ 1+E_EDIT, E_DivBy0 equ 2+E_EDIT, … — while non-editable ones (E_Label equ 20, E_Stat equ 21, …) carry no such bit. The handler masks the code (AND 0x7F) before indexing. So the whole error pathway is: a routine _JErrors a code → the handler restores SP from errSP → masks the code and looks up the message here → renders ERR:<msg>.

Confirmed details

• cx* vector layout — confirmed. The six 2-byte handler slots and cxPage offsets are pinned by tracing _AppInit (ram:0936): LD DE,0x858D / LD BC,0x000C / LDIR then IN A,(6) / LD (0x8599),A. See Context block layout above for the full offset table and _AppInit body. _AppInit installs the block; it is not the sole writer — _POPCX (bcall 0x49E1 → 07:6D1C) restores a saved context into cxMain, and a save path at 07:5A8C copies cxMain into the cxPrev shadow.
• Boot RAM-init trace — raw-disassembly trace. Reset (ram:0000) → 028c paging setup → JP 0x812c (boot page 3F:412C — BootFree substitute in this rom.bin; retail boot in D84PBE1.8Xv). The RAM clear/re-init is ram_reset_wipe (35:719f): two LDIR zero-fills (0x8000–0x9BC3, 0x9BD0–0xFFFF) preserving a few flag bytes, then JP 0x0BD9 (ram_init_after_reset: port 0 = 0xC0, stack reset in the raw trace, CALL 0x3EC1). The ram:0BD9 entry matches the re-init point cross-referenced in 12-memory-management. See RAM clear / re-init.
• Flash write/erase sector primitives. Page-3D anchors include flash_program_buf 3D:678C, the per-record status writers 3D:7C8F/7C93/7C97, and flash_erase_wait 3D:5ED3, with byte-poke loops copied to ramCode 0x8100. The candidate labels flash_program_core 3D:61AF and flash_write_record 3D:64AA are not defined functions in the disassembly; both names are project-local inferred labels, not WikiTI or ti83plus.inc equates. The public single-byte flash writers are _WriteAByte (bcall 0x8021) and _WriteAByteSafe (bcall 0x80C6) in ti83plus.inc; these name the public entry points, whose bodies are likewise not defined functions in the disassembly. See sub-vat-archive §6.

Residual: JP 0x812c targets the boot page (3F:412C); page 3F is a BootFree substitute in this rom.bin, with the retail boot code in D84PBE1.8Xv. The ram:3EC1 init continuation is page-0 kernel code and is statically present.

12 — Memory management (RAM heap & Flash archive)

How the OS allocates the ~24 KiB of user RAM between variables, temporaries, the FP stack, and the program being run — and how it offloads variables to Flash (“archive”).

The RAM heap [confirmed pointers, standard layout]

The dynamic region runs from userMem (0x9D95) up to symTable (0xFE66). Two structures grow toward each other with free RAM in the middle:

flowchart TB
    A["0xFE66 · symTable — top of user RAM"]
    B["VAT — variable names + metadata<br/>type, data ptr/page, name · grows DOWNWARD ↓"]
    C["( free RAM )"]
    D["user data — variable contents<br/>grows UPWARD ↑"]
    E["0x9D95 · userMem — bottom of user RAM"]
    A --- B --- C --- D --- E
    style C fill:#1b1b1b,stroke-dasharray:5 5

VAT entry layout: type, data ptr/page, name — see 05-variables-vat.md.

Boundary/work pointers (clustered at 0x9820–0x983A) [confirmed addrs]:

_MemChk reports free RAM as (OPS) − (FPS) (the pointers at 0x9828/0x9824) + 1, i.e. the span between the floating-point stack and the operand/symbol stack in the middle of the region (the conceptual picture above: user data grows up, the VAT grows down, free RAM in the middle). When a variable grows/shrinks, everything above it shifts.

Core allocation primitives [confirmed]

• _InsertMem (ram:0F81) — open a gap of HL bytes at address DE by shifting all memory above it up. It calls insertmem_setup (ram:0F8B), which does the LDDR block move (at ram:0FA1), then delmem_fixup_tail (ram:1398) to fix up pointers. _InsertMem does not check free space itself — callers must ensure room first via _EnoughMem (the wrapper _ErrNotEnoughMem at ram:1735 calls _EnoughMem then jumps to _ErrMemory at ram:2721 on shortfall).
• _DelMem (ram:1368) — the inverse: close a gap, shifting memory down.
• _EnoughMem (ram:0FA6) — ensure N free bytes; if short, it walks the temp/scratch entries (9-byte stride from pTemp down to OPBase) and _DelVars reclaimable temporaries to make room. [confirmed]
• _MemChk (ram:0E20) — compute current free RAM.

Variable-creation bcalls — _CreateReal, _CreateStrng, _CreateAppVar, _CreateRList, etc. (see 05) — share a create body (_CreateReal at ram:10B8 jumps into ram:1011) that carves space via an internal gap routine at ram:0F0C — which does its own block move and updates the temp/FP-stack pointers, not the public _InsertMem — then registers the variable in the VAT.

Flash archive [confirmed location]

To save scarce RAM, variables can be archived to Flash. The archive entry point is on flash page 0x07, while the low-level flash read/write/erase workers are on page 0x3D:

• _Arc_Unarc (07:6248) — move OP1’s variable between RAM and the Flash archive (toggles the archive bit, then relocates the data and rewrites the VAT entry’s page to the Flash page).
• _FlashToRam (id 5017 → body 3D:6745) — copy archived data back into RAM. Archived vars are appended to Flash, which can’t be overwritten in place, so deleting one only marks it dead. When the archive Flash fills, a garbage collector rewrites the live vars to fresh sectors and erases the old ones — the Garbage Collecting screen (stored as two ROM strings, "Garbage"/"Collecting...", with three ASCII dots). That GC path is distinct from _CleanAll, but the older flash_gc_relocate@3C:7BD0 / gc_show_screen@3C:7E0D labels are not present as functions in the current live Ghidra/MCP DB.

_CleanAll is RAM cleanup (not Flash GC) [confirmed from disassembly]: _CleanAll (07:52CF) compacts the floating-point stack down to tempMem (fpBase/FPS) and the OP/scratch stack down to pTemp (it sets OPBase = pTemp, LDDRs the live span down, and sets OPS to its new top), reclaiming temporary RAM after a command/expression finishes. It does not touch Flash.

Flash is erased a sector at a time but programmed byte-by-byte (the page-3D writer at 3D:64AA calls the single-byte bcall _WriteAByte, id 8021), via low-level routines through the flash-control port 0x14 (see Variables, Archive & Unarchive) [partly confirmed]:

• Confirmed page-3D anchors include _FlashToRam (3D:6745), flash_program_buf (3D:678C), flash_erase_wait (3D:5ED3), flash_cmd_base (3D:738B), and the status-bit helpers flash_op_fd (3D:7C8F), flash_op_fb (3D:7C93), flash_op_fe (3D:7C97).
• Further page-3D flash routines at 3D:61AF, 3D:6B9B, 3D:64AA, 3D:62C2, and 3D:6413 are unnamed in the disassembly.
• Archive workers: _Arc_Unarc (07:6248) → arc_ram_to_flash (07:6107, RAM→Flash) / arc_flash_to_ram (07:61F4, Flash→RAM). (_Arc_Unarc dispatches on the FindSym page byte B: B==0/in-RAM → 6107 archive, B≠0/in-Flash → 61F4 unarchive.)

The _FindSym VAT walk is byte-verified in Variables, Archive & Unarchive. Flash write/erase and GC routines on page 3D are partly unnamed [hypothesis].

Variables, archive & unarchive

TI-84 Plus OS 2.55MP — feature deep dive.

Deep-dive companion to 05-variables-vat.md and 12-memory-management.md, focused on what a program that manages memory touches: the VAT walk (_FindSym), variable Store/Recall, and the Archive / UnArchive path (RAM ↔ Flash), the Flash garbage collector, and the memory checks.

Every address here is read from the raw Z80 disassembly rather than the decompiler alone, which mis-renders the SET b,(IY+d) flag ops and the cross-page CALL 0x2b09-style trampolines. Page numbers are the masked flash page (rawpage & 0x3F); cross-page trampolines store lo hi rawpage in the 3 bytes after the CALL.

1. The arcInfo workspace and key RAM pointers [confirmed]

The archive engine keeps a 12-byte scratch block, labelled arcInfo (83EEh) in ti83plus.inc, plus a saved copy savedArcInfo (8406h). _Arc_Unarc’s reentrant inner mover at 07:61DC copies the 12 bytes starting at 83F1 (the vatPtr field onward, not the whole 83EE block) into 8406 (LD HL,83F1 / LD DE,8406 / LD BC,0C / LDIR); the matching 07:61E8 restore candidate is an inferred label, not byte-confirmed in the disassembly.

RAM-heap pointers used by the mem checks (cluster at 0x9820–0x983A, confirmed in .inc): FPS=9824, OPBase=9826, OPS=9828 (top of the upward data heap), pTemp=982E, progPtr=9830. The VAT grows down from symTable=0xFE66. chkDelPtr3=981C holds the result pointer from the last lookup (_Arc_Unarc does LD (981C),HL) — note 981C is chkDelPtr3 in ti83plus.inc, not tSymPtr1 (which is 9818h). ramCode=8100h is where Flash read/write routines are copied to run (you cannot execute from a Flash page while erasing it).

2. _FindSym and the VAT walk [confirmed]

_FindSym (00:0E65, = RST 10h) is a page-0 trampoline that cross-page-jumps to the real scanner findsym_scan @ 07:565F. _ChkFindSym (00:0E60) first type-checks OP1 (_CkOP1Real) then falls into FindSym.

The scanner keys off OP1 at 8478: OP1.type/varType and the name token at 8479 (=OP1+1), with the 2 name bytes at 847A/847B:

findsym_scan (07:565F):
  CALL FUN_ram_20d6           ; classify OP1 name
  if name-token (8479) == 0x24 (list-name token):
        scan the temp/list region: HL from progPtr(9830) down toward OPBase(9826), pTemp(982E)
  else: HL = symTable (0xFE66), scan downward to progPtr
  loop:
     A = (HL); A &= 0x1F            ; *** mask off archive flag bits in high nibble ***
     SBC HL,DE ; RET C  (ran past end → not found)
     CP (HL) against token (8479); on match check name bytes (847A/847B) at HL-1/HL-2
     else step HL -= 3 (single-char entries) / -= (6+nameLen) and continue
  on match:  B=(entry).pageByte, DE=dataPtr, A=(entry+6)=type; store type→8478

So each VAT entry is read high-address-first; the type byte’s low 5 bits are the TIVarType; the high bits flag the archive state. _FindSym returns: type in A and 8478, data pointer in DE, and the page byte in B — B is the discriminator: zero for an in-RAM var, nonzero for a var whose data lives on a Flash page.

VAT entry shapes (consistent with _CreateR* header writes — see 05-variables-vat.md):

• single-char (real/cplx/Ln/[A]/sysvars): high-address-first name token, page byte, data pointer, and type byte; findsym_scan reads these as page at name+1, data pointer at name+2/+3, and type at name+6.
• named (prog/appvar/group/str/equ): high-address-first name bytes/length plus the same page/data/type fields; the exact byte order is easiest to reason about relative to the matched name token rather than as a forward C struct.

For an archived entry the data address (addrLSB/MSB) points into the Flash window and the page byte selects the Flash page; the VAT record itself always stays in RAM.

3. Store / Recall [standard]

Store _StoOther (38:62A9) and siblings (_StoAns, _StoX, _StoY, … 38:6251–62A3):

• Set OP1 type = 0xFF placeholder (62A9: LD A,FF / LD (8478),A), parse the destination name.
• 5F45 resolves/creates the target symbol; then it copies the value. It dispatches on the destination name token (849B): list-element store (0x2A → bounds-checks via _ErrDimension), matrix element, etc. Ultimately a _Create* routine carves RAM with _InsertMem and the data is copied.
• A store into an archived var is not done in place; the OS unarchives first (you cannot rewrite Flash in place) — see the _Arc_Unarc direction logic in §4. [hypothesis]

Recall _RclVarSym (38:67B1) and _RclVarPush (3A:5D07):

• _RclVarSym calls RST 10h (17A6, a _FindSym+error-check wrapper: RST 10h; JP C,271D), then checks the name token (8479). For a list recall (63/2A) it sizes the data with _DataSize (00:1485) and copies it into a work buffer (91E0), using _LdHLind and cross-page helpers; ends JP _OP4ToOP1.
• _DataSize (00:1485): returns the variable’s data byte-count in DE from the type byte — real=9, list/cplx-list read the word count header, matrix uses cols×rows, and named types (0x15 AppVar, 0x16, 0x17 Group) read the leading word size.
• The recall code does not care whether the source is RAM or Flash for reading — Flash is memory-mapped read-only into the 0x4000 window. To use an archived program/var that must be modified or executed in RAM, the OS first copies it via _FlashToRam (§5). [standard]

4. Archive / unarchive — _Arc_Unarc (07:6248) [confirmed]

The headline. bcall(_Arc_Unarc), OP1 = the variable name. It toggles the var between RAM and the Flash archive (the same entry point does both directions, deciding from the current state).

_Arc_Unarc (07:6248):
  SET 0,(IY+0x24)              ; flag: an archive operation is in progress
  CALL 628B                    ; validate OP1 name is an archivable class; Z⇒not allowed → JP 26E0 (local error shim; LD A,0xB2 = E_Variable, ERR:VARIABLE → _JError)
  CALL _OP1ToOP3 (1A0F)
  CALL _ChkFindSym (0E60)      ; locate the VAT entry; C ⇒ JP 271D (undefined)
  DI
  LD (981C),HL                 ; chkDelPtr3 = entry ptr
  LD A,B ; OR A ; JR Z,6272    ; B = page byte: 0 ⇒ currently in RAM, else ⇒ in Flash
      (Flash, B≠0) LD A,(HL); CP 0x17 ; Group? ⇒ JP 26E0 reject  [groups archive via a different path]
                   CALL 61F4   ; *** Flash → RAM:  unarchive ***
   6272 (RAM, B==0):  CALL 6107        ; *** RAM → Flash:  archive ***
  ... name-token-0x5D (list name, `tVarLst`) special-case via 32A9 / cross_page 05:4A6E
  LD A,(83EE); OR A; EI; RET

628B is the archivable-name guard: after _CkOP1Real it returns Z for the non-archivable single-letter real/sysvar name tokens 0x58 0x59 0x54 0x5B 0x52 0x72 0xFC (CP n; RET Z chain), so _Arc_Unarc’s JP Z,26E0 rejects them via the 26E0 shim (LD A,0xB2 = E_Variable, ERR:VARIABLE → _JError); archivable classes (lists, matrices, programs, appvars, …) return NZ and continue. (_arc_59f1 @07:59F1 and _arc_5936 @07:5936 are companion name/range validators for the catalog archive command.)

Direction note: the B-page test sends an in-RAM var (B==0) to 6107 (archive) and an in-Flash var (B≠0) to 61F4 (unarchive). 6107 is the one that programs Flash and frees the RAM copy; 61F4 is the one that carves RAM and copies the data back out of Flash.

4a. RAM → Flash (archive), 6107 [confirmed]

6107:  CALL 7866 ; DI
       CALL 614B                       ; size/accounting: (83F1)=vatPtr, _DataSize→83F7;
                                       ;   616C reserves the archive-Flash slot
       CALL 2FF1 (cross_page 3D:64AA)  ; *** program the data into the archive Flash ***  (see §6)
       LD HL,(83F3) ; LD DE,(83F7) ; CALL _DelMem (1368)  ; release the old RAM copy
       RET
616C:  reads vatPtr type, AND 0x1F (clean type for the record header),
       LD HL,(83F7)+(83F5) ; ADC ; JP C,2729 (E_Invalid, 0x8F)  ; size overflow?
       reserves a Flash slot via 2FDF(3D:61AF) / 2FF7(3D:62C2)

The data is appended to the archive Flash (Flash cannot be overwritten in place). The VAT entry’s type byte gets its archive flag set and its data ptr/page rewritten to point into Flash; the old RAM copy is then released (the upward data heap shrinks). 3D:64AA is the Flash writer that lays down a fresh archived record plus a copy of the symbol header/name and data (status marker bytes — 0xFE=in-progress / 0xFC=valid / 0xF0=deleted, with 0xFF=erased/empty; the bit-clearing mechanism is confirmed in §6a). 3D:64AA is an inferred label, not byte-confirmed in the disassembly; the flash_write_record name for it is a project-local inferred label, not a WikiTI or ti83plus.inc equate. _Chk_Batt_Low (00:0D07) gates the Flash write — archiving aborts on low battery (61C5: CALL _Chk_Batt_Low).

4b. Flash → RAM (unarchive), 61F4 [confirmed]

61F4:  LD (83EF),DE ; LD (83EE),A      ; arcInfo.dataPtr/page = source (Flash page+addr from FindSym)
       CALL 6335                       ; 6331/6335: stash vatPtr (83F1), compute dataSize (83F5) via _DataSize
       CALL 32D3                       ; size accounting
       LD A,(HL) ; CALL 146C           ; add header overhead → 83F9 (sizeFull)
       EX DE,HL ; CALL _EnoughMem(0FA6); ensure there is RAM room for the unarchived copy
                JP C,_ErrMemory(2721)
       OR 1 ; CALL 0F0C                ; carve the RAM gap (internal create-gap routine)
       LD (83F3),DE                    ; destPtr = new RAM address
       CALL 3003 (cross_page 3D:6440)  ; *** page-3D unarchive worker: copy Flash→RAM, retire the old record ***
       RET

The data is copied from Flash into the freshly-carved RAM gap. The VAT entry’s archive flag is cleared and its data ptr/page rewritten back to the new RAM address; the old Flash record is left marked dead (0xF0, reclaimed at the next GC). 3D:6440 shares the page-3D flash-control prologue (OUT (0x14)) and is an inferred label, not byte-confirmed in the disassembly.

4c. Errors raised on the path [confirmed]

• 2785: LD A,0x31 → _JError = E_ArchFull (0x31) “ERR:ARCHIVE FULL” (no room even after GC).
• 2729/272D/2731: LD A,0x8F/0x90/0x91 → E_Invalid / E_IllegalNest / E_Bound. The archive size check (616C) takes the 2729 (E_Invalid, 0x8F) entry on overflow.
• 26E0+ is a cluster of local error shims: each loads its code (0xB2=E_Variable, 0xB3=E_Duplicate, 0x81=E_Overflow, 0x82=E_DivBy0) into A and enters _JError — not _ErrDataType.
• Error-name strings live at 07:6CA9: ARCHIVED, VERSION, ARCHIVE FULL, VARIABLE, DUPLICATE.

5. Reading archived data — _FlashToRam (3D:6745) [confirmed]

bcall(_FlashToRam) (id 0x5017 → real body 3D:6745). Copies BC bytes from a Flash page:addr to a RAM destination, transparently advancing the Flash page when the read crosses the 0x8000 window boundary:

3D:6745: mask page (AND 1F / AND 3F per port-2 model check FUN 1837/182F)
         PUSH IX ; LD IX,6761 ; CALL 678C ; POP IX ; RET
3D:678C: copies the small arg-block to ramCode, sets DE=0x8100, JP 8100  ; runs the copier from RAM
the copier (6761..678A):
   IN A,(6) saved ; OUT (6),A     ; bank A = the source Flash page into 0x4000 window
   loop LDI:  BIT 7,H → at 0x8000 wrap: IN A,(6); INC A; OUT (6),A; LD HL,0x4000  ; next page

Port 6 is the bank-A page-select; the read code itself runs from ramCode (0x8100). This is how an archived program/appvar is pulled back into RAM to be executed or edited. ti83plus.inc also names a sibling _FlashToRam2 (id 8054); the retail boot table maps it to 3F:4888.

6. Low-level Flash write / erase (pages 3C/3D, port 0x14) [mixed]

The Flash program/erase primitives live on flash pages 0x3C / 0x3D and are invoked through page-0 cross-page trampolines. The public bcall entry points for the byte writer are named in ti83plus.inc: _WriteAByte (id 8021) and _WriteAByteSafe (id 80C6) program a single Flash byte; _FlashToRam2 (id 8054) is the companion Flash→RAM copy of _FlashToRam (§5). The retail boot table maps those APIs to boot-page bodies (_WriteAByte→3F:4C9F, _WriteAByteSafe→3F:4C9A, _FlashToRam2→3F:4888), which then wrap the lower-level page-3C/3D flash machinery below. Several page-3C/3D targets below are reached by byte trace but are inferred labels, not byte-confirmed in the disassembly; their flash_* names are project-local inferred labels (not WikiTI or ti83plus.inc equates):

The program-core candidates 3D:64AA and 3D:6440 share this unlock prologue (3D:61AF starts differently — PUSH AF; PUSH HL; BIT 6,(IY+0x24)):

RES 7,(IY+0x24) ; LD A,1 ; DI ; IM 1 ; DI ; OUT (0x14),A ; DI ; CALL FUN_ram_02bf

OUT (0x14),A toggles the Flash control port (0x14) to enable write/erase; FUN_ram_02bf sets up the RAM-resident write stub (the actual byte-poke loops run from RAM at 0x8100/ramCode, because the CPU cannot fetch from a Flash chip mid-erase). 3D:6B9B/3D:6B6D are bounds-checked byte-program candidate calls (return carry → caller raises E_ArchFull); neither is byte-confirmed in the disassembly. The public byte-write API for this layer is _WriteAByte (8021) / _WriteAByteSafe (80C6), which resolve to boot-page wrappers. The free-slot scan reads sector status bytes and sums free space to decide whether a GC is needed before a write.

6a. Record-status byte — the one-way bit-clearing scheme [confirmed]

The status byte is a classic AMD/Am29F monotonic bit-clear marker: erased Flash is all-ones (0xFF), and the OS advances a record’s state by clearing bits (program can only flip 1→0; only a sector erase restores 1s). The writers are three tiny routines on page 0x3D that load an AND-mask into C and then read-modify-write the status byte (3D:7C9A: CALL flash_read_byte; AND C; …):

Successive clears compose: the three helpers take a record 0xFF (erased) → 0xFE (started) → 0xFC (valid/complete, bits 0+1 clear). Deletion marks the record 0xF0 (deleted/dead, bits 0–3 clear) with a direct write in the delete/GC path (§7), not via those three in-progress/valid helpers. Because only bits go 1→0, a deleted record can never be re-validated in place — it is reclaimed only by GC erasing the whole sector. flash_find_nonff (3D:7DEA) confirms 0xFF = empty: it reads the 13-byte record header and CP 0xFF on each, treating an all-0xFF run as a free slot. (3D:7C99 additionally folds in AND 0xE7 and conditional OR 0x10/OR 0x08 for the swap/relocate state bits driven by (IY+0x1A).0 and (IY+0).2.)

6b. Archive sector map / erase-block granularity [confirmed]

The physical Flash pages that form the archive pool are model-selected at runtime from the two model bits — port 2 bit 7 (probe_hw_model_keep_a 00:1837) and port 0x21 low bits (probe_port21_keep_a 00:182F):

So on a 1 MB TI-84 Plus the user archive occupies roughly raw pages 0x15…0x1E, and the OS pages it into the 0x4000 window one 16 KB page at a time for both reading (_FlashToRam, masks 0x1F/0x3F via the same model check, 3D:6745) and erasing. flash_set_sector_cnt (3D:727D) loads (base+1) into the sector counter 0x82A3; the erase routine flash_erase_wait (3D:5ED3, whose loop jumps to 3D:5EF1 — 3D:5EE3 is the unrelated _FindApp) pages each sector to 0x4000 and issues the chip erase command via RST 0x28, decrementing 0x82A3 down toward the base page. The underlying Am29F-class chip uses 64 KB physical sectors (= 4 × 16 KB OS pages); the OS walks/erases at 16 KB page granularity. [64 KB physical-sector figure: hypothesis]

7. Flash garbage collector — “Garbage Collecting…” [mixed]

Distinct from _CleanAll (RAM/FP-stack cleanup, 07:52CF). When the archive Flash fills, dead (unarchived/deleted) records must be reclaimed by rewriting the live records to fresh sectors and erasing the old ones.

• The on-screen prompt string "Garbage\0Collecting...\0" is at 01:4126; "Defragmenting...\0" at 01:4076. The display front-end candidate 3C:7E0D (LD HL,0x4126 ... CALL 3E85) is an inferred label, not byte-confirmed in the disassembly.
• GC is driven from the command dispatcher candidate 3C:7121: 3C:71F9 = “show GC screen + relocate” (CALL 7E0D then CALL 7219 then CALL 7733), 3C:720D = relocate-only, and the archive-full auto-GC 3C:7204 runs 71FC (GC) then retries the write at 7F1C. 3C:7121 is an inferred label, not byte-confirmed in the disassembly.
• The relocation/erase-core candidate 3C:7BD0–7BF4: tests a status flag, 7E6B/7C10 prepare the swap sectors (writes 0xF0 marker, sets 97A6 sector counter, 8477), 7BE3:CALL 7E0D shows the banner, 7C1F walks live VAT/Flash entries copying each valid (0xFC-marked) record to the new sector, and 7C04 finalizes (erases the old sectors, SET 2,(IY+0x25)). [standard] 3C:7BD0 is an inferred label, not byte-confirmed in the disassembly; the flash_gc_relocate/gc_show_screen names are project-local inferred labels, not WikiTI or ti83plus.inc equates.
• GC is callable from the user catalog (Archive/the MEM menu “Garbage Collect?” — string at 01:76C9).

So: archive = append to Flash; delete/unarchive = mark dead; when Flash fills, GC compacts. Exactly the classic TI-83+/84+ behaviour, now pinned to addresses.

8. Memory checks [confirmed]

• _MemChk (00:0E20) — free RAM = OPS(0x9828) − FPS(0x9824); returns 0 if the heap top has met the FP stack, else count (INC HL ⇒ off-by-one inclusive). OPS is the top of the upward data heap; the gap to the downward VAT is the real free RAM (see _InsertMem collision check). The decompiler’s trivial 2-line view is wrong — the real routine subtracts the two pointers.
• _EnoughMem (00:0FA6) — ensure N free bytes; if short it walks the temp/scratch entries from pTemp(982E) down toward OPBase(9826) at a 9-byte stride, and _DelVars any entry whose flag byte has bit 7 (& 0x80) set (a reclaimable temporary), looping until enough or exhausted. Used by the _Create* routines and by the unarchive RAM-fit check (61F4 calls it before allocating).
• _InsertMem (00:0F81) / _DelMem (00:1368) — open / close a gap at HL by block-moving everything above; _InsertMem fails E_Memory if it would collide with the VAT.
• Free archive (Flash) is computed inside the Flash layer. The free-space sum is at 3D:6413 and the catalog “MEM” read path runs through 3C:7121. Neither address is byte-confirmed in the disassembly.

9. Confident address index

Strings: 01:4126 “Garbage Collecting…”, 01:4076 “Defragmenting…”, 07:6CA9 “ARCHIVED/VERSION/ARCHIVE FULL/VARIABLE/DUPLICATE”, 01:76C9 “Garbage Collect?”. Ports: 0x06 = bank-A page select (Flash window), 0x14 = Flash write/erase control, 0x02 bit7 = Flash-size/model. RAM run-from-RAM stub: ramCode = 0x8100.

10. Summary & open items

• Sector map / erase-block — [confirmed], see §6b. The archive pool is model-selected: base page 0x15/0x29/0x69 (flash_page_select 3D:726E) up to top page 0x1E/0x3E/0x7E (flash_cmd_base 3D:738B); on a 1 MB TI-84 Plus that is raw pages ~0x15…0x1E. The OS pages the region into the 0x4000 window and erases one 16 KB page at a time (flash_erase_wait 3D:5ED3, sector counter 0x82A3 from flash_set_sector_cnt 3D:727D); the physical chip sector is 64 KB = 4 OS pages [hypothesis].

• Record-status bytes — [confirmed], see §6a. Monotonic bit-clear: 0xFF erased → 0xFE in-progress → 0xFC valid via flash_op_fe/fd/fb (3D:7C97/7C8F/7C93) AND-masking; 0xF0 deleted is a direct write in the delete/GC path the status byte; flash_find_nonff (3D:7DEA) treats an all-0xFF header as free.

• Lower-level flash helper bodies — address-keyed labels still inferred [hypothesis]. The public bcall entry points are canonical equates in ti83plus.inc and now resolve through the retail boot table: _WriteAByte (8021) → 3F:4C9F, _WriteAByteSafe (80C6) → 3F:4C9A, and _FlashToRam2 (8054) → 3F:4888. The address-keyed flash_* labels in §6/§9 stay inferred and body-undisassembled until the lower-level page-3C/3D helper graph is split cleanly.

• Group archive path — partially pinned [hypothesis]. _DataSize (00:1485) confirms a Group (type 0x17, like AppVar 0x15/0x16) carries a leading word-size header, so a group can be stored as one Flash blob. In _Arc_Unarc the CP 0x17 → 26E0 reject sits on the B≠0 (in-Flash) branch, immediately before the unarchive worker 61F4 — so an archived group is not unarchived through 61F4, and groups are handled by a separate routine that walks the group’s member list. That member-walk routine remains unidentified in the disassembly — _Arc_Unarc’s body past the entry CALL is not disassembled here (cross-page CALL flagged non-returning), and no group-archive function is named or xref-reachable. Confirming it would need a linear disassembly pass like the one behind §4.

Apps, memory reset & settings

TI-84 Plus OS 2.55MP — feature deep dive.

How the student-facing parts of the OS work: launching Flash Apps, the MEM → Reset menu (what “RAM Cleared” erases), and the MODE screen format/mode flags. Addresses are space:addr where ram/page_00=0000-3FFF, flash pages mapped at 4000-7FFF. Confidence flags follow conventions.md: [confirmed] = read from disassembly; [hypothesis] = strong inference, not yet verified (used below for both strongly-inferred claims and partial traces where the code is RAM-resident / cross-page and not fully traced).

Cross-references: doc 11 (contexts, _AppInit, event router), doc 12 (RAM heap, _CleanAll), doc 13 (flash page map). Flag bits use the ti83plus.inc equates; the SystemFlags base is IY = flags = 0x89F0, so e.g. (IY+0x0A) = flags + fmtFlags.

1. Flash Apps — find & launch

This ROM ships with zero bundled apps in the local ROM-byte scan (zero 80 0F headers found at page starts) [hypothesis], but the entire find/launch machinery is present on page 0x3D (_FindApp*) and page 0x3B (_AppInit glue / app-quit). Apps are TI Flash Applications: a contiguous run of 16 KiB flash pages whose first page begins with a TLV app header.

1.1 App header format (TLV) [confirmed]

An app header is a sequence of type-length-value fields starting at offset 0 of the app’s first page. Each field begins with two bytes in WikiTI’s TT TS notation: the high 12 bits are the field number, and the low nibble of the second byte encodes the payload length. The decoder bytes are around 3D:7285, but the disassembly does not expose a live function there:

3D:7285  AND 0x0F; CP 0x0F -> B=4 ; CP 0x0E -> B=2 ; CP 0x0D -> B=1

The master field at offset 0 is usually 80 0F … (field 800, size nibble F, followed by a 4-byte size) — this is what the page-scan keys on to recognise an app. Fields carry the app name, the page count, flags, the date stamp, and signature-related data.

The public header descriptions match the ROM parser and the local app corpus. Useful references are WikiTI’s application-header and certificate/header format pages, TI’s AppHeader guide, and Tari’s Cemetech disassembly note, which describes .8xk data as Intel HEX pages based at 0x4000 and app code as starting after field 807.

Common app-header fields in the sample corpus:

The app header is not a fixed 128-byte struct. The 807 final field terminates it. The common 80 7F 00 00 00 00 form uses size nibble F with a four-byte zero, but WikiTI documents that length as ignored; the shorter 80 70 form is valid. The app body begins after the final field and any app-controlled padding. Bytes before the conventional 4080 entry point are not loader magic; they are field payload or padding, and an app can choose payload bytes that also decode as Z80. [standard]

External sample check (not ROM evidence): the local Axe Parser Axe.8xk sample decodes to a base page whose 020D date-stamp-signature field starts at 4027 and has a 64-byte payload. Part of that payload is a Z80 helper at 4037:

ti-kid identified this Axe header case and published an annotated decode in Hatchet-Compiler; the local decode below uses that lead and verifies it against the extracted Axe.8xk bytes.

4037  POP AF
4038  POP BC
4039  POP DE
403A  POP HL
403B  PUSH HL
403C  PUSH DE
403D  PUSH BC
403E  PUSH AF
; ...
4056  LD A,0C9h
4058  CPIR
405A  PUSH HL
405B  IN A,(6)
405D  DEC A
405E  LD HL,4065h
4061  RST 20h
4062  JP 8478h
4065  OUT (6),A
4067  RET

RST 20h is _Mov9ToOP1, so the helper copies the thunk at 4065 into OP1 (0x8478) and jumps to OP1. That makes OUT (6),A; RET run from RAM after A has been set to the current bank-A page minus one. The preceding CPIR searches from HL for a RET byte (0xC9) and pushes the byte after it as the return address. The first half preserves the popped registers while it probes caller-owned bytes and can return early; the later page switch and RAM-thunk behavior are directly decoded from the sample bytes.

The same sample’s conventional entry area at 4080 starts NOP; JR 408C; JP 4097; JP 4548. tools/app_header_re.py reproduces this pass: --fetch-known downloads a local corpus from ticalc.org into ignored tools/app-samples/, and --markdown prints the decoded header table. The corpus keeps the same parser boundary rule:

So 4080 is a common app-entry convention, not the OS’s header parser boundary. Some apps end the parsed header at 4029, 4070, or exactly 4080, and all remain valid because the 807 final field terminates the header.

The public entry points for walking these fields are bcalls in ti83plus.inc: _FindAppHeaderSubField (bcall 0x80AB) locates a field in an app header, and _FindOSHeaderSubField (bcall 0x8075) does the same for the OS header. Both build on the generic walkers _FindSubField (bcall 0x805D), _FindGroupedField (bcall 0x8030), and _GetFieldSize (bcall 0x805A), which decode the TLV length nibble shown above. These IDs sit in the boot-page bcall range (0x8000+); the 0x8040/0x8070/0x8080 helpers the OS also reaches are a distinct group in the same range and are not these field walkers. The body addresses behind these public entry points are not defined functions in the disassembly.

1.2 _FindApp / _FindAppUp / _FindAppDn [confirmed]

• _FindApp (3D:5EE3) — locate an app by name (OP1). Inits the search page, then loops app_find_next_page (5FB1) + a header-match step until done, returning the app’s start page and a found/not-found flag via RST 28 (bcall) into RAM flash helpers.

  5EE3 CALL 727D            ; flash_set_sector_cnt -> appSearchPage (0x82A3)
  5EE6 CALL 5FB1            ; step to next candidate page (DEC appSearchPage)
  5EE9 RET C                ; ran off the end -> not found
  5EEA CALL 5EB2            ; read/compare this page's header
  5EED BIT 3,C; JR Z,5EE6   ; not a match -> keep scanning
  

• app_find_next_page (3D:5FB1) — appSearchPage (0x82A3) -= 1; stops at page 7 (low boundary of the app region); bjumps appSearchPage:0x4000 to inspect the header.
• flash_set_sector_cnt (3D:727D → helper 726E) — initializes 0x82A3 to the model-selected page base plus one.
• _FindAppUp (5DDA) / _FindAppDn (5DE6) — enumerate the previous / next app in flash (for the APPS-menu list), both wrapping the common walker _app_5de7 (5DE7). _app_5de7 keeps two counts in BC (apps before/after) and tracks the current name in OP3.
• _FindAppNumPages is present in the bcall table (3D:4AA3), but the disassembly has no function record at that address.

State variables: appSearchPage = 0x82A3, 0x8497/0x8481/0x9C87 are search-mode scratch (0x9C87=‘i’ selects the in-RAM “temp app” search variant).

1.3 Launching an app as a context [confirmed]

_AppInit (ram:0936, bcall 0x404B) installs a context from an app header:

_AppInit(byte *hdr):                 ; HL -> 13-byte vector block in the header
  copy 12 bytes hdr[0..11] -> cxMain (0x858D)   ; the 6 context vectors
  flags.appFlags (IY+0x0D) = hdr[12]            ; appFlags byte
  cxPage (0x8599) = port_mapBankA               ; the flash page the handlers run from

The 12 bytes are the 6 little-endian handler pointers (cxMain, cxPPutAway, cxPutAway, cxRedisp, cxErrorEP, cxSizeWind — see doc 11 §Context block). Example: the OS’s own default app vectors live at 3B:7571:

3E 75 | 4B 75 | 9F 74 | 4B 75 | 4B 75 | 4B 75 | 0A
cxMain=753E cxPPutAway=754B cxPutAway=749F cxRedisp=754B cxErrorEP=754B cxSizeWind=754B appFlags=0A

_ReloadAppEntryVecs (3B:73E4, bcall 0x4C36) calls _AppInit on that block, then overrides cxErrorEP (0x8595)=0x27D9. After _AppInit, the main event loop runs the app through call_context_main (pages in cxPage, jumps (cxMain) — doc 11).

Because cxCurApp (0x859A) is a key code, pressing a mode key selects the context to load (doc 11). The App quit restore-path candidate at 3B:7412 is not a defined function in the disassembly; the saved-context restore behavior stands as a byte-trace note (the label is project-local, not a WikiTI or ti83plus.inc equate).

2. RAM clearing / memory reset

The MEM menu ([2nd][+], “MEMORY MANAGEMENT/DELETE” + “RESET”) and its messages are on page 0x01 (text/homescreen page). The reset engine is on page 0x35; the user-RAM re-init lands in page-0 boot code.

2.1 The user-facing strings (page 0x01) [confirmed]

2.2 The reset dispatcher (mem_reset_dispatch @ 35:7180) [confirmed]

Dispatch is on the selected reset item held in keyExtend (0x8446):

2.3 What “RAM Cleared” (RAM reset) zeroes [confirmed]

The RAM-reset path (35:719F):

719F BIT 1,(IY+0x35); JP Z,0x0B2F          ; first-stage vs full path select
71A6 LD HL,(0x9B73)                         ; preserve a saved word
71B4 LD A,(IY+0x3F); AND 0x7F               ; keep low 7 bits (clear bit 7) of flag byte 0x3F
71B9 DI
71BA LD HL,0x8000; LD DE,0x8001; LD BC,0x1BC3; LD (HL),0; LDIR   ; *** zero system RAM 0x8000-0x9BC3 ***
71C7 LD (IY+0x3F),A                         ; restore the saved low 7 bits
...   (restore IY+0x34 bit6, IY+0x35 bit0 from the preserved state)
71E0 LD HL,0x9BD0; LD DE,0x9BD1; LD BC,0x642F; LD (HL),0; LDIR   ; *** zero user RAM 0x9BD0-0xFFFF ***
71ED JP 0x0BD9                              ; re-init RAM (page-0 boot init)

So a RAM reset clears two blocks to 0:

1. System RAM 0x8000–0x9BC3 (~7 KiB: OS scratch, the Context block, system buffers).
2. User RAM 0x9BD0–0xFFFF (0x6430 = 25648 bytes, ~25 KiB: the VAT and all user variables/programs).

A handful of flag bits are explicitly preserved across the wipe (IY+0x3F bit7, IY+0x34 bit6, IY+0x35 bits0/1, and the word at 0x9B73) so the calculator knows it is mid-reset. It then JP 0x0BD9, the RAM-init entry (OUT (0) page select, LD SP,0xFFF7, then CALL 0x3EC1 — the cross-page trampoline that rebuilds the VAT, system vars, and LCD; see doc 11), which rebuilds a clean default VAT and system state and re-enters the homescreen. The Flash archive is not touched by a plain RAM reset.

2.4 Full reset (page_0/ram:0B27) [confirmed]

The harder reset (RESET ALL / power-on cold start) is at ram:0B27:

0B27 LD SP,0; ... 0B37 DI; OUT (0),0xC0
0B41 LD HL,0x8000; LD DE,0x8001; LD BC,0x7FFF; LD (HL),0; LDIR   ; zero ALL of 0x8000-0xFFFF (32 KiB)
0B4E ... preserve/inspect IY+0x3F; select sub-path; JP 0x3EA9/0x3EAF

This zeroes the entire 32 KiB RAM and does the deepest re-init.

2.5 _CleanAll / cleanup_temp_ram (07:52CF) — not a reset [confirmed]

Distinct from the MEM reset. _CleanAll (bcall 0x4A50) only compacts temporary RAM after a command finishes: it shifts the FP stack (fpBase/FPS) down to tempMem, resets the OPBase/OPS/pTemp scratch pointers, and clears pTempCnt/cleanTmp. It does not clear the VAT, user vars, or Flash (see doc 12). _FixTempCnt (07:4FEC) marks temps ≥ a count reclaimable then tail-calls the same compaction.

2.6 Flash archive GC — “Defragmenting…” / “Garbage Collecting…” [confirmed behavior; display-label addresses undisassembled]

Separate from RAM reset: when the Flash archive fills, the OS rewrites live archived vars to fresh sectors and erases the old ones. The display dispatcher sits around 3C:7E23 (shows Defragmenting... 0x4076) / 7E10/7E1C (shows Garbage Collecting... 0x4126+412E); 3C:7E00 is not a defined function in the disassembly (the label is project-local, not a WikiTI or ti83plus.inc equate). It clears 0x844B (curRow, the text-row cursor — reset before the banner draws) and runs with the screen frozen (DI). The actual sector erase/write primitives are RAM-resident (flash control port 0x14) — see doc 12.

3. MODE / settings flags

The flag bytes live in the SystemFlags area at IY = 0x89F0. The MODE screen (cxMode = kMode = 0x45) is a menu context that flips these bits; the canonical setters below show exactly which bits.

3.1 Angle: Degree vs Radian — trigFlags (IY+0) [confirmed]

trigDeg = bit 2 of trigFlags (0x89F0): 1 = Degrees, 0 = Radians. (Confirmed against WikiTI Flags:00 and the ROM — _Sin (02:7342) tests BIT 2,(IY+0) to pick the degree path.)

SET 2,(IY+0)   ; FD CB 00 D6  -> Degree
RES 2,(IY+0)   ; FD CB 00 96  -> Radian
BIT 2,(IY+0)   ; FD CB 00 56  -> tested by _Sin/_Cos/_Tan to select degree vs radian

Math routines branch on this bit to choose degree/radian variants (_SinCosRad etc. force radians; the degree paths convert first).

3.2 Graph type: Func / Param / Polar / Seq — grfModeFlags (IY+0x02) [confirmed]

The four graph-mode setters on page 0x36 are mutually exclusive: each first clears all four bits via clr_grfmode (36:7D00), then ORs in its own bit, then calls _SetTblGraphDraw. param_1 is IY, so *(param_1+2) = grfModeFlags.

clr_grfmode (36:7D00):  grfModeFlags &= 0xEF & 0xDF & 0xBF & 0x7F   ; clear bits 4,5,6,7

Each setter first calls a small predicate (36:0013/0254/0259/025E) and only re-sets the mode if the parity/condition flag (F bit6) requires it, avoiding needless redraws.

Other grfModeFlags bits (from inc, not in the setters above): bit3 grfPolar (rect↔polar coordinate readout). Related graph bytes: grfDBFlags (IY+0x04) bit0 grfDot (line/dot), bit1 grfSimul (sequential/simultaneous), bit4 grfNoCoord, bit5 grfNoAxis; seqFlags (IY+0x0F).

3.3 Numeric format: Normal/Sci/Eng, Float/Fix, base — fmtFlags (IY+0x0A) [confirmed (bits from inc)]

fmtFlags byte at 0x89FA:

So Normal/Sci/Eng = (bit0, bit1): Normal = 00, Sci = 01, Eng = 11. fmtOverride (IY+0x0B, 0x89FB) is a working copy used during conversions.

Float vs Fix N is not in fmtFlags — it is the separate byte fmtDigits = 0x97B0: value 0x00–0x09 = Fix-N decimal places, 0xFF = Float.

3.4 MODE screen plumbing

The MODE screen is a menu context (cxMode/kMode=0x45) reached via the event/key router (doc 11). Its row strings live as token names on page 0x01 (RadianN/DegreeO/NormalP/ Float at 01:49E4..4A06; trailing letters are token-id bytes) and full-caps menu labels on page 0x37 (DEGREE 4A85, RADIAN 4A8C). Selecting a row writes the flag bits documented above directly (SET/RES (IY+…), or stores into fmtDigits). [hypothesis] (partial) — the per-row write table itself is reached through the menu dispatcher and was not traced line-by-line, but every target bit/byte is confirmed from the setters and inc equates.

4. Confident space:addr index

3D:5EE3   _FindApp
3D:5DDA   _FindAppUp
3D:5DE6   _FindAppDn
3D:5DE7   _app_5de7
3D:5FB1   app_find_next_page
3D:727D   flash_set_sector_cnt
3D:7285   TLV-length candidate (inferred label); no defined function in live DB
3D:4AA3   _FindAppNumPages bcall target; no live function in current DB
ram:0936       _AppInit
ram:08AF       _PutAway
3B:73E4   _ReloadAppEntryVecs
3B:7571   default app vectors data block (12 bytes + appFlags), not a function
3B:7412   app-quit restore candidate (inferred label); no defined function in live DB
35:7180   mem_reset_dispatch
35:719F   ram_reset_wipe         (zeroes 0x8000-0x9BC3 and 0x9BD0-0xFFFF)
ram:0BD9       ram_init_after_reset
ram:0B27       full_reset_wipe        (zeroes all 0x8000-0xFFFF)
3C:7E00   archive-GC-display candidate (inferred label); no defined function in live DB
07:52CF   _CleanAll (cleanup_temp_ram)
07:4FEC   _FixTempCnt
36:7D11   _SetFuncM     (grfModeFlags bit4)
36:7D1F   _SetSeqM      (grfModeFlags bit7)
36:7D2C   _SetPolM      (grfModeFlags bit5)
36:7D39   _SetParM      (grfModeFlags bit6)
36:7D00   clr_grfmode   (clears grfModeFlags bits 4-7)

Key SystemFlags / RAM addresses

0x89F0  flags (IY base)
 +0x00  trigFlags   (bit2 trigDeg: 1=Degree,0=Radian)
 +0x02  grfModeFlags(bit4 Func,bit5 Polar,bit6 Param,bit7 Seq; bit3 grfPolar)
 +0x04  grfDBFlags  (bit0 Dot, bit1 Simul, bit4 NoCoord, bit5 NoAxis)
 +0x0A  fmtFlags    (bit0 Exponent, bit1 Eng, bit2-4 base, bit5 Real, bit6 Rect, bit7 Polar)
 +0x0B  fmtOverride
 +0x0D  appFlags
0x97B0  fmtDigits   (0-9 = Fix N, 0xFF = Float)
0x82A3  appSearchPage
0x8446  keyExtend   (reset-submenu selector 1..4; extended-key state)
0x858D  cxMain ...  0x8599 cxPage  0x859A cxCurApp   (Context block, doc 11)

13 — Flash page map

What lives on each of the 64 physical flash pages (16 KiB each). OS code occupies pages 00–07 and 33–3D; pages 08–32 are blank in this image; page 3E is the certificate sector and 3F the boot page. On a retail unit the upper pages can also carry Flash Apps, but this dump is OS-only — the page scan below reports zero Flash-App headers. The page roles below are characterized by the named bcall routines that resolve to each page (tools/bcall_targets.txt) plus function counts; the 0x8xxx cert/boot/USB bcalls come instead from ti83plus.inc and the retail segment files (bcall_targets.txt does not carry the 0x8xxx targets).

OS pages (carry bcall entry points)

Page byte-scan notes (empty range, boot & system pages)

No Flash-App headers (80 0F) appear at any page boundary; the image is OS-only [hypothesis]. Byte-level notes on the empty page range and the boot/system pages (some of which, e.g. 34–39/3B/3C, also carry the bcalls listed above):

The large-font glyph table is on page 0x07 (see Display / LCD). Alternate large fonts live on pages 1 and 0x36 (selected by (IY+0x35) bits 5/1). Page 7 is the busiest data page (archive code, list/matrix, error messages, and the large font). [confirmed]

Takeaway

The OS is page-specialized: kernel + math on page 0, one subsystem per low page. A bcall is really “run subsystem X’s routine on its page” — the page map is the subsystem decomposition, physically.

14 — RAM pages

The TI-84 Plus has banked RAM pages behind the Z80’s 16 KiB windows. TI-OS normally keeps RAM page 81 in 8000-BFFF and RAM page 80 in C000-FFFF, but ROM helpers temporarily map other pages for paged memory access. On OS 2.55MP, traces show page 83 writes during boot/home initialization and during homescreen expression entry. Programs that borrow page 83 must preserve or restore the OS-visible regions below.

Page selectors [confirmed]

The 84+ memory ports use two encodings:

This rule matches the dynamic resolver, TilEm’s x4 memory mapper, and the OS trace. In the idle boot/home trace, the RAM-window writes are:

OUT (port 7) <- 0x7f   8000-BFFF = page_3F
OUT (port 7) <- 0x81   8000-BFFF = RAM/0x81
OUT (port 5) <- 0x00   C000-FFFF = RAM/0x80
OUT (port 7) <- 0x80   8000-BFFF = RAM/0x80
OUT (port 7) <- 0x81   8000-BFFF = RAM/0x81
OUT (port 5) <- 0x02   C000-FFFF = RAM/0x82
OUT (port 7) <- 0x83   8000-BFFF = RAM/0x83
OUT (port 7) <- 0x81   8000-BFFF = RAM/0x81
OUT (port 5) <- 0x00   C000-FFFF = RAM/0x80

The final restore values are therefore port 7 = 0x81 and port 5 = 0x00 for normal OS execution.

Page map [standard, cross-checked]

WikiTI’s RAM pages page is a useful public map, but OS 2.55MP needs the page-83 warnings to be read literally. The local dump at wikiti-dump/main/83Plus:OS:Ram Pages.wiki carries the same current page-83 notes. The local trace and disassembly support this table:

On newer 48 KiB hardware, WikiTI says RAM pages 82-87 alias the same physical memory. WikiTI’s port 15 page identifies ASIC value 55h as the 48 KiB TA1 ASIC. Programs that use page 83 must not treat 82-87 as independent storage on that hardware. [standard]

Per-page trace coverage [confirmed]

The boot/home and 2+3 ENTER traces exercise startup, homescreen initialization, display capture, parsing, evaluation, and previous-entry storage. They do not exercise app launch, USB transfer, graph drawing, archive cleanup, or a 48 KiB ASIC. Within that scope, physical RAM-page writes are:

The zero-write rows mean “not hit by these scenarios,” not a global proof that the page is never used. On 48 KiB hardware, pages 82-87 alias page 83, so writes intended for 84-87 would not be independent storage even if a program can select those page numbers. [standard]

The graph scenario in tools/macros/graph-y1-x2.macro reaches the graph screen and still only writes pages 80, 81, and 83. It increases normal page-80/81 activity but leaves page-83 at the same confirmed ranges as the idle trace. It does not hit pages 82 or 84-87. [confirmed]

How to hit the confirmed paths

The useful distinction is between “page number can be selected” and “the OS uses it in a normal workflow.” These paths are confirmed or have a concrete next scenario:

The computed bank-pair helpers use this selector formula:

    LD A,B
    SLA A
    OUT (5),A        ; pair index 0/1/2/3 -> pages 80/82/84/86 in bank C
    INC A
    OR 0x80
    OUT (7),A        ; pair index 0/1/2/3 -> pages 81/83/85/87 in bank B

Decoded callers set B = 1, selecting pages 82/83; that explains the observed port 5 = 02, port 7 = 83 sequence. Pages 84–87 are reachable through the helper but are not selected on any observed OS path [hypothesis]. The B = 1 caller pattern is confirmed for the decoded callers above. [confirmed]

Page 83 use [confirmed and standard]

Page 83 is the page people most often borrow as scratch, but the ROM uses it as more than anonymous free RAM. Keep the evidence classes separate:

Ghidra identifies the page-83 block-copy helper at ram:1868. It saves the current port-6 value, writes 0x83 to port 6, runs LDIR, and restores the previous page through the page-set helper:

ram:1877  IN A,(6)
ram:1879  PUSH AF
ram:187A  LD A,0x83
ram:187C  OUT (6),A
ram:187E  LDIR
ram:1880  POP AF
ram:1881  CALL 0x181C

Ghidra identifies the LCD capture helper at ram:1890. It maps page 83, waits on the LCD, reads port 11, and stores each byte through HL:

ram:189F  IN A,(6)
ram:18A1  PUSH AF
ram:18A2  LD A,0x83
ram:18A4  OUT (6),A
ram:18A6  CALL 0x0CC3
ram:18A9  IN A,(0x11)
ram:18AB  LD (HL),A

The reset path on page 37 initializes the previous-entry pointers:

37:6E0D  LD HL,0x577E
37:6E10  LD (lastEntryPTR),HL
37:6E13  LD HL,0x0000
37:6E16  LD (numLastEntries),HL

Page 38 has a second clear path with the same pointer reset:

38:422D  LD HL,0x577E
38:4230  LD (lastEntryPTR),HL
38:4233  LD HL,0x0000
38:4236  LD (numLastEntries),HL

The homescreen entry-history code on page 33 uses the same constants and variables:

33:53D1  LD A,(numLastEntries)
33:53E2  LD HL,0x5A7E
33:53F7  LD HL,0x577E
33:5430  LD A,(numLastEntries)
33:543A  LD DE,0x577E
33:5451  LD DE,0x577E
33:5459  LD (lastEntryPTR),HL
33:5462  LD HL,numLastEntries
33:5465  INC (HL)

If a program modifies the history buffer on page 83, clearing numLastEntries at 0x8E29 prevents the homescreen from scrolling back into invalid entry data. That is the public WikiTI recovery advice, and the ROM confirms that 0x8E29 is the OS-visible previous-entry count. [standard, address confirmed]

Dynamic test scenarios

The trace analyzer maps TilEm memory-write records back to physical RAM pages. Use it with full-range traces:

ROM=/path/to/ti84plus_2.55mp_complete.rom
tilem2 --headless --rom "$ROM" --model ti84p --normal-speed --reset \
  --macro tools/macros/boot-idle.macro \
  --trace /tmp/page83-idle.trace --trace-range all
tilem2 --headless --rom "$ROM" --model ti84p --normal-speed --reset \
  --macro tools/macros/home-2plus3.macro \
  --trace /tmp/page83-2plus3.trace --trace-range all
tilem2 --headless --rom "$ROM" --model ti84p --normal-speed --reset \
  --macro tools/macros/graph-y1-x2.macro \
  --trace /tmp/page83-graph.trace --trace-range all
python3 tools/analyze_ram_page_trace.py /tmp/page83-idle.trace --page 0x83
python3 tools/analyze_ram_page_trace.py /tmp/page83-2plus3.trace --page 0x83
python3 tools/analyze_ram_page_trace.py /tmp/page83-graph.trace --page 0x83

The baseline idle trace writes:

RAM page 0x83 writes: 1882
unique page addresses: 1114
range 43D9-44BD
range 5A7E-5DF2

The 2+3 ENTER trace writes:

RAM page 0x83 writes: 3467
unique page addresses: 1163
range 4373-4390
range 43D9-44BD
range 577E-5790
range 5A7E-5DF2

The before/after RAM variables line up with the previous-entry write:

Those values come from end-of-trace RAM reconstruction. The added page-83 range 577E-5790 is exactly the bytes between the old and new lastEntryPTR values. [confirmed]

Restoring after page 83

Restore the selector for every window you changed. For code entered from normal TI-OS state that temporarily maps page 83 into bank B (8000-BFFF) and page 82 into bank C (C000-FFFF), restore the two RAM windows this way:

    LD A,0x81
    OUT (7),A        ; 8000-BFFF back to RAM page 81
    XOR A
    OUT (5),A        ; C000-FFFF back to RAM page 80

For code that maps page 83 into bank A (4000-7FFF), preserve and restore port 6:

    IN A,(6)
    PUSH AF

    LD A,0x83
    OUT (6),A        ; map RAM page 83 at 4000-7FFF
    ; use 4000-7FFF here

    POP AF
    OUT (6),A        ; restore previous Flash/RAM page selector

Keep the nonstandard mapping inside a short critical section. The OS helper preserves interrupt state around the temporary RAM-page mapping so the interrupt handler does not run with bank A or bank B pointing at page 83.

For code that may be called with nonstandard paging, preserve and restore the selectors for all touched windows:

    IN A,(6)
    PUSH AF
    IN A,(7)
    PUSH AF
    IN A,(5)
    PUSH AF

    LD A,0x83
    OUT (7),A        ; map RAM page 83 at 8000-BFFF
    ; use 8000-BFFF here

    POP AF
    OUT (5),A
    POP AF
    OUT (7),A
    POP AF
    OUT (6),A

The OS’s own paged byte-store helper at 37:44AE uses the normal restore pattern:

37:44D0  OUT (5),A        ; A = page index << 1, trace case A = 0x02 (→ RAM page 82)
37:44D2  INC A            ; A = 03
37:44D3  OR 0x80          ; A = 0x83
37:44D5  OUT (7),A        ; trace case: 0x83
37:44D7  LD A,B
37:44D8  LD (DE),A        ; byte store while RAM page 83 is visible
37:44D9  LD A,0x81
37:44DB  OUT (7),A
37:44DD  XOR A
37:44DE  OUT (5),A

The dynamic trace resolves the same sequence at instruction indices 712241-712250, including the final port 7 = 81 and port 5 = 00 writes. [confirmed]

05 — Variables & the VAT (Variable Allocation Table)

Deep dive: Variables, Archive & Unarchive — Store/Recall, the byte-verified _FindSym walk, and archive/unarchive.

Every named object the user creates — reals, lists, matrices, strings, programs, pictures, appvars, groups — is catalogued in the VAT, a table in RAM that grows downward from a fixed top. The VAT stores metadata + where the data lives; the data itself sits elsewhere in RAM (or in archived flash).

Object types — TIVarType enum [confirmed — generated tools/ty_vartype.txt, per ti83plus.inc]

The active object’s type byte is held in varType (0x85D0); the current var being processed in curType (0x8450). Both are typed TIVarType in the DB.

How a variable is named/found

The OS passes variable identity through OP1 as a “name string”: OP1[0] = type byte, OP1[1..] = the name (token/bytes). The lookup/create family all key off OP1:

_CreateReal (recovered): sets the type byte and a fixed size of 9, then jumps to the common create core at 00:1011. That core stores the type, type-checks the object (chk_type_not_str at ram:2045), handles the complex-list special case (OP1.exp == 0x5D), applies the 6-character name limit (00:1023 CP 0x7; 00:1025 JP NC,00:2700 → LD A,0x88, E_Syntax), and carves the gap via the internal routine at ram:0F0C (00:1034). Aggregate creators (lists/matrices) instead enter through the size prelude var_alloc (00:1005), which computes count×element-size + the 2-byte header and raises E_Memory on overflow (JP C,00:2721 at 00:1008 → LD A,0x8E) before falling into the same 00:1011 core.

Variable data formats — rendered as C [confirmed from the _Create* family / DB types]

A VAT entry points at the variable’s data, whose layout depends on the object type. Every numeric value is a 9-byte BCD TIFloat (see Floating-Point); aggregates are a small header followed by an element array or a tokenized blob. These mirror the project’s DB types (TIFloat, TIComplex, TIListHdr, TIMatrixHdr), with fields shown in ROM byte order:

/* ── numeric primitives ───────────────────────────────────────────── */
typedef struct {
    uint8_t type;          /* 0x00 real, 0x80 negative; 0x0C/0x8C = complex part  */
    uint8_t exp;           /* base-10 exponent, biased by 0x80 (0x80 == 10^0)     */
    uint8_t mantissa[7];   /* 14 packed BCD digits, normalized d.dddddddddddddd   */
} TIFloat;                                                       /* 9 bytes  */
typedef struct { TIFloat re, im; } TIComplex;                   /* 18 bytes */

/* ── aggregate data (what the VAT entry's dataAddr points at) ──────── */
struct List   { uint16_t count;       TIFloat elem[/* count */];         }; /* ListObj 1; CListObj 0x0D uses TIComplex[] */
struct Matrix { uint8_t  rows, cols;  TIFloat elem[/* rows * cols */];  }; /* MatObj 2, column-major; dim0=rows first (byte-confirmed in sub-matrix-list.md; the TIMatrixHdr DB type labels these cols,rows — reversed) */
struct Tokens { uint16_t size;        uint8_t body[/* size */];          }; /* EquObj 3, StrngObj 4, ProgObj 5/6 — tokenized */
struct AppVar { uint16_t size;        uint8_t data[/* size */];          }; /* AppVarObj 0x15 — RAW bytes, not tokenized     */

Per object type:

WindowObj/ZStoObj (0x0F/0x10) hold the graph Window settings, TblRngObj (0x11) the table range, BackupObj (0x13) a full RAM image — all system, fixed-shape blobs.

Aggregate creators size their data region (= count × element-size + 2-byte header) in the var_alloc prelude (ram:1005), then fall into the common create core (ram:1011), which carves the gap via the internal routine at ram:0F0C (the create path’s own block-move, not the public _InsertMem; see 12). The specific _Create* routine then writes the data header after the core returns — e.g. _CreateRList writes the list count, _CreateStrng the 2-byte size word. All key off the name in OP1 (OP1.exp is the name’s token class — _CreateRList validates a list-name token 0x5D/0x24/0x3A/0x72).

The VAT entry [confirmed — byte-verified vs findsym_scan]

The VAT grows downward from symTable (0xFE66); _FindSym (00:0E65 → findsym_scan 07:565F) scans down, matching the name in OP1. Fixed-token names (reals, complex, L-lists, [A]-matrices, system vars) are matched by a short 1–3 byte compare against OP1’s 0x8479–0x847B; length-prefixed names (programs, appvars, groups) branch to a separate name scanner at 07:55D1 that compares the full name. On a match it reads the entry’s metadata at fixed offsets relative to the matched name pointer N:

Because the VAT grows downward, the type byte sits at the higher address and the name at the lower, so the scanner reads metadata upward from the matched name (this is the reverse of a forward C-struct order). _FindSym/_ChkFindSym return the page in B (0 ⇒ data in RAM). For an archived var the data address points into Flash and the page byte selects the page; the VAT entry itself always stays in RAM (only the data moves to Flash).

Names come in two encodings:

• Token-named vars — real, complex, L-lists (tVarLst 0x5D), [A]-matrices (tVarMat 0x5C), system vars, and the token-named strings (tVarStrng 0xAA + id) and equations (tVarEqu 0x5E + id) — carry a fixed name token, matched by the 1–3 byte compare above.
• Length-prefixed names — programs, appvars, groups — store the name bytes with a length byte at the higher address; the scanner at 07:55D1 reads the length byte, then compares the name bytes that precede it (downward, toward lower addresses — the same high-address-first ordering as the rest of the entry).

Strings (Str1–Str0) — a distinct object type [confirmed]

String variables are StrngObj (type 4) — not equation variables (EquObj = 3), although both hold tokenized byte streams. The ten strings Str1…Str0 are named by a 2-byte token: lead tVarStrng (0xAA) then tStr1…tStr0 (0x00…0x09), so Str1 = AA 00 … Str0 = AA 09.

Storage. _CreateStrng (id 0x4327, 00:1123) decompiles to create_var_entry(StrngObj) followed by writing a 2-byte word size into the data; the data area is then [word size][size tokenized bytes] — the same [size][bytes] shape programs and appvars use (above). The bytes are TI-BASIC tokens, not raw ASCII: a string stores exactly the token stream the editor renders, so "sin(A)" keeps the sin( token, the A token, and ) — which is why a string can hold any displayable token, commands included.

String vs. equation variable. Both hold tokenized byte streams, so the two are worth separating. EquObj vars (Y1–Y0, parametric, polar, sequence) are system variables that carry a selection/style flags byte and are auto-evaluated by the grapher, table, and solver (see Graphing, Table & Y= Variables). A StrngObj is an inert user variable — no selection/style, never evaluated on its own; it is bytes the string commands manipulate.

Bridges between the two. Tokens convert a string’s text to/from executable form:

• expr( parses a string’s token bytes as an expression and evaluates it → a value (string → number/list/…).
• String►Equ( / Equ►String( (2-byte tokens BB 56 / BB 55 — t2ByteTok 0xBB then tStrngToEqu 0x56 / tEquToStrng 0x55) copy token bytes between a Str and a Y=/equation variable (string ↔ equation).
• sub(, length( (_StrLength, id 0x4C3F → 36:7F91), and inString( operate on the token bytes; _StrCopy (0x44E3 → 00:2810) is the byte mover. The " string-literal delimiter in source is its own token, tString (0x2A).

FindSym scan and VAT entry layout

The _FindSym scan loop and per-class VAT entry layout are byte-verified in Variables, Archive & Unarchive (findsym_scan@07:565F; tSymPtr1/tSymPtr2 and archived-var resolution covered there).

06 — Floating-point engine

Deep dive: Calculation Engine — ×, ÷, ^, roots, the transcendentals (sin/cos/ln/eˣ), and number formatting.

All TI-BASIC arithmetic runs through a BCD floating-point engine centered on the OP registers in RAM. The engine lives mostly on flash page 0 (it’s hot), with the RST-30 shortcut for the most common op.

Number format — TIFloat (9 bytes on disk) [confirmed]

+0  type      0x00 = real (positive), 0x80 = negative real;
              0x0C/0x8C = complex (paired with the imaginary part)
+1  exp       base-100? no — base-10 exponent, biased by 0x80 (0x80 = 10^0)
+2..+8  mantissa   7 bytes = 14 packed BCD digits, normalized d.dddddddddddddd

As a C struct:

typedef struct {
    uint8_t type;          /* +0: 0x00 real (positive), 0x80 negative; 0x0C/0x8C complex part */
    uint8_t exp;           /* +1: base-10 exponent, biased by 0x80 (0x80 == 10^0)             */
    uint8_t mantissa[7];   /* +2..+8: 14 packed BCD digits, normalized d.dddddddddddddd        */
} TIFloat;                                              /* 9 bytes on disk / in a stored var   */
/* In an OP register slot the number occupies 11 bytes: the 9 above plus 2 trailing guard      */
/* digit bytes (OP1EXT at +9/+10) used during math — see "OP registers" below.                 */

The stored value is

$$v = \pm\,(d_0.d_1d_2\cdots d_{13})\times 10^{\,e-\mathtt{0x80}}$$

where $e$ is the biased exponent byte and $d_0\ldots d_{13}$ are the 14 BCD mantissa digits. A ROM-byte scan found roughly 126 candidate BCD constants ROM-wide [hypothesis] ($\pi/180 = 1.745\ldots\mathrm{e}{-2}$, $180/\pi = 5.729\ldots\mathrm{e}{1}$, 65536, plus the FP transcendental coefficient tables on page 0x02). The table addresses below are confirmed by Ghidra disassembly and raw ROM bytes.

OP registers — 11 bytes each [confirmed]

OP1–OP6 at 0x8478, spaced 11 bytes (OP2=0x8483 …). The extra 2 bytes past the 9-byte number are extended guard digits used during math: OP1EXT/OP2EXT = bytes +9/+10 (seen in _FPAdd as 0x8481/0x8482). OP1 is the primary accumulator; most routines take their argument in OP1 (and OP2 for binary ops) and return in OP1.

Core operations [confirmed from disassembly]

Every binary operation has the shape OP1 ∘ OP2 → OP1. Add and subtract walk the same five stages below; multiply and divide instead combine exponents (add them for ×, subtract for ÷) and multiply/divide the mantissas. Because the format is sign-magnitude BCD, the sign is settled separately — negating a value is a single XOR 0x80 on its type byte — so the digit work always runs on a non-negative 14-digit mantissa:

flowchart LR
    A["clear guard digits<br/>fp_clear_guard"] --> B["align exponents<br/>shift smaller right by Δ"]
    B --> C["BCD digit op<br/>add / sub / mul / div"]
    C --> D["renormalize<br/>back to d.dddd…"]
    D --> E["round on guards<br/>write type/exp to OP1"]

The page-0 entry points — the hottest get a one-byte RST shortcut, which is why FP code is dense with RST 30h/08h/20h:

Alignment, then the worked example — _FPAdd

To combine $x=(-1)^{s_x} m_x\times 10^{e_x}$ and $y=(-1)^{s_y} m_y\times 10^{e_y}$, the engine first aligns to the larger exponent. With $e_x \ge e_y$ it shifts $m_y$ right by

$$\Delta = e_x - e_y \quad(\text{digit shifts})$$

one nibble per fp_shift_right_digit call; if $\Delta > 15$ the smaller operand falls entirely past the 14 mantissa digits plus the 2 guard digits and is dropped. It then adds the aligned mantissas when the signs match ($s_x = s_y$) and subtracts when they differ ($s_x \ne s_y$), fixing the result’s sign afterward — the essence of sign-magnitude arithmetic:

\begin{algorithm}
\caption{\texttt{\_FPAdd}: $OP1 \gets OP1 + OP2$ (sign-magnitude BCD)}
\begin{algorithmic}
\IF{$OP2 = 0$}
    \RETURN $OP1$
\ENDIF
\IF{$OP1 = 0$}
    \STATE $OP1 \gets OP2$ \COMMENT{incl. extended bytes}
    \RETURN $OP1$
\ENDIF
\STATE $\Delta \gets \mathrm{exp}(OP1) - \mathrm{exp}(OP2)$ \COMMENT{\texttt{fp\_exp\_diff}}
\STATE shift the smaller mantissa right by $|\Delta|$ digits to align \COMMENT{\texttt{fp\_shift\_right\_digit}}
\IF{$|\Delta| > 15$}
    \RETURN larger operand \COMMENT{other is negligible}
\ENDIF
\IF{$\mathrm{sign}(OP1) = \mathrm{sign}(OP2)$}
    \STATE $\mathrm{mantissa} \gets$ BCD-add
\ELSE
    \STATE $\mathrm{mantissa} \gets$ BCD-subtract; fix result sign \COMMENT{\texttt{fp\_sub\_mantissa}}
\ENDIF
\STATE round via the guard digits, renormalize, store exp/type in $OP1$
\RETURN $OP1$
\end{algorithmic}
\end{algorithm}

This is the canonical sign-magnitude BCD add. The full helper cluster is documented below.

Dynamic confirmation. Traced under headless TilEm: the 2+3 run (home-2plus3.macro) enters _FPAdd and — signs equal — falls through the sign test to fp_add_mantissa (ram:1cb9), while the 5−2 run (fpsub.macro) negates OP2 and takes the opposite-sign branch into fp_sub_mantissa (ram:1d37). fp_sub_mantissa has 0 hits in the add trace and the add path 0 hits in the subtract trace, so the pseudocode’s sign dispatch is confirmed both ways.

The FP helper cluster [confirmed]

These five page-0 primitives are shared by add/sub/mult/div and the transcendentals. All were decompiled and disassembled in this ROM; the fp_* names below are the project’s labels (in tools/names.txt). They operate on the OP-register guard region (OP1EXT/OP2EXT are 2 bytes each, at 0x8481–0x8482/0x848C–0x848D — fp_clear_guard zeroes all four) and the 7-byte mantissas of OP1 / OP2 (OP1M 0x847A / OP2M 0x8485, two bytes past the type/exponent bytes at 0x8478/0x8483).

ram:1d2f and ram:1d37 are two entry points into the same BCD-subtract body — 1d2f loads HL=0x8481 (OP1 guard), DE=0x848C (OP2 guard) and computes OP2 − OP1 into OP2 (LD A,(DE); SUB (HL)), while 1d37 enters with the pointers swapped for the reverse OP1 − OP2, before joining the common loop — so the caller picks the subtraction direction by choosing the entry. This is what lets _FPAdd produce a non-negative magnitude and then fix the sign.

Multiply/divide/transcendentals (on page 0x02) reuse the same align/normalize primitives.

Floating-point stack (FPS) [standard]

FPS (0x9824) is a software stack for temporaries; _PushRealO1 (= RST 18h, ram:155C), _PushReal, _PopRealO1 through _PopRealO6, _PopReal, _AllocFPS, and _DeallocFPS manage it. Used to spill OP registers during nested expression evaluation.

Multiply / divide / transcendentals [confirmed — located]

The rest of the FP op set lives alongside add on page 0, with the transcendentals banked to page 0x02:

See Calculation Engine for the ×/÷/^/root algorithms and number formatting.

Transcendental method [confirmed]

The ln/e^x/sin-cos evaluators are local page-0x02 code plus page-0x02 coefficient tables. The apparent LD A,n; CALL ram:2362 “page switch” sites are not banked series tails: Ghidra disassembly shows ram:2362: CALL ram:3DD1, and ram:3DD1 is a bcall-table entry whose inline descriptor is 1E 7D 02 (02:7D1E). The real banked-call helper is ram:2B09. ram:2362 fetches the page-0x02 coefficient indexed by A and then multiplies OP1 by it (it enters the _FPMult body at ram:2392). Therefore the preceding LD A,n is a coefficient-table index, not a target flash page. Raw ROM bytes at the supposed same-address page-0x03 targets are 0xFF, and Ghidra has no page-0x03/page-0x06 functions there.

The shared algorithm — digit-by-digit pseudo-division [confirmed]

The forward log and exp evaluators are a digit-by-digit pseudo-division recurrence — the algorithm BCD calculators have used since the 1960s. The table gives it away: 02:7181’s 16 rows are exactly $\log_{10}(1+10^{-k})$ for $k=0\ldots15$ (matched to 14 digits — [00] = log₁₀2, [01] = log₁₀1.1, [02] = log₁₀1.01, …), which is precisely the per-step increment such a recurrence consumes. The recurrence runs on shift-and-add alone: scaling a BCD number by $1+10^{-k}$ is $x + (x\text{ shifted right }k\text{ digits})$, one fp_shift_right_digit (ram:1bea) plus one BCD-add, so the digit-by-digit recurrence core needs no general multiply (only the base-conversion scaling via CALL ram:2362 enters _FPMult). (The traces show the shift 1bea is shared, but the running-add entry differs: _EToX uses fp_add_mantissa ram:1cb9, while _LnX uses the sibling BCD-add entry ram:1ca9 — 1cb9 fires 0× in the ln(2) loop, 1ca9 0× in the e¹ loop.)

Logarithm. With the exponent already split off so the mantissa is $x\in[1,10)$, the loop (02:6F80–6FEE) drives $x$ up toward $10$ by repeatedly scaling by the largest table factor that doesn’t overshoot; the number of scalings at each position is the corresponding digit of the answer, and the running sum of the table entries is the logarithm:

\begin{algorithm}
\caption{Logarithm by pseudo-division (table $c_k=\log_{10}(1+10^{-k})$ at \texttt{02:7181})}
\begin{algorithmic}
\REQUIRE reduced mantissa $x \in [1,10)$, accumulator $L \gets 0$
\FOR{$k = 0$ \TO $15$}
    \WHILE{$x \cdot (1+10^{-k}) \le 10$}
        \STATE $x \gets x + (x \gg k\text{ digits})$ \COMMENT{$\times(1+10^{-k})$ is a BCD shift-add}
        \STATE $L \gets L + c_k$ \COMMENT{add count = the $k$-th digit of the answer}
    \ENDWHILE
\ENDFOR
\RETURN $\log_{10}x = 1 - L$ \COMMENT{$x$ driven up to $10$; then $\ln x = \log_{10}x \cdot \ln 10$}
\end{algorithmic}
\end{algorithm}

The code’s two passes — the AND 0x8 then BIT 4 stops at 02:6FAD/6FD3 — are the coarse digits ($k=0\ldots7$) and the fine digits ($k=8\ldots15$). The selector C chooses the base: $\ln x = \log_{10}x \cdot \ln 10$, with $\ln 10$ fetched from 02:7D42[06] by the LD A,6; CALL ram:2362 tail at 02:704A (_LogX skips that final multiply).

Exponential. _EToX/_TenX (02:7066+) run the same table backwards — consuming the fractional part $y$ digit by digit, subtracting $\log_{10}(1+10^{-k})$ while building $10^{y}=\prod_k(1+10^{-k})^{d_k}$ into an accumulator, again with only shift-adds:

\begin{algorithm}
\caption{Exponential by pseudo-multiplication (same table, run in reverse)}
\begin{algorithmic}
\REQUIRE $y = $ fractional part of $x\log_{10}e$, accumulator $A \gets 1$
\FOR{$k = 0$ \TO $15$}
    \WHILE{$y \ge c_k$}
        \STATE $y \gets y - c_k$
        \STATE $A \gets A + (A \gg k\text{ digits})$ \COMMENT{$\times(1+10^{-k})$}
    \ENDWHILE
\ENDFOR
\RETURN $10^{y} = A$
\end{algorithmic}
\end{algorithm}

So a single 16-row table at 02:7181 powers all of ln / log / eˣ / 10ˣ; the 02:7D42 block only supplies the base-conversion constants ($\log_{10}e$, $\ln 10$) and the trig reduction constants.

Dynamic confirmation. Traced under headless TilEm: ln(2) (ln2.macro) drives _LnX, whose selector (02:6F94) steps A=00…07 then 08…0F (the coarse/fine split at the 6FAD AND 0x8 / 6FD3 BIT 4 tests), walking successive 02:7181 rows with a per-step shift-add, then fetches $\ln 10$ via LD A,6; CALL ram:2362 and multiplies. e^{1} (exp1.macro) drives _EToX, which consumes the same table in reverse (the inner step is fp_sub_mantissa 1d37, the accumulator add fp_add_mantissa 1cb9), selector sweeping 00…0F under the 710A CP 0x0F bound. On-screen results: .6931471806 and 2.718281828.

Sin/cos (_SinCosRad) uses the same digit-recurrence shape on the range-reduced angle, but with its own near-unity scaling tables 02:7201/02:7281 (eight rows, two sign-variants each, picked by 0x84A4 bit 7) rather than Taylor coefficients — so it too is a table-driven recurrence, not a fixed polynomial. The exact rotation identity each trig row encodes is not pinned here.

_LnX — natural log (02:6EFD) [confirmed]

_LnX first calls _CkOP1Pos (ram:1E5D) and raises a domain error on x <= 0. The core (02:6F1B) splits x into mantissa × 10^exp; after a small pre-step near 02:6F45–02:6F50 (a value formed with _FPAdd (RST 30h) / _FPSub / _FPDiv ram:2541), the pseudo-division loop described above (02:6F8C–02:6FEC) steps through the shared 16-slot table at 02:7181 via 02:7301/02:7302; the first phase stops when the selector has bit 3 set (02:6FAB–02:6FAF, coarse digits) and the second when it reaches bit 4 (02:6FD2–02:6FD5, fine digits). The 02:6F70: LD A,3; CALL ram:2362 site fetches constant-table index 3, and 02:704A: LD A,6; CALL ram:2362 fetches index 6 (ln(10), the base-conversion multiply), both from 02:7D42.

_EToX — eˣ (02:705C) [confirmed]

_EToX is local page-0x02 code. It clears guard digits, then 02:705F: LD A,3; CALL ram:2362 loads constant-table index 3 (log10(e)) and then 02:7064 JR +3 skips _TenX’s entry at 02:7066 (which does its own CALL ram:2627), joining the shared body at 02:7069. The body splits the decimal exponent/integer digit shift (02:7069–02:70B6), handles sign/reciprocal cases (02:70B9–02:70D9), then evaluates the fractional part with the shared 16-row table at 02:7181. The exact loop bound is 02:7106 LD HL,0x848E; 02:7109 LD A,(HL); CP 0x0F; JR Z,02:7140, so the table-driven exp evaluator has 16 selector slots (0..15).

_SinCosRad — sin/cos in radians (02:733E) [confirmed]

This one keeps its range reduction on page 0x02 and is the most fully recovered:

1. Mode/select flags. 0x8499 holds the trig-op selector — 0x01 (sin), 0x02 (cos), 0x04 (tan) — ORed with 0x80 when (IY+0) bit 2 is clear (BIT 2,(IY+0); JR NZ,+2; OR 0x80). _SinCosRad itself enters with A=0x81, so it stores 0x81 regardless. fp_clear_guard and _ZeroOP3 initialize the work area.
2. Exponent gate. LD A,(0x8479); SUB 0x80; JP C,02:73D4; CP 0x0C; JP NC — tiny arguments (negative exponent) take a fast path at 02:73D4, and arguments with decimal exponent ≥ 12 are rejected to the slow/error path (_JError 0x84 for out-of-range), because reduction can no longer be done accurately.
3. Reduce the angle. It reduces against the stored period constants and takes the fractional part to find the quadrant. The reduction constants are the page-0x02 BCD block:
   • 02:7D81 — the 2π full-turn modulus (mantissa 62 83 18 53 07 17 96 = 6.2831853…), copied to the OP3 work reg via LD HL,02:7D81; CALL ram:1AE2 (ram:1AE2/copy7_from_8490 copies 7 mantissa bytes to 0x8490).
   • 02:7D8E, 02:7D95, 02:7D96 — companion constants used in the quadrant-fixup / remainder comparisons (CALL ram:1D7B magnitude compare at 02:73B1/02:7447). The quadrant (0–3) is accumulated in B/bStack_1 (bits 0/3/6) and decides sin-vs-cos and the result sign (the XOR 0x1 / OR 0x8 / XOR 0x8 flag juggling at 02:7424–02:7464).
4. Per-digit evaluation. After reduction (02:7475 onward, falling through 02:7488 LD A,B) the reduced argument in [0, pi/4) drives the same table-stepping digit recurrence as ln/e^x: a selector walks the coefficient table one row per step rather than unrolling a fixed polynomial. The loaders are local — 02:74AB: CALL 02:731D reads the signed table at 02:7201, 02:74EA: CALL 02:7312 reads the signed table at 02:7281 — and the selector advances under BIT 3,B / BIT 3,C in the tail (02:74DD–02:74E0, 02:75C6–02:75C8), so the walk covers eight selector rows (0..7), each carrying two 8-byte sign/phase variants. Per-row decoding of 02:7201/02:7281 is the one piece still open: the rows climb toward 10 (e.g. 02:7201[00]=9.9668…, [06]=9.999999…), the shape of a half-angle / rotation factor consumed one digit at a time.

Dynamic confirmation. Traced under headless TilEm: sin(1) in radian mode (sin1.macro) drives _SinCosRad. The flag init, the exponent gate (735D LD A,(0x8479); SUB 0x80; JP C,02:73D4; CP 0x0C; JP NC — neither branch taken, since exp(1)=0 is in [0,12)), the reduction multiply by the 02:7D81 constant (7372 LD HL,02:7D81; CALL ram:1AE2), and the table-stepping loader 02:731D returning successive rows of 02:7201 (HL = 7209/7219/…/7279, 16-byte stride) all execute as described. On-screen result: .8414709848. (Per-row coefficient meaning remains the open piece.)

Coefficient tables [confirmed]

02:7D1E zeroes the OP2 type byte, indexes 02:7D42 + 9*A, then copies the selected constant image into OP2. The only LD A,n; CALL ram:2362 uses in this cluster are A=3 (log10(e)) and A=6 (ln(10)); the later trig reduction constants are loaded directly from the same nearby block.

02:7D42 constants, 9-byte stride:
  [00] 81 57 29 57 79 51 30 82 32
  [01] 80 15 70 79 63 26 79 48 97
  [02] 7F 78 53 98 16 33 97 44 83
  [03] 7F 43 42 94 48 19 03 25 18  ; log10(e) fetch site
  [04] 80 31 41 59 26 53 58 98 00
  [05] 7E 17 45 32 92 51 99 43 30
  [06] 80 23 02 58 50 92 99 40 46  ; ln(10) fetch site
  [07] 62 83 18 53 07 17 96 31 41  ; direct trig-reduction region starts here
  [08] 59 26 53 58 98 78 53 98 16

02:7181 is the shared ln/e^x digit table loaded by 02:7301/02:7302/02:7305. It has 16 8-byte rows:

[00] 30 10 29 99 56 63 98 12  [01] 04 13 92 68 51 58 22 50
[02] 00 43 21 37 37 82 64 26  [03] 00 04 34 07 74 79 31 86
[04] 00 00 43 42 72 76 86 27  [05] 00 00 04 34 29 23 10 45
[06] 00 00 00 43 42 94 26 48  [07] 00 00 00 04 34 29 44 60
[08] 00 00 00 00 43 42 94 48  [09] 00 00 00 00 04 34 29 45
[10] 00 00 00 00 00 43 42 94  [11] 00 00 00 00 00 04 34 29
[12] 00 00 00 00 00 00 43 43  [13] 00 00 00 00 00 00 04 34
[14] 00 00 00 00 00 00 00 43  [15] 00 00 00 00 00 00 00 04

02:7201 and 02:7281 are the forward sin/cos signed recurrence tables (the per-row near-unity factors the digit loop steps through, per the shared algorithm above). Each row is 16 bytes: the first 8-byte variant is selected when 0x84A4 bit 7 is clear, and the second 8-byte variant is selected when it is set.

02:7201:
[00] 09 96 68 65 24 91 16 20 | 10 03 35 34 77 31 07 56
[01] 09 99 96 66 68 66 65 24 | 10 00 03 33 35 33 34 76
[02] 09 99 99 96 66 66 68 67 | 10 00 00 03 33 33 35 33
[03] 09 99 99 99 96 66 66 67 | 10 00 00 00 03 33 33 33
[04] 09 99 99 99 99 96 66 67 | 10 00 00 00 00 03 33 33
[05] 09 99 99 99 99 99 96 67 | 10 00 00 00 00 00 03 33
[06] 09 99 99 99 99 99 99 97 | 10 00 00 00 00 00 00 03
[07] 10 00 00 00 00 00 00 00 | 10 00 00 00 00 00 00 00

02:7281:
[00] 95 09 85 29 44 83 72 02 | 10 52 06 69 51 89 55 92
[01] 99 94 95 10 19 99 69 80 | 10 00 50 52 03 08 13 30
[02] 99 99 94 94 95 10 20 35 | 10 00 00 50 50 52 03 05
[03] 99 99 99 94 94 94 95 10 | 10 00 00 00 50 50 50 52
[04] 99 99 99 99 94 94 94 95 | 10 00 00 00 00 50 50 51
[05] 99 99 99 99 99 94 94 95 | 10 00 00 00 00 00 50 51
[06] 99 99 99 99 99 99 94 95 | 10 00 00 00 00 00 00 51
[07] 99 99 99 99 99 99 99 95 | 10 00 00 00 00 00 00 01

The forward ln, e^x, and sin/cos paths all run on the table-driven digit recurrence above — a selector that steps through a coefficient table one row at a time, on shift-and-add (ln/e^x loaded from 02:7181; sin/cos from 02:7201/02:7281). The separate arctangent engine behind inverse trig uses a base-10 CORDIC iteration, documented in Calculation Engine.

Calculation engine

TI-84 Plus OS 2.55MP — feature deep dive.

What happens between a college student typing 2*sin(π/6)+ln(5) and seeing a number. All arithmetic is BCD floating point in the OP registers (OP1–OP6 @ 0x8478, 11-byte spaced) with a software FP stack (FPS @ 0x9824) for nested temporaries. See 06-floating-point.md for the TIFloat byte format and _FPAdd internals; this doc covers the rest of the engine: ×, ÷, ^, roots, transcendentals, formatting, and errors.

Address form below is page:addr (flash page in slot 4000) or ram:addr for the fixed page-0 core mapped at 0000. Page-0 routines are reached by RST/direct CALL; everything else through the bcall dispatcher. Confidence: [confirmed] = read from disassembly, [standard] = matches documented TI behavior, [hypothesis] = inferred.

1. Register & stack model [confirmed]

Every calculation runs through the OP registers and the software FP stack; the table gives each register’s RAM address and its role during an operation.

A TIFloat is type(+0) exp(+1) mantissa(+2..+8); type bit7 = sign, bits set 0x0C = complex. exp is base-10 biased by 0x80. Sign is sign-magnitude, so negation is a single XOR 0x80.

FP-stack discipline during nested expressions [confirmed]

Binary/transcendental routines that need to preserve an operand spill it to FPS:

• _PushRealO1 (= RST 18h, ram:155C), _PushReal/_PushRealOn, _PushOP1 (ram:1599).
• _PopRealO1…_PopRealO6 (ram:150F…14F6), _PopReal (ram:1512).
• _AllocFPS/_DeallocFPS (ram:1534/1526) grow/shrink the stack frame.

Example seen in the complex-log core (_CLN, §5): it does _PushRealO1 to save the input, computes the magnitude, then _PopRealO2 to recover it for the angle — the canonical “spill then restore” used everywhere the parser evaluates a nested sub-expression.

2. Basic arithmetic [confirmed]

All four route operands through OP1/OP2, clear the guard digits, early-out on zero operands, then do BCD mantissa work and renormalize. Result in OP1.

Convenience / derived ops:

• _FPSquare ram:238A = RST 08h (OP1→OP2) then _FPMult. [confirmed]
• _Cube ram:237D = _FPSquare then _FPMult. [confirmed]
• _Times2 ram:2282 = OP1+OP1; _TimesPt5 ram:2382 loads the constant 0.5 (9-byte BCD @ ram:2635) into OP2 then _FPMult. [confirmed]
• _InvSub ram:227D = _InvOP1S then _FPAdd ⇒ OP2 − OP1 (reversed subtract). [confirmed]
• Negation: _InvOP1S ram:24BD (XOR OP1.type with 0x80, guarding against −0), _InvOP2S ram:24CD, _InvOP1SC ram:24BA (both). _CkOP1Pos ram:1E5D ANDs OP1.type with 0x80. [confirmed]

Roots & integer parts [confirmed]

• _SqRoot 02:6E38: _ErrD_OP1NotPos (→ DOMAIN if negative/complex-real), fp_clear_guard, _ZeroOP3, then a digit-by-digit BCD square-root extraction loop (ram:1C9C trial-subtract + ram:1D4A compare, halving the exponent up front). A classic long-hand sqrt, not Newton’s method.
• _Int/_Intgr ram:2621/2263: floor. _Trunc ram:2279 drops the fractional part (toward zero); _Intgr truncates then subtracts 1 (_Minus1 ram:2294) when the original was negative, giving true floor.
• _Frac ram:24E3: fractional part = x − trunc(x); shifts mantissa by the exponent and keeps the low digits.
• _Round / _RndGuard ram:2623 / 02:6A57: round to the active display-digit count; _Round is a thin cross_page_jump wrapper (body banked off page 0).

3. Degree/radian & polar conversions [confirmed]

• _DToR ram:236B (deg→rad): multiply OP1 by $\pi/180$ (ram:235D loads the constant) then normalize via ram:249E.
• _RToD ram:2374 (rad→deg): multiply by $180/\pi$ (ram:2361).
• _PToR 02:50BD polar→rectangular; pairs with the complex trig below. These constants are the BCD floats π/180 = 1.745…e-2 and 180/π = 5.729…e1 noted in 06-floating-point.md’s constant scan.

4. Cross-page dispatch (cross_page_jump @ ram:2B09) [confirmed]

Banked ROM calls use a bcall-style trampoline. cross_page_jump:

1. saves the current page (IN A,(6)),
2. builds a RET-to-page-0 trampoline on the stack (bcall return frame, page restored on exit),
3. reads a 3-byte {lo, hi, page} descriptor (page masked with 0x1F/0x3F for 83+/84+ via ports 2/0x21),
4. OUT (6),A to bank the target page in at 4000, then jumps to it.

The ln/e^x sites that look similar are local calls, not cross-page dispatches. ram:2362 calls the bcall entry at ram:3DD1, whose inline descriptor is 1E 7D 02, so it invokes the page-0x02 coefficient fetcher at 02:7D1E. In LD A,3; CALL 0x2362 / LD A,6; CALL 0x2362, the 3 and 6 are coefficient-table indexes, not target pages. _EToX falls through locally into the _TenX body at 02:7069; the ln/e^x/sin-cos coefficient tables are on page 0x02 (7181, 7201, 7281, and the constant block near 7D42), not page 0x03/0x06/0x07.

5. Transcendentals

Logarithms [confirmed]

• _LnX 02:6EFD: _CkOP1Pos; non-positive real → _ErrDomain. For a positive real it calls the real-log core (_CLN path, selector C=2); the generic entry handles complex args.
• _LogX 02:6F16: same structure, base-10 selector C=0, guards _ErrD_OP1_0/_ErrD_OP1NotPos.
• _CLN 02:6CCA / _CLog 02:6CE7 — complex log: _CAbs (magnitude) → real _LnX/_LogX for the real part, _ATan2Rad (02:76D4) for the imaginary part (the argument/angle). Uses _PushRealO1/_PopRealO2 to juggle the operand. This is why ln(-2) returns a complex result in a+bi mode but raises _ErrNonReal (0x87) in real mode.

Exponentials [confirmed]

• _EToX 02:705C (e^x): loads the log10(e) constant through ram:2362/02:7D1E, then falls through into the local _TenX body.
• _TenX 02:7066 (10^x): splits exponent into integer (digit shift) + fractional (16-slot table-driven evaluation through 02:7181). Argument too large → _ErrOverflow.

Trig — sin/cos/tan [confirmed]

• _SinCosRad 02:733E, _Sin 7342, _Cos 7346, _Tan 734A. Each loads a function selector byte into 0x8499 (1=sin, 2=cos, 4=tan; 0x80 bit set when the rad-special mode tested by BIT 2,(IY+0) is off; _SinCosRad forces 0x81).
• Range reduction: reads OP1 exponent; exponent ≥ 0x0C (|x| ≳ 10^12·) → _ErrDomain (“argument out of range”). It then reduces the angle modulo a quarter-period using the BCD constant table near 02:7D81 and runs the same table-driven digit recurrence as ln/eˣ over the signed near-unity tables at 02:7201 and 02:7281 (one row per digit step, sign-variant picked by 0x84A4 bit 7) — the per-step bcd_sub_op1_op2 (ram:1D8A) / bcd_add_8496_8480 (ram:1D26) are the shift-and-add BCD steps of that recurrence, not a fixed polynomial and not CORDIC for the forward trig. The per-row decoding of 02:7201/02:7281 is detailed in 06-floating-point.md.

Inverse trig [confirmed]

• _ASinRad 76DA, _ACosRad 76C9, _ATanRad 76CF, _ATan2Rad 76D4, plus the degree-mode _ASin/_ACos/_ATan/_ATan2 at 76F1/76DF/76E9/7749.
• _ASin/_ACos call domain check 02:79D3; |arg| > 1 → _ErrDomain.
• All inverse trig funnel into the shared arctangent CORDIC engine at 02:774B (B=0x20 seeds the octant/quadrant base written to 0x84A4; the core is a base-10 trial-subtract digit recurrence, not a fixed 32-step loop), with asin/acos expressed via atan2 of (x, √(1−x²)).

Hyperbolics [confirmed]

• _SinHCosH 7626, _TanH 762A, _CosH 762E, _SinH 7632; _ATanH/_ASinH/_ACosH at 7909/7956/7964. Same 0x8499 selector mechanism; built from _EToX (sinh = (e^x−e^-x)/2, visible in the _EToX+_FPDiv sequence near 02:6D08).

Power operator ^ [confirmed]

The general a^b lives at 02:6D08+: it computes b·ln(a) then e^() and reconstructs with _SinCosRad for the complex case — i.e. a^b = e^(b·Ln a), with _FPDiv/_FPMult glue and _OP2ToOP6/_OP6ToOP1 shuffles. Integer/√ special cases short-circuit to _FPMult/_SqRoot. This makes ^ the most FP-stack-heavy single operator a student hits.

6. Number entry & display formatting

When the homescreen shows a result (or Ans), the engine converts the OP1 TIFloat to a digit string honoring the MODE screen (Normal/Sci/Eng, Float/Fix 0–9).

• _FormReal 06:5ACF — real-number formatter. [confirmed]
  • fp_clear_guard; zero → _OP1Set0; copies arg to OP5.
  • Reads the digit-count/mode flags from (IY+0xc) and the byte at 0x89FA (active fixed/decimal-places setting; (IX-1) local holds the effective format byte).
  • Exponent thresholds drive Normal↔Sci switchover: it compares OP1.exp against 0x7D/0x7F (≈ the ±-exponent window) and renormalizes (ram:1BE7) to bring the value into the displayable mantissa range, bumping a digit counter. Negative sign decrements the leading column count (DEC (IX-3)).
• _FormEReal 06:5799 — forces scientific/E notation by setting 0,(IY+0xc) then calling _FormReal. [confirmed]
• _FormBase 06:57C0 — integer formatting in a base; requires _CkOP1Real (→ DATA TYPE / DOMAIN on non-real). [confirmed]
• _FormDCplx 06:59D3 — complex a+bi / r∠θ formatting (calls _FormReal twice). [standard]
• Exponent ↔ ASCII helpers on page 0: _ExpToHex ram:1E4E, _OP1ExpToDec ram:1E77, _DecO1Exp ram:1E6F (decrement exp), ram:1BCB (BCD-digit → value). [confirmed]
• The formatted string is then drawn by _DispOP1A (04:7844) / homescreen put-string routines (see 08-display-lcd.md).

Ans is the last-result TIFloat saved in a system var and reloaded into OP1 (via _Mov9ToOP1 = RST 20h) when the token Ans is evaluated. [standard]

7. Error handling [confirmed]

Errors are raised by loading an error code in A and jumping to _JError (ram:2793), which unwinds to the error context and shows the named message. The raiser cluster lives at ram:26E8+ — exact code map read from disassembly:

Domain pre-checks (page-0, set Z if OK else jump to _ErrDomain):

• _ErrD_OP1NotPos ram:2119 — _CkOP1Pos; not >0 ⇒ DOMAIN (used by _SqRoot, _LogX).
• _ErrD_OP1Not_R ram:2120 — _CkOP1Real; complex ⇒ DOMAIN.
• _ErrD_OP1NotPosInt ram:2125 — _CkPosInt.
• _ErrD_OP1_LE_0 ram:212A, _ErrD_OP1_0 ram:212D — zero/sign guards (e.g. ln(0)).

Where the calc engine raises what:

• ÷ 0, 1/0: _FPDiv/_FPRecip → 0x82 DIVIDE BY 0.
• ×/10^x/exponent overflow: ram:250F exponent-add → 0x81 OVERFLOW.
• √(neg), ln/log(≤0), asin/acos(|x|>1), tan(π/2), |trig arg| ≳ 10^12: 0x84 DOMAIN.
• Complex result requested in real mode: 0x87 NONREAL ANS (the _CLN/complex paths).

8. Routine index (confident, space:addr)

Arithmetic core (page 0): _FPAdd 229E, _FPSub 2297, _FPMult 238B, _FPDiv 2541, _FPRecip 253D, _FPSquare 238A, _Cube 237D, _Times2 2282, _TimesPt5 2382, _InvSub 227D, _Int 2621, _Intgr 2263, _Trunc 2279, _Frac 24E3, _Round 2623, _InvOP1S 24BD, _InvOP2S 24CD, _InvOP1SC 24BA, _CkOP1Pos 1E5D, fp_clear_guard 2627, fpmul_expadd 250F, _DToR 236B, _RToD 2374, cross_page_jump 2B09.

Transcendentals (page 02): _SqRoot 6E38, _LnX 6EFD, _LogX 6F16, _CLN 6CCA, _CLog 6CE7, pow_core 6D08, _EToX 705C, _TenX 7066, _SinCosRad 733E, _Sin 7342, _Cos 7346, _Tan 734A, _SinHCosH 7626, _TanH 762A, _CosH 762E, _SinH 7632, _ACosRad 76C9, _ATanRad 76CF, _ATan2Rad 76D4, _ASinRad 76DA, _ACos 76DF, _ATan 76E9, _ASin 76F1, _ATan2 7749, atan_cordic 774B, coeff_fetch 7D1E, trig_coeff_table 7D81.

Formatting (page 06): _FormReal 5ACF, _FormEReal 5799, _FormBase 57C0, _FormDCplx 59D3.

Errors (page 0): _JError 2793, raiser table 26E8+, domain pre-checks 2119–2131.

9. Worked flow: 2*sin(π/6)+ln(5) [hypothesis, from the above]

1. Parser pushes 2 (OP1), evaluates sin(π/6): loads π/6 into OP1, _SinCosRad/_Sin (selector 0x8499), table-driven digit recurrence → OP1=0.5.
2. ×: the saved 2 is in OP2 (or popped from FPS) → _FPMult → OP1=1.
3. ln(5): spill 1 to FPS (_PushRealO1), OP1=5, _LnX (_CkOP1Pos passes) → 1.6094….
4. +: pop 1 to OP2 (_PopRealO2), _FPAdd → OP1≈2.6094.
5. _FormReal renders per MODE; result stored as Ans.

Statistics

TI-84 Plus OS 2.55MP — feature deep dive.

What happens between a college student entering data into L1/L2, pressing STAT ▸ CALC ▸ 1‑Var Stats (or LinReg(ax+b), QuadReg, …), and seeing x̄, Σx, Sx, a, b, r, r² appear — and where every result is stored so it can be recalled by name (x̄, Σx, RegEQ, …).

This doc covers the STAT CALC computations. The data source is the L1–L6 lists (VAT/05-variables-vat.md, sub-vat-archive.md); the arithmetic is the BCD FP engine (06-floating-point.md, sub-calculation.md). Stat plots and the DISTR menu are noted in §8/§9 — DISTR functions are parser functions, not part of the STAT‑CALC engine.

Address form: page:addr (flash page in the 0x4000 slot) or ram:addr for the fixed page‑0 core at 0x0000. The whole STAT‑CALC engine lives on flash page 0x3A. Confidence: [confirmed] = read from Z80 disassembly, [standard] = matches documented TI behavior, [hypothesis] = inferred.

The Ghidra decompiler mis-renders the Z80 SET/RES b,(IY+d) flag ops, the RST macros, and cross-page CALL 0x2b09 trampolines, so the algorithm here is read primarily from the disassembly.

1. The statVars result block (0x8A3A) [confirmed]

Every STAT‑CALC result is a 9‑byte TIFloat (see 06-floating-point.md) written into a fixed RAM table beginning at statVars = 0x8A3A (statVars EQU 8A3Ah in ti83plus.inc). Entries are packed at the 9‑byte FPLEN stride. These are the system variables a student recalls by name ([2nd][STAT] ▸ VARS):

Continuing past the table (also .inc): PStat/ZStat/TStat/ChiStat/ FStat/DF/Phat…/MeanX1/StdX1/StatN1/MeanX2/StdX2/StatN2/StdXP2/ SLower/SUpper/SStat — these hold the inferential‑stats outputs (the STAT‑TESTS menu) and are written by the test commands, not by 1/2‑Var Stats. An ANOVA block anovaf_vars (F_DF/F_SS/F_MS/E_DF/E_SS/E_MS) follows.

STAT‑TESTS are separate command handlers [confirmed scope]. Z‑Test/T‑Test/χ²‑Test/ 2‑SampFTest/ANOVA( etc. come in as their own 2‑byte t2ByteTok (0xBB)‑prefixed command tokens — e.g. LinRegTTest=34h noted in §3 — and are not dispatched through _OneVar (whose token map is only F2–FF, §3). They fill the PStat…SStat/anovaf_vars block above directly. No PStat/ZStat‑writing routine appears among the page‑0x3A stat_* symbols (all of which are the _OneVar accumulate/variance/median/regression engine), confirming the tests live in their own command handlers reached from the parser’s command dispatch, separate from the STAT‑CALC engine documented here. The exact per‑test handler addresses are not exposed as named routines in this DB; those per-test handler addresses are [hypothesis]. [confirmed: separate from _OneVar]

A scratch byte 0x8A36 (immediately below statVars) holds the stat‑command discriminator (the model index, set from the command token — see §3) for the duration of the computation. Working list/element pointers used by the loop live in the OP‑scratch RAM 0x84AF…0x84DB (84D3=median data ptr, 84D5/84D7=current x/y element ptr, 84D9=sums matrix base, 84DB=freq list ptr, 84B1/84B2=loop counters, 84B3=element count). [confirmed]

Recall by name: _Rcl_StatVar (00:2149, id 0x42DC) is a page‑0 bcall trampoline (CALL 0x3E07 → dispatcher, inline id 0xC9E7) that loads the named statVar into OP1; the VAT‑level recall (_RclVarSym/_RclVarPush, see sub-vat-archive.md) routes the stat‑var name tokens (tRegEq 0x01, tStatN 0x02, tXMean 0x03, … tCorr 0x12, the STATVARS token group) to it. The name‑token values are in ti83plus.inc (tStatN=02h … tSumXY=11h, tCorr=12h, tMedX=13h, regression coeffs via tRegEq=01h). [confirmed/standard]

2. _OneVar — the STAT‑CALC engine entry (3A:6420, id 0x4BA3) [confirmed]

bcall(_OneVar) is the single entry point for all STAT‑CALC commands (1‑Var, 2‑Var, and every regression). The parser invokes it after pushing the list arguments; the command token (F2–FF, see §3) selects the behaviour.

_OneVar (3A:6420):
  SET 5,(IY+9)            ; statFlags: "stat computation active"
  LD B,0                  ; arg counter
  RES 1,(IY+0)  ; RES 1,(IY+1a)
  LD (9817),0             ; clear a status byte
  LD HL,8499 ; CALL 1b33  ; stage the parsed arg descriptor at 8499
  LD A,0FF ; LD (84af),A
  CALL _CkOP1Real (1942-ish) / arg-class checks …
  ; ---- argument parsing (6442..64de) ----
  ;   walks the parser argument list, accepting list-name tokens (0x24 list,
  ;   0x2A list-element, 0x1C/0x25/0x19 = freq/list variants); validates count;
  ;   _JError(0x8A) ARGUMENT / 0x88 SYNTAX on a bad arg list.
  ; ---- set up the data pointers (64e1..6503) ----
  LD HL,847a ; LD DE,8d2a ; CALL 1a9a  ; resolve the x-list (and y/freq) → 84D3..84DB
  POP AF ; LD (8a36),A          ; *** save the command code → model discriminator ***
  LD HL,6352 ; CALL 27da        ; install an on-error cleanup frame
  CALL 6572                     ; *** the accumulation pass (§4) ***
  CALL 2800 ; CALL 6345         ; tear down frame
  ; ---- regression coefficient region select (6506..652f) ----
  LD A,(8a36) ; CP 4 ; JR NC,..  ; A<4 ⇒ polynomial regression
       LD A,16 ; LD HL,8aee      ; coeff dest = QuadA block; … solve (§5)
  …
  SET 7,(IY+9)                  ; mark results valid
  CALL 67c1 …                   ; finalize / median (§6)

Key facts read from the disassembly:

• The command byte is saved at (0x8A36) and steers everything afterward.
• LD HL,0x8AEE (= QuadA) is the regression coefficient destination; the solver writes a,b,c,d,e there in descending order of power.
• _ErrStat (00:2741, id 0x44C2, code 0x15 “STAT”) and _ErrStatPlot (00:2759, code 0x1B) are the STAT‑specific error raisers; the _OneVar body jumps to 0x2741 on e.g. fewer than the required data points. _ErrDimMismatch (0x2715) is raised if L1 and L2/freq lengths differ (the 21bb length compare at 6584/658a).

3. STAT command token map (STATCMD = 0xF2) [confirmed]

The parser passes the command token; _OneVar stores it at 0x8A36 and treats it as a model index. From ti83plus.inc:

CubicReg/QuartReg come in as the regression tokens tCubicR=2Eh/tQuartR=2Fh; SinReg=32h, Logistic=33h, LinRegTTest=34h are 2‑byte t2ByteTok (0xBB)‑prefixed tokens (their 2Eh/2Fh/32h/33h/34h values are the second byte after 0xBB). Degree for the polynomial solver = the model index; the coefficient fan‑out into QuadA..QuartE is naturally sized by degree. [confirmed/standard]

SortA(/SortD( are separate tokens (tSortA=E3h, tSortD=E4h) with their own command handler — not _OneVar. The sort used here, stat_sort (3A:7935), is stat‑internal: its only callers are stat_median_quartile (3A:79B9) and medmed_partition (3A:760F) (xref‑confirmed), so it powers the 1‑Var median/ quartile and Med‑Med paths (§6). The SortA(/SortD( command sort is a different routine on page 0x02 (≈02:5939, comparator _CpOP1OP2) — see Matrices & Lists.

4. The accumulation pass (3A:6572 …) [confirmed]

This is the heart of 1/2‑Var Stats and the regression sum‑setup. It makes a single pass over the data list(s), accumulating the power‑sums needed for the mean, variance, and least‑squares normal equations. Read from disassembly:

6572: CALL 6f90/6f7d         ; default freq = 1 if no freq list given
6584: CALL 21bb              ; if freq list present, length-check vs x-list
                             ;   → _ErrDimMismatch (2715) on mismatch
658a: LD HL,(84d3)          ; HL = first element ptr; DE = element count
6590: LD A,(8a36)           ; dispatch on command:
   CP 8 (Med-Med) → jump to the resistant-line path (760f/75e4 → 79b9)
   else compute the matrix dimension from the degree:
        CP 1c/25/19/9 → dim=4 ; CP 5 (CubicReg) NC → dim+? ; default
   65c1: A = dim ; SUB 2 ; PUSH AF
65cd: set up x/y element pointers (84d5/84d7/84db)
65f0: ---- per-element accumulator init ----
   LD DE,8a3a ; … CALL 1a92  ; StatN slot
   LD DE,8a94                ; YMean/Σy slots
   CALL 110f                 ; allocate the sums matrix (84d9 = base)
6646..66fe: ---- per-element loop ----
   6f6a  : fetch next x (and y) list element, advance ptr
   28e4/2297 : loop bound (RST FPSub / compare)
   6567  : helper = (RST 8: OP1→OP2) ; LD HL,(84af) ; CALL 6f7d ; _FPMult (238b)
           → forms the running power x^k · freq
   238a  : _FPSquare (Σx²)
   238b  : _FPMult   (Σxy, Σx^(i+j))
   RST 30: _FPAdd    → accumulate into the matrix cell / Σ-slot
   2999/29db/29a2 : guard-clear / OP-shuffle helpers
   66fe: JP C,6655  ; loop while elements remain

So one pass builds, for a degree‑d fit, the symmetric moment matrix of power‑sums Σxⁱ (i = 0 … 2d) and the right‑hand side Σxⁱy, stored as a small 2‑D array reached by the RAM trampoline helpers 00:3A8F/3AA1/3AA7/3AAD/3AB9 (matrix‑element get/set by (row B, col C)). StatN, SumX, SumXSqr, SumY, SumYSqr, SumXY, MinX/MaxX/MinY/MaxY are filled here directly. [confirmed]

Non‑polynomial regressions transform first [confirmed]: the front‑end at 658a+ checks the command code and, for ExpReg/PwrReg (ln y), LnReg/PwrReg (ln x), pre‑applies the logarithm to each element before accumulating, then exponentiates the resulting linear coefficients off page 0x3A. The per‑element ln is in the element fetch stat_next_elem (3A:6F6A): LD A,(8A36); CP 4; RET NC then bcall _LnX at 3A:6F72 for model codes < 4 (ExpReg/LnReg/PwrReg); the back‑transform _EToX/_TenX lives on page 0x02 (see sub-calculation.md §5). This is the standard “linearize, fit a line, transform back” method; r is the correlation of the transformed data.

4a. Mean & standard deviation [confirmed]

After the pass, _OneVar finalizes the moments (3A:6762+):

6762: LD DE,8a67 ; CALL 6984   ; σx  (population) from Σx², Σx, n
6786: LD DE,8a5e ; CALL 6989   ; Sx  (sample), via _Minus1 (n→n-1) at 677c
6798: LD DE,8a55 ; CALL 6998   ; Σx² slot
67a7: LD DE,8aa6 ; CALL 6998   ; Σy²   (2-Var)

The variance helpers (3A:6984/6989/6998) implement the one‑pass formula var = (Σx² − n·x̄²)/N then √:

6998: _FPSquare(x̄) ; recall Σx² (15da) ; _FPMult ; (RST 30 _FPAdd / subtract) ; …
6989: CALL _FPDiv (2541) ; CALL 3939 (_SqRoot wrapper) ; store

The only difference between σx (population) and Sx (sample) is the divisor: the population path divides by n, the sample path first does _Minus1 (00:2294, n−1) — confirmed at 3A:677C. x̄ = Σx / n via _FPDiv. [confirmed]

5. The regression solver — Gauss‑Jordan on the normal equations (3A:67C6 …) [confirmed]

For a polynomial fit the moment matrix from §4 is the augmented normal‑equations matrix [ M | Σxⁱy ]. _OneVar solves it in place by Gauss‑Jordan elimination (not a closed‑form determinant), then writes the coefficients to QuadA…QuartE.

67c6: build/copy the augmented matrix; 84d9 = base
67d4..67e3: scale the pivot row
67ec: LD BC,0202 ; CALL 3aad        ; pivot element (2,2)
67f7: CALL 212d                     ; _ErrD check (zero pivot → SINGULAR MAT 0x83)
67fa: RST 8 ; …                     ; pivot reciprocal
6804: CALL 2541 (_FPDiv)            ; divide row by pivot
680d..6815: elimination loop
6845: CALL 3939 (_SqRoot) ; 6849 ; CALL 2541 (_FPDiv)  ; (forms r²/r from the fit)
684f: LD A,12 ; CALL 213d           ; r-related store/guard
6859..6876: row-reduce all other rows (3aa7 get, 238b _FPMult, RST 30 _FPAdd)
6880: CALL 2541 (_FPDiv) ; CP 2 ; LD A,0x35/0x36 ; CALL 213d  ; *** _Sto_StatVar stores into the
                                                              ; statVar slots id 0x35/0x36 — NOT a SingularMat raise.
                                                              ; the zero-pivot guard is the 67F7→212D path → 0x83.
68d6..6953: back-substitution — each coeff = (rhs − Σ known·M) / pivot
   (3aa7/3aa1 matrix access, 238b _FPMult, RST 30/RST 8 accumulate,
    24bd _InvOP1S to subtract, 2541 _FPDiv)
   each solved coefficient is stored via 69af → CALL 3ab9 (matrix set)
       then copied out to the QuadA..QuartE statVars block.

• A zero/near‑zero pivot raises _ErrSingularMat (0x83) “SINGULAR MAT” (e.g. all x equal, or too few distinct points for the degree). The LD A,0x35/ 0x36 and CALL 0x213d are the in‑solver guards. [confirmed]

• The solver is dimension‑generic: LinReg (2×2) → a,b; QuadReg (3×3) → a,b,c; CubicReg (4×4) → a,b,c,d; QuartReg (5×5) → a,b,c,d,e. The coefficients land in QuadA(8AEE) downward. [confirmed]

• Correlation r and r² are computed for the linear models from the centred sums:

  $$r=\frac{\sum (x-\bar x)(y-\bar y)}{\sqrt{\sum (x-\bar x)^2\,\sum (y-\bar y)^2}}=\frac{n\sum xy-\sum x\sum y}{\sqrt{\big(n\sum x^2-(\sum x)^2\big)\big(n\sum y^2-(\sum y)^2\big)}}$$

  assembled with _FPMult/_FPSub/_SqRoot/ _FPDiv (the 6845/684c cluster) and stored to Corr (8ACA). The store offset is pinned: at 3A:684F the code does LD A,0x12 ; CALL 0x213D, and 0x213D is _Sto_StatVar (the store counterpart of _Rcl_StatVar 00:2149 — both funnel through the 0x3E07 statVar dispatcher with the name id in A). Id 0x12 = tCorr = the Corr slot, so this single sequence is exactly r → Corr (8ACA). The preceding 3A:6845 _SqRoot/_FPDiv cluster forms the ratio; r² (and R² for higher‑order fits) is the r·r / coefficient‑of‑determination derived from the same cluster and surfaced through the same Corr slot. [confirmed: the A=0x12 → _Sto_StatVar r‑store; standard formula]

• The fitted equation is also written to RegEQ (the Y=‑style regression equation system var, recalled via token tRegEq=0x01) so RegEQ can be pasted or graphed. [standard]

The Med‑Med model (F8) takes the resistant‑line branch (3A:760F/79B9): it sorts, splits the x‑sorted data into three equal partitions, takes the median (x,y) of each (MedX1/2/3, MedY1/2/3 at 8B1B…), and fits the line through the outer two summary points adjusted toward the middle — classic Tukey median‑median. [confirmed path / standard]

6. Median, quartiles, min/max & the sort (3A:7935, 3A:79B9) [confirmed]

For 1‑Var Stats the five‑number summary needs the data sorted:

• MinX/MaxX are tracked during the §4 pass (running min/max compares).
• The median/quartile path (3A:79B9 → 7A0B …) sorts a working copy via the internal sort stat_sort (3A:7935), then:
  • Med (MedX, 8AD3) = middle element (or mean of the two middle for even n),
  • Q1 (8ADC) = median of the lower half, Q3 (8AE5) = median of the upper half (TI’s “exclude the overall median when n is odd” convention), with frequency‑weighted positions (the 7B30/7B4C/7B6E helpers walk the cumulative‑frequency index, and 198d/238b interpolate the rank). [confirmed path / standard quartile rule]

The five‑number summary (minX, Q1, Med, Q3, maxX) is what the MED/box‑plot stat plot reads back out of statVars.

7. Worked flow: 2‑Var Stats L1,L2 then LinReg(ax+b) L1,L2,Y1 [hypothesis, from §§2–6]

1. Parser pushes the list args, sets A = command token, bcall(_OneVar).
2. _OneVar parses args → x‑list ptr (84D3), y‑list (84D5), freq (84DB); saves the model code to (8A36).
3. Accumulation pass (§4): one walk of L1/L2 building n, Σx, Σx², Σy, Σy², Σxy and minX/maxX/minY/maxY into statVars, plus the 2×2 moment matrix.
4. Moments (§4a): $\bar x=\tfrac{\sum x}{n}$, $\bar y=\tfrac{\sum y}{n}$; the sample/population spreads $S_x,\sigma_x,S_y,\sigma_y$ via the variance helper (divide by $n-1$ vs $n$).
5. Solve (§5): Gauss‑Jordan on the normal equations $\left[\begin{array}{cc|c}\sum 1&\sum x&\sum y\\\sum x&\sum x^2&\sum xy\end{array}\right]$ → b=slope, a=intercept → QuadA/QuadB; r,r² → Corr; equation → RegEQ, pasted into Y1.
6. Results displayed by the STAT‑CALC report screen; all of x̄/Σx/…/a/b/r persist in statVars for later recall by name (_Rcl_StatVar).

8. Stat plots [standard / partially confirmed]

Stat plots (Scatter tScatter=FE, xyLine FD, Histogram tHist=FC, box plots tBoxIcon, normal‑prob) are drawn by the graphing subsystem, reading the five‑number summary and the raw L1/L2 lists. _ErrStatPlot (00:2759, code 0x1B) guards an invalid/undefined plot configuration; _ZmStats (33:65DC, id 0x47A4) is the ZoomStat routine that auto‑scales the window to the plotted list data (sets Xmin/Xmax/Ymin/Ymax from minX/maxX/minY/maxY). See sub-graphing.md. [confirmed addresses / standard behavior]

9. Distributions (DISTR menu) — not part of STAT‑CALC [confirmed scope]

normalpdf(, normalcdf(, invNorm(, binompdf(, tcdf(, χ²cdf(, Fcdf(, etc. are parser functions (DISTR‑menu tokens, the t2ByteTok (0xBB)‑prefixed two‑byte tokens like tShadeNorm=35h), evaluated through the normal function dispatch of the TI‑BASIC parser, not through _OneVar. They are not exposed as named bcalls in this OS image (a search of bcall_targets.txt finds only _SetNorm_Vals 00:220F, a helper that copies the display “Normal mode” default values — unrelated to the normal distribution). Their numerical cores (error‑function / incomplete‑gamma / incomplete‑beta continued fractions) live on a banked flash page reached via the parser’s function table and the page‑02 FP transcendentals; they belong to the parser/sub-tibasic dispatch rather than the STAT subsystem documented here. [confirmed: not reachable from _OneVar; hypothesis: numerical method]

Grounding [confirmed]. A name search of the whole‑OS image for norm/stat/distribution cores returns no normalcdf/erf/incomplete‑gamma/incomplete‑beta entry points — the only *norm* symbols are _SetNorm_Vals (00:220F, display “Normal mode” defaults), fp_normalize/fp_norm_left (mantissa normalisation), cplx_norm_* (complex modulus) and the eqdisp_setnorm_split layout helpers — none is a distribution. Likewise every stat_* symbol on page 0x3A is part of the _OneVar STAT‑CALC engine (accumulate / variance / median / sort / regression), not a DISTR core. So the erf / incomplete‑gamma / incomplete‑beta continued fractions are [hypothesis] — outside the STAT‑CALC engine, sitting behind the parser’s 2‑byte (0xBB‑prefixed) DISTR‑token function table; their exact page/address is not exposed as a named routine in this DB. [confirmed scope; address hypothesis]

10. Integration summary

  L1..L6 lists (VAT data)                 statVars (0x8A3A)  ← results, recall-by-name
        │ (element fetch 3A:6F6A)               ▲
        ▼                                       │ (_Rcl_StatVar 00:2149)
   _OneVar (3A:6420, id 0x4BA3)  ──►  per-element accumulation pass (3A:6572)
        │  cmd code → 0x8A36                     │  uses FP engine:
        │                                        │   RST30 _FPAdd, 238B _FPMult,
        ├─ moments / Sx,σx (3A:6984..)           │   238A _FPSquare, 2541 _FPDiv,
        ├─ Gauss-Jordan solve (3A:67C6..) ───►   │   3939 _SqRoot, 2294 _Minus1
        │     → QuadA..QuartE, Corr, RegEQ       │
        └─ sort + median/quartile (3A:7935/79B9) ┘
  errors: _ErrStat 00:2741 (0x15), _ErrStatPlot 00:2759 (0x1B),
          _ErrSingularMat 0x83, _ErrDimMismatch 00:2715 (0x8B)

The STAT subsystem is a thin data‑driven front‑end on page 0x3A that reads list data via the VAT, drives the page‑0/page‑02 BCD FP engine to build power‑sums, then either finalizes the moments or runs an in‑place Gauss‑Jordan solve of the normal equations, depositing every output as a named TIFloat in the statVars block.

11. Confident address index (space:addr)

RAM: statVars=0x8A3A, model‑discriminator 0x8A36, work ptrs 0x84AF–0x84DB (84D3 x/median ptr, 84D5/84D7 element ptrs, 84D9 sums‑matrix base, 84DB freq ptr, 84B1/84B2 loop counters, 84B3 element count). FP engine reused: RST 30h=_FPAdd, RST 08h=OP1→OP2, 00:238B=_FPMult, 00:238A=_FPSquare, 00:2541=_FPDiv, 00:2294=_Minus1, 02:6E38/3A:3939 =_SqRoot, 24BD=_InvOP1S.

12. Notes

• r store offset. 3A:684F does LD A,0x12 ; CALL 0x213D (_Sto_StatVar, id 0x12 = tCorr), i.e. r → Corr (8ACA); r²/R² is the r·r/coefficient‑of‑determination from the same 6845 _SqRoot/_FPDiv cluster, surfaced through the same Corr slot (§5). (Residual: the 6845–6891 region is unanalyzed code in the DB, so only the A=0x12 store sequence was byte‑pinned, not every intermediate.)
• DISTR numerical cores (erf/incomplete‑gamma/incomplete‑beta) are outside the STAT‑CALC engine: no distribution core is a named routine in this DB; they sit behind the parser’s 2‑byte DISTR‑token function table (sub-tibasic). Exact address [hypothesis] (§9).
• STAT‑TESTS (Z/T/χ²/F/ANOVA) that fill PStat…SStat/anovaf_vars are separate command handlers, not reached through _OneVar (whose tokens are only F2–FF); no PStat‑writing routine is among the page‑0x3A stat_* symbols (§1). Per‑test addresses [hypothesis].
• stat_sort (3A:7935) is a 49-byte setup that validates/counts the elements then dispatches the compare-swap via rst 28h (the bcall site isn’t fully analyzed in the DB). The SortA(/SortD( command sort is a different routine (page 0x02, comparator _CpOP1OP2) — its complex-list ordering is documented in Matrices & Lists.

Matrices & lists

TI-84 Plus OS 2.55MP — feature deep dive.

How the TI-84 Plus OS (2.55MP) stores, indexes, and computes on lists and matrices — the routines a college student hits doing linear algebra (det(, [A]⁻¹, rref(, [A]*[B], identity(, T) and data work (L1+L2, dim(, sum(, seq(, SortA(). Companion to 05-variables-vat.md (where the data lives), 06-floating-point.md (how each element is computed), and sub-vat-archive.md (Store/Recall/Archive).

All page:addr are read from the raw Z80 disassembly, not the decompiler alone. Page numbers are the masked flash page (rawpage & 0x3F). The whole-OS image lives in one Ghidra program with address spaces ram (the page-0/RAM-resident 0x0000–0x7FFF window) and page_NN for each flash page mapped into the 0x4000–0x7FFF bank-A window.

0. TL;DR — the mental model

• A list is word count (2 bytes) followed by count × 9-byte TIFloat elements (18-byte complex elements if the list is complex, flagged 0x0C). Element $i$ (1-based) lives at $\mathrm{addr}(L_i)=\mathrm{data}+2+(i-1)\cdot 9$.

• A matrix is byte dim0; byte dim1; (two 1-byte dimensions) followed by dim0*dim1 × 9-byte TIFloat, stored column-major. The element offset from the start of the data area (after the 2 dim bytes) is

  $$\mathrm{offset}=\big((\mathit{idx}_0-1)\cdot \mathit{dim}_0+(\mathit{idx}_1-1)\big)\times 9$$

• Every element read/write routes one TIFloat through OP1/OP2 and the FP engine — there is no “vector unit”; matrix multiply is a triple loop of _FPMult+_FPAdd.

• The data area is found through the VAT (_FindSym, doc 05): the VAT entry’s data pointer + page byte locate the count/dim header, after which all indexing is pointer arithmetic computed by _AdrLEle/_AdrMEle.

• One shared Gauss-Jordan engine (02:42A6) implements matrix inverse [A]⁻¹ (flag 0x00) and det( (flag 0x40) with partial pivoting. rref(/ref( are the same elimination family.

1. Data layouts & the creator routines [confirmed]

List — _CreateRList (00:10C4), _CreateCList (00:1109)

_CreateRList(count, dataPtrOut):
  reject unless OP1 name token (8478.exp) ∈ {0x5D, 0x24, 0x3A, 0x72}  ; list-name classes
  var_alloc(1)                  ; carve  count*9 + 2  bytes via _InsertMem
  store count word at data[0..1]
  if list is complex (8499.type & 8): data[2] = 0x0C   ; element-size flag

Layout: [countLo countHi] [TIFloat e1] [TIFloat e2] …. A complex list keeps a 0x0C flag and 18-byte elements.

Matrix — _CreateRMat (00:1115)

_CreateRMat(dimWord, dataPtrOut):
  _HTimesL()                    ; element count = H * L  (the two dims multiplied)
  var_alloc(2)                  ; carve  H*L*9 + 2  bytes
  header: LD (HL),C ; INC HL ; LD (HL),B   ; writes dim0 then dim1

• _HTimesL (00:1EF6) is literally result = H * L (B=H; HL=Σ L, a DJNZ add loop) — it computes the element count from the two dimension bytes. [confirmed]
• Header = two bytes dim0,dim1; data is dim0*dim1 floats column-major.

Dimension naming [confirmed]. Settled by disassembly. _AdrMEle (02:4002) reads the header’s first byte (LD A,(DE); LD L,A) and uses it as the major stride, looping (B−1) adds of it and then +(C−1) within a column (column-major). The major stride of a column-major array is the number of rows, so the first header byte (dim0) = #rows, and _AdrMEle’s B = idx0 = column, C = idx1 = row. _CreateRMat (ram:1115) confirms the layout: it is PUSH HL ; CALL _HTimesL (1EF6) ; LD A,2 ; JR 10DD — _HTimesL returns H·L (the element count) and A=2 is the 2-byte dim header; the two dimension bytes are stored dim0 (rows) then dim1 (cols). The byte-confirmed index arithmetic ((idx0−1)·dim0 + (idx1−1))·9 is therefore a (column, row) register convention with a row-count stride.

2. Element access — the index→offset math [confirmed]

This is the heart of everything. Two address-calculators turn a 1-based index into a byte pointer, then a 9-byte move shuttles the TIFloat to/from OP1.

List element address — _AdrLEle (02:47C5)

_AdrLEle(index, listDataPtr):           ; HL=index, DE=listDataPtr
  INC DE ; INC DE                        ; skip the 2-byte count header
  A = (DE) & 0x1F                         ; element type (low 5 bits); 0x0C ⇒ complex
  CALL 21C4                               ; classify real vs complex element width
  HL = (index − 1)                        ; _HLTimes9(index-1)
  CALL 1930  (_HLTimes9)                  ; HL = (index-1) * 9
  HL += DE                                ; final element pointer

So list element i is at data + 2 + (i−1)*9 (×18 path for complex). _HLTimes9 (00:1930) is the universal “multiply by 9” (real TIFloat size). chk_type_lt_1a (ram:21C4) masks the type to ≤0x19 and sets carry for the complex case (drives the 18-byte width). [confirmed]

Convenience wrappers (all = _AdrLEle then a 9-byte move through OP1, complex-aware): [confirmed]

• _GetLToOP1 (02:47EA) — list[i] → OP1 (real or complex via two _Mov9B).
• _RclListElemToOP1 (02:47FB), _RclListElemB (02:47FE) — recall to OP1 with the index pre-loaded in RAM (84AF/84D3).
• _PutToL (02:4829) — OP1 → list[i]; _CkValidNum validates the float first, then copies, honoring the complex (& 0xC) element width.
• _RclCListElem (02:49A7), _RclCListElemB (02:49B5) — complex-list element via _CplxOPArrange (splits real/imag into OP1/OP2).
• _GetPosListElem (02:5BBB) — fetch by a positive-integer index with _CkOP1Pos bounds (loads A=0x15 = E_Stat and jumps to the error vector ram:2741 on a bad index).

Matrix element address — _AdrMEle (02:4002) [confirmed]

_AdrMEle:                                 ; B=column idx0, C=row idx1, DE=matrixDataPtr
  if B==0 or C==0 -> LD A,0x78 ; JP 0x2793 ; 0-index rejected (error vector)
  A = (DE)        ; A = dim0 (rows)        ; first header byte
  HL = 0
  repeat (B − 1) times:  HL += dim0        ; (idx0-1) * dim0     (column stride)
  HL += (C − 1)                            ; + (idx1-1)          (within column)
  DE += 2                                  ; skip both dim bytes
  CALL 1930 (_HLTimes9)                    ; HL *= 9
  HL += DE                                 ; final element pointer

Column-major offset: elem = data + 2 + ((idx0−1)*dim0 + (idx1−1)) * 9. The (B-1) adds of dim0 walk whole columns; the (C-1) steps within a column. The 8-bit adds track a carry into H so the address is a true 16-bit offset (matrices up to 99×99). Because the multiplied byte is dim0 and that is the row count (column-major major stride), B=idx0 is the column index and C=idx1 is the row index — see the [confirmed] dimension-naming note in §1. [confirmed]

Matrix element wrappers: [confirmed]

• _AdrMRow (02:4000) — address of the start of column idx0 in the column-major buffer (loops (idx0−1) × dim0, no +(idx1-1)); whole-row operations layer their own iteration on top.
• _GetMToOP1 (02:4044) — [M](r,c) → OP1 (_AdrMEle then RST4 = load 9 bytes).
• _PutToMat (02:406C) = mele_store_ckvalid (02:4068): _AdrMEle ; _CkValidNum ; _MovFrOP1 — OP1 → [M](r,c) with validation.
• _StMatEl (38:6C8F) — high-level “store into [M](r,c)” used by the parser: resolves the matrix name (5F45), bounds-checks indices against the dims (r≤rows && c≤cols, else _JError 0x8C = E_Dimension), unarchives if needed, then _PutToMat. [standard]

Internal index helpers reused by the algorithms [confirmed]

• mele_adr_af_jp (02:403C) = _AdrMEle(currentIJ) ; RST4 — “load [M](i,j) to OP1” (the elimination inner-loop read). Indices come from the loop state at 84AF/84B3/84B4.
• mele_adr_to8483 (02:4051) = _AdrMEle ; _Mov9B(→OP2@8483) — load element to OP2.
• mele_put_af (02:405A) / mele_put_d3 (02:405E) = _AdrMEle ; _CkValidNum ; _MovFrOP1 — store OP1 back to [M](i,j).
• _ListIdxTimes9 (35:79E9) = _HLTimes9(idx) then a small dispatch (RST4) — the list analogue used in a few list-builder paths.

3. List operations [standard]

Create / resize / insert / delete

dim(, dim(L)→n, list↔value

dim( reads the count word straight from the list header; assigning n→dim(L) calls the resize path (_IncLstSize/_DelListEl) to grow/shrink, zero-filling new cells. List→matrix and matrix→list (List►matr(, Matr►list() reshape via _DataSize + a column-major copy (mele_copy9_d3 (02:4539)/mele_copy9_loop (02:453F), a _DataSize-counted byte copy of the float payload). [standard]

List arithmetic L1+L2, scalar broadcast

Binary list ops are element-wise folds: the parser walks both lists by index, loads L1[i]→OP1, L2[i]→OP2, applies the FP RST shortcut (RST 30h _FPAdd, _FPSub, _FPMult, _FPDiv), stores into a freshly _CreateRList’d result. Length mismatch ⇒ E_DimMismatch (_ErrDimMismatch 00:2715, 0x8B); a list⊕scalar broadcasts the scalar across every element. [standard — the per-element FP path is confirmed; the outer driver is the parser’s binary-op handler.]

sum(, prod( — higher-order folds over a list [confirmed]

Tokens 0xB6=sum(, 0xB7=prod( load a combiner function pointer and fold the list (dispatcher 02:6104):

sum(  : HL = 0x3A83 (cross-page → FP add-accumulate),  seed via _OP1Set0
prod( : HL = 0x49B9 (seed accumulator = 1.0, _PushOP1), combine with _FPMult
        CALL 0x64B7 ; ... ; JP (HL)   ; apply the combiner across e1..eN

The fold seeds the accumulator (0 for sum, 1 for prod), then for each element does acc = combine(acc, L[i]) through OP1/OP2. Works on real and complex lists (type 1/0xD both route to 02:6140). [confirmed]

seq(, cumSum(, SortA(/SortD(, mean(/median(/stdDev( [hypothesis]