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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 04/11/2017 à 12:22, Nicolas Pomarède a écrit :

> > 2) In TT mode (68030/16/MMU is what I tested) I had no issues until I 
> > added my intro, and then something really strange happened. It's been 
> > tested not to happen on real hw, but this issue is the same on Hatari 
> > v2.0 and current dev versions it seems. This is in the Audio Sculpture 
> > code, so something changes in the emulation from when I only loaded 
> > the AS binaries compared to when running the (TOS friendly) intro 
> > beforehand as well. But, on real hw it's fine.
>
> Will look at this later.

Hi

I gave a look to this ; always complicated to debug, because caches are 
rather complex on the 68030. So far, I found nothing in the cpu code :(

But I see the intro does some uncompressing or copy some code to other 
part of the memory. Toni told me he had no idea of a bug in the curent 
i-cache code (which is certainly true, because all 68030 programs would 
likely crash rather often if i-cache was wrong).

So, it's quite likely that this uncompressing / copying of code is 
messing with the internal i-cache state and will make audio sculpture 
crashes later when accessing one of those addresses.

You can go the brute force way and disable the i-cache completely in the 
start of your intro (and in the start of AS). This should fix the problem.

A better solution if you want to keep i-cache enabled would be to flush 
it after each parts that writes code to memory (uncompressing and so on).
Hopefully, cleaning i-cache after such parts should fix the problem

(some packers/depackers automatically do that for you, but I don't know 
which one you used)

Nicolas