Sylpheed/docs/re/pad-decoder-double-tap-not-key-repeat.md

✅ The decoder's timers are a double-tap detector on LB and LT — and directions have no repeat in this layer

Status: ✅ decoded from the image. Instrument: ⟨image⟩ — /image/sylpheed.pe via tools/ppc-dis, database not consulted. 2026-09-02.

Answers the first half of H1 — does a held direction repeat in the menus, and at what rate? — with a negative, and decodes what the timers are actually for.

---

What the timing constants really are

C_PAD_DECODER's constructor sub_8220B610 writes five values that look like a key-repeat pair — +0xB4 = 10, +0xB8 = 90, +0xBC = 10, +0xC0 = 90. They are two identical channels of a double-tap detector, and the update sub_8220B8C0 consumes them like this:

channel	button	short timer	long timer	output bit
A	cfg +0x74 = LT	this+0 ← +0xB4 = 10	this+4 ← +0xB8 = 90	0x20
B	cfg +0x70 = LB	this+8 ← +0xBC = 10	this+12 ← +0xC0 = 90	0x40

Buttons named in the decoder's own bit numbering (input-button-numbering-is-remapped.md), not XINPUT's.

The mechanism, in the order the code runs it

1 — both timers tick down once per update (0x8220BAE0):

if this+0 != 0:  this+0 -= 1 ;  if it lands on exactly 1000: this+0 = 0, this+4 = 0
if this+4 != 0:  this+4 -= 1

2 — a press arms the short timer (0x8220BF74): on PRESSED ∧ this+0 == 0, this+0 = 10.

3 — a release adds 1000 to it (0x8220BFC8, reading 20(r6) = RELEASED): this+0 += 1000 if it is still running, else 0. The +1000 is a flag stored inside the counter — "this press has already been released" — which is why the tick in step 1 watches for the value 1000 and clears both timers there.

4 — a second press while the flag is set arms the long timer (0x8220BF44): on this+0 > 1000 ∧ this+4 == 0 ∧ PRESSED, this+4 = 90.

5 — while the long timer runs, the output bit fires EVERY frame (0x8220C0F8):

if this+4 > 0:
    this+0 = 10 + 1000            ; re-armed and flagged
    this+0x24C |= 0x20            ; the output bit, set on every update

📌 So it is not a repeat, it is a latch. A double-tap opens a 90-update window, and for its whole duration the output bit is asserted continuously. That is the shape of a dash / barrel-roll, not a menu cursor — which fits the buttons it is wired to.

🔴 The H1 answer: no key-repeat in this layer

The directions have no timer at all. The D-pad (ring bits 12–15) and the left stick (ring bits 4–7) reach the output word through bare mask tests — the four left-stick literals at 0x8220C458, 0x8220C474, 0x8220C490, 0x8220C4AC, and DPAD DOWN through cfg +0xA4 — with no counter loaded, decremented or tested on any of those paths (data/input-decoder-output-map.txt).

On the evidence of C_PAD_DECODER, a held direction does not repeat. The only two timed inputs in the whole decoder are LB and LT, and what they do is latch, not repeat.

⚠️ Reach, and it matters here. This is one layer. The decoder hands a word to the menus; a menu could implement its own repeat on top of a held bit, and this page says nothing about that. What it does establish is that the repeat is not in the shared input decoder, so it would have to be per-screen — which also means it cannot be answered once for all screens from this function.

For the port: "one step per deflection" remains authored, and this narrows rather than settles it. The next step is the layer above — the consumer of this+0x24C — or a capture of a held direction on a real menu, counting cursor moves against presents.

Refutation attempt, recorded per the adversarial duty

Target: my own earlier note in input-pad-read-path.md that "a decoder between the raw wButtons and the menus is where a game normally puts its repeat timing, its edge detection and its button remap."

Result: two thirds SURVIVE, one third is REFUTED. The remap is there (24 bits, bijective) and the edge detection is there (+12 held, +16 pressed, +20 released). The repeat timing is not. The reasoning was "this is where it normally goes", which is a prior about how games are written, not a reading of this one — and it is exactly the kind of inference this corpus keeps having to withdraw.

Reach

⟨image⟩, so it holds for every screen — that is the point of doing it statically. 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.