On a Master 128 with OS 3.2, the date (as reported by *TIME, for example)
will wrap around to 1st January 1900 at midnight on 1st January 2000. This
may also occur with the later OS 3.5 and the various third-party real time
clocks available for the other 8-bit Acorn machines.
(I'm not even close to being an expert, but in case this 'fix' misleads
anyone, the 'real' year 2000 problem is much more complicated.)
For the impatient...
The rest of this documentation has an unfortunate tendency to interweave
technical and non-technical information, so please don't be put off reading
it if parts seem beyond you. In brief, though:
To 'fix' the year 2000 problem, just *RUN Y2KFix before any program which
uses the date. (You'll need to do this again if you press BREAK.)
To see that the problem has been fixed, try the following (sorry if this
Type *RUN Y2KFix, then *TIME to see that Y2KFix doesn't interfere with dates
before 2000 (this isn't strictly true; see below if you're interested.)
Press BREAK to make sure Y2KFix isn't installed
Type TIME$="Fri,31 Dec 1999.23:59:00"
Type *TIME to see that the time and date have been set correctly
Wait for about a minute
Type *TIME to see that the year is now wrong; it says 1900 instead of 2000.
Type *RUN Y2KFix, then *TIME to see that the year is now right.
Press BREAK to make sure Y2KFix isn't installed
Type *TIME to see that the year is now wrong again.
Type *RUN Y2KFix, then *TIME to see that the year is now right. (This shows
that you don't have to worry about loading Y2KFix all the time, only when you
need it. The date and time will continue to be updated correctly even if it's
not loaded, it's just that the date will be displayed wrongly.)
What Y2KFix does
This simple program intercepts the OSWORD vector and traps the calls to read
the current time as a string and to convert a BCD time to a string. The OS
deals with the call as usual, then if the year is earlier than 1970, the
19 in the year is changed to a 20 before returning to the program which
issued the OSWORD call. The result of this is that, to some extent, the
real time clock works correctly from 1970 to 2069 instead of 1900 to 1999.
No special action is needed when setting the clock, as the OS just seems to
ignore the century part of the year. It doesn't check that the day of the
week is correct, so it doesn't matter that 1st January 1900 was a Monday
while 1st January 2000 is a Saturday. Although 1900 wasn't a leap year,
the RTC and/or OS treat it as though it was, so the fact that 2000 is a
leap year doesn't cause problems.
The OSWORD call to read the current time in BCD format doesn't return the
century part of the year. As a result, this program is of no use with any
software which reads the time in BCD format and uses that directly instead
of having the OS convert it to a time string.
If this doesn't make any sense, don't worry; it just means that programs
which read the date from the real time clock and don't assume the century
will be 19 will work correctly even after 1999. (It is not necessarily a
sign of a badly written program to assume that the century will be 19, at
least not on the 8-bit Acorn machines, as one method of reading the date
doesn't return a century year; this is what the previous paragraph is about.)
It's all a bit cosmetic really, but it just might be useful to someone and
it kept me amused for an hour or two while I wrote it.
How to use it
An assembled version of the machine code is supplied as Y2KFix. This occupies
memory from &A80 to &AFF, although the first part of the code is only used
for initialisation and can be overwritten once it has been run. If you want
to store the code somewhere else, load Y2KFixS, alter the value of dest% in
PROCinit and RUN it to assemble a new copy of Y2KFix. You will need BASIC 2
or later to run Y2KFixS as it uses offset assembly. This is obviously not a
problem for Master 128 owners, but it may matter to the hypothetical owner
of a BBC B with BASIC 1 and a real time clock upgrade. If anyone has this
problem please contact me and I'll see if I can do anything to help.
Once you have a suitable copy of Y2KFix, you can simply *RUN Y2KFix to use
it. This should probably be done in the !Boot file of the disc containing
the program which needs it. Note that the code does not remain in place over
a BREAK, let alone a CTRL-BREAK. This could be fixed quite easily, and if
you feel this is necessary and can't do it for yourself then please contact
me. I haven't done it as standard because it would increase the amount
of memory used slightly and prevent any other utilities from remaining
installed over a BREAK or CTRL-BREAK.
How I tested it
I tested Y2KFix using an extremely simple program, TestY2K, which sets the
date and time to just before midnight on 31st December 1999 and then makes
each day pass fairly quickly by repeatedly setting the time to just before
midnight and waiting for the time to wrap around at midnight. If you want
to try this yourself, please note that it (fairly obviously) destroys the
existing time and date, which will have to be manually reset afterwards.
Writing TestY2K revealed an interesting quirk in the RTC and/or
OS. Try changing the TIME$="23:59:57" line to read TIME$="23:59:58" or
TIME$="23:59:59" and run the program again. (Both have a different effect
on my Master.) I thought this was a fault in my code at first, and after
switching off and on didn't cure the problem I started to wonder if I'd
damaged the RTC somehow.
I tried TestY2K on a RISC OS 2 Archimedes 310 (with the intention of
comparing the output of a long run against that from a Master 128 using
Y2KFix, to see if it worked correctly in the long term) and even with a
few minutes' fiddling I couldn't get the A310 to run it properly. I haven't
experimented further or tried any other Acorn machines/OSs yet; if anyone
is inspired to look into this then I'd be interested in hearing about it.
Y2KFix is genuinely public domain software. You can do anything you like
with it - sell it for profit, give it away, modify it and release your own
version, etc. It would be nice if you let me know what you do with it, but
having placed it in the public domain I have no right to insist on this.
Bug reports or suggestions for improvements are welcome, but I can't promise
to do anything with them. You can contact me through the 8-Bit Software
messaging system (user 15A), or write to me directly:
6 Laythorpe Avenue
(no 'phone calls please). If you want a reply or the return of any discs
you send, please enclose a SAE. (I can handle any standard Acorn disc format.)