[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MiNT] Millennium bug (fwd)

Below are 2 newsposts about a couple of little details we need fixed,
mainly related to BIOS and GEMDOS time-handling commands.  Fixing TOS
is too difficult (except for the Milan TOS, of course - Hi Michael!),
so could we integrate that into MiNT instead?   Just curious. ;-)

Martin-Eric Racine       http://www.pp.fishpool.com/~q-funk/M-E/
The Atari TT030 Homepage   http://www.megacom.net/~q-funk/TT030/
New MiNT Distribution   http://members.tripod.com/~TT030/nmd.htm

---------- Forwarded message ----------
Date: Mon, 15 Mar 1999 16:01:25
From: Thomas Much <support@aktienman.de>
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Y2K compliance

Max Kramer <maxk@tig.com.au> wrote:

> Will my old reliable 1040 & 520 ST's make it into the next century?

See http://www.snailshell.de/y2k.html, there's a link to an Atari IKBD

bye, Thomas

---------- Forwarded message ----------
Date: 15 Mar 1999 11:42:52 GMT
From: Philip Taylor <philipt@dial.pipex.com>
Newsgroups: comp.sys.atari.st
Subject: Millennium bug

TOS 2.06 and Y2K
The ST(E) Millennium Bug

Gemdos stores the date in one word, with bits 9-15 being the year
minus 1980.  Hence the year 1990 is stored as 10, 1999 as 19, and
2000 as 20 etc.  With 7 bits any number up to 127 can be stored,
corresponding to 2107. (Gemdos may limit this to 119 ?).

The Gemdos functions tgetdate ($2A) and tsetdate ($2B) invoke the
lower-level Xbios routines Gettime (23) and Settime (22).  These
routines read the date/time from, and send it to, the Intelligent
Keyboard Controller or IKC.  [This is a big 20-pin chip on the
underside of the keyboard].  The IKC contains the "real-time" clock.
Now, data are transmitted to and from the IKC in packed BCD format:
each byte containing two decimal digits.  One byte is allocated to
the year, hence a two-decimal digit year is stored and processed in
the IKC.
For the year 1999, stored by GEMDOS in memory as 19 (25 hex), one
might expect that the value 19 BCD would be the byte written to/read
from the IKC by Settime and Gettime.
But no, these routines add/subtract an offset of 80 decimal.  Thus
for the year 1999, Settime gets the value 19 from tsetdate (or by
direct Xbios function call), adds 80 to produce 99, and sends 99 as a
2-digit BCD to the IKC.  Conversely, Gettime gets the BCD number 99
from the IKC, subtracts 80 from it, then packs 19 into the prescribed
DOS format.
So what about year 2000?  This is stored by Gemdos as 20 (well within
its capable range), but Settime changes this to 100 and then of
course fails to encode this as a two-digit BCD.  [In fact Settime
sends illegal nibbles to the IKC, which are ignored].

As far as I know, Settime and Gettime are the only routines used for
communicating with the RTC in the IKC.  So it does not matter if the
IKC stores the year 19 or 99, so long as Settime and Gettime agree to
add/remove the same offset.  I suggest zero offset.  To stop Settime
adding 80 to the year, the patch for TOS 2.06 UK (and probably German
version too) is:
1F43 $80 change to $00
and to stop Gettime subtracting 80 from the year:
1E91 $50 change to $00

For other versions of TOS, look for strings beginning with
 $80123c001b...  and $501400e982...

With these changes, TOS can handle dates up to 2079.  For example,
using Control Panel to enter the year 15, Gemdos interprets this to
be 2015, subtracts 1980 giving 35, passes this value to modified
Settime, which now stores 35 BCD correctly in the IKC.

In a date-sorted window, files of the year 00 are correctly shown as
later than those of 99.

OK, all ready for the next century now...

Most of the above information is taken from "Atari ST Internals",
Abacus Software 1988.
The patches have been tested using the TOS RAM Loader program from
Pera Putnik

Philip Taylor, Glasgow, Scotland       philipt@dial.pipex.com