System overview

This wiki documents how TI-84 Plus OS 2.55MP uses the Z80, banked memory, calculator hardware, and its internal software subsystems. It keeps direct ROM evidence, emulator observations, public hardware behavior, and unresolved inferences distinct.

The target is a validated 1 MiB Flash image whose OS identifies itself as 2.55MP. Conventions and methodology defines the address notation and confidence flags used throughout the book.

Machine and OS

The TI-84 Plus is a Z80 machine that can only see 64 KiB at once. The target has 1 MiB of Flash and eight RAM selector values. Community hardware reports assign eight independent 16 KiB RAM blocks to early units. They assign 48 KiB to later units, with selectors 82–87 sharing one block. No physical result is recorded for the calculator used by this project. A four-slot paging scheme and a system-call (bcall) mechanism expose code and data beyond the current address space. The OS is a single-tasking monitor. Its boot/kernel core occupies Flash page 0, other OS routines span banked Flash pages, and fixed RAM windows hold system state. See RAM pages for the revision evidence.

Four mechanisms connect most user-facing OS behavior:

Around those sit the I/O subsystems: the Flash command path and boot write APIs; the IM1 interrupt dispatcher (interrupts.md); the standard timers, RTC, and low-power state machine (clock-timers-power.md); the MD5 round accelerator; the LCD driver; the keypad scanner; and the link port.

Subsystem index

Each row maps a documentation page to the subsystem it covers.

The sidebar groups subsystem deep dives beneath their parent pages. The Glossary defines TI-specific terms, and the bcall index is the alphabetical system-call reference.

Subsystem map (bcall API surface)

This page groups the roughly 600 named bcall entry points by subsystem. The result shows the public API used by both application code and the OS itself.

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

Reading the map

This is a calculator: roughly two-thirds of the API is numeric, and 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: the bcall mechanism, interrupt dispatch, clock/timers/APD/power, MD5 and boot signature arithmetic, error handling (_JError + TIError codes), and the system flags (SystemFlags @ flags).

Execution 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 the subsystem pages linked above and in the sidebar for detail.

Conventions and evidence

This page defines the notation, evidence labels, and naming conventions used throughout the wiki.

Suggested reading order

1. System overview introduces the machine, OS, and evidence model.
2. Subsystem map shows the major services and their dependencies.
3. Memory map, Paging, The bcall mechanism, and Interrupts cover the shared architecture.
4. Continue with a core subsystem such as Floating point, Variables and the VAT, Tokenizer and TI-BASIC tokens, or Display and LCD, followed by its linked deep dives.
5. Glossary for any unfamiliar term.

Address notation

• pp:addr — Flash page pp (00–3F) and logical address addr. Banked pages run in the 0x4000–0x7FFF window, so _PutS at 01:5C39 means page 01, address 0x5C39.
• 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, such as _FindSym = 0x42F4) 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:

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 from a routine’s behavior, including its callees and RAM or port accesses, such as findsym_scan or fp_normalize. Any individual low-level helper name remains a best-effort interpretation.

The rebuilt Ghidra project keeps each kind of name in a separate checked registry:

• tools/symbols/names.txt contains function entries. Its importer disassembles the entry and creates a function.
• tools/symbols/labels.txt contains ROM data and internal code-entry labels. Rows marked entry seed and preserve disassembly without creating an overlapping function.
• tools/symbols/ram.txt contains RAM symbols, including official SDK equates and carefully named inferred state.
• tools/symbols/ports.txt contains I/O-port symbols.
• tools/symbols/poffsets.txt contains reviewed base-plus-offset references. These make an operand such as mathprintArenaState + 0x0D render as a structure member without inventing a second global name for the field address.

tools/symbols/ty_regions.txt applies the C layouts built by BuildTypes.java. The prose can therefore use expressions such as table_value_cache.band[1].value[row] once it introduces the typed base and its concrete address. A physical boundary, trace target, or byte-level proof still keeps its concrete address. [confirmed]

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.

Evidence and reproducibility

• The Ghidra database is rebuilt from the ROM by tools/build.sh (a 15-stage reproducible pipeline around Ghidra’s headless analyzer). It loads all 64 flash pages (page 0 + overlays at 4000), then resolves routines, applies function and data symbols, and installs the checked C layouts and offset references.
• Local ROM trust boundary. tools/ti84re/rom/assemble_local_rom.py --check validates the exact ignored base-ROM and AppVar hashes without writing output. Its reusable tools/ti84re/rom/assembly.py library decodes each TI variable container, verifies its checksum, type, name, flags, duplicate length fields, internal 16 KiB size, and payload hash, then requires the assembled-ROM hash. This proves which bytes the analysis uses; it does not prove that the files were captured from a physical calculator. The pinned base already contains the D84PBE1.8Xv page-3F payload byte for byte. Only D84PBE2.8Xv, installed at page 2F, changes the base image (8,615 bytes). [confirmed]
• 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 87 populated retail boot-table entries on page 3F; several USB entries target page 2F. The local rom.bin is assembled from the patched base plus the retail D84PBE1.8Xv and D84PBE2.8Xv payloads. tools/symbols/bcalls8x_targets.txt contains the 83 byte-resolved bodies with public SDK names; the remaining four entries have project-inferred names. The resolver rejects these targets when page 3F has a BootFree prefix.
• Decompiler caveats. Ghidra’s Z80 decompiler can mis-render SET b,(IY+d) flag operations, CALL cross_page_jump (ram:2B09) trampolines, and register-passed arguments on banked pages. Raw disassembly and ROM bytes are authoritative for these cases.

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

Build and evidence provenance

Reverse-engineering results are meaningful only when their ROM, execution environment, include file, and analysis tools are identifiable. This repository uses SHA-256 identities rather than filenames as the primary provenance boundary.

Two local OS 2.55MP images

The repository recognizes two complete-image identities. Pages 0x00–0x2E and 0x30–0x3E are identical. Their pages 0x2F and 0x3F provide different boot support. [confirmed]

The canonical image starts from ti84plus_patched.rom, whose SHA-256 is 90472848b5f56902287fd5d8b455e62d60e9ab054647c9a03c1c91a67fc1a95a. D84PBE2.8Xv supplies page 0x2F; D84PBE1.8Xv supplies page 0x3F, although that decoded retail page is byte-identical to the base image’s page 0x3F. The exact AppVar and decoded-page identities are pinned in tools/ti84re/rom/signatures.py. [confirmed]

The BootFree image matches the patched base on pages 0x00–0x3E. Only page 0x3F differs, with SHA-256 b3ae75aa81231de15e5931746d79834863132d5e4dca01010e3a8e24aabd3003. Its acquisition artifact is not pinned, so this is a page-identity statement, not a physical-capture provenance claim. [confirmed]

Use the retail image for boot-table, USB boot, reset, recovery, certificate, and page-0x3F claims. A BootFree trace identifies execution on unchanged page bytes, but the replacement boot can change the program’s initial state. Such a trace supports an OS-path claim only when the required state and dependent pages are also recorded. It cannot establish retail boot behavior.

BootFree callable surface and reset path

tools/data/boot-page-comparison.csv compares all 87 populated 0x8xxx table entries. Every target address differs. BootFree maps 38 entries to other bodies, 45 entries to a bare RET, and four entries to small constant-return stubs. The six retail entries whose bodies live on USB boot page 0x2F all map to BootFree’s bare-RET stub. [confirmed]

The reset paths also differ before any OS code runs: [confirmed]

The retail reset and installed-OS branches are at 3F:4000–3F:400C and 3F:420B–3F:4308. The corresponding BootFree branches are at 3F:4000–3F:4006 and 3F:412C–3F:41FC. [confirmed]

The CSV classifies every populated boot-table slot, not every internal helper entry in either page. A complete internal-routine comparison still requires matched function-entry recovery for both images. [confirmed]

Generate a manifest

tools/ti84re/rom/provenance.py records the complete ROM identity, target model, hardware or emulator environment, ASIC revision, emulator profile, OS version, boot-page classification, component page ranges, the 2007 include-file identity, Ghidra version, Git revision, dirty-tree state, and a digest over the top-level analysis scripts.

nix develop -c python3 -m ti84re.rom.provenance manifest \
  --rom tools/rom.bin --model 'TI-84 Plus' --environment emulator \
  --asic unknown --emulator-profile 'TilEm x4' \
  --output /tmp/ti84p-provenance.json

The generated manifest reports an unknown component map for an unrecognized ROM rather than silently assigning it a known OS identity. [confirmed]

Reject stale results

Single-ROM CSV result tables use a rom_sha256 column. Dual-ROM tables record both identities, and tables derived from external source or hardware record an evidence identity instead. JSON reports use either a rom_sha256 field or a rom.sha256 object. Verify a single-ROM artifact against the current manifest before reuse:

nix develop -c python3 -m ti84re.rom.provenance verify \
  --manifest /tmp/ti84p-provenance.json \
  tools/data/launch-boundary-results.csv \
  tools/data/resident-launch-snapshot.csv

The command rejects missing, mixed, or mismatched identities. Raw TLMT traces do not embed a ROM hash, so they require a JSON provenance sidecar; verify the sidecar rather than treating the trace filename as evidence. [confirmed]

Audit the Ghidra database

tools/ghidra/DatabaseHealth.java makes database coverage and cleanup debt machine-readable. Run it against the existing project without analysis or writes:

nix develop -c ghidra-analyzeHeadless "$PWD" ti84 \
  -process -noanalysis -readOnly -scriptPath "$PWD/tools/ghidra" \
  -postScript DatabaseHealth.java tools/data/database-health.json

The checked report identifies the BootFree runtime-trace image by its complete ROM hash. It records 64 loaded Flash pages, 27,995 instructions, 2,413 functions, and 94.081086 percent of instructions inside functions. The listing has no overlapping instructions. It also lists each of the 163 unresolved inline cross-page jumps and 45 primary symbols that have neither an instruction nor typed storage at their address. [confirmed]

The 989,125 undefined Flash bytes are addresses with no defined Ghidra code or data unit. That number measures database coverage; it does not imply that those bytes are unused or safe to overwrite. Likewise, an unresolved jump is a specific analysis task, not evidence that the ROM’s control flow is invalid. [confirmed]

The health report is deterministic for a given database, script revision, and Ghidra version. Its rom_sha256 field can be checked with tools/ti84re/rom/provenance.py verify; use a separately rebuilt retail project when auditing retail boot and USB pages. [confirmed]

Community assembly archive snapshot

The community-source audit uses a 2026-08-24 mirror of the ticalc.org TI-83/84 Plus assembly archive. The archive was cloned outside this repository. This repository contains hashes and analysis tools, not the contributed programs. [confirmed]

tools/data/community-archive-inventory.csv records every mirrored ZIP path, its SHA-256, compressed and expanded sizes, member count, source-member count, and the number of paths with byte-identical archive contents. The snapshot has 2,770 ZIP paths, 2,649 unique archive identities, 19,323 members, and 4,241 members with recognized assembly or implementation-source suffixes. Of the ZIPs, 897 contain at least one such member. [confirmed]

Run the same inventory and safe extraction process from the development environment:

nix develop -c python3 -m ti84re.community.archive \
  "$COMMUNITY_ARCHIVE/mirror/pub/83plus/asm" \
  --archive-csv tools/data/community-archive-inventory.csv \
  --member-csv /tmp/community-archive-members.csv \
  --extract-to "$COMMUNITY_ARCHIVE/extracted"

The extractor validates paths before writing, keeps each ZIP in a separate directory, preserves duplicate member revisions under an explicit namespace, and stores archived symbolic links as inert metadata. It uses the system unzip only for compression methods that Python cannot decode, after rejecting links and duplicate paths and before checking every resulting file against the ZIP size and CRC records. The audit does not execute contributed host or calculator binaries. [confirmed]

An archive description or readme is a community claim. Source establishes the instructions present in that member, but does not prove that the distributed calculator variable was assembled from it or that the code works on physical hardware. Cite both archive and member hashes for a source finding, and retain the wiki’s existing hardware or ROM evidence boundary. [confirmed]

Evidence limit

A matching hash proves byte identity, not how the image was obtained. The environment, ASIC, and emulator-profile fields keep physical and emulator evidence separate. They do not turn emulator behavior into hardware evidence. Git and script-tree identities make an analysis run reproducible; they do not by themselves validate the analysis conclusion.

Glossary

This glossary defines the TI-specific terms and key RAM symbols used throughout the wiki.

Core concepts

Floating point

Variables and memory

Registers and 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).

Memory map

The Z80 sees a flat 64 KiB logical space divided into four 16 KiB windows. Port 0x04 selects paired or independent mapping; ports 0x05–0x07 and their extensions select the physical Flash or RAM pages. See Paging for the complete mapper and RAM pages 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/ghidra/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 is the Ghidra build input. tools/ti84re/rom/assemble_local_rom.py starts with ti84plus_patched.rom, validates the complete TI AppVar containers, installs D84PBE2.8Xv as page 2F, and installs D84PBE1.8Xv as page 3F. The first installation changes 8,615 bytes; the second changes none because the base already has that exact page. The required SHA-256 identities are 90472848b5f56902287fd5d8b455e62d60e9ab054647c9a03c1c91a67fc1a95a for the base and 7d9a7d96d89fc552ebee6afdbdd011fdc6047be9c16d308245dff07eb1f7bd6d for the result. These checks establish reproducible analysis inputs, not a physical-capture history. The page-2F and page-3F bodies above decode directly from rom.bin. The resolver detects a BootFree input and omits retail targets when the retail pages are absent.

Key named and typed RAM regions

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

Principal input/output ports [standard]

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).

Paging

The ASIC maps four 16 KiB logical windows into Flash and RAM. Port 0x04 selects one of two mapping modes, ports 0x05–0x07 hold the page selectors, and ports 0x0E, 0x0F, 0x27, and 0x28 modify the selected pages or small subranges.

This page distinguishes behavior executed by OS 2.55MP from public hardware descriptions and emulator implementations. The ROM never gives ports 0x27 or 0x28 a nonzero value, so their physical behavior remains unconfirmed.

Evidence and scope

The target ROM runs on a TI-84 Plus with 64 Flash pages and eight RAM page selectors. Family members with more Flash need the extended selector bits in ports 0x0E and 0x0F.

Page selection and execution permission are separate. The mapper can expose a RAM page in a CPU window while the execution-protection logic rejects an opcode fetch from the corresponding physical chunk. See Execution protection. [standard]

OS and analysis use

The bcall dispatcher maps a paged body through port 0x06, executes it in window A, then restores the previous page. A bcall whose body resides on fixed page 0 executes below 0x4000 without changing bank A. The page-set helper at ram:181C implements the dispatcher write. [confirmed]

cross_page_jump at ram:2B09 consumes an inline address-and-page payload and transfers control across Flash pages. Banked routines are position-fixed for window A because their logical addresses remain in 0x4000–0x7FFF regardless of the selected physical page. [confirmed]

Ghidra models physical Flash pages 1–63 as overlay blocks based at 0x4000. This makes every banked body statically visible while preserving its logical address. Runtime traces still need the active port-0x06 value to identify the physical page. [confirmed]

The four logical windows

The Z80 supplies a 16-bit address. The top two address bits choose a logical window; the mapper supplies the physical page.

Window 0 stays fixed in both modes. [standard] The fixed page and the normal RAM values match the OS trace. [confirmed]

A physical page can appear in more than one window. During boot, Flash page 3F is visible through both A and B for part of the transition. Logical addresses in those windows then alias the same physical bytes at different offsets. [confirmed]

Mapper view. Window 0 remains fixed. The boot example is [confirmed]; the complete paired and independent register contract is [standard].

Mapping modes — port 0x04 bit 0

Writing port 0x04 changes the memory mode and the standard-timer rate. Its bit 0 controls the mapper. Reading the same port returns interrupt and key status, not the last mode byte. See Clock, timers, and power for the other bits. [standard]

Independent mode — bit 0 clear

Each banked window has its own selector.

The OS normally writes 0x06 to port 0x04, selecting independent mode and the slowest standard-timer rate. Its bcall dispatcher maps a target Flash page through port 0x06. Paged-RAM helpers use ports 0x05 and 0x07 as a pair. [confirmed]

Paired mode — bit 0 set

Port 0x06 supplies an adjacent page pair, and port 0x07 moves to window C. Port 0x05 does not select a visible window in this mode. [standard]

For example, the TI-84 Plus reset selector 0x3F produces Flash page 3E in window A and page 3F in window B. The boot trace begins at logical 0x8000, which therefore executes retail_boot_reset_stub at 3F:4000. [confirmed]

Changing bit 0 reinterprets all three banked windows at once. Code that changes the mode must execute from fixed page 0 or from a physical page visible at the next logical PC under both mappings. The boot transition uses the latter method. [confirmed]

Selector encoding

Ports 0x06 and 0x07

Bit 7 chooses the memory type. On the TI-84 Plus, these selector rules match the trace, TilEm, and Wabbitemu: [confirmed] for executed OS values; [standard] for the complete register contract. MAME matches the OS-used Flash values and RAM selectors 0x80–0x86, but does not wrap higher RAM values.

The hardware-facing 0x80–0x87 RAM notation distinguishes RAM selectors from Flash page numbers. It does not mean that RAM has 128 pages. See RAM pages for physical aliasing and OS use.

Port 0x05

Port 0x05 always selects RAM. On the TI-84 Plus, its low three bits select RAM page 0x80 | (value & 7). The normal value 0x00 therefore maps RAM page 80 into window C in independent mode. [confirmed]

TilEm stores four low bits for port readback but uses only three in its page calculation. Wabbitemu reduces the low seven bits by the model’s RAM page count. MAME stores the low three bits. The arithmetic in all three selects the same eight page numbers, although MAME’s backing range omits the last page as described below. [standard]

Extended Flash bits — ports 0x0E and 0x0F

Public descriptions and Wabbitemu model these registers as two high Flash-page bits. Port 0x0E extends port 0x06; port 0x0F extends port 0x07: [standard]

$$ P_A = ((p_6 \bmod 128) + 128(p_{0E} \bmod 4)) \bmod N_F $$

$$ P_B = ((p_7 \bmod 128) + 128(p_{0F} \bmod 4)) \bmod N_F $$

Here $N_F$ is the number of physical Flash pages. The high registers apply only when bit 7 of the corresponding low selector is clear. A RAM selector ignores them. [standard]

For the 64-page TI-84 Plus, every contribution from ports 0x0E and 0x0F is a multiple of 128 and disappears after the page mask. The boot ROM still writes 3 to each register while selecting its highest boot page, then clears both during normal mapper initialization. [confirmed]

TilEm’s TI-84 Plus mapper stores and reads the low two bits but does not feed them into its 64-page calculation. Wabbitemu uses the family-wide formula and masks the result by the configured Flash size. These implementations agree for this target. MAME does not map ports 0x0E or 0x0F; writes reach no handler. Its TI-84 Plus port-0x06 and port-0x07 handlers instead truncate every Flash selector below 0x80 to six bits. [standard]

Emulator mapper comparison

The source-level comparison below describes the pinned implementations, not the ASIC. Agreement is useful corroboration of an intended rule; disagreement is a test target rather than a vote. [standard]

Wabbitemu’s reads are therefore not register snapshots in paired mode. Port 0x06 reads visible A, port 0x07 reads visible B, and port 0x05 reads the physical page visible in C without a RAM-type bit. A routine that writes an even page to port 0x06 and reads port 0x07 receives that duplicated even page under the pinned implementation. TilEm and MAME instead return their stored selector bytes from ports 0x05–0x07. [standard]

Wabbitemu’s paired-B expression

Wabbitemu’s update_bootmap_pages intends to construct the second member of the pair, but the pinned source assigns it with: [standard]

page = normal_page | (!flash_version == 1);

Every supported Plus-family initializer gives flash_version a nonzero value. C operator precedence therefore evaluates !flash_version first, producing zero, and then compares zero with one, again producing zero. The expression is effectively page | 0. An odd port-0x06 selection still produces the usual even/odd pair because A clears its low bit and B preserves the already-set bit. An even selection duplicates the even page into both A and B. TilEm and MAME instead produce the adjacent odd B page. [standard]

This is a Wabbitemu implementation result, not evidence that the ASIC duplicates even pages. [hypothesis] for physical behavior until a hardware test exercises an even selector in paired mode.

MAME’s raw RAM banks and short backing range

For TI-84 Plus Flash values below 0x80, MAME stores value & 0x3F. For RAM values at or above 0x80, it stores the complete byte and passes that byte directly to the address-map bank. It does not reduce the selector modulo eight. Port 0x05 is the exception because its handler stores value & 7. [standard]

The TI-84 Plus banked map provides Flash at offsets 0x000000–0x0FFFFF and RAM at 0x200000–0x21BFFF. The latter is seven, not eight, 16 KiB pages. Selectors 0x80–0x86 reach RAM; selector 0x87, port-0x05 = 7, and every higher raw RAM selector land outside the mapped backing range. This boundary follows directly from the MAME address map and is an emulator defect, not a claim that TI-84 Plus RAM page 87 is absent. [standard]

Reset entry and fixed-page handoff

The three emulators do not begin at the same logical address: [standard]

MAME’s reset initializes selectors 0x05–0x07 to zero, port 0x04 to one, and m_booting to true. Its fixed window consequently starts on page 3F, while paired A/B are pages 00/01 and C is Flash page 00. The handoff is implemented in read handlers, despite a comment saying it should apply only to opcode fetches. [standard]

