From a0b210631de2fa865d668fe9e223771fc652538f Mon Sep 17 00:00:00 2001 From: DoubleGate Date: Sun, 2 Aug 2026 02:01:56 -0400 Subject: [PATCH] =?UTF-8?q?docs:=20retract=20the=20Mode-5=20defect=20claim?= =?UTF-8?q?=20=E2=80=94=20it=20is=20a=202-vs-2,=20not=20a=20RustySNES=20bu?= =?UTF-8?q?g?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit PR #322 published "the two references agree bit-for-bit and RustySNES differs, which is this project's signature for a real defect". That was wrong, and wrong for exactly the reason this project's own notes warn about: I had TWO references, concluded "RustySNES alone", and had not read the third. Diffing the pixels rather than the hashes: the divergence is ONE COLUMN -- column 0 of the extracted sample, the first pixel of the 512-wide picture -- on all 224 rows and nothing else. 224 differing pixels of 57,344. RustySNES 0x0000, snes9x 0x0421 (the backdrop). ares' sfc/ppu/dac.cpp settles it AGAINST the original conclusion. scanline() seeds `math.above.colorEnable = false` under the comment "the first hires pixel of each scanline is transparent // note: exact value initializations are not confirmed on hardware", and below() returns (n15)0 -- black -- in that state. RustySNES seeds `above_enable: false` and does the same. The split is RustySNES + ares against snes9x + Mesen2, on a value ares itself flags as unverified. Consequences, recorded so the scene is not mistaken for a pending fix: there is no defect here; c5-mode5-hires-16px-tiles is NOT blessable under ADR 0013 rule 4 and stays permanently unblessed as a variant set; C5.15 does not become coverage this way, though a hi-res scene avoiding column 0 would make the rest of Mode 5 blessable. The extraction infrastructure is vindicated regardless -- two hosts with different geometries produced identical hashes for the other 57,120 pixels. The durable note: two references agreeing is not "the references agree". This project counts ares and bsnes as ONE reference precisely because lineage matters, and here the lineage that disagreed was the one not consulted. Read the third source BEFORE publishing a defect claim. Co-Authored-By: Claude Opus 5 (1M context) --- CHANGELOG.md | 22 +++++++++++ .../0013-accuracysnes-framebuffer-oracle.md | 38 +++++++++++++++++++ 2 files changed, 60 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index de79babe..aae3d43c 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -11,6 +11,28 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 ### Fixed +- **RETRACTION: the Mode-5 first-pixel divergence is a 2-vs-2 reference disagreement, not a + RustySNES defect.** The entry below claims the two references agree bit-for-bit against RustySNES, + "this project's signature for a real defect". That was published from **two** references without + consulting the third, which is the exact mistake this project's own notes warn about. + + Diffing the pixels rather than the hashes: the divergence is **one column** — column 0 of the + extracted sample, the first pixel of the 512-wide picture — on all 224 rows and nothing else. 224 + differing pixels of 57,344. RustySNES `0x0000`, snes9x `0x0421` (the backdrop). + + ares' `sfc/ppu/dac.cpp` settles it *against* the original conclusion: `scanline()` seeds + `math.above.colorEnable = false` under the comment *"the first hires pixel of each scanline is + transparent // note: exact value initializations are not confirmed on hardware"*, and `below()` + returns `(n15)0` — black — in that state. RustySNES does the same thing. The split is **RustySNES + + ares against snes9x + Mesen2**, on a value ares itself flags as unverified. + + So there is **no defect to fix**, and `c5-mode5-hires-16px-tiles` is **not blessable** under + ADR 0013 rule 4 — it stays permanently unblessed as a variant set rather than looking like a + pending golden. `C5.15` does not become coverage this way; a hi-res scene avoiding column 0 would + make the rest of Mode 5 blessable, and that is the follow-up. The extraction infrastructure is + vindicated either way: two hosts with different geometries produced identical hashes for the other + 57,120 pixels. + - **Both scene hosts silently accepted an out-of-contract frame geometry.** The width tests were lower bounds — `w < SCENE_W` in the libretro host, `#buf < …` in the Mesen2 script — which catch a frame that is too *narrow* and miss one that is too **wide**. Too wide is the case that actually diff --git a/docs/adr/0013-accuracysnes-framebuffer-oracle.md b/docs/adr/0013-accuracysnes-framebuffer-oracle.md index 6f960633..3f87f31a 100644 --- a/docs/adr/0013-accuracysnes-framebuffer-oracle.md +++ b/docs/adr/0013-accuracysnes-framebuffer-oracle.md @@ -202,3 +202,41 @@ The scene is left **unblessed**. Rule 4 would permit blessing at the reference v references agree — but that turns the scene gate red on a live finding, and an unblessed scene does not fail the gate, so the finding is preserved without taking the tree red. The investigation is tracked separately; blessing follows the fix. + +### Correction, same day — that divergence is a 2-vs-2, not a RustySNES bug + +The claim above ("the two references agree bit-for-bit ... one host failing alone means a bug in +that host") is **withdrawn**. It was made from two references without consulting the third. + +Diffing the pixels rather than the hashes: the divergence is **exactly one column** — column 0 of +the extracted sample, the first pixel of the 512-wide picture — on all 224 rows, and nothing else. +224 differing pixels of 57,344; RustySNES `0x0000`, snes9x `0x0421` (the backdrop). + +ares' source settles it against the original conclusion. `sfc/ppu/dac.cpp::scanline()`: + +```cpp +//the first hires pixel of each scanline is transparent +//note: exact value initializations are not confirmed on hardware +math.above.colorEnable = false; +``` + +and `below()` returns `math.above.colorEnable ? math.below.color : (n15)0` — **black** at line +start. RustySNES seeds `above_enable: false` and does the same thing. So the split is **RustySNES + +ares against snes9x + Mesen2**, and ares explicitly flags its own initialisation as *not confirmed +on hardware*. + +Consequences, recorded so the scene is not mistaken for a pending fix: + +- There is **no defect here to fix**. Changing column 0 to emit the backdrop would move RustySNES + off ares' behaviour to match the other two on a value ares says is unverified. +- `c5-mode5-hires-16px-tiles` is **not blessable** under rule 4 and stays permanently unblessed + unless real hardware settles it — a variant set, not a pending golden. +- `C5.15` does not become coverage this way. A hi-res scene that avoids column 0, or a hash that + excludes the first column, would make the rest of Mode 5 blessable; that is the follow-up. +- The extraction itself is **vindicated**: two hosts with different geometries produced identical + hashes for the other 57,120 pixels. + +The method note is the durable part. Two references agreeing is not "the references agree" — this +project counts ares and bsnes as **one** reference precisely because lineage matters, and here the +lineage that disagreed was the one not consulted. Read the third source *before* publishing a defect +claim, not after.