Re: [hatari-devel] Problem with Hatari 1.6.2 and EmuTOS 192K ROMs

[Vincent Rivière <vincent.riviere@xxxxxxxxxxx>]

On 12/10/2012 22:48, Eero Tamminen wrote:
> Does EmuTOS call IKBD_Cmd_SetClock() before IKBD_Cmd_ReadClock()
> with some wierd value?

BTW, the following Hatari code looks like a Y2K bug:

src/ikbd.c, function IKBD_Cmd_SetClock()

NewTime.tm_year = IKBD_FromBCD(Keyboard.InputBuffer[1]);

As I said, EmuTOS sets year 12 at startup.
tm_year is an offset from 1900, so Hatari understands 1912. This will shock 
MinGW mktime() which will probably return -1.

When EmuTOS (or whatever) says year 12, it means 2012.
The classic way to solve this issue is to use 80 as pivot year:
- if 2 digit year < 80 then add 2000
- otherwise add 1900

Anyway, the upper limit of time_t is 2038, so 2 digit years from 39 to 79 
(understand: 2039 to 2079) will still not be representable with MinGW time_t.
Hatari should use another way to represent nTimeOffset, at least on Windows.

--
Vincent Rivière