The pinned MAME source also swaps model constants in two machine-start functions: the ti83pse start assigns TI84PSE, and ti84pse assigns TI83PSE. The ti84p start correctly assigns TI84P, so the six-bit selector mask described here does execute for this article’s target. The swapped names still make cross-model inferences from this driver unsafe without checking the actual machine configuration and m_model branch. MAME registers the TI-84 Plus driver with MACHINE_NOT_WORKING; this comparison treats its source as an implementation oracle, not a fidelity endorsement. [standard]

Boot mapping transition

The retail boot page contains retail_boot_reset_stub at 3F:4000. Under TilEm’s reset mapping it executes at logical 0x8000: [confirmed]

3F:4000  LD A,0x07
3F:4002  OUT (0x04),A     ; paired mode
3F:4004  LD A,0x7F
3F:4006  OUT (0x06),A     ; A=page 3E, B=page 3F
3F:4008  LD A,0x03
3F:400A  OUT (0x0E),A
3F:400C  JP 0x812C       ; continue on page 3F in window B

Page 0 also contains a restart path at 00:0000 → 00:028C. It tests port 0x02 bit 7, writes either 0x1F or 0x03 to port 0x0E, writes 0x7F to port 0x06, selects paired mode, and jumps to the same logical 0x812C. Both values written to 0x0E have low two bits equal to three. [confirmed]

boot_os_entry at 3F:412C changes to independent mode without paging out its next instruction: [confirmed]

3F:412C  IM 1
          ; stack/RAM probe omitted
3F:4142  LD A,0x03
3F:4144  OUT (0x0F),A
3F:4146  LD A,0x7F
3F:4148  OUT (0x07),A     ; C=page 3F while still paired
3F:414A  LD A,0x06
3F:414C  OUT (0x04),A     ; independent: A=3F, B=3F, C=RAM 80
3F:414E  JP 0x4151       ; page 3F remains visible in window A

Boot then maps 0x81 through port 0x07, probes writable RAM at 0xC000 and 0x8000, and programs the execution-protection registers. At 3F:4208 it clears ports 0x0E, 0x0F, and 0x05, writes page 0x3F to port 0x06, and later maps RAM through port 0x07. [confirmed]

The resolved trace records the complete transition:

OUT (0x04) <- 07   paired mode
OUT (0x06) <- 7F   A=page 3E, B=page 3F
OUT (0x0E) <- 03
OUT (0x0F) <- 03
OUT (0x07) <- 7F   C=page 3F
OUT (0x04) <- 06   independent mode
OUT (0x07) <- 81   B=RAM page 81
OUT (0x0E) <- 00
OUT (0x0F) <- 00
OUT (0x05) <- 00   C=RAM page 80
OUT (0x06) <- 3F   A=Flash page 3F
OUT (0x07) <- 80   B=RAM page 80

This sequence shows why a mode change cannot be modeled as three independent port assignments. The meaning of the already-written 0x06 and 0x07 selectors changes when port 0x04 bit 0 changes.

Why RAM helpers clear port 0x0F

Several OS helpers clear port 0x0F immediately before selecting RAM through port 0x07. Representative sites include ram:0B78, 05:5B66, 2F:45A9, 36:74F8, 37:44CA, and 38:7782. They then compute a page pair: [confirmed]

    XOR A
    OUT (0x0F),A
    LD A,B
    SLA A
    OUT (0x05),A       ; even RAM page in window C
    INC A
    OR 0x80
    OUT (0x07),A       ; odd RAM page in window B

Bit 7 of the port-0x07 value is set, so the extended Flash bits do not participate in the resulting RAM page under the public contract, TilEm, or Wabbitemu. MAME has no extended selectors to clear. The clear may be defensive state normalization or compatibility with another ASIC revision. The ROM does not establish that it is required. [hypothesis]

Forced RAM subranges — ports 0x27 and 0x28

The public descriptions and TilEm implement two 64-byte-granularity overlays. For a byte value $n$: [standard]

A zero value disables the corresponding overlay. The maximum byte value, 0xFF, leaves one 64-byte block of its 16 KiB window outside the forced range.

OS 2.55MP writes zero to both ports in mode_default_init at 37:6D3A and 37:6D3E. It also clears port 0x27 before RAM-bank tests at 37:72D3 and 3F:45F5. No immediate or dynamic write in the analyzed ROM gives either port a nonzero value. These writes confirm that the OS disables the feature, but they do not confirm the nonzero mapping formula. [confirmed]

Emulator disagreement

The three emulator implementations disagree at the point most useful for a hardware test: [standard]

WikiTI’s historical description says these ports have no effect in paired mode, which agrees with Wabbitemu and disagrees with TilEm. None of these software sources proves the ASIC behavior. Whether the overlays operate in physical paired mode remains a hypothesis. [hypothesis]

Native Wabbitemu mapper edges

A guarded initialized-core run invokes the eight registered mapper handlers and the pinned core’s memory paths directly. Reset reads are 0x08 from port 0x04 and zero from ports 0x05–0x07, 0x0E, 0x0F, 0x27, and 0x28. The 0x08 is interrupt status, not the mapping mode. The visible reset windows are Flash 3F/00/00 and RAM 80, with independent mode active and hasChangedPage0 clear. [standard]

A data read at 0x4000 leaves fixed page 3F and the handoff flag unchanged. Executing a NOP from the same address changes fixed page 3F to 00, sets hasChangedPage0, and advances the PC to 0x4001. This confirms that Wabbitemu’s fixed-page handoff is an opcode-fetch effect. [standard]

Writing 0xFF to ports 0x0E and 0x0F reads back 0x03. With those high fields set, a raw Flash selector of 0x7F remains stored internally but ports 0x06 and 0x07 read the visible 64-page result 0x3F. RAM selectors 0xFF and 0xFE remain stored while the visible windows read 0x87 and 0x86. Port 0x05 = 0xFF maps and reads RAM page 7 as 0x07. [standard]

The paired-mode case writes C/A/B selectors 0x05, 0x02, and 0x83. Ports 0x05–0x07 then read 0x03, 0x02, and 0x02; the visible windows are Flash page 2, duplicate Flash page 2, and RAM page 3. Port 0x04 still reads interrupt status 0x08. This exercises the paired-B expression through the registered port handlers. [standard]

Directly seeded backing bytes isolate the two forced ranges. In independent mode with 0x28 = 1 and 0x27 = 0xFF, reads at 0x8000, 0x803F, and 0x8040 return markers 0xB0 and 0xB1 from RAM page 1, then underlying Flash marker 0xA2. Reads at 0xFB63 and 0xFB64 return marker 0xC3 from underlying RAM page 5 and marker 0xD4 from forced RAM page 0. Low-level writes change RAM pages 1 and 0 while leaving the two underlying windows unchanged. A NOP in forced RAM over an underlying Flash HALT executes the NOP. [standard]

Switching only to paired mode changes those five reads to underlying markers 0xE0, 0xE1, 0xE2, 0xF3, and 0xF4. Low-level writes modify the underlying Flash pages while both forced RAM markers remain unchanged. The same NOP/HALT discriminator executes the underlying HALT. These writes call Wabbitemu’s low-level mapper function; they test address routing, not Flash command acceptance. The run establishes emulator behavior only. [standard]

Native MAME mapper edges

A guarded MAME 0.287 run uses five fresh processes so each handoff case starts with m_booting set. The untouched process reports PC = 0x0000, port reads 08 00 00 00 for 0x04–0x07, and visible Flash prefixes 3E 07, DB 02, 44 6F, and DB 02 in windows 0, A, B, and C. These prefixes identify pages 3F, 00, 01, and 00 in the exact OS 2.55MP image. [standard]

Reading A through Lua’s CPU program space changes the window-0 prefix from page 3F’s 3E 07 to page 00’s DB 02. This MAME Lua access carries read side effects; it is not a side-effect-free debugger peek. Three tiny programs in RAM then perform actual Z80 data reads in separate processes. An independent B read returns page-02 byte 0E and leaves page 3F fixed. An A read returns page-01 byte 44 and fixes page 00. A paired B read returns page-03 byte 02 and also fixes page 00. Each program reaches the expected HALT at 0xC008. [standard]

The selector cases exercise only mapped backing. Flash write 0x41 reads back 01 and exposes page 01; 0x7F reads back 3F and exposes page 3F. RAM selectors 0x80, 0x85, and 0x86 reach seeded pages 0, 5, and 6. Port 0x05 = 0xFE reads back 06 and reaches RAM page 6. In paired mode, port 0x06 = 0x02 exposes adjacent Flash pages 02 and 03, while port 0x07 = 0x83 maps RAM page 3 into C. The probe omits selector 0x87; the pinned address map places that bank beyond its seven mapped RAM pages. [standard]

Ports 0x0E, 0x0F, 0x27, and 0x28 return zero before and after patterned writes. With underlying RAM pages 2 and 3 in B and C, writes at 0x8000 and 0xFB64 change those pages while seeded candidate overlay bytes in RAM pages 1 and 0 remain unchanged. A fetched discriminator executes marker 22 from underlying RAM page 2 rather than marker 11 from candidate overlay page 1. The run therefore covers MAME read, write, and instruction-fetch routing without treating the missing overlay as ASIC evidence. [standard]

Interaction with execution protection

Ports 0x21–0x26 control Flash and RAM execution permissions. They do not select pages; see Execution protection for their write gate, equations, and boundary discrepancies.

TilEm first resolves a port-0x27 or port-0x28 overlay, then applies the execution rule for the resulting physical RAM page. A fetch forced from a Flash-backed window into RAM is therefore checked as RAM in TilEm. [standard]

Wabbitemu’s fetch check chooses its Flash-versus-RAM branch from the underlying window before adjusting a RAM address for the overlay. A forced RAM range over an underlying Flash page can therefore follow different protection logic from TilEm. This is an emulator fidelity difference, not evidence for either ASIC ordering. [standard]

The analyzed OS leaves both overlays disabled before normal execution, so this difference does not affect the traced boot and homescreen paths. [confirmed]

Safe mapper use

• Preserve every selector that the routine changes. Ports 0x05, 0x06, 0x07, 0x0E, 0x0F, 0x27, and 0x28 have readable state in the public contract, TilEm, and Wabbitemu. MAME does not implement the latter four. [standard]
• Do not use IN A,(0x04) to save the memory mode. Reads return interrupt status. Code entered under TI-OS can rely on its documented normal independent mode or must receive the mode from its caller. [standard]
• Disable interrupts around a temporary mapping unless the interrupt path can run with that mapping. The OS page-83 helpers preserve interrupt state for this reason. [confirmed]
• When changing paired mode, ensure the next instruction remains mapped. Fixed page 0 is the least state-dependent place to perform the transition. [standard]
• On family members with more than 128 Flash pages, preserve the matching high selector with each low Flash selector. Restoring only port 0x06 or 0x07 can restore the wrong physical page. [standard]
• Restore normal TI-84 Plus RAM windows with port 0x07 = 0x81 and port 0x05 = 0x00 when the caller follows the ordinary OS convention. For a general library, restore the values read on entry instead. See RAM pages.

Reproducing the mapping

tools/ti84re/hardware/memory_mapper.py contains explicit documented, tilem, wabbitemu, and mame profiles. tools/ti84re/hardware/describe_memory_mapping.py applies writes and reads, compares profiles, and can emit JSON. List the pinned coverage first:

nix develop -c python3 -m ti84re.hardware.describe_memory_mapping profiles

This reproduces the final TilEm boot state shown above:

nix develop -c python3 -m ti84re.hardware.describe_memory_mapping \
  map --profile tilem \
  --write 0x0e=3 --write 6=0x7f \
  --write 0x0f=3 --write 7=0x7f --write 4=6 \
  --write 7=0x81 --write 0x0e=0 --write 0x0f=0 \
  --write 5=0 --write 6=0x3f --write 7=0x80

An even paired selector exposes Wabbitemu’s duplicated B page while also showing MAME’s ignored high-selector and overlay writes:

nix develop -c python3 -m ti84re.hardware.describe_memory_mapping compare \
  --write 4=1 --write 6=2 \
  --write 0x0e=3 --write 0x27=0xff --write 0x28=1

To reproduce MAME’s fixed-page read latch and machine-read the result:

nix develop -c python3 -m ti84re.hardware.describe_memory_mapping --json \
  map --profile mame --read 0x4000

The trace resolver uses the same library. To show the executed boot writes:

nix develop -c python3 -m ti84re.trace.resolve /tmp/boot.trace \
  --initial-mapping ti84p-reset --page-switches \
  --io-ports 04-07,0e-0f,27-28

Static whole-ROM port scans are candidate generators because data can decode as instructions. Add context and verify control flow before treating a hit as code:

nix develop -c python3 -m ti84re.rom.analyze_io \
  --before 8 --after 8 0x0e-0x0f,0x27-0x28

tools/ti84re/emulators/wabbitemu/mapper_probe.py derives the native edge expectations from the same mapper profile. tools/ti84re/emulators/wabbitemu/run_mapper_edge_probe.py requires the exact OS 2.55MP ROM and writes a hash-complete JSON manifest.

tools/ti84re/emulators/mame/mapper.py derives the corresponding MAME oracle from the reusable profile and pinned ROM prefixes. The guarded CLI runs every latch case from a fresh machine:

mame_mapper_parent=$(mktemp -d /tmp/ti84-mame-mapper.XXXXXX)
nix shell nixpkgs#mame --command python3 -m ti84re.emulators.mame.run_mapper_probe \
  --expected-mame-sha256 \
    fc5f4aba1aa6eb115d66decad13bb3f5313b9f3be9cff7c785d8d88e3fca0b91 \
  --output-dir "$mame_mapper_parent/run" --json

Open physical tests

• Write nonzero values to ports 0x27 and 0x28 in independent mode and test both range boundaries with reads and writes.
• Repeat the boundary tests in paired mode to distinguish TilEm from Wabbitemu and the historical WikiTI claim.
• Execute controlled code on each side of an overlay boundary while varying ports 0x21–0x26; record whether protection follows the underlying window or the forced RAM page.
• Test port 0x27 below 0xFB64 to determine whether Wabbitemu’s additional cutoff models hardware or is an emulator-specific restriction.
• Read ports 0x0E and 0x0F after writing values with upper bits set on TA2, TA3, and larger-Flash family members.
• Select an even Flash page through port 0x06 in paired mode and verify that window B exposes the adjacent odd page rather than Wabbitemu’s duplicate.
• Select RAM page 87 through ports 0x05, 0x06, and 0x07; this confirms the physical page independently of MAME’s seven-page backing-map defect.

Sources

Bus timing and wait states

The TI-84 Plus ASIC inserts programmable T-states into Flash, RAM, and LCD transactions. CPU-speed mode selects one of four LCD-delay registers, which also gates the memory waits in port 0x2E; port 0x2F separately controls the high-speed LCD-ready interval and a documented programmable-timer prescaler.

OS 2.55MP programs this block once during retail boot. The ROM bytes and trace pin the register values. Public measurements, TilEm, and Wabbitemu supply the detailed timing contract; MAME provides an explicit omission comparison.

Evidence and limits

The trace proves what the ROM writes and which CPU-speed values execute. It does not measure the ASIC bus electrically. Emulator-added clock counts are reported as emulator behavior, not physical measurements.

Register block

TilEm reads back the last byte written to ports 0x29–0x2C, 0x2E, and 0x2F. Wabbitemu registers one generic latch handler across the complete 0x29–0x2F range. Its port 0x2D therefore stores a raw byte instead of implementing the separate low-power contract. MAME maps only port 0x20 from this block; its I/O map has no handler for the six delay-register writes. [standard]

Selection pipeline

Let $s = p_{20} \bmod 4$. The active speed-dependent register is [standard]

$$ D_s = p_{29+s} $$

That one byte controls two independent effects:

• bits 2–7 select the T-states added to each LCD-port instruction;
• bit 0 enables the Flash bits in port 0x2E, and bit 1 enables the RAM bits.

Timing model. The register behavior is [standard], and the diagram’s widths are conceptual. OS 2.55MP’s register bytes and executed speed values are [confirmed].

Changing port 0x20 changes the active byte immediately in TilEm and Wabbitemu. The OS does not need to rewrite ports 0x29–0x2C when it moves between 6 and 15 MHz. Both emulators recompute memory delays on an accepted speed write. [standard]

Under the public TI-84 Plus contract and TilEm, speed value 0 selects nominal 6 MHz and values 1–3 select nominal 15 MHz. Wabbitemu’s default TI-84 Plus context clamps writes 2–3 to mode 1. Its external extraSpeed option instead assigns 20 and 25 MHz to modes 2 and 3. MAME stores the raw byte and selects 15 MHz for every nonzero value. These are software policies, not evidence for extra physical TI-84 Plus clocks. OS 2.55MP uses only values 0 and 1 in the captured workflows. See Clock, timers, and power for frequency and ASIC-revision caveats. [confirmed] for executed values; [standard] for public and emulator behavior.

A guarded initialized-core run writes 0xFC–0xFF. The reset timer_version = 0 context reads back modes 0/1/1/1 at 6, 15, 15, and 15 MHz. Directly setting timer_version = 1 produces modes 0/1/2/3 at 6, 15, 20, and 25 MHz. The direct setting represents Wabbitemu front-end state; it is not a calculator port transition. [standard]

A guarded MAME run writes 00, 01, 02, 03, and FF to port 0x20 and reads the same five raw bytes back. A 50-T-state RAM counter advances 12,000 times during five 20 ms frames after write zero and 30,000 times after write one. The exact 2.5 ratio dynamically distinguishes 6 MHz from 15 MHz. A MAME soft reset retains raw speed 0x03; this is driver behavior, not a calculator reset claim. [standard]

Boot configuration

boot_bus_timing_init at 3F:41BD writes the complete block after the retail boot RAM probes and link-assist initialization: [confirmed]

3F:41BD  LD A,0x17
3F:41BF  OUT (0x29),A
3F:41C1  LD A,0x27
3F:41C3  OUT (0x2A),A
3F:41C5  LD A,0x2F
3F:41C7  OUT (0x2B),A
3F:41C9  LD A,0x3B
3F:41CB  OUT (0x2C),A
3F:41CD  LD A,0x45
3F:41CF  OUT (0x2E),A
3F:41D1  LD A,0x4B
3F:41D3  OUT (0x2F),A

The resolved trace executes the writes at clocks 1,747,536 through 1,747,628. Port 0x20 still reads zero at 3F:653E. The OS later writes zero at ram:0DD5 and selects speed mode 1 at ram:0C72. [confirmed]

TilEm resets its internal registers to the older values 0x14, 0x27, 0x2F, 0x3B, 0x44, and 0x4A. The retail boot writes above replace every differing value before normal OS operation. Emulator reset defaults therefore must not be mistaken for TI-84 Plus OS policy. [standard]

MAME accepts the later port-0x20 speed write but drops all six boot writes to ports 0x29–0x2C, 0x2E, and 0x2F. It therefore runs the ROM at the selected base clock without the programmable LCD or memory additions described below. A native patterned-write run reads zero from every port 0x29–0x2F both before and after the writes. [standard]

LCD instruction delay — ports 0x29–0x2C

TilEm and Wabbitemu add [standard]

$$ T_{\mathrm{LCD}} = D_s >> 2 $$

T-states to each Z80 IN or OUT instruction targeting LCD ports 0x10–0x13. The two low bits do not contribute to this count; they gate memory waits.

The OS bytes decode as follows:

At nominal 6 MHz, five T-states are about 0.833 µs. At nominal 15 MHz, nine T-states are 0.6 µs. These are additions to the Z80 I/O instruction, not the complete interval between two LCD transfers. [standard]

Published hardware tests report that values below 0x0C can make LCD writes stop responding, while read behavior has a different lower boundary. The exact threshold and failure mode should be remeasured by controller and ASIC revision. [standard] for the published observation; [hypothesis] for cross-revision behavior.

Memory waits — port 0x2E

Each selected bit adds one T-state to one memory-access class. Bits 0–2 apply only when active register $D_s$ has bit 0 set. Bits 4–6 apply only when $D_s$ has bit 1 set. [standard]

The boot value 0x45 sets bits 6, 2, and 0. Because all four active-register bytes have gate bits 0 and 1 set, the OS policy in every speed mode is: [confirmed] for register values; [standard] for the access decode.

A CB-, ED-, DD-, or FD-prefixed Z80 instruction performs two M1 fetches. Both TilEm and Wabbitemu apply the opcode wait to the prefix and following opcode. A repeated DD or FD prefix adds another M1 fetch in both cores. [standard] for the Z80 bus cycle and pinned emulator source paths.

Indexed CB instructions expose a model difference. The Z80 fetches DD or FD and CB with M1 signaling, then reads the displacement and final opcode without M1. TilEm follows this split in z80main.h:674 and z80ddfd.h:301. Wabbitemu routes the final opcode through CPU_opcode_fetch at core/core.c:832, then decrements R at line 836. Its wait model therefore counts three opcode waits while its visible refresh count remains two. The hash-guarded ti84re.emulators.describe_prefix_fetch_models CLI reproduces this result from the pinned source trees. The exact assembled HWPFX program also reproduces the split in the pinned Wabbitemu runtime: its indexed-CB row adds 30 timer ticks, compared with 25 for the three ordinary one-prefix rows and 29 for repeated DD. [confirmed] for the emulator run; physical ASIC placement remains open.

The delay follows the physical page selected by the mapper in TilEm. An opcode executed from banked RAM uses the RAM M1 bit; the same logical address backed by Flash uses the Flash bit. See Paging for physical-page resolution. [standard]

One T-state is about 0.167 µs at nominal 6 MHz and 0.067 µs at nominal 15 MHz. The register therefore preserves a cycle margin, not a fixed wall-time margin, when CPU speed changes. [standard]

LCD-ready interval — port 0x2F

