Variations in TIME

12 views
Skip to first unread message

tudo...@aol.com

unread,
Aug 10, 2006, 10:03:45 AM8/10/06
to
I seem to have a problem with the TIME variable (centisecond
clock) in that its rate seems to vary. In one application I have it
ran nearly 8% fast and in others it can quite easily run 0.5% fast or
slow. A reset (Ctrl+Brk) seems to sort it out. There have been
occasions when the rate has changed from slow to fast (typically 0.5%)
for no apparent reason during the running of a program. I cannot
detect any programming errors and have checked the accuracy of the
clock with no program running simply by typing PRINT TIME at, say,
five-minute intervals timed with a stopwatch. The last time I did this
there was a consistent error of -0.42%. The machine is an A7000
running BASIC V, version 1.16. I have not checked the accuracy of the
real-time clock, but TIME should be independent of it anyway. I'd be
grateful for any help on this because I can't find iny guidance among
the FAQ's.

Tudor Hughes, Warlingham, Surrey.

David Buck

unread,
Aug 10, 2006, 4:07:55 PM8/10/06
to

Are you running any other software (in BASIC) which is setting the TIME
variable. ISTR BASIC only maintains one copy.

--
David Buck
2D CAD for RISC OS at www.risccad.freeuk.com


tudo...@aol.com

unread,
Aug 10, 2006, 5:27:20 PM8/10/06
to

