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

[Thomas Huth <th.huth@xxxxxx>]

Am Mon, 28 May 2012 01:01:15 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:

> Hi,
> 
> On tiistai 17 tammikuu 2012, laurent.sallafranque@xxxxxxx wrote:
> > 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.
[...]
> I don't see what goes wrong though.
> 
> In both cases according to "info gemdos":
> * GEMDOS emulation is enabled,
> * connected drives mask
>   (Hatari variable and corresponding Atari memory address)
> is the same and SysInit is called.
> 
> Thomas, is there something else from which TOS decides whether
> C: drive works?

It's all about black magic .... ;-) No, honestly, the culprit here was
currprefs.cpu_level which is used in GemDOS_OpCode() to find the right
offset to the parameters on the stack.
currprefs.cpu_level is a old-UAE only variable, the WinUAE core uses
currprefs.cpu_model instead. So to keep both happy, the Hatari code and
the WinUAE code, both variables need to stay in sync. They were synced
already in Init680x0(), but when the CPU model was changed on the fly,
currprefs.cpu_level was not updated anymore. I committed a fix for this
problem now, so GEMDOS HD should now also work with the WinUAE core as
expected.

 Cheers,
  Thomas