Subject: Re: [hatari-devel] New SYNC release. New Hatari bugs found ;)
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