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 ]


Hi,

I've got a fix for the problem now.
I've tested it both with the new and the old CPU, and it works fine now.

There was a a second problem after I fixed the problem, hatari didn't want to quit anymore.
That's fixed too.

I'll upload tonight.


> 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).


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 ?

Regards

Laurent




----- Mail Original -----
De: "Thomas Huth" <th.huth@xxxxxx>
À: hatari-devel@xxxxxxxxxxxxxxxxxxx
Envoyé: Mardi 17 Janvier 2012 00h17:07 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne
Objet: Re: [hatari-devel] WinUAE core freeze with ST emulation

Am Mon, 16 Jan 2012 23:56:58 +0100
schrieb Laurent Sallafranque <laurent.sallafranque@xxxxxxx>:

> OK, I've finaly found it : it's in m68000.c
> 
> /**
>   * Reset CPU 68000 variables
>   */
> void M68000_Reset(bool bCold)
> {
>      /* Clear registers */
>      if (bCold)
>      {
>          memset(&regs, 0, sizeof(regs));
>      }
> 
> 
> The memset clears the regs (and spcflags is into this structure).
> 
> It's because we come from change.c which calls Reset_Cold();

Good finding!

> Should I change the reset cold by a reset warm or add some ifs to
> avoid the problem ? (This may complexify the understanding of the
> code).

First, I think you do not have to reset the emulator when you only
change the bCompatibleCpu or bCycleExactCpu settings, do you?
(I am talking about the code in Change_DoNeedReset()).

But for the rest, you're right of course, _BRK and _MODECHANGE flags
should not be altered here. I'd suggest some code like this:

   if (bCold)
   {
      /* Need to keep SPCFLAG_BRK and SPCFLAG_MODECHANGE */
      int spcflags = regs.spcflags & (SPCFLAG_BRK|SPCFLAG_MODECHANGE);
      memset(&regs, 0, sizeof(regs));
      regs.spcflags = spcflags;
   }

That should fix the problem without ifdefs and is still pretty
readable, I think.

 Thomas





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