xbios year 2000 problem on atari sts

The problem definitely exists on Atari STs using TOS levels 1.0, 1.2, and 
1.62.

I do not have access to any other TOS levels so the problem may or may not
exist on TOS levels after 1.62.

The XBIOS problem is such that dates after 1999 will not be handled correctly
by the following XBIOS functions:

Trap#14 - Function #$16 Set 32-bit DOS format date & time.
Trap#14 - Function #$17 Get 32-bit DOS format date & time.

For years from 2000 to 2059, the consequence is that the date part of the 
SetDate&Time function is ignored and the GetDate&Time date part return 
value remains unchanged from when it was last successfully set.

For years from 2060 to 2107, the GetDate&Time date part return 
values are from 2028 to 2075 respectively.

The good news is that the GEMDOS Trap #2 - Date and Time functions 
work correctly.
The bad news is that a lot of programs use the XBIOS functions and those
programs that do so will need a patch.

Associated Year 2000 Problems
-----------------------------------------------
I have encountered several programs that were designed so as to prevent
dates greater than 1999 being entered. These programs will need to be 
patched as necessary. 

Clive Williams, as mailed to John Whalley 30/12/99, used with author's permission.

Clive also posted the following to c.s.a.s, which adds a little further information:

Here is a defintion of the problem. Hope it is of interest.

_Atari ST Time-of-Day Clock Problems_

Definition of the Problems
1. There are two Time-of-day Clocks in the Atari which are not maintained
in
sync by the hardware or operating system.
2. One of the Time-of-day Clocks fails to operate for dates after 31 Dec
1999.

_Scope of the Problems_

The problems exists on Atari ST machines with TOS levels from 1.0 to 1.62.

_Background to Atatri ST Time-of-Day Clock Problems_

When the Atari ST was released in the mid 1980's there were at least three
design errors associated with the Time-of-Day Clock. These were:

_1. Two Time-of-Day Clocks_

Two related but different Time-of-Day(TOD) Clocks mechanisms were included.
This
does not make any sense given the associated functions that were provided in
the
DOS and XBIOS sections of TOS. The TOS Version 1 code associated with XBIOS can
be examined at the addresses shown in the TOS Addresses table below.

The two TOD Clocks can be independently set to any date/time, and in
consequence, Get Date/Time frequently gives unexpected results if the clocks
are
not in sync.

Since the choice of TOD Clock Function rests with the application programmer,
there is likely to be many date incompatible programs. There are various
Clock-Sync programs that may help to get the clocks in sync up until 31Dec1999.
After that a software fix is needed for the XBIOS Clock functions.

_2. XBIOS SetTime/Date Function_

The XBIOS SetTime/Date function, which accesses the IKBD hardware via the IKBD
serial Binary Coded Decimal (BCD) interface, for some strange reason, has #$80
added to the BCD Year value before transmitting it to the IKBD.

Programmers have already gone to the trouble of subtracting 1980 from any date
inputted by the user so that the year 1980 from the user will be passed to
XBIOS
(or DOS) as 0.

The consequence of this is that year values greater than BCD 19 will be invalid
after adding #$80. e.g. BCD_19 + #$80 = BCD_99 which is valid but BCD_20 + #$80
= BCD_A0 which is invalid. The IKBD ignores invalid BCD values so the year is
not updated in the IKBD although the time is updated.

_3. XBIOS GetTime/Date Function_

The XBIOS GetTime/Date function, which also accesses the IKBD hardware via the
IKBD serial Binary Coded Decimal (BCD) interface, compensates for 2. above by
subtracting decimal 80 from the Year AFTER it has been converted from BCD.

This means that the Get Year is not the same as the Set Year for input dates
above 2060. The Set years 2060 to 2107 map to Get years 2028 to 2075.

This may sound a bit academic, but it does affect some of the possible software
fix methods.

This also accounts for frequently getting the year 2028. When the date in the
IKBD rolls over to an invalid number and the IKBD passes back BCD_00. Since
BCD_00 from the IKBD Clock becomes BCD_00 - decimal 80 = #$B0, then the top
7-bits are then right-shifted to give #$30 (48 decimal) which is passed back to
the
application. Add 1980 in the application and you get 2028. Magic, but a pain.

 Clive Williams
 Latest update: 02Jan2000