The LCD instruction delay above slows the I/O instruction itself. Port 0x2F controls a second mechanism: at high speed, the ASIC deasserts port-0x02 bit 1 for a longer programmable interval after an LCD transaction. The OS lcd_wait helper polls that bit before accessing the controller. See LCD controller and display bus. [standard]

Speed mode selects one field: [standard]

For a selected field $f$, TilEm and Wabbitemu use [standard]

$$ T_{ready} = 48 + 64f $$

The boot value 0x4B produces:

TilEm restarts this ready timer on every modeled access to ports 0x10–0x13, including reads. Wabbitemu derives readiness from the last successful LCD write. This disagreement matters for read-heavy code and requires a physical test. [standard] for emulator behavior; [hypothesis] for ASIC read behavior.

The guarded Wabbitemu initialized-core run sets speed mode 1 and field 3, then writes the LCD at T-state 2,000. Port 0x02 reads 0xE1 at T-state 2,240 and 0xE3 at 2,241. An accepted status read at 2,241 leaves the write timestamp at 2,000 and leaves port 0x02 at 0xE3. The comparison is strict rather than inclusive: readiness requires elapsed time greater than 240 T-states in this implementation. [standard]

Programmable-timer mode-3 divisor

Public documentation assigns a second role to the selected port-0x2F field. For programmable-timer sources in the 0xC0 family, the field selects divisor $f+1$; speed mode 0 applies no divisor. [standard]

With the OS byte 0x4B, the documented divisors are 1, 4, 3, and 3 for speed modes 0–3. TilEm treats the 0xC0 family like its ordinary CPU-clock modes, and Wabbitemu’s timer-source update does not use port 0x2F. The prescaler is therefore absent from both compared emulator paths. [standard]

OS 2.55MP’s timer API can select 0xC0-family sources. The prepared HWTMR probe counts source-0xE0 expiries against a crystal reference in CPU-speed modes 0–3. Its exact assembled image completes in pinned Wabbitemu and measures a prescaler near one, matching that emulator’s source implementation. No result from a physical calculator has been recorded. [confirmed] for the probe and emulator run; [hypothesis] for the physical divisor.

Emulator comparison

The matching memory and LCD-instruction decode corroborates the public bit layout. MAME cannot corroborate that decode because it omits the block. The readiness, speed, and timer differences remain emulator policy, not proof of physical timing.

The same guarded Wabbitemu run dynamically checks three linked cases. Port 0x2A = 0x27 adds nine T-states to a status read. With port 0x2E = 0x45, the enabled additions are Flash opcode fetch, Flash write, and RAM write. A write of speed value 3 reads back mode 1 in the reset TI-84 Plus context because timer_version = 0 disables the external extra-speed modes. [standard]

A dedicated speed run reads all seven reset latches as zero and verifies raw byte readback across ports 0x29–0x2F. With active-register values 0x00/0x01/0x02/0x03 and port 0x2E = 0x77, modes 0–3 produce wait masks 0x00/0x07/0x38/0x3F: none, all Flash classes, all RAM classes, and all six classes. Writing 0x5A to port 0x2D changes only that latch. The active wait mask, CPU frequency, timer version, programmable-timer state, LCD-active state, HALT, interrupt line, and T-state count remain unchanged. These observations describe Wabbitemu’s registered handler, not physical low-power behavior. [standard]

Reproducing the decode

tools/ti84re/hardware/bus_timing.py is a pure register decoder. tools/ti84re/hardware/describe_bus_timing.py prints all four speed modes from the boot values:

nix develop -c python3 -m ti84re.hardware.describe_bus_timing

The default documented profile reports:

documented (WikiTI pages retrieved 2026-08-09): speed-mode=1 clock=15MHz port20=01/01
  port2e=0x45 port2f=0x4B
  mode  port value  MHz  LCD-I/O  Flash +1T      RAM +1T        LCD-ready  doc-div
   0    0x29  0x17    6      5T     M1,write       write            0T       /1
   1    0x2A  0x27   15      9T     M1,write       write          240T       /4
   2    0x2B  0x2F   15     11T     M1,write       write          176T       /3
   3    0x2C  0x3B   15     14T     M1,write       write          176T       /3

doc-div is the public port-0x2F divisor decode. It is not an emulator claim. Compare the four pinned implementations, including ignored MAME writes and jsTIfied’s stored-delay model, with:

nix develop -c python3 -m ti84re.hardware.describe_bus_timing --compare
nix develop -c python3 -m ti84re.hardware.describe_bus_timing --compare --json

Pass --extra-speeds to model Wabbitemu’s external 20/25 MHz option. The flag does not describe the default TI-84 Plus configuration.

Repeated --write PORT=VALUE options make altered settings explicit. JSON is available for scripts:

nix develop -c python3 -m ti84re.hardware.describe_bus_timing \
  --write 0x20=0 --write 0x29=0x17 --write 0x2e=0x45 --json

Run the native boundary checks with the pinned Wabbitemu adapter:

wabbit_lcd_parent=$(mktemp -d /tmp/ti84-wabbit-lcd.XXXXXX)
python3 -m ti84re.emulators.wabbitemu.run_lcd_edge_probe \
  --rom tools/rom.bin \
  --binary "$wabbit_tmp/wabbitemu-headless" \
  --output-dir "$wabbit_lcd_parent/run" --json

wabbit_speed_parent=$(mktemp -d /tmp/ti84-wabbit-speed.XXXXXX)
python3 -m ti84re.emulators.wabbitemu.run_speed_edge_probe \
  --rom tools/rom.bin \
  --binary "$wabbit_tmp/wabbitemu-headless" \
  --output-dir "$wabbit_speed_parent/run" --json

mame_asic_parent=$(mktemp -d /tmp/ti84-mame-asic.XXXXXX)
nix shell nixpkgs#mame --command python3 -m ti84re.emulators.mame.run_asic_probe \
  --expected-mame-sha256 \
    fc5f4aba1aa6eb115d66decad13bb3f5313b9f3be9cff7c785d8d88e3fca0b91 \
  --output-dir "$mame_asic_parent/run" --json

The manifest labels the run as initialized-core emulator evidence and records both input hashes. tools/ti84re/emulators/wabbitemu/lcd_probe.py derives its pointer, latch, ready-hold, delay, wait-bit, and speed-clamp expectations from the reusable LCD and bus-timing libraries.

tools/ti84re/emulators/wabbitemu/speed_probe.py derives speed, latch, and wait-mask expectations from tools/ti84re/hardware/bus_timing.py. Its guarded CLI records both input hashes and labels the direct timer_version = 1 configuration explicitly. tools/ti84re/emulators/mame/asic.py reuses the MAME timing profile for raw readback, binary clock selection, and the absent delay block.

The executed initialization can be recovered from a full boot trace:

nix develop -c python3 -m ti84re.trace.resolve /tmp/boot.trace \
  --initial-mapping ti84p-reset --io-ports 20,29-2f

Open physical tests

The read-only ASIC register snapshot captures ports 0x20, 0x29–0x2C, 0x2E, and 0x2F before a mutating timing test. It does not measure any delay. No physical snapshot is recorded. [confirmed] for the probe bytes; [hypothesis] for pending readback values.

The guarded memory-bus timing probe prepares paired timer-2 measurements for all six access classes. Its counted loops separate fixed-Flash opcode fetches, Flash data reads, safe Flash reset writes, RAM opcode fetches, RAM non-opcode reads, and idempotent RAM writes. It restores the entry timing byte and an initially idle timer 2. No exported physical result has been recorded. [confirmed] for the probe bytes and decoder; [hypothesis] for pending measurements.

The guarded prefix-M1 timing probe prepares paired RAM-M1 measurements for unprefixed, CB, ED, DD, repeated-DD, and indexed-CB shapes. The indexed-CB row distinguishes TilEm and documented Z80 M1 placement from Wabbitemu’s extra wait. The exact image completes through the cleanup boundary in pinned Wabbitemu and selects its three-wait model. No physical result has been recorded. [confirmed] for the probe bytes, decoder, and emulator run; [hypothesis] for pending measurements.

The guarded programmable-timer probe prepares the port-0x2F mode-3 measurement. It also distinguishes crystal divisor, counter-zero, and expiry-status models while timers 1 and 2 are idle. The exact image completes through cleanup in pinned Wabbitemu. No exported physical result has been recorded. [confirmed] for the probe bytes, decoder, and emulator run; [hypothesis] for pending measurements.

• Run all three prepared timing matrices on TA2 and TA3 units.
• Repeat the loop test with active-register gate bits 0 and 1 cleared to verify whether they disable all corresponding 0x2E effects.
• Measure the interval from LCD writes and reads to port-0x02 bit 1 becoming ready. This distinguishes TilEm’s every-access restart from Wabbitemu’s write-based model.
• Find the lowest reliable ports-0x29–0x2C values for each LCD controller revision without assuming the published 0x0C threshold is universal.
• Compare the HWTMR port-0x2F results across CPU-speed modes and ASIC revisions.
• Compare nominal and measured T-state wall times on TA2 and TA3 ASICs.

Sources

ASIC status, identity, protection, and GPIO

TI-84 Plus OS 2.55MP — status, battery comparison, protection mode, and GPIO.

Ports 0x02, 0x15, 0x21, 0x39, and 0x3A expose several unrelated ASIC controls. The ROM establishes how TI-OS uses four of them. Port 0x15 comes only from public tables and emulator configuration because this ROM does not read it through an immediate or statically resolved literal-C access.

Evidence boundaries

The sources answer different questions. Emulator behavior is useful for constructing tests, but it does not establish electrical behavior on a physical calculator.

The static I/O scanner reports candidates from a linear disassembly. Data can decode as instructions, so a candidate needs control-flow or trace evidence. The credible code for these ports is concentrated in page 00, pages 2F, 33, 35–37, 3C, 3D, and the retail boot page 3F. [confirmed]

Complete ROM I/O candidate audit

Unlisted immediate ports

A full linear scan of the 1 MiB retail ROM finds 35 aligned immediate-port candidates whose 21 apparent port values are absent from the project port map. This count removes inline bcall and bjump descriptors. None establishes an I/O operation. [confirmed]

The rebuilt Ghidra database gives the 34 table candidates no containing function and no xrefs. A page-local direct CALL/JP scan also finds no target to any candidate. Ghidra places 03:6DE1 inside editbuf_clr_hibit, but the owning instruction starts at 03:6DE0; bytes DB 9C are the little-endian operand of LD HL,0x9CDB. [confirmed]

A reset/idle TLMT trace executes 1,753,851 instructions and reaches none of the 35 locations. This trace result covers one emulator scenario. The byte and control-flow classifications, rather than trace absence, establish that these linear candidates do not add ports to the ROM inventory. [confirmed]

Register and block I/O

A separate raw-byte scan finds every ED-prefixed register and block-I/O opcode pair. It does not depend on recovering the value of C across calls or control-flow joins. The exact retail ROM contains 37 pairs and no ED prefix at a 16 KiB page boundary. [confirmed]

The 27 operand sites include ED 41 inside JP Z,0x41ED at 04:4177, ED 70 inside CALL 0x70ED at 04:6F5A, and ED 40 inside LD HL,0x40ED at 39:73B6. The scanner resolves the two aligned instructions from their preceding literal loads and DEC C. No other raw pair is an I/O instruction, so this ROM has no hidden computed-C access to an unlisted, status, GPIO, or USB port. [confirmed]

tools/ti84re/rom/io_coverage.py contains the reusable scanner and review manifest. The manifest pins retail ROM SHA-256 7d9a7d96d89fc552ebee6afdbdd011fdc6047be9c16d308245dff07eb1f7bd6d. The CLI fails on a different ROM, a missing or duplicate review, a stale location, or changed instruction bytes. --trace uses the constant-memory point counter instead of constructing an object for every instruction:

nix develop -c python3 -m ti84re.rom.describe_io_coverage
nix develop -c python3 -m ti84re.rom.describe_io_coverage --json
nix develop -c python3 -m ti84re.rom.describe_io_coverage \
  --trace /tmp/trace-benchmark.tlmt

The complete direct result is 34 reviewed-data entries and one operand-overlap. The indirect result is 27 operand-overlap, eight reviewed-data, and two resolved-instruction entries. Both manifests have zero unresolved candidates. [confirmed]

Port 0x02 status

Port 0x02 combines transient hardware state with model-family bits. The boot and archive traces return 0xE1, 0xE3, and 0xE7. [confirmed]

_NZIf83Plus model probe [confirmed]

_NZIf83Plus = 0x50E0, body ram:1837, preserves BC and the caller’s A while returning its result only in the flags. It reads port 0x02, masks bit 7, and XORs with 0x80. Bit 7 set therefore returns Z; bit 7 clear returns NZ. The historical name should not be read as “NZ on every TI-83 Plus-family calculator.” OS 2.55MP uses the flag to distinguish the advanced TI-84 Plus path from the older family path.

A controlled trace enters with A = 0xA5, returns with the same A, and records Z set on the TI-84 Plus model. The reduced result is in tools/data/community-manual-bcall-traces.csv. [confirmed] under TilEm.

Complete direct-consumer audit

The 1 MiB ROM contains exactly 55 raw DB 02 byte pairs, the opcode and operand for IN A,(0x02). Every linear-disassembly candidate reaches one of three conservative A-register consumers within two following instructions: [confirmed]

The 33:4E9F battery path inserts LD C,0 before BIT 0,A. Every other candidate tests A in the next instruction. The decoder crosses only instructions that preserve A; calls, branches, arithmetic, and unknown instructions produce an unclassified result. This ROM produces zero unclassified candidates. [confirmed]

No status read selects bits 2–6. The complete raw register/block-I/O census finds no port-0x02 access beyond these 55 immediate reads. This result does not depend on propagating C across a call or control-flow merge. [confirmed]

The assist routines therefore use bit 7 as their model-family gate. Public bit 6 remains a hardware capability field, but OS 2.55MP does not consult it before the link-assist port accesses described in USB ASIC and link assist.

TilEm computes bits 0–2 from its battery value, LCD wait timer, and Flash lock. Wabbitemu does the same except that its TI-84 Plus battery result is fixed high. Their agreement supports the interpretation but does not replace a voltage or timing measurement. [standard]

The certificate-tail use gives bit 7 a concrete persistent-data consequence. The model-selected clear, write, and query paths call 3D:5247; the helper calls ram:1837, selects offset 0x1E50 for the TI-84 Plus trace values above, and selects 0x1F18 when bit 7 is clear. Wabbitemu independently makes the same family split, setting bit 7 for its TI-84 Plus models and clearing it for its TI-83 Plus family. [confirmed] for the ROM branch and resolved TI-84 Plus values; [standard] for the emulator family mapping.

MAME returns 0xC3 | (m_flash_unlocked << 2), truncated to one byte. Its comparator and LCD-ready bits are fixed high. The normal gate values zero and one therefore return 0xC3 and 0xC7. The handler does not normalize other bytes: writes 02, 3F, 40, and FF return CB, FF, C3, and FF. Port 0x14 remains write-only and reads zero. Bit 5 is fixed low for the normal locked status, so this TI-84 Plus driver reports link assist but not USB capability. These are emulator inconsistencies, not evidence for a different ASIC status layout. [standard]

Battery comparison

Port 0x04 has two roles on this hardware: its low bits configure mapping and standard-timer behavior, while bits 6–7 select a battery-comparison setting. The battery routines keep the low configuration at 0x06 and write 0x46, 0x86, or 0xC6 to change the upper selector. [confirmed] for the writes; [standard] for the selector interpretation.

_Chk_Batt_Low

The bcall _Chk_Batt_Low = 0x50B3 resolves to 00:0D07. A larger entry at 00:0D04 first runs a RAM-access delay, then performs this sequence: [confirmed]

00:0D07  IN A,(0x3A)
00:0D09  OR 0x80
00:0D0B  OUT (0x3A),A
00:0D0D  LD A,0x06
00:0D0F  OUT (0x04),A
00:0D11  LD A,0x86
00:0D13  OUT (0x04),A
              ; delay
00:0D20  IN A,(0x02)
00:0D22  BIT 0,A

The routine sets (IY+0x18) bit 5 before the comparison and clears it when port 0x02 bit 0 is zero. It restores port 0x04 to 0x06, writes 0xF0 to port 0x39, pulses port-0x3A bit 4, clears port-0x3A bit 7, then returns with Z reflecting (IY+0x18) bit 5. [confirmed]

Both boot entries set port-0x3A bit 7, sample port-0x02 bit 0, restore port 0x04 = 0x06, clear GPIO bit 7, and return Z according to the saved comparison flag. The public flag file names (IY+0x18) as traceFlags, so the bit’s wider ownership remains unknown. [confirmed]

_Chk_Batt_Level

The main bcall table resolves _Chk_Batt_Level = 0x5221 to 33:4E9B. The routine returns a value from 0 through 4 in A: [confirmed]

It sets (IY+0x18) bit 5 before the first comparison and clears that bit before the final 0x46 test. Results 1 and 2 therefore leave the bit clear. The routine restores 0x04 = 0x06, pulses GPIO bit 4, clears GPIO bit 7, and returns C in A. [confirmed]

TilEm maps the two high selector bits to the following thresholds. Its source labels the table FIXME: measure actual levels, so these voltages are emulator parameters rather than measured ASIC facts. [standard]

This mapping conflicts with the ROM’s comparison order. Whenever the later 0x46 comparison succeeds at 3.9 V or above, the earlier 0x86 comparison at 3.6 V has already returned level 3. Result 2 is therefore unreachable in that emulator model. Physical measurements must establish the actual selector ordering, thresholds, hysteresis, and load conditions. [confirmed] for the code/model comparison; [hypothesis] for the unmeasured electrical behavior.

Pinned TilEm comparator sweep

A guarded direct-core run sets TilEm’s battery field from 3.0 through 4.5 V in 0.1 V steps. For each value, it writes all four selectors through port 0x04 and reads port-0x02 bit 0. The observed comparator mask uses bit order 0x06, 0x46, 0x86, 0xC6: [standard]

The native mask transitions match the four source constants. The reusable model then applies the byte-verified decision tree at 33:4E9B–4EDA. The combination reaches levels 0, 1, 3, and 4, but not level 2. The probe binary has SHA-256 47008d660c7ea3e88c07df3d41d5c3e34c51d49850a806d5d2e37d5ca6214029. This run validates TilEm’s implementation; it does not measure a calculator’s battery rail. [confirmed] for the ROM tree; [standard] for the emulator run.

Port 0x15 identity

WikiTI publishes the following read values. They are [standard] because this OS image does not use the port through an immediate or statically resolved literal-C I/O instruction.

Wabbitemu returns these values according to its selected model and RAM revision. TilEm’s TI-84 Plus model returns fixed 0x45 with a ??? source comment. Neither implementation verifies what a particular physical unit returns. [standard]

MAME’s shared TI-83 Plus Silver Edition/TI-84 Plus I/O map returns fixed 0x33 from port 0x15 for every machine using that map. The TI-84 Plus configuration therefore identifies itself as the public 83PL2M/TA2 row. MAME’s MACHINE_NOT_WORKING declaration and shared handler make this a driver defect, not an alternate identity claim. [standard]

The complete-ROM scan finds no immediate IN or OUT instruction for port 0x15. The conservative C-register resolver also finds no access after a straight-line literal load into C or BC. Computed register-C accesses that cross calls or control-flow edges remain outside that static proof. [confirmed]

Port 0x21 Flash grouping and RAM execution mode

Port 0x21 is a writable protected register, not a read-only ASIC identity. The retail boot page loads A=0, executes the protected-byte sequence, and writes the value at 3F:41DC. [confirmed]

3F:41D5  LD A,0x00
3F:41D7  NOP
3F:41D8  NOP
3F:41D9  IM 1
3F:41DB  DI
3F:41DC  OUT (0x21),A
3F:41DE  DI

TilEm stores writes only while Flash is unlocked and exposes value & 0x33 on reads. Wabbitemu also marks the port protected and stores the same two fields. Its read handler shifts the stored mode right by four a second time, so it loses bits 4–5. [standard]

MAME accepts writes without the protected-byte gate, stores value & 0x0F, and returns that nibble. It can therefore expose undocumented bits 2–3 while discarding the RAM execution field in bits 4–5. MAME does not implement the execution-protection ports controlled by that field. A native locked write of 0x33 reads back 0x03; opening the port-0x14 gate does not change results for writes 0x30, 0x03, 0x33, or 0xFF. [standard]

Complete immediate-I/O audit

The ROM contains 11 raw DB 21 pairs and three raw D3 21 pairs. Ten reads are instructions, and every one immediately executes AND 0x03. The boot write at 3F:41DC is the only OUT (0x21),A instruction. [confirmed]

The remaining three raw pairs overlap other instructions: [confirmed]

The rebuilt Ghidra database confirms instruction ownership for these boundaries. The raw scanner reports zero unclassified pairs and zero decoded instructions without a matching opcode pair. The conservative literal-C resolver finds no additional port-0x21 access. [confirmed]

Bits 0–1: Flash group

The OS repeatedly reads port 0x21 & 3 to distinguish the 1 MiB TI-84 Plus configuration from larger family members. The archive App scan at 3D:726E selects top page 0x29 when the field is zero and 0x69 for the remaining advanced-family branch. [confirmed]

WikiTI supplies these configured sizes. TilEm also uses the field as a Flash-sector protection override group. The physical relation between the programmed field and chip capacity has not been tested here. [standard] for the table and model; [hypothesis] for unmeasured hardware.

Bits 4–5: RAM execution mode

WikiTI describes this field as RAM chip size. The boot writes mode 0 even on a 128 KiB TI-84 Plus. “RAM execution mode” therefore describes the observed use more precisely than treating it as detected capacity. [confirmed] for the boot value; [standard] for the public size labels.

