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

[ Thread Index | Date Index | More Archives ]

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

Mail converted by MHonArc 2.6.19+