Organiser and Alarm thinks its 2012
Brian
Switching on the machine today at 1.56 a.m this Iyonix 5.14 has jumped
straight to 2012 !
Its keen.
So Organizer( 2.04) told me of everyone's birthday for the next couple
of years.
Odd how the clock/Alarm (2.79) jumped ahead?
Brian
--
Check out Brian's pics at:
www.flickr.com/photos/httpflickrcomphotosbrian
David
Brian <brfe...@orpheusmail.co.uk> wrote:
> Happy New Year !
> Switching on the machine today at 1.56 a.m this Iyonix 5.14 has jumped
> straight to 2012 !
> Its keen.
> So Organizer( 2.04) told me of everyone's birthday for the next couple
> of years.
> Odd how the clock/Alarm (2.79) jumped ahead?
> Brian
Similar version - but I'm in 2010!
Happy new year(s)!
--
Dave Wisnia, Leeds, UK
Brian
Brian <brfe...@orpheusmail.co.uk> wrote:
> Mmmm.
> Both Alarm and Organizer thinks its Sunday 1st Jan 2012.
> Also now my news is getting deleted from Messenger because I only
> keep the items for x amount of time.
> Bloody Hell !
Hi
Even after shutting down the machine and re-starting the machine says
its 1st Jan 2012 when I run !Alarm and of course the apps think it is.
What the hell went wrong here ?
Never had a problem before in all my years or even during BST
switching.
Ian Hamilton
Brian <brfe...@orpheusmail.co.uk> wrote:
> In message <3152834a52....@brferris.orpheusmail.co.uk>
> Brian <brfe...@orpheusmail.co.uk> wrote:
> > Both Alarm and Organizer thinks its Sunday 1st Jan 2012.
> > Also now my news is getting deleted from Messenger because I only
> > keep the items for x amount of time.
> > Bloody Hell !
> Even after shutting down the machine and re-starting the machine says
> its 1st Jan 2012 when I run !Alarm and of course the apps think it is.
> What the hell went wrong here ?
> Never had a problem before in all my years or even during BST
> switching.
I had exactly the same issue but only on the first boot. Very odd.
Ian
--
Ian Hamilton (Iyonix RO5) http://www.hamiltoni.pwp.blueyonder.co.uk/
Dr Peter Young
> Happy New Year !
> Switching on the machine today at 1.56 a.m this Iyonix 5.14 has jumped
> straight to 2012 !
> Its keen.
> So Organizer( 2.04) told me of everyone's birthday for the next couple
> of years.
> Odd how the clock/Alarm (2.79) jumped ahead?
> Brian
This has also been reported on the Iyo list. I can only say that here
it's definitely 2010, with nearly the same setup; the only difference
is that I don't use Alarm.
With best wishes,
Peter.
--
Peter, \ / \ Prestbury, Cheltenham, Glos. GL52
Anne \ / __ __ \ England.
and / / \ | | |\ | / _ \ http://pnyoung.orpheusweb.co.uk
family / \__/ \_/ | \| \__/ \______________ pny...@ormail.co.uk.
Ian Hamilton
Matthew Phillips <mn...@sinenomine.freeserve.co.uk> wrote:
> In message <3152834a52....@brferris.orpheusmail.co.uk>
> on 1 Jan 2012 Brian wrote:
> > Mmmm.
> > Both Alarm and Organizer thinks its Sunday 1st Jan 2012.
> > Also now my news is getting deleted from Messenger because I only
> > keep the items for x amount of time.
> > Bloody Hell !
> I'm on RISC OS 5.13. Don't have Organizer installed on this machine
> but we do have Alarm running at start up.
It's not Organizer or Alarm causing it, they just show the result.
> I was wondering whether the NTP time server I am using is the problem,
> but on running FreeTime manually just now it picked up the correct time
> and gave a warning about the time being 63072000 seconds fast, wanting
> me to confirm before setting the clock, so FreeTime and an NTP server
> cannot have been the culprit here.
The problem only shows up if the NTP time server pickup doesn't work
(internet down or NTP pickup not running), they corrects the problem
before the applications are run. I suspect all machines are having the
date changed to 2012 but those running the NTP time pickup might not
realise it yet.
> Also the RISC PC is unaffected.
> Most of my newsgroup messages have been deleted, including those I had
> marked for attention. Bother!
It's a major headache as it breaks everything.
Matthew Phillips
on 1 Jan 2012 Matthew Phillips wrote:
> In message <3152834a52....@brferris.orpheusmail.co.uk>
> on 1 Jan 2012 Brian wrote:
>
> > Mmmm.
> > Both Alarm and Organizer thinks its Sunday 1st Jan 2012.
> > Also now my news is getting deleted from Messenger because I only
> > keep the items for x amount of time.
> > Bloody Hell !
>
> I'm on RISC OS 5.13. Don't have Organizer installed on this machine but we
> do have Alarm running at start up.
>
> I was wondering whether the NTP time server I am using is the problem, but
> on running FreeTime manually just now it picked up the correct time and
> gave a warning about the time being 63072000 seconds fast, wanting me to
> confirm before setting the clock, so FreeTime and an NTP server cannot have
> been the culprit here.
>
> Also the RISC PC is unaffected.
>
> Most of my newsgroup messages have been deleted, including those I had
> marked for attention. Bother!
After a reboot, the clock resets to 2012 again. This happens even if I do
not run Alarm at bootup. I think I will try running the machine without
!Boot altogether to see if that makes any difference: that should indicate
whether it's an OS problem.
As a precaution, I have set my default group expiry in Messenger to 1000 days
for the time being.
--
Matthew Phillips
Dundee
Matthew Phillips
on 1 Jan 2010 Matthew Phillips wrote:
> After a reboot, the clock resets to 2012 again. This happens even if I do
> not run Alarm at bootup. I think I will try running the machine without
> !Boot altogether to see if that makes any difference: that should indicate
> whether it's an OS problem.
OK, I've tested this carefully now.
1. I reset the date to 2010 by running FreeTime.
2. Checked the time with *time: it was 1st January 2010.
3. Renamed !Boot on the hard disc to !BootOld
4. Restarted Iyonix by Ctrl-Shift-F12 and hitting Return to restart.
5. Error that !Boot could not be found: clicked Continue.
6. F12 and *time -- the date had changed back to 2012.
7. Renamed !BootOld back to !Boot
So it's definitely something in ROM.
We're on RISC OS 5.13 (23-Feb-07).
--
Matthew Phillips
Dundee
James Lampard
> Switching on the machine today at 1.56 a.m this Iyonix 5.14 has jumped
> straight to 2012 !
> Its keen.
> So Organizer( 2.04) told me of everyone's birthday for the next couple
> of years.
> Odd how the clock/Alarm (2.79) jumped ahead?
Hi everyone,
I have done most of the alterations to the ROOL version of Alarm since
it has been made available from them.
Running the latest development version on my RiscPC I haven't seen any
jump ahead to 2012.
Thus I don't believe it's Alarm causing the problem.
--
James.
To reply use james underline lampard at talk 21 dot com
Ian Hamilton
<87f682d6-72a2-4903...@a32g2000yqm.googlegroups.com>,
James Lampard <dontrep...@mailinator.com> wrote:
> > Happy New Year !
> > Switching on the machine today at 1.56 a.m this Iyonix 5.14 has jumped
> > straight to 2012 !
[Snip]
> I have done most of the alterations to the ROOL version of Alarm since
> it has been made available from them.
> Running the latest development version on my RiscPC I haven't seen any
> jump ahead to 2012.
> Thus I don't believe it's Alarm causing the problem.
It's not Alarm causing it. It does appear to be Iyonix specific.
Does anyone have an Iyonix without the problem? Booting while not
connected to the internet will demonstrate the fault.
Dr Peter Young
> In article
> <87f682d6-72a2-4903...@a32g2000yqm.googlegroups.com>,
> James Lampard <dontrep...@mailinator.com> wrote:
>>> Happy New Year !
>>> Switching on the machine today at 1.56 a.m this Iyonix 5.14 has jumped
>>> straight to 2012 !
> [Snip]
>> I have done most of the alterations to the ROOL version of Alarm since
>> it has been made available from them.
>> Running the latest development version on my RiscPC I haven't seen any
>> jump ahead to 2012.
>> Thus I don't believe it's Alarm causing the problem.
> It's not Alarm causing it. It does appear to be Iyonix specific.
> Does anyone have an Iyonix without the problem?
Yes, and I run NetTime, and it's been firmly 2010 here.
Brian
Another result of this is that if you don't reset the date back each
time getting into some websites where you have to log into don't seem
to like you ! Or indeed complain about the time difference. Of course
when you shutdown you have to re-set the date again when you boot up.
:(
Frank de Bruijn
Dr Peter Young <pny...@ormail.co.uk> wrote:
> On 1 Jan 2010 Ian Hamilton <Ian.Ha...@AAUG.net> wrote:
> > Does anyone have an Iyonix without the problem?
> Yes, and I run NetTime,
In that case I think you can safely assume that you haven't and NetTime
makes you believe you have. :-)
Regards,
Frank
Ian Hamilton
> > In article
> > <87f682d6-72a2-4903...@a32g2000yqm.googlegroups.com>,
> > James Lampard <dontrep...@mailinator.com> wrote:
> >>> Happy New Year ! Switching on the machine today at 1.56 a.m this
> >>> Iyonix 5.14 has jumped straight to 2012 !
> > [Snip]
> >> I have done most of the alterations to the ROOL version of Alarm
> >> since it has been made available from them.
> >> Running the latest development version on my RiscPC I haven't seen
> >> any jump ahead to 2012.
> >> Thus I don't believe it's Alarm causing the problem.
> > It's not Alarm causing it. It does appear to be Iyonix specific.
> > Does anyone have an Iyonix without the problem?
> Yes, and I run NetTime, and it's been firmly 2010 here.
You do have the problem, NetTime just masks it. If there are any Iyonix
machines that don't show the fault that might help with a solution.
Disconnecting from the Internet and rebooting demonstrates the fault.
Frank de Bruijn
Barry Allen (news) <evan...@onetel.net.uk.invalid> wrote:
> I had NetTime, or at least I thought I had but it apparently was not
> being loaded at Boot time. I first of all had it in:-
> !Boot.Resources.!System.500.Modules.Network
> Then:-
> !Boot.Resources.!System.310.Modules.Network
> And In:-
> !Boot.Choices.Internet.User
> I have:-
> sysctl -ew net.inet.tcp.rfc1644=0
> Set Inet$NTPServer uk.pool.ntp.org
> RmEnsure NetTime 0 RmLoad System:Modules.Network.NetTime
> But the NetTime module was not loading. I have now put NetTime in
> !Boot.Choices.Boot.PreDesk which now seems to load it OK.
> Any ideas why the NetTime module was not being loaded with the other
> setup?
Sorry, no idea. I actually put it in !Boot.Choices.Boot.PreDesk years
ago and had a couple of lines in an obey file to set it up properly [1].
That did work but just not early enough in the boot sequence. I have now
moved these lines to !Boot.Choices.Internet.User and as far as I can
tell by the files in my SysLogs directory, nothing important gets to see
the 2012 date and neither does Organizer.
Regards,
Frank
[1] These lines:
Set Inet$NTPServer nl.pool.ntp.org
NetTime_PollInterval 3600
NetTime_Kick
Dr Peter Young
> In article <d1d2c2d25...@pnyoung.ormail.co.uk>,
> Dr Peter Young <pny...@ormail.co.uk> wrote:
>> On 1 Jan 2010 Ian Hamilton <Ian.Ha...@AAUG.net> wrote:
>>> In article
>>> <87f682d6-72a2-4903...@a32g2000yqm.googlegroups.com>,
>>> James Lampard <dontrep...@mailinator.com> wrote:
>>>>> Happy New Year ! Switching on the machine today at 1.56 a.m this
>>>>> Iyonix 5.14 has jumped straight to 2012 !
>>> [Snip]
>>>> I have done most of the alterations to the ROOL version of Alarm
>>>> since it has been made available from them.
>>>> Running the latest development version on my RiscPC I haven't seen
>>>> any jump ahead to 2012.
>>>> Thus I don't believe it's Alarm causing the problem.
>>> It's not Alarm causing it. It does appear to be Iyonix specific.
>>> Does anyone have an Iyonix without the problem?
>> Yes, and I run NetTime, and it's been firmly 2010 here.
> You do have the problem, NetTime just masks it.
If it ain't broke, don't fix it :-)
Or rather, if it works I can live with it.
Vince M Hudd
> Happy New Year ! Switching on the machine today at 1.56 a.m this Iyonix
> 5.14 has jumped straight to 2012 !
As James has said, the problem isn't with Alarm (as the subject suggests) -
and nor is it with Organiser. The problem isn't with software running on
RISC OS 5.xx on the Iyonix - the problem is either with the OS itself or,
perhaps, the hardware(?)
The problem *seems* to be that, from 2010, certain changes to the time will
cause the year to be moved on by 2 (as seen at the next reboot): it isn't a
one off thing. Examples:
* Changing the time - including setting or unsetting BST - will trigger the
2 year increment.
* Changing the year (to correct it) will trigger the 2 year increment.
* The year rolling over at midnight on 31/12/any-year-from-2009 will
trigger the 2 year increment.
* Changing other aspects of the date (ie day/month) do not trigger the 2
year increment.
* The clock's natural changes - other than the year rolling over - do not
trigger the 2 year increment.
* The bug causing this 2 year increment to occur doesn't itself then trigger
the 2 year increment (IYSWIM).
Caveat: I've only tried a few examples of the changes described to see what
happens - it could be that I've just fluked onto instances that do or don't
trigger this problem, but they do seem to be consistent.
--
Vince M Hudd - Soft Rock Software
http://www.softrock.co.uk
http://misc.vinceh.com
Matthew Phillips
(Follow-ups set to csa.programmer, as we need some programmers to look into
this!)
Our experiments here were confined to setting the year (via Alarm) and
resetting the Iyonix and seeing what the clock said afterwards, so it's
really interesting seeing all the rest of this testing above.
From our testing, we discovered that if you set the year and date to
anything, it worked fine until the machine was rebooted. But then if the
year was in an odd-numbered decade, after reboot the year would be shown two
years on from what it should have been.
For example, set the date to 1/1/2020 and reset the Iyonix. No problem.
Set the date to 1/1/2010 to 31/12/2019 or 1/1/2030 to 31/12/2039 or indeed
1/1/1990 to 31/12/1999 and reset the Iyonix, and the year will magically have
increased by two, but doesn't do so *again* after resetting a further time.
I suspect this means that the real time hardware clock and the CMOS soft copy
are out of kilter. The soft copy is what is used by the OS in all cases, as
far as I can see, except at reset, when the soft copy is read from the
hardware clock.
It also must be re-read when setting the time or BST flag.
--
Matthew Phillips
Dundee
Roger Darlington
> On 1 Jan 2010 Ian Hamilton <Ian.Ha...@AAUG.net> wrote:
>
>> In article <d1d2c2d25...@pnyoung.ormail.co.uk>,
>> Dr Peter Young <pny...@ormail.co.uk> wrote:
>>> On 1 Jan 2010 Ian Hamilton <Ian.Ha...@AAUG.net> wrote:
>
>>>> In article
>>>> <87f682d6-72a2-4903...@a32g2000yqm.googlegroups.com>,
>>>> James Lampard <dontrep...@mailinator.com> wrote:
>>>>>> Happy New Year ! Switching on the machine today at 1.56 a.m this
>>>>>> Iyonix 5.14 has jumped straight to 2012 !
>
>>>> [Snip]
>
>
>>>>> I have done most of the alterations to the ROOL version of Alarm
>>>>> since it has been made available from them.
>
>>>>> Running the latest development version on my RiscPC I haven't seen
>>>>> any jump ahead to 2012.
>
>>>>> Thus I don't believe it's Alarm causing the problem.
>
>>>> It's not Alarm causing it. It does appear to be Iyonix specific.
>
>>>> Does anyone have an Iyonix without the problem?
>
>>> Yes, and I run NetTime, and it's been firmly 2010 here.
>
>> You do have the problem, NetTime just masks it.
>
> If it ain't broke, don't fix it :-)
>
> Or rather, if it works I can live with it.
Until the internet is down and you suddenly find whole hoards of files
have been automatically deleted ;-(
>
> With best wishes,
>
> Peter.
>
--
Cheers
Roger
Feel rich. Smoke a diamond in your kimberlite pipe
Bryn Evans
> So it's definitely something in ROM.
> We're on RISC OS 5.13 (23-Feb-07).
I don't have an Iyonix ! So excuse me butting in -
*IF* This fault ONLY occurs with RO 5.13, AND 23Feb2007 is the
copyright date of the rom AND this is the date to which the clock
reverts with a PowerOn/Delete reset -
THEN the problem is that the ROM code has got a scrambled
read of the YEAR data lines in it - Crossing the 2 and 4
data reads would give this error. Extrapolate forward to test.
(like maybe trying to be in 2013 will keep jumping to 2011 ?)
I offer this expanation, but no solution, based on experience with
a reference clock used on a Satellite comms station, where a Rat
widdled on the data connector and shorted a 1 data line to always
on, giving 75 day months :(
--
|)����[
|)ryn [vans mail to - Bryn...@bryork.freeuk.com
Dr Peter Young
> On 1 Jan 2010, Dr Peter Young wrote:
>> On 1 Jan 2010 Ian Hamilton <Ian.Ha...@AAUG.net> wrote:
>>
>>> In article <d1d2c2d25...@pnyoung.ormail.co.uk>,
>>> Dr Peter Young <pny...@ormail.co.uk> wrote:
[snip]
>>>> Yes, and I run NetTime, and it's been firmly 2010 here.
>>
>>> You do have the problem, NetTime just masks it.
>>
>> If it ain't broke, don't fix it :-)
>>
>> Or rather, if it works I can live with it.
> Until the internet is down and you suddenly find whole hoards of files
> have been automatically deleted ;-(
I did think of that, and now have ClockFixer in Boot > Configuration >
Run at start, which should cover that eventuality. "If you're not
paranoid, then you haven't fully understood the situation". :-)
With best wishes,
Peter.
--
Ben Crick
<Ian.Ha...@AAUG.net> wrote:
> Does anyone have an Iyonix without the problem? Booting while not
> connected to the internet will demonstrate the fault.
Yes, my Iyo is faultless in this regard.
Ben
--
_ __________________________________________
/ \._._ |_ _ _ /' Orpheus Internet Services
\_/| |_)| |(/_|_|_> / 'Internet for Everyone'
_______ | ___________./ http://www.orpheusinternet.co.uk
Revd Ben Crick BA CF <ben.crick[at]argonet.co.uk> ZFC Os
232 Canterbury Road, Birchington on sea, Kent CT7 9TD (UK)
Acorn RPC700 Kinetic RO 4.03 with Castle Iyonix RO 5.13 Ethernet
* Watch your step carefully; everyone else does.
Dave Higton
<87f682d6-72a2-4903...@a32g2000yqm.googlegroups.com>
James Lampard <dontrep...@mailinator.com> wrote:
> I have done most of the alterations to the ROOL version of Alarm since
> it has been made available from them.
Is the format of !Alarm's alarm files published anywhere?
Is is possible to add an alarm programmatically to !Alarm?
Dave
James Lampard
> In message
> <87f682d6-72a2-4903-a8cc-25c52bf51...@a32g2000yqm.googlegroups.com>
> James Lampard <dontreplytot...@mailinator.com> wrote:
>
> > I have done most of the alterations to the ROOL version of Alarm since
> > it has been made available from them.
>
> Is the format of !Alarm's alarm files published anywhere?
Yes.
> Is is possible to add an alarm programmatically to !Alarm?
Sort of. It depends what you mean by an Alarm. If you mean an
'application alarm' then it's easy: just send the Message_AlarmSet
(&500) to Alarm and at the apropriate time it will broadcast
Message_AlarmGoneOff (&501) which your app should acknowledge.
If you mean a bog standard alarm that's a little bit more complicated.
The only way I can think of is to create an alarm file containing your
alarm and then Filer_Run it. This will cause it to be mergered into
the main database.
This will work great if you are using the "Save automatically" option
to an alarm file in Choices. If however you currently have no alarm
file, then the dummy file will become the default. :(
Bryn Evans
> In a mad moment - Matthew Phillips mumbled :
>> So it's definitely something in ROM.
>> We're on RISC OS 5.13 (23-Feb-07).
> I don't have an Iyonix ! So excuse me butting in -
> *IF* This fault ONLY occurs with RO 5.13, AND 23Feb2007 is the
> copyright date of the rom AND this is the date to which the clock
> reverts with a PowerOn/Delete reset -
> THEN the problem is that the ROM code has got a scrambled
> read of the YEAR data lines in it - Crossing the 2 and 4
> data reads would give this error. Extrapolate forward to test.
> (like maybe trying to be in 2013 will keep jumping to 2011 ?)
After some more thought -
I predict that this error will cause Iyonix clocks
to jump forward or backward by two years in
2010, 2011, 2013, then again in 2018, etc.
I have tried a fix (on an RPC to test for function)
Add an 'Obey' file to the 'Boot.PreDesk' sequence
Call it " !!2010 " (Note the double ! NO quotes)
The file contains one line - *Set Sys$Year 2010
This file will need to be updated for each of the
predicted troublesome years. I hope this helps
but don't blame me if it don't.
I do NOT have access to an Iyonix.
Vince M Hudd
> In a mad moment - Bryn Evans mumbled :
> > YEAR data lines in it - Crossing the 2 and 4 data reads would give this
> > error. Extrapolate forward to test. (like maybe trying to be in 2013
> > will keep jumping to 2011 ?)
> After some more thought -
> I predict that this error will cause Iyonix clocks to jump forward or
> backward by two years in
> 2010, 2011, 2013, then again in 2018, etc.
That isn't the problem - it's a software problem. Both Matthew Phillips and
I have come up with temporary (and imperfect) fixes, and Adrian Lees has now
submitted a proper solution to RISC OS Open.
James Lampard
[snip]
> After some more thought -
>
> I predict that this error will cause Iyonix clocks
> to jump forward or backward by two years in
> 2010, 2011, 2013, then again in 2018, etc.
>
> I have tried a fix (on an RPC to test for function)
>
> Add an 'Obey' file to the 'Boot.PreDesk' sequence
> Call it " !!2010 " (Note the double ! NO quotes)
>
> The file contains one line - *Set Sys$Year 2010
>
> This file will need to be updated for each of the
> predicted troublesome years. I hope this helps
> but don't blame me if it don't.
>
> I do NOT have access to an Iyonix.
According to http://www.iconbar.com/forums/viewthread.php?threadid=11304#12637
this bug has now been fixed. Panic over.
Dave Higton
James Lampard <dontrep...@mailinator.com> wrote:
> On 1 Jan, 21:39, Dave Higton <davehig...@dsl.pipex.com> wrote:
> > In message
> > <87f682d6-72a2-4903-a8cc-25c52bf51...@a32g2000yqm.googlegroups.com>
> > � � � � � James Lampard <dontreplytot...@mailinator.com> wrote:
> >
> > > I have done most of the alterations to the ROOL version of Alarm since
> > > it has been made available from them.
> >
> > Is the format of !Alarm's alarm files published anywhere?
>
> Yes.
>
> > Is is possible to add an alarm programmatically to !Alarm?
>
> Sort of. It depends what you mean by an Alarm. If you mean an
> 'application alarm' then it's easy: just send the Message_AlarmSet
> (&500) to Alarm and at the apropriate time it will broadcast
> Message_AlarmGoneOff (&501) which your app should acknowledge.
That's the one I want - thanks. I really wasn't aware that this
method existed.
It also means I don't need to know !Alarm's file format.
Dave
Alex Cessford
Ian Hamilton <Ian.Ha...@AAUG.net> wrote:
> In article
> <87f682d6-72a2-4903...@a32g2000yqm.googlegroups.com>,
> James Lampard <dontrep...@mailinator.com> wrote:
>>> Happy New Year !
>>> Switching on the machine today at 1.56 a.m this Iyonix 5.14 has jumped
>>> straight to 2012 !
> [Snip]
>> I have done most of the alterations to the ROOL version of Alarm since
>> it has been made available from them.
>> Running the latest development version on my RiscPC I haven't seen any
>> jump ahead to 2012.
>> Thus I don't believe it's Alarm causing the problem.
> It's not Alarm causing it. It does appear to be Iyonix specific.
There have been lots of responses to this problem, (3 or 4 from me),
on the Iyo list. More than one of them report that it's happened on
RiscPCs too, so it would appear that it is not Iyonix specific after
all.
I have an Iyonix, RISC OS 5.13 and it did happen to me. I am not at
all technical, but as far as I can judge, on my machine at least, the
problem seems to have originated from NetTime, a Module file located
in:
!Boot.Resources.!System.500.Modules.Network
Alan Adams and Brian Howlett cured it here for me, by suggesting that
I add a couple of lines at the bottom of the "User" Obey file,
located in:
!Boot.Choices.Internet
as follows:
Set Inet$NTPServer uk.pool.ntp.org
RMEnsure NetTime 0.35 RMLoad System:Modules.Network.NetTime
Just copy this bit into there and re-boot - that solved it for me.
> Does anyone have an Iyonix without the problem? Booting while not
> connected to the internet will demonstrate the fault.
> Ian
For your interest, I also have a RiscBOOK Asus EeePC running Virtual
Acorn Adjust. I do not have the NetTime module on there, and I did not
experience the 2012 clock problem at all with that.
To finish, a disclaimer! As I said, I am not in the least technical.
The above worked for me, but perhaps proceed with caution if you are
following my advice - lots of others are better qualified, I'm only
trying to be helpful.
--
Alex.
Steve Fryatt
<eada94d45...@cessford.org.uk>:
> In message <50d2c05950I...@AAUG.Net>
> Ian Hamilton <Ian.Ha...@AAUG.net> wrote:
[RISC OS 5 fails to read the hardware RTC data correctly when the year hits
particular values]
> > It's not Alarm causing it. It does appear to be Iyonix specific.
>
> There have been lots of responses to this problem, (3 or 4 from me), on
> the Iyo list. More than one of them report that it's happened on RiscPCs
> too, so it would appear that it is not Iyonix specific after all.
The cause of the problem has been identified, and is a bug in RISC OS 5
where it reads the date from the hardware Real Time Clock. A fix has been
supplied to ROOL for including in a future OS update, and two workarounds
have been made available in the meantime consiting of short BASIC programs
to modify the time when the machine boots.
From what I've read, it only affects the Iyonix (as it's a bug with the way
that RISC OS 5 interacts with hardware unique to the Iyonix motherboard).
> I have an Iyonix, RISC OS 5.13 and it did happen to me. I am not at all
> technical, but as far as I can judge, on my machine at least, the problem
> seems to have originated from NetTime, a Module file located in:
> !Boot.Resources.!System.500.Modules.Network
No. NetTime did *not* cause the problem. The presence of (a corrctly
configured) NetTime (which yours wasn't to start with) *masked* the problem
so that it didn't show up.
> Alan Adams and Brian Howlett cured it here for me, by suggesting that I
> add a couple of lines at the bottom of the "User" Obey file, located in:
> !Boot.Choices.Internet
>
> as follows:
>
> Set Inet$NTPServer uk.pool.ntp.org RMEnsure NetTime 0.35 RMLoad
> System:Modules.Network.NetTime
>
> Just copy this bit into there and re-boot - that solved it for me.
This just made NetTime work, and so masked the problem.
For a variety of reasons (as detailed here and on the Iyonix list), relying
on this is not a good idea. If the network isn't present when the machine
boots, or the NTP server isn't available, then your machine will once again
think it's 2012.
Until an OS fix comes out, install either Vince Hudd's or Matthew Philips'
utilities to correct the year when the system starts.
--
Steve Fryatt - Leeds, England
Jeremy Nicoll - news posts
> For your interest, I also have a RiscBOOK Asus EeePC running Virtual
> Acorn Adjust.
More to the point, it runs Windows. Clocks on PCs are notoriously
unreliable too, and there's any number of Windows apps which talk to NTP
servers etc to align the PC clocks with reality.
VA (etc) are just application as far as Windows is concerned. Certainly on
my Windows-running laptop I use a NTP-checking program to keep the laptop's
clock right. VRPC just asks Windows for the time.
--
Jeremy C B Nicoll - my opinions are my own.
Email sent to my from-address will be deleted. Instead, please reply
to newsre...@wingsandbeaks.org.uk replacing "nnn" by "284".
Alex Cessford
Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> On 5 Jan, Alex Cessford wrote in message
> <eada94d45...@cessford.org.uk>:
>> In message <50d2c05950I...@AAUG.Net>
>> Ian Hamilton <Ian.Ha...@AAUG.net> wrote:
> [RISC OS 5 fails to read the hardware RTC data correctly when the year hits
> particular values]
>>> It's not Alarm causing it. It does appear to be Iyonix specific.
>>
>> There have been lots of responses to this problem, (3 or 4 from me), on
>> the Iyo list. More than one of them report that it's happened on RiscPCs
>> too, so it would appear that it is not Iyonix specific after all.
> The cause of the problem has been identified, and is a bug in RISC OS 5
> where it reads the date from the hardware Real Time Clock. A fix has been
> supplied to ROOL for including in a future OS update, and two workarounds
> have been made available in the meantime consiting of short BASIC programs
> to modify the time when the machine boots.
> From what I've read, it only affects the Iyonix (as it's a bug with the way
> that RISC OS 5 interacts with hardware unique to the Iyonix motherboard).
Hi Steve - I wouldn't dream of arguing with your expertise, I know
nothing of motherboards and such. So just checking, were the several
folk who reported this problem occuring on RiscPCs on the Iyo list
mistaken in some way then?
>> I have an Iyonix, RISC OS 5.13 and it did happen to me. I am not at all
>> technical, but as far as I can judge, on my machine at least, the problem
>> seems to have originated from NetTime, a Module file located in:
>> !Boot.Resources.!System.500.Modules.Network
> No. NetTime did *not* cause the problem. The presence of (a corrctly
> configured) NetTime (which yours wasn't to start with) *masked* the problem
> so that it didn't show up.
I am very glad that you have said this because I was happily sitting
here believing that my problem was permanently cured - thank you for
enlightening me.
>> Alan Adams and Brian Howlett cured it here for me, by suggesting that I
>> add a couple of lines at the bottom of the "User" Obey file, located in:
>> !Boot.Choices.Internet
>>
>> as follows:
>>
>> Set Inet$NTPServer uk.pool.ntp.org RMEnsure NetTime 0.35 RMLoad
>> System:Modules.Network.NetTime
>>
>> Just copy this bit into there and re-boot - that solved it for me.
> This just made NetTime work, and so masked the problem.
Yup! It certainly did for me!
> For a variety of reasons (as detailed here and on the Iyonix list), relying
> on this is not a good idea. If the network isn't present when the machine
> boots, or the NTP server isn't available, then your machine will once again
> think it's 2012.
Am I correct in interpreting your use of the word 'network' in the
above paragraph as referring to the Time thingy in NTP? You don't mean
my home computer network, do you?
> Until an OS fix comes out, install either Vince Hudd's or Matthew Philips'
> utilities to correct the year when the system starts.
Since I corrected that 'User' file I have had no further problems -
ie. my Iyonix has been powered off and then on again maybe ten times
after the correction and each time the clock is correctly showing
2010, I have never had to touch it since. I have therefore downloaded
Mathew's app but just kept it in reserve rather than install it.
Should I continue with this "If it ain't broke don't fix it" policy or
not, please?
--
Alex.
John Sandford
Alex Cessford <al...@cessford.org.uk> wrote:
> In message <mpro.kvr0la0l...@stevefryatt.org.uk>
> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
>> This just made NetTime work, and so masked the problem.
> Yup! It certainly did for me!
>> For a variety of reasons (as detailed here and on the Iyonix list), relying
>> on this is not a good idea. If the network isn't present when the machine
>> boots, or the NTP server isn't available, then your machine will once again
>> think it's 2012.
> Am I correct in interpreting your use of the word 'network' in the
> above paragraph as referring to the Time thingy in NTP? You don't mean
> my home computer network, do you?
He is referring to the networking of your Iyonix to the Internet as
the "Time thingy" gets the time information from a special server
which is located external to your home network if your internet
connection or the time server is down the date problem will re occur.
>> Until an OS fix comes out, install either Vince Hudd's or Matthew Philips'
>> utilities to correct the year when the system starts.
> Since I corrected that 'User' file I have had no further problems -
> ie. my Iyonix has been powered off and then on again maybe ten times
> after the correction and each time the clock is correctly showing
> 2010, I have never had to touch it since. I have therefore downloaded
> Mathew's app but just kept it in reserve rather than install it.
> Should I continue with this "If it ain't broke don't fix it" policy or
> not, please?
It is broke, you have applied a fix which in its self can break, use
Mathews's app as well.
When 5.15 is issued with a permanent fix you can remove Mathew's App,
leaving Nettime working to keep the clock accurate.
John
--
John Sandford West Herts UK
Hemel Hempstead RISC OS User Group email info @ hhrug.org
Alex Cessford
Jeremy Nicoll - news posts
<jn.nntp....@wingsandbeaks.org.uk> wrote:
> Alex Cessford <al...@cessford.org.uk> wrote:
>> For your interest, I also have a RiscBOOK Asus EeePC running Virtual
>> Acorn Adjust.
> More to the point, it runs Windows. Clocks on PCs are notoriously
> unreliable too, and there's any number of Windows apps which talk to NTP
> servers etc to align the PC clocks with reality.
> VA (etc) are just application as far as Windows is concerned. Certainly on
> my Windows-running laptop I use a NTP-checking program to keep the laptop's
> clock right. VRPC just asks Windows for the time.
Ah, right, thanks very much, I never thought of that. I'll go check my
RiscBOOK.
Is there any Windows app for NTP servers in particular which you would
recommend?
--
Alex.
John Sandford
Alex Cessford <al...@cessford.org.uk> wrote:
[snip]
> Ah, right, thanks very much, I never thought of that. I'll go check my
> RiscBOOK.
> Is there any Windows app for NTP servers in particular which you would
> recommend?
Windows has this built in, see control panel>date and time.
Russell Hafter News
Cessford <al...@cessford.org.uk> wrote:
> Is there any Windows app for NTP servers in particular
> which you would recommend?
AboutTime
The Home Page states "AboutTime isn't really needed on
Windows XP, which has its own way to set the system clock
(although some loyal users report AboutTime works better
than the XP service), and it will only work on Windows
Vista by disabling some of its security features."
--
Russell
http://www.russell-hafter-holidays.co.uk
Russell Hafter Holidays E-mail to enquiries at our domain
Need a hotel? <http://www.hrs.com/?client=en__blue&customerId=416873103>
James Lampard
[snip]
> Hi Steve - I wouldn't dream of arguing with your expertise, I know
> nothing of motherboards and such. So just checking, were the several
> folk who reported this problem occuring on RiscPCs on the Iyo list
> mistaken in some way then?
What several people? As far as I can see it's only one person. First
message http://www.freelists.org/post/iyonix-support/Date-problem-in-new-year,28
in which he says that on comp.sys.acorn.apps people with RPC's are
having the problem also (Where? I don't see any such posts). Maybe the
author assumed that anyone posting on the proletarian usenet can't own
an Iyonix.
Then the SAME PERSON posted http://www.freelists.org/post/iyonix-support/Date-problem-in-new-year,91
claiming that his RO4.49 RPC had jumped forward to 2012.
I have looked on comp.sys.acorn.apps and the ROL Select mailing list
(Which is where the problem with RO4.49 should be raised) and just for
luck comp.sys.acorn.hardware and comp.sys.acorn.misc
No one else has posted that they have this problem with their RiscPC.
So we can finally lay the matter to rest:
If there is anyone out there with the 2012 problem on their RiscPC can
they please speak now, or forever hold their peace.
PS The 40 minutes I spent re-reading all the messages; I want them
back please.
--
James.
charles
<a0741ed9-7abc-4f92...@r24g2000yqd.googlegroups.com>,
James Lampard <dontrep...@mailinator.com> wrote:
> On 5 Jan, 11:35, Alex Cessford <a...@cessford.org.uk> wrote:
> [snip]
> > Hi Steve - I wouldn't dream of arguing with your expertise, I know
> > nothing of motherboards and such. So just checking, were the several
> > folk who reported this problem occuring on RiscPCs on the Iyo list
> > mistaken in some way then?
> What several people? As far as I can see it's only one person. First
> message http://www.freelists.org/post/iyonix-support/Date-problem-in-new-year,28
> in which he says that on comp.sys.acorn.apps people with RPC's are
> having the problem also (Where? I don't see any such posts). Maybe the
> author assumed that anyone posting on the proletarian usenet can't own
> an Iyonix.
No, I assumed that if people were posting on that site they were refering
to the RISC PC. I post on there and own an Iyonix, so your logic is wrong.
> Then the SAME PERSON posted http://www.freelists.org/post/iyonix-support/Date-problem-in-new-year,91
> claiming that his RO4.49 RPC had jumped forward to 2012.
It was more than a claim - it was a fact.
--
From KT24
Using a RISC OS computer running v5.11
Chris Hughes
charles <cha...@charleshope.demon.co.uk> wrote:
>> [snip]
I am not awre of any problem with the RiscPC's clock/time, none of my
RiscPc has the problem, or Virtual machines. All other reports I have
seen have related to the Iyonix.
--
Chris Hughes
Chris Evans
James Lampard <URL:mailto:dontrep...@mailinator.com> wrote:
> So we can finally lay the matter to rest:
> If there is anyone out there with the 2012 problem on their RiscPC can
> they please speak now, or forever hold their peace.
Well we have nearly a two year wait to see if there is a 2012 problem!
The Iyonix has a 2010 problem, I don't know myself of any RiscPC's with a
new year problem.
Chris Evans
--
CJE Micro's / 4D 'RISC OS Specialists'
Telephone: 01903 523222 Fax: 01903 523679
ch...@cjemicros.co.uk http://www.cjemicros.co.uk/
78 Brighton Road, Worthing, West Sussex, BN11 2EN
The most beautiful thing anyone can wear, is a smile!
James Lampard
[snip]
> > What several people? As far as I can see it's only one person. First
> > messagehttp://www.freelists.org/post/iyonix-support/Date-problem-in-new-year,28
> > in which he says that on comp.sys.acorn.apps people with RPC's are
> > having the problem also (Where? I don't see any such posts). Maybe the
> > author assumed that anyone posting on the proletarian usenet can't own
> > an Iyonix.
>
> No, I assumed that if people were posting on that site they were refering
> to the RISC PC. I post on there and own an Iyonix, so your logic is wrong.
My logic is so bad I'm afraid I can't make head nor tail of that
sentence. To which site are you referring?
In the message http://www.freelists.org/post/iyonix-support/Date-problem-in-new-year,28
you said
>from posts in comp.sys.acorn.aps this would appear to apply to RISC PCs as
well.
Please list one of these posts.
>
> > Then the SAME PERSON posted http://www.freelists.org/post/iyonix-support/Date-problem-in-new-year,91
> > claiming that his RO4.49 RPC had jumped forward to 2012.
>
> It was more than a claim - it was a fact.
Then please report it on the Select mailing list.
Evan Clark
Chris Hughes <ne...@noonehere.co.uk> wrote:
> > It was more than a claim - it was a fact.
> I am not awre of any problem with the RiscPC's clock/time, none of
> my RiscPc has the problem, or Virtual machines. All other reports
> I have seen have related to the Iyonix.
It's just possible that Charles is running Joseph Heenan's time
server module on his Iyonix and serving the (wrong) time to his
RiscPC.
From what knowledgable people have said regarding Iyonix and RiscPC
hardware, I can't see any other way that a RiscPC could be affected,
albeit indirectly.
Evan.
Ben Crick
> Add an 'Obey' file to the 'Boot.PreDesk' sequence
> Call it " !!2010 " (Note the double ! NO quotes)
>
> The file contains one line - *Set Sys$Year 2010
>
> This file will need to be updated for each of the
> predicted troublesome years. I hope this helps
> but don't blame me if it don't.
I spoke too soon. My Iyo always starts up with an Error message about
!Alarms, and I have to reset the year manually after startup.
I've followed your advice; but it still restarts in 2012.
I don't have NetTime; nor do I have ClockFixer.
Where can I download these from the WWW, please?
Ben
--
_ __________________________________________
/ \._._ |_ _ _ /' Orpheus Internet Services
\_/| |_)| |(/_|_|_> / 'Internet for Everyone'
_______ | ___________./ http://www.orpheusinternet.co.uk
Revd Ben Crick BA CF <ben.crick[at]argonet.co.uk> ZFC Os
232 Canterbury Road, Birchington on sea, Kent CT7 9TD (UK)
Acorn RPC700 Kinetic RO 4.03 with Castle Iyonix RO 5.13 Ethernet
* To be almost saved is to be totally lost.
Dr Peter Young
> In article <csaa67424...@yo.rk>, Bryn Evans <d...@a.invalid> wrote:
>> Add an 'Obey' file to the 'Boot.PreDesk' sequence
>> Call it " !!2010 " (Note the double ! NO quotes)
>>
>> The file contains one line - *Set Sys$Year 2010
>>
>> This file will need to be updated for each of the
>> predicted troublesome years. I hope this helps
>> but don't blame me if it don't.
> I spoke too soon. My Iyo always starts up with an Error message about
> !Alarms, and I have to reset the year manually after startup.
> I've followed your advice; but it still restarts in 2012.
> I don't have NetTime; nor do I have ClockFixer.
> Where can I download these from the WWW, please?
ClockFixer sent off-group. NetTime, I'm sure ,is from the Iyonix site,
but can't find it ATM.
Steve Fryatt
> In message <mpro.kvr0la0l...@stevefryatt.org.uk>
> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
[The Iyonix RTC problem]
> > The cause of the problem has been identified, and is a bug in RISC OS 5
> > where it reads the date from the hardware Real Time Clock. A fix has
> > been supplied to ROOL for including in a future OS update, and two
> > workarounds have been made available in the meantime consiting of short
> > BASIC programs to modify the time when the machine boots.
>
> > From what I've read, it only affects the Iyonix (as it's a bug with the
> > way that RISC OS 5 interacts with hardware unique to the Iyonix
> > motherboard).
>
> Hi Steve - I wouldn't dream of arguing with your expertise, I know nothing
> of motherboards and such. So just checking, were the several folk who
> reported this problem occuring on RiscPCs on the Iyo list mistaken in some
> way then?
Given that by the time I found the thread on Sunday, there were already over
150 posts in the thread and most seemed to contain nothing more than wild
guesswork or repeated pleas for help from the same few people, it wouldn't
surprise me if they were.
It was clear that some people knew what they were talking about, but they
were drowned out. Even today, several days after the problem was identified
and a fix submitted to ROOL, there are still posts to the Iyonix list asking
when someone might get around to finding the cause of the problem.
It was certainly far from an edifying spectacle.
[snip]
> > For a variety of reasons (as detailed here and on the Iyonix list),
> > relying on this is not a good idea. If the network isn't present when
> > the machine boots, or the NTP server isn't available, then your machine
> > will once again think it's 2012.
>
> Am I correct in interpreting your use of the word 'network' in the above
> paragraph as referring to the Time thingy in NTP? You don't mean my home
> computer network, do you?
Yes, I mean your home computer network. Your NetTime "fix" is fine until
the time when you boot the machine up and either your network isn't working,
your broadband isn't connected, your ISP has a problem or the timeserver
you've configured NetTime to use is either down or can't be reached.
At which point, your Iyonix will once again decide that it's 2012 without
any warning, and you can wave goodbye to any auto-expired data.
> > Until an OS fix comes out, install either Vince Hudd's or Matthew
> > Philips' utilities to correct the year when the system starts.
>
> Since I corrected that 'User' file I have had no further problems - ie. my
> Iyonix has been powered off and then on again maybe ten times after the
> correction and each time the clock is correctly showing 2010, I have never
> had to touch it since.
That's because, so far, the many different external resources that NetTime
relies on have all been working correctly. I wouldn't rely on that
long-term when there are two fixes available that will be much more
reliable.
> I have therefore downloaded Mathew's app but just kept it in reserve
> rather than install it. Should I continue with this "If it ain't broke
> don't fix it" policy or not, please?
No, install the app until the release of RISC OS 5.15 is made by ROOL. Then
re-flash your machine with the new OS and remove the temporary fix.
Keep NetTime as well: it servers a very useful, but totally different,
purpose. Starting from the assumption that your clock is correct, it keeps
it that way.
Steve Fryatt
<5264edd4...@o2.co.uk>:
Given that the problem has been traced to the fact that the Iyonix's
hardware RTC chip is different from the RISC PC's one, and the conversion of
the bits of RISC OS that read the hardware clock don't seem to have been
made correctly, it would be strange if the problem *did* affect the RiscPC
as well.
If the RiscPC was affected, the problem was a different, unrelated one.
Ben Crick
<pny...@ormail.co.uk> wrote:
> ClockFixer sent off-group. NetTime, I'm sure ,is from the Iyonix site,
> but can't find it ATM.
Many thanks, Peter! ClockFixer installed, and clock fixed.
Ben
--
_ __________________________________________
/ \._._ |_ _ _ /' Orpheus Internet Services
\_/| |_)| |(/_|_|_> / 'Internet for Everyone'
_______ | ___________./ http://www.orpheusinternet.co.uk
Revd Ben Crick BA CF <ben.crick[at]argonet.co.uk> ZFC Os
232 Canterbury Road, Birchington on sea, Kent CT7 9TD (UK)
Acorn RPC700 Kinetic RO 4.03 with Castle Iyonix RO 5.13 Ethernet
* Is your home Prayer Conditioned?
Jeremy Nicoll - news posts
> In message <5082d5d45...@cessford.org.uk>
> Alex Cessford <al...@cessford.org.uk> wrote:
> > Ah, right, thanks very much, I never thought of that. I'll go check my
> > RiscBOOK. Is there any Windows app for NTP servers in particular which
> > you would recommend?
>
> Windows has this built in, see control panel>date and time.
Windows' in-built support is crap, at least in XP. It only attempts a
re-sync once every 7 days or so (which you can trigger manually from the
InternetTime tab of Adjust Date+Time).
I use AboutTime, and I have it recheck every minute.
Dave Higton
<a0741ed9-7abc-4f92...@r24g2000yqd.googlegroups.com>
James Lampard <dontrep...@mailinator.com> wrote:
> So we can finally lay the matter to rest:
> If there is anyone out there with the 2012 problem on their RiscPC can
> they please speak now, or forever hold their peace.
I'm sorry to risk muddying the waters, but, yes, it happened to
me too.
However, I think it may be a special case: my Risc PC has hardly
been powered up in a couple of years[1], so it's quite likely
that the battery had run down to the point where it could no
longer keep the CMOS RTC/RAM up reliably or at all.
Dave
[1] Something went wrong a couple of years or so ago, when I
tried to upgrade to Select (at an SAUG meeting - probably the
demo effect!) Since then I have found that heavy access to one
(or maybe two, I'm not really sure) of its three hard drives
stiffs the machine. There is some fault there. Since I use
my Iyonix for everything, I didn't bother to diagnose and fix
the problem. I just got round to trying again on Sunday. I
now have a working Risc PC, so long as I stick to using the
oldest hard drive in it, which is only 4 GB, the others being
50 GB and 80 GB. My motive for getting it going again is to
enable development of more USB applications on the Simtec
stack as well as the Castle. My recent developments for the
Simtec stack have been done on my Risc PC at work. I really
ought to be able to do it all at home!
Graham Thurlwell
> In message <50d4e9c5...@charleshope.demon.co.uk>
> charles <cha...@charleshope.demon.co.uk> wrote:
<snip>
>>> claiming that his RO4.49 RPC had jumped forward to 2012.
>> It was more than a claim - it was a fact.
> I am not awre of any problem with the RiscPC's clock/time, none of my
> RiscPc has the problem, or Virtual machines. All other reports I have
> seen have related to the Iyonix.
No problems with any of the following:-
Omega (1.15f firmware) running RO Select 3i4 (4.39).
A7000 running RO 3.6
A9home running RO 4.42
A7000+ running RO Select 6i1 (6.20).
TBH, I'm surprised that the Iyonix clock problem never showed up in
testing. Maybe Castle didn't think anything would go wrong.
Imagine the fuss if it'd been Select or Adjust...
--
Graham Thurlwell
Jades' First Encounters Site
http://www.jades.org/ffe.htm
Graham Thurlwell
> In message <5082d5d45...@cessford.org.uk>
> Alex Cessford <al...@cessford.org.uk> wrote:
> [snip]
>> Ah, right, thanks very much, I never thought of that. I'll go check my
>> RiscBOOK.
>> Is there any Windows app for NTP servers in particular which you would
>> recommend?
> Windows has this built in, see control panel>date and time.
Last time I tried setting that on my XP box the URL someone gave for
the BT Openwoe time server was one character too long to go in the
dialogue box!
Dave Higton
Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> Given that by the time I found the thread on Sunday, there were already
> over 150 posts in the thread and most seemed to contain nothing more than
> wild guesswork or repeated pleas for help from the same few people, it
> wouldn't surprise me if they were.
>
> It was clear that some people knew what they were talking about, but they
> were drowned out. Even today, several days after the problem was
> identified and a fix submitted to ROOL, there are still posts to the Iyonix
> list asking when someone might get around to finding the cause of the
> problem.
>
> It was certainly far from an edifying spectacle.
I have to agree with you, sadly.
> [snip]
>
> No, install the app until the release of RISC OS 5.15 is made by ROOL.
> Then re-flash your machine with the new OS and remove the temporary fix.
I'm expecting a rash of further e-mails at some point, when the
temporary fix malfunctions, because some people won't have removed
it, no matter how many times they were told to.
Dave
Peter Naulls
[Finally fix grammar in subject]
Dave Higton wrote:
> I'm expecting a rash of further e-mails at some point, when the
> temporary fix malfunctions, because some people won't have removed
> it, no matter how many times they were told to.
It'll be before then, as people wrangle over doing a soft-load
or reflash (and how to do each). There are a number of people
still using 5.13 for unknown reasons. Unfortunately, certain
people feel compelling to write endless one liners saying
essentially nothing.
In a more organised environment, one of the date work arounds
could be rolled out via !RiscPkg, avoiding all the installation
headaches, and then later deprecated, via a later ROM update.
druck
> TBH, I'm surprised that the Iyonix clock problem never showed up in
> testing. Maybe Castle didn't think anything would go wrong.
It's not just us, many Windows CE devices think it's 2016 because they
didn't realise the clock chip being used returned dates in BCD rather
than binary. It's not something you'd test for unless you'd come across
a similar issue before.
---druck
Martin
<gemini.kvsmm...@wingsandbeaks.org.uk.invalid>,> John Sandford <fornew...@ntlworld.com> wrote:
> > In message <5082d5d45...@cessford.org.uk>
> > Alex Cessford <al...@cessford.org.uk> wrote:
> > Windows has this built in, see control panel>date and time.
> Windows' in-built support is crap, at least in XP. It only attempts a
> re-sync once every 7 days or so
That is indeed the default: there is a simple registry change which I
used so long ago to change it to every day that I have forgotten what it
was! Google?!
> I use AboutTime, and I have it recheck every minute.
Seems rather excessive! Are you really expecting your PC clock to drift
*that* quickly?
--
Martin Avison
Note that unfortunately this email address will become invalid
without notice if (when) any spam is received.
Jeremy Nicoll - news posts
> On 05 Jan, in article
> <gemini.kvsmm...@wingsandbeaks.org.uk.invalid>,
> Jeremy Nicoll - news posts <jn.nntp....@wingsandbeaks.org.uk>
> > I use AboutTime, and I have it recheck every minute.
>
> Seems rather excessive! Are you really expecting your PC clock to drift
> *that* quickly?
I was going to say no, because last time I looked I thought it tended to be
stable for hours and then throw a wobbly every so often (not when shut-down
and rebooted), but I just had a look at the app's log and that suggests the
PC clock is running faster than it should just at the moment, that is the
app is having to rein-in the machine time by about a second every minute.
I just changed the update time to every 10 minutes and I'll look again in a
while.
I only installed AboutTime in the first place because I'd seen time drift
more than I thought reasonable.
Chris Hall
> On 5 Jan, Alex Cessford wrote in message
> <eada94d45...@cessford.org.uk>:
> Until an OS fix comes out, install either Vince Hudd's or Matthew Philips'
> utilities to correct the year when the system starts.
Will there be an OS fix for those running RISC OS 5.11 please?
--
Chris Hall <ch...@svrsig.org>
Dave Higton
Martin <New...@avisoft.f9.co.uk> wrote:
> Seems rather excessive! Are you really expecting your PC clock to drift
> *that* quickly?
You might be astonished to discover how fast PC clocks can drift.
Unfortunately they are often implemented in software by programmers
who have little or no knowledge of hardware or of real-time software,
so the result is poor performance.
I think the usual flaw is that the source is interrupts, so the
clock is incremented by some amount every interrupt... well, every
interrupt that the OS /sees/. Some are lost, presumably because
one happens while a previous interrupt is still being serviced.
So the clock runs slow. So the programmer observes that it's
running slow and "corrects" the time increment instead of solving
the real problem. So, when interrupts are not being missed so
frequently, the clock runs fast...
... all as a substitute for reading the proper hardware RTC.
Dave
Rob Kendrick
Dave Higton <daveh...@dsl.pipex.com> wrote:
> ... all as a substitute for reading the proper hardware RTC.
Reading the hardware RTC is an expensive and slow operation. You most
certainly want the OS to keep its own copy that it updates itself.
NTP is an especially useful protocol for keeping the clocks on multiple
machines so close to each other they might as well be identical. This
is not a work-around for poorly-implemented software clocks, but often
a requirement in networked situations.
B.
Ian Hamilton
Same as everyone else. Use one of the utilities for now, install 5.15
when available removing the utility at the same time.
--
Ian Hamilton (Iyonix RO5) http://www.hamiltoni.pwp.blueyonder.co.uk/
Dave Higton
Rob Kendrick <nn...@rjek.com> wrote:
> On Thu, 07 Jan 2010 11:06:56 GMT
> Dave Higton <daveh...@dsl.pipex.com> wrote:
>
> > ... all as a substitute for reading the proper hardware RTC.
>
> Reading the hardware RTC is an expensive and slow operation.
Oh yes, I understand that. Some slower than others - the PCF8583,
traditionally used by RISC OS machines prior to the Iyonix, must
be one of the worst because of the IIC communication by PIO.
> You most certainly want the OS to keep its own copy that it updates
> itself.
But then you see what happens - many (most?) of them are poorly
implemented, and thus hopelessly inaccurate.
> NTP is an especially useful protocol for keeping the clocks on multiple
> machines so close to each other they might as well be identical. This
> is not a work-around for poorly-implemented software clocks, but often
> a requirement in networked situations.
You're arguing against yourself there, because the problem is
precisely the poorly-implemented software clocks.
Dave
Rob Kendrick
Dave Higton <daveh...@dsl.pipex.com> wrote:
> > You most certainly want the OS to keep its own copy that it updates
> > itself.
>
> But then you see what happens - many (most?) of them are poorly
> implemented, and thus hopelessly inaccurate.
This is an argument for them to be well implemented, not to abandon
them.
> > NTP is an especially useful protocol for keeping the clocks on
> > multiple machines so close to each other they might as well be
> > identical. This is not a work-around for poorly-implemented
> > software clocks, but often a requirement in networked situations.
>
> You're arguing against yourself there, because the problem is
> precisely the poorly-implemented software clocks.
No, absolutely not. It's not reasonable to expect an interrupt-derived
software clock to be drift-free enough for many business purposes
between computers. Or even when you're a software developer using
"make" over NFS. And this is the problem that NTP helps solve. A good
implementation of a software clock helps, but doesn't solve.
B.
Roger Darlington
> Martin <New...@avisoft.f9.co.uk> wrote:
>
>> On 05 Jan, in article
>> <gemini.kvsmm...@wingsandbeaks.org.uk.invalid>,
>> Jeremy Nicoll - news posts <jn.nntp....@wingsandbeaks.org.uk>
>
>> > I use AboutTime, and I have it recheck every minute.
>>
>> Seems rather excessive! Are you really expecting your PC clock to drift
>> *that* quickly?
>
> I was going to say no, because last time I looked I thought it tended to be
> stable for hours and then throw a wobbly every so often (not when shut-down
> and rebooted), but I just had a look at the app's log and that suggests the
> PC clock is running faster than it should just at the moment, that is the
> app is having to rein-in the machine time by about a second every minute.
A second every minute!!
Blimey.
The clock is obviously either:
a) not timed by a clock regulated by a quartz crystal.
b) the crystal has broken.
There can surely be no other explanation for a Xtral being so far out.
Normally they are accurate to at most 200ppm, and 20ppm if adjusted.
1 in 60 is 167,000 ppm!!!
--
Cheers
Roger
If you collect them, then, one day - you'll have a lot.
Rob Kendrick
Roger Darlington <roge...@freeuk.com> wrote:
> A second every minute!!
>
> Blimey.
>
> The clock is obviously either:
> a) not timed by a clock regulated by a quartz crystal.
> b) the crystal has broken.
Almost all software clocks on computers are not directly driven by a
quartz crystal, they are driven by a specific "timer" interrupt that
is generated by a signal generator that generates its frequency using
PLLs, dividers, multiplies and such from other buses and clock nets on
the motherboard, which will normally ultimately reach a quartz crystal
or some other clock. This crystal will be far and unrelated to the
typical 32kHz source used in wall clocks and watches. An additional
problem is that higher-priority interrupts may delay the CPU's reaction
to the timer's IRQ, thus causing drift.
B.
Chris Evans
One PC here often loses 15 minutes between 9a.m. and 5.30p.m. no descernable
pattern of what applications are used and time loss.
n.b. the computer is normally only used for 15-30mins a day and Firefox is
the only app normally running!
Chris Evans
--
CJE Micro's / 4D 'RISC OS Specialists'
Telephone: 01903 523222 Fax: 01903 523679
ch...@cjemicros.co.uk http://www.cjemicros.co.uk/
78 Brighton Road, Worthing, West Sussex, BN11 2EN
The most beautiful thing anyone can wear, is a smile!
Graham Thurlwell
> In article <4676d8d5...@chris.svrsig.org>,
> Chris Hall <ch...@svrsig.org> wrote:
<snip>
>> Will there be an OS fix for those running RISC OS 5.11 please?
> Same as everyone else. Use one of the utilities for now, install 5.15
> when available removing the utility at the same time.
Anyone know if Castle is planning to contact owners who don't have
access to the Internet or know about ROOL? I imagine there could well
be quite a few confused people out there at the moment.
Chris Hughes
Graham Thurlwell <nos...@jades.org> wrote:
> On the 7 Jan 2010, Ian Hamilton <Ian.Ha...@AAUG.net> wrote:
>> In article <4676d8d5...@chris.svrsig.org>,
>> Chris Hall <ch...@svrsig.org> wrote:
> <snip>
>>> Will there be an OS fix for those running RISC OS 5.11 please?
>> Same as everyone else. Use one of the utilities for now, install 5.15
>> when available removing the utility at the same time.
> Anyone know if Castle is planning to contact owners who don't have
> access to the Internet or know about ROOL? I imagine there could well
> be quite a few confused people out there at the moment.
What about all those supposedly sold to businesses have they been
informed?
--
Chris Hughes
Dave Higton
Rob Kendrick <nn...@rjek.com> wrote:
> On Thu, 07 Jan 2010 11:48:54 GMT
> Dave Higton <daveh...@dsl.pipex.com> wrote:
>
> > > You most certainly want the OS to keep its own copy that it updates
> > > itself.
> >
> > But then you see what happens - many (most?) of them are poorly
> > implemented, and thus hopelessly inaccurate.
>
> This is an argument for them to be well implemented, not to abandon
> them.
Ah, the view of the ivory tower theoretician. I live in the real
world, where all the commonly available OS clocks are not well
implemented. That was the basis of my response to you.
Are you going to fix Windows' or Linux's clocks?
No, I thought not.
> > > NTP is an especially useful protocol for keeping the clocks on
> > > multiple machines so close to each other they might as well be
> > > identical. This is not a work-around for poorly-implemented
> > > software clocks, but often a requirement in networked situations.
> >
> > You're arguing against yourself there, because the problem is
> > precisely the poorly-implemented software clocks.
>
> No, absolutely not. It's not reasonable to expect an interrupt-derived
> software clock to be drift-free enough for many business purposes
> between computers. Or even when you're a software developer using
> "make" over NFS. And this is the problem that NTP helps solve. A good
> implementation of a software clock helps, but doesn't solve.
Your line of reasoning completely escapes me.
Dave
Dave Higton
Roger Darlington <roge...@freeuk.com> wrote:
See my explanation earlier in this thread as to why the accuracy of
the crystal source is thrown away by the OS.
Dave
Rob Kendrick
What's escaping you? That nobody wants to put PCI-connected atomic
clocks into servers and workstations, and have a dedicated network to
synchronise them?
A 10ms drift between NFS server and build box can cause problems that
can be tricky to diagnose. NTP removes them.
B.
Steve Fryatt
<ecd808d650...@dsl.pipex.com>:
Time variations, even small ones, between systems cause problems. Look at
the compexity of work-arounds on the various RISC OS file-sync software to
see the lengths that need to be gone to in order to allow for clock drift.
NTP can resolve most (all?) of that, if required. Even if you made the
system clocks completely, 100% identical, you would still need an NTP-like
system to get them in sync to start with anyway.
--
Steve Fryatt - Leeds, England
Steve Fryatt
<793df9d5...@o2.co.uk>:
> In message <2c87f5d5...@d.thurlwell.btopenworld.com>
> Graham Thurlwell <nos...@jades.org> wrote:
>
> > Anyone know if Castle is planning to contact owners who don't have
> > access to the Internet or know about ROOL? I imagine there could well be
> > quite a few confused people out there at the moment.
Did Castle ever have a regular upgrade route for non-'net connected users
who couldn't use IyoUpWatch?
> What about all those supposedly sold to businesses have they been
> informed?
If they wanted support, someone relevant will presumably be subscribed to
the support list, which is how it worked for the rest of us. And I don't
think that anyone there can have failed to have noticed that there was a bit
of a problem... :-(
Steve Fryatt
<39510cd5...@d.thurlwell.btopenworld.com>:
> No problems with any of the following:-
>
> Omega (1.15f firmware) running RO Select 3i4 (4.39). A7000 running RO 3.6
> A9home running RO 4.42 A7000+ running RO Select 6i1 (6.20).
>
> TBH, I'm surprised that the Iyonix clock problem never showed up in
> testing. Maybe Castle didn't think anything would go wrong.
I'm not, really. There are many, many variables that would have needed
testing on the Iyonix hardware, and probably not that long to get it all
done in. I'm sure Castle believed that they had tested all the critical
points.
That doesn't excuse it, but I can't believe that there aren't at least a few
people reading this and having "There but for the grace of God"-type
thoughts. Faults that come to light in the field are rarely ones that the
engineers thought of during design and testing; if they did, the problems
would be unlikely to make it into the field.
> Imagine the fuss if it'd been Select or Adjust...
Having been on the Select scheme for a number of years following its
inception, I don't have to *imagine* the fuss...
Rob Kendrick
Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> NTP can resolve most (all?) of that, if required. Even if you made
> the system clocks completely, 100% identical, you would still need an
> NTP-like system to get them in sync to start with anyway.
Precisely.
B.
Chris Hall
Ian Hamilton <Ian.Ha...@AAUG.net> wrote:
> In article <4676d8d5...@chris.svrsig.org>,
> Chris Hall <ch...@svrsig.org> wrote:
>> In message <mpro.kvr0la0l...@stevefryatt.org.uk>
>> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
>>> On 5 Jan, Alex Cessford wrote in message
>>> <eada94d45...@cessford.org.uk>:
>>> Until an OS fix comes out, install either Vince Hudd's or Matthew
>>> Philips' utilities to correct the year when the system starts.
>> Will there be an OS fix for those running RISC OS 5.11 please?
> Same as everyone else. Use one of the utilities for now, install 5.15
> when available removing the utility at the same time.
Excellent - how does one install 5.15 (bear in mind that 5.12 was not
available unless you paid) - I just need the update to 5.15 not the
payable bit. I also do not want to lose 16 and 256 colour screen modes
as I use them extensively.
--
Chris Hall <ch...@svrsig.org>
Ian Hamilton
Chris Hall <ch...@svrsig.org> wrote:
> In message <50d5da72b5I...@AAUG.Net>
> Ian Hamilton <Ian.Ha...@AAUG.net> wrote:
> > In article <4676d8d5...@chris.svrsig.org>,
> > Chris Hall <ch...@svrsig.org> wrote:
> >> In message <mpro.kvr0la0l...@stevefryatt.org.uk>
> >> Steve Fryatt <ne...@stevefryatt.org.uk> wrote:
> >>> On 5 Jan, Alex Cessford wrote in message
> >>> <eada94d45...@cessford.org.uk>:
> >>> Until an OS fix comes out, install either Vince Hudd's or Matthew
> >>> Philips' utilities to correct the year when the system starts.
> >> Will there be an OS fix for those running RISC OS 5.11 please?
> > Same as everyone else. Use one of the utilities for now, install 5.15
> > when available removing the utility at the same time.
> Excellent - how does one install 5.15 (bear in mind that 5.12 was not
> available unless you paid) - I just need the update to 5.15 not the
> payable bit. I also do not want to lose 16 and 256 colour screen modes
> as I use them extensively.
5.12/5.13 were chargeable when released but that was before the ROOL
initiative. You could install 5.14 for free now, you will be able to
install 5.15 for free when available. These later versions include USB2
in ROM. The 16/256 colour screen modes are provided by Aemulor, which
will still work with a later OS version.
You may as well move straight to 5.15 when released. As you are on 5.11
there may be a problem if you have any unplugged modules as the ROM
module order changes. It's best to list everything with '*Unplug', put
them back with '*RMReinit xxxx' and then install the new ROM. If required
those modules can then be unplugged again with '*Unplug xxxx'. When the
new ROM is installed whichever clock fix program you used should be
removed.
HTH,
Ian
Chris Hall
Ian Hamilton <Ian.Ha...@AAUG.net> wrote:
On my Iyonix (OS 5.11) the 16 and 256 colour screen modes are *not*
provided by Aemulor - which is only active for selected applications.
How do I load 5.14? And in such a way that I can revert to 5.11 if I
need to please? !IyoUpWtch reports 'no updates available'.
> HTH,
> Ian
--
Chris Hall <ch...@svrsig.org>
Ian Hamilton
<ch...@svrsig.org> wrote:
> In message <50d650480eI...@AAUG.Net>
> Ian Hamilton <Ian.Ha...@AAUG.net> wrote:
> > In article <5cfefed5...@chris.svrsig.org>,
> > Chris Hall <ch...@svrsig.org> wrote:
[Snip] 5.15
> >> Excellent - how does one install 5.15 (bear in mind that 5.12 was
> >> not available unless you paid) - I just need the update to 5.15 not
> >> the payable bit. I also do not want to lose 16 and 256 colour screen
> >> modes as I use them extensively.
> > 5.12/5.13 were chargeable when released but that was before the ROOL
> > initiative. You could install 5.14 for free now, you will be able to
> > install 5.15 for free when available. These later versions include
> > USB2 in ROM. The 16/256 colour screen modes are provided by Aemulor,
> > which will still work with a later OS version.
> On my Iyonix (OS 5.11) the 16 and 256 colour screen modes are *not*
> provided by Aemulor - which is only active for selected applications.
Sorry, yes Aemulor provides 16 colour modes. The 256 colour modes work
anyway.
> How do I load 5.14? And in such a way that I can revert to 5.11 if I
> need to please? !IyoUpWtch reports 'no updates available'.
5.14 can be softloaded or flashed, see :-
http://www.riscosopen.org/content/downloads/other-zipfiles
Chris Hall
Ian Hamilton <Ian.Ha...@AAUG.net> wrote:
> [Snip] 5.15
> http://www.riscosopen.org/content/downloads/other-zipfiles
> Ian
Many thanks - I have softloaded 5.14 and it is only the 16-colour
modes that I lose unless Aemulor Pro is running. I keep the 256 colour
modes (which I need for a screen capture application I have written)
so all is well.
Presumably I don't need any patches (previous ROM reflashes tended to
come with 'other stuff' that was required).
--
Chris Hall <ch...@svrsig.org>
Ian Hamilton
Chris Hall <ch...@svrsig.org> wrote:
> In message <50d65d96c5I...@AAUG.Net>
> Ian Hamilton <Ian.Ha...@AAUG.net> wrote:
> > In article <8ffc5cd6...@chris.svrsig.org>, Chris Hall
> > <ch...@svrsig.org> wrote:
> >> In message <50d650480eI...@AAUG.Net>
> >> Ian Hamilton <Ian.Ha...@AAUG.net> wrote:
> >>> In article <5cfefed5...@chris.svrsig.org>,
> >>> Chris Hall <ch...@svrsig.org> wrote:
> > [Snip] 5.15
> >>> 5.12/5.13 were chargeable when released but that was before the
> >>> ROOL initiative. You could install 5.14 for free now, you will be
> >>> able to install 5.15 for free when available. These later versions
> >>> include USB2 in ROM. The 16/256 colour screen modes are provided by
> >>> Aemulor, which will still work with a later OS version.
[Snip]
> >> How do I load 5.14? And in such a way that I can revert to 5.11 if I
> >> need to please? !IyoUpWtch reports 'no updates available'.
> > 5.14 can be softloaded or flashed, see :-
> > http://www.riscosopen.org/content/downloads/other-zipfiles
> Many thanks - I have softloaded 5.14 and it is only the 16-colour
> modes that I lose unless Aemulor Pro is running. I keep the 256 colour
> modes (which I need for a screen capture application I have written)
> so all is well.
> Presumably I don't need any patches (previous ROM reflashes tended to
> come with 'other stuff' that was required).
No patches, it's only the '*Unplug' list that can cause issues as the ROM
order varies between 5.11 & 5.14.
Jeremy Nicoll - news posts
> I just changed the update time to every 10 minutes and I'll look again in
> a while.
For hours at a time the clock barely drifts - a few tens of mS wrong every
ten minutes. Then I get bursts of errors of 10-20 seconds every ten
minutes.
I've gone back to checking every minute.