Re: [hatari-devel] MegaSTE cache emulation issues

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 30.6.2025 0.00, Nicolas Pomarède wrote:
> Le 29/06/2025 à 19:36, Eero Tamminen a écrit :
> > Sorry, the attached patch was missing compile fixes (forgot to commit 
> > them before "git format-patch"). Attached is the correct one.
>
> patch looks ok to me, thanks for going though this gemdos code (and 
> thanks to Christian for pointing to the faulty part)

Good, pushed.


[...]
> I used a function with the addr/len as parameter in case someone in the 
> future would like to make a more fine-grained version that would 
> invalidate only the changed bytes from the cache.
>
> But this can be quite complicated to do, because this part would need to 
> know the inner work of all 680x0 cpu with a cache + megaSte cache, which 
> would duplicate a lot of code / complexity from the cpu part.

Fair enough.


> In the meantime, the function indeed flushes the whole cache. This might 
> impact performance, but as gemdos HD emulation is not cycle exact 
> anyway, this should not be a problem.
>
> Also note that TOS itself will flush caches under certain conditions 
> when reading data from disk to RAM, doing the same in gemdos hd part is 
> not very different.

On re-reading the patch, I was a bit worried about adding flushing to 
Super() call, but then noticed that flush is only on the no-TOS test 
path. :-)


	- Eero

> Nicolas
>
>
> > On 29.6.2025 20.33, Eero Tamminen wrote:
> > > On 29.6.2025 0.15, Nicolas Pomarède wrote:
> > > > Le 28/06/2025 à 21:27, Christian Zietz a écrit :
> > > > This is indeed a missing flush ; it's done in PopulateDTA, 
> > > > GemDOS_Read or GemDOS_SFirst but not in this case :(  An in-depth 
> > > > review of gemdos.c would be needed to ensure this is the only 
> > > > missing case.
> > >
> > > I checked all places in gemdos.c where emulated memory is written, 
> > > but flush is missing.  There were quite a few places, see the 
> > > attached patch.  Does it look OK?
> > >
> > >
> > > Btw. I looked into m68000.c, and noticed it ignoring the memory 
> > > addresses / sizes given for the flush functions.  It always flushes 
> > > the whole (16KB) MegaSTE cache even when only few bytes need to be 
> > > uncached.
> > >
> > > Meaning that some things which on real device would be cached, won't 
> > > be with Hatari, at least after the updated GEMDOS HD fuctions are 
> > > called.
> > >
> > > I think this should affect only timings, which are unlikely to be 
> > > that critical after OS calls => I don't think it to be an issue, just 
> > > something that may need to be documented.