From ad3d14ab2638a282976254d32fd9ac3991c6f74a Mon Sep 17 00:00:00 2001 From: sylph-decoder Date: Wed, 2 Sep 2026 16:35:55 +0000 Subject: [PATCH] re: a THIRD timed channel in the decoder -- my "only two" was wrong, and +0xC4/+0xC8 are timings not masks Chasing F1 I examined a counter block I had skipped. this+0x10 decrements every update and fires output bit 0x4 at zero, guarded against the HELD word by cfg +0xA0; it is re-armed from +0xC4 = 10 and +0xC8 = 8. So my statement that "the only two timed inputs in the whole decoder are LB and LT" is false, and two constants I tabulated as ring-word button masks (B|Y and Y) are counter reload values. A number that is a valid mask AND a valid duration cannot be told apart by its value, only by its use, and I classified those two by value. What it does not change: F1 is still not answered. This channel is guarded by cfg +0xA0 = ring bit 1 = B, not a direction. The D-pad and left-stick paths still carry no counter, so "a held DIRECTION has no repeat timer in C_PAD_DECODER" stands, and the human's observation that it repeats in the real game is consistent with the caveat this page already carried: the repeat is in the layer above. Explicitly NOT offering 10 and 8 as F1's two numbers. They belong to a channel on a button that is not a direction, and at 60 units/s they are 0.167 s and 0.133 s -- about 7 moves a second, which does not match "a medium pace, slow enough to see which item is selected". Reporting them as the menu repeat would be the same read-a-config-infer-a-behaviour error this correction is about. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t --- .../pad-decoder-double-tap-not-key-repeat.md | 48 +++++++++++++++++++ 1 file changed, 48 insertions(+) diff --git a/docs/re/pad-decoder-double-tap-not-key-repeat.md b/docs/re/pad-decoder-double-tap-not-key-repeat.md index 14b5f415..6130889a 100644 --- a/docs/re/pad-decoder-double-tap-not-key-repeat.md +++ b/docs/re/pad-decoder-double-tap-not-key-repeat.md @@ -102,3 +102,51 @@ It says nothing about layers above the decoder, and **nothing here has been confirmed against a running capture**: no row may be labelled *measured*. The obvious check is to hold a direction on a real menu and count cursor moves per present. + +## 🔴 Correction 2026-09-02 — there is a THIRD timed channel, and my "only two" was wrong + +I wrote above: *"the only two timed inputs in the whole decoder are LB and LT."* +**That is false.** Chasing F1 I examined a counter block I had skipped, and found a +third timer on a different shape: + +``` +8220BB50 lwz r11,16(r31) ; this+0x10, a counter +8220BB5C addic. r11,r11,-1 ; decrements EVERY update +8220BB64 bne -> skip ; only when it reaches ZERO: +8220BB6C lwz r11,160(r31) ; cfg +0xA0 +8220BB70 lwz r10,12(r10) ; ...against the HELD word +8220BBAC ori r11,r11,0x4 ; fires output bit 0x4 +``` + +and it is re-armed from two more constants I had mis-read as button masks: + +``` +8220CB50 lwz r11,196(r31) ; +0xC4 = 10 -> this+0x10 +8220CB58 lwz r11,200(r31) ; +0xC8 = 8 -> this+0x14 +``` + +⚠️ **So `+0xC4` and `+0xC8` are TIMINGS, not masks.** My constructor table read +them as ring-word button sets (`B|Y` and `Y`) because 10 and 8 are legal masks. +They are counter reload values, exactly like `+0xB4`/`+0xBC` = 10. **A number that +is a valid mask and a valid duration cannot be told apart by its value — only by +its use**, and I classified these by value. + +### What it does NOT change + +**F1 is still not answered here.** This third channel is guarded by cfg `+0xA0`, +which is ring bit 1 — **B**, not a direction. The D-pad and left-stick paths still +carry **no counter**, so the finding stands where it matters: + +> **A held DIRECTION has no repeat timer in `C_PAD_DECODER`.** + +The human watched the real game and reports that a held direction *does* repeat. +Both can be true, and the caveat this page already carried is the reason: +**the repeat is in the layer above.** That is where F1 must be answered — the +consumer of `this+0x24C`, or a capture holding a direction on a real menu. + +⚠️ **And I am not offering 10 and 8 as F1's two numbers.** They are this channel's +constants, on a button that is not a direction. At 60 units/s they would be +0.167 s and 0.133 s — about 7 moves a second, which does not match *"a medium +pace, slow enough to see which item is selected"*. Reporting them as the menu +repeat would be the same error as reading a config value and inferring a +behaviour, which is the error this correction is about.