| |
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. |
|
... 24 posts hidden. Click here to view all posts....
|
| |
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 |
| Previous - 1 | 2 | 3 | 4 - Next |
