| Re: [hatari-devel] Problem with Hatari 1.6.2 and EmuTOS 192K ROMs |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel 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
the
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).
Nicolas