Convert Hz to Timer?

[JoeJoe]

Hello,

I'm a bit stuck at the moment. My problem is to create a timer that can process 40Hz as well as 75Hz.

My idea:
If I now have a 1/3000Hz, I could trigger it 75 times for the 40Hz and 40 times for the 75Hz. But I can't set a timer like that. I can't get any further with the VBA either, because it only triggers 50 (PAL) times a second.

Does anyone have an idea. Or am I completely wrong?

Thanks

[Samurai_Crow]

What operating system version are you targetting? If you need more precise timing on most Amiga versions older than 3.2 (possibly including 3.2 also) you might just need to use a timer-based interrupt based on the complex interface adapter (CIA) chip.

[JoeJoe]

Yes, I will use the CIA Timer.

[paraj]

Well that are many options depending on the constraints, e.g. is it important that the interval is exact or is it sufficient that the rate is correct? Can you reprogram the timer?

If the interval part is not too important, you can trigger the 75Hz one twice every other frame (3/2 * 50Hz = 75Hz) and omit the 40Hz one very 5th frame (i.e. trigger 4/5 times).

Or if you can program the timer to your liking, set it up to tick at 3000Hz and initially set the timeout to 40 (for the 75Hz) timer, when it expires reprogram to (75-40) for the 40Hz one, then to 5 for the second 75Hz tick, etc. (you don't have to change the timer frequency for this approach, just scale the numbers appropriately.)

Or just use two timers

[Photon]

Timers evenly divisible into seconds is a classic problem in computing. Generally, there's no such thing because no dedicated crystal with such a frequency was added to motherboards.

Later, computers got clock chips for system time, but generally not for programming timers.

Finally, the actual trigger will be rounded to the nearest CPU clock cycle or four, plus a number of cycles to push program counter and register contents onto the stack to reach the instruction to be timed exactly, and that number of cycles will vary with acceleration. (Interrupts can also be delayed by DMA hogging, such as by older HDD controller DMA, Blitter, and the other DMA chips.)

If you want an accurate-as-possible timer at a specific beats per second, you can use two high-resolution interrupts at 40 and 75Hz. These will be as exact as it gets, but will drift if run for hours. You can either start them both and select which one to use at interrupt time, or detect or select beforehand and only start one of the two.

If you just want a video frequency-independent timer for an on-screen clock, CIA A TOD counter divided by the mains frequency from Exec should fit the bill? Timer details.

[JoeJoe]

First of all,

thanks for the answers. I can only use TBLO and TBHI from CIA A. Do the respective values for a 1/3000 HZ timer look like this?

; 30000 / 1.3968255 = $53e5
move.b #$53,CIATBHI+CIAA
move.b #$e5,CIATBLO+CIAA

Thanks

[paraj]

CIA ticks at 1/10th of 7MHz clock, i.e. every 1410ns. At 3000Hz you want a clock that ticks every ~333333ns which would be 333333/1410 = 236 ($ec) ticks. $53e5 is around 30 milliseconds. You definitely do not want 3000 mostly unnecessary interrupts per second though.

Instead if you really only have one timer available (or in general you have more timer needs than you have physical timers available), keep track of when the next one is due and program the physical timer with the necessary value.

Generally it is better if you have a counter that always counts and you can set a timeout, but TOD counter is buggy in a way I don't recall, and it's not how "lowlevel" CIA timers, work.

Maybe this (python) code makes it more clear, what I mean:

TICKS_PER_SEC = 28375160 / 40
TICK_INTERVAL_SEC = 1/TICKS_PER_SEC

def ticks(hz):
    return round(TICKS_PER_SEC / hz)

TICKS_40 = ticks(40)
TICKS_75 = ticks(75)

t40 = TICKS_40
t75 = TICKS_75

print([x*TICKS_40 for x in range(1,10)])
print([x*TICKS_75 for x in range(1,10)])

interval = 0
next = "<Init>"

t = 0
for i in range(10):
    t += interval
    print("%d %s" %( t, next))
    t40 -= interval
    t75 -= interval
    assert t40 >=0
    assert t75 >=0
    if t40 < t75:
        interval = t40
        next = "T40"
        t40 += TICKS_40
    else:
        interval = t75
        next = "T75"
        t75 += TICKS_75

[Don_Adan]

From my memory 3000 Hz timer will be wasted too many CPU power on 68000.
But maybe I remember wrong.
For me, if it must be timer then 20 Hz or 40Hz with extra counter for handling 75Hz.

[meynaf]

3000Hz is big, especially for 68000. But you don't need 3000Hz to get 40Hz and 75Hz timers.
You could use 600Hz timer instead. Count 1 out of 15 for 40Hz and 1 out of 8 for 75Hz.

[Thomas Richter]

Originally Posted by Samurai_Crow

What operating system version are you targetting? If you need more precise timing on most Amiga versions older than 3.2 (possibly including 3.2 also) you might just need to use a timer-based interrupt based on the complex interface adapter (CIA) chip.

I wouldn't know why anything in the timer.device changed in 3.2, not that I know of. But then again, I wonder why it seems necessary to bang the hardware for that. Compute the time in usecs and open the timer.device unit #0 for it to get a delay as close as possible to the desired rate. High precision timing (and synchronization) is not exactly the feature of the Amiga - unless it is related to genlocking. But 75Hz and 40Hz are outside of the genlock range anyhow.

[JoeJoe]

Thanks for the helpful answers. I'll test it with the 600Hz.

[JoeJoe]

For 50Hz this is a value of 14187 (PAL). If I then change the frame color every timer trigger, the Y position is not fixed. If I set the value to 14209, the Y position remains almost the same when the timer is reached.
I would have thought that for 50Hz the timer is always triggered at the same point. Or am I making a mistake in the calculation.

Here is a small overview for calculating timer values ??and where the frequency values ??come from.

; The base Amiga crytal frequecies are:
;           NTSC    28.63636 MHz
;           PAL     28.37516 MHz
;
; NTSC:
; - CLK = 7.15909 MHz (28.63636/4 > div 4 at FAT AGNUS) 
; - E is 1/10th of the clock input (CLK) of 68000 = 7.15909/10 = 0.715909 Mhz or 28,63636/40 = 0.715909 MHz = 715909 Hz
; - That works out to 1.3968255742 microseconds per count ( 1/715909 = 1.3968255742)
; e.g.:
;   #  3000 / 1.3968255742 ~  2148  (3 miliseconds = 3000 microsecsonds)
;   # 10000 / 1.3968255742 ~  7159  (1/100 = 10,000 microseconds)
;   # 20000 / 1.3968255742 ~ 14318  (1/50 = 20,000 microseconds)
;
; PAL:
; - CLK = 7.09379 MHz (28.37516/4 > div 4 at FAT AGNUS) 
; - E is 1/10th of the clock input (CLK) of 68000 = 7.09379/10 = 0.709379 Mhz or 28,37516/40 = 0.709379 MHz = 709379 Hz
; - That works out to 1.40968368107 microseconds per count ( 1/709379 = 1.40968368107)
; e.g.:
;   #  3000 / 1.40968368107 ~  2128  (3 miliseconds = 3000 microsecsonds)
;   # 10000 / 1.40968368107 ~  7093  (1/100 = 10,000 microseconds)
;   # 20000 / 1.40968368107 ~ 14187  (1/50 = 20,000 microseconds)

[ross]

1/(freq/2)*227*313*freq/10-1

CCKs per line = 227
Lines per (long) field = 313
CIA underflow = -1

In PAL 14209

[JoeJoe]

okay.....my calculation is wrong?

[ross]

Originally Posted by JoeJoe

okay.....my calculation is wrong?

It depends.
No, if you want an exact 50Hz (you just have to manage the rounding better due to the fact that the CIA count does not stop at 0 but goes into underflow at -1).
Yes, if you expect to synchronize these 50Hz with a frequency that is not exactly this (Amiga PAL' progressive modes, both 312 and 313 lines, are not exactly 50Hz).

[Don_Adan]

I can tell only about music players.
$376B or $376C for 50 Hz.
$376C is closest value than $376B.

[JoeJoe]

Thank you all for the helpful explanations.

[malko]

Originally Posted by ross

1/(freq/2)*227*313*freq/10-1
CCKs per line = 227
Lines per (long) field = 313
CIA underflow = -1
In PAL 14209

Sorry if "student"'s dumb question, but are the CCK the number of memory access by each screen line ?
If yes, the book "Amiga system programmer's guide (Abacus - 1988)" mention 225 memory accesses. Do I have to correct my learning notes ?

[hooverphonique]

Originally Posted by malko

Sorry if "student"'s dumb question, but are the CCK the number of memory access by each screen line ?
If yes, the book "Amiga system programmer's guide (Abacus - 1988)" mention 225 memory accesses. Do I have to correct my learning notes ?

CCK is short for color clock(s).

[ross]

Originally Posted by malko

.. but are the CCK the number of memory access by each screen line ?

Basically yes, but not generic memory, only that under the control of Agnus (which is a DMA controller and regulates access to the internal bus: chip memory and 'ranger' memory).

The CPU must obey the Agnus rules if it wants to have access to that type of memory.
4 cycles per line are obligatorily used to refresh this memory and unusable, therefore in PAL, where there are 227 of them, 223 remain usable.
I don't know where Abacus book got the (wrong) number 225... (not valid even in NTSC).