|Re: [hatari-devel] IDE 32-bit data transfer|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 22/05/2016 13:36, Thomas Huth a écrit :
Am Thu, 19 May 2016 20:39:28 +0200
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
Le 19/05/2016 17:40, Roger Burrows a écrit :
Agreed, for 68000s. In this case, we're running on an emulated
Falcon. The code works fine on a real Falcon.
For cpu >68020, I think the winuae code is not completely hooked to
Hatari yet to handle long accesses. It's already on my todo list, but
in the meantime thomas' fix will do the job.
I think the problem is that all those memory banks are declared with
CE_MEMBANK_CHIP16 in memory.c. That way, the code in the mem_access*()
functions in newcpu.c splits the access into two WORDs.
Should we use CE_MEMBANK_CHIP32 at least in TT mode? The Falcon
also had a 16-bit bus only, right? So staying with CE_MEMBANK_CHIP16 is
more suitable in Falcon mode, I guess?
yes, that's part of the missing thing. But also not all RAM is capable
of 32 bits accesses under falcon. Standard ram (shared with video) is 16
bits wide, extra fast ram is 32 bits and some IO regs can be 32 bits.
In the meantime, I put _CHIP16 for all memory types (except fast ram),
but this should be measured on real HW to adapt our memory bank
Doing so will require precise cycle counting when running at 16 or 32
MHz (see previous mail about "wrong" 4 cycle rounding) to be able to
compare Hatari results with real HW.
So, before changing memory type, I'd like to unstack a few things I have
in progress :
- wakeup states for STF (not related to this)
- more accurate x2/x4 clock and cycle rounding (code is somewhat
complete but would conflict with some wakeup states changes, so can't
commit at the moment)
- adapt memory type for each bank and measure/compare bus access
penalties in those cases (video access must be take into account to
round cpu accesses when necessary).