mega65_ftp leaves system in half NTSC half PAL state

[lydon42]

after mega65_ftp exists, the system is not fully resetted.

@gurcei notes: might have to do with mega65_ftp exiting to C65 mode via SYS 58552

But on the other hand: why is mega65_ftp changing the VIC screen mode the user selected? It should keep PAL/NTSC as it was. Perhaps the solution can be found in that part?

[lydon42]

We need a procedure to replicate the Problem. I was not able to reproduce it on my system.

[gurcei]

I'm trying to re-read Tayger's thread from this point onwards to grasp the details better:

• https://discord.com/channels/719326990221574164/805492126128930846/991433623939068036

1. His default system is configured for NTSC
2. He then uses m65 tool to switch to PAL mode
3. Then he enters mega65_ftp tool, then exits it
4. Then his c65-mode screen appears to jump back to NTSC

Hmm, ok, the aspect of his steps that I overlooked initially was that he was using the m65-tool to switch from NTSC to PAL (I initially assumed he had changed to PAL via the mega65-config settings, but now I realise I was mistaken there).

Aah, but still, despite using m65 tool to replicate Tayger's steps, I was still unable to replicate the issue.

[gurcei]

Aah, but now I think I have replicated what Tayger is experiencing, not through using purely console-based tools such as m65 and mega65_ftp, but I can replicate this if I use the M65Connect tool to perform such duties.

E.g. perform step 2 and step 4 via M65Connect.

When I do so, I notice a behaviour in step4 that is unique to M65Connect. After exiting the sdcard manager utilit (which internally uses mega65_ftp), I can see the mega65_ftp successfully exit back to c65-mode, but then it seems that M65Connect performs an extra 'reset' activity that goes back to the hypervisor boot-up sequence, which then knocks the screen back into NTSC mode.

So my suspicion now is that the issue is specific to M65Connect and this extra payload that it added after exiting from mega65_ftp. Perhaps it calls m65 tool to reset the system, which isn't necessary.

[gurcei]

Maybe it relates to this part of M65Connect, in WinSDCard.xojo_window:

          Case "quit"
            '// Clear Commander window
            WinSDCard.ListLocal.RemoveAllRows
            WinSDCard.ListRemote.RemoveAllRows
            ActiveCommand = ""
            SdCardInfo = ""

            // Reactivate Terminal on quit and force reset of Mega65 if no d81 file mounted
            if  Terminal.Go65 = False Then
              Terminal.ResetMega65 = True
            End If
            Terminal.Connect()

            WinSDCard.Close
          End Select

I took note of the comment above, that mentioned that M65Connect will only perform this 'extra reset' step upon exiting mega65_ftp only if a d81 image had been mounted.

And indeed, if I were to mount a .d81 disk via the sd-card manager, then exit, I no longer see the reset back to hypervisor, and simply see mega65_ftp exit out to c65-mode with a SYS 58552, and the PAL-mode of the screen is preserved.

So my suggestion is to just get rid of the Terminal.ResetMega65 = True stuff, I don't believe it is needed.

[lydon42]

So... this is essentially a M65Connect problem? Can we close it?