www.virtualacorn.co.uk/forum

My problems with the four year jump have not recurred since I upgraded to select 4 (after Wakefield), from which time I haven't been running SyncClock.

Previously it had jumped on at least the following dates(from my mail/newsgroups records).

Forward four years:
6 May 2007
14 May 2007
3 Jul 2007
9/10 Nov 2007

Back four years:
20 Jan 2008
23 Mar 2008
12 Apr 2008

So it's not very often but has been time consuming when it happens. At least with my latest news server it tells me immediately and I know to look.

It's not conclusively OK with SyncClock disabled, so I'll leave it so for a few more months. I'll post again if any recurrence.

This is with AdjustSA. I haven't noticed it on SE on my laptop, which isn't used a lot.

Thanks for the update. It will be interesting to see if installing RISC OS 6 cures the fault. If so then it's possible that it's a fault with earlier versions of RISC OS. Mind you if that was the case I would have expected more reports of it

Lets see what happens with the new setup and hope the fault was resolved itself (if you see what I mean)

I think the jump by _four_ years must be a red herring and therefore the problem may not be related to the year storage in CMOS (or at least its unrelated to the splitting off of the bottom two bits).
This weekend I left VRPC-SA running and on Sunday at 00:03 my year-jump trap noticed the year change to 2007. The trap is implemented as a modification to TempDir and as soon as the jump is seen it puts the clock back to the correct year so that no damage is done by TempDir attempting to delete old temp directories. In this case there were a number of applications running but all were sitting idle waiting for user input. SyncClock was running.
My hunch is that the least significant decimal digit of the year can change pretty much at random. Some of the date SWIs manipulate the date in BCD format and as far as I can see the culprit must be something that uses BCD otherwise it would not be just the lower digit of the year that is affected.
In any case, it really would be good if SyncClock would correct the year as well as the rest of the time/date. In the meantime if anyone would like the TempDir modification that corrects the year please ask.

This clock problem is proving to be even more interesting but obscure. My modified TempDir prog is showing up further clock problems. On two different VRPC systems (one SE and one SA) new temporary directories have appeared in the TempDir directory. They are named nnJan08 where nn is a day number which varies. Now what happens is that TempDir creates a new temp directory with this naming convention when the date changes. Thie means the clock is changing intermittently and causing these rogue temp directories to be created. Note that the year is unchanged (which means my trap for the year jumping is not being involed) however, the month and day is changing, but its also subsequently changing back to the correct value some time later without any intervention by me.
Looking at an example on this machine I see this directory 07Jan08 but its time stamp is 21:37:56 30 Jul 2008 so its not even changing at midnight like I previously thought it was.
I'm going to instrument the TempDir code further to track these weird clock changes and will report my findings in due course.
Meanwhile I would be interested in liaising with anyone else who would like to help investigate this issue.
Please email mike(at)mhobbs.demon.co.uk.

Drop me an e-mail privately as I have something I would like you to test....

I still haven't had any problems (other than slightly incorrect clock) since the upgrade and disablement of SyncClock.

I've now restored Syncclock to !boot.

I'll let you know if the problem comes back.

I've since had a few incidents when !Organiser has given an alarm at the wrong time, which didn't occur with SyncClock disabled. I'm suspecting a jump and then a correction as I'm not seeing a clock error.

I'll try disabling Organiser and putting my alarms in !Alarm and see what happens.

I did write a version of SyncClock for VRPC, but I'm not sure if the one mentioned is mine or not.

Mine works by regularly reading the Risc PC's hardware clock via I2C, which will cause the emulator to read the host OS's clock, and correcting RISC OS's soft clock, which is normally maintained by interrupts but can suffer accuracy problems on real hardware, and particularly on the emulator which can suspend RISC OS for long periods.

The hardware clock in the Risc PC only provides two bits (0-3) for the year value, so RISC OS has to store the base year in the CMOS memory. If you perform a delete power on, or something causes the emulators cmos.ram file to be corrupted, it may revert to an earlier base year. Each version of RISC OS has a minimum base year encoded in to it, so the clock will normally appear to go back 4 years, but could be 8 or more on earlier OSs.

Some very clock sensitive software may have problems with the clock being updated by large amounts, either via SyncClock or by manual setting, but that has to be taken up with the authors of the software. RISC OS 5's RTCAdjust module does a better job than SyncClock, adjusting the interrupt rate so the clock gradually gets back in sync and stays there, but if large time discrepancies are detected it will jump the clock too.

I had a problem following accidental installation of SyncClock on my RiscPC. I have VirtualRPC-SAAdjust on a PC but it had no SyncClock in its !Boot. I am running RISC OS 6.10 which has RTCAdjust in ROM.

Does it need SyncClock as well? If so, where do I get it?

A copy of SyncClock will be in your old (backed up) boot sequence as created by the RISC OS 6 installer.

I am somewhat facinated about someone accidentally copying SyncClock from a VirtualRPC !Boot to the !Boot on a "real" RiscPC. This would take several operations. Why was it copied over? Because it certainly wouldn't work and might well cause all sorts of problems.

[quote="Aaron"]A copy of SyncClock will be in your old (backed up) boot sequence as created by the RISC OS 6 installer. ...]

Regrettably this is not the case. You may recall that, following your advice, I transferred a previous VRPC installation complete from a laptop to a desktop PC. I did not use the installer.

I asked the questions because it appears from what SyncClock's author has written, here and in a newsgroup, that it might not be required if the module RTCAdjust is present; as it is in RISC OS 6 which I am using with your latest possible VRPC_SAAdjust. Can you please elucidate this?

The saga of the SyncClock module on a real RiscPC is recounted in newsgroup comp.sys.acorn.hardware in thread 'RiscPC Timekeeping' and 'RiscPC Timekeepin - Part 2'.

Soon after I wrote that I remembered I had kept a 'virgin' copy of the HardDisc4 image (ie, before any changes, additions, etc from within VRPC). So I have found the files that were missing. Sorry, for misleading you.

I still would like to know whether I actually need SyncClock which I see is at least 7 years old.

It depends. If your VirtualRPC is up to date with the new HostClock plugin (Jan 2009 HostFS Update) then you probably won't need SyncClock.