slajerek / RetroDebugger

Retro Debugger is a multiplatform debugger APIs host for retro computers: C64 (Vice), Atari800 and NES (NestopiaUE).
173 stars 20 forks source link

Bad Line Timings seem incorrect (shifted) when comparing to what the VIC2.txt states #62

Open paich64 opened 3 weeks ago

paich64 commented 3 weeks ago

Describe the bug Machine PAL, Bad Line, No sprites. running a program cycle by cycle when on a bad line, it looks like the bad line timings reported by The CPU counters are the following: 12 r/w cycles 3 w only cycles 40 cycles stolen by vic2 (43 if the above 3 w only cycles can't be used by any instruction) 8 r/w cycles

However, according to the vic2.txt doc (https://www.zimmers.net/cbmpics/cbm/c64/vic-ii.txt) the timings should be :

11 r/w cycles 3 w only cycles 40 cycles stolen by vic2 (43 if the above 3 w only cycles can't be used by any instruction) 9 r/w cycles

To Reproduce Steps to reproduce the behavior:

  1. Load the .prg in attachement
  2. run it using SYS4096
  3. Hit F10 to stop the execution
  4. Using the VIC2 screen, explore the CPU timings on raster line $83 (which is a badline) and notice the discrepancy that i have reflected in the big picture I have uploaded

Expected behavior Unless I'm wrong, according to the VIC2.txt doc, there should be 11 r/w cycles (not 12) at the beginning of the badline, and 9 r/w cycles (not 8) at the end of the badline.

Screenshots

VicTimingIssueInRetroDebuggerOnBadLine

Desktop (please complete the following information):

Additional context

rastcolor1.zip

paich64 commented 3 weeks ago

I have carefully reviewed the VIC2.txt file, and the very first "x" on the list belongs to cycle 63 which has been voluntary duplicated by the author on the left of the document (and cycle 1 has been also voluntary duplicated by the author on the right). Also based on the "phi" signal it's obvious the first "x" belongs to cycle 63 which has been duplicated. VicTimingIssueInRetroDebuggerOnBadLine2