From 68339b157827aadf6bc5a58c2d32f6edd11ce9b8 Mon Sep 17 00:00:00 2001 From: DoubleGate Date: Sun, 2 Aug 2026 03:28:20 -0400 Subject: [PATCH] docs: C10.04 is blocked by the same exclusion that unblocked C5.15 Attempted and withdrawn; the attempt is worth more written down than the scene would have been. C10.04 says a mosaic of 1 is the identity at 256 pixels but a 2x1 pair of half-pixels in true hi-res. A Mode 5 scene with MOSAIC = $01 was written against exactly the control the working rules ask for -- the same canvas with mosaic off -- and hashed IDENTICALLY to that control on both references: 0xf7ed8ab9ecd95d85 either way. The reason is structural, not a bug in the scene. A 2x1 mosaic pair merges an EVEN column with its ODD neighbour, and HiResEven samples only the even columns, so the merge is invisible to the hash by construction -- the extraction discards precisely the columns the assertion is about. So C10.04 sits with C5.06/C5.07: its subject lives in the MAINSCREEN half, which the three references diverge on by 33-35% pairwise and which rule 4 forbids blessing. HiResEven does not unblock it and no variant can -- any rule including the odd columns inherits the disagreement. This is the unshowable-scene trap in its exact documented form. The control scene caught it, and its doc comment said in advance what an equal hash would mean, which is why it cost one run rather than a blessed golden that proved nothing. Write the control first: it is the only thing that distinguishes "the references agree" from "nothing happened". Docs only; the scene is not in the tree. 55 scenes still match on both hosts, three references agree. Co-Authored-By: Claude Opus 5 (1M context) --- CHANGELOG.md | 17 +++++++++++++ .../0013-accuracysnes-framebuffer-oracle.md | 25 +++++++++++++++++++ 2 files changed, 42 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 0b275cb9..ab1b98a2 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -11,6 +11,23 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 ### Fixed +- **`C10.04` attempted and withdrawn: it is blocked by the same exclusion that unblocked `C5.15`.** + A Mode 5 scene with `MOSAIC = $01` was written against the control the working rules require — the + same canvas with mosaic off — and hashed **identically to it on both references** + (`0xf7ed8ab9ecd95d85` either way). + + The reason is structural. A 2x1 mosaic pair merges an *even* column with its *odd* neighbour, and + `HiResEven` samples only the even columns, so the merge is invisible to the hash **by + construction**. `C10.04` therefore sits with `C5.06`/`C5.07`: its subject lives in the mainscreen + half, which the references diverge on by 33-35% pairwise and which rule 4 forbids blessing. No + variant of `HiResEven` can help — any rule including the odd columns inherits the disagreement. + + Recorded rather than silently dropped, because the *attempt* is the finding: this is the + unshowable-scene trap in its documented form, and **the control scene is the only thing that + distinguishes "the references agree" from "nothing happened"**. Its doc comment said in advance + what an equal hash would mean, which is why the trap cost one run instead of a blessed golden that + proved nothing. + - **`C5.15` is now blessed coverage: excluding the one undefined pixel made the rest of Mode 5 agree.** The retraction below establishes that the first hi-res pixel of a line is a genuine reference disagreement on a value ares flags as *not confirmed on hardware*. Hashing it would have diff --git a/docs/adr/0013-accuracysnes-framebuffer-oracle.md b/docs/adr/0013-accuracysnes-framebuffer-oracle.md index 3f87f31a..ff438d48 100644 --- a/docs/adr/0013-accuracysnes-framebuffer-oracle.md +++ b/docs/adr/0013-accuracysnes-framebuffer-oracle.md @@ -240,3 +240,28 @@ The method note is the durable part. Two references agreeing is not "the referen 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. + +### `C10.04` is blocked by the same exclusion that unblocked `C5.15` + +Attempted 2026-08-02 and **withdrawn**, because the attempt is worth more written down than the +scene would have been. + +`C10.04` says a mosaic of **1** is the identity at 256 pixels but a **2x1 pair of half-pixels** in +true hi-res. A Mode 5 scene with `MOSAIC = $01` was written against exactly the control the working +rules ask for — the same canvas with mosaic off — and it hashed **identically to that control on +both references**: `0xf7ed8ab9ecd95d85` either way. + +The reason is structural, not a bug in the scene. A 2x1 mosaic pair merges an *even* column with its +*odd* neighbour, and `HiResEven` samples **only the even columns**. The merge is therefore invisible +to the hash by construction: the extraction discards precisely the columns the assertion is about. + +So `C10.04` sits with `C5.06`/`C5.07` — its subject lives in the **mainscreen** half, which is the +half the three references diverge on by 33-35% pairwise and which rule 4 therefore forbids blessing. +`HiResEven` does not unblock it, and no variant of `HiResEven` can: any rule that includes the odd +columns inherits the disagreement. + +This is the *unshowable scene* trap (`CLAUDE.md`) in its exact documented form — "a scene can arrange +a state no picture can show; an unshowable scene hashes stably and every emulator agrees with it." +The control scene is what caught it, and its doc comment said in advance what an equal hash would +mean. **Write the control first; it is the only thing that distinguishes "the references agree" from +"nothing happened".**