TilEm converts the field to one of four repeating masks. Wabbitemu’s intended page shortcut collapses to zero for modes 1–3, so it does not implement the same arithmetic. Ports 0x25 and 0x26 add inclusive 1 KiB bounds. See Execution protection for the equations, complete page coverage, and physical tests. [standard]

Ports 0x39 and 0x3A GPIO

The ROM treats port 0x39 as GPIO direction or configuration and port 0x3A as GPIO data. It normally updates 0x3A with read-modify-write sequences so unrelated bits retain their values. [confirmed]

The direction polarity is not established by the ROM alone. WikiTI’s port 0x39 page says both that clearing and setting a bit designate output, which is self-contradictory. Its port-0x3A page recommends 0xE0, but this boot writes 0xF0 at 3F:4214, and the archive trace later reads back 0xF0 from port 0x39. Those public direction claims remain [hypothesis] pending physical tests.

Complete immediate-I/O audit

Raw-byte coverage separates GPIO code from accidental opcode pairs: [confirmed]

The two DB 3A overlaps begin on an 0xDB operand byte. At 06:5A8C, the owner is CP 0xDB; at 3C:7364, the owner is a relative JR whose displacement is 0xDB. In both cases, 0x3A begins the following LD A,(nn) instruction. [confirmed]

Of the 13 port-0x39 reads, every one begins an adjacent read-modify-write. The 16 writes comprise those 13 updates and three direct 0xF0 writes at ram:0D39, 37:6D10, and 3F:4214. Port 0x3A has 17 adjacent read-modify-write sequences. Its remaining two reads test bit 3 at 2F:521B and 35:402C. The page-35 body duplicates the page-2F USB implementation. [confirmed]

TilEm lacks a meaningful TI-84 Plus port-0x3A model, Wabbitemu lacks port 0x39, and MAME maps neither port. Emulator execution can check control flow around these instructions, but it cannot validate the paired GPIO state or electrical effect. The sequences below are byte- and control-flow-validated against the ROM; their physical signal interpretation remains unmeasured. [confirmed] for the instructions; [hypothesis] for electrical behavior.

Battery GPIO sequence

_Chk_Batt_Level provides the clearest GPIO sequence: [confirmed]

1. Set port-0x3A bit 7.
2. Run the port-0x04 comparator tests.
3. Set port-0x39 bit 4.
4. Set port-0x3A bit 4, delay, and clear it.
5. Clear port-0x3A bit 7.

The shorter _Chk_Batt_Low path writes 0xF0 directly to port 0x39 before the bit-4 pulse. The ROM confirms that bits 7 and 4 participate in battery testing. It does not expose the electrical signal names. [confirmed]

USB GPIO sequence

The boot USB code on page 2F and the parallel OS code on page 35 use the low GPIO bits: [confirmed]

These operations tie GPIO bits 0–3 to USB setup and state selection. The exact charge-pump, PHY, or cable signals remain [hypothesis]. See USB ASIC and link assist for the controller transaction.

Dynamic and emulator limits

The boot trace writes 0xF0 to port 0x39 but does not access port 0x3A. The archive scenario reads and rewrites 0xF0 through port 0x39; it also does not reach port 0x3A. Those traces cover startup and archive work, not battery level or connected USB workflows. [confirmed]

TilEm’s TI-84 Plus model returns fixed 0xF0 from port 0x39 and has no meaningful write or port-0x3A model. Wabbitemu stores port 0x3A as a latch but does not register port 0x39. Both emulators model a color-calculator backlight side effect for port-0x3A bit 5; that does not validate TI-84 Plus GPIO wiring. [standard]

MAME maps neither port 0x39 nor port 0x3A. Battery and USB code can execute through the driver, but those GPIO reads and writes reach no device handler. [standard]

Native Wabbitemu confirmation. The guarded initialized-core probe reads port 0x02 as 0xE3 while the in-memory Flash gate is locked and as 0xE7 after directly opening that gate. With Wabbitemu’s TI-84 Plus model, port 0x15 reads 0x44 at RAM revision 0 and 0x55 at RAM revision 2. [standard]

Port 0x21 is active and protected. A write of 0x33 while Flash remains locked is rejected, leaving both internal fields and readback zero. After the probe directly opens the in-memory gate, writing 0x30 stores internal RAM execution mode 3 but reads back 0x00. Writing 0x03 stores Flash group 3 and reads 0x03. Writing 0x33 stores both internal fields while still reading 0x03. This run exercises the protected device handler, not the retail ROM’s port-0x14 unlock sequence. [standard]

A separate initialized-core run verifies the same locked-write rejection for every port from 0x22 through 0x26. It also checks the Flash-bound low-byte handlers, port-0x24 high-field clearing, and the 16-bit RAM-bound wrap. See Execution protection for the complete value matrix and evidence limits. [standard]

The same initialized core has no active device at port 0x39; a read is rejected and produces the device layer’s 0xFF fallback. Port 0x3A is active, starts at zero, and reads back complete 0xA5 and 0x5A writes. The run advances zero T-states and does not assign electrical direction or signal meaning to either GPIO port. [standard]

Native MAME confirmation. The guarded run reads startup values C3, 00, 33, 00, and 00 from ports 0x02, 0x14, 0x15, 0x20, and 0x21. The raw gate sweep produces C3 C7 CB FF C3 FF for writes 00 01 02 3F 40 FF. Port 0x14 reads zero after every write. [standard]

Ports 0x22–0x2F and 0x39–0x3A return zero before and after patterned writes. A 50-T-state counter continues executing from RAM while port 0x21 reads 0x03 and ports 0x22–0x26 retain no written byte. The five-frame counter records 12,000 iterations at the zero speed value and 30,000 at the nonzero value. This checks one RAM execution path, not the missing physical boundary rules. [standard]

A scheduled MAME soft reset begins at PC = 0x0000 but retains a gate value of one, raw speed 0x03, and the port-0x21 nibble from write 0xAB. The reads are consequently 0xC7, 0x03, and 0x0B after reset. The driver reset routine does not restore these fields. This is MAME reset behavior and does not establish calculator warm-reset retention. [standard]

Emulator comparison

The four pinned implementations disagree on several control groups not already established by ROM use. Their values are test oracles for the software, not physical ASIC measurements.

Reusable analysis tools

tools/ti84re/hardware/asic_control.py decodes port-0x02 values, generic immediate-port consumers and raw-opcode coverage, the public port-0x15 table, port-0x21 modes, TilEm’s battery selector, and adjacent GPIO read-modify-write sequences. Its raw audit distinguishes aligned instructions, operand overlaps, reviewed data, and unclassified pairs. tools/ti84re/hardware/describe_asic_control.py exposes those operations as text or JSON. tools/ti84re/emulators/wabbitemu/asic_probe.py validates native results against the reusable source model. tools/ti84re/rom/io_coverage.py and tools/ti84re/rom/describe_io_coverage.py separately reconcile every direct candidate for ports absent from the project port map. tools/ti84re/emulators/wabbitemu/run_asic_edge_probe.py guards the exact ROM and native binary identities and writes a JSON manifest. tools/ti84re/emulators/wabbitemu/protection_port_probe.py applies the adjacent boundary-port model from tools/ti84re/hardware/execution_protection.py; its guarded CLI records the same two identities. tools/ti84re/emulators/mame/asic.py combines the ASIC and bus-timing profiles with a typed native report. tools/ti84re/emulators/mame/run_asic_probe.py guards the MAME, ROM, and Lua identities and retains the soft-reset output. tools/ti84re/hardware/battery.py formalizes the ROM result tree and threshold regions. tools/ti84re/hardware/describe_battery.py exposes voltage and raw-sample queries as text or JSON. tools/ti84re/emulators/tilem/battery.py validates a typed native comparator sweep against the same model. [confirmed] for the ROM-analysis tools; [standard] for the emulator oracle.

nix develop -c python3 -m ti84re.hardware.describe_asic_control
nix develop -c python3 -m ti84re.hardware.describe_asic_control --status 0xE7 --port21 0x20
nix develop -c python3 -m ti84re.hardware.describe_asic_control --implementations --json
nix develop -c python3 -m ti84re.hardware.describe_asic_control \
  --scan-status-consumers --json
nix develop -c python3 -m ti84re.hardware.describe_asic_control \
  --scan-port21-consumers --scan-gpio --json
nix develop -c python3 -m ti84re.hardware.describe_asic_control \
  --audit-port 0x21 --audit-port 0x39 --audit-port 0x3A
nix develop -c python3 -m ti84re.rom.analyze_io \
  0x02 0x15 0x21 0x39 0x3A --summary
nix develop -c python3 -m ti84re.rom.disassemble 0x33 \
  --start 0x4E9B --end 0x4F02
nix develop -c python3 -m ti84re.hardware.describe_battery --json
nix develop -c python3 -m ti84re.hardware.describe_battery --voltage 3.6
nix develop -c python3 -m ti84re.hardware.describe_battery --samples 1010

asic_probe_parent=$(mktemp -d /tmp/ti84-asic-probe.XXXXXX)
nix develop -c python3 -m ti84re.emulators.wabbitemu.run_asic_edge_probe \
  --rom tools/rom.bin \
  --binary "$wabbit_tmp/wabbitemu-headless" \
  --output-dir "$asic_probe_parent/run" --json

protected_port_parent=$(mktemp -d /tmp/ti84-protected-port.XXXXXX)
nix develop -c python3 -m ti84re.emulators.wabbitemu.run_protection_port_probe \
  --rom tools/rom.bin \
  --binary "$wabbit_tmp/wabbitemu-headless" \
  --output-dir "$protected_port_parent/run" --json

mame_asic_parent=$(mktemp -d /tmp/ti84-mame-asic.XXXXXX)
nix shell nixpkgs#mame --command python3 -m ti84re.emulators.mame.run_asic_probe \
  --expected-mame-sha256 \
    fc5f4aba1aa6eb115d66decad13bb3f5313b9f3be9cff7c785d8d88e3fca0b91 \
  --output-dir "$mame_asic_parent/run" --json

The I/O and GPIO scans generate candidates. A report becomes evidence for code only after raw-byte and control-flow review or a resolved execution trace.

Open physical tests

The read-only ASIC register snapshot captures ports 0x15, 0x21, 0x39, and 0x3A without changing GPIO configuration or data. It provides a baseline, not an electrical direction test. No physical snapshot is recorded. [confirmed] for the probe bytes; [hypothesis] for pending readback values.

• Run the restoring battery-level probe across an upward and downward controlled-supply sweep. It records 16 retail bcall results per point and verifies port/GPIO/flag cleanup. Run the higher-risk raw battery-selector probe after it at each voltage point. The second result records all four comparator bits so the sweep can assign individual selector thresholds and hysteresis.
• Read port 0x15 on known TA1, TA2, and TA3 units and compare the result with package markings and installed RAM.
• Program each port-0x21 field while Flash is unlocked. Test Flash protection groups and the execution ranges described in Execution protection. Do not rely on emulator reset behavior.
• Measure port-0x39 direction polarity and port-0x3A electrical state with battery and USB paths active. Preserve the OS configuration and avoid driving externally forced pins against the ASIC.

Sources

Execution protection

TI-84 Plus OS 2.55MP — Flash-page and RAM-chunk fetch controls.

Ports 0x21–0x26 define where the ASIC permits instruction fetches. The retail boot writes five protection registers before it changes the normal memory map. Emulator source supplies reproducible models for the resulting checks, but several boundary details still require physical measurement.

Evidence boundaries

The emulator equations below are source-verified descriptions of those programs. Agreement between an emulator and a public table does not promote an unmeasured ASIC behavior to [confirmed].

Registers and boot values

The boot sequence establishes these values. [confirmed]

boot_execution_protection_init at 3F:41D5 performs the five writes through 3F:4206: [confirmed]

3F:41D5  ld a,0x00
3F:41D7  nop
3F:41D8  nop
3F:41D9  im 1
3F:41DB  di
3F:41DC  out (0x21),a
3F:41DE  di

3F:41DF  ld a,0x08
3F:41E1  nop
3F:41E2  nop
3F:41E3  im 1
3F:41E5  di
3F:41E6  out (0x22),a
3F:41E8  di

3F:41E9  ld a,0x29
3F:41EB  nop
3F:41EC  nop
3F:41ED  im 1
3F:41EF  di
3F:41F0  out (0x23),a
3F:41F2  di

3F:41F3  ld a,0x10
3F:41F5  nop
3F:41F6  nop
3F:41F7  im 1
3F:41F9  di
3F:41FA  out (0x25),a
3F:41FC  di

3F:41FD  ld a,0x20
3F:41FF  nop
3F:4200  nop
3F:4201  im 1
3F:4203  di
3F:4204  out (0x26),a
3F:4206  di

Each output is preceded by fetched bytes 00 00 ED 56 F3 D3. TilEm advances its protected-write recognizer only while these bytes come from physical Flash 0xB0000–0xBFFFF or 0xF0000–0xFFFFF. Wabbitemu does not recognize the six bytes. It accepts a port-0x14 lock change whenever the output instruction executes on one of its privileged pages. Both implementations then accept writes to ports 0x21–0x26 only while Flash is unlocked. [standard]

The ROM proves that it emits the required byte sequence from page 3F. It does not by itself prove the complete privileged-page set or the response to an invalid sequence. [confirmed] for the bytes; [standard] for the differing emulator gates.

Flash instruction fetches

TilEm x4 applies the following test after it resolves a logical address to a physical Flash page $p$: [standard]

$$ \mathit{denied}_{\mathrm{TilEm}} = (\mathtt{port22} \le p \le \mathtt{port23}) $$

The boot values therefore deny pages 0x08–0x29, inclusive. Pages 0x00–0x07 and 0x2A–0x3F remain executable. Reversing the bounds makes the interval empty in this model. [standard]

Wabbitemu implements a different lower edge: [standard]

return bank->page <= flash_lower || bank->page > flash_upper;

Its forbidden interval is (port22, port23]. With the boot values, Wabbitemu allows page 0x08, while TilEm denies it. Both deny page 0x09 and page 0x29. WikiTI describes the lower bound as inclusive, which agrees with TilEm, but the physical page-0x08 result remains unmeasured. [standard] for the published contract and source comparison; [hypothesis] for hardware.

Boot execution ranges. The written bounds are [confirmed], and the emulator predicates are [standard]. The physical page-08 boundary remains [hypothesis]. The RAM panel introduces the mode-dependent chunk model detailed below.

Both emulator paths apply this rule to opcode fetches. Ordinary Flash data reads use a separate path. The locked certificate-page read censor is also a separate mechanism. [standard]

jsTIfied stores ports 0x22 and 0x23 only while its Flash gate is open and builds page-level run_lock entries. A denied fetch sets its halted/reset state to 2. Ports 0x25 and 0x26 are stored but do not participate in the fetch predicate, so jsTIfied cannot test the documented 1 KiB RAM-bound behavior. Its port-0x21 handler instead rebuilds coarser RAM-page execution groups. These are properties of the pinned JavaScript source, not ASIC evidence. [standard]

WikiTI also says page 0x00 always remains executable and that a forbidden fetch resets the calculator. Wabbitemu always permits page 0 and resets the CPU on a violation when no debugger callback is installed. TilEm’s interval test can deny page 0 when port 0x22 = 0. Its opcode-read handler raises an execution exception, and its Z80 loop performs a full calculator reset after the fetched opcode completes. These custom-bound and post-violation behaviors remain physical test cases. [standard]

Guarded TilEm boundary trace

A controlled fixture tests both sides of the boot interval rather than inferring runtime behavior from source alone. Each derived ROM changes only six erased bytes at target pp:7FF0 to this marker routine:

ld a,pp
ld (0x8478),a
ret

The 75-byte assembly program at ram:9D95 first reads those six bytes as data and compares them with its embedded signature. It then seeds 0x8478, maps the target page, and executes CALL 0x7FF0 at ram:9DBD. A mismatch returns without attempting the fetch. The fixture builder requires the exact complete ROM hash, verifies that the patched span was FF FF FF FF FF FF, and writes a new ROM copy rather than modifying tools/rom.bin.

The pinned headless TilEm run produced these control-flow sequences. Clock deltas are relative to the CALL; absolute clocks include UI launch timing. [confirmed]

TilEm records the denied target’s first opcode-fetch address before its main loop services the pending execution exception. It does not advance to the marker store at pp:7FF2; the next record is logical 0x8000, followed by the retail reset stub’s mapping writes and boot continuation. The first post-reset record is resolved with stale pre-reset mapper state because TLMT has no explicit internal-reset event, so the classifier uses the logical 0x8000 transition and the subsequent reset-stub sequence.

The machine-code and trace identities were: [confirmed]

This dynamically confirms the inclusive 08–29 interval and reset policy implemented by this TilEm build. It does not decide the physical page-08 boundary or validate Wabbitemu’s lower-exclusive model. [confirmed] for TilEm; [hypothesis] for the physical lower edge and violation response.

TilEm reset and exception scope

TilEm’s tilem_calc_reset resets the Z80, LCD controller, link port, keypad, Flash command state, MD5 accelerator, programmable timers, and model-specific hardware state in sequence. The TI-84 Plus callback then selects this starting state: [standard]

The reset retains all memory arrays, including LCD backing memory. It also retains Flash program-address, data, toggle, override-group, and emulation fields. External link-emulator state remains. The TI-84 Plus callback leaves port 0x05, ports 0x09–0x0F, the three RTC fields, and LCD_WAIT unchanged. Scheduler and debugger state also survives: the Z80 clock, access timestamps, emulation flags, dynamic timers, and breakpoints. [standard]

A guarded direct-core run seeds eight reset groups and nine retained groups. All 17 match the source model. It records PC=0x8000, SP=0xFFFF, mapper windows 00/3E/3F/3F, and a retained dynamic timer with 4,321 clocks remaining. Direct internal seeding tests TilEm implementation state, not a physical reset. [confirmed]

TilEm’s forbidden-fetch path does not suppress the opcode. The M1 read raises TILEM_EXC_FLASH_EXEC, returns the byte, and the Z80 executes the complete instruction. The main loop checks the exception afterward and calls tilem_calc_reset. The direct-core fixture maps Flash page 08 at 0x4000 and RAM page 0x40 at 0x8000. Its forbidden instruction is LD (0x8000),A with A=0x5A. The run stops on the exception after reset with PC=0x8000 and AF=SP=0xFFFF, while physical RAM byte 0x100000 contains 0x5A. [confirmed]

The boundary fixture above begins with LD A,pp; reset follows that first instruction, before its marker-store instruction. Its unchanged marker proves only that the second opcode did not execute. It does not prove that TilEm suppresses the forbidden opcode itself.

The direct-core binary SHA-256 is ab0a862b1fbb7f8a09a075fbd0ec61ebb0bab84d12d2a9c2a650813476cc7e5a. The builder requires clean TilEm commit f56ad637d0524ee841dd381be6ecbaf5b8975600 and Git tree 58316afe35d69e69353f0f743698144153051d4a.

Guarded Wabbitemu boundary run

The pinned Wabbitemu core executed the same six-byte ROM markers and 75-byte RAM probes. The native adapter first cold-boots the fixture ROM. It waits until the retail boot establishes 0x08, 0x29, 0x4000, and 0x83FF as the Flash and RAM bounds. It also requires mode 0 and relocked Flash. Every run reached this state after 134,845 instructions and 1,746,999 T-states at 3F:4223. [confirmed] for the pinned emulator run.

The adapter then maps physical RAM page 1 at 0x8000, copies the probe to ram:9D95, verifies the complete copy through the logical mapping, and sets PC=0x9D95. This is a direct emulator-core injection, not an OS variable or UI launch. An execution-violation callback counts the event and calls the same CPU_reset function used by Wabbitemu’s callback-free path. [confirmed] for the harness behavior.

The native core produced these sequences: [confirmed]

The probe seeds the marker with A0 immediately before the call. The denied pages therefore show that the marker store at pp:7FF2 did not execute. Page 08 returns while page 09 resets, dynamically distinguishing Wabbitemu’s lower-exclusive interval from TilEm’s inclusive interval. This establishes the pinned emulator’s behavior only. The physical lower edge and violation state remain unmeasured. [confirmed] for Wabbitemu; [hypothesis] for hardware.

The native binary SHA-256 is 07d56ac311cc6726d95f0e76987ce34af8814d07bcf1528f6b25375c083489f2. It was built from pinned Wabbitemu commit 48c2dc0e6d1d87bb5cf9611efbeb0d048b19c422 and source-tree SHA-256 a8a4f97fc7952770bed317b4a477f80345894da38d14fad8f0bf0ee60aae71ba. The derived fixture identities were: [confirmed]

Wabbitemu reset scope

Wabbitemu’s CPU_reset is a CPU and mapper reset, not a complete hardware reinitialization. The function writes only these groups for the TI-84 Plus model: [standard]

The function retains the other directly seeded state. This includes general and alternate CPU registers, I, R, bus state, RAM contents, the Flash command state, Flash lock and bounds, protection mode and selectors, timer frequency and T-states, delay registers, MD5 state, standard and programmable timers, RTC, keypad and ON state, raw link, link assist, USB, GPIO, and the LCD object. [standard]

The frontend calc_reset calls CPU_reset and then the LCD reset callback. The LCD callback clears display memory and its queue, disables output, zeros the coordinates and last-read latch, selects 8-bit words, and sets contrast 32. It retains the LCD access timestamp and port-0x2F delay field. No other peripheral reset follows. [standard]

