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

[ Thread Index | Date Index | More Archives ]

Le 13/10/2012 00:02, Vincent Rivière a écrit :
On 12/10/2012 23:45, Nicolas Pomarède wrote:
Is that something that is specified in the original TOS ? Are you sure
TOS use this behaviour and this pivot year of 80 ?

No, I didn't find any reference documentation about this.

I used 1980 as pivot year to solve Y2K problems in EmuTOS because I
didn't find anything better.

OK, but then I think the possible pivot is TOS dependant.

You could use 80 in EmuTOS because most users are running it nowadays and there's little reason to believe someone has a real need to set its clock before 1980.
But maybe TOS 1.02, 2.06, ... had some different methods we don't know.

What I mean is that there should be no pivot notion in the ikbd (well, maybe there's one, but I don't think it's 80), it's up to the TOS to interpret this 2 digit value into a complete 4 digit year.

A fix to IKBD's SetClock should not necessarily have this pivot, but it should allow any year to be set without causing the reported problem.

A possible and completly different solution could be to not use the TimeOffset anymore, but only use SetClock to define year/month/.... and then on each VBL call a function IKBD_UpdateInternalClock that would add 1/50 sec or 1/60 sec, .. (depending on nRefreshRate) to the second counter, then propagate this to minute/hour/day/... counter.

This would make SetClock / ReadClock completly independant of any system call such as time() or localtime().

IMHO, this would be more "correct" from an emulation point of view : the ikbd receives "ticks" and increments the second counter (in the real ikbd, I guess they use the HD6301's timer to update the second counter).


Mail converted by MHonArc 2.6.19+