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

[ Thread Index | Date Index | More Archives ]

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.



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 ?


Mail converted by MHonArc 2.6.19+