RustyNES v2.6.5 — "Muster" (rung 5 closes — the AccuracyCoin status vector is identical entry for entry across all 146 entries, with 146 of 146 executed on both sides and none NotRun. Five PPU defects close the last six differing entries, and one of the release's own diagnoses is retracted)

RustyNES v2.6.5 "Muster"

Rung 5 closes: the AccuracyCoin status vector is identical entry for entry across all 146 entries, with 146 of 146 executed on both sides and none NotRun.

A muster is a roll call where every name is called and answered. That is this release's acceptance exactly, in two clauses: the vector agrees entry for entry, and no entry is unrun on both sides. The second clause is v2.6.4's addition — without it, an identical vector over entries that never executed is a pass, and was one.

The gate

coverage: 146 of 146 entries executed on both sides (0 on neither, 0 on one side only)
status vectors are IDENTICAL entry for entry across all 146 entries.

Measured over the 4500-frame golden, 134,012,761 cycles. At the version's start the same gate read 5 of 146 executed and 22 differing.

Five defects, and the shape they share

Four of the five were invisible to every gate that existed when the version opened, and the recurring shape is a gate agreeing about a question it was never asked.

The background shift registers' reload and their shift clock need separate gates. With one shared gate BG Serial In was not merely failing, it was arithmetically unreachable: reload dots are absolute, so on a render re-enable the next reload is at most seven dots away, and the reload discards the low seven bits — a serial-in one can never reach bit 7, on any alignment, for any stimulus. Modelling both structures reproduces both measured shifter values, the oracle's F807 falling out of the split model without being fitted to it.

That fix alone left the gate red. The sprite X counters are not gated on rendering, and AccuracyCoin's Stale Sprite Shift Registers test 2 states it outright — "Rendering was disabled for 18 ppu cycles, but the sprite counters were NOT halted during that time". This core froze them, so a disable/enable pair pushed every sprite right by the width of the window. The ROM that states the rule passes either way: it expects no hit at X=254, and a sprite shoved 18 dots further right is also off the end of the line.

The PPUADDR second-write v <- t copy is delayed, and the wiki says so inside the write sequence itself — "wait 1 to 1.5 dots after the write completes". This core committed it in the write's own edge. Swept 1 to 4 dots (all close Hybrid Addresses) against a control at 8 and 12 (both fail, which is what proves the parameter reached the compiler); the documented minimum ships.

The pre-render line clears secondary OAM. The whole evaluation block — including the clear — was gated on scanline < 240, so the pre-render line kept what scanline 239 had left and the next frame's scanline 0 drew it. No sprite can ever render on scanline 0, because OAM Y is stored one less than the display row. A sprite-0 probe over the full battery named it in one run: 24 hits in 134 M cycles, four of them at scanline 0, one per frame.

The fifth, the octal latch holding across the read dot, is verified by exactly one gate and was unverifiable until the fourth landed — the two compose the hybrid address together and neither produces it alone.

A diagnosis retracted

The residual was read as a two-dot CPU/PPU alignment error, from comparing per-dot record spans across two instruments. Three configurations refute it: at the committed alignment the two consoles execute identical pc, bus_addr and bus_access for 1,695,131 cycles, while a two-dot power-on shift moves the first divergence back to 593,228 and takes the differing share from 5.13% to 66.80%. The "two dots" was two instruments stamping their records at different points in the cycle — the v2.5.7 lesson, third occurrence.

Also

rustynes-cosim's state_trace_records_carry_their_cpu_cycle was gated on a feature no CI step enabled, so it ran nowhere — a regression test the gate could not reach, which is the shape the surrounding CI steps exist to prevent. It now runs, and the test that is genuinely inapplicable under that feature is gated out with its reason rather than left failing.

The oracle changes on the default path (a Controller::write_strobe owed-shift fix), so AccuracyCoin 141/141 (RAM decoder) and nestest 0-diff are verified, not asserted.