Re: [hatari-devel] One bug, one warning, one :)

[David Savinkoff <dsavnkff@xxxxxxxxx>]

On Tuesday 13 November 2012 00:40, Eero Tamminen wrote:
> Hi,
>
> On tiistai 13 marraskuu 2012, David Savinkoff wrote:
> > Hatari changeset 4072 is the most recent without the new Hextracker
> > mouse problem on my system. I hope this helps. If you have suggestions
> > on tracking down what part of ikbd.c or acia.c to look at, please let me
> > know. (maybe main.c or ioMemTabST.c also)
>
> As it works fine for us, first we should find out what differs.
>
> MD5 of my tracker binary is:
>     $ md5sum hext837.prg
>     9d8af2ab5fd5488d7c9645d2eeed6c34  hext837.prg
>
Check.
>
> To discount differences in config, start with empty one:
>     $ echo "" > empty.cfg
>     $ hatari -c empty.cfg --machine ste --tos etos512k.img ./hext837.prg
>
Check.
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?

David
>
>     - Eero