Re: [hatari-devel] WinUAE core freeze with ST emulation

[Thomas Huth <th.huth@xxxxxx>]

Am Mon, 16 Jan 2012 00:18:43 +0100
schrieb Laurent Sallafranque <laurent.sallafranque@xxxxxxx>:

> 
> > If I boot with "--machine falcon --tos etos512k.img" and in
> > the settings select ST / 68000 / 8Mhz / TOS 1.02, them the old TOS
> > boots up fine too without saving settings, even with prefetch
> > enabled.
> 
> It's only by luck, as the wrong CPU is running after the reboot.
> 
> As I explained before, changing of CPU in the GUI makes the code run 
> into newcpu.c:check_prefs_changed_cpu (void)
> and at the end of the function, it goes to
> 
>      if (changed)
>          set_special (SPCFLAG_BRK);
> 
> 
> But when the code returns to the running CPU (like m68k_run_1 (void), 
> m68k_run_2 (void), ...) the value of SPCFLAG_BRK is back to 0 and the 
> program doesn't return to m68k_go (that's where the change of CPU
> occurs).
> 
> I haven't managed to find this problem, and it's quite annoying. Some 
> help would be appreciate on this one.

I remember having some similar problems a couple of years ago with the
uae-cpu core. Some quick observations:

1)
- check_prefs_changed_cpu() in uae-cpu/hatari-glue.c sets SPCFLAG_MODE_CHANGE
- check_prefs_changed_cpu() in cpu/newcpu.c sets SPCFLAG_BRK

2)
- uae-cpu/newcpu.c m68k_reset() does:
  regs.spcflags &= ( SPCFLAG_MODE_CHANGE | SPCFLAG_DEBUGGER );
- cpu/newcpu.c m68k_reset() does:
  regs.spcflags = 0;

==> I guess one of your problems is that m68k_reset() (which is
certainly called when changing the CPU level) clears SPCFLAG_BREAK so
that the m68k_run-loop is never left.

 Thomas