Re: [hatari-devel] Hatari freeze on XaAES quit with TT + MMU + 24-bit emulation

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Sun, 3 Jul 2022 23:05:07 +0200
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

> Le 03/07/2022 à 15:08, Thomas Huth a écrit :
> > Am Sun, 26 Jun 2022 12:35:02 +0300
> > schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> >   
> >> On 26.6.2022 9.27, Thomas Huth wrote:  
.... 
> > Yes, I can reproduce it with EmuTOS v1.1.1 - and only if CPU cycle exact
> > mode is enabled, too. Seem like 030 + MMU + CE is pretty much defunc in
> > Hatari right now. In m68k_run_mmu030() I can see:
> > 
> > 					if (!currprefs.cpu_cycle_exact) {
> > 
> > 						count_instr (regs.opcode);
> > 						do_cycles (cpu_cycles);
> > 
> > 						cpu_cycles = (*cpufunctbl[regs.opcode])(regs.opcode);
> > 					} else {
> > #ifdef WINUAE_FOR_HATARI
> > 						currcycle = 0;
> > #endif
> > 						(*cpufunctbl[regs.opcode])(regs.opcode);
> > 						wait_memory_cycles();
> > 					}
> > 
> > However, if cpu_cycle_exact is enabled, currcycle is often still 0 after
> > the emulated instruction has been run via cpufunctbl.
> > Looks like cpufunctbl is either pointing to the wrong table, or the table
> > has been somehow generated badly? ... no clue yet ... Nicolas, do you maybe
> > have an idea?  
> 
> Hi
> 
> I need to look in more detail, but I guess it's possible that with cycle 
> exact some instructions are 0 cycles because of emulated behaviour where 
> tail/head cycles for some instruction are "overlapping"
> 
> running this with emutos 1.1.1 :
> 
> /hatari --tos tos.img --machine tt -s 14 --fast-boot on --mmu on 
> --log-level debug --cpu-exact on
> 
> I see that after a while it loops on these instructions :
> 
> cpu video_cyc=531003 651@261 423252551 : 00e0d612 2039 0000 04ba 
>    move.l $000004ba [*00000a4a],d0
> cpu video_cyc=531003 651@261 423252551 : 00e0d618 b081 
>    cmp.l d1,d0
> cpu video_cyc=531003 651@261 423252551 : 00e0d61a 6c0e 
>    bge.b #$0e == $00e0d62a (F)
> cpu video_cyc=531003 651@261 423252551 : 00e0d61c 1038 fa01 
>    move.b $fa01,d0
> mfp read gpip fffa01=0xb1 video_cyc=531003 651@261 pc=e0d61c instr_cycle 0
> IO read.b $00fffa01 = $b1 pc=e0d61c
> cpu video_cyc=531010 658@261 423252558 : 00e0d620 0800 0005 
>    btst.l #$0005,d0
> cpu video_cyc=531010 658@261 423252558 : 00e0d624 66ec 
>    bne.b #$ec == $00e0d612 (T)
> 
> Is that what you see ?

In "normal" operation yes, it's only updating the cycle count after a
couple of instruction. It could be that this is related to the cache
emulation, fair.

But when the hang happens, it seems like the emulated code is looping
through the whole cleared memory, only executing op_0000_35_ff() in
cpuemu_35.c. And this never seems to add any cycles anymore, thus Hatari
completely hangs in the m68k_run_mmu030() loop, without ever generating an
interrupt and thus not reacting to user input anymore...

 Thomas