4

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:

C64 PAL

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:

C64 NTSC

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 PAL

Plus/4 NTSC:

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)?
Improve this question
1
  • 1
    The jiffy clock can still be 60 Hz while being tied to the 50 Hz PAL refresh. You'd just increment the jiffy clock twice every so often. Commented Jul 31, 2020 at 21:41

2 Answers 2

Reset to default
5

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.

Improve this answer
3
  • 2
    I'll just add that you can verify this by looking at the kernal disassembly (fx ted/kernal/kernal.lst) off of zimmers.net/anonftp/pub/cbm/src/plus4/… - search for judt2 Commented Jul 31, 2020 at 23:56
  • This is a great answer, thanks. In hindsight it seems logical, but it hadn't occured to me that one could occasionally increase the jiffy value by more than one. Commented Aug 1, 2020 at 18:29
  • 50 Hz PET models also used the same trick (increase the jiffy clock an extra 1 every 5th time) to effectively have a 60 Hz jiffy clock. Commented Dec 12, 2022 at 17:56
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.

Improve this answer
1
  • This is indeed the case for the C64 but does not apply to the Plus/4 where the jiffly clock is derived from a raster interrupt as can be seen by looking at the kernal disassembly (fx ted/kernal/kernal.lst) in zimmers.net/anonftp/pub/cbm/src/plus4/… (search for judt2) Commented Jul 31, 2020 at 23:58

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.