|Re: [hatari-devel] EmuTOS + 68040 + GEMDOS drive|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 04/12/2017 à 08:29, Thorsten Otto a écrit :
On Montag, 4. Dezember 2017 00:23:53 CET Vincent Rivière wrote:
Maybe Hatari forgets to invalidate the data cache inside Fsfirst() /
Fsnext(), after filling the DTA.
It wasn't forgotten, there is a call to M68000_Flush_Data_Cache, which in turn
calls flush_cpu_caches(). However, the latter looks rather dubious to me:
- for 030, it will only do the flush if cpu_compatible ||
cpu_memory_cycle_exact, ignoring the force argument that was passed to the
This case is normal, because if neither cpu_compatible nor
cpu_memory_cycle_exact are set, then it means the cache is not enabled
in the emulation (so, nothing to flush)
- also for 030, it uses regs.caar to determine the address to invalidate.
However, caar is not set to the DTA address in this scenario (same is true
when it is called from other functions, like GEMDOS_Read())
I don't see that part with caar ? I put 2 parameters address and size in
M68000_Flush_Data_Cache to flush only a specific area, but they're not
used for now. so this just calls flush_cpu_caches() which flushes
- For 020/030, it also does some additional checks of the cacr register, but
not for 040, so it looks like this function can only be used after writing to
cacr, but not in the scenario used here.
vincent, which cpu settings are you using in your case ? "prefetch /
compatible" mode, or "cycle exact" or none ?