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

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


 Changing the CPU mode (within one CPU level) should be handled via
 SPCFLAG_MODECHANGE already.

It seems the change of CPU is done via FLAG_BRK with the new core.
I've done my patch on it and it works fine.

Do you prefer I rework it to use MODECHANGE instead (and devivate a little from winuae code) ?
Or maybe I could upload the patch and then, we can improve it if necessary ?

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







Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/