Copy / Paste doesnt work properly when going from 128 mode to 64 mode
Versatile Commodore Emulator
Brought to you by:
blackystardust,
gpz
Not on my box using Gtk3, I get the standard C64 boot screen text. Since you filed this against 3.2, did you use WinVICE or did you use a current nightly?
This would be winvice. I don't believe it was a nightly build.
Last edit: Scott 2018-11-04
I'm away at the moment but will check and see if there's anymore info I can
provide that will help.
Last edit: Scott 2018-11-04
According to the About window, this is Version 3.2 rev 34843M (Windows)
The screen that is copied is determined by the position of the 80/40 key, which you still have 'down' even in 64 mode.
So toggle the 40/80 key (numpad "/" for me) and copy again, you'll get the correct screen.
Having explained all that, I'm still not sure if this is a real bug or not :)
I would suggest that it is a bug. Copy / Paste from the active screen infers you're going to get a copy of what you see, regardless of any other factor. Intuitively, I would never go File->Copy on a 64 screen expecting to get data from another screen, if that makes sense.
Also (AFAIK) theres no visible indicator of the 40/80 col switch, so one wouldnt even be clued in that way either.
So does this work correct with the GTK3 and/or SDL UIs?
The way it works in Gtk3 is that when starting x128 I get the VIC screen with the green border, copy/paste copies the VIC screen text ("BASIC V7.0"). When doing a 'Go64', and a copy/paste I get the VIC screen text of the 'C64': ("BASIC V2.0").
However, when I run
x128 -80col, x128 starts with the VDC active, copy/paste copies the VDC, also after Go64. Pushing'/'on the numpad and then doing copy/paste results in a copy of the 'C64' VIC screen, it does not matter whether I select Copy from the VIC window or the VDC window.So it seems copy is indeed depending on the 40/80 column key. No idea if this is a bug, I never had a C128, but personally I would expect a copy of the VDC when the VDC GtkWindow has focus and a copy of the VIC when the VIC GtkWindow has focus.
IIRC the 40/80 key check was added because the c128 code can't determine which GUI screen is active at any given time, and that was better than nothing.
The actual copying and 40/80 check is done in src/c128/c128mem.c mem_get_screen_parameter() around line 1286.
That would need to be updated to query the GUI to determine which screen has focus.
So there will need to be a callback created in both GTK3 and SDL1/2 UI's which returns which window is currently active.
As I don't know the GUI code, I'll leave it up to compyx/mcmartin to make a gui_active_screen_query() callback (or something better named).
The Gtk3 UI has a ui_get_active_window() function which should return the active window. However, I'd rather not stuff any UI-dependent code in src/c128, so if we need x128 to determine which screen it needs to copy, independent of 40/80 col but dependent of the active display, maybe some archdep code is in order?
On Gtk3 that could return the active GtkWindow and thus the 'proper' VIC/VDC content. Probably a similar thing can be done for SDL, though that port doesn't have separate active VDC/VIC windows.
Last edit: compyx 2019-01-01
why do you think this would need archdep code? and why was it labelled as windows specific?
all that is needed is a function that exists in both SDL and GTK, which tells what videochip relates to the active display. neither windows specific, nor archdep.
The value of active_win_index in /arch/gtk3/ui.c looks like all we need to get on the GTK3 side?
Perhaps sdl_active_canvas_num in /arch/sdl/video_sdl?.c for SDL?
By the way, the monitor's
screencommand has the same issue (and the same current solution).yep the screen command calls the same routine, so fixing the copy/paste bit will also fix the monitor
Should be fixed in r40172 -- please re-test.
Last edit: June 2021-06-15