One thing I really liked about the 8-bit (and even most 16-bit) games was that the frame rate was fixed to the vertical blanking. Games were smooth back then. I've been trying to recreate that feeling on a Macbook Pro and recently on a RetroPie (connected to an almost new 65" Sony TV) without any real success. The Mac does a better job than the RetroPie but it's not perfect.

VICE is an excellent emulator and it is so perfectly timed that it even handles horizontal raster splits. It has to handle microsecond timing correctly to pull that off.

The RetroPie hardly breaks a sweat (one of four cores at 30%) to emulate the C64 and that's why it bothers me that it seems unable to even do a simple side-scroller smoothly. The juddering reminds me of a bad conversion from 24 fps to 25 fps (the actual frame rate for a PAL C64 is 50 fps). Why does this seem so hard to emulate and is there something I can do about it?

  • 1
    No all games scrolled smoothly sideways back then. JCB Digger on the BBC was so bad it was universally known as JCB Judder.
    – Chenmunka
    Jul 12, 2017 at 13:19
  • 1
    Cobra for the ZX Spectrum was quite famous in its day for being one of the few titles for that platform that locked itself to 50Hz updates. But scrolling on the Spectrum is even more hassle than the BBC — all software, all the time, no CRTC tricks. Luckily the CPU was in the beefier range and the display buffer fairly compact. Cobra specifically used the trick of pointing the stack buffer at the display file. The Z80 can push two bytes and address decrement that address in 11 cycles, and the Spectrum has linearly-addressed scan lines.
    – Tommy
    Jul 12, 2017 at 13:54
  • That ZX Spectrum trick reminded me of a recent ABC80 hack. A new graphics mode for a 39 years old computer. youtube.com/watch?v=0EzeMt2F-kU The ABC80 does not have a raster line counter, only a vertical blanking NMI so to make manipulation on each raster line possible it's all about counting CPU cycles. Jul 12, 2017 at 14:43
  • 1
    One issue is that a non-realtime multitasking OS like MacOS (based on BSD) or RetroPie (based on Debian Linux) is allowed to preempt the emulator and cause it to drop frames. Maybe QNX would be a better host OS. Jul 12, 2017 at 16:44
  • Another reason...the C64 and CRT technology = epic win.
    – cbmeeks
    May 11, 2018 at 22:24

4 Answers 4


Macs with a built-in screen are generally locked to 60Hz. Your Raspberry Pi is most likely also to be running at 60Hz.

The simplification applied by almost all emulators is to calculate an entire frame of the display, output that, calculate the entire next frame, output that, ad infinitum.

Therefore the software is pushing a complete new frame 50 times a second. Your Mac or Pi is pushing a new HDMI or composite image 60 times a second. Neither is doing anything in particular in regard of the difference. So you're probably not even getting as nice a conversion as a bad 24 to 25 — for C64 frames 1 2 3 4 5 6 7 8 9 10 you'll at best be getting output of 1 2 3 4 5 5 6 7 8 9 10 10. But because nowhere is it exactly written that 5 frames shall be output in 6 slots you also might be seeing some minor timing differences pushing one or the other frame backwards or forwards during the time that 50Hz and 60Hz end-of-frame timings are close.

On your Raspberry Pi, modify your config.txt for 50Hz if you haven't already. That should help a lot. Possibly you'll still get the odd frame that goes slightly askew because cross-platform libraries rarely tie neatly to platform-specific signals like retrace.

