| Re: [hatari-devel] Error in SetClock / ReadClock |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
On 28/12/2012 11:04, Thomas Huth wrote:
Ok, never mind, the problem with XCONTROL does not occur with hg tip
anymore. Maybe I forgot to update my checkout after doing a pull, sorry
for the confusion.
I've tested some more revisions, and it seems like the problem vanished
with your commmit e0e2dd72877a (Better timings for the bytes returned
by IKBD). So this was rather related to IKBD timing than to your
new IKBD clock function.
hello
In fact I thing the better/different timings are hiding the problem, but
the cause was maybe similar to "Zombi" and it's possible the crash could
still happen.
By the way, when running XCONTROL on TOS 2.06, the problem with the bad
year does not occur with your new IKBD set-clock code. Don't ask me why
it needed the overflow hack with the old code, but as long as it works
fine now, I think we can forget about that problem, too.
It's because when going from byte/bcd to internal integer (using
time/localtime) and back to byte/bcp again, you need to imply the
century in the conversion. But at the ikbd level, there's no century
notion, you just have 6 bytes that get incremented by 1 and propagate to
another one when the max value is reached.
However, the problem with Zombi still persists. Funnily, the clock
seems to work as long as you don't move the mouse in the game. It just
freezes as soon as you move it - which you have to do of course because
this game is played with the mouse :-/
You're right with the mouse. I looked at the traces yesterday and at one
point the relative mouse packet (0xf8 + 2 bytes) is truncated by the
readclock bytes. So 0xf8 contains 2 bytes from readclock, and the TOS
waiting for 7 bytes starting with 0xfc for the clock only get 5 bytes.
At that point, the game stops working correctly.
I will have a look at the ring buffer used to transmit byte from ikbd to
acia, it's seems sthg is overwritten.
By the way, with previous ikbd (hatari 1.62), Zombi's clock started at
12:00, now it correctly starts at 11:15 :) (this is because zombi uses
setclock with "0" for several bytes, which gives problem when converting
with time/localtime)
Nicolas