I have a simple animation loop going on the C64.
In that loop, I have a delay between each frame. During each frame, I update a ZP counter (single byte).

My delay looks something like this (KickAsm):



Now, if I have a value such as $03 in the ObjectAnimationDelay, I notice the frames update every 4th frame. Which is correct. And, it's "even". Meaning, no single frame gets more time than any other.

Other values that seem to work OK are: $0f, $1f, etc.

What is odd is that some values cause funny behaviors. One value is $06.

If I use that, one frame will get much longer display time than the others.
My assumption is because 6 isn't evenly divisible by 256. But I would have thought the amount of time visible would only be slightly longer than the other frames but in reality, it's like 5 times longer. Just doesn't seem proportional.

So then I tried changing to other values that ARE evenly divisible by 256 and some of them behave the same way. Some don't.

For example, these work just fine: $03, $07, $0f, $1f, $3f
These do not work: $2f, $4f

I'm perfectly OK with sticking to a handful of "good values". I'd just like to understand why some numbers are drastically out of proportion.

Thanks!

_________________
Cat; the other white meat.

AND is working on the individual bits, so if you convert your numbers to binary it should make it clearer what's happening.

Using 6 as an example that's 110 in binary, it's still counting 1 frame in 4 as the 03 value would, but the zero flag will be set twice in succession, then skip 6.

OK that makes sense. I knew I needed to create a large truth table to see a real pattern.
Thanks

_________________
Cat; the other white meat.

For this purpose, you could use a "virtual clock" scheduling algorithm as follows: