Skip to content

Let bitmap mode's switch-off reach the graphics fetch a cycle late, start SYS(n) stubs in the VICE harness - #336

Merged
highbyte merged 1 commit into
feature/cpu-cycle-enginefrom
feature/c64-vic2-register-timing-tests
Sep 17, 2026
Merged

highbyte merged 1 commit into
feature/cpu-cycle-enginefrom
feature/c64-vic2-register-timing-tests

Conversation

@highbyte

Copy link
Copy Markdown
Owner

Summary

Two things found through VICE's vicii_timing and videomode test programs.

  • The graphics fetch follows bitmap mode a cycle late when it is switched off. On the NMOS chips (6569, 6567R8) the g-access's address uses BMM as it is in that cycle or as it was in the cycle before, whichever is set, so a bitmap-off reaches the fetch one cycle after it reaches the sequencer (whose own timing, set four pixels into the cycle and cleared six pixels in, was already there). In the cycle the mode changes, a fetch that moves from RAM into the character ROM takes the address's low byte from the bitmap address and the rest from the character set's.
  • Harness: SYS(2080) stubs. The SYS parser stopped at an opening parenthesis and started such programs at their load address instead. The three vicii_timing programs and spritevssprite had therefore never run.
  • Two unit tests for the fetch rule (character set in RAM, and in the ROM for the merged address); docs updated.

Verification

  • VICE harness, 274 VIC-II tests on both models: 239 to 241 match. vicii_reg_timing (35,000 pixels of never-started garbage before, then 56 from the fetch rule alone), videomode2 on PAL and videomode-z on NTSC now match; several other videomode cases are a few pixels closer.
  • One test goes the other way and is not a regression: spritevssprite never ran before and its timeout was counted as a match. It now runs and fails on reading the sprite collision register in the middle of a line, which we latch at the line's end (a known follow-up, shared with spriterestart and the two collision-cycle tests).
  • What remains in the videomode group is in its hand-crafted references rather than in the emulation: videomode-w's 6569 reference paints one line in colours the program never sets (its 8565 reference shows what we draw), videomode1's NTSC reference lacks the text pattern its PAL reference has, and the one and two pixel cases are the ones the suite's readme calls undecided. Moving BMM's falling edge by a pixel to satisfy vicii_reg_timing's -a5/-ff builds breaks three tests that match, so it stays.
  • Games A/B against the integration branch: identical for Commando (two snapshots, D64 PAL and NTSC) and Giana Sisters (D64 PAL and NTSC). Demo A/B: all fourteen demos identical at three frame counts.
  • Timing (For Your Sprites Only, four alternating rounds): nothing that stands out of the noise; the configurations this change does not touch vary as much.
  • Whole solution builds; full test suite passes (the wall-clock test passes when run alone).

@sonarqubecloud

Copy link
Copy Markdown

@highbyte
highbyte merged commit 7a09d87 into feature/cpu-cycle-engine Sep 17, 2026
9 checks passed
@highbyte
highbyte deleted the feature/c64-vic2-register-timing-tests branch September 17, 2026 13:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant