Activity for Greg King
-
Greg King modified a comment on ticket #1631
Renaming to "Allow keyset joysticks". But, it controls the "Numpad", too -- not only the two keysets. That text change might confuse users.
-
Renaming to "Allow keyset joysticks". But, it controls the "numpad", too -- not only the two keysets. That text change might confuse users.
-
It's the disassembly, not the prompt, that's different. The prompt always shows the PC register, which anticipates the next instruction. Your first example disassembles the current instruction, while your second example disassembles the next instruction,
-
just for the records: kernal initializes the CIA2 ports like this - interestingly, the portb output value is NOT initialized - so the kernel itself relies on the power-up value in the CIA! KERNAL doesn't set the output value because it's irrelevant -- all pins are set to input.
-
Three settings are needed: 1. The control port must be "Joystick". 2. The Joystick must be either "Numpad", "Keyset A", or "Keyset B". 3. "Enable keyboard joysticks" must be enabled.
-
Virtual shift is needed for typing the apostrophe, on US keyboards.
-
Nope! It's a workaround, not a fix. That workaround would be needed in EVERY keymap in VICE. The bug is that the virtual shift key is "pressed" even when it isn't needed (and not wanted). That bug is known. It's mentioned in https://sourceforge.net/p/vice-emu/bugs/1187/#4059 That comment has a very useful C64 keyboard test program attached to it. It shows the bug vividly. Run it. If you have a US host keyboard, then press the apostrophe key. The virtual (right) shift key will be pressed. Release....
-
Nope! It's a workaround, not a fix. That workaround would be needed in EVERY keymap in VICE. The bug is that the virtual shift key is "pressed" even when it isn't needed, and not wanted. That bug is known. It's mentioned in https://sourceforge.net/p/vice-emu/bugs/1187/#4059 That comment has a very useful C64 keyboard test program attached to it. It shows the bug vividly. Run it. If you have a US host keyboard, then press the apostrophe key. The virtual (right) shift key will be pressed. Release....
-
The upstream bug is fixed! Pango 1.48.8 doesn't show those verticle lines.
-
Aha, no I didn't. Usually, I try the emulators directly in the src/ folder; and, if they, for some reason, stop working, I don't run "sudo make install", so that I continue to have a working c64-emulator on my system. That won't work. "data/", not "src/" is the anchor. Therefore, you must copy the newly-built binaries from "src/" into "data/". Then, run them from "data/".
-
Also, please give us some more information, what OS is it running on?? "x86_64-w64-mingw32" means 64-bit Windows (I assume version 10).
-
Also, please give us some more information, what OS is it running on?? "x86_64-w64-mingw32" means 64-bit Windows.
-
(Don't try to compile "render-common.c" anymore, it's now #included within "render-common.h".) That causes a recursive #include of "render-common.h". Here is a better fix: 1. Move the inline function definitions into the header, itself. 2. Delete "render-common.c". 3. Declare those functions as static inline. 4. Remove the unneeded #include "video.h".
-
Copy external FFMPEG libraries into Windows bindist packages
-
Of course QLink doesn't like ip232. It's a tcpser protocol. ip232 can't be used with anything else.
-
The symbolic keymaps are designed to make it easier to type the symbols that are on host keyboards. If you want to type PetSCII graphics characters, then you must switch to a positional keymap, and remember where those graphics sit on Commodore's keyboards.
-
Also, you should add libjoystickdrvto the list of .PHONY: goals.
-
Search this web page for "dhcpc". You'll see that both the non-working and the working logs reach that far. Then, the non-working log exits. The working log continues with HardSID messages. The HardSID code attempts to access the I/O ports directly -- a big no-no! Modern Windows versions simply block those attempts. But maybe, a third-party antimalware program is monitoring the systems of users who have "the problem". Maybe, it thinks that those emulators are "bad actors" -- and kills them. (The...
-
Search this web page for "dhcpc". You'll see that both the non-working and the working logs reach that far. Then, the non-working log exits. The working log continues with HardSID messages. The HardSID code attempts to access the I/O ports directly -- a big no-no! Modern Windows versions simply block those attempts. But, maybe a third-party antimalware program is monitoring the systems of users who have "the problem". Maybe, it thinks that those emulators are "bad actors" -- and kills them. (The...
-
-Use your favourite editor to change your home dir entry in /etc/passwd: +Use your favourite editor to change your home dir. entry in /etc/passwd: Why the dot? 'dir' is a perfectly acceptable abbreviation of 'directory'; and if you want 'directory' written out, it still fits in 80 columns. It's a syntax tradition that I like. It says, "this definitely is an abbreviation". For example, direct is a word, while direct. is an abbreviation of a longer word. Another 'issue' is the removal of the instructions...
-
-Use your favourite editor to change your home dir entry in /etc/passwd: +Use your favourite editor to change your home dir. entry in /etc/passwd: Why the dot? 'dir' is a perfectly acceptable abbreviation of 'directory'; and if you want 'directory' written out, it still fits in 80 columns. It's a syntax tradition that I like. It says, "this definitely is an abbreviation". For example, direct is a word, while direct. is an abbreviation of a longer word. Another 'issue' is the removal of the instructions...
-
Update MSys2 "Howto" document.
-
So ... we have bash (it seems to set OSTYPE), texi2dvi, and uname. At least one of them changed (and broke) recently (I don't know exactly when it happened).
-
It's not "configure"; it's "texi2dvi". Look at lines 79 to 92 in "/bin/texi2dvi". The "uname" command wants to see "MSYS"; it doesn't recognize "msys"!
-
I have some updates for that "Howto" file. One of them is that we don't need to build the static stuff anymore; MSys2 has FFMPEG now. I'll submit a patch.
-
The bug is in MSys2's BASH, not VICE. It sets an environment variable to a wrong spelling: $ declare -p OSTYPE declare -- OSTYPE="msys" OSTYPE should hold an upper-case "MSYS". That misspelling makes texi2dvi think that it's running on pure Windows (not a POSIX overlay). Therefore, it looks for semicolons in the PATH string, instead of colons. It can't find where to look for programs. You can work around that bug by putting this line in "~/.bash_profile": export OSTYPE="MSYS"
-
It's a typo. Compyx spelled it "vnversion.h". :-)
-
I disagree with revision 39853. Two rules are used to build the header. The first rule should name the header in the same way that the second rule names it. There is no path in svnversion.h: svnversion.h.indirect That is the way that it should be; it's a local file (in the current directory). Therefore, there should be no path at the end of the first rule's recipe.
-
You're right! I apologize; my patch was incomplete. I forgot about a fix that I did a long time ago: Index: src/Makefile.am =================================================================== --- vice/src/Makefile.am (revision 39852) +++ vice/src/Makefile.am (working copy) @@ -610,7 +610,7 @@ BUILT_SOURCES = $(EMBEDDED_H_FILES) $(SVN_VERSION_ .PHONY: svnversion.h.indirect svnversion.h.indirect: - @$(SHELL) $(srcdir)/buildtools/gensvnversion.sh $(SVNVERSION) $(top_srcdir) $(srcdir)/svnversion.h +...
-
This is what I get: Wed Mar 10, 04:26 AM; (error 0) /usr/local/src/svn-vice-build $ make petcat make[1]: Entering directory '/usr/local/src/svn-vice-build/src/tools/petcat' cd ../../../../svn-vice && automake-1.16 --foreign src/tools/petcat/Makefile cd ../../.. && /bin/sh ./config.status src/tools/petcat/Makefile depfiles config.status: creating src/tools/petcat/Makefile config.status: executing depfiles commands (cd ../..; make svnversion.h) make[2]: Entering directory '/usr/local/src/svn-vice-build/src'...
-
By the way, those tool Makefiles didn't work in-tree, either. (Note that make clean doesn't remove an old "svnversion.h". Therefore, your tests probably never had a truely "virgin" build environment.)
-
In the other makefiles, the cd commands use simple relative paths. They don't use make variables. cd ../..; is consistent with those other makefiles.
-
Made cartconv and petcat tools buildable by themselves.
-
The until command is better for the two jobs that you described.
-
should be fixed in r39253 That new code sets AutostartDelayDefaultSeconds twice. autostart_init() sets it, then autostart_reinit() sets it again.
-
They don't appear to be listed options in configure. They aren't documented because we aren't supposed to use them. We aren't supposed to know even that they exist! As I told you before, only a second script file ever uses those two options.
-
Don't type those last two options. (Only the "./config.status --recheck" script uses them.)
-
I think that a right parenthesis shouldn't have been moved. The inner parentheses should surround only the option name. (--enable-pdf-docs),
-
A duplicated macro expansion in "configure.ac" is deprecated anyway.
-
Bug in error messages for missing PDF tools
-
Windows's COM ports support those signals. Code for DTR is at https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src/arch/shared/rs232-win32-dev.c#l456 . Code for DCD is at https://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src/arch/shared/rs232-win32-dev.c#l493 .
-
Al, have you tried the programs at http://com0com.sourceforge.net/ instead of a cable?
-
Yes. It's fixed. I build both the HTML docs and the static FFMPEG library, in both SDL2 and GTK3. I don't see those messages anymore.
-
The second use of va_copy() and va_end() is pointless (the line in between them doesn't use args).
-
DJGPP and RSXNT, yes; Visual C, no. It wasn't until GCC 2.91 that MinGW's headers looked enough like Visual C's headers that "soundwmm.c" could be built by both Microsoft's and GNU's compilers. I think that there used to be MSVC version tests there, too. But, official support for Visual C was removed from VICE. I agree, that preprocessor line has been obsolete for a long, long time. (-std=c99 is used for C source files.)
-
There seems to be some bleed-over between the two mappings. If I remove the 1 (key is combined with shift) flag from the unshifted mapping, then the shifted mapping works -- even without the 16 (deshift key) flag!
-
I have no idea what caused it, but the last byte in the "sudoku3" file is $02. It should be $00. The last three bytes in a BASIC program must be zeroes. That tells both the BASIC ROM and CBM prg Studio where the end is. The file can have other stuff (such as machine code) after that spot, but BASIC can know where its source stops. After the BASIC ROM loads a file, it walks through the code (fixing line links) until it gets to the end. But, BASIC couldn't see the end of your source. Therefore, it...
-
I have no idea what caused it, but the last byte in the "sudoku3" file is $02. It should be $00. The last three bytes in a BASIC program must be zeroes. That tells both the BASIC ROM and CBM prg Studio where the end is. The file can have other stuff (such as machine code) after that spot, but BASIC can know where its source stops. After the BASIC ROM loads a file, it walks through the code (fixing line links) until it gets to the end. But, BASIC couldn't see the end of your source. Therefore, it...
-
I have no idea what caused it, but the last byte in the "sudoku3" file is $02. It should be $00. The last three bytes in a BASIC program must be zeroes. That tells both the BASIC ROM and CBM prg Studio where the end is. The file can have other stuff (such as machine code) after that spot, but BASIC can know where its source stops. After the BASIC ROM loads a file, it walks through the code (fixing line links) until it gets to the end. But, BASIC couldn't see the end of your source. Therefore, it...
-
I have no idea what caused it, but the last byte in the "sudoku3" file is $02. It should be $00. The last three bytes in a BASIC program must be zeroes. That tells both the BASIC ROM and CBM prg Studio where the end is. The file can have other stuff (such as machine code) after that spot, but BASIC can know where its source stops. After the BASIC ROM loads a file, it walks through the code (fixing line links) until it gets to the end. But, BASIC didn't see the end of your source. Therefore, it kept...
-
You put the #ifdef HAVE_MIDI test before the #include "vice.h" line. Therefore, the test cannot be true.
-
You put the #ifdef HAVE_MIDI test before the #include <vice.h> line. Therefore, the test cannot be true.
-
GTK3VICE cannot be built on Windows because "gtk3/data/win32/Makefile.am" doesn't create "icon.res".
-
Compyx, you had forgotten to convert "vice.gresource.xml.proto" into a generic "vice.gresource.xml".
-
compyx, you forgot to convert "vice.gresource.xml.proto" into a generic "vice.gresource.xml".
-
Can't you plug into the "-autoload" code?
-
When I switch between SDL2 and GTK3, I must use an extra command to clean VICE: make clean find src/lib/libffmpeg -name '*.[oa]' -delete
-
I have seen that you also added a "ogg-vorbis" option but, after this change, libFLAC cannot be used anymore, because you changed FLAC_PRESENT to "no" at global level. Am I doing some mistakes or this is wrong? It's a bug.
-
Update MSYS2 Building Instructions
-
svn up, run ./autogen.sh, ./configure, make clean and finally make. Only svn up make is needed -- the Makefile will do the other things.
-
Can the 2 vdrives in a unit have different emulation types (the simplest combination: True Drive Emulation and Filesystem)? "vice.pdf" says that the two drive controllers always are virtual. Therefore, many names are misleading. Two of them are actually "True Unit Emulation" and "Virtual Units". The sensible answer to that question is "no".
-
Here is a command line that builds SDL2 x64sc on my MSYS2 system: g++ -std=c++11 -g -O3 -Wall -Wformat -Wformat-signedness -Wshadow -Wpointer-arith -Wstrict-prototypes -Wuninitialized -Wunreachable-code -Wno-unused-parameter -Werror=implicit-function-declaration -Wfatal-errors -Wall -Wno-unused-parameter -Wno-sign-compare -mwindows -I/mingw64/include/SDL2 -Dmain=SDL_main -Ofast -march=native -o x64sc.exe alarm.o attach.o autostart.o autostart-prg.o cbmdos.o cbmimage.o charset.o clipboard.o clkguard.o...
-
I can build SDL2 with MSYS2. Did you configure VICE with --enable-sdlui or --enable-sdlui2?
-
First of all, substituting $(top_builddir) with $(top_srcdir) seems wrong; that'll probably break out-of-tree building. The .RC file won't be built anymore. Instead, a permanent generic version of it will be substituted for the prototype file in the (repo's) source tree. (A -I command-line option, for include paths, will be used to find the common icon file.) But at least, set svn to use Unix by default; I'm seeing some ^M's that should not be there. Carlo, you must run your new "icon.rc" file (and...
-
This patch clears the keyboard (on Windows, at least) when VICE loses the keyboard focus.
-
Fixed by revision 37368.
-
This ticket should be marked as "pending-fixed". The US positional keymaps, for both GTK and SDL, work properly now.
-
This ticket can be marked as "closed-fixed". The fix is universal; it works in all "bindist" scripts (and Makefiles, too).
-
There's a memory leak in the Windows code (string a isn't freed). This patch fixes that leak, and removes an unneeded lib_strdup(a) (string a is allocated; so, just return it).
-
In the meantime, fixing "src/arch/shared/archdep_quote_parameter.c" might be a simpler solution. Currently, the function creates three strings: a, b, and c. To make the fix: all platforms need string a; nobody needs string b; only Microsoft's OSes need string c.
-
In the meantime, fixing "src/arch/shared/archdep_quote_parameter.c" is a simpler solution. Currently, the function creates three strings: a, b, and c. To make the fix: all platforms need string a; nobody needs string b; only Microsoft's OSes need string c.
-
This ticket seems like bug ticket 920.
-
Look on the "Emulator" pane in the Settings dialog.
-
Look on the "Emulator" pane.
-
Fix xplus4's US Keymaps
-
Shift-7 is an apostrophe on the US +4 keyboard (it looks like a short slash).
-
But so, the interfaces that invert the handshake lines do not work with Commodore BASIC in X-line mode? As Commodore BASIC does not expect this, right? No, it's the adapters that do invert the handshake lines that work with Kernal's standard RS-232 driver. The Glink-lt adapter is right; the C64-wiki is wrong. (Magnify the Glink schematic a few times, then look at the names of the lines that go in/out of the Max232 chips. You'll see a bar over those names. Those chips use inverted lines; the adapter...
-
greg, i think your example is different. the space bar stops acting when going back to VICE. even if you just hover the mouse over VICE. That happens only if you do something that sends an event. For example, tapping a key, or hovering over a status-bar region that changes the mouse cursor's shape. The only difference between our examples is that fewer events are able to cancel state-modifier keypresses. also, the issue i described did NOT happen on versions before mentioned commit, just check stable...
-
greg, i think your example is different. the space bar stops acting when going back to VICE. even if you just hover the mouse over VICE. That happens only if you do something that sends an event. For example, tapping a key, or hovering over a status-bar region that changes the mouse cursor's shape. The only difference between our examples is that fewer events are able to cancel state-modifier keypresses. I typed: GDK/GTK sees those announcements, and remembers what it thinks is the current condition...
-
It's not a bug; it's the normal way that GTK/GDK works. It's based on the way that X11 (X Window System) works. When an input condition changes, an "event" (announcement) is given to the currently active window. Typical events are "Left Shift pressed", "Left Shift released", "Space pressed", and "Space released". GDK/GTK sees those announcements, and remembers what it thinks is the current condition of some inputs. VICE does the same thing with mapped keys. (They don't ask the keyboard, "what is...
-
GTK: Close settings after "Hide VDC" only when needed.
-
Stop the ACIA core from trying to talk to unopened devices.
-
It would be better to change the c128 definition of z80_regs into a comment, and add a note that says that the struct variable is exported by ../c64/cart/cpmcart.c.
-
You mean something like BPS: 20 ? But, does it actually work? It sets the speed of the ACIA emulation; but, it's ignored by devices outside of VICE.
-
I think that you should remove the SDL2 prefix stuff -- it's pointless! VICE never will need a prefix! sdl2.pc and sdl2-config always point directly to the headers directory.
-
This patch should let you see the message in Unix builds: Index: src/arch/shared/rs232-unix-dev.c =================================================================== --- src/arch/shared/rs232-unix-dev.c (revision 37525) +++ src/arch/shared/rs232-unix-dev.c (working copy) @@ -411,6 +411,10 @@ int rs232dev_set_status(int fd, enum rs232handshak /* get the status lines of the RS232 device */ enum rs232handshake_in rs232dev_get_status(int fd) { + if (fd < 0 || fd >= RS232_NUM_DEVICES) { + log_error(rs232dev_log,...
-
GTK VICE on Windows used to pop up a console (terminal) window even when it wasn't needed. That action has been suppressed. As a result, console output normally is redirected to "nowhere". In order to see the usage list, you must "catch" that output before it's dropped. Use this command: x64 -h|more
-
The lock is "Caps", not "Shift"; we don't get punctuation marks when we tap number keys. I noticed that too. So, that is the wrong behaviour? On a real C64, SHIFT-LOCK does really shift every key, unlike CAPS LOCK on a PC? SHIFT LOCK is a "push on, push off" switch (not key!) that's wired across the left Shift key. (When the switch is in its "on" state, the machine thinks that the left Shift is being held down.)
-
In the GTK3 version, that works fine on the same system, though. Actually, Shift-Lock doesn't work in the GTK UI, either. But, we usually don't see it because of the different ways that the two UIs encode keypresses. SDL encodes the position of the key; "G" is the same as "g" (ignoring the modifier flags). GDK encodes the character symbol; "G" is different from "g". Therefore, after we press Caps Lock, SDL still sends lower-case "g"; but, GDK sends upper-case "G" (because the OS obeys the Caps Lock...
-
press LEFT SHIFT press some other key Now, RIGHT SHIFT is pressed, too. That's the "Caps Lock" effect. Pressing the left Shift key activates the "SHIFT LOCK" light, too! Then, pressing any key that can be affected by Caps Lock will activate the virtual shift key (which happens to be the right-side one, in the current keymap). You can see it also if you press the Caps Lock key, release it, then press any letter key.
-
press LEFT SHIFT press some other key Now, RIGHT SHIFT is pressed, too. That's the "Caps Lock" effect. Pressing the left Shift key activates the "SHIFT LOCK" light, too! Then, pressing any key that can be affected by Caps Lock will activate the virtual shift key (which happens to be the right-side one, in the current keymap). You can see it also if you press the Caps Lock key, release it, then press any letter key. P.S., It's a side effect, not a bug.
-
press LEFT SHIFT press some other key Now, RIGHT SHIFT is pressed, too. That's the "Caps Lock" effect. Pressing the left Shift key activates the "SHIFT LOCK" light, too! Then, pressing any key that can be affected by Caps Lock will activate the virtual shift key (which happens to be the right-side one, in the current keymap). You can see it also if you press the Caps Lock key, release it, then press any letter key.
-
"Well, we can, but only the first one is recognised." That seems to be a Windows-specific issue (with either GTK or even the OS) -- it works in Linux. It works in SDL on Windows. So, I think that the bug is in GDK-on-Windows. You can see it if you "Enable keyboard debugging on statusbar". It's pure GDK; VICE has very little effect on that display.
-
... , we need to 'rescue' (ie, move) the 'vice-logo.svg' and 'vice-logo-black.svg' files -- at least, the black logo file is used in the vice.gresource file by reading it from the html/images directory. But, it doesn't belong there! "vice-logo-black.svg" isn't used by the HTML pages. It is only a UI file. It belongs in the directory which holds the UI's icon files.
-
The "model" option works: -model sx64, -model sx64pal, and -model sx64ntsc. -kernalrev tries to patch the Kernal before the file is loaded; then, it pretends that it succeeded. KernalRev is ignored. Its value is replaced by the actual revision number from the loaded file. The attached patch fixes the -kernalrev bug. (A KernalRev from the settings file still is ignored.)
-
The "model" option works: -model sx64, -model sx64pal, and -model sx64ntsc. -kernalrev tries to patch the Kernal before the file is loaded; then, it pretends that it succeeded. KernalRev is ignored. Its value is replaced by the actual revision number from the loaded file. The attached patch fixes the -kernalrev bug. (A KernalRev from the settings file still is ignored.)
-
/usr/local/Cellar/vice/3.4/bin/x64sc -kernalname "sxkernal" -kernalrev 67 This results in: Unknown option '-kernalname'. Seems strange that one can specify the kernal revision on the command line, but not the (apparently mandatory) kernal name as well. Enter this command: /usr/local/Cellar/vice/3.4/bin/x64sc -help|more Then, tell "more" to find kernal. You will see the correct options.
-
It works in Windows. (The "IEC Device" setting has no effect.)
-
registers is another command that doesn't like semicolons. P.S., You don't need to use the command command, to see the bug. You can see it when you type multiple-command lines at the monitor's prompt.
-
Full quotes? When you sent those recent messages, your mail program "quoted" the entire text of previous messages in this thread. It's a lot of undesired noise. Please delete that extra text from your messages before you send them (keep only the specific text to which you're replying).
1 >