A guarded initialized-core run seeds 14 component groups before calling CPU_reset. All 14 retain their seeded values. The reset mapping is 3F/00/00/00, the RAM bounds are 0x0000–0x03FF, and the frontend-equivalent call produces the LCD state above while retaining last_tstate = 654321 and lcd_delay = 61. Direct state seeding isolates field retention; it does not reproduce a physical warm or cold reset. [confirmed] for the pinned Wabbitemu run.

An execution violation calls CPU_reset inside CPU_opcode_fetch, then continues the same CPU_step. A seeded FLASH_PROGRAM violation ends the command state, fetches boot bytes 3E 07, executes LD A,0x07, and finishes at PC=0x0002 after seven T-states. A seeded FLASH_ERROR violation fetches opcode 0x3E, returns status byte 0xE0 for the immediate read, clears the error flag, executes LD A,0xE0, and also finishes at PC=0x0002. The command step remains FLASH_ERROR in the second case. This is an emulator control-flow quirk, not a physical reset model. [confirmed]

The reset-retention manifest guards OS 2.55MP ROM SHA-256 7d9a7d96d89fc552ebee6afdbdd011fdc6047be9c16d308245dff07eb1f7bd6d and native-binary SHA-256 386be74e738f2a0f9ad17f12bae4cd44994b5a73835ab10d488c7b8232afd87e.

RAM instruction fetches

TilEm x4 reduces a physical RAM byte offset $a$ to a 1 KiB chunk address. For port-0x21 mode $t = 0,1,2,3$, it computes: [standard]

$$ \begin{aligned} M_t &= (\mathtt{0x8000} \ll t) - \mathtt{0x400} \\ m &= a \mathbin{\&} M_t \\ \mathit{allowed} &= \mathtt{port25}\cdot\mathtt{0x400} \le m \le \mathtt{port26}\cdot\mathtt{0x400} \end{aligned} $$

The mask clears the low ten address bits, so the comparisons operate at 1 KiB granularity. The upper comparison is inclusive. A port-0x26 value of 0x20 therefore includes the complete 0x8000–0x83FF chunk whenever $M_t$ can produce 0x8000. [standard]

Coverage with the boot bounds

The table covers the TI-84 Plus’s eight physical RAM pages. Page notation uses the ordinary selector spelling 0x80–0x87. “Chunk 0” means the first 1 KiB at page offset 0x0000–0x03FF. [standard]

Modes 2 and 3 have the same coverage within the first 128 KiB. Their masks diverge only when an address reaches the next 128 KiB. Reversing ports 0x25 and 0x26 denies every RAM chunk in TilEm because the inclusive interval is empty. [standard]

Wabbitemu comparison

Wabbitemu’s source comments list the fully executable page pattern implied by the four modes. Its executable predicate contains this expression: [standard]

if (bank->page & (2 >> (prot_mode + 1)))
    return TRUE;

For mode 0, the shifted value is 1, so every odd RAM page returns early. For modes 1–3, the shifted value is zero. Those modes fall through to one global address comparison instead of applying a repeating mask. The default bounds produce this actual coverage: [standard]

The extra mode-0 chunk comes from Wabbitemu’s inclusive global range check, not its page shortcut. Its mode-2 and mode-3 coverage happens to match TilEm within 128 KiB under these bounds. The source arithmetic still differs for other RAM sizes and bound values. These implementation results are not ASIC evidence.

Wabbitemu stores ram_lower and ram_upper as 16-bit unsigned fields. Its port handlers multiply the 8-bit port value by 0x400 before assigning those fields. Values 0x40–0xFF therefore wrap modulo 0x10000. For example, writing 0x40 to both ports produces the implemented interval 0x0000–0x03FF, not 0x10000–0x103FF. TilEm retains the wider products. [standard] for the emulator sources; [hypothesis] for physical high-value behavior.

Guarded RAM execution runs

Two guarded runners exercise the predicates through opcode fetches. Both use a six-byte target routine that stores a case marker at 0x8478 and returns. The source program reads back all six target bytes before it seeds 0x8478 with 0xA0 and calls the target. A returned case records its case marker. A denied case retains 0xA0, omits the target store at logical target +2, and records one reset. [confirmed] for the pinned emulator runs.

The Wabbitemu adapter cold-boots the exact ROM through the retail protection sequence. It then configures the requested RAM fields and injects the guarded source at physical RAM page 1, ram:9D95, plus the target routine. This is a direct emulator-core injection. Every default-bound case reached the baseline at 3F:4223 after 134,845 instructions and 1,746,999 T-states. Returned cases executed 47 injected instructions; denied cases reset on instruction 45. [confirmed]

The TilEm runner changes only the immediate byte at 3F:41D6 when it selects a nonzero mode. Mode 1 changes that byte from 0x00 to 0x10; the derived ROM SHA-256 is 47b38fa0fd747529dea85d4fe54d24bafdadeee29c8ade82014f4452ef52699f. The OS launches a self-installing assembly program through the normal variable and UI path. The program writes the marker through data accesses before the guarded call. [confirmed]

The runtime comparison produced these boundary results: [confirmed]

The TilEm target fetch occurs seven clocks after each CALL. Allowed marker routines return 44 clocks after the call. Denied targets reset seven clocks after the attempted fetch. TilEm completes the first target opcode during that interval. Wabbitemu’s callback records the violation and invokes the same CPU_reset function as its callback-free path. Timing between the two runners is not compared because the Wabbitemu harness reports instruction counts, not a TLMT clock trace.

The other Wabbitemu cases cover all four modes under the boot bounds: [confirmed]

A separate Wabbitemu run configured both chunk ports to 0x40. The native report recorded the wrapped bounds 0x0000–0x03FF. Mode-0 page 0x80, offset 0x0000, returned; page 0x82, offset 0x0000, reset. The first result comes from the wrapped global interval. The second lies outside it and has no odd-page shortcut. [confirmed] for Wabbitemu; [hypothesis] for hardware.

The pinned identities for the cross-emulator cases were:

The TilEm assembly source SHA-256 is eafb257ff0190bfa8417269c981ab0ff94508e92a31b716c01814b0afe4bb2ca. The Wabbitemu assembly source SHA-256 is e21fe4374eec887b4877ad27ccb77dd458dcb38c24e48cb167ebb1438fc8d43c. These runs establish emulator behavior only. Physical mode repetition, high-value wrapping, chunk endpoints, and reset state remain open measurements.

Port 0x24 larger-device extension

WikiTI assigns two high Flash-bound bits to port 0x24: bit 0 extends port 0x22, and bit 1 extends port 0x23. TilEm’s color xc model uses exactly those two bits when it compares pages. Its TI-84 Plus x4 model has no port-0x24 case. [standard]

The complete OS 2.55MP ROM scan finds no direct port-0x24 instruction and no access resolved from a nearby literal load into C or BC. Computed accesses across calls or control-flow joins remain outside this static proof. [confirmed]

Port 0x24 is therefore a family extension, not part of the confirmed retail TI-84 Plus initialization path. Wabbitemu registers it on the TI-84 Plus-family device, but its two high-bit assignment expressions lack parentheses around the masked bit before shifting. Both expressions evaluate to zero for an 8-bit bus value under C operator precedence. [standard]

Native protected-register confirmation

The guarded initialized-core probe finds active, protected handlers at every port from 0x22 through 0x26. The reset core reads 0x10/0x30/0x00/0x00/0x00. These are Wabbitemu initialization values, not the retail boot values in the table above. All five writes are rejected while the in-memory Flash lock remains closed. Reads remain active. [standard]

The probe then opens the emulator’s lock directly and seeds the internal Flash bounds as 0x01A5 and 0x02B6. Writes of 0xCC and 0xDD to ports 0x22 and 0x23 produce 0x01CC and 0x02DD, confirming that both low-byte handlers preserve their seeded high bytes. Writing 0xFF to port 0x24 reads back 0xFF but changes the internal bounds to 0x00CC and 0x00DD. The native result matches Wabbitemu’s precedence defect. It does not test a physical larger-device extension. [standard]

The same run writes four edge values to both RAM-bound ports: [standard]

The manifest records the exact ROM and native-binary hashes. Opening the lock and seeding high fields are direct emulator-core operations. This mode does not execute the ROM’s protected-byte sequence or attempt an opcode fetch.

_SetFlashLowerBound

The official bcall name does not match the port written by its body. _SetFlashLowerBound = 80CF maps to 3F:4784, which writes A to port 0x23 — the upper end of the modeled forbidden interval: [confirmed]

3F:4784  nop
3F:4785  nop
3F:4786  im 1
3F:4788  di
3F:4789  out (0x23),a
3F:478B  di
3F:478C  ret

Flash must already be unlocked for either emulator to accept the write. The routine preserves A and leaves interrupts disabled. [confirmed] for the routine; [standard] for the modeled write gate.

Mapping and forced overlays

Execution protection runs after logical-to-physical page resolution. TilEm applies ports 0x27 and 0x28 first, then chooses its Flash or RAM predicate from the resulting physical page. [standard]

Wabbitemu chooses its Flash-versus-RAM branch from the underlying bank. Its RAM path also evaluates the page shortcut before replacing the global address for a forced overlay. The two emulators can therefore disagree when an overlay forces RAM over a Flash-backed window or substitutes RAM page 0 or 1. See Paging. [standard]

The guarded Wabbitemu mapper run places a NOP in forced RAM over an underlying Flash HALT. Independent mode executes the NOP; paired mode disables the overlay and executes the HALT. This confirms the fetched-byte routing through the initialized core. Both underlying Flash pages are permitted by the boot protection bounds, so the run does not distinguish which protection predicate Wabbitemu evaluated. That ordering remains established by pinned source. [standard]

The normal OS boot and homescreen traces leave both overlays disabled, so this difference does not affect those executed paths. [confirmed]

MAME 0.287 omission

MAME’s TI-84 Plus I/O map does not register ports 0x22–0x28. Its opcode fetch path reads the mapped Flash or RAM without an execution-protection predicate. Port 0x14 records an unlock value, but the paging and Flash-write paths do not consult it. [standard]

A guarded native run writes patterns to ports 0x22–0x28; all seven ports still read zero. With port 0x21 = 0x33, writes CC DD AA 10 20 to 0x22–0x26 also read back as five zero bytes while a 50-T-state loop continues executing from RAM page 0. This covers one allowed-by-absence fetch path. It does not emulate any boundary or violation response. [standard]

MAME therefore cannot test any boundary or violation described on this page. The driver is marked MACHINE_NOT_WORKING, so this omission is a driver limit, not evidence that the physical ASIC lacks execution protection. See Flash emulator comparison for the resulting Flash-command behavior. [standard]

Reproducing the models

tools/ti84re/hardware/execution_protection.py contains side-effect-free predicates and RAM coverage enumeration. The focused CLI prints both emulator results:

$ python3 -m ti84re.hardware.describe_execution_protection flash
Flash bounds 0x08-0x29
page 0x07: TilEm=allow Wabbitemu=allow
page 0x08: TilEm=deny Wabbitemu=allow

$ python3 -m ti84re.hardware.describe_execution_protection ram --compare-wabbitemu
RAM chunks 0x10-0x20
mode 0 TilEm-mask=0x7C00
  page 0x80: TilEm=- Wabbitemu=-
  page 0x81: TilEm=all Wabbitemu=all

Use --json for machine-readable output. Custom --lower, --upper, --mode, and --ram-pages values expose boundary cases without modifying an emulator.

The guarded trace runner builds all four boundary fixtures in a fresh output directory, runs them, and rejects a classification that disagrees with the TilEm predicate:

probe_parent=$(mktemp -d)
nix develop -c python3 -m ti84re.hardware.run_execution_protection_probe \
  --tilem "$TILEM" --output-dir "$probe_parent/run" --json

tools/ti84re/hardware/execution_protection_fixture.py holds the exact-ROM patching, machine-code validation, reusable assembler entry point, packaging, and trace classifier. The CLI retains each derived ROM, program pair, log, trace, and a hash-complete manifest.json in the requested directory.

The direct reset probe supplies the missing single-opcode control. Its build and run commands are under “Reset and execution exception” in the repository’s tools/notes/emulator-probes.md. The shared tools/ti84re/emulators/tilem/core.py library validates the source tree and runs the binary. tools/ti84re/emulators/tilem/reset.py parses the native report and checks the reset and retention vectors against the source model.

The Wabbitemu CLI uses the same fixture library and adds page 09 to distinguish the two lower-edge predicates:

wabbit_probe_parent=$(mktemp -d)
nix develop -c python3 -m ti84re.emulators.wabbitemu.run_execution_probe \
  --binary "$wabbit_tmp/wabbitemu-headless" \
  --output-dir "$wabbit_probe_parent/run" --json

It refuses an existing output directory. Each native report must contain the boot-register snapshot, exact injection mapping, call and target visit counts, marker value, reset count, fixture hashes, and native-binary hash.

The RAM runners accept repeatable MODE:PHYSICAL_PAGE:PAGE_OFFSET targets. Their defaults cover the cross-emulator disagreements and all Wabbitemu modes:

tilem_ram_parent=$(mktemp -d)
nix develop -c python3 -m ti84re.emulators.tilem.run_ram_execution_probe \
  --tilem "$TILEM" --output-dir "$tilem_ram_parent/run" --json

wabbit_ram_parent=$(mktemp -d)
nix develop -c python3 -m ti84re.emulators.wabbitemu.run_ram_execution_probe \
  --binary "$wabbit_tmp/wabbitemu-headless" \
  --output-dir "$wabbit_ram_parent/run" --json

The Wabbitemu CLI also accepts custom --lower-chunk and --upper-chunk values. The 0x40 wrap case is reproducible with:

wrap_parent=$(mktemp -d)
nix develop -c python3 -m ti84re.emulators.wabbitemu.run_ram_execution_probe \
  --binary "$wabbit_tmp/wabbitemu-headless" \
  --output-dir "$wrap_parent/run" \
  --lower-chunk 0x40 --upper-chunk 0x40 \
  --target 0:0:0 --target 0:2:0 --json

protected_port_parent=$(mktemp -d /tmp/ti84-protected-port.XXXXXX)
nix develop -c python3 -m ti84re.emulators.wabbitemu.run_protection_port_probe \
  --rom tools/rom.bin \
  --binary "$wabbit_tmp/wabbitemu-headless" \
  --output-dir "$protected_port_parent/run" --json

The boot bytes can be recovered independently:

$ python3 -m ti84re.rom.disassemble 0x3f --start 0x41d5 --end 0x4206
$ python3 -m ti84re.rom.analyze_io 0x21 0x22 0x23 0x24 0x25 0x26 --summary

Flash write-disable bcall [confirmed]

_FlashWriteDisable = 0x4F3C, body 3C:66D5, controls Flash programming, not the execution-protection bounds described above. After four padding NOPs, it saves AF, clears A, executes DI, selects IM 1, writes 0x00 to port 0x14, executes another DI, restores AF, and returns. The intervening OR A makes its JP NZ,ram:0000 unreachable on this path.

The body restores the caller’s AF but deliberately leaves maskable interrupts disabled. Callers that require interrupts must re-enable them after the bcall; they must not infer interrupt restoration from the saved AF. A controlled trace reaches the body once, observes OUT (0x14),A with A = 0x00, returns to the fixture, and then executes an explicit EI. The reduced result is in tools/data/community-bcall-semantics.csv. [confirmed] under TilEm; the physical Flash gate was not written on hardware in this test.

Community execution techniques

Crabcake’s original source uses two model-specific methods. On a 6 MHz TI-83 Plus it uses a Flash-unlock exploit, locates a protected OUT (0x16),A routine on Flash page 0x1F, and calls it with 0x00 or 0x07. Separate exploit code changes the port-0x05 mapping. On the TI-83+SE/TI-84+/SE family it does not rewrite ports 0x25 or 0x26. With interrupts disabled, it swaps all 0x4000 bytes between physical RAM pages 0x80 and 0x83, then maps page 0x83 into bank C. Code above 0xC000 remains at the same CPU address while residing on an executable odd physical page. The Crabcake release source contains both paths. [confirmed]

The TI-84-family cleanup restores port 0x05 to an assumed normal value, unconditionally enables interrupts, and has no error handler around the swap. These operations are explicit in the release source. [confirmed] The release does not distinguish the later 48 KiB alias model. That hardware remains unsupported without a physical probe.

zStart 1.3.013 implements its Execute >C000 option as a persistent policy. Its menu toggle first writes the assumed retail values 0x10 and 0x20 to ports 0x25 and 0x26, regardless of the new option state. If the option is enabled, later configuration and ON-script paths call unlockC000, which writes 0x00 and 0xFF after unlocking Flash writes. This is not a per-launch save/restore wrapper. The zStart release source confirms this control flow. [confirmed]

The Swords 2 source release contains FULLRENE.8xv, a 229-byte AppVar payload with the Axiom DE C0 signature. Both embedded command bodies contain this sequence: [confirmed]

    LD A,0x10
    JR NC,+1
    XOR A
    OUT (0x25),A

The incoming carry therefore selects 0x10 or 0x00 for port 0x25, and neither command body writes port 0x26. One command immediately calls _FlashWriteDisable and returns. The other restores port 0x06 from the stack before the same bcall and return. [confirmed] The artifact does not establish a hardware model matrix or behavior after an OS error. Those details remain [hypothesis].

tools/data/execution-protection-observations.csv records the emulator and physical-probe classifications in the preceding sections. It does not classify Crabcake, zStart, or Fullrene.

Resolved findings and open hardware tests

• The boot writes 00, 08, 29, 10, and 20 to ports 0x21, 0x22, 0x23, 0x25, and 0x26 through protected byte sequences. [confirmed]
• _SetFlashLowerBound writes port 0x23, despite its official name. [confirmed]
• TilEm denies the inclusive Flash interval. Four guarded TilEm traces execute pages 07 and 2A and reset on attempted fetches from pages 08 and 29. Wabbitemu allows its programmed lower page: guarded native runs execute pages 07, 08, and 2A and reset on attempted fetches from pages 09 and 29. [standard] for the source comparison; [confirmed] for the pinned emulator runs.
• TilEm applies a repeating RAM mask and inclusive 1 KiB chunk bounds. Wabbitemu’s modes 1–3 omit the intended page shortcut and its 16-bit fields wrap high chunk values. Guarded runs exercise the mode-0 extra chunk, both mode-1 repetition disagreements, the common chunk edge, all four Wabbitemu modes, and the 0x40 wrap case. [standard] for source behavior; [confirmed] for the pinned emulator runs.
• The retail ROM has no statically resolved port-0x24 access. [confirmed]
• jsTIfied implements page-level Flash and RAM execution groups, but its stored ports 0x25 and 0x26 do not affect instruction fetches. [standard]
• A guarded initialized-core Wabbitemu run verifies the common protected-write gate across ports 0x22–0x26, the port-0x24 high-field clearing defect, and 16-bit RAM-bound wrap at 0x40 and above. [standard]
• A guarded initialized-core Wabbitemu run confirms forced-RAM fetch routing in independent mode and underlying-window fetch routing in paired mode. It does not dynamically distinguish the Flash-versus-RAM protection predicate. [standard]
• Wabbitemu’s low-level reset retains most peripheral and Flash state. Its frontend adds only an LCD reset. A guarded initialized-core run verifies all 14 seeded retention groups and shows that an execution violation continues the interrupted CPU_step through one boot instruction. [standard] for the source model; [confirmed] for the pinned run.
• TilEm’s full reset reinitializes eight CPU, peripheral, and ASIC groups while retaining memory plus selected Flash, link, RTC, scheduler, and debugger fields. A forbidden opcode completes before that reset. A guarded direct-core run verifies the reset inventory and a surviving RAM-store side effect. [standard] for the source model; [confirmed] for the pinned run.

Physical tests must determine whether page 0x08 executes, what exception or reset state follows a violation, and whether lower-greater-than-upper disables each protection range. The read-only physical fetch suite prepares the retail-mode Flash edge and RAM chunk tests. Tests should also sweep all 1 KiB RAM boundaries in all four modes, repeat them with ports 0x27 and 0x28 active, and record the register state after warm and cold resets. Until then, emulator agreement is only a test oracle for emulator behavior.

Sources

The bcall mechanism

bcall is how the OS spans 1 MiB with a 64 KiB CPU: a routine on any page calls a routine on any other page 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 named 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, 645 entries resolve and are live-confirmed. Of those IDs, 623 also appear in the included SDK equates and 22 are project-inferred additions.
• Validation: known bcalls land exactly where expected — _PutS→01:5C39, _GetKey→06:491E, _ClrLCDFull→01:60E4, _GetCSC→00:04B2, _CreateReal→00:10B8.

tools/symbols/bcall_targets.txt holds 645 resolved main-table bcall rows. The retail boot table has 87 populated entries. tools/symbols/bcalls8x_targets.txt holds the 83 rows with official SDK names; four populated slots have only project-inferred names in the bcall index. tools/ti84re/rom/resolve_bcalls.py emits the official-name rows only when page 3F has the retail prefix and page 2F contains the companion USB payload; its BootFree guard otherwise leaves only diagnostic comments. tools/ghidra/ApplyBcalls.java disassembles and names the confirmed bodies. tools/ghidra/BcallEvidenceStudy.java then provides a read-only listing, reference, and decompiler dump for a selected set of IDs. For example:

nix develop -c ghidra-analyzeHeadless "$PWD" ti84 \
  -process -noanalysis -readOnly -scriptPath tools/ghidra \
  -postScript BcallEvidenceStudy.java tools/symbols/bcall_targets.txt \
  /tmp/bcall-evidence.txt 4030 4ED6 50C8

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 (645 live-confirmed bcalls: 623 IDs also present in the included SDK equates and 22 project-inferred additions).
• 0x8xxx (bit 15 set): the retail boot table is on physical page 3F, indexed by ID & 0x7FFF. Its real entries occupy IDs 0x8018–0x80D2 and 0x80E4–0x8129; bytes 3F:40D5–3F:40E3 between those ranges are executable dispatch-stub bytes, not five table entries. 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/ti84re/rom/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. Its encoding is:

