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

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Le 09/07/2022 à 09:32, Thomas Huth a écrit :
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?

Hi

I will apply the missing changes, it should not cause problem. The merge somehow failed at one point when I applied WinUAE's changes to Hatari, because we can see that this 'if' case is present twice, which makes no sense :

                } else if (currprefs.cpu_data_cache) {
                        dcache_lput = put_long030_cicheck;
                        dcache_wput = put_word030_cicheck;
                        dcache_bput = put_byte030_cicheck;

Nicolas





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/