Re: [hatari-devel] MegaSTE cache emulation issues

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 29/06/2025 à 14:05, Christian Zietz a écrit :
> Nicolas Pomarède schrieb:
>
> > That's strange, because M68000_BusError() will flush caches in the case
> > of the MegaSTE, I need to check this.
>
> This might just a matter of the order in which things happen.
>
> For example in this code path, I think (but please double check my 
> analysis!) that the cache flush in M68000_BusError() is called via 
> wait_cpu_cycle_write_megaste_16():
> https://framagit.org/hatari/hatari/-/blob/v2.6.0/src/m68000.c?ref_type=tags#L1637
> ... whereas the cache update via MegaSTE_Cache_Write() only happens 
> *after* the flush.

Hi

the code was written in this order because after the write to the cache 
it is possible to enable cache consistency check at compile time when 
MegaSTE_Cache_Check_Entries() is called.
So in normal case, data must be written to RAM first to be compared with 
the cache after (else switching order to do write to cache then write to 
ram would indeed handle this bus error / flush issue)

but in fact, address error are not taken into account too, so a word 
read/write to ram that would fail at odd address would still update part 
of the cache, which would be wrong (I don't have megaSTE HW to test, but 
I guess the internal cache logic prevents update in case of address 
error during a read/write ?)

I will write a more generic version of MegaSTE_Cache_Addr_Cacheable() to 
handle these corner cases

Nicolas