Re: [hatari-devel] New SYNC release. New Hatari bugs found ;)

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 03/12/2017 à 21:12, Troed Sångberg a écrit :
> Well, my tracing was under Hatari (both v2.0 and latest dev at the time) 
> and it was always those exact instructions. I did use TOS 3.06 Swedish 
> though if we need to go hunting for differences in setup :)
>
> The loading of the intro is done by TOS from AUTO and will differ 
> between (at least) TOS versions. The included color/mono binary is then 
> depacked and moved to $c000 (always) from where it's executed. The crash 
> happens sort of soon (but thousands of instructions) after that.
>
> Indeed it's possible/likely that the same addresses have been executed 
> from during the AUTO-loaded intro as is then reached from the 
> $c000-based execution of the AS binary.


Hi

after much tracing, I was able to track down the bug.

regarding the data/instr caches, tos itself cleans the cache while doing 
some file accesses (this is around $e00602, tos reads 3919 from CACR, 
then write 3111).

So, by the time AS main program is loaded using Fread, cache will be 
correctly cleared (note that UPX packed used for the intro correctly 
clears caches on 68030 too)

Then main program starts and write 3010 to CACR ; this doesn't flush 
caches, but it disables instr/data caches.
This is where the problem lies : I saw a bug in the 68030 instr cache 
handling that didn't disable cache read :(  So, even if cache was not 
updated anymore, it was still used, and since it was not flushed after 
decompressing main program (it's not necessary), then cache was wrong 
and we could get some wrong opcodes if the instr cache hit a location 
where data was written during decompressing.

There was also a minor bug in 68020 cache, but less annoying for us as 
atari machines don't really use 68020.

I made a quick fix for this and reported it to Toni ; I will merge the 
"official" changes from WinUAE later.

One less cache problem, hopefully we will have no more of them :)

Nicolas