Re: [hatari-devel] MegaSTE cache emulation issues

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 28/06/2025 à 21:27, Christian Zietz a écrit :
> Hi,
>
> while investigating why Spectre stopped working on Hatari 2.6.0 in 
> MegaSTE 16 MHz + cache mode (reported here https://www.atari-forum.com/ 
> viewtopic.php?p=482013#p482013), I found three issues with the cache 
> emulation. The attached test program illustrates all three. The first 
> two were "red herrings" as far as Spectre is concerned, the third is the 
> reason for the regression w.r.t. Spectre.

Hi

thanks a lot for looking into this :)

> #1: When no further files are found, Fsnext() zeroes the file name in 
> the DTA: https://framagit.org/hatari/hatari/-/blob/v2.6.0/src/gemdos.c? 
> ref_type=tags#L2965. However, it does not flush/invalidate the cache, as 
> M68000_Flush_Data_Cache is only called in PopulateDTA. (This would 
> presumably also affect CPUs with built-in data cache.)
> Note: As stated in the comments, C:\TEST.TXT must exist for the test 
> program to demonstrate this issue.

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.

At least this only affects Hatari when running in Gemdos HD mode, but as 
this is the simplest way to map a local directory to an Atari drive, 
this can be annoying.

> #2: When a write fails with a bus error (e.g. because of an attempted 
> write to ROM), the cache is still updated. I would have expected the bus 
> error to clear the entire cache as it happens on a real MegaSTE. The bus 
> error handling needs to be checked.

That's strange, because M68000_BusError() will flush caches in the case 
of the MegaSTE, I need to check this.


> #3: Due to the 24-bit address bus of the 68000, the MegaSTE does not 
> care about the top eight bits of the address. However, the current code 
> in Hatari https://framagit.org/hatari/hatari/-/blob/v2.6.0/src/m68000.c? 
> ref_type=tags#L1242 treats addresses where the top bits are not zero as 
> uncacheable. The address should be taken AND 0xFFFFFF before doing this 
> check.

you're right, I remember I thougth about this at one time, but forgot to 
take it into account in the code ... :(

> All of these issues can potentially cause hard-to-debug problems in 
> MegaSTE 16 MHz + cache mode in Hatari 2.6.0.
>
> Regards
> Christian

Can you provide a compiled version of your DTA test case ?

thanks

Nicolas