Re: [hatari-devel] MEMWATCH freezes Hatari

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 16/10/2018 à 15:00, Nicolas Pomarède a écrit :

> 0001A8AC 4e73                     RTE
> 0001E276 42a7                     CLR.L -(A7)
> 0001E278 6036                     BT .B #$36 == $0001e2b0 (T)
>
> As can be seen, the RTE executes the instruction at 1e276, but the 
> "clr.b (a1)" at 1e274 is not retried.
>
> So, in that case there's no instant crash, this clr.b might be useless 
> now, but the rerun behaviour was not correct.
>
> I don't see anything obvious in m68k_do_rte_mmu030(), neither in code 
> for op_4e73.
>
> Toni, do you see sthg with these traces or do you need more infos ?

Some more debugging :

after the RTE opcode is executed, we go back to the main loop in 
m68k_run_mmu030. Then we have this code :

if (mmu030_retry && mmu030_opcode == -1)
        goto insretry;

A printf just before this 'if' shows mmu030_retry=true (as expected 
after m68k_do_rte_mmu030) but mmu030_opcode=4211 and not -1

Looking in m68k_do_rte_mmu030, mmu030_opcode comes from :

      uae_u32 ps = get_long_mmu030c(a7 + 0x28);
      uae_u32 oc = get_long_mmu030c (a7 + 0x14);

      mmu030_opcode = (ps & 0x80000000) ? -1 : (oc & 0xffff);

In that case, ps=00003f00 oc=00004211 and mmu030_opcode=4211

I couldn't find the meaning of a7+0x28 in the doc, it just says 
"internal registers, 2 words".
Maybe that's here that the retry is not correctly validated ?

So, should it be mmu030_opcode != -1 in m68k_run_mmu030 ?
If I use a "!= -1", the instruction at 1e274 is correctly retried, but I 
don't know if this is the proper fix.

Nicolas