|Re: [hatari-devel] IDE 32-bit data transfer|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 19/05/2016 04:10, Thomas Huth a écrit :
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
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.
WinUAE's behaviour is the correct one : appart from accessing internal
register (Dx, Ax), the 68000 can only access 16 bits at a time on the
external bus. Considering a .L access could be made in one go was an
approximation of the old uae core, but it's wrong and it caused problem
with programs requiring cycle exact mode (color plasma, ...) and with
some game protection using self modified code to alter the prefetch
queue (2 words on 68000).
Only cpu > 68020 could access 32 bits in one single access.
On 68000, accessing a .L will cause 2 .W accesses ; code that assumed it
was 1 .L access (based on old/wrong uae core) should be fixed.