Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user su3686 ! (Registered 2023-05-30) You are not logged in - nap
CSDb User Forums

Forums > C64 Coding > Tricky code execution time calculation puzzle
2023-05-21 17:45

Registered: Aug 2003
Posts: 106
Tricky code execution time calculation puzzle

Hi, you magnificent cycle-counting mathematical brains of C64 scene. I have a puzzle for you to solve. :) I've been scratching my head with this for a while, to no avail. Now it is time to accept inferiority and defeat and ask for help from people far more capable than yours truly.

I have a code loop that utilises two lower bytes of the jiffy clock ($A1 and $A2), and has an internal 8bit up-counter too. Given the dependency on the jiffy clock, I've been trying to determine how long the loop has to run for the three values (internal up counter, jiffy lo, jiffy mid) to return to same values as when the loop began running, and when we're also at the exact same cycle of the loop (and the same number of cycles until the next jiffy clock update too) when this happens. In other words, how long does my code have to truly run until repetition occurs.
Also, as interrupts are enabled, I suppose the system interrupts have an effect on all of this? But I simply don't have enough knowledge of C64's kernal/basic interrupts, their execution time, and how do they affect the loop execution time and/or the accuracy of jiffy clock.

Specs of my loop:
- Length of the loop is always 35 cycles
- Loop has an internal 8bit up-counter (cycles through 256 values)
- Loop uses values of low and mid bytes of the jiffy clock ($A1 and $A2)
- Interrupts are not disabled

What I've been able to determine:
- Considering the loop's internal counter only, the loop returns to the initial state in 256 * 35 = 8960 cycles.
- Jiffy clock has 5184000 values, from $000000 to $4F19FF, updated every 1/60th of a second.
- If the loop state (values of jiffy lo and mid, internal counter, exact cycle where we are in the loop, exact cycle of jiffy clock updating) "resets" within a day, I consider this beginning of the repetition.
- If however the loop state does NOT reset within a day, and the jiffy clock resets back to $000000, I suppose we must consider the whole range of jiffy clock in our calculations.

This is where my max brain capacity is reached. :D I don't know about you, but to me calculating this is far, far more complex than what one might initially think.

I would share the code itself, but it is for an upcoming size coding compo so I can't. Nevertheless, I hope I've exposed all details about the loop that are relevant for the calculations.
2023-05-21 19:31

Registered: Apr 2002
Posts: 4875
do you realize you have 16 bit timers in both CIAs you can program to fire them when you want? each tick of that 16bit value is 1 clock cycle on the cpu, but you can make one clock count how many times the other has underflowed. so instead of a "wait" (?)loop you can just have one of the CIA chips count as many cycles you want, then it can fire an interrupt for you. and it doesnt ends here, as interrupts whatever doesnt affect this counting.
2023-05-21 20:09

Registered: Aug 2003
Posts: 106
I do understand, but my loop is not a wait loop, it is the whole thing. This is an entry for an upcoming 16 byte intro compo. ;)

The code itself is ready, I'm just curious how long it actually runs before repeating, but I can't figure the maths out (and I am lacking the knowledge of how the kernal/basic IRQs affect the timings anyway).
2023-05-21 22:25

Registered: Apr 2002
Posts: 4875
jiffydos timer will restart in 24h, and thats the answer, as your loop will take all 256 possible values many times during each jiffy tick.

if you want more accurate answer that would be asking for hacking an emulator that checks when the same cycle exact circumstances occur again. because of the interrupts the behaviour is too unpredictable, what you are asking is a lot of work to calculate.
2023-05-23 12:57

Registered: Oct 2014
Posts: 456
The Jiffy clock is updated by the standard IRQ handler, which doesn't have a solid number of clocks that it takes, as the keyboard scan will take longer or shorter depending if keys are pressed.
On a PAL machine without any key pressed and no modifications to the standard interrupt handler A1 is changed 16406,16420,16422 and so on, as it is not frame sync'd it will move about the frame and sometimes hit bad lines etc.
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Users Online
Barfly/Powers of Pain
E$G/hOKUtO fOrcE
Guests online: 73
Top Demos
1 Coma Light 13  (9.6)
2 Edge of Disgrace  (9.6)
3 Uncensored  (9.6)
4 Bromance  (9.6)
5 Comaland 100%  (9.6)
6 Lunatico  (9.5)
7 Unboxed  (9.5)
8 Memento Mori  (9.5)
9 Wonderland XII  (9.5)
10 Christmas Megademo  (9.5)
Top onefile Demos
1 Party Elk 2  (9.8)
2 Copper Booze  (9.6)
3 Pandemoniac Part 1 o..  (9.5)
4 Barry Boomer - Trapp..  (9.5)
5 Dawnfall V1.1  (9.5)
6 Daah, Those Acid Pil..  (9.5)
7 Onscreen 5k  (9.5)
8 Selbuvotter Latitudes  (9.4)
9 Square Booze  (9.4)
10 Offering  (9.4)
Top Groups
1 Booze Design  (9.4)
2 Oxyron  (9.3)
3 Censor Design  (9.3)
4 Crest  (9.3)
5 Pond  (9.2)
Top Organizers
1 Burglar  (9.9)
2 Yugorin  (9.8)
3 Sixx  (9.8)
4 MWS  (9.7)
5 hedning  (9.7)

Home - Disclaimer
Copyright © No Name 2001-2023
Page generated in: 0.033 sec.