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

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Wed, 6 Jul 2022 22:31:38 +0200
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

> Le 06/07/2022 à 22:19, Nicolas Pomarède a écrit :
> 
> >> 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...
> >>  
> > 
> > I had the feeling the hang happened on the above loop, but I will let 
> > hatari runs for longer until I read the point you mention (where input 
> > is not processed anymore)
> >   
> 
> no lock here when running :
> 
> ./hatari --tos etos1024k.img --machine tt -s 14 --fast-boot on --mmu on 
> --log-level debug --cpu-exact on --addr24 on
> 
> it boots to gem desktop
> 
> Do I really need to use XaAES to see this freeze or can it be seen with 
> just emutos 1.1.1 ?

I had another try, but it only reproduces with XaAES as far as I can tell.

While looking at the code, I noticed that we have some differences between
WinUAE and Hatari in the set_x_funcs() function:

--- hatari/src/cpu/newcpu.c	2022-07-09 08:55:17.109584474 +0200
+++ winuae/newcpu.cpp	2022-07-03 14:48:00.686757771 +0200
@@ -1047,10 +979,15 @@
 				x_get_byte = get_byte_dc030;
 			}
 		}
-		x_do_cycles = do_cycles;
-		x_do_cycles_pre = do_cycles;
-		x_do_cycles_post = do_cycles_post;
-
+		if (currprefs.cpu_cycle_exact) {
+			x_do_cycles = do_cycles_ce020;
+			x_do_cycles_pre = do_cycles_ce020;
+			x_do_cycles_post = do_cycles_ce020_post;
+		} else {
+			x_do_cycles = do_cycles;
+			x_do_cycles_pre = do_cycles;
+			x_do_cycles_post = do_cycles_post;
+		}
 	} else if (currprefs.cpu_model < 68020) {
 		// 68000/010
 		if (currprefs.cpu_cycle_exact) {
@@ -1518,19 +1455,6 @@
 			dcache_lput = put_long030_cicheck;
 			dcache_wput = put_word030_cicheck;
 			dcache_bput = put_byte030_cicheck;
-			if (currprefs.cpu_data_cache) {
-				dcache_lput = mem_access_delay_long_write_ce030_cicheck;
-				dcache_wput = mem_access_delay_word_write_ce030_cicheck;
-				dcache_bput = mem_access_delay_byte_write_ce030_cicheck;
-			} else {
-				dcache_lput = mem_access_delay_long_write_ce020;
-				dcache_wput = mem_access_delay_word_write_ce020;
-				dcache_bput = mem_access_delay_byte_write_ce020;
-			}
-		} else if (currprefs.cpu_data_cache) {
-			dcache_lput = put_long030_cicheck;
-			dcache_wput = put_word030_cicheck;
-			dcache_bput = put_byte030_cicheck;
 		}
 	}
 }

But I already tried to adapt Hatari and it makes no differnce for this
problem. Anyway, should we still adjust this before the release?

 Thomas