|Re: [hatari-devel] WinUAE core freeze with ST emulation, solved but another question about gemdos drive.|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
I've given another try to this problem, but it still doesn't work.
I've added a hack : Just after the build_cpufunctbl() in newcpu.c, I add
the following: Cart_PatchCpu();
In cart.c, I've added :
/* Use internal cartridge when user wants extended VDI resolution
or GEMDOS HD. */
if (bUseVDIRes || ConfigureParams.HardDisk.bUseHardDiskDirectories)
fprintf (stderr ,"GEMDOS HACK OK !!! \n");
/* Hatari's specific illegal opcodes for HD emulation */
cpufunctbl[GEMDOS_OPCODE] = OpCode_GemDos; /* 0x0008 */
cpufunctbl[SYSINIT_OPCODE] = OpCode_SysInit; /* 0x000a */
cpufunctbl[VDI_OPCODE] = OpCode_VDI; /* 0x000c */
With a printf, I've verified that the code goes into the function (it does).
But the c: drive still doesn't open.
There may be something else to init. Any more ideas I could try ?
Le 17/01/2012 21:16, Thomas Huth a écrit :
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 ?