cc72f8b5a8
because the test probed the wrong state Nine stores to the phase field this+132, control-gated on the 136 query returning at least the 18 known ones. Attributed to the handler each lives in, they give the phase graph: entry -> 2, then 2 -> 0 (splash), 2 -> 3, 3 -> 4, and 4 -> 2 on event 0. That last edge is the problem with what I did last iteration. The event-0 block sets TWO fields one instruction apart -- stw r28,136(r30) for state 0 and stw r11,132(r30) with r11 = 2 for phase 2. So B from the menu lands in PHASE 2, the same phase as the boot title, and the test I ran believing it probed phase 4 state 0 probed nothing of the kind. So the refutation is withdrawn. Worse for me and better for the idea: A working on the B-returned title is exactly what the hypothesis predicts, since phase 2 is the phase that references BUTTON. The hypothesis is back to untested, now consistent with two observations rather than one, and what it still needs is the attract-returned title's phase -- which no test so far has read. The measurement from that iteration stands, because it does not depend on the phase: the B-returned title accepts A, so only the ATTRACT-returned title is inert. I have said so explicitly in the page rather than letting the withdrawal take the good half down with it. METHOD gets the lesson: before testing "state X behaves like this", check your route actually reaches state X. When a transition writes more than one field, read the whole block and not just the store you were looking for.