EDIT: with a little more research on the C64 specifically, one frame takes 19,656 cycles (312 lines of 63 cycles), but the machine is clocked at around 985,248.6111Hz (it's 17.734475Mhz divided by 18). So a real machine actually puts out about 50.13 frames per second. So even if you adjust the Pi to put out 50 that's still not quite the perfect rate. As you note though, VICE has an option to just lock itself to one frame of output = one frame of input. So then you're running your emulated C64 about 0.25% too slowly, but that should be a lot less worrying an imperfection than dodgy frame adaptation.

For comparison, quite a few 24fps movies are just sped up for PAL-region 25fps broadcast for the same reason. That's is a 4.2% speed up, so more than sixteen times as far off, but I've never met anybody who realised without being told.

  • Comment, not answer: I've actually found that treating one line of output as the minimum thing painted to the host screen rather than one frame works a whole lot better if you also have phosphor decay in place. Hand waveringly, that inherently eliminates the hard chop you'd associate with tearing, but then you win in motion terms by painting something every output frame. Also it scales up to 120/144Hz gaming monitors. But that's independent research in the emulator I happen to write, which has a very limited appeal for many other reasons. So not strongly helpful in answering your question.
    – Tommy
    Jul 12, 2017 at 13:56
  • 1
    @traal You're righting something to the host's display buffer. That buffer is only read once every [protocol-dependent time interval] by the system that deals with image display.
    – wizzwizz4
    Jul 12, 2017 at 19:27
  • 3
    I changed to 50Hz in config.txt (hdmi_mode=19 720p 50Hz ) and everything got better but it still skipped a frame now and then. Sometimes it ran flawlessly for a couple of seconds and then a few skips. I then found the Speed setting Refresh rate in VICE. I changed that from Automatic to 1/1 and the scrolls ran just as smooth as I remembered them! Jul 12, 2017 at 20:30
  • 2
    @JonasElfström ah, yes, I've had a quick look at clock rates and the C64 is actually 50.13Hz, not 50Hz. So a Pi at 50 still isn't quite exactly on the money unless you allow the emulator to be a tiny bit off. There's no route to perfect though, given the constraints; I think what you've done is probably as good as it gets and almost imperceptibly different. Unless you intend to load a clock program and run it for a few hours. If my arithmetic holds up and you were to play Prince of Persia, you'd get slightly more than nine extra seconds to save the princess.
    – Tommy
    Jul 12, 2017 at 20:53
  • 1
    "That's is a 4.2% speed up, so more than sixteen times as far off, but I've never met anybody who realised without being told" -- I have, but only because until relatively recently the method of doing so also increased the pitch of sounds, and musicians who have perfect pitch can easily distinguish a sound with a 4% frequency shift from where it's supposed to be. Visually, you'll never tell the difference.
    – Jules
    Jun 10, 2018 at 18:04

I'll come from the other end -- nice and smooth feeling of 50fps screen update was mostly because of stroboscopic nature of CRT tvs and monitors used: while you move your line of sight smoothly, CRT shortly displays a flash of picture for you every time in the correct place, hence the "one-frame" feel. Even if you'll use 50Hz lcd tv for real C64, there will be no comparable feeling, since lcd shows the same picture during all the frame.

  • 4
    Which is exactly why I play all my games on real hardware running on a real CRT. Can't emulate that. :-)
    – cbmeeks
    Jul 13, 2017 at 12:25
  • 1
    I would think something like an OLED could come really close if a manufacturer wanted to do so.
    – supercat
    Jul 21, 2017 at 16:56
  • 50 fps or 60 fps looks quite smooth even on today's LCD monitors. Not as smooth as on a PAL/NTSC CRT, I get that, but the problem the question was about is that emulators "randomly" drop or show frames twice, which is a far, far more noticeable problem.
    – ddekany
    May 11, 2018 at 13:21
  • There is still a difference: on CRTs, some small one-frame moving sprite seems to be excellently sharp, while on LCDs it would be blurred by 1 pixel (for the case when movement speed is 1 pixel per frame)
    – lvd
    May 15, 2018 at 19:18

On WinVice 3.1 (certainly on other Vice-s as well), perfectly smooth scrolling is possible on the expense of severe sound glitches... which may not be acceptable, but here it is. If your monitor refresh rate is close to 50 (for PAL emulation) or 60 (for NTSC emulation), and you set "Settings"/"Maximum speed" to 101% (or maybe higher), and "Settings"/"Refresh rate" to "1/1" (not "Auto"), then the emulated vertical refresh will be perfectly aligned with the monitor refresh rate. If speed is at 100%, then duplicate frames will occur (quite often on my system), because when the emulation missed the real vertical blank then it can do nothing about it and have to show the same frame again (assuming VSYNC is used, which is needed for this whole thing to work). But if it reaches the emulated vertical blank too early (and that's what we try to consistently achieve with speed over 100%), it can still pause to wait for the real vertical blank (or whatever it's called on a modern display). But you will have a lot of odd sound distortions, the more you go over 100%, the more. (It's kind of expected, given how sound is programmed on Commodore 64, but I don't get why are they so dramatic)

Note that this all assumes that Vice shows things with VSYNC (no mid screen tearing). For me by default it does, even if the related video setting is grayed out for some reason.

It might be also good to know that you don't have to change your desktop refresh rate to 50 (from the common default 60), as you can configure Vice to switch to 50 Hz in full screen mode (if your hardware supports it).


the only way to get a perfect emulation is using a real crt tv with winvice and the correct modeline to output an "original" c64 video-signal. http://forum.arcadecontrols.com/index.php?topic=138847.0

  • 2
    Well... it's not the only way... That aside, it would be helpful if you included some more information from that link, perhaps with the > blockquote syntax. That way people can see it even if that link goes dead (link rot) and a whole host of other advantages.
    – wizzwizz4
    Jun 10, 2018 at 15:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .