Re: [hatari-devel] Error in SetClock / ReadClock

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 22/12/2012 13:31, Nicolas Pomarède wrote:
> Hello
>
> while comparing some IKBD results on a real STF with Hatari, I noticed
> an error.
>
> On a real ST, if you write :
>
> $1b, $01, $02, $03, $04, $05, $06  (setclock)
>
> then sending readclock $1c immediatly will return
>
> $fc, $01, $02, $03, $04, $05, $06
>
> -> we get the same bytes
>
> But on Hatari, we get :
>
> $fc, $b2, $12, $22, $13, $15, $20
>
> same test a few minutes later returns :
>
> $fc, $b2, $12, $22, $13, $28, $21
>
> a few seconds later :
>
> $fc, $b2, $12, $22, $13, $28, $43
>
> Is there a problem with the time(NULL) / nTimeOffset / localtime
> conversion ? Something seems wrong, it seems the setclock is ignored and
> the returned bytes are based on the real time, which shouldn't be the case.
> This should always return the same bytes in that case.
>
>
> Nicolas

Hello again,

I have the feeling we do something maybe too "clever" when emulating the 
ikbd's clock by trying to map ikbd's internal date/time with the 
system's time (with all the problems that can arise when considering 
different OS and their time's handling).

I'm actually disassembling the real ikbd's to see how it behaves :

 - ikbd stores date/time informations in RAM $82 - $87 in BCD format

 - bytes sent with setclock are checked to see they're in the range 
$00-$99 (BCD coding). Each byte in the wrong range is ignored and the 
ikbd keeps the previous version in the RAM.

 - readclock just returns bytes $82 - $87 without doing any 
computations or BCD conversions

 - a timer maintains the date/time in BCD format (I need to check this 
part to see how overflow are handled)


So, would someone object if I changed ikbd.c to behave the same :
 - check BCD encoding in setclock and store bytes
 - return BCD bytes in readclock
 - add an update function (called from the VBL for example) that would 
maintain the ikbd clock by updating it every second (in emulation time, 
not in real system time)

This means we completly remove OS specific date/time conversions (time, 
localtime, mktime) and all the possible nightmares that go with them.


In that case, the emulated machine would default to 1985 or sthg like 
that at first boot, which can be annoying when dealing with harddisk 
mounted on the real filesystem.
So, we could have an option "init ikbd clock on boot" that would do only 
one localtime() call.

This way, the machine has a correct date/time at boot, but then it 
updates independantly of the system (which means if you pause emulation 
for 8 hours in 'Captain Blood' or 'Zombi' for example, you don't loose 
your game when you unpause it)


Nicolas