|Re: [hatari-devel] New SYNC release. New Hatari bugs found ;)|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: npomarede@xxxxxxxxxxxx, hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] New SYNC release. New Hatari bugs found ;)
- From: Troed Sångberg <troed@xxxxxxxxxxx>
- Date: Sun, 03 Dec 2017 11:37:23 -0500
- Authentication-results: mail1.protonmail.ch; dkim=none
- Feedback-id: lLIKE5s5wPbGAleCMIidZ9y4DJH8WwUbEWXleyLVKfLYBKSj12NDOlR8Bi3eYDk1jIinaDc2CAJDLk473wDNXw==:Ext:ProtonMail
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.
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.
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)