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

[Troed Sångberg <troed@xxxxxxxxxxx>]

Not sure I follow :) It works on real hw. Thus there must be an issue in the emulation even if Toni does not know about it.

(When tracing it I must confess that it didn't seem like a cache issue, but I'm not absolutely certain)

UPX, latest version, is the packer used. I don't know how much they test on 68030.

/Troed


Sent from ProtonMail mobile



-------- Original Message --------
On Dec 3, 2017, 17:32, Nicolas Pomarède < npomarede@xxxxxxxxxxxx> wrote:
> 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