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.

> 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.

Thanks for the information.

Writing a 100% cycle accurate c64 emulator is a bit pointless, you might as well just port vice. Some of the nastiest tricks you can do on the c64 are used by a couple of demos that were written after the c64 died.

An emulator good enough for most games is probably worth doing for pocket pc or a gp32, although I'd be more interested in modding a c64dtv into a handheld case.

smf

> Writing a 100% cycle accurate c64 emulator is a bit pointless, you might as well
> just port vice. Some of the nastiest tricks you can do on the c64 are used by a
> couple of demos that were written after the c64 died.
>
> An emulator good enough for most games is probably worth doing for pocket pc or
> a gp32, although I'd be more interested in modding a c64dtv into a handheld
> case.

You will need cycle-accurate emulation or very nearly so for some games, and pocket PC should be fast enough given you don't try to go all-out with SID emulation.

> You will need cycle-accurate emulation or very nearly so for some games,

Yes for some, but how many? Back to my other thought I had the other day for hacking a portable C64DTV and using something like a SDMMC or compact flash for storing tape/disk images. Then it struck me that the c64 chip in it is so accurate you'd have real loading times. On a battery operated device who wants to suck up 3 minutes of battery for loading times? So you can instantly knock off any games that used multiload & just concentrate on single file'd games. You still get the classics but don't have to go all out with the emulation.

This is all IMO, I've found it more fun to concentrate on getting one game running then move on to the next than spend the whole time coding and only then seeing any results.

smf

I've been going thru that vic artcle I posted earlier, specifically this section: http://www.minet.uni-jena.de/~andreasg/c64/vic_artikel/vic_article_3.6.htm#3.6.3

I'm starting to understand what's going on but I'm confused on the "X Coo." portion of the chart. Anyone know what that's all about? I don't understand what all those numbers are for.

The chart provided in that article has been useful for answering most of the timing issues I've been inquiring about. From what I've read, I now no when to draw each sprite and tile (text or bitmap background) and how many cpu cycles should pass when doing so. But I'm not sure when to start drawing the border. Anyone have any idea? I know its probably not that important but I'd like to get as close as possible.