[CSDb] - User Forums - Tricky code execution time calculation puzzle

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Tricky code execution time calculation puzzle

2023-05-21 17:45

Frostbyte

Registered: Aug 2003
Posts: 167

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

Oswald

Registered: Apr 2002
Posts: 5017

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

Frostbyte

Registered: Aug 2003
Posts: 167

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

Oswald

Registered: Apr 2002
Posts: 5017

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

oziphantom

Registered: Oct 2014
Posts: 478

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.

2024-02-11 12:39

Frostbyte

Registered: Aug 2003
Posts: 167

So the production in question is finally released: Frostbyte's 15th Symphony [15/17 bytes]

I think I did end up calculating how long it'd approximately take for the loop to cycle over, but I can't find my notes anymore or the chat where I discussed about that with someone, so "about 20 mins" it is. :D It was either a bit over or a bit under. Anyway, more than 13 minutes as that's the longest I've listened to it on one sitting. :D

Refresh

Subscribe to this thread: