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

[ Thread Index | Date Index | More Archives ]

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.


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 :)


Mail converted by MHonArc 2.6.19+