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

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

This is easy to reproduce, one just needs to give TOS version that
is different than the default.

When Hatari is by default running ST emulation, this triggers the bug:
	$ hatari --tos tos404.img <dir>

But adding "--machine falcon" makes it to go away.


I.e. selecting machine / TOS when options are read works fine,
but CPU level being changed to match TOS version when TOS is
loaded is too late with WinUAE.


When looking at main.c:
....
        M68000_Init();                /* Init CPU emulation */
        Audio_Init();
        DmaSnd_Init();
        Keymap_Init();

        /* Init HD emulation */
        HDC_Init();
        Ide_Init();
        GemDOS_Init();
        if (ConfigureParams.HardDisk.bUseHardDiskDirectories)
        {
                /* uses variables set by HDC_Init()! */
                GemDOS_InitDrives();
        }

        if (Reset_Cold())             /* Reset all systems, load TOS image 
*/
        {
                /* If loading of the TOS failed, we bring up the GUI to let 
the
                 * user choose another TOS ROM file. */
                Dialog_DoProperty();
        }
....


In the working version CPU is initialized before cold reset,
which loads the TOS image (from reset.c):
....
        if (bCold)
        {
                int ret;

                Floppy_GetBootDrive();      /* Find which device to boot 
from (A: or C:) */

                ret = TOS_LoadImage();      /* Load TOS, writes into 
cartridge memory */
                if (ret)
                        return ret;               /* If we can not load a 
TOS image, return now! */

                Cart_ResetImage();          /* Load cartridge program into 
ROM memory. */
        }
        CycInt_Reset();               /* Reset interrupts */
        MFP_Reset();                  /* Setup MFP chip */
        Video_Reset();                /* Reset video */
        VDI_Reset();                  /* Reset internal VDI variables */

        GemDOS_Reset();               /* Reset GEMDOS emulation */
....

Cart_ResetImage() is done after loading of TOS, and that's what sets
the (illegal) GEMDOS_OPCODE:
....
        if (PatchIllegal == true)
        {
                //fprintf ( stderr ," Cart_ResetImage patch\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 */
        }

which causes calling of GemDOS_Boot() which does rest of GEMDOS setup.

If GEMDOS HD dir doesn't work, I guess neither will VDI emulation.


If TOS doesn't match machine type, something like this is done:
                IoMem_UnInit();
                ConfigureParams.System.nMachineType = MACHINE_ST;
                ClocksTimings_InitMachine ( 
ConfigureParams.System.nMachineType );
                IoMem_Init();
                ConfigureParams.System.nCpuFreq = 8;
                ConfigureParams.System.nCpuLevel = 0;
                M68000_CheckCpuSettings();


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?


	- Eero