| |
Laxity
Registered: Aug 2005
Posts: 459 |
Detecting ctrl and shift pressed simultaniously
OK.. here goes.
I need to find out if it's possible to detect simultanious key presses of both Ctrl and shift (both left and or right). The code I've written for detecting this works nicely in Vice, but the question is if the key matrix of the real c64 hardware allows this?
Unfortunately my 64 is broken, so I'm unable to investigate this myself. |
|
| |
Wanderer
Account closed
Registered: Apr 2003
Posts: 478 |
Location 653 = 3, works on my 64 :) |
| |
Laxity
Registered: Aug 2005
Posts: 459 |
What's that? |
| |
Wanderer
Account closed
Registered: Apr 2003
Posts: 478 |
Quote: What's that?
Ooops... I thought you meant C= and Shift. |
| |
Laxity
Registered: Aug 2005
Posts: 459 |
Took me a few moments to figure out that location 653 was actually in the memory map :) .. Thanks a bunch..
The thing is, I'm not using the kernal to handle key input so I was completely unaware of this one.. It's been a while you know :)
Cheers again. |
| |
Laxity
Registered: Aug 2005
Posts: 459 |
Oh. Well, control should be registered on there too, if I'm not mistaken (bit 2).. .. So, if you're able to get 5 in location 653, I'm home safe.. ;) |
| |
Style
Registered: Jun 2004
Posts: 498 |
Laxity: Yes, it should work I believe.
The c64 keyboard matrix allows you to detect most keys independently of each other, except for restore and shift lock.
(Edit: Dont use kernel junk - its a waste of time) |
| |
Laxity
Registered: Aug 2005
Posts: 459 |
I'm not using the kernal.. Wrote my own input library to waste my time on something instead.. :) |
| |
Soren
Registered: Dec 2001
Posts: 547 |
As far as I know you can check CTRL, shiftR, shiftL by using $dc00 and $dc01...
Well any keycombination should be possible this way, apart from RESTORE.
|
| |
Style
Registered: Jun 2004
Posts: 498 |
Quote: As far as I know you can check CTRL, shiftR, shiftL by using $dc00 and $dc01...
Well any keycombination should be possible this way, apart from RESTORE.
and shiftlock, which is a mechanical switch on the left shift?
Edit: Oh, and Laxity, dont forget to account for keybounce. |
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
Quote: and shiftlock, which is a mechanical switch on the left shift?
Edit: Oh, and Laxity, dont forget to account for keybounce.
I do believe Marko or someone had a bit of code that could detect shift-lock, left shift or right shift was used on some (all?) models.
http://sta.c64.org/cbm64kbdlay.html is helpful but won't let you detect if shift-lock or the shift key also mapped the same is pressed. |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
shift lock can be detected and distinguished from the other shift keys (even though it "shouldn't" be possible).. Marko Mäkeäkkölälälä wrote some strange routine to take care of that.
I tried it and it worked.
Not that this was the topic really, but anyway... |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
its called kernal.
secondly IMHO kernal has neat routines to read the keyboard, why should one waste time and memory for that ? Altho in this case kernal probably wouldnt do. |
| |
Style
Registered: Jun 2004
Posts: 498 |
wow, you can detect the difference between shift and shift lock?
How? any details?
They should be equivalent! |
| |
Laxity
Registered: Aug 2005
Posts: 459 |
Quote: As far as I know you can check CTRL, shiftR, shiftL by using $dc00 and $dc01...
Well any keycombination should be possible this way, apart from RESTORE.
I'm doing just that. I wanted to know if the physical key matrix would allow detection of shift and ctrl at the same time :) |
| |
Zyron
Registered: Jan 2002
Posts: 2381 |
There's a Crest-demo that goes on automatically where you can hold the parts with Shift-Lock, don't remember which one right now. |
| |
iopop
Registered: Dec 2001
Posts: 317 |
Quote: There's a Crest-demo that goes on automatically where you can hold the parts with Shift-Lock, don't remember which one right now.
its Krestology 100% - as if you ever wanted to hold the parts in that one anyhow.. :) |
| |
Stryyker
Registered: Dec 2001
Posts: 468 |
Krestology may be the demo - it has a big finger pressing it very early.
LAxity:Yes you can via the link I gave earlier. The biggest issue is if three keys in the grid that align so that you make 3 points of a square (using 8*8 grid) then a 4th key press is registered. Maybe with some clever coding you can eliminate the ghost press. From the link at Joe's site if you pressed 3, 5 and W then R would also be detected even if not pressed. |
| |
Style
Registered: Jun 2004
Posts: 498 |
Quote: There's a Crest-demo that goes on automatically where you can hold the parts with Shift-Lock, don't remember which one right now.
and not the corresponding shift key? |
| |
Laxity
Registered: Aug 2005
Posts: 459 |
Quote: Krestology may be the demo - it has a big finger pressing it very early.
LAxity:Yes you can via the link I gave earlier. The biggest issue is if three keys in the grid that align so that you make 3 points of a square (using 8*8 grid) then a 4th key press is registered. Maybe with some clever coding you can eliminate the ghost press. From the link at Joe's site if you pressed 3, 5 and W then R would also be detected even if not pressed.
Yes, I saw your link. I'm already detecting key presses using $dc00 and $dc01 and it works like a charm. No problem there... Multiple key presses and all is good. Was just wondering as I said a few times already :), if the physical hardware would allow for the combination of shift and control being pressed simulaniously, and apparently it does.. So there's much rejoycing ;) |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: wow, you can detect the difference between shift and shift lock?
How? any details?
They should be equivalent!
From Markos article in C=Hacking #7:
Quote:
The difference between an input and an output is that an output uses more current to drive the signal to the desired level. An input and an output outputting logical '1' are equivalent for any other inputting chip. But if a chip is trying to drive a signal to ground level, it needs more current to sink an output than an input. You can even use outputs as inputs, i.e. read them in your program.
You can use this feature to distinquish between the left shift and the shift lock keys, although they are connected to same hardware lines. The shift lock key has smaller resistance than the left shift. If you make both CIA 1 ports to outputs (write $FF to $DC03 and $DC01) prior reading the left shift key, only shift lock can change the values you read from CIA 1 port B ($DC01).)
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Indeed, you cannot detect any key combinations possible. Two keys pressed at the same time are possible, but at already three (i think) you get short circuits in the matrix for certain key combinations, and more short circuit-prone combinations with rising number of pressed keys to detect at the same time.
That is, keys may be left released in the checked combination but are still reported as being pressed (Giana Sisters cheat code, pressing ARMIN will skip a level - as intended by the author, but pressing ARMN will do that as well).
Or, different keys kan be pressed instead of some of the keys in the checked combination (Giana Sisters ARMIN again, but i forgot the extra key combination that works as well).
Oh and also Deus Ex Machina allows you to hold parts by pressing left shift or shift lock. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Also, if many keys are involved, some completely different key might replace several others. To stick at the Giana Sisters example:
ARMIN is the intended combination.
ARMN is an example that a key might not be needed to achieve the same port settings.
But:
AWXZ also works, or ARM together with one of the SHIFT-keys. |
| |
Style
Registered: Jun 2004
Posts: 498 |
Quote: From Markos article in C=Hacking #7:
Quote:
The difference between an input and an output is that an output uses more current to drive the signal to the desired level. An input and an output outputting logical '1' are equivalent for any other inputting chip. But if a chip is trying to drive a signal to ground level, it needs more current to sink an output than an input. You can even use outputs as inputs, i.e. read them in your program.
You can use this feature to distinquish between the left shift and the shift lock keys, although they are connected to same hardware lines. The shift lock key has smaller resistance than the left shift. If you make both CIA 1 ports to outputs (write $FF to $DC03 and $DC01) prior reading the left shift key, only shift lock can change the values you read from CIA 1 port B ($DC01).)
Jesus Marko is a smart guy - I would have never thought to try that, altho the theory is very sound.
|
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
Quote: Jesus Marko is a smart guy - I would have never thought to try that, altho the theory is very sound.
It was first done by ZYX-soft of Finnish Gold, they used it to select different musics inside one of their demos.
Edit: it's in D.Y.S.P.I.D.C.E. |
| |
zdzisek
Account closed
Registered: Apr 2002
Posts: 33 |
It's rather advisable to test routines like this on a real thing - partly because of a different way of simultaneous key presses handling in Windows systems, and partly due to bugs in the emulators. For example, SHIFT handling is fucked up in VICE: hold left SHIFT, then hold the right one, release right SHIFT, and release the left one - VICE will think that the right SHIFT key is still pressed. Anyone up to fixing keyboard.c? ;-)
I reckon some fully reliable emulator detection routine could be written if someone took time to investigate it further, but it would require user interaction, so it's pointless anyway. ;-) |
| |
Hoogo
Registered: Jun 2002
Posts: 105 |
There was a way to distinguish 3 keys. I think this one worked: sei
main
lda#254
sta 2
ldy#0
lda#4
sty adr1a+1
sta adr1a+2
sty adr1b+1
sta adr1b+2
lda#255
ldy#0
sta $dc02
sty $dc03
.loop1a lda 2
sta $dc00
ldx#7
lda $dc01
.loop1b asl
bcs .nokey1
pha
adr1a lda 1024,x
ora#1
adr1b sta 1024,x
pla
.nokey1 dex
bpl .loop1b
lda#40
clc
adc adr1a+1
sta adr1a+1
sta adr1b+1
lda adr1a+2
adc#0
sta adr1a+2
sta adr1b+2
sec
rol 2
bcs .loop1a
lda#254
sta 2
ldy#0
lda#4
sty adr2a+1
sta adr2a+2
sty adr2b+1
sta adr2b+2
ldy#255
lda#0
sta $dc02
sty $dc03
.loop2a lda 2
sta $dc01
ldx#7
lda $dc00
.loop2b lsr
pha
bcs .nokey2
adr2a lda 1024
ora#2
adr2b sta 1024
.nokey2
lda#40
clc
adc adr2a+1
sta adr2a+1
sta adr2b+1
lda#0
adc adr2a+2
sta adr2a+2
sta adr2b+2
pla
dex
bpl .loop2b
lda adr2a+1
sec
sbc#<(8*40-1)
sta adr2a+1
sta adr2b+1
lda adr2a+2
sbc#>(8*40-1)
sta adr2a+2
sta adr2b+2
sec
rol 2
bcs .loop2a
jsr $e544
jmp main
|
| |
Laxity
Registered: Aug 2005
Posts: 459 |
Hmm.. Maybe I haven't done my homework. I'm not really doing anything with $dc02 and $dc03 (CIA1 post A/B data direction registers) in my input routines. Do these really need to be reset to read/write each time I attempt to scan the keyboard matrix, as long as I don't have the kernal changing the state of the CIA?.. As far as I can see CIA2 is used for serial comm, so once the port directions have been setup propertly on CIA1, they ought to remain as such. Or am I mistaken? (Edit: I'm using kernal to read and write to and from disk, nothing else...)
Works in Vice this way, but I do not trust the emulator on that account. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: Hmm.. Maybe I haven't done my homework. I'm not really doing anything with $dc02 and $dc03 (CIA1 post A/B data direction registers) in my input routines. Do these really need to be reset to read/write each time I attempt to scan the keyboard matrix, as long as I don't have the kernal changing the state of the CIA?.. As far as I can see CIA2 is used for serial comm, so once the port directions have been setup propertly on CIA1, they ought to remain as such. Or am I mistaken? (Edit: I'm using kernal to read and write to and from disk, nothing else...)
Works in Vice this way, but I do not trust the emulator on that account.
with dc02/dc03 you set dc00/dc01 to input or output..
for reading keys, you should do this :
ldx #$ff ;port dc00 = outputs
stx $dc02
inx ;port dc01 = inputs
stx $dc03
|
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quote: It's rather advisable to test routines like this on a real thing - partly because of a different way of simultaneous key presses handling in Windows systems, and partly due to bugs in the emulators. For example, SHIFT handling is fucked up in VICE: hold left SHIFT, then hold the right one, release right SHIFT, and release the left one - VICE will think that the right SHIFT key is still pressed. Anyone up to fixing keyboard.c? ;-)
I reckon some fully reliable emulator detection routine could be written if someone took time to investigate it further, but it would require user interaction, so it's pointless anyway. ;-)
Oh there are better ways to check for an emulator... ways that don't require user input :D
Anyways, i think you can never fix an emulator to emulate the keyboard 100% since the keyboard matrixes used nowadays should work a little different concerning short-circuits than the c64 one, since there are more lines and the keys are connected differently to that matrix. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
@wvl: you can ofcourse also swap the two ports and use $dc00 as input and $dc01 as output. if you want a truely 100% scanner (which maybe should even still work together with joysticks) you might want to check both directions AND exploit the output/output thing too |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: @wvl: you can ofcourse also swap the two ports and use $dc00 as input and $dc01 as output. if you want a truely 100% scanner (which maybe should even still work together with joysticks) you might want to check both directions AND exploit the output/output thing too
urgh.. i have no idea :)
this is the routine i use for checking CERTAIN keys..
checkforkeys
ldx #5 ;number of keys-1 to check
checkkeyloop
lda keycolumn,x
sta $dc00
lda $dc01
eor #$ff
ldy keyindex,x
and keyrow,x
sta $00,y
dex
bpl checkkeyloop
keycolumn ;6 bytes
.byte $7f,$fd,$bf,$7f,$bf,$df ;runstop,lshift,/,space,poundkey,p
keyrow ;6 bytes
.byte $80,$80,$80,$10,$01,$02
keyindex ;6 bytes
.byte <exitkey,<leftflipper,<rightflipper,<tiltkey,<crsrdown,<pausekey
it will set the zp-adress for each key to 0 if it was not pressed, any other value means it is pressed.
|
| |
zdzisek
Account closed
Registered: Apr 2002
Posts: 33 |
Quote: Oh there are better ways to check for an emulator... ways that don't require user input :D
Anyways, i think you can never fix an emulator to emulate the keyboard 100% since the keyboard matrixes used nowadays should work a little different concerning short-circuits than the c64 one, since there are more lines and the keys are connected differently to that matrix.
http://www.hoxs64.com/ <- try out this one. It passes the Emu-Fuxx0r v1/v2 tests and SounDemon's Waveform Composer emulation detection. Any new test routines that can be used to further improve the emulation are very welcome. :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
zdzisek: you're not the authfor of hoxs, are you? i have some emu-checks up my sleeve but didnt care to hack them down so far.. :D |
| |
zdzisek
Account closed
Registered: Apr 2002
Posts: 33 |
Quote: zdzisek: you're not the authfor of hoxs, are you? i have some emu-checks up my sleeve but didnt care to hack them down so far.. :D
No, I ain't the one behind Hoxs64 - I've been closely following the project since its emulation improved, and reported a couple of flaws to the author. I can pass the checks on to him (admittedly, I would like to have a peek myself ;-) if needed. |
