|Re: [hatari-devel] Problem with Hatari 1.6.2 and EmuTOS 192K ROMs|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] Problem with Hatari 1.6.2 and EmuTOS 192K ROMs
- From: Vincent Rivière <vincent.riviere@xxxxxxxxxxx>
- Date: Sun, 14 Oct 2012 19:11:23 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=94ndupp8fzEddY0rSDpvZrNDmiGj/oWb4ch2lSw+3gE=; b=PPBqHEDNmB0OQovfHhkl2eD9E7WuIiiDBHDQUlkJL35UDYaOOab0NLbBS/oxlE/6mV 43F9Vzpw0KVhLvods9TvmtyoK53GyM9qS/TsUaSBydinKaAv/i8neCBdSgFcrs0+QcpH SX16FO4zhLnWci6WI+e5QcciDFDNTaza+4rvgcjHekpwgNkH8gK6pMYYiunbAaeWqBz2 7DZoWsCYXdQfhl0auSEALhooGgcfmJQQiAxoFV9toyoXS7juVjg9l8Ek6VfP79/clpe1 FxSeTKlyEhnQWch1/rUvD/6a6jI4oSuUvaF5Ix6WVv6XdiZsAK6jYsU6rxcN/i7Z7w4B 7wfA==
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
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.