Why is Amiga clock never precise?

[ancalimon]

I have tried many clock programs but all of them had the same problem. The only clock program that works precisely is the Clock from utilities drawer.

Seconds are not really seconds. Seconds always pause for a very short time and then suddenly it moves faster to catch "now" only to pause again for a very short time. This goes on and on.

Any reason for this?

[Michael]

On a real machine or under UAE ? Also what specs ?
Chances are your main CPU is loaded and the clock tasks are running at lower priority.

[Toni Wilen]

I think OP means clock GUI display update looks "unstable".

Reason is quite simple, they usually update screen only once/second (or sometimes twice/second) using vblank wait but vblank wait is not synced to clock, it will slowly drift depending on screen mode. Use of CIA e-clock based timer would look more stable.

Clock updates will look like this (of course it is not that bad in real world, this is just short example):

draw clock, clock seconds+1, draw clock, draw clock (it looks like clock stopped for one second), clock seconds+1, draw clock, clock seconds+1, clock seconds+1, draw clock (clock jumped 2 seconds at once) and so on..

[ancalimon]

Thanks for the explanation Toni. Any reason people program clock utilities without using CIA ? For example Dopus5 clock or MCP clock are "unstable".

[mr.vince]

Processing Power. You don't want to spend resources on a clock...

[Thorham]

Originally Posted by Toni Wilen

Use of CIA e-clock based timer would look more stable.

But how will you know the exact frequency of the CIA? Doesn't it change based on the screen's refresh rate?

Originally Posted by mr.vince

Processing Power. You don't want to spend resources on a clock...

I don't think that's a problem.

[Toni Wilen]

Originally Posted by Thorham

But how will you know the exact frequency of the CIA? Doesn't it change based on the screen's refresh rate?

All Amiga models have same CIA timer clock rates, ~709KHz if PAL model and ~715KHz if NTSC model. (Basically it is main DMA clock crystal frequency divided by 40)

CIA TOD counters count h and v-blanks.

I don't think that's a problem.

Use of microhz or e-clock timer.device mode is not recommend for long delays, it means more CPU time is lost for CPU interrupts (every time timer underflows, timer is only 16-bit) and resetting and recalculation of timer registers. But as usual, probably not much, if any difference if CPU is 68020+.

vblank timing is practically free.

[thomas]

VBLANK has a resolution of 50Hz or 60Hz. This is by far enough to wait for the next second. There is no need to waste a CIA for timing. You just don't have to wait stupidly one second every time, but have to calculate the number of ticks needed until the next second arrives. Depending on how much time is needed to draw the graphics this can well be far less than a second.

[ancalimon]

I just realized that something similar also happens on my Windows 7 PC.

Click the clock once to open the analog clock which shows seconds and watch. It seems like default Amiga clock from the Utilities drawer is better than the default Windows one. :P

[Thorham]

Originally Posted by Toni Wilen

All Amiga models have same CIA timer clock rates, ~709KHz if PAL model and ~715KHz if NTSC model.

Not necessarily all Amigas use standard PAL or NTSC modes. I use a customized DblPal driver on my A1200 that's 50.04 hertz according to MonSpecsMui, and 49 hertz according to my monitor's OSD (now what is the true frequency?) . In the past I've even used a custom 96 hertz interlaced mode.

How can you get accurate timing if these vertical rates can vary so much?

Originally Posted by thomas

VBLANK has a resolution of 50Hz or 60Hz. This is by far enough to wait for the next second. There is no need to waste a CIA for timing.

On systems with an RTC you simply count VBlanks and read the clock once per second. Accurate and fast.

[Daedalus]

The thing could be as well that some 3rd party clocks do actually count the Vblanks, but they have a different setup to you. So, if someone programmed their clock to wait 60 frames before redrawing, and you run it on a 50Hz (PAL machine), then it will drift and catch up with itself over the space of around 5-6 seconds.

Using a CIA timer is a terrible idea (though would result in very accurate redraws)... It would tie up that timer so it's not available for use by other things, and some things such as audio decoders etc. do use CIA timers, so you want them available.

