Re: [hatari-devel] Hatari/EmuTOS Conflict |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi David,
On 12 Jun 2013 at 10:27, David Savinkoff wrote:
>
> 1) Use a Windows Hatari build from June 8 or earlier to test without
> the "Default IKBD's ACIA to 9600 baud after a reset" patch.
>
> 2) Delete directory ~/.hatari
>
> 3) Execute Hatari,
> press f12,
> select: System
> uncheck: Patch TOS for faster boot
> select: Back to main menu
> select: ROM, and browse for latest etos256uk.img
> select: Back to main menu
> select: Save config
> select: Quit
>
> 4) Execute Hatari again while continuously moving the mouse
> across the Hatari window during the boot-up. Notice that
> the mouse is frozen in the Hatari window once EmuTOS has
> fully booted.
>
> 6) press altgr-r to reset Hatari; cursor is movable this time.
>
Although your problems as described above started this thread, my first concern
was to discover whether EmuTOS is correctly handling the interface with the
keyboard ACIA in Hatari. I have now tried the EmuTOS 256K UK image, and it too
seems to have the correct ACIA handling code.
I can verify that the problem you describe exists when using the most recent
EmuTOS CVS snapshot with the Hatari 1.6.2+ Windows version of around 2 June,
running as an ST on the old core (not winuae - I didn't check winuae). It
doesn't exist on the most recent Hatari version I have (around 10 June), nor on
version 1.6.1 (both using the most recent EmuTOS CVS snapshot).
So it seems more likely to be a Hatari problem than an EmuTOS one, though of
course that's not conclusive. I did try to determine what exactly was the
state of EmuTOS at the time of the hang, but I don't know enough about Hatari
debugging to be able to do that.
For anyone else chasing this bug: when it occurs, not only is the mouse cursor
frozen, but prior to that, EmuTOS does not see keyboard input at the point that
the welcome screen appears (e.g. pressing C to get an early console is
ignored).
Since this doesn't occur on current Hatari versions, investigating it probably
shouldn't be a high priority, but this kind of thing has a habit of biting
again later ...
Roger