There is simply one BASIC program running. TIME is called
every 0.2 seconds or so and is converted to a display of "elapsed
time". I set TIME=0 at the start. I have just run the program and in
one state (where it's not doing much) it gained 8 seconds in half an
hour. When the program was doing more it gained 20 seconds in half an
hour. Occasionally the gain rate has been startling (5 seconds a
minute). When I ran it last night it *lost* 10 seconds in half an hour
though this rate depended on how much it was doing and the loss was
less when the program was doing more. On the other hand I have a
program in which TIME seems to work very accurately. I am very puzzled
because some of the variability seems quite random.

Tudor Hughes.

Rob Kendrick

unread,
Aug 10, 2006, 7:09:29 PM8/10/06
to
On Thu, 10 Aug 2006 14:27:20 -0700, tudorhgh wrote:
> I set TIME=0 at the start.

Please, for the love of God, do not do this. A nicer solution to your
problem would be to get the time from the OS via a SWI, and do the maths
on that.

(And if you don't want to do that, take a copy of TIME, and then compare
that to the current TIME when you want to know.)

B.

tudo...@aol.com

unread,
Aug 10, 2006, 9:36:29 PM8/10/06
to

I can't see that it should make any difference what TIME is set
to initially if there is only the one program running. It should
increase at a uniform rate of 100 per second regardless of the initial
setting.
I have run a program for 2 hr 50 m and during that period TIME
gained 20 seconds. I ran the program again and this time it *lost* 6
seconds in half an hour. The program was doing exactly the same in
both cases. On other occasions the error has been negligible over
several hours. In this program TIME is initially set to 100 times the
number of seconds that have elapsed since midnight and TIME is
converted to provide a display of the current time (GMT or BST). In
other words part of the program is a digital clock display, but the
clock is randomly fast or slow. It seems that TIME does not do what is
says on the can for reasons I cannot fathom.
As for using the OS, that may provide an answer, but what is an
SWI? What is causing the variation in the rate of TIME?

Tudor Hughes.

Steven Pampling

unread,
Aug 11, 2006, 3:41:48 AM8/11/06
to
In article <1155260189....@b28g2000cwb.googlegroups.com>,
<tudo...@aol.com> wrote:

> I can't see that it should make any difference what TIME is set
> to initially if there is only the one program running. It should
> increase at a uniform rate of 100 per second regardless of the initial
> setting.

But you can't guarantee that there is only one programme doing this and if
the other programme happens to set TIME to some other arbitrary value what
then?

--

Steve Pampling

andrew

unread,
Aug 11, 2006, 4:39:04 AM8/11/06
to
<tudo...@aol.com> wrote in message
news:1155218625.3...@m73g2000cwd.googlegroups.com...

You are right, TIME is unreliable. I suspect that it is a software
timer maintained by BASIC. This has been the way of TIME since the
BBC micro.

Your best bet is not to rely on it for accuracy, but rather use it
as a guide - much like Microsoft minutes when installing their software,
or using exploder to download something.

You need to expand your system knowledge and come to terms with the OS
provided time handling SWIs (SoftWare Interrupts) - Called by the
BASIC keyword "SYS". There are many knowledgeable people that will,
if proded by the right questions, pretty much lead you through the
task above step by step, just requires the right questions.

A starting point would be:
SYS "OS_ReadMonotonicTime" TO my_time%
which duplicates TIME, so from there to the much more obscure
combination of:
DIMblock% 8
!block%=3
SYS "OS_Word",14,block% TO,block%

And this leaves you with a 5 byte centisecond value in block%
It's up to you how you go about converting or reading specific
values from it.

I would like to have been more help, but I'm working from paper
manuals at the mo. as my RISC OS machine is, um, broken.

Andrew


tudo...@aol.com

unread,
Aug 11, 2006, 8:52:07 AM8/11/06
to

andrew wrote:

Thanks for that, Andrew. At least someone recognises that
TIME is a bit of a box of tricks. Today, ironically, TIME is running
very accurately in both of my programs that use it. They are exactly
the same programs, each doing exactly the same thing as yesterday and
all the other days when TIME has been a bit awry.
I have never dug much into the OS, but your suggestion
doesn't look too fearsome. I assume the 5-byte centisecond value is in
the usual form of 4-byte mantissa (MSB first) followed by the
characteristic. If so it will not be beyond me to convert that to
hours, minutes and seconds.
A rather clumsy way round the problem would be to use TIME$,
possibly, as in :
second% = EVAL(MID$(TIME$,23,2))
minute% = ditto 20
hour% = ditto 17

but this would only give a resolution of one second, which might just
about do.
Of course I am still very puzzled why TIME should be so
variable, particularly as it seem random and I have known it to run
8%(!) fast.
Thanks for your help, and to others.

Tudor Hughes, Warlingham, Surrey.

David Buck

unread,
Aug 11, 2006, 10:26:58 AM8/11/06
to

Consider this...

If you are running two programs, or even the same program twice, and each of
these has within it code to set TIME = 0 and then wait until TIME = value, a
discrepency could occur if the programs were not started exactly on a second
start. ie if the first program was started at an exact second start and the
second at say 1.03 seconds displaced from the first, then the second may be
setting TIME =0 and then counting from there, the first program then looks
for TIME = 1, which it will now see 1.03 seconds after it set TIME = 0.

ie the error will be dependant on the difference between when the programs
started, which, whilst possibly not a random time, may vary.

Justin Fletcher

unread,
Aug 11, 2006, 10:33:50 AM8/11/06
to

I had hoped that someone who knew what they were talking about would reply
to this but clearly that hasn't happened.

TIME within BASIC is a BBC-ism. It uses the system clock (OS_Word 1/2).
About the only useful thing that has been stated on this thread is that
explicitly modifying the TIME variable is destructive to the rest of the
system - it modifies the shared system timer and thus affects every BASIC
program. This is not a fault and is required for backward compatibility
with earlier (BBC) applications.

To correct some misunderstandings by posters...

BASIC does not maintain the timer and has nothing to do with its
operation. The system clock is incremented in line with the monotonic time
and real time clock (albeit in slightly different ways).

Reading the CMOS clock (incorrectly named within most documentation -
read the documentation as 'software RTC clock') using OS_Word 14 will be
ineffectual in comparison to using TIME, as (as been stated above) the
two are incremented together.

The clock is timed by Timer0. Timer0 is a hardware timer which is updated
at 2MHz (that is, 2 million times per second). It is set up such that an
interrupt will be generated every 20000 ticks - that is, an interrupt
occurs 100 times per second (2E6 Hz / 20000 times = 100/second). Thus, if
interrupts are disabled for significant periods the time represented by
the system clock (OS_Word 1/2), interval timer (OS_Word 3/4), RTC clock
(OS_Word 14), monotonic time (OS_ReadMonotonicTime), and ticker events
(OS_CallAfter, OS_CallEvery) will be affected. If the hardware timer does
not actually trigger at a frequency of 2MHz then this timing will be off.

In order to correct for the hardware timer being inaccurate and the
possibility that the clock may be skewed by excessive interrupt disabled
operations, the module RTCAdjust provides a correction to this. The
RTCAdjust module will, over the course of an hour cause the clock to
become re-synchronised to the hardware RTC, if possible. This is achieved
by changing the number of ticks used between interrupts. If the clock is
running fast then the number of ticks per interrupt is increased. If the
clock is running slow then the number of ticks per interrupt is reduced.
Thus, the period of the Timer0 timer may not actually be 20000 at any
given instant.

These corrections are applied hourly, over the course of an hour, but only
if the hardware RTC is not manipulated during that period. The RTC
hardware within the RiscPC and A7000(+) is capable of tracking time to an
accuracy of centiseconds, so this correction can be reasonably accurate.

In summary, then, if 'TIME' in BASIC is exhibiting incorrect values then
you should investigate what is running on the system which would cause the
clock to run slower (it is unlikely that the clock would run faster).
Using the 'alternative' clock reading OS calls is not useful as all values
are controlled simultaneously.

Consult PRM 1 for more details of IRQ handling.

--
Gerph <http://gerph.org/>
... Do you believe in heaven above ? Do you believe in love ?

Darren Salt

unread,
Aug 12, 2006, 9:19:12 AM8/12/06
to
I demand that Justin Fletcher may or may not have written...

[snip]


> Reading the CMOS clock (incorrectly named within most documentation -
> read the documentation as 'software RTC clock')

Software real-time clock clock? Are you sure? :-)

