Quick fix for IyonixPC year increase bug

IMPORTANT UPDATE:

RISC OS 5.16 is now available from RISC OS Open Ltd. This an official release and, as well as a number of other updates and improvements to RISC OS 5.xx, if programmed into the Iyonix ROM will solve the clock problem described below. This means the program presented below to act as a temporary solution to the problem is now no longer necessary. If you are using it, please remember to remove it from your boot sequence prior to rebooting your updated computer.

However, please note that if you softload RISC OS 5.16, the clock will continue to need fixing – so if you choose to do that, the temporary fix will continue to be of use to you. I would recommend programming the new version of RISC OS into your ROM, though, and thus negating the need for such temporary work-arounds.

Original post:

There appears to be a problem with IyonixPCs which causes the year to be progressed by two after a reset when the date/time has been updated in certain circumstances. Most notably, this appears to only happen in odd decades – so, for example, from 2000 to 2009 there is no problem, while from 2010 to 2019 the problem occurs, everything’s fine again from 2020 to 2029 and the problem reoccurs from 2030 to 2039, and so on.

The main things I use my IyonixPC for these days are programming (ie WebChange Pro) and website maintenance – for which I use WebChange Pro! And a key feature of that software is the insertion of dates into web pages, based on file datestamps. If the datestamps are wrong because the system clock is wrong, then the dates inserted into the web pages will be wrong. I therefore needed to fix the problem on my computer. The quick fix I came up with was the following program, written in BBC Basic:

DIM Time5% 5, Ordinals% 32
?Time5%=3
SYS"OS_Word",14,Time5%
SYS"Territory_ConvertTimeToOrdinals",-1,Time5%,Ordinals%
IF(!(Ordinals%+24)/10) MOD 2<>0 AND !(Ordinals%+24) MOD 10>1 THEN
 !(Ordinals%+24)=!(Ordinals%+24)-2
 SYS"Territory_ConvertOrdinalsToTime",-1,Time5%,Ordinals%
 SYS"Territory_SetTime",Time5%
ENDIF

If you are using an IyonixPC that is affected by this problem, copy and paste that into a text editor on your IyonixPC, and save it out as a BASIC program (filetype ‘BASIC’ or &ffb). Double click on !Boot (or click Menu on the Switcher icon and then click on ‘Configure’), click on ‘Boot’ and then on ‘Run’ and drag the BASIC file you’ve just saved into the list of programs to be run at start up.

What should now happen is that, when your IyonixPC is booted, the above program will run. It reads the time into a 5 byte block, which is then converted into ‘ordinals’ (numbers representing each aspect of the date/time). A calculation is performed on the year number, to determine if it is in an odd or even decade. If it is an odd decade, the year is rewritten with 2 deducted, the ordinals converted back to a 5 byte value and that value used to reset the clock.

Unfortunately, there is a flaw in this fix. In 2018, the bug will cause the year to be updated to 2020 – and this program will recognise 2020 as being in an ‘even’ decade, and therefore won’t fix it. Similarly, in 2019 the bug will update the year to 2021, which won’t be fixed – and the same for the equivalent two years twenty years later, and so on. Making the program fix those years means it will be deducting 2 from the year unnecessarily when it really is 2020 and 2021 (etc). I’d hope that by then, though, there might be a proper fix to the problem so that quick fixes such as this aren’t needed.

One minor adjustment has been made to the above program since originally publishing this page: the condition now has an extra check (the AND… part). This is to ensure the program doesn’t set the clock back by two years if the year ends in a 0 or 1. Provided it’s only ever run as part of the boot sequence, and nothing else corrects the date, this shouldn’t be a problem – but it does add a small amount of robustness. There is also an issue with leap years – on 29th February 2012, when the date bug increases the date by two years, the result will be 1st March 2014, and my program will ‘fix’ this to 1st March 2012. However, while I can build in a check for that, there would be no way to for the program to know if it really is 1st March – so instead of (as now) moving the clock forward by a day on 29th February (in a leap year), the fix would be to move the clock backwards by a day on 1st March (in a leap year). Neither is the right thing to do – so the deadline for a proper fix to this problem with the Iyonix is now 29th February 2012!