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 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t

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.