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

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

On 14/10/2012 16:44, Thomas Huth wrote:
> AFAIK the TOS versions 1.x do not use the IKBD clock at all. TOS 2.06
> seems to interpret the year in a special way: It expects the BCD year to
> overflow for years >= 2000, e.g. the year 2012 has to be represented as
> 0xB2 instead of 0x12. So maybe EmuTOS should use this incoding, too?

Hmmm, I'm puzzled.

That 0xB2 looks more like a Y2K bug in TOS 2.x rather than a feature. I 
wonder how the real IKBD clock behaves after that. Does it bump to 0xB3 the 
year after? This should really be investigated on real hardware to see how 
it behaves.

On the other side, I think that EmuTOS should only reset the IKBD clock if 
the date read is bogus (not initialized), but I don't know how to test that 
(again, tests on real hardware should help). Since the date returned by 
Hatari is always good, EmuTOS will never try to set it.

> Anyway, I now added a check for the NULL pointer in Hatari, so that at
> least the crashes should be gone.

Beware, IMHO the root of the bug was mktime() returning ((time_t)-1) on 
MinGW. Consequently, localtime() returned NULL. So the right fix is to test 
the mktime() return value first. Anyway, also testing the return value of 
localtime() does not hurt, too.

--
Vincent Rivière