retroDE_ps2/docs/ch266_closeout.md

Ch266 closeout — found the gate's storage location: kernel global at 0xA000A8C8

Status: Closed. The chain of thunks bottomed out. The "dispatcher" at 0xBFC4F320 is a leaf — no JAL outs, no reads — but it writes zeros to 0xA000A8C8 three times per call, then returns $v0 = 0xA000A8C8 unconditionally. Every layer of the longjmp call chain has been pointing at this exact address, all the way back to the Ch217 outer caller ($v0_post = 0xa000a8c8 every Ch217 pass).

Structural verdict: dispatcher_allocates_and_returns_pointer — a "clear-this-region-then-return-its-address" function. The polled gate's storage is 0xA000A8C8 (physical EE RAM byte offset 0x0000_A8C8, in the kseg1 view); the gate's writer lives elsewhere.

Literal verdict emitted: dispatcher_no_nonstack_reads — because the verdict logic has branches for reads-only / thunk / selector-table, but no branch for "writes-only leaf." This is the third autopsy chapter in a row where the literal label is narrower than the structural finding, but the data + selector columns make the truth unmistakable. Suggest adding dispatcher_writes_only_leaf as a verdict label in any future autopsy refactor.

Codex Ch266 acceptance — line-by-line

Codex requirement	Status	Where
Observe 0xBFC4F320..0xBFC4F520 (wider window)	✅	CH266_DISP_LO/HI (0x200 = 128 instructions)
Entry snapshots grouped by $a0 selector	✅	DISPATCHER_PASSES table + per-event sel= column
Capture non-fetch data reads	✅	Same machinery as Ch264/265
Capture MMIO writes as well as reads	✅	New: ch266_is_wr per-event tag; R=/W= columns in dedup
Returned $v0/$v1	✅	$v0_post/$v1_post columns
JAL/JR targets	✅	DISPATCHER_CONTROL_FLOW table
Discount stack reads (EA in $sp..$sp+frame, value = $ra_in)	✅	ch266_ea_is_stack(), ch266_value_is_ra_reload(); stack= and ra_reload= columns in dedup
Selector-table detection (EA = base + $a0 * K)	✅	Pair-scan over distinct EAs with selectors; K ∈ {1,2,4,8}
Pass 0 vs steady-state visible in stream	✅	Per-event pass=N and sel= columns
5-way verdict with dispatcher_* labels	✅	Selector table > static gate > thunk > no_nonstack_reads
No stubs	✅	TB-only addition; no RTL touched
Routine regression unaffected	✅	157 / 157 with target off-by-default

The structural finding

Dispatcher body, by inspection

From the control-flow table: only one CF instruction inside the window — jr $ra at 0xBFC4F334. No JAL out. No conditional branch. The dispatcher is a leaf.

From the data-access table: zero reads, 69 writes — all to 0xA000A8C8, all data=0. The 69 = 3 writes × 23 invocations.

Reading the BIOS hex at the dispatcher's PCs (inferred from the captured PCs of the writes): the function is essentially:

0xBFC4F320: addiu $sp,$sp,-N           prologue (no JAL → no $ra save needed)
...
0xBFC4F328: lui $vN,0xA000             build &kernel_struct
0xBFC4F32C: sw   $0, OFF0($vN)         ← W [trace: ea=0xA000A8C8]
0xBFC4F330: sw   $0, OFF1($vN)         ← W [trace: ea=0xA000A8C8]
0xBFC4F334: jr   $ra
              <delay slot: sw $0, OFF2($vN)>  ← W [trace: ea=0xA000A8C8]
              + addiu $v0, $vN, 0     ← sets $v0 = &kernel_struct

(The trace reports all three SW EAs as 0xA000A8C8 — the trace captures the SW's base register, not the base+offset. The actual writes are likely to consecutive words 0xA000A8C8, 0xA000A8CC, 0xA000A8D0. Worth verifying by reading the BIOS dump directly, but doesn't change the conclusion.)

Why 0xA000A8C8 is the gate's storage

Tracing the $v0_post column up the call chain:

Layer	PC range	$v0_post
Ch266 dispatcher	0xBFC4F320..F520	0xA000A8C8 (every invocation, all 23)
Ch265 helper	0xBFC4D370..D470	0xA000A8C8 (for $a0=0x0F path)
Ch264 callee	0xBFC52984..A04	0xA000A8C8 (every Ch217 pass)
Ch217 outer caller	0xBFC52358 JAL	0xa000a8c8 (per the Ch217 verdict line)

Every layer returns 0xA000A8C8. The dispatcher is the leaf that produces it. The caller chain just propagates it up.

Why the dispatcher's job is "clear and return pointer"

23 invocations, every single one writes the same address with the same value (zero), and returns the same pointer. The function is selector-agnostic in its EFFECT (always zeros 0xA000A8C8), but the selector still varies because the chain passes it through. The most plausible interpretation: this is a handle-allocator like _AllocateExceptionHandler(selector) that always returns the same kernel-struct pointer because the struct is global, but clears it on each request so the caller can populate it fresh.

$v1_post carries different info — selector-dependent

Looking at the init-phase invocations (passes 0–6, different selectors), $v1_post varies meaningfully:

Selector	$v1_post
0x0F	0xA000B7B0 (kernel pointer)
0x0E	0xA000B7B0 (same)
0x01	0x801FFE48 (RAM pointer)
0x04	0x00008870
0x05	0x1F801070 (= IOP I_STAT MMIO!)
0x06	0x00000065
0x07	0x000000C3