CALL cross_page_jump ; = CALL ram:2B09
.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 database models it in the page-0/ROM address space; whether the table is copied to RAM at runtime remains a hypothesis. Code invokes a routine by CALL ram:3Bxx into the table. tools/symbols/bjumps.txt lists every entry’s (offset → page:addr); tools/ghidra/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, the three-line bjump encoding above appears in packed dispatch tables and inside OS routines. The target returns to the bjump caller, so cross_page_jump consumes the three inline descriptor bytes as a non-returning tail-jump. tools/ghidra/FixInlineBjumps.java runs before and after the scripts that seed parser handlers and reviewed function entries. Each pass marks every disassembled inline site, including the 87 trampoline-table entries. Raw byte matches outside disassembled code are not counted. [confirmed]

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.

Interrupts (IM1)

TI-84 Plus OS 2.55MP — Interrupt masks, status, acknowledgement, dispatch, and low-power wake.

The TI-84 Plus OS runs the Z80 in interrupt mode 1 (IM1) and polls the ASIC’s interrupt status. This page separates the USB event gate from the legacy controller at ports 0x03 and 0x04, then follows acknowledgement, priority, and HALT wake behavior.

Evidence layers

The ROM proves how OS 2.55MP uses the registers. Public notes and emulators describe behavior inside the ASIC that the ROM cannot prove by itself. Emulator agreement is supporting evidence, not physical confirmation.

IM1 entry and context

IM1 accepts a maskable interrupt at im1_vector, the fixed address ram:0038. The vector jumps to int_entry_save_alt_regs at ram:006D, which swaps AF, BC, DE, and HL with the alternate register set. The normal exit swaps them back, executes EI, and returns with RETI. [confirmed]

ram:0038  jr ram:006D
ram:006D  ex af,af'
ram:006E  exx
ram:006F  in a,(0x55)
ram:0071  xor 0xFF
ram:0073  and 0x1F
ram:0075  jr z,ram:003A

The handler uses the alternate general registers as its working context. It assumes IY = flags at 0x89F0 and uses the interrupted stack. It does not push IY, IX, or a complete register frame at entry. [confirmed]

The normal exit restores the standard OS mask after source-specific work: [confirmed]

ram:00E4  ld a,0x0B
ram:00E6  bit 0,(iy+0x16)
ram:00EA  jr z,ram:00EE
ram:00EC  add a,0x04          ; select 0x0F when timer 2 is wanted
ram:00EE  out (0x03),a
ram:00F0  ex af,af'
ram:00F1  exx
ram:00F2  ei
ram:00F3  reti

USB gate and legacy controller

Port 0x55 is the active-low USB interrupt summary. The three instructions at int_entry_save_alt_regs + 0x02 invert and mask its low five bits. A result of zero jumps directly to interrupt_legacy_status at ram:003A. A nonzero result enters the USB activity-hook and port-0x56 event paths before the handler considers the legacy controller. [confirmed]

This ordering does not make port 0x55 a summary of ON, standard-timer, or legacy link requests. Those sources appear at port 0x04. Port 0x56 is a USB line-event bitmap, not the mask for port 0x04. [confirmed] for the separate ROM paths; [standard] for the register roles.

The disconnected TilEm x4 model returns 0x1F from port 0x55 and zero from port 0x56. Its ordinary trace therefore takes int_entry_save_alt_regs + 0x02 → interrupt_legacy_status without USB event work. [standard]

See USB ASIC and link assist for the port-0x56 event-bit branches and page-35 handlers.

Port 0x03: mask, acknowledgement, and power mode

Port 0x03 controls the four legacy interrupt sources and the ASIC’s behavior when the Z80 executes HALT. Public notes document readback for enable bits 0, 1, 2, and 4. TilEm and Wabbitemu return the complete stored byte, but physical readback of bit 3 is not documented. [standard] for the public fields and emulator behavior; [hypothesis] for physical bit-3 readback.

Bit 3 changes what HALT does. A write with bit 3 clear does not enter low power by itself. The CPU must execute HALT, and an enabled wake source must later request an interrupt. [standard]

The OS uses these values: [confirmed] for each ROM write and branch; [standard] for the hardware effect.

Port 0x04 read: source and ON status

Reading port 0x04 returns status. Bit 3 is the live active-low ON level; it is not an interrupt request. Bits 5–7 report programmable-timer completion even when the corresponding timer mode did not request a maskable interrupt. [standard]

The OS reads one status byte and retains it in A while testing the source bits. Programmable timers 1 and 3 receive an extra check of bit 1 in their own mode/status ports before the OS calls their banked handlers. A finished bit can therefore be visible without being eligible for interrupt service. [confirmed]

Port 0x04 write: three unrelated controls

Writing port 0x04 does not acknowledge the status returned by a read. A write selects the memory-map mode, standard-timer rate, and battery-comparator input. [standard]

For TI-84 Plus standard timer 1, the published quartz-domain period is

$$ T_1 = \frac{64 + 80i}{32768}\text{ seconds}, $$

where $i$ is bits 2–1. Timer 2 runs at twice that frequency. OS value 0x06 selects independent mapping, rate index 3, and battery selector zero. [confirmed] for the OS value; [standard] for the field meanings and formula.

The battery-selector bits identify comparator configurations. The ROM’s write order does not prove that the raw two-bit number is a monotonic voltage level. Physical threshold and bit-order measurements remain open. [hypothesis]

See Paging for paired mapping and Clock, timers, and power for exact timer rates.

Dispatch order and simultaneous sources

The legacy-status path tests port-0x04 bits in this order: [confirmed]

ram:003A  in a,(0x04)
ram:003C  bit 7,a
ram:0041  bit 5,a
ram:0046  bit 6,a
ram:00C8  bit 2,a
ram:00CD  bit 4,a
ram:00D2  rra                 ; original bit 0 enters carry
ram:00D6  rra                 ; original bit 1 enters carry

An eligible handler exits through acknowledgement instead of resuming at the next lower-priority bit. Simultaneous eligible sources are therefore not all dispatched from one port-0x04 read. A timer-1 or timer-3 completion bit whose mode gate is clear is skipped, allowing the next candidate to be tested. [confirmed]

The common port-0x03 write of 0x08 clears all four legacy source bits at once under the public clear-on-zero contract and TilEm’s model. Simultaneous lower-priority legacy requests can therefore be coalesced by the higher-priority service. A programmable-timer completion is acknowledged separately through its mode/status port. [standard] for latch behavior; [confirmed] for the OS write sequence.

Clear-on-zero acknowledgement

The common acknowledgement helper preserves the handler-supplied byte in A, writes 0x08, then writes the saved byte: [confirmed]

ram:00DC  push af
ram:00DD  ld a,0x08
ram:00DF  out (0x03),a
ram:00E1  pop af
ram:00E2  out (0x03),a

The first write clears the ON, standard-timer, and link source latches because their enable bits are all zero. Bit 3 remains one, so this acknowledgement does not request low power. The second write exposes the handler-supplied value only until the normal exit writes 0x0B or 0x0F. [confirmed] for values and ordering; [standard] for clear-on-zero semantics.

Leaving a legacy pending bit uncleared causes another maskable request after EI. Rewriting the same all-enabled mask is not an acknowledgement because each set bit leaves its source enabled and pending. [standard]

Programmable timers use a separate contract. Writing their mode/status ports 0x31, 0x34, or 0x37 clears finished/overflow state and removes that timer’s request in TilEm and the public hardware description. Port 0x03 does not clear bits 5–7. [standard]

Standard and programmable timer distinction

The standard timers belong to the legacy mask block. Port-0x03 bits 1 and 2 enable their interrupt requests, and clearing those bits acknowledges them. Their rate comes from port-0x04 bits 2–1. [standard]

The three programmable timers have source, mode/status, and counter triplets at ports 0x30–0x38. Their port-0x04 bits are completion observations, not enable bits. Timer mode bit 1 selects whether completion requests a maskable interrupt. [standard]

OS 2.55MP uses programmable timer 1 for its timer bcall state machine and programmable timer 3 for a USB timeout path. standard_timer1_irq drives keypad scanning, cursor blink, the run indicator, and Auto Power Down (APD). [confirmed]

See Clock, timers, and power for programmable-timer modes, the bcall ABI, and kernel-tick consumers.

ON request versus ON level

Port-0x04 bit 0 is the ON interrupt latch. Bit 3 is the button’s current active-low level. The dispatcher selects the ON handler from bit 0, while on_key_debounce_power at ram:0964 repeatedly samples bit 3 to classify a stable press or release. [confirmed]

The power-cycle trace reads 0x01 after the injected ON press. Bit 0 reports the request and bit 3 clear reports the held key. The two meanings coincide in this event but remain independent fields. [confirmed]

TilEm requests an ON interrupt on both press and release transitions when enabled. Wabbitemu latches only a transition into its pressed state. The ROM handles either stable level, but it cannot determine the physical ASIC’s edge policy. [standard] for emulator behavior; [hypothesis] for the unmeasured physical policy.

See Keypad and ON-key hardware for debounce timing and the OS ON state machine.

Link interrupt versus periodic link polling

Port-0x03 bit 4 controls the legacy link-activity interrupt. The shutdown mask 0x11 uses it as a wake source. The port-0x04 bit-4 dispatcher branch enters legacy_link_irq, the power-restoration path. [confirmed] for OS use; [standard] for the interrupt source.

Normal operation uses mask 0x0B, so legacy link interrupts are disabled. Standard timer 1 still performs a periodic silent-link check at ram:01B1: the raw path reads port 0x00, and the assist path reads port 0x09. This polling is separate from a direct port-0x04 bit-4 request. [confirmed]

See Two-wire link port hardware for both detection paths.

Low-power entry and wake

poweroff_shared_tail at ram:0A24 first acknowledges legacy sources with 0x08. It then writes 0x06 to port 0x04, writes 0x11 to port 0x03, enables interrupts, and reaches poweroff_halt_loop at ram:0A5C. [confirmed]

ram:0A4B  out (0x04),a        ; A = 0x06
ram:0A4F  out (0x03),a        ; A = 0x11
ram:0A5B  ei
ram:0A5C  halt
ram:0A5D  jr ram:0A5C

Mask 0x11 disables both standard timers, enables ON and link activity, and clears the powered-HALT bit. The next HALT enters the ASIC low-power mode under the public contract. [confirmed] for the sequence; [standard] for the physical effect.

A resolved TilEm trace records the transition and ON wake: [confirmed]

clk=98010423   ram:0A29 OUT (0x03) <- 0x08
clk=99871166   ram:0A4B OUT (0x04) <- 0x06
clk=99871186   ram:0A4F OUT (0x03) <- 0x11
clk=99871258   ram:0A5C HALT
clk=99915117   ON pressed
clk=99915172   ram:006F IN  (0x55) -> 0x1F
clk=99915213   ram:003A IN  (0x04) -> 0x01
clk=99915377   ram:0964 ON wake/debounce path
clk=100195536  ram:09B5 power-on restoration

TilEm prevents programmable timers from waking HALT when both standard-timer bits in port 0x03 are clear. A programmable timer can still interrupt a running CPU in that state. This is an emulator policy approximating public reports that programmable timers do not reliably wake a halted CPU; it does not identify the physical ASIC mechanism. [standard]

MAME ON-wake trace

MAME 0.287 includes the ti84pv3 machine and accepts a 1 MiB OS 2.55MP image. The repository ROM has SHA-1 ffddb460d7d4e79cc8fbd288d6895fd113d7f3bf, while MAME’s reference image has SHA-1 d500540feca974f6e8fa269981cfb25dc951c338. MAME warns about this difference because the repository image contains locally assembled boot pages. [confirmed]

The Lua tap records the program counter after each I/O instruction. MAME reaches the shutdown mask, accepts an injected ON press, and enters the ROM debounce path: [confirmed]

MAME_IO frame=20 pc_after=0DF3 OUT (0x03) <- 0x08
MAME_IO frame=20 pc_after=0DF6 OUT (0x03) <- 0x00
MAME_IO frame=20 pc_after=0C97 OUT (0x03) <- 0x11
MAME_KEY frame=30 ON press
MAME_IO frame=31 pc_after=0071 IN (0x55) -> 0x1F
MAME_IO frame=31 pc_after=003C IN (0x04) -> 0x01
MAME_IO frame=31 pc_after=0977 IN (0x04) -> 0x01

The trace confirms ROM control flow under MAME. It does not confirm MAME’s register semantics. The driver itself marks every monochrome TI-84 Plus configuration MACHINE_NOT_WORKING. [standard]

Custom handler rules

A custom IM2 handler, or code that replaces OS interrupt service, must account for each controller independently: [standard]

• Preserve every register and mapping state that interrupted code can observe. The OS shadow-register convention is safe only while the interrupted program leaves those alternate registers to the OS.
• Read port 0x55 as an active-low USB gate and port 0x04 as legacy/completion status. Do not interpret port-0x04 bit 3 as a pending source.
• Acknowledge legacy sources by clearing their port-0x03 bits, then restore the intended mask. Acknowledge programmable timers through their own mode/status ports.
• Keep handler code and any data it requires in mapped memory. Banked calls must preserve the interrupted mapping or restore it before returning.
• Service or deliberately disable USB events. A port-0x03 acknowledgement does not clear port-0x55/0x56 state.
• Enable a source capable of waking the chosen power mode before executing HALT.

Chaining to the OS handler also inherits its assumptions: IY points to flags, normal RAM and page mappings are active, and the alternate general registers are available. [confirmed]

Emulator comparison

Wabbitemu’s source comments state uncertainty about its standard-interrupt write behavior. Its model is useful as an independent implementation comparison, but disagreement must remain explicit. [standard]

Native TilEm interrupt edges

A guarded direct-core run compiles the complete TilEm tree at commit f56ad637d0524ee841dd381be6ecbaf5b8975600. It calls the registered x4 port handlers and timer callbacks, plus the public keypad, link, timer, and reset functions. It does not execute the ROM. [standard]

Port 0x03 stores all eight written bits. Writes 00, 01, 02, 04, 08, 10, and FF produce identical readback. The same writes select internal ON, power-on-HALT, and link enables from bits 0, 3, and 4. Either standard-timer bit clears TilEm’s NO_HALT_INT flag on all three programmable timers; both bits clear set that flag. All three timer flags agree in every case. [standard]

The probe seeds all four legacy latches, all three programmable completion flags, and all three programmable CPU requests. Applying the seven values above through port 0x03 produces status E8 E9 EA EC E8 F8 FF. Applying them through port 0x02 produces the same sequence. Both paths leave the three programmable requests at internal mask 0x38, and port 0x03 leaves completion bits 5–7 visible. This directly checks TilEm’s two clear-on-zero implementations. [standard]

The ON sequence produces 00 00 09 08 01 00 09 08 00: masked press, enable while held, release, acknowledge released, press, acknowledge held, release, disable, and press while disabled. TilEm therefore latches both enabled transitions. Timer callbacks with both masks clear remain at 08. With both enabled, timer 1, either timer-2 callback, and both sources produce 0A, 0C, 0C, and 0E. [standard]

Reset schedules timer 1, timer 2A, and timer 2B at initial delays 1,600, 1,300, and 1,000 µs with 9,277 µs periods. Port-0x04 writes select periods 1953, 4395, 6836, and 9277 µs for all three without changing the current interval. An enabled external link-line transition sets status 18; either acknowledgement path clears it to 08, and a disabled transition does not latch. [standard]

With the CPU halted and both standard timers disabled, programmable-timer-1 expiry leaves completion status 0x28 but no CPU request. Enabling either standard timer clears the gate and produces internal request 0x08; a running CPU also receives the request when both standard timers are disabled. This is TilEm’s policy, not a physical wake measurement. [standard]

TilEm reset writes stored port 0x03 = 0x0B directly after the generic keypad reset clears the internal ON enable. A fresh core therefore reads 0x0B while the internal ON enable is zero. Reset also retains poweronhalt; after the probe first clears it, reset again reads 0x0B while the retained power field is zero. Writing 0x0B through the port handler synchronizes both fields to one. This inconsistency affects experiments that begin at initialized-core reset without executing the ROM’s first mask write. [standard]

A separate guarded link matrix checks the interrupt-facing parts of the same implementation while exercising complete raw and assist transactions. An enabled external peer-line transition asserts the raw link-activity request. Assist idle-ready reports 0x22, receive-ready reports 0x31, and both assert the CPU interrupt. Reading receive data changes status to 0x20. Illegal both-low input reports 0x64; its first status read clears the CPU request while retaining error status 0x60. These are direct TilEm handler results, not physical interrupt-edge or acknowledgement measurements. [standard]

Two isolated executions produce identical canonical native JSON with SHA-256 1c1209e9c3f625b07c42288c21e9a5dbadddb38f12aee995c1fbc8daf1f8e8ad. The binary SHA-256 is 23037df0fee48b3ec15656aae80b6181d97211e8eec325c2be81eef02b1ff840. [standard]

Native Wabbitemu interrupt edges

A guarded initialized-core run checks the source model through the registered port handlers. Port 0x03 resets to 0x00 and stores all eight bits of 0xFF. Writing 0xFE clears a seeded ON latch while preserving 0xFE as the mask readback. [standard]

Wabbitemu selects standard-timer-1 rates of 512, 227, 158, and 108 Hz. The native periods round to 1,953,125, 4,405,286, 6,329,114, and 9,259,259 ns. Timer 2 at index 3 has a 4,629,630 ns period and starts 2,314,815 ns after timer 1. These are emulator intervals, not host-clock measurements or the documented physical formula. [standard]

The expiry comparison is strict. At exactly one 108 Hz timer-1 period, port 0x04 reads released-ON status 0x08 and the CPU interrupt line remains clear. At the next representable emulator time, status is 0x0A and the line asserts. The sequence 0x0A → 0x08 → 0x0A then reads 0x08: disabling the overdue timer runs the handler’s catch-up loop before re-enabling it. A port-0x02 zero write produces the same idle result through Wabbitemu’s second acknowledgement path. [standard]

With all three programmable underflow flags seeded, port 0x04 reads 0xE8. With the CPU halted, port-0x03 bit 3 clear changes Wabbitemu’s LCD activity field from on to off; setting bit 3 restores it. This is its visual low-power approximation, not evidence that a physical ASIC powers down the controller. [standard]

Native Wabbitemu USB interrupt edges

A separate initialized-core run checks Wabbitemu’s USB gate. With both USB request fields clear, port 0x55 reads 0x1F. Directly selecting line, protocol, or both requests produces 0x1B, 0x0F, and 0x0B. These values confirm active-low bits 2 and 4 in this emulator. [standard]

Writing zero to port 0x57 does not mask a line event. A subsequent write of 0x08 to port 0x4A raises the CPU interrupt, changes port 0x56 from 0x50 to 0x58, and changes port 0x55 from 0x1F to 0x1B. Repeating the same write after clearing only the CPU interrupt raises it again. The run invokes Wabbitemu’s handlers directly; it does not execute the ROM dispatcher or establish physical interrupt acknowledgement behavior. [standard]

MAME 0.287 provides a third comparison with larger known gaps: [standard]

Native MAME interrupt edges

The guarded MAME run parks the Z80 in a DI loop on page-0 RAM and disables the programmable timers. At reset, ports 0x03 and 0x04 both read released ON status 0x08. Writes 00, 01, 02, 04, 08, 10, and FF to port 0x03 leave both reads at 0x08; the driver does not return the written mask. [standard]

Writing 0x07 to port 0x02 directly creates status 0x0F. Subsequent port-0x03 writes 0x01, 0x06, 0xFF, and 0x00 retain ON only, retain both standard timers, retain all three fields, and clear all three fields. Port 0x04 consequently reads 09, 0E, 0F, and 08. Port 0x02 still reads ASIC status 0xC3; its write and read handlers have unrelated meanings. [standard]

The live-input sequence begins with ON masked. A press, enabling ON while the button remains held, release, enabled press, enabled release, and bit-0-clear acknowledgement produce 00, 00, 08, 01, 09, and 08. The adapter waits through both the video input update and a 256 Hz timer-1 sample after each forced transition. This confirms MAME’s press-only latch and release rearming without executing the ROM handler. [standard]

One 20 ms frame with only timer 1, only timer 2, or both enabled produces status 0x0A, 0x0C, or 0x0E. Timer-1 status reaches 0x0A after both port-0x04 configuration writes 0x00 and 0x06. These frame-level results show that both callbacks run and that neither configuration suppresses timer 1; the pinned source, rather than this coarse interval, establishes the exact fixed 256 Hz and 512 Hz rates. [standard]

A scheduled soft reset retains seeded status 0x0F through the reset callback. After a port-0x02 zero write clears pending state, the retained standard-timer masks regenerate 0x0E; a new ON press changes the status to 0x07. MAME’s reset hook restores the mapper but does not restore these interrupt fields. This is emulator reset behavior, not physical warm-reset evidence. Two isolated runs produce identical canonical parsed native JSON with SHA-256 bb4b38d444692b5136d96264fa3acf9fe95ef2f6a1879ab72e9a2ad8077c1def. [standard]

Reusable debugging tools

tools/ti84re/hardware/interrupt_controller.py provides typed decoders, exact timer periods, clear-on-zero acknowledgement, ROM status-test order, USB active-low decoding, and immutable TilEm and MAME legacy-interrupt state models. tools/ti84re/hardware/describe_interrupt_controller.py exposes focused CLI commands: [confirmed] for the ROM/public decoders; [standard] for the emulator model.

