Re: [hatari-devel] IDE 32-bit data transfer

[ Thread Index | Date Index | More Archives ]


If there's a need to measure real performances on a real Hardware Falcon, I can help.
Just ask.


Le 22/05/2016 15:25, Nicolas Pomarède a écrit :
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 configurations.

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).


Mail converted by MHonArc 2.6.19+