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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

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


Nicolas