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

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Sun, 26 Jun 2022 12:35:02 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> Hi,
> 
> On 26.6.2022 9.27, Thomas Huth wrote:
> > Am Fri, 24 Jun 2022 17:32:26 +0300
> > schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:  
> >> Hatari hard-freezes with following:  
> > [...]  
> >> 7. In XaAES, click on "Process" -> "Quit all Apps" menu item
> >>
> >> 8. Then click on "Process" -> "Quit XaAES"
> >>  
> >> => After second or two, Hatari freezes completely.  
> > 
> > I cannot reproduce the issue - for me, XaAES simply gets restarted in that
> > case. Which version of EmuTOS are you using?  
> 
> Freeze happens with EmuTOS v1.1.1 (which is going to be shipped with 
> Hatari), but not with the latest Git version of EmuTOS.
> 
> Can you reproduce it with EmuTOS v1.1.1?

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?

 Thomas