nix develop -c python3 -m ti84re.hardware.describe_interrupt_controller mask 0x0B
nix develop -c python3 -m ti84re.hardware.describe_interrupt_controller status 0x8B
nix develop -c python3 -m ti84re.hardware.describe_interrupt_controller config 0x06
nix develop -c python3 -m ti84re.hardware.describe_interrupt_controller ack 0xF7 0x08

The trace command resolves mapper state, restricts output to interrupt ports, annotates each value, and collapses consecutive identical polls: [confirmed]

nix develop -c python3 -m ti84re.hardware.describe_interrupt_controller trace \
  /tmp/tilem-power-cycle.trace --clock 97000000-101000000

Use --all to retain repeated ON-level polling and --json for machine-readable output.

tools/ti84re/emulators/wabbitemu/interrupt_probe.py adds the pinned Wabbitemu timer-rate and edge oracle. Run its exact-ROM, hash-recording CLI with:

wabbit_interrupt_parent=$(mktemp -d /tmp/ti84-wabbit-interrupt.XXXXXX)
python3 -m ti84re.emulators.wabbitemu.run_interrupt_edge_probe \
  --rom tools/rom.bin \
  --binary "$wabbit_tmp/wabbitemu-headless" \
  --output-dir "$wabbit_interrupt_parent/run" --json

The ROM is only a core-initialization fixture in this mode. No TI-OS instruction executes.

tools/ti84re/emulators/tilem/interrupt.py supplies the typed direct-core report and checks it against the reusable TilEm state model. The guarded builder requires the exact clean source commit and tree. The runner requires the binary SHA-256 and refuses to reuse an output directory. The “Legacy interrupt matrix” section in tools/notes/emulator-probes.md contains the reproduction commands.

tools/ti84re/emulators/tilem/link.py checks the raw-activity and assist-interrupt transitions against the shared link model in tools/ti84re/link/port.py. Its guarded builder and runner use the same clean-source and binary-hash requirements. The “Raw link and assist matrix” section in tools/notes/emulator-probes.md contains the command.

tools/ti84re/emulators/mame/interrupt.py parses the complete MAME report and checks it against the reusable state model. Its guarded CLI records the exact MAME, ROM, Lua, logs, and evidence scope:

mame_interrupt_parent=$(mktemp -d /tmp/ti84-mame-interrupt.XXXXXX)
nix shell nixpkgs#mame --command python3 -m ti84re.emulators.mame.run_interrupt_probe \
  --expected-mame-sha256 \
    fc5f4aba1aa6eb115d66decad13bb3f5313b9f3be9cff7c785d8d88e3fca0b91 \
  --output-dir "$mame_interrupt_parent/run" --json

tools/ti84re/emulators/mame/trace.py, tools/ti84re/emulators/mame/run_io_trace.py, and tools/probes/mame/mame_io_trace.lua provide the equivalent headless MAME path. The Lua tap accepts comma-separated ports and ranges, collapses identical polls, records post-I/O PCs, and can inject ON at selected video frames: [confirmed]

nix shell nixpkgs#mame -c python3 -m ti84re.emulators.mame.run_io_trace \
  --seconds 2 --ports 03-04,55-56 \
  --on-press-frame 30 --on-release-frame 34

MAME prints a checksum warning for the locally assembled ROM and identifies the expected and actual hashes. Keep that warning with captured evidence.

Resolved findings and open hardware tests

• [confirmed] OS 2.55MP tests USB activity before reading legacy status, but ports 0x55/0x56 remain separate from ports 0x03/0x04.
• [confirmed] The port-0x04 test order is programmable timer 3, timer 1, timer 2, standard timer 2, link, ON, then standard timer 1.
• [confirmed] The OS acknowledgement sequence is 0x08 → handler-supplied byte → 0x0B or 0x0F.
• [confirmed] Shutdown writes 0x11 and executes HALT; the trace wakes through port-0x04 value 0x01 after an ON press.
• [standard] Programmable completion bits remain observable independently of their interrupt-mode bits.
• [standard] The guarded TilEm run verifies stored mask readback, both clear-on-zero paths, ON press and release latches, both timer-2 callbacks, link transitions, programmable-timer HALT gating, and the reset readback/internal-policy mismatch.
• [standard] The guarded TilEm link run independently verifies raw activity, assist idle and receive requests, data acknowledgement, and interrupt-only acknowledgement of a retained error flag.
• [standard] The guarded Wabbitemu run verifies complete mask readback, ON clearing, strict standard-timer expiry, both standard-timer acknowledgement paths, programmable completion readback, and its LCD-based low-power approximation.
• [standard] The guarded Wabbitemu USB run verifies its active-low line/protocol summary, mask-independent line event, and repeat-event path. It does not verify the ROM dispatcher or physical USB interrupt behavior.
• [standard] The guarded MAME run verifies shared status reads, three-bit mask behavior, direct port-0x02 status injection, press-only ON sampling, both standard-timer pending bits within scheduled frames, and interrupt-field retention across soft reset.
• [hypothesis] Physical TA2 and TA3 tests should measure ON request edges, link wake transitions, simultaneous legacy-source coalescing, programmable-timer wake behavior, and battery-selector thresholds.

Sources

Clock, timers, and power

TI-84 Plus OS 2.55MP — Clock domains, timer APIs, APD, RTC, and low-power control.

The TI-84 Plus derives OS timekeeping from a 32.768 kHz crystal while the Z80 runs at a separately selectable CPU rate. This page separates the standard interrupt timers, three programmable timers, and real-time clock; reconstructs the undocumented timer bcall state machine; and follows both explicit and automatic shutdown into the ASIC’s low-power state.

Evidence layers

The subsystem crosses ROM code, public hardware observations, and emulator policy. A claim marked [confirmed] comes from the local OS 2.55MP image or a complete instruction trace. A claim marked [standard] comes from the named hardware or emulator source and agrees with the ROM where their scopes overlap. Emulator behavior is identified by implementation and revision rather than treated as physical-ASIC proof.

Hardware blocks and clock domains

The TA2/TA3 ASIC integrates the Z80-compatible core, RAM interface, USB, and supporting logic. WikiTI’s hardware history places the variable CPU clock, 32.768 kHz quartz oscillator, programmable timers, and MD5 assist in the advanced gate array introduced with the TI-83 Plus Silver Edition. The TI-84 Plus adds a real-time clock driven from that low-frequency domain. Datamath identifies the local calculator family as using TI REF 83PLUSB/TA2 or 84PLUSB/TA3 ASIC revisions. [standard]

The MD5 accelerator and boot API page checks the MD5 port block and boot routines independently.

flowchart LR
    CPU["CPU clock<br/>port 20 · 6 or 15 MHz"] --> Z80["Z80 core"]
    CPU --> PTCPU["programmable timers<br/>CPU-clock modes"]
    XTAL["32.768 kHz quartz"] --> ST["standard timers 1 and 2"]
    XTAL --> PTX["programmable timers<br/>crystal modes"]
    XTAL --> RTC["32-bit RTC seconds counter"]
    ST --> ISR["im1_vector · ram:0038"]
    PTCPU --> ISR
    PTX --> ISR
    ISR --> APD["keypad · cursor · APD"]

The three timing blocks have different contracts: [standard]

CPU speed

Port 0x20 selects CPU speed. Value 0 selects the nominal 6 MHz mode; values 1–3 select the nominal 15 MHz mode on the TI-84 Plus. TilEm models these as exactly 6 MHz and 15 MHz. Physical measurements published by WikiTI vary by ASIC revision and unit, so cycle-count conversion should name whether it uses nominal or measured frequency. [standard]

Pinned Wabbitemu starts at exactly 6 MHz. Its default TI-84 Plus context maps port-0x20 values 0–3 to 6, 15, 15, and 15 MHz. An internal timer_version = 1 setting maps them to 6, 15, 20, and 25 MHz. A guarded initialized-core run verifies both matrices. The internal setting is front-end configuration, not a calculator port or evidence of additional physical TI-84 Plus clock modes. [standard]

The low two speed bits also select one of ports 0x29–0x2C for LCD and memory wait states, plus a field in port 0x2F. See Bus timing and wait states. [standard]

The standard timers and RTC remain tied to the quartz domain when the CPU speed changes. Programmable timers can instead select the CPU clock, so their wall time then changes with port 0x20. [standard]

Interrupt-source routing

TI-OS uses IM1. im1_vector at ram:0038 jumps to int_entry_save_alt_regs at ram:006D. That entry swaps in the alternate general registers, polls the active-low USB summary at port 0x55, and falls through to the separate legacy status port 0x04 when the USB block reports no source. [confirmed]

Reading port 0x04 reports legacy pending state, live ON level, and programmable-timer completion: [standard]

The two status handlers visible in this dispatch are unrelated to the kernel’s APD tick: [confirmed]

• 33:5EB4 continues the OS timer API’s programmable-timer-1 countdown.
• 35:4792 stops programmable timer 3 and services a USB timeout/event structure through ports 0x8E, 0x91, and 0x92.
• standard_timer1_irq handles the tick that reaches keypad scanning, cursor blink, the run indicator, and APD.

The status-test order is programmable timer 3, timer 1, timer 2, standard timer 2, link, ON, then standard timer 1. Programmable completion bits remain visible when their timer mode does not request an interrupt, so timers 1 and 3 receive an additional mode-bit check before their handlers run. [confirmed] for the test order and mode checks; [standard] for completion visibility.

The kernel normally writes 0x0B to port 0x03: ON and standard timer 1 can interrupt, timer 2 and link cannot, and bit 3 keeps the ASIC powered during HALT. The acknowledge sequence at ram:00DC writes 0x08, which clears all legacy source bits under the clear-on-zero contract, and then writes a handler-supplied byte. See Interrupts (IM1) for the complete register tables and simultaneous-source behavior. [confirmed] for the writes; [standard] for latch semantics.

Standard hardware timers

Writing port 0x04 selects both memory-map mode and the standard-timer rate. Bits 1–2 form an index $i$ from 0 through 3. On the TI-84 Plus, standard timer 1 has period [standard]

$$ T_1 = \frac{64 + 80i}{32768}\text{ seconds} $$

and timer 2 runs at twice its frequency. [standard]

TI-OS writes 0x06 to port 0x04 at several setup sites, including ram:09B7. Bit 0 is clear, selecting memory-map mode 0, and bits 1–2 select the slowest standard-timer rate. The kernel tick period is therefore exactly $304/32768$ seconds under the documented quartz model. [confirmed] for the write; [standard] for the physical rate.

Wabbitemu instead stores a rounded rate table of 512, 227, 158, and 108 Hz. Its index-2 value differs from the documented 146.285714 Hz, while the other three approximate their corresponding public rates. A guarded initialized-core run records the resulting internal periods and checks the expiry boundary through the registered port handler. These values describe Wabbitemu only. [standard]

Dynamic cadence

A resolved TilEm trace enters standard_timer1_irq at steady intervals of 139,153–139,157 emulated CPU cycles after the OS reaches its 15 MHz state. TilEm schedules this timer at 9,277 µs, so its nominal interval is 139,155 cycles. Instruction-boundary acceptance accounts for the small spread. [confirmed]

The hardware formula gives 9,277.34375 µs, or 139,160.15625 nominal 15 MHz cycles. TilEm rounds each rate to whole microseconds with the table {1953, 4395, 6836, 9277}. The five-cycle difference at the slow setting is emulator quantization, not evidence that the quartz formula differs. [standard]

A guarded direct-core probe confirms the table through port-0x04 writes. Each selection applies the same period to timer 1 and both timer-2 callbacks. The initial intervals remain 1,600, 1,300, and 1,000 µs across those writes, matching TilEm’s tilem_z80_set_timer_period contract. Direct callbacks with port-0x03 mask 0x06 produce status 0x0A for timer 1 and 0x0C for either timer-2 callback. These are scheduler observations from pinned TilEm, not physical phase or frequency measurements. [standard]

Kernel-tick consumers

standard_timer1_irq at ram:0167 performs the periodic kernel work below before returning through the common interrupt acknowledge path. [confirmed]

The keypad mechanism is covered in Keypad and ON-key hardware. These consumers advance from standard timer 1, not from a programmable timer. [confirmed]

Auto Power Down timing

_ApdSetup = 4C93 has body ram:03AE. It reloads only the high byte: [confirmed]

ram:03AE  ld hl,0x8449       ; apdTimer
ram:03B1  ld (hl),0x74
ram:03B3  ret

When apdAble and apdRunning are set, ram:036C decrements the low byte first and the high byte only when the low byte reaches zero: [confirmed]

ram:036C  ld hl,0x8448       ; apdSubTimer
ram:036F  dec (hl)
ram:0370  ret nz
ram:0371  inc hl             ; apdTimer
ram:0372  dec (hl)
ram:0373  ret nz

Because _ApdSetup leaves apdSubTimer unchanged, the timeout depends on its phase. If $d$ is the number of ticks until the low byte next reaches zero, with $1 \le d \le 256$, expiry takes [confirmed]

$$ N = d + 115 \times 256 $$

standard timer-1 ticks. The exact range is: [confirmed] for the counter arithmetic; [standard] for conversion through the documented timer rate.

The low byte’s free-running phase explains the roughly 2.37-second spread after a reload. The high-byte constant alone therefore does not encode one exact number of minutes. [confirmed]

On expiry, ram:0374 performs display/context cleanup, clears apdRunning, sets apdWarmStart, and jumps to poweroff_shared_tail at ram:0A24. [confirmed]

Cursor blink cadence

_CursorOn and _CursorOff reload curTime with 0x32 (50). cursor_blink_tick decrements it, toggles curOn on expiry, and reloads the same value. [confirmed]

At the OS standard-timer setting, one visible-state interval is [confirmed] for the tick count; [standard] for wall time.

$$ 50 \times \frac{304}{32768} = 0.4638671875\text{ seconds} $$

A complete on/off cycle is 0.927734375 seconds. The run indicator has a separate counter at 0x8476; it does not share the APD word. [confirmed]

Programmable timers

The ASIC provides three independent eight-bit countdown timers. Each uses a source/frequency register, a mode/status register, and a counter register. [standard]

Source and divisor

The high two frequency-register bits choose the clock family. The low bits encode a family-specific divisor. [standard]

Writing a nonzero counter starts it when a valid source is selected. Counter value zero represents 256 ticks, loops continuously, and does not assert the port-0x04 completion bit. [standard]

TilEm stops a timer on every source-register write and retains the current counter as the next loop value. This is emulator behavior in tilem_user_timer_set_frequency, not evidence that every physical ASIC revision retains the counter the same way. [standard]

TilEm rounds crystal-family durations to whole microseconds before scheduling. For a freshly loaded counter value of one, sources 0x40–0x47 schedule at 92, 1007, 10010, 100006, 31, 488, 7813, and 125000 µs. The counter read rescales that rounded remainder against a separately rounded 256-count duration. It consequently reads 1 0 1 0 1 0 1 1 immediately after those eight starts. This readback pattern is a TilEm quantization effect, not a physical counter claim. [standard]

Mode, completion, and acknowledgement

Writing the mode/status port acknowledges completion, clears overflow, and removes the timer’s interrupt request. The corresponding port-0x04 bit records completion even when mode bit 1 did not request an interrupt. If looping remains active without a new mode write before the next expiry, the counter continues through a 256-count overflow cycle and sets status bit 2. [standard]

TilEm also assigns a recurring 256-tick period when software restarts an already completed non-looping timer without first writing its mode port. The completion bit remains set, the low mode read remains zero, and the next callback sets overflow bit 2. OS 2.55MP acknowledges before programming its next chunk, so the timer bcall path does not use this emulator edge. [standard]

Bad Apple audio timer case

The third-party Bad Apple application sets CPU-speed port 0x20 to 1, then writes source 0x82, mode 0x03, and counter 120 to timer 1. Its interrupt routine acknowledges by rewriting 0x03 to port 0x31 and emits one link-port sample through port 0x00. [confirmed] for the application source.

Source 0x82 is the CPU-clock family divided by 4. At the nominal 15 MHz TI-84 Plus speed, the programmed cadence is therefore

$$ \frac{15{,}000{,}000}{4 \times 120} = 31{,}250\ \mathrm{Hz}. $$

The program’s companion encoder instead uses 33,333.3 Hz when converting notes to oscillator counts. That value is an encoder tuning assumption rather than a decode of the active timer registers. The program advances its tracker after $24 \times 75 = 1{,}800$ interrupts, so both note pitch and tracker tempo depend on the actual timer cadence. Published CPU-frequency variation and unresolved physical timer edges prevent the nominal calculation from serving as a physical measurement. [confirmed] for the constants and control flow; [standard] for the timer decode; [hypothesis] for physical cadence.

Cadence evidence. The top lane combines [confirmed] application bytes with the [standard] timer decode. The encoder and trace lanes preserve their source contexts; neither measures physical calculator cadence.

Port 0x2D controls low-power behavior. Bit 0 keeps the quartz oscillator active on the TI-83 Plus Silver Edition; the TI-84 Plus RTC already requires it. Bit 1 allows the programmable timers to continue counting in low power. TI writes 0x03. Public hardware tests report that these timers still do not reliably interrupt a halted CPU, so software should keep a standard timer enabled when it must escape HALT. [standard]

Prepared physical discriminator

The guarded HWTMR probe tests the four source-model disagreements without using HALT. It compares source 0x41 with the common source-0x45 reference, measures source 0xE0 across CPU-speed requests 0–3, starts a source-0x45 timer with counter zero, and captures status after two unacknowledged expiries. It snapshots ports 0x02, 0x03, 0x04, 0x15, 0x20, 0x2D, 0x2F, and 0x30–0x35. It runs only when timers 1 and 2 are idle and their completion bits are clear. Every polling loop is bounded. [confirmed] for the assembled source and host decoder.

The exact image completes through its cleanup boundary in pinned Wabbitemu and selects that implementation’s divisor-32, omitted-port-0x2F, counter-zero completion, and first-expiry-bit-2 behaviors. This validates the program and decoder against a known model. No exported HWTMR001 result from a calculator has been recorded, so the physical divisor, prescaler, zero-counter, and expiry-status edges remain [hypothesis].

Undocumented timer bcall API

OS 2.55MP exposes one software timer backed by programmable timer 1. ti83plus.inc supplies official equate names, but the WikiTI pages for IDs 526C–5281 are absent. The ABI below is reconstructed from 33:5E1E–33:5F69. [confirmed]

Entry points

All operations except _InitTimer validate A=0x70. An invalid or uninitialized ID returns carry set and A=2. _InitTimer returns carry set and A=1 when already initialized. _StartTimer returns carry set and A=3 when already running. [confirmed]

State block

_InitTimer sets only initialized. _KillTimer writes zero to ports 0x30 and 0x31, then clears all seven bytes. _StopTimer stops those ports and clears running, but preserves finished, auto-restart, the saved duration, and the expiry count. [confirmed]

Duration encoding and hardware programming

_StartTimer selects source 0x41, whose tick period is $33/32768$ seconds, and mode 0x02, which requests an interrupt without hardware looping. timer_program_next_chunk at 33:5EF3 programs counter 0x32 in chunks. [confirmed]

For input DE, the high byte D counts full chunks of 255 and the low byte E supplies the final chunk. The total hardware count is therefore [confirmed]

$$ N = 255D + E $$

rather than the ordinary 16-bit value $256D+E$. Each tick is about 1.007080078125 ms under the crystal specification. For example, DE=0x0100 programs 255 ticks, and DE=0x0101 programs 256. This radix-255 chunking is an ABI quirk, not a generic property of the hardware counter. [confirmed]

After each hardware expiry, timer_irq acknowledges mode port 0x31, programs the next chunk, and returns while chunks remain. At the logical expiry it increments the word at 0x9C11, saturating at 0xFFFF, clears running, and sets finished. With auto-restart selected, it restores the original duration, sets running again, and programs the first new chunk. [confirmed]

A zero duration has no hardware chunk. _StartTimer marks the timer finished immediately and increments the expiry count once. [confirmed]

Check and wait quirks

_CheckTimer preserves the BIT 2 result while loading HL: Z means unfinished and NZ means finished. It always returns A=0 and carry clear on a valid timer. The count can exceed one when auto-restart runs faster than the caller checks it. [confirmed]

_CheckTimerRestart disables interrupts, captures the old count, clears finished and the count, then executes EI unconditionally. It does not preserve a caller’s disabled-interrupt state. Its final success path also makes Z set, so use the returned count rather than _CheckTimer’s finished-flag convention. [confirmed]

_WaitTimer sets C=0, calls _StartTimer, and spins on state bit 2. It does not execute HALT. Because timer_irq advances multi-chunk and completed timers, ordinary waits require interrupts to remain enabled. [confirmed]

Real-time clock

The RTC is a 32-bit count of seconds since midnight on 1 January 1997. The set and current registers are little-endian by port number. [standard]

To set the clock, software writes all four staged bytes, writes 0x01 to port 0x40 so command bit 1 is low, then writes 0x03 to create its rising edge while leaving the clock enabled. [standard]

Raw OS access

rtc_read_seconds at 37:58A1 reads current ports in the order 0x48, 0x47, 0x46, 0x45 into 0x8499–0x849C. The following conversion loop turns that 32-bit integer into the OS floating-point/date representation. [confirmed]

rtc_write_seconds at 37:593F writes the four converted bytes in the reverse port order 0x44, 0x43, 0x42, 0x41, then emits the 0x01 → 0x03 control sequence. [confirmed]

The exact-ROM disassembly shows both block-I/O loops:

