fix(accuracysnes): E3.06 polls and accumulates; retract F1.10's "1-vs-3" (#310)

E3.06 read TnOUT once at the end of the interval, and TnOUT is a four-bit
read-and-clear counter, so the useful range was 8..15 with the wrap one tick
above. That is not a band that can be widened -- it is the instrument's
ceiling. It now polls timer 2 every ~32 SPC cycles (one timer-2 period), so
every read returns 0, 1 or 2 and the running sum cannot lose a tick however
long the interval gets.

It also asserts the RATIO rather than two absolute counts: |T2 - 8*T0| <= 6,
computed on the 65816. Absolute counts pin the poll loop's own cycle cost,
which differs between cores for reasons unrelated to the 64 kHz stage -- and
that is exactly what made the old row fail on ares while ares' own
Timer<128>/Timer<128>/Timer<16> declarations were a correct 8:1.

RustySNES and ares now report the identical 6 and 46. ARES_KNOWN_FAILURES
drops 5 -> 4. A ceiling in the instrument reads exactly like a defect in the
thing measured.

RETRACTION: F1.10 is not "1-vs-3 with RustySNES passing alone", and its Mesen2
verdict is phase-fragile. #306 published that reading from a measurement taken
at the time. Then rewriting E3.06 -- an UNRELATED APU row -- made Mesen2 PASS
F1.10: three identical runs before, three identical runs after. The rewrite
changed one uploaded program's length, which moved the cart's execution phase,
which moved when F1.10 samples $4212 relative to the vblank edge.

So Mesen2's verdict on that row encodes where the cart happens to be, not only
what Mesen2 models. snes9x and ares fail it stably; Mesen2 flips.
MESEN2_KNOWN_FAILURES drops 2 -> 1 (F1.03 only), and the comment says not to
restore an F1.10 entry: either pin the row's sampling point, or accept that
Mesen2's verdict on it carries no information.

Third instance of the same trap in one session, after E8.01's two rejected
drafts and the scene field gate.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: doublegate

CHANGELOG.md

@@ -11,6 +11,37 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Added
 
