Re: [hatari-devel] MEMWATCH freezes Hatari

[Toni Wilen <twilen@xxxxxxxxxx>]

> 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

This looks perfectly fine. 4211 = CLR.B (A1) which is the instruction
that was supposed to be retried.

> 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 ?

UAE 68030 emulation uses those undocumented internal registers to store
instruction state. Like real CPU does to enable continuation of
instruction, when it gets "retried", instruction actually continues
where it was left, any already completed memory accesses before fault
are stored in bus error stack frame and must not be retried. (UAE 68030
MMU reruns whole instruction with memory access routines returning
stored data so end result still matches real 68030 behavior)

I simply used those undocumented fields without even trying to check how
real CPU uses them, it probably would have been impossible to
reverse-engineer anyway. Only documented fields work like documented.