|Re: [hatari-devel] One bug, one warning, one :)|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 13/11/2012 20:25, David Savinkoff wrote:
Hatari changeset 4072 and previous work, but newer changesets
have the same problem where the mouse freezes near the center
of the screen (whereas LOAD MOD is in the upper right of Hextracker).
Note that the mouse works in Hextracker until LOAD MOD is activated.
The new screen is fully displayed with the mouse cursor frozen near
the center of the screen. atl+arrow keys will move the mouse cursor.
Upon exiting the screen with the frozen mouse, the mouse resumes
working in the main Hextracker screen (where LOAD MOD is).
Upon exiting Hextracker, the mouse is frozen in Hatari in the same
manner. The mouse works properly in the SDL menu and on my desktop
during Hextracker problems.
Does the acia.c/ikbd.c emulation actually shift bits (or just time delay)?
Does the bit shifting/sampling occur on rising, falling, center of high,
or center of low, or ... ?
I'm wondering if the mouse packets are corrupted.
The above is all one question where a single NO is a reasonable answer.
What do you think?
Since acia/ikbd "talk" over serial line, a bug in the code could create
an error where both acia and ikbd serial code is not synced with the
other and bytes would be lost.
But if that's the case, only a few bytes would be lost, then the
start/stop bits should allow being in sync again.
And what is very strange is that mouse doesn't react for you, but
keyboard and arrow keys are still working ; so bytes seem to go between
acia and ikbd, else keyboard would not work either.
Can you try running with "--trace ikbd_all,acia" and see if some error
messages are present (warning, this will give lots of trace, redirect
this to file).