[hatari-devel] Raimbow2 problem : seems to be a big problem

Laurent Sallafranque laurent.sallafranque at free.fr
Thu Jan 28 23:00:58 CET 2010


1. breakpoint 'pc = $2e752' conditions matched.

CPU=$2e752, VBL=104038, FrameCycles=73842, HBL=145, LineCycles=182, 
DSP=$7ec9
  c
Returning to emulation...

11 bombs. After the 11 bombs, hatari return to the desktop without any 
more message.
I have never reached the breakpoint 2 (instruction at address $2e752 is 
bombing)

4 conditional CPU breakpoints:
  1: pc = $2e752
  2: pc = $2e758
  3: pc = $2e75a
  4: pc = $2e75c

Regards,

Laurent



npomarede at corp.free.fr a écrit :
> On Thu, 28 Jan 2010, Laurent Sallafranque wrote:
>
>> The program stops with 11 bombs when it reachs this part of code.
>>
>> Regards
>>
>> Laurent
>>
>
> could you try to put a breakpoint at 0002e752, 0002e758, 0002e75a and 
> 0002e75c to see after exactly which instruction you get the 11 bombs ?
>
> If you're in debugger mode, this should even bring you to the debug 
> console.
>
> Nicolas
>
>
>>
>> npomarede at corp.free.fr a écrit :
>>> On Wed, 27 Jan 2010, Laurent Sallafranque wrote:
>>>
>>>> Hello,
>>>>
>>>> I've traced and disassembled Raimbow2.
>>>>
>>>> Here is what I get :
>>>>
>>>> Raimbow2 Trace taken from hatari : d $2e74a
>>>>
>>>> 0002e74a: 22c0 4e7a 0802 22c0 f011 MOVE.L D0,(A1)+
>>>> 0002e74c: 4e7a 0802 22c0 f011 0a00 MOVEC2.L #$0802
>>>> 0002e750: 22c0 f011 0a00 5849 f011 MOVE.L D0,(A1)+
>>>> 0002e752: f011 0a00 5849 f011 0e00 ILLEGAL.L
>>>> 0002e754: 0a00 5849 f011 0e00 5849 EOR.B #$49,D0
>>>> 0002e758: f011 0e00 5849 33f8 0484 ILLEGAL.L
>>>> 0002e75a: 0e00 5849 33f8 0484 0008 ILLEGAL.L
>>>> 0002e75c: 5849 33f8 0484 0008 1be4 ADDA.W #$00000004,A1
>>>> 0002e75e: 33f8 0484 0008 1be4 6100 MOVE.W $00000484,$00081be4
>>>> 0002e766: 6100 005e 08b8 0001 0484 BSR.W #$005e == 0002e7c6
>>>
>>>
>>> Some instructions are not always correctly disasembled and give 
>>> 'ILLEGAL' instead of the real instruction.
>>> For example, I think f011 could be a line-f exception (but I don't 
>>> have the list of possible values) (I already noticed that line-a and 
>>> line-f are not printed as such)
>>> Also 0e00 could be a "moves.b something" (from the 680xx motorola 
>>> doc, this doesn't look like a valid addressing mode though).
>>>
>>> Note that the fact that the disassembly shows "illegal" doesn't mean 
>>> this will create an illegal instruction, you have to run it for real 
>>> to see what it gives, disassembly can be misleading.
>>>
>>>>
>>>> Raimbow2 disassembled with Desert Drain :
>>>>
>>>> move.l      D0,(A1)+
>>>> movec.l     SFC,D0
>>>> move.l      D0,(A1)+
>>>> movec.l     DFC,D0
>>>> move.l      D0,(A1)+
>>>> movec.l     CACR,D0
>>>> move.l      D0,(A1)+
>>>> movec.l     CAAR,D0
>>>> move.l      D0,(A1)+
>>>> pmove       tt0,(A1)
>>>> addq.w      #4,A1
>>>> pmove       tt1,(A1)
>>>> addq.w      #4,A1
>>>> move.w      $484.w,B_53A10 ;conterm
>>>> bsr.w       T_5F2
>>>>
>>>>
>>>> It seems something is not well emulated in 68030.
>>>> MMU code ?
>>>>
>>>> Regards
>>>>
>>>> Laurent
>>>> _______________________________________________
>>>> hatari-devel mailing list
>>>> hatari-devel at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/hatari-devel
>>>>
>>>
>>>
>>
>>




More information about the hatari-devel mailing list