[snip]
--
| Darren Salt | d @ youmustbejoking,demon,co,uk | nr. Ashington, | Toon
| RISC OS, Linux | s zap,tartarus,org | Northumberland | Army
| + Output less CO2 => avoid boiling weather. TIME IS RUNNING OUT *FAST*.

I'd like to, but I've been scheduled for a karma transplant.

Steve Drain

unread,
Aug 11, 2006, 6:04:38 AM8/11/06
to
andrew wrote:

> tudor hughs wrote:
> > I seem to have a problem with the TIME variable (centisecond
> > clock) in that its rate seems to vary.
> You are right, TIME is unreliable. I suspect that it is a software
> timer maintained by BASIC. This has been the way of TIME since the
> BBC micro.

The TIME keyword reads and sets the OS_Word interval timer, which is a
system value and should not really be set by individual programs. I do
not think it is expected to be reliable over longer intervals and is
really obscelescent. A more reliable value is given by the monotonic
timer, which cannot be set, and you must read with the SWI as Andrew
shows below.

> Your best bet is not to rely on it for accuracy, but rather use it
> as a guide

> SYS "OS_ReadMonotonicTime" TO my_time%
> which duplicates TIME

Except that this is a different timer. ;-)

If you are working in BASIC and need no more than a time display you
could use TIME$ to read the real-time clock.

<plug> Basalt changes the action of TIME so that it uses the monotonic
timer and keeps an independent pseudo-variable for each program </plug>

--
; ,', * Basalt * - gives RO 3.10+ versions of BASIC V new and alternative
;,' keywords, dynamic memory for arrays and blocks, new variable types.
;', Legal, fast and simple to use. Freeware - version 0.98ß - 19 Aug 03
,; ',, Steve Drain, Kappa : http://www.users.zetnet.co.uk/kappa/basalt.htm

Justin Fletcher

unread,
Aug 12, 2006, 1:20:31 PM8/12/06
to
On Sat, 12 Aug 2006, Darren Salt wrote:

> I demand that Justin Fletcher may or may not have written...
>
> [snip]
>> Reading the CMOS clock (incorrectly named within most documentation -
>> read the documentation as 'software RTC clock')
>
> Software real-time clock clock? Are you sure? :-)

Absolutely and positively sure. OS_Word 14 reads the software managed copy
of the hardware clock. The two are not synchronised except at startup (or
OS_ResyncTime). Thus it would be incorrect to call it an operation which
read the 'hardware RTC clock' as it does not do so. And it is further
incorrect to be documented as being based on CMOS technology because that
is not necessarily the case for even the hardware implementation which is
read at startup.

My point was not that it's real-time time clock based in software, but
that it's explicitly not required to depend on any particular technology.

--
Gerph <http://gerph.org/>
... It's all in your head, you're living a lie.

Jeremy C B Nicoll

unread,
Aug 14, 2006, 6:03:49 PM8/14/06
to
In article <1155300727....@75g2000cwc.googlegroups.com>,
<tudo...@aol.com> wrote:

> A rather clumsy way round the problem would be to use TIME$,
> possibly, as in :
> second% = EVAL(MID$(TIME$,23,2))
> minute% = ditto 20
> hour% = ditto 17

> but this would only give a resolution of one second, which might just
> about do.

Very clumsy. Consider what happens if the time value changes from one
second to the next, or one minute to the next, between execution of two
of those lines. If you must do that, at least have:

storetime$ = TIME$
second% = EVAL(MID$(storetime$,23,2))
minute% = ....... storetime$ ... etc

(and why use EVAL - what's wrong with VAL ?)

--
Jeremy C B Nicoll, Edinburgh, Scotland - my opinions are my own.

Reply all
Reply to author
Forward
0 new messages