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 memory for the resulting Flash-command behavior. [standard]

Reproducing the models

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

$ python tools/describe_execution_protection.py flash
Flash bounds 0x08-0x29
page 0x07: TilEm=allow Wabbitemu=allow
page 0x08: TilEm=deny Wabbitemu=allow

$ python tools/describe_execution_protection.py 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 python tools/run_execution_protection_probe.py \
  --tilem "$TILEM" --output-dir "$probe_parent/run" --json

tools/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/dynamic-tracing.md. The shared tools/tilem_core.py library validates the source tree and runs the binary. tools/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 python tools/run_wabbitemu_execution_probe.py \
  --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 python tools/run_tilem_ram_execution_probe.py \
  --tilem "$TILEM" --output-dir "$tilem_ram_parent/run" --json

wabbit_ram_parent=$(mktemp -d)
nix develop -c python tools/run_wabbitemu_ram_execution_probe.py \
  --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 python tools/run_wabbitemu_ram_execution_probe.py \
  --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 python tools/run_wabbitemu_protection_port_probe.py \
  --rom tools/rom.bin \
  --binary "$wabbit_tmp/wabbitemu-headless" \
  --output-dir "$protected_port_parent/run" --json

The boot bytes can be recovered independently:

$ python tools/disassemble_rom.py 0x3f --start 0x41d5 --end 0x4206
$ python tools/analyze_rom_io.py 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