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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

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