AmigaOS 4 ms timer ?

Hi,

I want to do a timer function to calculate frame rate and others functions duration.
But I didn't find in autodocs something that can be useful.

I'd like to get internal timer (if sensitivity is 1/2ms).

Any idea ?

Thank you.

Regards,
Freddix / AmiDARK

@freddix

timer.device has functions like GetSysTime() check the autodocs for that.

keep in mind that it's a device not a libray so opening is a little different.

@broadblues:
I've seen this but impossible to find doc about Timeval structure anywhere ...

@freddix

SDK:include/include_h/devices/timer.h

Quote:

@ZeroG
Thank you :)

But now, can someone explain me how I can use a device ?
I have found no sample over the net or in the SDK to show me how to ...

Regards,
Freddix / AmiDARK

@freddix

Open the device using OpenDevice() and then get the library base pointer and interface. Something like:

OpenDevice("timer.device",UNIT_WAITUNTIL,(struct IORequest *)ioreq,0);
TimerBase = (struct Device *)ioreq->Request.io_Device;
ITimer = (struct TimerIFace *)GetInterface((struct Library *)TimerBase,"main",1,NULL);

NB: ioreq must be allocated with AllocSysObjectTags

@freddix

I don't have a lot of time to explain at the moment but here some source code that handles opening timer.device

m_ITimer below is of type stuct ITimerIFace, once you have it you can call ITimer->GetSysTime() to get the current time etc

@broadblues
Thank you.
I will learn from your sample :)

Regards;
Freddix / AmiDARK

@BroadBlues:

Hi, can you add the definition for your sample because I get many errors using it with m_timerPort, m_timersigflag, m_timerRequest, m_iITimer not defined ...

Regards,
Freddix / AmiDARK

@freddix

#include <devices/timer.h>



#include <proto/exec.h>
#include <prot/timer.h>


struct TimerIFace * m_ITimer;


struct MsgPort *m_timerPort;

ULONG m_timersigflag;
ULONG m_inputsigflag;
ULONG m_windowsigflags;

BOOL m_timerFirst;
struct TimeRequest *m_timerRequest;
struct Device *TimerBase;


those are the relavent lines I think

BTW I wouldn't copy my naming scheme that's just because the variable are members of a C++ class, rather than globals, and it makes it easire to track in the original code, to which I added this code too, (it;s part of blender's system interface GHOST) so drop all 'm_' bits

@broadblues
I understand.

I have removed the m_ on var(s) beginning.
It compiles :)
I've added my function to get timer and to calculate frame rate ...
Is there a more precise timer calculation than ms ?

Thank you Broadblues

Regards,
Freddix / AmiDARK

@freddix

UNIT_MICROHZ has ?s accuracy.

For higher accuracy than that you can use UNIT_ECLOCK but in this case you will get a struct EClockVal rather than a struct TimeVal. The EClock frequency is stored in ((struct ExecBase *)SysBase)->ex_EClockFrequency. On my ?A1-C it is 33333333 Hz which according to my calculator should provide an accuracy of about 0.03 ?s.

1 ?s = 0.001 ms
1 ms = 0.001 s

@salass00
Ok I'll check this

Thanks.

I've written an example to use a timer (I will add it on gurumed.net) but I have 2 questions regarding what was said in this thread :

Chris : You wrote "ioreq must be allocated with AllocSysObjectTags". What is wrong with CreateIORequest even if I understand using AllocSysObjectTags is more compliant with the updated API of OS4 ?
CreateIORequest is not marked as deprecated in autodocs.

broadblues : You wrote "SetSignal(0L,m_timersigflag)", is it mandatory ? What is the exact behaviour of this call ?

@corto

Quote:
Nothing wrong IMHO, CreateIORequest might even be using ASOT_IOREQUEST internally.

Quote:
I wonder too, the signal mask is already cleared by the call to WaitIO().

@centaurz

It's needed in this case, as there is a high likelyhood that the IO is over before the WaitIO call and thence Wit doesn't get called. Resulting in a program exited with unfreed signals error

From the autodocs:

Quote:

@corto

AllocSysObjectTags does resource tracking, whereas CreateIORequest does not. It is better to use the new functions where possible. I should have said "should" rather than "must" I admit.

@salass00

Quote:

No, this has not been exactly correct since AmigaOS 2.x. While the old AmigaOS 1.x documentation explains that UNIT_VBLANK timing accuracy is coarser than UNIT_MICROHZ, this explanation only holds for the timer.device versions available in AmigaOS 1.x.

With AmigaOS 2.x the source that drives the timer.device time keeping was switched, yielding much higher accuracy in excess of what UNIT_MICROHZ could deliver in AmigaOS 1.x. In effect, the same source drives UNIT_VBLANK, UNIT_MICROHZ and UNIT_ECLOCK. There is no difference in accuracy between UNIT_VBLANK and UNIT_MICROHZ.

The exception is UNIT_ECLOCK. Since it does not use seconds/microseconds values for time intervals, you can go beyond microsecond accuracy. In practice, however, this may make little difference because task scheduling will tend to get in the way and skew your delay times

UNIT_ECLOCK is really useful only if you want to measure time differences with great accuracy.

Incidentally, if you use the EClock timer, you should not peek SysBase->ex_EClockFrequency, but use timer.device/ReadEClock() instead. This is because SysBase->ex_EClockFrequency may be set to a legacy value on AmigaOS 4.x while the actual EClock frequency returned and referenced by timer.device/ReadEClock() may be much, much higher.