Re: [hatari-devel] Hatari/EmuTOS Conflict

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

On 05/06/2013 23:09, David Savinkoff wrote:
> Hi,
>
> I tested both developmental Hatari and EmuTOS and found that
> Hatari Must be reset alt-r after loading the EmuTOS image when
> (Hatari > System > Patch TOS for faster boot)
> is Not selected. Otherwise EmuTOS takes a Long time to boot
> And the mouse cursor does not move in Hatari.
>
> Furthermore, The latest Hatari Must be reset after
> loading the EmuTOS 0.8.5 image even when
> (Hatari > System > Patch TOS for faster boot)
> IS selected.
>
> Thus, Hatari Must be unconditionally reset after loading
> the EmuTOS image.
>
> Atari ROMs work flawlessly of course.
>
> Hatari/EmuTOS tested with etos256us.img and etos256uk.img images.
>
> David

Hello

there was a thread about this in february 2013 "IKBD regression with 
EmuTOS".

It was about Emutos 0.90, but from the discussion it appeared there were 
2 potential problems :

 - emutos before 0.90 did not correctly wait for the ikbd reset to 
complete (by waiting for 0xf0 or 0xf1) ; with the new acia code added 
after hatari 1.6.2, this caused a buffer overflow in the ikbd, and 
keyboard packets were ignored -> a reset is needed to reset the acia's 
buffer.

 - from the tests with emutos on a real STE, it seems the serial line 
must be started after a cold reset of the acia, even if the acia control 
register is not initialised (this is not done in the current dev 
version, I still need to add it before 1.7 is released, but that's a 
trivial fix). This doesn't stop "normal" TOSes from working, because 
they correctly flush the reset byte and init acia after.


So, for current hatari dev version, could you try with emutos 0.90 ? It 
should fix the problem, as Vincent Riviere added a pause in emutos to 
wait for the ikbd reset with a possible timeout (when no keybpoard is 
connected)


Nicolas