The two shift keys of the PET (graphics) keyboard are mapped to the two shift keys of the PC keyboard. Pressing each or both of the keys is working. Only releasing a single shift key when both are pressed results in the PET registering both shift keys as released, even though one key is still pressed.
To reproduce enter this program (in xpet -model 4032)
.C:033c 78 SEI
.C:033d AD 10 E8 LDA $E810
.C:0340 29 F0 AND #$F0
.C:0342 09 08 ORA #$08
.C:0344 8D 10 E8 STA $E810
.C:0347 AD 12 E8 LDA $E812
.C:034a 8D 00 80 STA $8000
.C:034d 58 CLI
.C:034e 60 RTS
10 SYS828:GOTO10
then watch the top left corner of the screen. The screen code for $ff is shown.
Press left shift, you get one char; press right shift, you get another char; press both shift, you get a third char.
So far so good. Now press both shift keys, you get the corresponding char in the top left corner of the screen. Release ONE of both shift keys - you get the screen code for $ff instead of the one where the corresponding single char is pressed.
So pressing the left and right shift keys is emulated correctly (setting both input bits correctly), but releasing the shift keys is not emulated correctly: releaseing one shift key resets both input keys for both shift keys)
Note: I have tested this in PET model 4032, but the same may be true for other PET models, and even other emulators.
is this with SDL or with GTK? and using which keymap?
That's GTK (the one with the drop-down menu), and I tested it with the "graphics(US)" mapping in 4032. I also tested it by then switching to business(US) mapping, with the same effect (you need to change the selected row in the test program at $0342 from 8 to 6)
Wow you make it really hard... In the same setup (4032, graphics (us) keymapping, 3.4 (GTK3 3.24.13, GLib 2.62.4)), when you press the left SHIFT key, and then a character key (e.g. "m"), row 8 (where the shift keys are) suddenly show both shift keys pressed.
Interestingly: when you press the right SHIFT key, and then the character key, the other shift key is not activated.
Also: When you press the left SHIFT key and e.g. a number key, the second shift key is also not activated. (This might have to do with the fact that the shifted number keys on the PC are mapped to non-shifted keys on the PET - it actually disables both shift keys, which is actually expected)
You can use the same test program as above.
What I am trying to do is to emulate a CTRL key (and preferrably SHIFT-CTRL as well) for my GeckOS operating system, by defining the order in which one or both shift keys are pressed or released. This bug makes it really hard in VICE....
seems the same thing can be reproduced in x64sc, see testprogs/CIA/ciaports.prg ... so the problem is in the generic keyboard handling. fixing this will be tricky, that stuff is a mess =P
Last edit: gpz 2020-01-30
there's also other problems i think. in x64sc:
now the first initially pressed key is also released. i did test with attached prg
but in "READY" mode, it can be seen too:
this is also the case for all other keys.
doing the same in the attached prg we see S is pressed again shortly after releasing RIGHT SHIFT
or do this:
now RIGHT SHIFT is pressed too
and as mentioned (i guess) we cannot press both shift keys together. well, we can, but only the first one is recognised.
at least it works differently in hoxs64.
Last edit: Querino 2020-02-02
"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
interesting. but honestly, i don't know if this really could be a problem in a real use case.
Well, what I am trying to do is to emulate a CTRL-key on the PET. The PET with the graphics keyboard does only have the two SHIFT keys as modifiers, no CTRL, or REPEAT (like the PET business keyboard).
perhaps you could map some other key(s) to shift, ie keys that are not modifiers on the host. that should at least tell if the host (GUI) is the problem, or if its the underlaying matrix emulation.
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.
but the latest pokefinder native windows v3.2 also only recognises the first pressed of the two.
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.
Last edit: Greg King 2020-02-02
but then. it's not like this in the SDL version. :)
Last edit: Querino 2020-02-03
I just compiled the SDL version of VICE on Linux. Actually the shift key handling work in this case! I.e. the test program from above provides the correct feedback. I.e. you can press both shift keys, release one of them and still get the correct remaining SHIFT key mapped.
However, the keymap is broken in many other ways, keys seem to have been mapped around a lot (xpet -model 4032, graphics(us) keyboard mapping, on a Linux PC with German keyboard).
The most annoying is that the xpet Backspace (DEL) is nowhere to be found on the PC keyboard, and even the RETURN key produces a '#' instead.
Just tested -model 8032 (business(us) mapping). Here the SHIFT handling also works.
However, even though I seem to be able to enter all keys, some of them are mapped around, e.g. ":" is where the "-" is on my PC keyboard. "," and "." are ok - but with SHIFT I get "<" and ">" instead of ";" and ":". I can't seem to enter the semi-colon. And the asterisk appears when I press SHIFT-Minus.
If that is supposed to be a positional keyboard mapping, some help would be nice, where which key is mapped. It's certainly not a character-based mapping.
the PET keymaps have been broken for a long time, perhaps someone who knows the PETs better than me can fix them =P
(i think there is also some confusion about what PET models use which keyboards)
If that is a bait, I'm not gonna take it ;-)
Here http://www.6502.org/users/andre/petindex/keyboards.html is all the information you need. 2001, 3032 and 4032 use graphics keyboard. 4032B, 8032 and up use business keyboard mapping. Mappings are documented on this page.
I have created proper SDL keymaps and fixed the keymap handling so that by default you will now actually get a working symbolic map for german keyboard (hopefully) :)
Fatality! Assigning to self,
bug #1213 is a dupe of this one, PET testprogram can be found in PET/keyscan/keybscan.prg
should be fixed in r37832 - please test again
I have a real/physical 4016 (with 32K RAM upgrade, and I guess US 60hz model), the OP sample assembler does produce different symbols with LEFT, RIGHT, and BOTH.
I tried this today with the VICE emulator xpet 3.5 (GTK3 3.24.24, GLib 2.66.3) Win10 x86_x64 build. The results are not exactly the same. The "first shift key" wins -- meaning, if I press LEFT, and then press RIGHT, it doesn't count as both (and vice versa).
Not a HUUUGE deal... and I don't know if my build includes this r37832 from nearly a year ago. But at least indicating LEFT is pressed or RIGHT is pressed is pretty cool.
Perhaps the keyboard debug widget might help?
Settings -> Input devices -> Keyboard -> 'Enable keyboard debugging on statusbar' checkbox.
Last edit: compyx 2021-04-16