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

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

I've uploaded the patch which fix the problem.

Maybe I can use MODECHANGE in check_prefs_changed_cpu() instead of 
SPCFLAG_BRK, and adapt m68k_run.
Like this, we would have SPCFLAG_BRK in M68000_Reset and I could 
simplify the code (I would also have to adapt m68k_go)

This would be closer to the old cpu but it changes WINUAE cpu code.
Thomas, it's a you want.

For the Gemdos part, I've had a quick look.
I didn't know this part of the code :)

I think you're right: when there's a change of cpu, newcpu calls 
build_cpufunctbl() which reinitialise the opcodes table.
There must be an init to call after, but I don't know well the gemdos code.

What is strange is that when I return to the CPU I booted on, I get back 
the gemdos drive (I thought that calling build_cpufunctbl() would erase 
the GEMDOS "opcode").

That's not a big problem as the change of CPU was, but I think it would 
be nice to have it fixed too.

Regards

Laurent



Le 17/01/2012 21:16, Thomas Huth a écrit :
> 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