| Posted By
SVS
on 2019-01-15
03:54:04
 |  Realtime clock preservation
As we know, the realtime clock is updated every IRQ call. But during the Basic execution the fetching operations do disable temporarly the IRQ, when switch between ROM/RAM reading. This can result as a loss of updating of the realtime clock.
I measure it in 0,21% (average). Does anybody has other info or measures?
|
|
Posted By
Csabo
on 2019-01-15
11:39:41
| Re: Realtime clock preservation
Are you talking about the TI$ variable? Do you know where that is being updated?
|
|
Posted By
Lavina
on 2019-01-15
13:01:12
 | Re: Realtime clock preservation
Time is relative. 
Seriously, I was very surprised reading this discrepancy.
|
|
Posted By
SVS
on 2019-01-15
13:40:22
| Re: Realtime clock preservation
@Csabo: yes TI, TI$.
TI$ is created from the TI value.
|
|
Posted By
MMS
on 2019-01-15
15:21:55
 | Re: Realtime clock preservation
Poor TED and CPU, the later all the time changes it's frequency...
It's no surprise, it does not really know, what time is it...
sure, it won't fulfill the atomic clock requirements, but anyhow you cannot keep them working so long, as they are fried by themselves 
I think you need THIS in the Plus/4.
Anyone?
https://www.amazon.com/CANADUINO-60kHz-Atomic-Clock-Receiver/dp/B01KH3VEGS
|
|
Posted By
Csabo
on 2019-01-15
18:24:11
| Re: Realtime clock preservation
Right, so TI value - SVS, do you have the place in the ROM that updates this value by any chance?
The reason I'm asking is this: if it's from IRQ, the you're right, every SEI/CLI will affect this, so it's pretty unreliable, especially if there's disk operations. If it's done using the timers though... Well, so that's my idea anyway, perhaps somehow this could be done from BASIC bypassing TI altogether, using one of the 3 timers. Haven't looked more into it though, just an idea.
|
|
Posted By
siz
on 2019-01-16
03:32:13
| Re: Realtime clock preservation
TI and TI$ are definitely updated from raster IRq. I had the impression that only the very necessary parts are enclosed between SEI and CLI so albeit raster IRq-s could be delayed they should occur every time. Perhaps if it's delayed so much that the first IRq (that splits the screen for GRAPHIC 2 and 4 modes) is delayed after the second IRq point that can cause missing clock updates.
|
|
Posted By
SVS
on 2019-01-16
04:48:33
| Re: Realtime clock preservation
@Csabo: the ROM address' involving time are: $9531, $9747, $CF26
$CEF0 (update time); $CFD1 (credits Litwr - adjust time for PAL systems still using 1/60")
I did lots of measures but the results are not linear. Then I'm not sure if the fact is caused by O.S., by Yape, or even by Windows.
|
|
| |
Copyright © Plus/4 World Team, 2001-2024 |