+- **`E3.06` rewritten to poll and accumulate — and ares agrees with it exactly.** The row read
+  `TnOUT` once at the end of the interval, and `TnOUT` is a four-bit read-and-clear counter, so the
+  useful range was `8..15` with the wrap one tick above. That is not a band that can be widened; it
+  is the instrument's ceiling. It now polls timer 2 every ~32 SPC cycles — one timer-2 period — so
+  every read returns 0, 1 or 2 and the running sum cannot lose a tick however long the interval gets.
+
+  It also asserts the **ratio** rather than two absolute counts: `|T2 − 8·T0| ≤ 6`, computed on the
+  65816. Absolute counts pin the poll loop's own cycle cost, which differs between cores for reasons
+  that have nothing to do with the 64 kHz stage — and that is precisely what made the old row fail on
+  ares while ares' own `Timer<128>`/`Timer<128>`/`Timer<16>` declarations were an exactly correct
+  8:1.
+
+  RustySNES and ares now report the **identical** 6 and 46. `ARES_KNOWN_FAILURES` drops 5 → 4. **A
+  ceiling in the instrument reads exactly like a defect in the thing measured**, which is the
+  reusable half.
+
+- **RETRACTION: `F1.10` is not "1-vs-3 with RustySNES alone", and its Mesen2 verdict is
+  phase-fragile.** #306 published that reading from a measurement taken at the time. Then rewriting
+  `E3.06` — an **unrelated APU row** — made Mesen2 **pass** `F1.10`. Three identical runs before,
+  three identical runs after. The rewrite changed one uploaded program's length, which moved the
+  cart's execution phase, which moved when `F1.10` samples `$4212` relative to the vblank edge.
+
+  So Mesen2's verdict on that row encodes where the cart happens to be, not only what Mesen2 models.
+  snes9x and ares fail it stably; Mesen2 flips. `MESEN2_KNOWN_FAILURES` drops 2 → 1 (`F1.03` only),
+  and the comment says not to restore an `F1.10` entry — either pin the row's sampling point, or
+  accept that Mesen2's verdict on it carries no information.
+
+  **This is the same trap for the third time in one session**, after `E8.01`'s two rejected drafts
+  and the scene field gate: a verdict that encodes an uncontrolled phase looks stable until something
+  unrelated moves.
+
 - **ares is wired into `crossval.sh` as a third reference.** `cross-validation: 3 reference(s) agree
   with the cart`, with `ARES_KNOWN_FAILURES=5` carrying the same per-row rationale the other two
   constants do: `C7.05`/`C7.10`/`F1.10` are rows snes9x already fails (ares corroborating it, not

scripts/accuracysnes/crossval.sh

@@ -191,26 +191,31 @@ SNES9X_KNOWN_FAILURES=14
 #                  | containing no Start and the cart would never leave its menu. Covered by the
 #                  | in-repo harness and snes9x, which do drive both ports.
 #
-#   F1.10  code 2  | NOT the port-2 limitation, though this comment said so until it was measured.
-#                  | `f1_require_contract` reads $4016 only, and code 2 means "$4212 read busy at
-#                  | the very start of the vblank line". Mesen2 fails it for the same reason snes9x
-#                  | and ares do -- the automatic read modelled as starting at the vblank edge
-#                  | rather than a few dozen cycles into the line.
+# `F1.10` USED to be a second entry here. It is not any more, and the reason is worth more than the
+# entry was.
 #
-# **So `F1.10` is 1-vs-3, with RustySNES passing ALONE.** snes9x, Mesen2 and ares all fail it. The
-# row is Documented -- nocash fullsnes puts the read's start at ~dot 32.5-95.5 of the first vblank
-# line -- and RustySNES passes only because of a deliberate auto-read-start-timing fix. A first-party
-# accuracy cart being right where three references are wrong is the point of having one, but 1-vs-3
-# on a scored row is stated here rather than left to be mistaken for consensus. If that citation
-# ever turns out to be misread, this row is where it will show.
-# **The Mesen2 runner can under-report under load.** One run during this investigation returned 1
-# where every other returned 2, while four other `dotnet` processes were live. `--timeout=60` is a
-# wall-clock bound, so a loaded machine can cut the battery short and report a SMALLER failing count
-# — which reads as "things improved", the most dangerous direction for a gate to be wrong in. Five
-# consecutive runs on an idle machine gave 2 every time, and `mesen_failing_set_probe.lua` gave the
-# identical SET four times. If this gate ever reports fewer failures than expected, re-run it idle
-# before believing it.
-MESEN2_KNOWN_FAILURES=2
+# It was first attributed to the port-2 limitation, which is wrong: `f1_require_contract` reads
+# $4016 only, and code 2 means "$4212 read busy at the very start of the vblank line". Measured
+# 2026-08-01, Mesen2 DID fail it, alongside snes9x and ares -- which read as "RustySNES passes
+# alone", and was published that way.
+#
+# **Then rewriting `E3.06` -- an unrelated APU row -- made Mesen2 PASS `F1.10`.** Three identical
+# runs before, three identical runs after. The rewrite changed one uploaded program's length, which
+# moved the cart's execution phase, which moved when `F1.10` samples `$4212` relative to the vblank
+# edge.
+#
+# So `F1.10`'s Mesen2 verdict is **phase-fragile**: it encodes where the cart happens to be, not only
+# what Mesen2 models. That is the same trap already recorded for `E8.01` and for the scene field
+# gate, in a third place. snes9x and ares fail it stably; Mesen2 flips. **Do not restore a
+# known-failure entry for it** -- either pin the row's sampling point, or accept that Mesen2's
+# verdict on it carries no information.
+#
+# **The Mesen2 runner can also under-report under load.** One run returned a smaller count than every
+# other while four other `dotnet` processes were live. `--timeout=60` is a wall-clock bound, so a
+# loaded machine cuts the battery short and reports FEWER failures -- which reads as "things
+# improved", the most dangerous direction for a gate to be wrong in. Re-run idle before believing a
+# drop, and use `mesen_failing_set_probe.lua` to read the SET rather than trusting the count.
+MESEN2_KNOWN_FAILURES=1
 
 # The PAL image's own count: only F1.03 fails there, so F1.10 passes on PAL and fails on NTSC under
 # the same port-2 limitation. That asymmetry has NOT been explained and is recorded as an open
@@ -236,22 +241,30 @@ MESEN2_PAL_KNOWN_FAILURES=1
 #   F1.10  code 2  | The auto-read start race. snes9x, Mesen2 AND ares all fail it — see the F1.10
 #                  | entry under MESEN2_KNOWN_FAILURES for why that leaves RustySNES passing alone.
 #
-# The other two share ONE cause, and it is a bug in ares rather than a disagreement:
+# The fifth is a bug in ares rather than a disagreement:
 #
-#   E3.06  code 2  | ares' `$F1` (CONTROL) handler NEGATES the timer-2 counter reset:
-#   E8.02  code 3  |     if(timer0.enable.raise(data.bit(0)))  { timer0.stage2 = 0; ... }
+#   E8.02  code 3  | ares' `$F1` (CONTROL) handler NEGATES the timer-2 counter reset:
+#                  |     if(timer0.enable.raise(data.bit(0)))  { timer0.stage2 = 0; ... }
 #                  |     if(timer1.enable.raise(data.bit(1)))  { timer1.stage2 = 0; ... }
 #                  |     if(!timer2.enable.raise(data.bit(2))) { timer2.stage2 = 0; ... }
 #                  |         ^ negated, and only here  (ares/sfc/smp/io.cpp)
 #                  | `raise()` is true on a 0->1 transition, so timers 0 and 1 reset ON a raise --
 #                  | the documented behaviour -- while timer 2 resets on anything EXCEPT one. Both
-#                  | rows enable timer 2 via `$F1`, run an interval, then write `$F1` again to STOP
-#                  | it, and that stopping write has already zeroed T2OUT. Both read 0 where
-#                  | RustySNES reads 10 and ~7. ares is internally inconsistent here, which is the
-#                  | strongest evidence available that it is a stray `!`: its own timers 0 and 1 do
-#                  | the un-negated version, and RustySNES, snes9x and Mesen2 all treat the three
-#                  | identically. The first bug this cart has found in a REFERENCE emulator.
-ARES_KNOWN_FAILURES=5
+#                  | The row enables timer 2 via `$F1`, runs an interval, then writes `$F1` again to
+#                  | STOP it, and that stopping write has already zeroed T2OUT -- so it reads 0.
+#                  | ares is internally inconsistent here, which is the strongest evidence available
+#                  | that it is a stray `!`: its own timers 0 and 1 do the un-negated version, and
+#                  | RustySNES, snes9x and Mesen2 all treat the three identically. The first bug this
+#                  | cart has found in a REFERENCE emulator.
+#
+# **`E3.06` used to be a sixth entry and is not any more, and it is worth saying why.** It failed on
+# ares for a reason that turned out to be the CART's: it read `TnOUT` once at the end of the
+# interval, and `TnOUT` is a four-bit read-and-clear counter, so the useful range was 8..15 with the
+# wrap one tick above. Rewritten to POLL and accumulate -- and to assert the ratio rather than two
+# absolute counts -- RustySNES and ares now report the identical 6 and 46. The row proves ares'
+# timer 2 does run at 64 kHz; the old instrument could not see it. A ceiling in the instrument reads
+# exactly like a defect in the thing measured.
+ARES_KNOWN_FAILURES=4
 
 # Where the built host lives. Not built by this script: it is a C++ link against ares' static libs
 # and takes minutes, so it is opt-in via `scripts/accuracysnes/ares_host/build.sh` and this block

tests/roms/AccuracySNES/ERROR_CODES.md

@@ -2640,8 +2640,8 @@ Provenance: **Documented** (SNESdev Wiki, SPC700 timers; fullsnes). Kind: scored
 
 | Code | Byte | Meaning |
 |---|---|---|
-| 1 | `$02` | timer 0 did not tick once over this interval, or ticked more than three times — either way the interval is not the one this test needs and the ratio below means nothing |
-| 2 | `$04` | timer 2 did not count roughly eight times what timer 0 did over the same interval, so it is not running from the 64 kHz stage — a core reading $01 here runs every timer at 8 kHz. NOTE: this row cannot distinguish that from timer 2 having WRAPPED past 16, so read slot 267 before concluding anything; ares fails here with a recorded 0 |
+| 1 | `$02` | timer 0 did not tick over this interval, or ticked far more than the poll loop allows for — either way the interval is not the one this test needs and the ratio below means nothing |
+| 2 | `$04` | timer 2 did not count within six ticks of eight times timer 0 over the same interval, so it is not running from the 64 kHz stage — a core running every timer at 8 kHz lands near a seventh of the expected count. The two raw counts are in slots 266 and 267 |
 
 ### E3.08 — TEST bit 0 halts timers
 

tests/roms/AccuracySNES/asm/tests_group_a.s

@@ -22926,7 +22926,7 @@ CATALOG_IMPL = 1
     rep #$30
     .a16
     .i16
-    lda #48
+    lda #69
     sta f:V_APU_LEN
     lda #$0200
     sta f:V_APU_DEST     ; APU RAM $0200: clear of the zero page and the stack
@@ -22973,11 +22973,6 @@ CATALOG_IMPL = 1
     ; Release: the program hands the APU back to the IPL so the NEXT test can upload at all.
     lda #$A5
     sta APUIO0
-    ; Record both counts before asserting on either. `TnOUT` is FOUR BITS, so timer 2's band
-    ; below ends one tick short of its wrap -- and a core whose SMP runs slightly fast crosses
-    ; it and reads a small number, which is indistinguishable from 'timer 2 is not running at
-    ; 64 kHz' unless the raw counts are kept. ares fails this row, and without these the failure
-    ; cannot be told from a real divergence.
     rep #$30
     .a16
     .i16
@@ -22987,31 +22982,41 @@ CATALOG_IMPL = 1
     sta f:$7EE414
     lda f:$7E0102
     and #$00FF
-    ; record slot 267: E3.06 timer 2 ticks over the SAME interval (TnOUT wraps at 16)
+    ; record slot 267: E3.06 timer 2 ticks, ACCUMULATED across polls (no 4-bit ceiling)
     sta f:$7EE416
-    ; Timer 0 first: one tick, maybe two. Zero would make the ratio below unmeasurable.
+    ; Timer 0 first: the interval has to contain a couple of its ticks for a ratio to exist.
     lda f:$7E0101
     and #$00FF
     cmp #$0001
     bcs :+
     jmp @fail1
   :
-    cmp #$0004
+    cmp #$0007
     bcc :+
     jmp @fail1
   :
-    ; Timer 2 over the SAME interval: eight times the rate, so eight or more ticks. The band is
-    ; 8..15 and `TnOUT` wraps at 16, which leaves NO headroom above -- and that is structural,
-    ; not a choice: timer 0 must tick at least once for the ratio to mean anything, and one
-    ; timer-0 period IS eight timer-2 periods, so timer 2 can never be below 8 and the wrap is
-    ; only a factor of two away. Measured: RustySNES 10, ares 0 -- and 0 is what 16 reads as.
+    ; The row, as a RATIO rather than two absolute counts. Asserting absolute numbers pins the
+    ; poll loop's own cycle cost, which differs between cores for reasons that have nothing to
+    ; do with the 64 kHz stage -- that is what made the previous version fail on ares while its
+    ; `Timer<128>/Timer<128>/Timer<16>` declarations were an exactly correct 8:1.
+    lda f:$7E0101
+    and #$00FF
+    asl a
+    asl a
+    asl a             ; timer 0 ticks x 8 = what timer 2 should have counted
+    sta f:$7E01F0
     lda f:$7E0102
     and #$00FF
-    cmp #$0008
+    sec
+    sbc f:$7E01F0     ; the signed error against the ideal ratio
+    clc
+    adc #$0006        ; biased by 6 so the allowed band is 0..12 rather than -6..+6
+    and #$00FF
+    cmp #$0000
     bcs :+
     jmp @fail2
   :
-    cmp #$0010
+    cmp #$000D
     bcc :+
     jmp @fail2
   :
@@ -23029,14 +23034,14 @@ CATALOG_IMPL = 1
     sta f:$7EE010
     jml test_restore
 @fail1:
-    ; timer 0 did not tick once over this interval, or ticked more than three times — either way the interval is not the one this test needs and the ratio below means nothing
+    ; timer 0 did not tick over this interval, or ticked far more than the poll loop allows for — either way the interval is not the one this test needs and the ratio below means nothing
     sep #$20
     .a8
     lda #$02
     sta f:$7EE010
     jml test_restore
 @fail2:
-    ; timer 2 did not count roughly eight times what timer 0 did over the same interval, so it is not running from the 64 kHz stage — a core reading $01 here runs every timer at 8 kHz. NOTE: this row cannot distinguish that from timer 2 having WRAPPED past 16, so read slot 267 before concluding anything; ares fails here with a recorded 0
+    ; timer 2 did not count within six ticks of eight times timer 0 over the same interval, so it is not running from the 64 kHz stage — a core running every timer at 8 kHz lands near a seventh of the expected count. The two raw counts are in slots 266 and 267
     sep #$20
     .a8
     lda #$04
@@ -34143,10 +34148,12 @@ apu_prog_112:
     .byte $C4, $F2, $E4, $F3, $C4, $F7, $E8, $5A, $C4, $F4, $E4, $F4
     .byte $68, $A5, $D0, $FA, $E8, $80, $C4, $F1, $5F, $C0, $FF
 apu_prog_113:
-    .byte $CD, $EF, $BD, $8F, $01, $FA, $8F, $01, $FC, $E4, $FD, $E4
-    .byte $FF, $8F, $85, $F1, $8D, $18, $FE, $FE, $8F, $80, $F1, $E4
-    .byte $FD, $C4, $F6, $E4, $FF, $C4, $F7, $E8, $5A, $C4, $F4, $E4
-    .byte $F4, $68, $A5, $D0, $FA, $E8, $80, $C4, $F1, $5F, $C0, $FF
+    .byte $CD, $EF, $BD, $8F, $01, $FA, $8F, $01, $FC, $8F, $00, $10
+    .byte $8F, $00, $11, $E4, $FD, $E4, $FF, $8F, $85, $F1, $E4, $FF
+    .byte $C4, $12, $E4, $10, $60, $84, $12, $C4, $10, $AB, $11, $E4
+    .byte $11, $68, $18, $D0, $ED, $8F, $80, $F1, $E4, $FD, $C4, $F6
+    .byte $E4, $10, $C4, $F7, $E8, $5A, $C4, $F4, $E4, $F4, $68, $A5
+    .byte $D0, $FA, $E8, $80, $C4, $F1, $5F, $C0, $FF
 apu_prog_114:
     .byte $CD, $EF, $BD, $8F, $01, $FA, $8F, $0B, $F0, $8F, $81, $F1
     .byte $8D, $00, $FE, $FE, $8F, $80, $F1, $E4, $FD, $C4, $F6, $8F