[hatari-devel] Fwd: Re: Perhaps this evocate something to you...

[Laurent Sallafranque]

Yes, I'm on it ;)

At 16 Mhz, the DSP + 68030 get stuck there.

00030012 1d6b 0001 0005           MOVE.B (A3, $0001) == $001d1dad,(A6,
$0005) == $ffffa205
00030018 3d6b 0002 0006           MOVE.W (A3, $0002) == $001d1dae,(A6,
$0006) == $ffffa206
0003001E 7000                     MOVE.L #$00000000,D0
00030020 082e 0000 0002           BTST.B #$0000,(A6, $0002) == $ffffa202
00030026 67f8                     BEQ.B #$fffffffffffffff8 == $00030020 (T)
00030020 082e 0000 0002           BTST.B #$0000,(A6, $0002) == $ffffa202
00030026 67f8                     BEQ.B #$fffffffffffffff8 == $00030020 (T)


At 32 Mhz, the DSP + 68030 continues to run *

00030012 1d6b 0001 0005           MOVE.B (A3, $0001) == $001d1dad,(A6,
$0005) == $ffffa205
00030018 3d6b 0002 0006           MOVE.W (A3, $0002) == $001d1dae,(A6,
$0006) == $ffffa206
0003001E 7000                     MOVE.L #$00000000,D0
00030020 082e 0000 0002           BTST.B #$0000,(A6, $0002) == $ffffa202
00030026 67f8                     BEQ.B #$fffffffffffffff8 == $00030020 (F)
00030028 102e 0005                MOVE.B (A6, $0005) == $ffffa205,D0
0003002C e188                     LSL.L #$00000008,D0


I look at the DSP side now...

Laurent