; 37:58A1 — bytes 21 99 84 06 04 0E 49 0D ED A2 20 FB
ld hl,0x8499
ld b,4
ld c,0x49
.read_byte:
dec c
ini
jr nz,.read_byte

; 37:593C — bytes 21 99 84 06 04 0E 45 0D ED A3 20 FB
ld hl,0x8499
ld b,4
ld c,0x45
.write_byte:
dec c
outi
jr nz,.write_byte

INI increments HL and decrements B, so the first loop pairs ascending RAM addresses with descending current-time ports. OUTI applies the same register updates to the staged set ports. [confirmed]

tools/ti84re/rom/describe_io_coverage.py reproduces this result from the pinned ROM. Its raw scan covers all 37 possible register and block-I/O opcode pairs in the image, including pairs inside operands and data. It also verifies that no 16 KiB page ends with an ED prefix. Only 37:58A9 and 37:5944 survive as aligned instructions with a statically resolved port. Regression tests pin their ports to 0x48 and 0x44. This is ROM evidence; the separate TilEm RTC probes below test emulator behavior. [confirmed]

The hardware documentation does not describe a snapshot/latch operation for current-time reads. The OS reads high byte first, which reduces but does not eliminate the possibility of a rollover between the four port reads. No retry or two-pass coherence check appears at 37:58A1. [confirmed] for the OS sequence; [hypothesis] for physical rollover behavior.

TilEm reads host time_t separately on every current-register access. A probe-controlled rollover from 0x00FFFFFF to 0x01000000 between the port-0x48 read and the remaining bytes assembles 0x00000000. This proves that pinned TilEm has no multi-byte RTC latch. It does not resolve whether the physical ASIC snapshots the current count. [standard]

Date and time bcalls

WikiTI documents _getDate as returning day, month, and year through OP1 and floating-point stack slots. _getTime returns seconds, minutes, and hours, with hours always in 24-hour form. _GetTimeString applies the user’s 12/24-hour setting and writes a null-terminated string such as 1:41AM or 15:56. [standard]

Power-off and wake flow

_PowerOff = 5008 resolves to ram:09E6. It performs context and display cleanup before joining poweroff_shared_tail at ram:0A24. APD performs its own cleanup at ram:0374 and joins the same tail. [confirmed]

flowchart TD
    EX["_PowerOff · ram:09E6"] --> CLEAN["put-away and display cleanup"]
    APD["APD expiry · ram:0374"] --> APDF["clear apdRunning<br/>set apdWarmStart"]
    CLEAN --> JOIN["poweroff_shared_tail · ram:0A24"]
    APDF --> JOIN
    JOIN --> P4["port 04 = 06"]
    P4 --> P3["port 03 = 11"]
    P3 --> H["poweroff_halt_loop · ram:0A5C"]
    H --> WAKE["ON/link interrupt and wake path"]

The final writes are: [confirmed]

The low-power request is port-0x03 bit 3 clear combined with Z80 HALT; writing 0x11 by itself does not finish the transition. ON and link activity remain enabled as wake sources. The wake interrupt follows im1_vector → int_entry_save_alt_regs → on_irq → on_key_debounce_power. After debouncing the active-low ON level, the power-on branch at ram:09AC restores the CPU-speed setting and writes 0x06 to port 0x04 at ram:09B7. It does not return to the suspended _PowerOff caller. [confirmed]

Dynamic power-cycle trace

tools/macros/power-cycle.macro cold-boots the OS, presses [2nd]+ON, waits in low power, then presses ON. The resolved trace enters _PowerOff once, reaches poweroff_shared_tail, executes both port writes, and repeats HALT in poweroff_halt_loop until the wake event. It then records the wake route through on_key_debounce_power, ram:09AC, and ram:09B5. [confirmed]

TILEM=~/Git/tilem-headless/result/bin/tilem2

$TILEM --headless --rom tools/rom.bin --model ti84p --normal-speed --reset \
  --macro tools/macros/power-cycle.macro \
  --trace /tmp/tilem-power-cycle.trace --trace-range all \
  --trace-limit 500000000

nix develop -c python3 -m ti84re.trace.resolve \
  /tmp/tilem-power-cycle.trace --initial-mapping ti84p-reset \
  --names tools/symbols/names.txt --only-space ram \
  --only-addr 09e6-0a5d --print 180

Emulator comparison

The comparison below reproduces pinned source behavior. Agreement between implementations is useful corroboration of a software contract, but it is not a substitute for a physical TA2 or TA3 measurement. [standard]

TilEm timer and RTC policy

TilEm reproduces the paths used by this OS, but several model choices matter for timing experiments. [standard]

Port-0x03 bits 1 and 2 jointly control TilEm’s programmable-timer NO_HALT_INT flag. With both bits clear, a halted CPU receives no programmable request even though port-0x04 exposes completion. Either bit set removes the gate for all three timers. A running CPU receives the request in either state. The guarded interrupt probe exercises all three cases through the direct timer callback. [standard]

• Standard-timer periods are rounded to whole microseconds: {1953, 4395, 6836, 9277}.
• Crystal-family programmable timers use the documented divisor table. CPU-family duration is measured in Z80 clocks and follows the speed selected at port 0x20.
• The 0xC0 family uses the ordinary CPU-family decode, so port 0x2F does not prescale it.
• Port 0x2D stores its low two bits but does not pause the oscillator or programmable timers in low power.
• An internal NO_HALT_INT flag suppresses programmable-timer interrupts during HALT when neither standard timer is enabled at port 0x03.
• The RTC uses host time_t plus an offset. Disabling it freezes the stored count rather than making current ports read zero.

A full TilEm reset disables all three programmable timers and clears their frequency, reload, and status fields. It reschedules the standard timers but retains the global Z80 clock and dynamically allocated scheduler timers. The TI-84 Plus callback also leaves CLOCK_MODE, CLOCK_INPUT, and CLOCK_DIFF unchanged. A guarded direct-core run verifies each boundary. These are emulator lifecycle rules, not physical RTC or reset behavior. [standard]

TilEm tracks completion internally for port 0x04 while exposing loop, interrupt enable, and overflow through the low three mode/status bits. The first nonzero-counter expiry sets completion; a second expiry without a mode write sets visible overflow bit 2. [standard]

Native TilEm confirmation. The guarded direct-core matrix verifies all eight rounded crystal durations and all seven CPU divisors. Sources 0x00, 0x01, and 0x3F leave the scheduler stopped while preserving a written counter. Source 0xC0 schedules one CPU clock with port 0x2F set to 0x00, 0x4A, or 0xFF. [standard]

Counter zero schedules a recurring 256-tick callback without completion. One non-looping expiry produces internal status 0x100, port-0x04 = 0x28, and no request. A second unacknowledged expiry changes the visible mode/status read to 0x04. Interrupt mode produces internal request 0x08; completing timers 1–3 cumulatively produces port-0x04 values 0x28, 0x68, and 0xE8, with internal request masks 0x08, 0x18, and 0x38. A mode write clears completion and the matching request. A source write after four of ten CPU ticks — advanced directly in the probe’s scheduler clock — retains counter six and stops the timer. [standard]

The RTC case substitutes a deterministic time_t source inside the probe process. Committing 0x12345678, advancing ten seconds, disabling for ninety, and re-enabling for five produces 0x12345678, 0x12345682, 0x12345682, and 0x12345687. A disabled commit of 0xDEADBEEF survives full TilEm reset with control mode 0x02. Two isolated executions produce identical canonical native JSON with SHA-256 0da06edc402dfb14945d28577f212face4c04c22b3b6ffc3e283a70e0ecb4aa5. The binary SHA-256 is fa665079fac1ace807930be8a3836385f6821ee9994c6454039b8ca85bb75d77. [standard]

Wabbitemu timer and RTC policy

Wabbitemu stops a programmable timer and clears its pending interrupt generation on a source write. It decodes the crystal-family divisors as 3, 32, 327, 3276, 1, 16, 256, and 4096; the three near-decimal divisors therefore differ from both the published table and TilEm. Its 0x80 and 0xC0 families both use the divided-CPU decode and ignore port 0x2F. [standard]

Wabbitemu’s low-level CPU_reset and frontend calc_reset do not reset the timer context, delay registers, standard interrupt controller, programmable timers, or RTC. A guarded initialized-core run retains seeded T-states 123456, frequency 25 MHz, timer version 1, and byte-complete state for those peripherals. Direct seeding verifies emulator field retention only. It does not establish warm-reset, cold-reset, or power-loss behavior on an ASIC. [standard] for source; [confirmed] for the pinned run.

Wabbitemu registers ports 0x29–0x2F through one delay-latch handler. Port 0x2D consequently stores all eight bits and only recomputes the memory-wait booleans from the active speed register and port 0x2E. A native write to 0x2D leaves the programmable-timer state, clock frequency, LCD-active state, HALT, interrupt line, and T-state count unchanged. This differs from the public low-power contract and cannot establish physical port-0x2D behavior. [standard]

The crystal handler computes elapsed 32.768 kHz ticks but uses a single if, so one invocation decrements each crystal timer at most once even if multiple source periods elapsed. The CPU path uses while and catches up all elapsed divisors. On the first expiry, Wabbitemu reloads the original counter, stops if loop bit 0 is clear, sets the underflow flag exposed as mode/status bit 2 and port-0x04 completion, and retains interrupt generation when mode bit 1 is set. It does not assert that interrupt while the emulated CPU is in HALT. [standard]

Wabbitemu implements ports 0x40–0x48 from emulated elapsed seconds rather than host wall time. A bit-1 rising edge copies the staged value into the base. Bit-0 transitions start or stop elapsed-time accumulation, and disabled reads return the frozen base. Each staged-byte write also resets the stored elapsed-time reference; the OS set sequence commits immediately afterward, so this does not disturb the traced ROM path. [standard]

Native Wabbitemu confirmation. The guarded initialized-core probe loads counter 3 with crystal source 0x41, advances the emulated crystal by 320 ticks, and reads the counter three times without advancing time again. The reads are 0x02, 0x01, and 0x03: each device evaluation consumes one pending divisor, and the third reloads the original count. Mode/status reads 0x04, and port 0x04 reads 0x28. [standard]

The corresponding CPU-source case loads counter 3 with source 0x80 and advances four T-states. One counter read catches up three divisors, reloads 0x03, and produces the same 0x04 mode/status and 0x28 port status. Loading counter zero and advancing 257 T-states reaches underflow after 256 decrements. It reads back zero with status 0x04 and port 0x04 = 0x28. A mode write acknowledges that state, returning mode/status to 0x00 and port 0x04 to 0x08. [standard]

With mode 0x02, source 0x80, and counter 1, expiry during HALT leaves the CPU interrupt line clear while mode/status reads 0x06. Evaluating the timer after leaving HALT asserts the retained interrupt request. The RTC case commits 0x12345678, advances emulated time by 10.75 seconds, and reads 0x12345682. Disabling the RTC freezes that value through an advance to 100 seconds. These tests inject emulator clock values directly; they do not measure wall-clock accuracy, callback cadence under CPU execution, or physical low-power behavior. [standard]

Assembled-probe confirmation. The exact 835-byte HWTMR image also runs after a retail OS 2.55MP boot. The guarded runner stops at 01:9EE4 before _CreateAppVar, after 1,645,212 probe instructions and 12,937,610 modeled T-states, with no execution-violation reset. Four samples infer source-0x41 divisor 3568/111, about 32.144. Speed requests 0–3 read back as 0, 1, 1, and 1, and the nonzero cases infer prescalers near one. Counter zero produces mode/status 0x04 and port 0x04 = 0x68; both expiry samples expose bit 2. All saved timer, speed, port-0x2F, power-control, and interrupt-mask fields compare equal after cleanup. [confirmed] for the pinned Wabbitemu run.

The shared injected-program adapter has SHA-256 3acb6a18280f9c42d6fe324188eab73f87280ee70b973e1251fcfa50f54fb14e. The machine-code SHA-256 is 6767caf1d714bc15e642de2f791151a060015fa0d9faebe1ebddd92d184df68a. This execution does not create the result AppVar or measure physical timing.

MAME timer and RTC policy

MAME maps only timer ports 0x30–0x38 from this block. Ports 0x2D–0x2F and RTC ports 0x40–0x48 are unmapped. For every nonzero source value, a counter write selects one of the eight Wabbitemu-style crystal divisors from the low three bits and schedules at 32768/divisor Hz. CPU-source family bits do not select the CPU clock. [standard]

The initial callback is scheduled at zero delay, so a nonzero counter value $N$ reaches its first modeled expiry after $N-1$ periodic intervals; a value of one can expire immediately. Counter zero remains zero because the callback decrements only a nonzero count. At expiry, loop bit 0 reloads the counter once, but the callback then applies loop &= 2 and discards that bit. Mode bit 1 has inverted polarity: an interrupt and port-0x04 completion are produced only when it is clear. A mode write also clears all three programmable completion bits globally rather than only the selected timer. [standard]

The TI-84 Plus driver is marked MACHINE_NOT_WORKING. Its standard timers remain fixed at 256 Hz and 512 Hz, and port-0x04 writes do not retime them. It can still run the repository ROM’s page-0 ON-wake path, as shown in Interrupts (IM1), but that execution does not validate the timer model. [standard]

Native MAME confirmation. The guarded CPU-I/O-space probe parks the Z80 in a DI loop on isolated RAM. Source bytes 0x01, 0x41, and 0x81 each reduce counter 0xFF to 0xEA over 20 ms of emulated time. The 21 decrements comprise one zero-delay callback and 20 periods at 1,024 Hz. This confirms that the documented off, crystal, and CPU families all use low-three-bit divisor 32. [standard]

Counter zero remains zero with source 0x07 after 15 frames. The source readback remains 0x07, and port 0x04 remains 0x08. Source zero disables a running timer while preserving count 0x05. A mode write retains only bits 0–1. Mode bit 1 set produces no completion; the same count with bit 1 clear sets timer-3 completion and changes port 0x04 from 0x08 to 0x88. [standard]

Loop mode reloads count one, clears bit 0, and schedules another zero-delay callback. The second callback stops the timer, leaving count, source, and mode at zero with completion set. Simultaneous timer-1 and timer-2 completion produces port 0x04 = 0x68; writing timer 1’s mode clears both bits and returns 0x08. Ports 0x2D–0x2F and 0x40–0x48 return zero before and after patterned writes. Two isolated runs produce byte-identical reports with SHA-256 5aab56b737495fef9c953522e1a3eee47d3e96637bc8266ce6258ff10d3e2c26. [standard]

A separate guarded legacy-interrupt run enables standard timer 1, standard timer 2, and both for one 20 ms frame. Port 0x04 reads 0x0A, 0x0C, and 0x0E. Timer 1 produces 0x0A after both configuration writes 0x00 and 0x06, consistent with the source’s fixed callbacks. A soft reset retains both masks: clearing their pending fields after reset allows both to regenerate status 0x0E during the next frame. These are MAME scheduler and reset results, not physical timer periods or retention. [standard]

Reusable timer tools

tools/ti84re/hardware/timer.py exposes exact rational source rates, first-expiry timing, callback outcomes, the ROM’s radix-255 chunks, RTC implementation profiles, and the physical-probe discriminator. tools/ti84re/hardware/describe_timer.py is a JSON-capable front end. The TilEm, Wabbitemu, and MAME report oracles validate native observations against reusable source models; tools/ti84re/emulators/jstified.py supplies a separately hash-guarded source profile without claiming a native run. tools/ti84re/emulators/tilem/timer.py adds the complete direct-core programmable-timer and deterministic RTC matrix. tools/ti84re/emulators/tilem/interrupt.py adds direct standard-timer scheduling and programmable-timer HALT-gate observations. tools/ti84re/emulators/mame/interrupt.py adds fixed standard-timer and reset-retention observations through the immutable MAME state in tools/ti84re/hardware/interrupt_controller.py. Their guarded CLIs retain exact binary, ROM, adapter, output, and evidence-scope identities. CPU-speed and port-0x2D implementation edges use tools/ti84re/emulators/wabbitemu/speed_probe.py and its guarded CLI. tools/ti84re/emulators/wabbitemu/run_timer_physical_probe.py executes the assembled physical discriminator through the shared injected-program runner. These are emulator-comparison tools, not physical-hardware simulators.

nix develop -c python3 -m ti84re.hardware.describe_timer \
  source 0x41 0x80 0xC0 --mode3-prescaler 4

nix develop -c python3 -m ti84re.hardware.describe_timer \
  duration --source 0x41 --counter 0xFF

nix develop -c python3 -m ti84re.hardware.describe_timer \
  expiry --mode 0x02 --halted --no-standard-timer

nix develop -c python3 -m ti84re.hardware.describe_timer chunks 0x0100 0x0101
nix develop -c python3 -m ti84re.hardware.describe_timer --json rtc

timer_probe_parent=$(mktemp -d /tmp/ti84-timer-probe.XXXXXX)
nix develop -c python3 -m ti84re.emulators.wabbitemu.run_timer_edge_probe \
  --rom tools/rom.bin \
  --binary "$wabbit_tmp/wabbitemu-headless" \
  --output-dir "$timer_probe_parent/run" --json

physical_timer_parent=$(mktemp -d /tmp/ti84-physical-timer.XXXXXX)
nix develop -c python3 -m ti84re.emulators.wabbitemu.run_timer_physical_probe \
  --rom tools/rom.bin \
  --binary "$wabbit_tmp/wabbitemu-headless" \
  --expected-binary-sha256 \
    3acb6a18280f9c42d6fe324188eab73f87280ee70b973e1251fcfa50f54fb14e \
  --output-dir "$physical_timer_parent/run" --json

mame_timer_parent=$(mktemp -d /tmp/ti84-mame-timer.XXXXXX)
nix shell nixpkgs#mame --command python3 -m ti84re.emulators.mame.run_timer_probe \
  --expected-mame-sha256 \
    fc5f4aba1aa6eb115d66decad13bb3f5313b9f3be9cff7c785d8d88e3fca0b91 \
  --output-dir "$mame_timer_parent/run" --json

Resolved findings and open hardware questions

• [confirmed] standard_timer1_irq drives APD, keypad scanning, cursor blink, and the run indicator.
• [confirmed] 33:5EB4 is the programmable-timer API interrupt handler; 35:4792 is a USB timer-3 handler.
• [confirmed] APD expires 29,441–29,696 kernel ticks after _ApdSetup, depending on the untouched low-byte phase.
• [confirmed] The cursor toggles every 50 kernel ticks.
• [confirmed] The timer bcall API exposes only ID 0x70, uses radix-255 duration chunking, and keeps a saturating expiry count.
• [confirmed] The Bad Apple application writes timer-1 tuple 0x82/0x03/120; the documented CPU-clock decode gives 31.25 kHz at nominal 15 MHz, while its companion encoder assumes 33,333.3 Hz.
• [confirmed] Explicit power-off and APD share poweroff_shared_tail.
• [standard] TilEm matches the published 33/328/3277 crystal divisors; pinned Wabbitemu and MAME sources use 32/327/3276.
• [standard] TilEm, Wabbitemu, MAME, and jsTIfied all omit the published port-0x2F prescaler from their 0xC0-family timer models.
• [standard] A guarded TilEm run verifies its four whole-microsecond standard-timer periods, unchanged current intervals on rate writes, two timer-2 callbacks sharing one pending bit, and the three programmable-timer HALT-gate cases.
• [standard] A guarded TilEm timer/RTC run verifies every source divisor, rounded count readback, off sources, ignored port-0x2F, counter-zero behavior, overflow and acknowledgement, the unacknowledged non-loop restart, per-timer status mapping, source-write retention, RTC freeze/re-enable/reset, and an exact torn read.
• [standard] A guarded initialized-core Wabbitemu run verifies single-step crystal catch-up, full CPU catch-up, first-underflow status bit 2, counter-zero completion, acknowledgement, HALT-line suppression with retained generation, and frozen disabled RTC reads.
• [confirmed] The exact assembled HWTMR image reproduces Wabbitemu’s divisor-32, omitted-prescaler, counter-zero-completion, and first-expiry-bit-2 model through its cleanup boundary. No physical result has been recorded.
• [standard] A guarded MAME run verifies fixed-crystal source-family collapse, its zero-delay first callback, idle counter zero, inverted mode-bit polarity, one-reload loop behavior, global completion clearing, source-off preservation, and unmapped auxiliary and RTC blocks.
• [standard] A separate guarded MAME run verifies both standard-timer pending bits, timer-1 status within one frame after port-0x04 writes 0x00 and 0x06, and retained legacy masks across soft reset.
• [standard] Wabbitemu’s low-level and frontend reset paths retain the timer context, delay registers, interrupt controller, programmable timers, and RTC. A guarded run confirms the directly seeded state. Physical reset retention remains open.
• [standard] TilEm’s full reset clears programmable timers and reschedules standard timers while retaining the global clock, RTC fields, and dynamic scheduler timers. A guarded direct-core run confirms the seeded boundaries. Physical reset retention remains open.
• [confirmed] The prepared memory-bus timing probe uses timer 2 only when its source and mode are zero, records completion state for every sample, and restores the idle counter byte. No physical result has been recorded.
• [hypothesis] Physical RTC reads can tear across a one-second rollover because no latch or OS retry is documented.
• [hypothesis] The physical crystal divisors, port-0x2F prescaler, first-versus-second-expiry meaning of mode/status bit 2, counter-zero edge, and precise reason programmable timers fail to wake HALT need direct TA2/TA3 measurements.
• [hypothesis] Low-power behavior of port 0x2D, disabled RTC reads, control-edge behavior, and rollover coherence should be checked on TA2 and TA3 hardware rather than inferred from emulators.

Sources