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

["Roger Burrows" <rfburrows@xxxxxxxxx>]

On 14 Oct 2012 at 19:11, Vincent Rivière wrote:

> 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.
>
I tried a simple test on my TT to set the IKBD clock.  (I expect the keyboard
processor behaves the same way on other models).  As specified in the original
Atari ikbd protocol document, a non-BCD digit in any subfield leaves that
subfield unchanged.  For example, setting a date/time of b2 11 05 19 18 17
leaves the year the same, but changes the month/day/hr/min/sec.  It does not
appear possible to store a non-BCD value in any subfield.

Also, I verified that the clock rolls over correctly from 99/12/31 23:59:59 to
00/01/01 00:00:00.

> 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.
>
I can't think of any way of testing this.  Again, according to the Atari ikbd
protocol document, and verified on my TT, a RESET of the ikbd processor does
not affect the date/time.

Roger