I don't know how the Workbench clock works, but perhaps it polls the clock once a frame or once every 5 frames or something, and if the time's changed, it redraws. Doing that every couple of frames wouldn't be that resource hungry and should give near-instant updates.

[thomas]

dos/dos.h defines TICKS_PER_SECOND as 50, no matter if NTSC or PAL. So on a NTSC machine this might run out of sync.

But if you use timer.device UNIT_VBLANK or UNIT_WAITUNTIL you can specify how many seconds and microseconds to wait. Timer.device calculates how many ticks to wait.

[Toni Wilen]

Originally Posted by Thorham

Not necessarily all Amigas use standard PAL or NTSC modes. I use a customized DblPal driver on my A1200 that's 50.04 hertz according to MonSpecsMui, and 49 hertz according to my monitor's OSD (now what is the true frequency?) . In the past I've even used a custom 96 hertz interlaced mode.

As I said above, it is PAL/NTSC model specific, nothing to do with display frequency. Everything would break if CIA timer counting rate would change depending on refresh rate, not even CIA timed module players would work and they obviously do work

(Or did you plan to quote thomas' post, not mine?)

[Thorham]

Originally Posted by Toni Wilen

As I said above, it is PAL/NTSC model specific, nothing to do with display frequency.

Somehow I didn't read the word model.

Originally Posted by Toni Wilen

Everything would break if CIA timer counting rate would change depending on refresh rate

So basically the CIA frequency is fixed per model, and can't change at all? Does that mean that if you have, for example, an NTSC A1200 modified to boot in PAL mode, the CIA frequency is still the NTSC frequency? Any reliable way to determine the model, regardless of modifications (short of using the RTC)?

Originally Posted by Toni Wilen

(Or did you plan to quote thomas' post, not mine?)

I meant your post.

[pandy71]

Originally Posted by Thorham

So basically the CIA frequency is fixed per model, and can't change at all? Does that mean that if you have, for example, an NTSC A1200 modified to boot in PAL mode, the CIA frequency is still the NTSC frequency? Any reliable way to determine the model, regardless of modifications (short of using the RTC)?

VBLANK is variable (fully on each chipset version) also HBLANK can be variable (with difficulties and limitations on ICS/OCS, with some limitations on ECS/AGA) , E clock (source for CIA's) is strictly related to SysClk - E=SysClk/80 (which is usually not variable unless genlock [or similar device] is used), seem that only one relatively stable source for frequency in Amiga is RTC clock but usually 32768Hz quartz oscillators are poor frequency source.

btw - VBLANK in nominal mode is not 50Hz unless bit LACE is active, also overall quartz oscillators accuracy apply to system.

[thomas]

Originally Posted by ancalimon

I just realized that something similar also happens on my Windows 7 PC.

Click the clock once to open the analog clock which shows seconds and watch.

Yes, you are right. Every 13th second the clock hand moves twice as fast as the other 12 seconds.

[ancalimon]

Originally Posted by thomas

Yes, you are right. Every 13th second the clock hand moves twice as fast as the other 12 seconds.

Here it happens every 7th second.

[Toni Wilen]

Originally Posted by Thorham

So basically the CIA frequency is fixed per model, and can't change at all? Does that mean that if you have, for example, an NTSC

Yes. It is hardwired. (Unless there is some weird accelerator board that does really weird things)

A1200 modified to boot in PAL mode, the CIA frequency is still the NTSC frequency?

Yes. AOS timer.device still has correct timing because it checks Agnus/Alice PAL/NTSC model too. I guess if main crystal and Agnus/Alice types are mismatched (for example NTSC crystal and PAL Agnus) timer.device will have slightly wrong timing..

Any reliable way to determine the model, regardless of modifications (short of using the RTC)?

I don't think it is possible, at least without using RTC (which may be too unreliable too). There simply isn't any reference timer that is not based on main crystal.

I guess models that have vsync/power line tick jumper can use power line tick (which clocks CIA TOD timer) as a reference clock but they aren't that common...