Le 20/01/2011 00:08, Nicolas Pomarède a écrit :
>  Le 19/01/2011 23:55, Laurent Sallafranque a écrit :
>>  >  What do you means by "it bugs" ? Crash ? Bomb ? Bad visual result ?
>>
>>  At 16 Mhz, it freezes at the following instructions after the 1rst
>>  screen is rendered :
>>
>>  00030020 082e 0000 0002 BTST.B #$0000,(A6, $0002) == $ffffa202
>>  00030026 67f8 BEQ.B #$fffffffffffffff8 == $00030020 (T)
>
>  You mean these 2 instructions are looping forever ?
>  It would mean ISR receive reg is always empty, so I think you would
>  need to see the corresponding DSP code being executed to see what it's
>  supposed to send back, the 68030 code alone won't help.
>
>
>>  Whereas at 32 Mhz, the animation continues to play correctly.
>>
>>  It looks like a DSP synchro.
>>
>>  This is a kind of tridi screen with letter morphing from W to A to T to
>>  E ...
>>
>>  WATERSHIP.
>>
>>  Regards
>>
>>  Laurent
>>
>>
>>
>>  Le 19/01/2011 23:50, Nicolas Pomarède a écrit :
>>>  Le 19/01/2011 23:37, Laurent Sallafranque a écrit :
>>>>  A good candidate for testing 16Mhz vs 32 Mhz is Watership.
>>>>
>>>>  It loads quickly and bugs immediately at 16 Mhz (but runs at 32Mhz).
>>>>
>>>>  I've taken 2 CPU traces : one at 16 Mzh and one at 32 Mhz and I've
>>>>  made
>>>>  a diff of the 2 traces.
>>>>
>>>>  Here is the result :
>>>>
>>>>  The 2 programs are running the first 3196 instructions the same way.
>>>>  Here are the latest instructions ran by both tests :
>>>>
>>>>  ...
>>>>  0002E226 4298 CLR.L (A0)+
>>>>  0002E228 51c9 fffc DBF .W D1,#$fffc == $0002E226 (F)
>>>>  0002E226 4298 CLR.L (A0)+
>>>>  0002E228 51c9 fffc DBF .W D1,#$fffc == $0002E226 (F)
>>>>  0002E226 4298 CLR.L (A0)+
>>>>  0002E228 51c9 fffc DBF .W D1,#$fffc == $0002E226 (F)
>>>>  0002E226 4298 CLR.L (A0)+
>>>>
>>>>  At line 3197, the 32 Mhz test continues to run the same 2 instructions
>>>>  as above.
>>>>
>>>>  But the 16 Mhz test does :
>>>>
>>>>  00E03C50 52b9 0000 04ba ADD.L #$00000001,$000004ba
>>>>  00E03C56 e7f9 0000 11ba ROLW.W $000011ba
>>>>  00E03C5C 6a48 BPL.B #$00000048 == $00E03CA6 (F)
>>>>  00E03C5E 48e7 fffe MOVEM.L D0-D7/A0-A6,-(A7)
>>>>  00E03C62 614a BSR.B #$0000004a == $00E03CAE
>>>>  00E03CAE 48e7 c080 MOVEM.L D0-D1/A0,-(A7)
>>>>  00E03CB2 2038 11bc MOVE.L $000011bc,D0
>>>>  00E03CB6 677a BEQ.B #$0000007a == $00E03D32 (T)
>>>>  00E03D32 4cdf 0103 MOVEM.L (A7)+,D0-D1/A0
>>>>  00E03D36 4e75 RTS.L
>>>>  00E03C64 0838 0001 0484 BTST.B #$0001,$00000484
>>>>  00E03C6A 672a BEQ.B #$0000002a == $00E03C96 (F)
>>>>  00E03C6C 4a38 11b1 TST.B $000011b1
>>>>  00E03C70 6724 BEQ.B #$00000024 == $00E03C96 (T)
>>>>  00E03C96 3f38 0442 MOVE.W $00000442,-(A7)
>>>>  00E03C9A 2078 0400 MOVEA.L $00000400,A0
>>>>  ...
>>>>
>>>>
>>>>  At line 4653, the 32 Mhz test does :
>>>>
>>>>  0002E228 51c9 fffc DBF .W D1,#$fffc == $0002E226 (F)
>>>>  00E03C50 52b9 0000 04ba ADD.L #$00000001,$000004ba
>>>>  00E03C56 e7f9 0000 11ba ROLW.W $000011ba
>>>>  00E03C5C 6a48 BPL.B #$00000048 == $00E03CA6 (T)
>>>>  00E03CA6 11fc 00df fa11 MOVE.B #$df,$fffffa11
>>>>  00E03CAC 4e73 RTE.L
>>>>  0002E226 4298 CLR.L (A0)+
>>>>  0002E228 51c9 fffc DBF .W D1,#$fffc == $0002E226 (F)
>>>>  0002E226 4298 CLR.L (A0)+
>>>>  0002E228 51c9 fffc DBF .W D1,#$fffc == $0002E226 (F)
>>>>  0002E226 4298 CLR.L (A0)+
>>>>  0002E228 51c9 fffc DBF .W D1,#$fffc == $0002E226 (F)
>>>>
>>>>
>>>>  Both tests are jumping to address $E03C50, but not after the same
>>>>  amount
>>>>  of instructions.
>>>>
>>>
>>>  Well, the tests are not exactly jumping, they are interrupted by an
>>>  MFP interrupt, which points in the ROM to e03c50.
>>>
>>>  $4BA is "Raw 200Hz timer", so this is just an interrupt that counts
>>>  200 Hz pulses.
>>>
>>>>  The test after the first 3 instructions after the "interrupt" is TRUE
>>>>  for the 32 Mzh test, but is false for the 16 Mhz test.
>>>>
>>>>  The 32 Mhz test continues to CLR / DBF whereas the 16 Mhz test goes
>>>>  into
>>>>  completely different code.
>>>
>>>  At one point, it's normal 32 and 16 Mhz don't return at the same
>>>  place, because the 32 Mhz version is running twice more instructions
>>>  per cycle, so when it's interrupted by the 200 Hz timer, it processed
>>>  more instruction than when it ran at 16 Mhz.
>>>
>>>  What do you means by "it bugs" ? Crash ? Bomb ? Bad visual result ?
>>>
>>>
>>>  Nicolas
>>>
>>>
>>
>
>
>