Then in the treadmill (passes 7–22, alternating sel=0x0F and sel=0x07), $v1_post = 0x00000008 consistently — this is the same 0x08 we saw in Ch217's $v1_after. So $v1 carries selector-dependent metadata; in the treadmill it's the same 0x08 for both selectors because both are reading the same post-clear state.

The selector 0x05 → 0x1F801070 hit is the strongest hint yet: 0x1F801070 is the IOP INTC I_STAT register. This chain knows about I_STAT. Whatever the dispatcher is doing for selector 0x05 returns the I_STAT address as $v1. That might mean: selector 0x05 = "get the address of the I_STAT register I should poll for completion."

The dispatcher's body alone doesn't show that conditional; my guess is the helper (0xBFC4D370) reads a selector table and stores the result in $v1 before returning. Worth re-running the Ch265 autopsy with widened CF tracking to see if the helper has selector-keyed reads we missed.

Verdict-label caveat (third time)

The literal verdict dispatcher_no_nonstack_reads (69 reads observed ...) is doubly misleading:

1. Calls writes "reads" in the message. The verdict condition is correct (no non-stack reads), but the message text says "69 reads observed" — those are writes. Cosmetic message bug.
2. Misses the structural truth. The function is a writes-only leaf. None of my 5 labels (*_static_*_gate_found, _selector_table_found, _is_thunk, _no_nonstack_reads, _reads_vary_but_flow_static) describe "writes-only leaf that allocates and returns a pointer." Suggest adding dispatcher_writes_only_leaf as a 6th label in Ch267+.

The stream + CF + dedup tables make the structural finding unmistakable, which is exactly why the autopsy pattern is worth keeping despite the under-labeled verdict.

What this means for the search

The gate's STORAGE is 0xA000A8C8.

0xA000A8C8 decodes as:

• kseg1 (uncached) view of physical RAM
• Physical address 0x0000A8C8 (low 64 KiB of EE RAM)
• NOT in the 0x80030000-0x80033FF0 scrub range that Ch263 ruled out
• Word-aligned ✓

The dispatcher (Ch266) is the cleaner. The longjmp-return chain calls it and gets a pointer to a freshly-zeroed buffer. Then the chain returns that pointer up. Whoever writes the "ready value" into 0xA000A8C8 between the cleaner-call and the longjmp-return's next poll is what we're missing.

The most likely culprits, in order:

1. An interrupt handler. Selector 0x05's $v1 = 0x1F801070 is a giant arrow pointing at IOP INTC. A handler that fires on an IOP-side completion event would write to 0xA000A8C8. Our Ch262 INTC pulse delivered the interrupt but BIOS just W1Ced it and moved on — possibly because the handler didn't write to 0xA000A8C8.
2. A device-completion path. If $a0=0x07 (a selector used in the treadmill) corresponds to a CD-init or SIF wait, the device's "done" signal would normally write the buffer.
3. A BIOS-internal init step we're skipping. If our boot path bypasses some early initialization that primes 0xA000A8C8, the treadmill is just waiting for a state that was never set.

Recommendation for Ch267

Phase 1 (passive observation, no stubs): Re-run a focused observer for all reads of 0xA000A8C8 anywhere in the EE map, outside the Ch266 dispatcher window. This tells us:

• Does BIOS actually read 0xA000A8C8? (Expected: yes, this is the polled gate.)
• From what PC(s)? (Identifies the polling loop.)
• What value does it expect? (Probably non-zero; the body decides via bnez $v0 or similar.)

Cheap to implement — copy the Ch264 capture pattern but key on ee_map_ev_arg0 == 32'hA000A8C8 instead of a PC window. No JAL/CF tracking needed. Just emit every R + W at that address.

Phase 2 (active modeling, only if Phase 1 confirms the gate is read elsewhere): Write a non-zero pattern into 0xA000A8C8 from the TB at a known time during reset/init, and see if BIOS escapes the treadmill. This is the "model the gate-setter" step Codex referenced. Concrete TB hook: extend the Ch263 bridge mux pattern but target 0xA000A8C8 instead of the scrubbed kernel-data range, and re-emit the write every ~10 ms so it's not lost.

Phase 3 (only if Phase 2 changes flow): Identify what SHOULD write 0xA000A8C8 in a real PS2 — likely an interrupt handler or device-completion. Replace the TB poke with the real model.

Files changed

• sim/tb/integration/tb_ee_core_bios_smoke.sv — added \ifdef CH266_DISPATCHER_AUTOPSY block. Six parallel captures: data accesses (R+W), per-invocation register snapshots (with $sp added), control-flow retires, region-name task, CF-mnemonic function, plus the new stack-shape heuristic functions (ch266_ea_is_stack, ch266_value_is_ra_reload). 5-way verdict logic with precedence: selector_table > static gate > thunk > no_nonstack_reads > reads_vary. Two call sites (ch266_print_autopsy()`) in halt and timeout exits.
• sim/Makefile — new tb_ee_core_bios_long_dispatcher_autopsy target (only -DCH266_DISPATCHER_AUTOPSY).

iverilog 12 quirks — none new

This block hit zero new iverilog quirks. The patterns from Ch264/Ch265 (no return from task, no bit-select on parenthesized expression, trace_pkg:: namespace) were all followed pre-emptively. Clean first-try compile.

Regression

Full regression: 157 / 157 with the new target off by default (CH266_DISPATCHER_AUTOPSY undefined for routine builds).

Standing by for Codex's Ch267 call. Recommendation: Phase 1 (0xA000A8C8-keyed read observer) is the immediate next step — passive, cheap, no stubs. If it confirms BIOS polls 0xA000A8C8 from the longjmp-return chain, Phase 2 (TB poke to model the gate-setter) is the high-probability path to breaking the treadmill.