The schedule decode previously rested on structural checks alone. The engine's own
reader is now found, statically.
The phase initialiser sub_82270DF8 takes the 0x1883 record's six words as arguments
and stores the table pointer:
82270FDC add r10, r26, r21 ; code_base + entry_a
82270FEC stw r10, 240(r30) ; [phase+240]
[phase+240] has exactly two readers in the ISL region, and one -- sub_822748D0 -- is
called from sub_82263408, ScriptPhase::Update. It walks the table and confirms every
field independently of my inference: N at table+4, kind at group+20, float t at
group+12, offset at group+4, and a 24-byte stride (three 8-byte records).
kind is NOT a flag. `rlwinm r11, r11, 2, 0, 29` then `lfsx` -- it is multiplied by 4
and used to index float arrays at [phase+104] and [phase+88], so it selects WHICH
TIMER the entry is scheduled against; 0 and 5 are two of at least six. An entry fires
only when its t lies between the two readings, the classic "which events did this
frame cross" test. Which array is previous and which is current follows from the two
comparison directions and is stated as a reading of those branches, not measured.
Both arrays are fields of the phase object, so the clock is PER PHASE -- which is why
every phase's table restarts at t = 0. That was an inference from the layout in the
previous commit; it is now a read.
All five artefacts regenerate byte-identical: this changes documentation only.
Still open and said so: what the six clocks are (only indices 0 and 5 appear in the
data, and neither array was traced to a source); sub_822737C8, which actually starts
the routine, is unread; and this is still not what starts the unreachable code, since
0 of the 675 targets are unreached run-starts.
f37df54ed2