docs(accuracysnes): record what each remaining v1.28.0 row actually needs - #283
Conversation
…eeds Working the rows filed as "needs no new machinery" showed several need rather more. The assessments are now in docs/accuracysnes-plan.md with the evidence, rather than left to be re-derived. The binding constraint across Group A/B is the measurement budget: hv_begin/hv_end cost ~189 dots against a 341-dot scanline, leaving ~152 usable before the H counter wraps and silently returns a plausible small number rather than failing. - A5.18 is parked on that arithmetic. BRK cannot be measured without RTI, so the span is a round trip and the differential is two extra stack accesses; measuring both and subtracting works (8 iterations gave 32 / 16 / 16 exactly as predicted) but a round trip is 39 dots, so 8 of them wrap. It passed only because both arms wrapped by the same 341 -- the tell being that the native round trip read 170, LESS than the 293 of the strictly cheaper RTI-alone arm. Three iterations fit, giving 6 dots of signal against TOL 2 in a difference-of-differences. - A6.15 needs its own design: sweep.rs deliberately covers only the unambiguous opcode subset, so citing it would be restatement. - C7.05/C7.06 are entangled with RustySNES setting range_over a line late against MesenCE, plus the F1.09 polling-vacuity shape. - B2.07 is gated on B2.02, and B2.09 is framebuffer-oracle work by its own dossier note. Both are v1.29.0. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 25 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Comment |
Module 40 says keep deep engineering narrative out of the CHANGELOG; the measurements belong in docs/accuracysnes-plan.md, which the entry now points at instead of restating. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Review adjudicationNo blocking issues. One suggestion applied, one nitpick declined. CHANGELOG carries too much engineering detail. Applied — and it is not just style, it is a British spelling of "quantisation". Declined, on two grounds. The repo has no single convention More to the point, the sentence in question is describing the |
Antigravity review (Gemini via Ultra)This PR updates the AccuracySNES roadmap documentation ( Blocking issuesNone found. Suggestions
Nitpicks
Automated first-pass review by |
#284) * docs(accuracysnes): correct the C7.05/C7.06 verdict — no eval-line gap The assessment landed in #283 said RustySNES sets range_over a line late against MesenCE. Re-measured on main with scripts/probes/eval-line-213e: it first reads set at scanline 100, which is MesenCE's value. The one-line lag belonged to the BATCH compositor, and per-dot is now the only one -- the probe's own README already recorded both figures, so this was a misreading rather than a measurement that changed. What actually remains for those rows is sampling resolution, not correctness. A polling loop is several dots per iteration and would pass whatever the true position is (the F1.09 vacuity shape). The probe demonstrates the technique that works -- an H-IRQ at a chosen HTIME, latching $2137/$213F and reading $213E -- so the rows should be written as a bracket: one sample below the expected H = OAM.INDEX*2 expecting clear, one above expecting set, the same shape D2.01 uses. Both of the probe's recorded traps are carried into the note: HTIME=300 pushes IRQ latency into the V-counter increment and skews every reading by a line, and the $213F read is required to reset the OPHCT/OPVCT second-read flip-flop. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(accuracysnes): move the per-row detail out of the table cells Raised in review: the C7.05/C7.06 cell had grown past 1,000 characters, which is unreadable in a plain-text editor and makes every future diff noisy. The A5.18 cell had the same problem at 744. Both now carry a one-line verdict and point at a subsection below the table, where the probe invocation, the two sampling traps, and the wrap-detection tell have room to be stated properly. Also records that probe.sfc is gitignored, so run.sh must build it first. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 participant
Follow-up to #282. Working the
v1.28.0rows filed as "needs no new machinery" showed that severalneed rather more, and the reasons are worth recording once rather than re-deriving each time.
The binding constraint
hv_begin/hv_endcost ~189 dots against a 341-dot scanline, leaving ~152 usable beforethe H counter wraps — and a wrap returns a plausible small number instead of failing. That single
number bounds every Group A/B timing row, and it is now written down with the per-body arithmetic.
Per-row verdicts
A5.18BRKthat never returns cannot be repeated, so the span is aBRK + RTIround trip and the differential is two extra stack accesses. Measuring both and subtracting works — 8 iterations gave round-trip delta 32, RTI-alone 16,BRK's own 16, exactly as predicted. But a round trip is 39 dots, so 8 of them wrap; it passed only because both arms wrapped by the same 341. The tell: the native round trip read 170, less than the 293 of the strictly cheaper RTI-alone arm. The largest count that fits is 3 → 6 dots of signal againstTOL2, in a difference-of-differences where quantisation from four measurements accumulates against it. Not sound, so not shipped.A6.15sweep.rs's own module docs list why control flow,BRK/COP,STP,WAIand memory-addressing modes are excluded from it. Citing the sweep would be coverage by restatement.C7.05,C7.06range_overa line late (two, batched) against MesenCE — an exact-position row would fail for a reason that is not its subject. A polling loop is also several dots per iteration, which is theF1.09vacuity shape.B2.07B2.02B2.04covers the 262-line count, not the clock total, so the frequency is not implied by it. 60.0988 Hz needs clocks-per-frame, and the frame alternates 357,368/357,364 because of the short scanline — which isB2.02, aT-06-Aresidual scheduled forv1.29.0.B2.09v1.29.0What this means for the rung
The mechanically writable Group A/B rows are largely done. Most of what remains is either gated on
the
v1.29.0dot-model work or needs an instrument cheaper than the one that exists — so the honestshape of
v1.28.0is smaller than the row list suggested, and the plan now says so.Docs and CHANGELOG only; no generator or ROM change, so the committed cart is untouched.
🤖 Generated with Claude Code