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;
+ }