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

[Thomas Huth <th.huth@xxxxxx>]

Am Sun, 22 May 2016 15:25:58 +0200
schrieb 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. 

Looking at the Falcon's schematics, only 16 out of the 32 data bus pins
are connected at all, so on a plain Falcon, I think everything is 16
bits only.
For 32-bit Fast-RAM, you certainly needed an accelerator with a
separate CPU, like the the Mighty Sonic or Afterburner040. (So in
Hatari, I think we can assume 32-bit accesses for Falcon Fast-RAM,
since you can't have memory above the 24-bit barrier on an unmodified
Falcon anyway)

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

Ok, thanks for sharing that information - and I'll keep my hands of
that part now, so I don't interfere with your work ;-)

 Thomas