Re: [hatari-devel] WinUAE core freeze with ST emulation, solved but another question about gemdos drive.

[Thomas Huth <th.huth@xxxxxx>]

Am Tue, 17 Jan 2012 15:16:53 +0100 (CET)
schrieb laurent.sallafranque@xxxxxxx:
> 
> > First, I think you do not have to reset the emulator when you only
> > change the bCompatibleCpu or bCycleExactCpu settings, do you?
> 
> Yes I must do so. 
> For the 68000 CPU (for example), whitching to prefetch or cycle exact
> changes the core (CPU_EMU_0, 11 or 12).

Changing the CPU mode (within one CPU level) should be handled via
SPCFLAG_MODECHANGE already. Setting MODECHANGE causes m68k_run_x() to
exit, so that it returns to m68k_go(). And m68k_go() then selects the
new CPU mode. That's at least how it is done with the old UAE core.
In the new core, I do not see where the code sets MODECHANGE. It's set
in check_prefs_changed_cpu() in the old core. Maybe we should set in in 
M68000_CheckCpuSettings() instead, so that it is done the same way for
both cores...

> I've got a last problem with the newcore : if I switch from Falcon
> mode (68030, DSP, TOS, memory, ..) to STF, I loose the gemdos
> harddrive. (I still have the icon on the desktop but it doesn't open
> while double clicking on it). If I switch back to falcon mode (always
> on the fly under the guy, without quitting hatari), I can still use
> the gemdos harddrive.
> 
> The problems occurs also in the opposite way : if I start hatari in
> ST(F/E) mode, I can use the Harddrive, if I switch to Falcon "on the
> fly", I can't use it anymore. If I return to ST(F/E) mode (always on
> the fly), it still works well.
> 
> Any idea where to search this problem ?

Sounds like the GEMDOS_OPCODE might get lost... could you check whether
cpufunctbl[GEMDOS_OPCODE] is still set to OpCode_GemDos ?

 Thomas