[hatari-devel] IKBD clock year

[Eero Tamminen]

Hi,

On keskiviikko 20 huhtikuu 2011, Thomas Huth wrote:
> > schrieb Eero Tamminen <oak at helsinkinet.fi>:
> > > > I have just fixed it in CVS, so they are now respectively handled
> > > > as 2000 to 2079. The range 80 to 99 is still handled as 1980 to
> > > > 1999.
> > > > 
> > > > So my question is:
> > > > Does Hatari return 0xb1 intentionally, or is this a bug ?
> > > 
> > > I think it's a bug.  Could you try the attached patch?
> > 
> > Looking at the comment that you've removed with your patch, this was
> > not a bug in Hatari but the emulated behaviour of the real machine...
> >
> > Have you tried your change with original TOS (without RTC)

No I hadn't.

But I just added a command line option for RTC so that it's a bit easier to
test (and can be changed from the debugger & through control socket).


> > to see whether it still shows the correct date?
>
> I've just checked it ... and yes, at least TOS 2.06 now calculates the
> year wrongly,

Without RTC, both TOS 1.6 & TOS 2 seem to get the date wrong, but TOS 3 & 4
get it right.

Reverting the BCD calculation fixes the date only for TOS 2, not TOS 1.6.
With RTC the date is fine also for all TOSes (at least for anything with 
which xcontrol.acc works).

Btw. Funnily, if I use "--rtc off --machine st", xcontrol.acc bus errors on
TOS 2 startup.  TOS 2 works fine with "--rtc on --machine st" and
"--rtc off --machine ste" though.

Clockly 2.37 shows time wrong regardless of how BCD is set.


> new files get the timestamp 2039 instead of 2011.

File timestamps (at least on GEMDOS HD) were fine, I saw the issue only in
xcontrol.acc.  What you do to get the timestamps wrong?

And what about the earlier TOS versions, what would be the best way to test
them?


> So please revert your change!

Well, I think first somebody would need to test what happens on real HW.
With TOS 2.06 or one of the other earlier TOSes if they now get the date
wrong with Hatari.  Who knows, maybe it even differs with different ST
models... :)

(According to Vincent, Steem also sets the value to 0x11 instead of 0xb1,
so that would then be wrong too...)


If it turns out that the previous BCD conversion was more accurate one,
the attached patch reverts the change and adds better comment about
it + fixes BCD function to use SDL types like everything else.


	- Eero
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ikbd.diff
Type: text/x-patch
Size: 752 bytes
Desc: not available
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20110421/87a7830e/attachment.bin>