Commodore Plus/4 jiffy clock tied to screen refresh frequency? (warning: flashing images)

Question

Warning: There are flashing images below, do not scroll down if you are sensitive to them!

According to various sources (for example this for the Plus/4), both the C64 and Plus/4 have a "jiffy" clock, which ticks approximately every 1/60 sec. However, when I tried to use the jiffy clock in code, I found it strangely correlated with the screen refresh on Plus/4. Take this ASM example in CA65 dialect, which changes the border color on every jiffy change (then changes it back after a short while):

.ifdef __C64__
    border_color = $d020
    jiffy_lsb = $a2 ; Jiffy clock LSB
.endif
.ifdef __PLUS4__
    border_color = $ff19
    jiffy_lsb = $a5 ; Jiffy clock LSB
.endif

loop:
    lda jiffy_lsb
wait4jiffy:
    cmp jiffy_lsb
    beq wait4jiffy

    inc border_color

    ldx #$ff
simulate_workload:
    dex
    bne simulate_workload

    dec border_color

    jmp loop

I tested this in the VICE emulator. On a PAL C64, the placement of the colored range changes erratically (as expected), because the jiffy clock is 60Hz and the PAL screen refresh is 50Hz. The following screen recording is slowed down to reduce flashing and to make the pattern more visible:

On an NTSC C64, the colored bar moves slowly and fluently (as expected), because the jiffy clock and the NTSC screen refresh are both around 60Hz, but are not exactly the same. The following screen recording is approximately real speed:

However, on a Plus/4, regardless of PAL/NTSC, the colored bar is completely stationary (apart from a tiny jitter). The following screen recordings are approximately real speed:

Plus/4 PAL:

Plus/4 NTSC:

How is this possible?

• Did I overlook something?
• Is this a bug in the VICE emulator?
• Is the jiffy clock tied to the screen refresh in the Plus/4 (making it 50Hz in the PAL model instead of the stated 60Hz)?

Answer 1

As you stated, the results for the C64 make sense, given that the interrupt source is based on a 50 Hz timer which is a bit off from a real 50 Hz signal, like for example the PAL screen refresh.

For the Plus/4, both models, the PAL and the NTSC version use a rasterline interrupt as an interrupt source. This can be checked by looking at address $ff0a which shows the enabled interrupt sources. Timer interrupts are disabled. Since the Plus/4 supports graphic modes with raster splits, that makes sense.

In the NTSC mode, the jiffy clock is increased by one with every raster interrupt, providing a 60 Hz clock. Your assembler program detects a change after each interrupt service routine, which makes it synchronized to the rasterline.

In the PAL mode, the Plus/4 routine cheats a little bit. The routine is now called 50 times per second, but the jiffy clock should count 60 ticks per second. Therefore, the Plus/4 PAL jiffy clock skips a number every now and then, after a quick test recording I saw such a sequence 00 01 02 04 05 06 07 08 0a 0b 0c 0d 0e 10 11 ... - so there was a two-step increase from $02 to $04 and from $08 to $0a. Since your program only checks for a change of the jiffy clock lsb, your program changes the screen 50 times a second while the jiffy clock increases by 60 in the same time.

Answer 2

The video timing is generated by the onboard crystal oscillator.

On the C64, the 50/60 Hz clock comes from the stepped down mains frequency of the 9VAC from the transformer, so it ticks at whatever the current mains frequency happens to be.

So the C64 clocks are asynchronous. It is not tied to screen refresh.

The Plus/4 works differently, it does not use the mains frequency and it is tied to the screen refresh.