| Re: [hatari-devel] DSP check freeze in Tautology II startup |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] DSP check freeze in Tautology II startup
- From: David Savinkoff <dsavnkff@xxxxxxxxx>
- Date: Mon, 3 Aug 2015 18:04:57 -0600 (MDT)
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=telus.net; s=neo; t=1438646697; bh=0evi5Hd88XnOGZdIkYIrz5MkHBBKy1k03L5rwa+Fob0=; h=Date:From:To:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type:Content-Transfer-Encoding; b=R5242MGW68R0kj+sco68tiZ8MCKNE+49YCkGyojhj0NK1V3UyyZb3gSOwNF+P9vJQ jXzo6cEHoMV03tT9sESce7fHhWybAU+Twr7+2bpCeGD/Kbt+++T+iENPXYhNImMa3k NQw7AI1JvjLBKDs9IDKQMGj2Qj3lI5vP/YXzgVI5IF6AAjS+Hvn4cJqHxMnDPxxW3n vyfC2VwpKT4EPoMkRSRq/ZUE6FjStJUDUpMZkz39cr+atZDkyq2hqWrFuKWfqi1CC+ 2UH8PYuTcSt7rq21ci8/DedB5YphrVARMJkBRm9bEj7aQd6xc/0DdUFw9evLDPoA/i OBgnD2L59anig==
- Thread-index: ZQkRMtZzm5FPcfZE7ge6+zqoHcdw7A==
- Thread-topic: DSP check freeze in Tautology II startup
----- Eero Tamminen wrote:
> Hi,
>
> On maanantai 03 elokuu 2015, Nicolas Pomarède wrote:
> > thanks to Toni's work on WinUAE, the 68020/30's pipeline is now much
> > improved and will stop prefetching when one of the opcode in the queue
> > will trigger a branch (rts, jmp, bsr, bra, ...).
> > This means the cpu will not always prefetch 3 words in advance, and the
> > extra word that was prefetched in Tautology II is not loaded anymore,
> > which allows the self modified code to work.
> >
> > This should fix other games/demos that uses the same dsp replay routine
> > for NTK4 modules.
> >
> > Eero, do you confirm it works for you too ?
>
>
> Tautology II & Kwiks.pd work now fine.
>
>
> Golden Island still gets stuck to DSP check:
> ---------------------------------------------------------------
> CPU=$d41d8a, VBL=5147, FrameCycles=68, HBL=0, LineCycles=68, DSP=$110
> $00d41d8a : 0813 0000 btst #0,(a3)
> 50.00% (37560001, 150240000, 0, 0)
> > profile addresses
> # disassembly with profile data: <instructions percentage>% (<sum of
> instructions>, <sum of cycles>, <sum of i-cache misses>, <sum of d-cache
> hits>)
> $00d41d8a : btst #0,(a3) 50.00%
> (37560001, 150240000, 0, 0)
> $00d41d8e : beq.s $d41d8a 50.00%
> (37559999, 150239996, 0, 0)
> Disassembled 2 (of active 2) CPU addresses.
> > r
> D0 00000000 D1 00000002 D2 00000010 D3 0000FFFF
> D4 00008000 D5 C000003F D6 00000003 D7 000001E0
> A0 00D42BDC A1 00D42BD8 A2 00D42BDC A3 FFFFA202
> A4 FFFFA205 A5 FFFFA206 A6 0010D4F8 A7 0010D4A4
> USP 000202B4 ISP 0010D4A4 SFC 00000000 DFC 00000000
> CACR 00003111 VBR 00000000 CAAR 00000000 MSP 00000000
> T=00 S=1 M=0 X=0 N=0 Z=1 V=0 C=0 IMASK=6 STP=0
> 00D41D8A 0813 0000 BTST.B #$0000,(A3)
> Next PC: 00d41d8e
> ---------------------------------------------------------------
>
> It works with (older) OldUAE, but not with latest WinUAE,
> even when using --cpu-exact off.
>
>
> - Eero
>
Maybe the btst bset bclr instructions influence the pre-fetch/cache
because of an uninterruptible read-modify-write addressing cycle
for the use of race-condition-free semaphores.