Jiffies in Assembly

By Michael Doornbos

- 3 minutes read - 429 words

Many of you know that you can use a “Jiffy” on a Commodore as a measure of time. Sorta.

The short short version is that we have a 3 byte clock that increments once every interrupt, so 1/60th of a second. It’s not considered reliable as a real time clock, but it IS useful for benchmarking.

According to “Compute’s Complete Guide to the C64” p. 156:

“TI equals PEEK(162) + 256PEEK(161) + 256256*PEEK(160); for TI$, the value of TI (in jiffies) is converted into hours, minutes, and seconds.”

It goes on to explain that there is a drift that can be as much as a couple minutes a day “depending on your power source”, so keep that in mind. We’re going to use it to compare changes in code execution, not time a marathon.

BASIC

In BASIC you can set the TI$ to 000000

10 TI$="000000"
20 REM DO SOME STUFF
30 PRINT TI

This will print the number of “Jiffies” for this routine.

Well be using this over, and over, and over, and over, and over in the next post where we compare the speed of a BASIC routine using a simple program that Noel from Noel’s Retro Lab (follow him, seriously) came up with to get a rough idea of the execution speeds on the systems he has. Here’s an example:

Lot’s more of these in the benchmarking post

Lot’s more of these in the benchmarking post

How do we do this in Assembly

This set of 3 bytes is available in our Assembly programs as well. They are in zero page decimals 160-162 (hex $A0-$A2) in reverse endian format.

So to use this, we do the same thing as in our BASIC program.

  • reset to zero
  • do some stuff
  • check the clock

I typically print the values somewhere to the screen as part of debugging, but you could certainly copy them somewhere for viewing via a monitor.

lda #$0
sta $a2
sta $a1
sta $a0
;------------------------------
; do some stuff here
;------------------------------
lda $a0
jsr printbyte 
lda $a1
jsr printbyte 
lda $a2
jsr printbyte


printbyte 
      ;put print hex value (or whatever) to screen here

Pretty easy.

I leave this as a hex value, simply because hex to the screen is quite a bit shorter than hex to decimal to the screen. This is a benchmark routine, and my current hex to dec standard routine is like 70 lines. Overkill.

Happy Benchmarking!

Fun fact: Did you know that my Commodore 64 (NTSC) takes over 22 HOURS to count to 16 billion with a Machine code program? My Macbook in Rust: 1.67 seconds. What a world!