bcall index

The main table below lists the live-confirmed 0x4xxx bcall system calls. Each has an ID (the 2-byte value after rst 28h) and a body at page:addr. Use your browser’s find, or the wiki search box. See The bcall Mechanism for how dispatch works. The 0x8xxx boot bcall names at the end are official SDK equates resolved from the retail boot table on page 3F; USB boot entries point into page 2F.

Corpus coverage and map provenance

tools/ti84re/community/audit_bcalls.py scans the extracted community corpus for numeric bcall macros, raw rst 28h plus word sequences, and complete EF low high instruction bytes. The pinned snapshot contains 112 such uses of 56 IDs. Three uses encode _CursorOn, _KeyToString, and _CursorOff as raw bytes; the other 109 use macro or rst 28h forms. Exact archive and source hashes are in tools/data/community-bcall-uses.csv. [confirmed] for the checked scan output.

The scan exposed 24 aligned main-table IDs that the old generated map omitted. All 24 were already literal entries in the OS 2.55MP table on page 0x3B, and all 24 names were already present in the bundled TI include. Adding them changed the main map from 621 to 645 rows and the include-backed subset from 599 to 623; the 22 project-inferred names did not change. They are therefore new to this repository’s resolver input, not new ROM routines or newly invented names. [confirmed]

The main table above is the single address catalog. ABI and side-effect notes live with their subsystems: contexts and errors, display, floating point, keypad, tokenizer, link transfer, execution protection, resident hooks, archive/group handling, and ASIC status. Reduced trace results are kept in the tools/data/community-*.csv files. This separation matters because an aligned table entry proves only an ID-to-body mapping; neither an include name nor a community comment proves the body’s complete behavior.

Malformed active call

The scan also finds one active malformed call. graphics/cool.zip:cool.asm defines _copygbuf = 4B9Ch and emits EF 9C 4B; the packaged cool.8xp contains the same bytes. 4B9Ch is not aligned to a three-byte main-table entry. Page 0x3B supplies overlapping bytes 7A EF 5E, which requests logical address 0xEF7A instead of a valid body. The TI-83 Plus _GrBufCpy ID is 486Ah, with body 04:60A3.

A complete trace of the packaged cool.8xp enters at ram:9D95, executes the malformed call at ram:9DAF, and reaches logical 0xEF7A once. It never reaches _GrBufCpy at 04:60A3, _ExecutePrgm cleanup at 07:57D1, or E_Invalid at ram:2729; it later reaches the OS handoff vector at ram:0053. The final display is blank. This confirms a nonreturning malformed dispatch under TilEm, not the physical-calculator failure mode. The trace and artifact identities are in tools/data/community-invalid-bcall-traces.csv. [confirmed] under TilEm; physical behavior remains [hypothesis].

The Cool archive SHA-256 is 1593afbeb85b831e910793d293963a9af52377bdf8af481300b13d1fa3b346f6. Member cool.asm has SHA-256 6d05c43420f4514357803fc09221a49252d0147e172a12ebdd12b74aef001998; member cool.8xp has SHA-256 ef2304ef5a731c1e4eee9f3602c1bd7c9ddb7c85427a037fbc7cecd18af0cd1c.

Preprocessor triage excludes four target-platform artifacts from the TI-84 Plus map. Math Pack’s 4166h _cpop1op2 equate is inside the non-TI83P branch; its TI-83 Plus build obtains _CpOP1OP2 = 4111h. Eliza’s 4004h, 477Dh, and 4014h values come from source/ti83asm.INC, which only its TI83I branch includes. Lock’s 5371h _getcsc is a direct call address in the TI86 branch. None is an active TI-84 Plus bcall. [confirmed] for source preprocessor structure.

tools/data/community-symbolic-bcall-triage.csv preserves every active row and excluded platform case with archive/member hashes, line numbers, and the TI-84 Plus replacement ID where applicable.

Retail boot (0x8xxx) bcalls

The retail table has 87 populated entries across IDs 0x8018–0x80D2 and 0x80E4–0x8129. The full 2007 ti83plus.inc defines 83 of them; the four snake-case rows below are project-inferred names for otherwise unnamed slots. tools/ti84re/rom/resolve_bcalls.py emits the public-name target file only when page 3F has the retail boot prefix, not when it sees BootFree. See Retail boot page for the intervening dispatch stub and evidence behind the inferred rows. [confirmed]