Exact cycle counter

[litwr]

I want to write an exact cycle counter for the 6502, but I think I've missed something. My counter always loses 2 cycles and I can't figure out why. I can only hope that a 6502 expert can help me...
In detail, I count all the cycles per screen. I use the raster interrupt on the same line to start and finish the procedure. The main code is simply a sequence of NOPs. The raster interrupt handler takes the address of the next NOP from the stack and subtracts the address of the first NOP from this value. I then multiply the difference by two to get the number of cycles spent on the main code. All that remains is to add the number of cycles spent on the interrupt handler itself. However, this value is always two cycles less than it should be according to the technical data.
I made my code for Commodore+4 and Commodore 64. I can make the code for other architectures that support raster interrupts if it helps to solve the problem. Let me present the code for the C64. It is available on github. There are two small programs there.

cycle-counter-0 is just skeleton code. You need a debugger to work with it but it briefly shows the main idea.

cycle-counter uses that skeleton to get a more advanced program that prints the number of cycles.

Using VICE I get 18520+59=18579 cycles on the PAL machine instead of 18581 (287*63 + 25*20 - normal + bad lines). I get 15959+59=16018 cycles on the NTSC machine instead of 16020 (238*65 + 25*22). Actually the program shows 2 numbers 15958 and 15960 that gives 15959 on average.
The sources for the C+4 is here.
Many thanks in advance. Are there similar programs available elsewhere?

[BigEd]

I think I'd recommend somehow checking with Hoglet's 6502 decoder.
https://github.com/hoglet67/6502Decoder
(It feels likely you have mis-accounted for interrupt latency, or something like that. Have you any way to run the ISR twice and see if the discrepancy doubles?)

[White Flame]

I don't have the code on me, but what I did when I did this is use a CIA timer. When the timer interrupt hit, it would read the current raster line. If the line was less than the previous read, it would increment the timer length by 1, and decrement if it ended up on a line further down. If it stayed on the same line for 256 frames, then I knew the timer was in sync with the screen, and represented the number of cycles per frame.

[BigDumbDinosaur]

BigEd wrote:

(It feels likely you have mis-accounted for interrupt latency, or something like that. Have you any way to run the ISR twice and see if the discrepancy doubles?)

Was thinking the same thing.  Another possibility is a miscount of total scan lines.

Also, I very vaguely recall that there was something a little hinky about the VIC-II raster interrupt and it not always hitting exactly on the same scan line every time due to the very short period in which the beam is on a particular line.  However I haven’t done anything with VIC graphics since around 1987, so I may be thinking of something else.

[litwr]

Thanks but it seems this problem is too hard for us. Perhaps those two cycles are part of the universe's infinite, global uncertainty.

BigEd wrote:

I think I'd recommend somehow checking with Hoglet's 6502 decoder.
https://github.com/hoglet67/6502Decoder

Could you tell me which part of this large project I should check? I want to create a version of my code for the BBC Micro, but if I recall correctly, it doesn't support raster interrupts. We would need to use some complicated techniques with timers to simulate them, but this would make achieving exact counting results very problematic.

BigEd wrote:

(It feels likely you have mis-accounted for interrupt latency, or something like that. Have you any way to run the ISR twice and see if the discrepancy doubles?)

My code (ISR) runs in the infinite loop, it shows number of cycles in live. It is quite easy to run it with VICE or any other emu. You can take the binary file here.

White Flame wrote:

I don't have the code on me, but what I did when I did this is use a CIA timer. When the timer interrupt hit, it would read the current raster line. If the line was less than the previous read, it would increment the timer length by 1, and decrement if it ended up on a line further down. If it stayed on the same line for 256 frames, then I knew the timer was in sync with the screen, and represented the number of cycles per frame.

It seems your method is a line accurate counter but my code must have been a cycle exact. Anyway why to use timers when we have raster interrupts?

BigDumbDinosaur wrote:

Also, I very vaguely recall that there was something a little hinky about the VIC-II raster interrupt and it not always hitting exactly on the same scan line every time due to the very short period in which the beam is on a particular line.  However I haven’t done anything with VIC graphics since around 1987, so I may be thinking of something else.

I suspect that some subtle issues with the VIC-II and CPU connections could be causing an additional two cycles to be used. However, the same problem applies to the Commodore Plus 4. But both machines are very similar and may have the same problems. I am also thinking that I could miss something about the 6502 prefetch opcode capabilities...

[litwr]

My gosh! It seems I made a stupid mistake. STA ABS,X ALWAYS takes 5 cycles but I counted it as 4 cycles. Excuse me, I am ashamed much. Sorry.

[BigEd]

ah, it was simple! A good result.

[White Flame]

litwr wrote:

It seems your method is a line accurate counter but my code must have been a cycle exact. Anyway why to use timers when we have raster interrupts?

No, my method is cycle-accurate. If it for instance was off by 1 cycle, then over the course of ~65 frames it would drift to firing on a different raster line. If the periodic interrupt fires on the same raster line over a long period of time without drifting to other lines, then it exactly matches the number of cycles per frame, with the cycle count directly numerically present in the timer counter latch.

But it's good to hear that your method was solved.