> I'm trying to work out the timing for displaying the graphics each scan line on
> a C64 emulator I'm working on. Based on other commodore 64 emulators I've looked
> at, the width is usually 384 pixels (divisible by 8) and the height varies from
> emulator to emulator. Based on this article
> http://www.minet.uni-jena.de/~andreasg/c64/vic_artikel/vic_article_3.4.htm I
> understand how the cycles per raster line are calculated but I'm not sure when
> to draw the pixels to my back buffer with the proper timing that's needed. From
> what I understand the graphic chip is running 8 times as fast as the cpu and
> therefore draws 8 pixels each clock cycle of the cpu. But that doesn't figure
> right when I calculate the cpu cycles per scan line. I Just know I need to draw
> 8 pixels on the screen each time I update my backbuffer but I'm not sure when
> that is in cpu cycle time.
> From what I understand from the article the cycles per scan line are calculated
> for PAL as follows: cpu speed of 985,000 hertz / 50 fps / 312 scan lines = 63
> cycles per scan line. Which is the same as taking 985,000 hertz / 25 fps / 625
> scan lines of an actual PAL screen. But from there I'm lost. Can anyone add any
> insight as to when I update my draw function for each scan line? I'm looking to
> draw the scan line section by section (8 pixels at a time) then flag a HBlank
> interrupt when the scan line has been drawn.
The C64 does draw one block of 8 pixels during a single 6510 cycle. Some effects require a cycle-accurate synchronisation between the VIC-II and the 6510, so you will need to take care of that in your CPU core as well. There aren't any hblank interrupts as such, though you would need to trigger the beam synchronised interrupt at the start of a scanline, which amounts to basically the same thing. Also don't forget that the VIC-II steals cycles from the 6510 when it needs to read sprite/tilemap data from work RAM.