|Re: [hatari-devel] IDE 32-bit data transfer|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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
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
> 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 ;-)