Re: [cc65] gettimeofday()

From: Karri Kaksonen <karri1sipo.fi>
Date: 2012-01-23 07:38:38
On 01/19/2012 09:15 PM, Ullrich von Bassewitz wrote:
> On Thu, Jan 19, 2012 at 07:04:58AM +0200, Karri Kaksonen wrote:
>> On 01/18/2012 10:25 PM, Ullrich von Bassewitz wrote:
>>
>>      struct currenttime {
>>          unsigned    sec;
>>          unsigned    msec;
>>      };
>>
>>      struct currenttime getcurrenttime (void);
>>
>>
>>
>> I like this approach.
>      unsigned long getticker (void);
>      /* Return the number of milliseconds since some undefined point
>       * in the past
>       */
>

>      /* Read the clock */
>      clock_t Ticks = clock();
>
>      /* Calculate the time used */
>      Ticks = clock() - Ticks;
>      Sec = (unsigned) (Ticks / CLOCKS_PER_SEC);
>      Milli = ((Ticks % CLOCKS_PER_SEC) * 1000) / CLOCKS_PER_SEC;
>

The most practical would be to have an unsigned long that is incremented 
at every IRQ and use CLOCKS_PER_SEC for converting it to milliseconds or 
seconds.

But I assume that clock() is only available in C++.

Machine generated music is also interested in a steady ticker so it 
could build on top of clock() easily without a need for conversions to 
seconds and milliseconds.

What about implementing

typedef clock_t unsigned long;

clock_t clockCounter = 0;

clock_t clock()
{
     return clockCounter;
}

And in the machine dependent library we can then define CLOCKS_PER_SEC 
and the interruptor to increment clockCounter.

This would have a very low overhead and 32 bits would allow us to track 
time for almost two years for the Lynx 75 Hz display rate. Certainly 
enough for any game.

So I would go for implementing clock() and CLOCKS_PER_SEC.

In reality you always need to do some calculations for displaying the 
time so I don't mind doing the conversions from clock() time.
--
Karri

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Mon Jan 23 07:38:51 2012

This archive was generated by hypermail 2.1.8 : 2012-01-23 07:38:57 CET