Am Wed, 18 May 2016 22:00:23 -0400
schrieb "Roger Burrows" <anodyne@xxxxxxxxxxxx>:
On 18 May 2016 at 23:31, Vincent Rivière wrote:
I noticed that Hatari IDE emulation worked fine with EmuTOS 0.9.1,
but it has been failing since EmuTOS 0.9.3.
The cause is that EmuTOS now uses 32-bit data transfer by default.
This means that the IDE data register is read using move.l instead
of move.w.
This works fine on real hardware.
Hatari should be fixed to allow that.
As a follow-up to that, it seems that EmuTOS's longword access to
$f00000 (via a move.l) generates a wget($f00000) followed by a
wget($f00002) rather than an lget($f00000).
Right. It's a new "problem" that only occurs with the WinUAE CPU core,
as far as I can see. I think this only occurs in certain CPU modes,
like 68000 mode or when cycle-exact emulation is enabled. In these
cases, the WinUAE core seems to split LONG word accesses into two WORD
accesses to simulate real bus behavior.
So this never happened with the old UAE core (which was still the
default including the last official release of Hatari), and thus we
never noticed that WORD accesses to $f00002 were not working as
expected (LONG accesses to $f00000 worked just fine).
Anyway, I've now committed a fix, please check again whether it is
working now as expected.