Ticket #227 (Fixed)Fri Jan 01 15:00:49 UTC 2010
Iyonix clock thinks it's 2012
Reported by: | Martin Bazley (331) | Severity: | Major |
Part: | RISC OS: General | Release: | |
Milestone: | Status | Fixed |
Details by Martin Bazley (331):
This has been extensively discussed on both the Iyonix mailing list and Usenet, and it appears to be exclusive to the Iyonix. The symptoms suggest a ROM issue to me, so I thought a ticket should be raised (I’m quite surprised nobody’s done it yet!).
Basically, according to other people who have done much more testing than I have (i.e. none), if the clock is in an odd numbered decade, an extra two years will be added at bootup. Hence when I booted up this morning (1/1/2010) the computer thought it was 2012 – very annoying when Messenger is set to expire old news, although at least I didn’t have the problems of those running Organizer!
Changelog:
Modified by Martin Avison (27) Fri, January 01 2010 - 22:17:36 GMT
If it is any help, if a *Time is added to Run, it shows a year of 2012 when the date had been 2010 on shutdown. This seems to confirm that it is nothing to do with softloaded modules or applications, but a ROM initialistion issue (or earlier!).
Modified by Jeffrey Lee (213) Sat, January 02 2010 - 00:29:37 GMT
The explanation Chris/Adrian has offered here does seem to be correct.
The only problem is that I can’t see how the code ever worked properly in the first place!
Modified by Jeffrey Lee (213) Sat, January 02 2010 - 00:29:46 GMT
The explanation Chris/Adrian has offered here does seem to be correct.
The only problem is that I can’t see how the code ever worked properly in the first place!
Modified by Jeffrey Lee (213) Sat, January 02 2010 - 00:41:09 GMT
Whoops, that post wasn’t quite ready (or meant to appear twice!)
Anyway, to elaborate:
I’m confused because, as far as I can tell, RISC OS 3.5/3.6/3.7 should suffer from a similar bug every 4 years. The code these versions of RISC OS use is here – it’s the “NewClockChip” block at line 1031. The first time the machine is booted in 2010, the 2-bit year in the RTC will be 0, while the first YearCMOS byte will be ‘09’. This results in R1=0, R0=9, R2=1. The SUBS on line 1039 will make R2=-1, and leave the carry flag clear – which will mean the year gets recalculated as 2012. And yet when I just turned on my RiscPC to check, it correctly thinks it’s 2010. Even after writing a quick BASIC program to check the results I can’t see how the code could ever work properly when the RTC year wraps around.
If I was more sure of how the RiscPC manages to work properly I’d suggest a fix for the Iyonix, but for the moment I think it’s best if I left that code alone!
Modified by Jeffrey Lee (213) Sat, January 02 2010 - 03:06:55 GMT
Of course, as soon as I get into bed I realise that what I’ve written above is complete nonsense, and how the code would only break on odd-numbered decades when used with an RTC that stores the year in BCD format.
Once I’ve had some sleep I’ll try putting together a fix!
Modified by Jeffrey Lee (213) Sat, January 02 2010 - 11:11:23 GMT
Once I’ve had some sleep I’ll try putting together a fix!
Or not, as apparently Adrian Lees has already submitted one.
Modified by Jeffrey Lee (213) Tue, January 26 2010 - 01:32:05 GMT
- Status changed from Open to Fixed
Fairly safe to say that this is fixed now!