Re: [hatari-devel] Hatari/EmuTOS Conflict

[ Thread Index | Date Index | More Archives ]

On 05/06/2013 23:09, David Savinkoff wrote:

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.



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)


Mail converted by MHonArc 2.6.19+