Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user maak ! (Registered 2024-04-18) You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > looking for rom independent keyboard read routine
2010-04-24 07:07
Oswald

Registered: Apr 2002
Posts: 5017
looking for rom independent keyboard read routine

I'm lazy, anyone can help me out? I'd need shift+crsrs + return aswell, not just alphanumeric stuff.
thanks.
2010-04-24 07:11
Frantic

Registered: Mar 2003
Posts: 1627
The one in C= Hacking regarding "three key rollover" is ROM independent, and if you don't want that fancy roll-over stuff, it is easy to modify:

http://codebase64.org/doku.php?id=magazines:chacking6#three-key..
2010-04-24 07:12
Oswald

Registered: Apr 2002
Posts: 5017
I see there's already like 3 topics on this here :) should have searched first. thanks :)
2010-04-24 08:36
Mace

Registered: May 2002
Posts: 1799
Yeah, shoo!
2010-04-24 10:01
chatGPZ

Registered: Dec 2001
Posts: 11100
i should post the one i made for my tracker loooooong ago on codebase. if i only knew where i have the source for that.... =P
2010-04-24 14:09
Ed

Registered: May 2004
Posts: 173
I made some halfhearted attempt in my unfinished gfx editor. However it has some bugs.

2010-04-24 16:28
Oswald

Registered: Apr 2002
Posts: 5017
who can make a faster/better one ? :) here's one from the top of my head, unrolled style:

lda #%11111110
sta $dc00
ldy $dc01
ldx table,y
ldy row/col key table,x
cpy pressedinthisrow/col
beq ;do somekindoffdebounce?
sty pressedinthisrow/col

next row/col

"table" translates 0111111 => 0, 101111 => 1, 11011111=2, for indexing a byte table. more than 2 zero bits would give $ff (dont need that except for shift,etc) for a bmi error check. Then I'd do a pinpoint scan for shifts/c=, etc.
2010-04-24 17:14
TWW

Registered: Jul 2009
Posts: 541
here is a crude table I made for this kind of routine a while back (Don't remeber where i got this info (maybee 3 key rollover or the ref. manual). Maybee it could be of some use...


$dc00 is used for selecting one of eight the scan rows as folows and the $dc01 value is then peeked:
+----+----------------------+--------------------------------------------------- ----------------------------------------------------+
|    |                      |                                Peek from $dc01 (code in paranthesis):                                 |
|row:| $dc00:               +------------+------------+------------+------------+------------+------------+- -----------+------------+
|    |                      |   BIT 8    |   BIT 7    |   BIT 6    |   BIT 5    |   BIT 4    |   BIT 3    |   BIT 2    |   BIT 1    |
+----+----------------------+------------+------------+------------+------------ +------------+------------+------------+------------+
|1.  | #%11111110 (254/$fe) | DOWN  ($  )|   F5  ($  )|   F3  ($  )|   F1  ($  )|   F7  ($  )| RIGHT ($  )| RETURN($  )|DELETE ($  )|
|2.  | #%11111101 (253/$fd) |LEFT-SH($  )|   e   ($05)|   s   ($13)|   z   ($1a)|   4   ($34)|   a   ($01)|   w   ($17)|   3   ($33)|
|3.  | #%11111011 (251/$fb) |   x   ($18)|   t   ($14)|   f   ($06)|   c   ($03)|   6   ($36)|   d   ($04)|   r   ($12)|   5   ($35)|
|4.  | #%11110111 (247/$f7) |   v   ($16)|   u   ($15)|   h   ($08)|   b   ($02)|   8   ($38)|   g   ($07)|   y   ($19)|   7   ($37)|
|5.  | #%11101111 (239/$ef) |   n   ($0e)|   o   ($0f)|   k   ($0b)|   m   ($0d)|   0   ($30)|   j   ($0a)|   i   ($09)|   9   ($39)|
|6.  | #%11011111 (223/$df) |   ,   ($2c)|   @   ($00)|   :   ($3a)|   .   ($2e)|   -   ($2d)|   l   ($0c)|   p   ($10)|   +   ($2b)|
|7.  | #%10111111 (191/$bf) |   /   ($2f)|   ^   ($1e)|   =   ($3d)|RGHT-SH($  )|  HOME ($  )|   ;   ($3b)|   *   ($2a)|   £   ($1c)|
|8.  | #%01111111 (127/$7f) | STOP  ($  )|   q   ($11)|COMMODR($  )| SPACE ($20)|   2   ($32)|CONTROL($  )|  <-   ($1f)|   1   ($31)|
+----+----------------------+------------+------------+------------+------------ +------------+------------+------------+------------+
2010-04-24 17:22
chatGPZ

Registered: Dec 2001
Posts: 11100
this is what i use if all i need is simple keychecking (one key at a time, no extras)

minikey:
	lda #$0
	sta $dd03	; port b ddr (input)
	lda #$ff
	sta $dd02	; port a ddr (output)
			
	lda #$00
	sta $dc00	; port a
	lda $dc01       ; port b
	cmp #$ff
	beq nokey
	; got column
	tay
			
	lda #$7f
	sta nokey2+1
	ldx #8
nokey2:
	lda #0
	sta $dc00	; port a
	
	sec
	ror nokey2+1
	dex
	bmi nokey
			
	lda $dc01       ; port b
	cmp #$ff
	beq nokey2
			
	; got row in X
	txa
	ora columntab,y
			
	sec
	rts
			
nokey:
	clc
	rts

columntab:
	.repeat 256,count
		.if count = ($ff-$80)
			.byte $70
		.elseif count = ($ff-$40)
			.byte $60
		.elseif count = ($ff-$20)
			.byte $50
		.elseif count = ($ff-$10)
			.byte $40
		.elseif count = ($ff-$08)
			.byte $30
		.elseif count = ($ff-$04)
			.byte $20
		.elseif count = ($ff-$02)
			.byte $10
		.elseif count = ($ff-$01)
			.byte $00
		.else
			.byte $ff
		.endif
	.endrepeat

2010-04-24 18:42
Oswald

Registered: Apr 2002
Posts: 5017
nice codebase material, thanks :)
2010-04-24 19:38
Frantic

Registered: Mar 2003
Posts: 1627
Yes, hehe.. sigh.. I felt obliged to put this stuff there, so I did:

http://codebase64.org/doku.php?id=base:reading_the_keyboard

...but I would indeed appreciate if people could just throw the code itself up there at once instead of posting it here, and just post a link to the code from here to there, or so... :)
2010-04-25 07:51
Oswald

Registered: Apr 2002
Posts: 5017
all keys + shift handling, one key at a time max:

(btw at groepaz's code I think dd02/3 should be dc02/3 or not needed)

lastkey	= $10
actkey	= $11
mask	= $12

matrixlo	= $13
matrixhi	= $14

table	= $0f00

	*= $1000
	
	lda #$37
	sta $01
	jsr $e544
	
	sei
	lda #$35
	sta $01
	
	ldx #$00
	lda #$00
-	sta table,x
	dex
	bne -
	
	lda #$ff
	sta lastkey
	
	lda #$08		;helper table to index into keyboard matrix
	sta table+%01111111
	lda #$07
	sta table+%10111111
	lda #$06
	sta table+%11011111
	lda #$05
	sta table+%11101111
	lda #$04
	sta table+%11110111
	lda #$03
	sta table+%11111011
	lda #$02
	sta table+%11111101
	lda #$01
	sta table+%11111110
	
	lda #$08		;left shift and another key
	sta table+%01111111
	lda #$07
	sta table+%00111111
	lda #$06
	sta table+%01011111
	lda #$05
	sta table+%01101111
	lda #$04
	sta table+%01110111
	lda #$03
	sta table+%01111011
	lda #$02
	sta table+%01111101
	lda #$01
	sta table+%01111110	
	
	lda #$08		;right shift and another key
	sta table+%01101111
	lda #$07
	sta table+%10101111
	lda #$06
	sta table+%11001111
	lda #$05
	sta table+%11101111
	lda #$04
	sta table+%11100111
	lda #$03
	sta table+%11101011
	lda #$02
	sta table+%11101101
	lda #$01
	sta table+%11101110


	;endless dummy 
	
uu	jsr keyscan
	lda actkey
	cmp #$ff	;$ff= no key pressed
	beq +
	cmp #$40	;convert to screen codes
	bmi ok
	sec
	sbc #$40
ok
	sta $0400
+	jmp uu
	

	
	

keyscan	lda #%11111110
	sta mask
	
	lda #%11111101
	sta $dc00
	lda $dc01
	and #%10000000
	beq shifted	;left shift pressed

	lda #%10111111
	sta $dc00
	lda $dc01
	and #%00010000
	beq shifted	;right shift pressed
	
	lda #<keytabunshifted
	sta matrixlo
	lda #>keytabunshifted
	sta matrixhi
	jmp scan

shifted
	lda #<keytabshifted
	sta matrixlo
	lda #>keytabshifted
	sta matrixhi
	
scan	ldx #$07
	
rowloop	lda mask	
	sta $dc00
	ldy $dc01
	lda table,y
	beq next
		
	tay
	lda (matrixlo),y
	cmp #$01
	beq next		;skip left shift
	cmp #$02
	beq next		;skip right shift
	cmp lastkey
	beq debounce
	sta lastkey
	sta actkey
	rts
	
next	
	sec
	rol mask
		
	lda matrixlo
	clc
	adc #$09
	sta matrixlo
	bcc *+4
	inc matrixhi
	
	dex
	bpl rowloop
	rts
	
debounce	lda #$ff
	sta actkey
	rts
		
	;unshifted
	
keytabunshifted

	.byte $ff,$14,$0D,$1D,$88,$85,$86,$87,$11 ;0
	.byte $ff,$33,$57,$41,$34,$5A,$53,$45,$01 ;1
	.byte $ff,$35,$52,$44,$36,$43,$46,$54,$58 ;2
	.byte $ff,$37,$59,$47,$38,$42,$48,$55,$56 ;3
	.byte $ff,$39,$49,$4A,$30,$4D,$4B,$4F,$4E ;4
	.byte $ff,$2B,$50,$4C,$2D,$2E,$3A,$40,$2C ;5
	.byte $ff,$5C,$2A,$3B,$13,$01,$3D,$5E,$2F ;6
	.byte $ff,$31,$5F,$04,$32,$20,$02,$51,$03 ;7
	.byte $ff

keytabshifted	
	.byte $ff,$94,$8D,$9D,$8C,$89,$8A,$8B,$91
	.byte $ff,$23,$D7,$C1,$24,$DA,$D3,$C5,$01
	.byte $ff,$25,$D2,$C4,$26,$C3,$C6,$D4,$D8
	.byte $ff,$27,$D9,$C7,$28,$C2,$C8,$D5,$D6
	.byte $ff,$29,$C9,$CA,$30,$CD,$CB,$CF,$CE
	.byte $ff,$DB,$D0,$CC,$DD,$3E,$5B,$BA,$3C
	.byte $ff,$A9,$C0,$5D,$93,$01,$3D,$DE,$3F
	.byte $ff,$21,$5F,$04,$22,$A0,$02,$D1,$83
	.byte $ff


	;one extra $ff column is added, because the zero value is used to detect unpressed kays
2010-05-29 13:43
TWW

Registered: Jul 2009
Posts: 541
Quote: here is a crude table I made for this kind of routine a while back (Don't remeber where i got this info (maybee 3 key rollover or the ref. manual). Maybee it could be of some use...


$dc00 is used for selecting one of eight the scan rows as folows and the $dc01 value is then peeked:
+----+----------------------+--------------------------------------------------- ----------------------------------------------------+
|    |                      |                                Peek from $dc01 (code in paranthesis):                                 |
|row:| $dc00:               +------------+------------+------------+------------+------------+------------+- -----------+------------+
|    |                      |   BIT 8    |   BIT 7    |   BIT 6    |   BIT 5    |   BIT 4    |   BIT 3    |   BIT 2    |   BIT 1    |
+----+----------------------+------------+------------+------------+------------ +------------+------------+------------+------------+
|1.  | #%11111110 (254/$fe) | DOWN  ($  )|   F5  ($  )|   F3  ($  )|   F1  ($  )|   F7  ($  )| RIGHT ($  )| RETURN($  )|DELETE ($  )|
|2.  | #%11111101 (253/$fd) |LEFT-SH($  )|   e   ($05)|   s   ($13)|   z   ($1a)|   4   ($34)|   a   ($01)|   w   ($17)|   3   ($33)|
|3.  | #%11111011 (251/$fb) |   x   ($18)|   t   ($14)|   f   ($06)|   c   ($03)|   6   ($36)|   d   ($04)|   r   ($12)|   5   ($35)|
|4.  | #%11110111 (247/$f7) |   v   ($16)|   u   ($15)|   h   ($08)|   b   ($02)|   8   ($38)|   g   ($07)|   y   ($19)|   7   ($37)|
|5.  | #%11101111 (239/$ef) |   n   ($0e)|   o   ($0f)|   k   ($0b)|   m   ($0d)|   0   ($30)|   j   ($0a)|   i   ($09)|   9   ($39)|
|6.  | #%11011111 (223/$df) |   ,   ($2c)|   @   ($00)|   :   ($3a)|   .   ($2e)|   -   ($2d)|   l   ($0c)|   p   ($10)|   +   ($2b)|
|7.  | #%10111111 (191/$bf) |   /   ($2f)|   ^   ($1e)|   =   ($3d)|RGHT-SH($  )|  HOME ($  )|   ;   ($3b)|   *   ($2a)|   £   ($1c)|
|8.  | #%01111111 (127/$7f) | STOP  ($  )|   q   ($11)|COMMODR($  )| SPACE ($20)|   2   ($32)|CONTROL($  )|  <-   ($1f)|   1   ($31)|
+----+----------------------+------------+------------+------------+------------ +------------+------------+------------+------------+


I have made a routine aswell for keyboard scanning.

However right now i am using the X & Y-regs to pass any special keys like CTRL, C=, etc.

Are there any standard over which codes should be "inserted" in my keyscan matrix above?

I'm asking coz I want my routine to be as "standard" as possible :)
2010-05-29 17:57
Devia

Registered: Oct 2004
Posts: 401
If you want standard, use KERNAL!

I wrote a routine some years back. Basic operation of that goes something like this: An IRQ routine takes a snapshot of the current state of the matrix. Then it updates 2 other tables with key up and key down states. The key up/down matrices only gets cleared when a message is passed to the IRQ routine from "user code" to do so.
The "user code", running outside IRQ or in another IRQ or whatever, can then choose to do whatever it wants with the key up/down events and then acknowledge them once they have been handled.

For the "user code" to check/ack keys I use macros like these:
.macro KBCheckKey key			;Returns zero if the checked key is pressed
	ldy	#<(key)			;Keyboard matrix row number in Y
	lda	#>(key)			;Keyboard matrix row value for given key in A
	and	KBMatrixSnapShot,y	;Check given key value against row value in matrix
.endmacro				;If equal, Zero flag is cleared

.macro KBCheckKeyDown key		;Returns zero if the checked key has a Key Down event
	ldy	#<(key)			;Keyboard matrix row number in Y
	lda	#>(key)			;Keyboard matrix row value for given key in A
	and	KBMatrixKeyDown,y	;Check given key value against row value in matrix
.endmacro				;If equal, Zero flag is cleared

.macro KBCheckKeyUp key			;Returns zero if the checked key has a Key Up event
	ldy	#<(key)			;Keyboard matrix row number in Y
	lda	#>(key)			;Keyboard matrix row value for given key in A
	and	KBMatrixKeyUp,y		;Check given key value against row value in matrix
.endmacro				;If equal, Zero flag is cleared

.macro KBAckEvents			;Acknowledge all Key Up/Down events
	lda	#$01
	ora	KBMSG
	sta	KBMSG
.endmacro


The keys have then been defined like the following:
KEY_F3		= $2000	;.byte	%00100000,0
KEY_F5		= $4000	;.byte	%01000000,0
KEY_CRSRUD	= $8000	;.byte	%10000000,0

KEY_3		= $0101	;.byte	%00000001,1
KEY_W		= $0201	;.byte	%00000010,1
KEY_A		= $0401	;.byte	%00000100,1


Each key combined by column/row in 2 bytes. (I'm writing $dc00 and reading $dc01)

Is that a KB handler then? No. It's more like a KB hardware driver for which I have to write a handler every time. But since I haven't needed full textual input for any of my projects yet, I haven't even thought out any general purpose style kb handler.
2010-05-29 20:06
TWW

Registered: Jul 2009
Posts: 541
Read the post TOPIC!

Forget about ROM.

To read and decipher $dc00/dc01 isn't a problem...


The problem is to assign the non-graphical keys to the scan-matrix you can find in my post above and return a value which means "CTRL" pressed or somesuch instead of passing the information via bits set/clear in reg's / stack etc...

This also means you don't need to scan for special keys and decipher them differently / pass they differently then ordinary alphanumeric keys if they have a proper code assigned.
2012-04-07 15:41
Hein

Registered: Apr 2004
Posts: 933
How's it possible that when I have this pretty piece of code:

lda #$fd
sta $dc00

lda $dc01
eor #$ff

I get only 2 bits from $dc01 when I press keys 3-4-E at the same time, but I get 3 bits from $dc01 when I press 3-W-A at the same time. According to this matrix sta.c64.org/cmb64kbdlay.html those keys are on the respective selected row.

This happens in VICE btw, and on other row/column combinations as well.
2012-04-07 16:42
Repose

Registered: Oct 2010
Posts: 222
Keyboards explained in detail in Transactor 5-05.
http://cbm.csbruce.com/cbm/transactor/v5/i5/

Also, distinguish left from right shift
ftp://n2dvm.com/Commodore/Commie-CDs/Kazez%20FREE-CD/c64-knowle..
2012-04-07 17:29
Hein

Registered: Apr 2004
Posts: 933
Quote: Keyboards explained in detail in Transactor 5-05.
http://cbm.csbruce.com/cbm/transactor/v5/i5/

Also, distinguish left from right shift
ftp://n2dvm.com/Commodore/Commie-CDs/Kazez%20FREE-CD/c64-knowle..


The transactor pdf is interesting, but it doesn't answer my question.

I only need to know if I can do a 3-key-at-once check (4 if you include shift/cbm-key) by simply reading the column byte each row and shift it 8 times to get all the key-bits in that row.

Seems bits get lost with some combinations of keys.
2012-04-07 19:10
Repose

Registered: Oct 2010
Posts: 222
I think you'll have to try it. I believe there's physical limits to how many keys can be read in one row/column due to the power available. I know Marko Makela has the answer. If you search for him and keyboards he's done a clever trick with reading caps lock or shift even though they are physically connected, or some such thing.

Sorry I didn't give best answer, I didn't have a lot of time. We celebrate Easter in my country.
2012-04-07 19:26
Hein

Registered: Apr 2004
Posts: 933
Quote: I think you'll have to try it. I believe there's physical limits to how many keys can be read in one row/column due to the power available. I know Marko Makela has the answer. If you search for him and keyboards he's done a clever trick with reading caps lock or shift even though they are physically connected, or some such thing.

Sorry I didn't give best answer, I didn't have a lot of time. We celebrate Easter in my country.


The 'physical limits' sounds like a reasonable posibility.

I've tried it, btw, wondering if my routine was borked or the hardware is limited.

The simplest check is what I wrote in my 1st post in this thread, reading the column bits in one row and it turned out some key-combinations in that row result in all proper bits, whereas other key-combinations in that row result in max 2 bits.

Thanks for the effort anyway :) Happy easter.
2012-04-07 19:29
Frantic

Registered: Mar 2003
Posts: 1627
Can't really give solid info either, but I can just confirm that I have also noticed that some key combinations work, and some don't, when you use some key combinations that involve several keys. Seems to be a hardware thing, yes..
2012-04-07 19:57
Repose

Registered: Oct 2010
Posts: 222
<speculation retracted>
Here ya go:
Quote:

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).)


http://ar.c64.org/wiki/Hiding_kilobytes_C%3DHacking_Issue_7.txt

So my memory was correct about the resistances. The reason is NMOS chips have weak pullup current.
What I'm wondering is if it's consistent across keyboards. I have 2 unnconnected keyboards here I can test the resistance of later.
Maybe I can write a test program and you guys can try it out?
2012-04-08 07:10
MagerValp

Registered: Dec 2001
Posts: 1055
Quoting Hein
This happens in VICE btw, and on other row/column combinations as well.

Then you're not using a keyboard with N-key rollover. The C64 has no such problem:

https://www.dropbox.com/gallery/839742/1/C64?h=4aeb14#/
2012-04-08 07:41
Hein

Registered: Apr 2004
Posts: 933
Quote: Quoting Hein
This happens in VICE btw, and on other row/column combinations as well.

Then you're not using a keyboard with N-key rollover. The C64 has no such problem:

https://www.dropbox.com/gallery/839742/1/C64?h=4aeb14#/


:) Olright, I didn't expect modern (expensive) equipment to be so lame, confirmed that:

the quick brown fox jumps over the lazy dog

typed with left and right shift pressed resulted in:

THEUIKROWFOJUPSOERTHELAYDOG

Thanx, at least I can continue coding worry-free.

2013-07-30 21:35
Hein

Registered: Apr 2004
Posts: 933
Some shameless hack 'n slash of Groepaz' and Oswald's routines, extending it to a 3 keys check.
Is there an indication as to why this will give unpredicted results when used on real hardware?

The handling of the 3 byte key-buffer is done in other routines.

zp_keyboard_current = $10   ;zeropage keycode buffer

	ldy #((continue_key-get_kb_column+1) ^ 255)
	sty continue_key+1
	
	ldy #$40
	
	lda #%11111101
	sta $dc00
	lda $dc01
	and #%10000000
	beq shifted_keys	;left shift pressed

	lda #%10111111
	sta $dc00
	lda $dc01
	and #%00010000
	beq shifted_keys	;right shift pressed

	ldy #$00
shifted_keys
	sty get_shifted_chr+1

						
	lda #%01111111
	sta cur_key_row+1
	
	ldx #64
next_key_row	
cur_key_row	lda #%01111111
	sta $dc00

	sec
	ror cur_key_row+1
	
	txa
	sbx #8
	
	bcc key_rows_finished
	

	lda $dc01
	eor #$ff
	beq next_key_row

	sta cur_kb_column+1
	
	ldy #7
	sty get_kb_column+1
		

get_kb_column	ldy #7
cur_kb_column	lda #0	

-	lsr
	bcs found_kb_column
	dey
	bpl -
	bmi next_key_row

	
key_rows_finished
	ldy #((continue_key-buffer_key+1) ^ 255)
	sty continue_key+1
	lda #0
	beq buffer_key	
	
			
found_kb_column
	sta cur_kb_column+1

	stx get_kb_char_row+1
	
	tya
	
	dey
	sty get_kb_column+1
	
get_kb_char_row	ora #0
get_shifted_chr	ora #0
	tay
	
	lda keyboard_mapping,y
	cmp #$fd		;$fd = C=, $fe = shift
	bcs get_kb_column


buffer_key	sta zp_keyboard_current
	inc buffer_key+1
	ldy buffer_key+1
	cpy #zp_keyboard_current+3
continue_key	bcc get_kb_column

	lda #zp_keyboard_current
	sta buffer_key+1


keyboard_mapping
	.byte $ef-$00,$f5-$00,$f3-$00,$f1-$00,$f7-$00,$ec-$00,$e3-$00,$eb-$00
	.byte $fe-$00,"E"-$40,"S"-$40,"Z"-$40,"4"-$00,"A"-$40,"W"-$40,"3"-$00
	.byte "X"-$40,"T"-$40,"F"-$40,"C"-$40,"6"-$00,"D"-$40,"R"-$40,"5"-$00
	.byte "V"-$40,"U"-$40,"H"-$40,"B"-$40,"8"-$00,"G"-$40,"Y"-$40,"7"-$00
	.byte "N"-$40,"O"-$40,"K"-$40,"M"-$40,"0"-$00,"J"-$40,"I"-$40,"9"-$00
	.byte ","-$00,"@"-$00,":"-$00,"."-$00,$e8-$00,"L"-$40,"P"-$40,$e9-$00
	.byte "/"-$00,$ff-$00,"="-$00,$fe-$00,$ff-$00,";"-$00,"*"-$00,$ff-$00
	.byte $fc-$00,"Q"-$40,$ff-$00,$20-$00,"2"-$00,$e7-$00,$f0-$00,"1"-$00
keyboard_mapping_shifted
	.byte $ed-$00,$f6-$00,$f4-$00,$f2-$00,$f8-$00,$ee-$00,$e3-$00,$ea-$00
	.byte $fe-$00,"E"-$00,"S"-$00,"Z"-$00,"$"-$00,"A"-$00,"W"-$00,"#"-$00
	.byte "X"-$00,"T"-$00,"F"-$00,"C"-$00,"&"-$00,"D"-$00,"R"-$00,"%"-$00
	.byte "V"-$00,"U"-$00,"H"-$00,"B"-$00,"("-$00,"G"-$00,"Y"-$00,"'"-$00
	.byte "N"-$00,"O"-$00,"K"-$00,"M"-$00,"0"-$00,"J"-$00,"I"-$00,")"-$00
	.byte $e6-$00,"@"-$00,"["-$00,$e4-$00,$e8-$00,"L"-$00,"P"-$00,$e9-$00
	.byte "?"-$00,$ff-$00,"="-$00,$fe-$00,$ff-$00,"]"-$00,"*"-$00,$ff-$00
	.byte $fc-$00,"Q"-$00,$ff-$00,$60-$00,'"'-$00,$e5-$00,$f0-$00,"!"-$00
2013-07-30 21:57
TWW

Registered: Jul 2009
Posts: 541
This is the routine which produces PLA I figgure?

I'd put my money on the buffer handling.

Do you do any overflow check (more than 3 keys found, ignore the result)?
2013-07-30 22:46
Hein

Registered: Apr 2004
Posts: 933
Quote: This is the routine which produces PLA I figgure?

I'd put my money on the buffer handling.

Do you do any overflow check (more than 3 keys found, ignore the result)?


If I change 'cpy #zp_keyboard_current+3' to 'cpy #zp_keyboard_current+4' it checks for 4 keys, resulting in a buffer of 'PLWA'. Why shouldn't this 4-key rollover work on a c64? Or N-key, for that matter. I'm not concerned about the order of keys in the buffer. It's handled in a different routine.
2013-07-31 01:38
TWW

Registered: Jul 2009
Posts: 541
Quote: If I change 'cpy #zp_keyboard_current+3' to 'cpy #zp_keyboard_current+4' it checks for 4 keys, resulting in a buffer of 'PLWA'. Why shouldn't this 4-key rollover work on a c64? Or N-key, for that matter. I'm not concerned about the order of keys in the buffer. It's handled in a different routine.

The question is what do your routine do after it detects 3 keys.

Does it continue to check the entire matrix to ensure only 3 keys are pressed?

If not, you could have 4 keys registered due to shadowing which means you may detect a worng key (depends on how you read the matrix and which keys pop up first which in turn totaly relies on the position in the matrix).
2013-07-31 05:34
Hein

Registered: Apr 2004
Posts: 933
The routine stops scanning after N keys, obviously, because my buffer is set to N keys. :) If someone presses N+1 keys, the buffer will be filled with the N keys first found in the matrix.
2013-07-31 06:43
chatGPZ

Registered: Dec 2001
Posts: 11100
Quote:
Is there an indication as to why this will give unpredicted results when used on real hardware?

look at the matrix. when you press 3 keys of which two are in the same row, and two are in the same column, then due to the shortcut a 4th key will be detected. (press A,D,W -> you will also detect R). and there is no way around it, unfortunately. (dont test this on emu, chances are your pc keyboard cant handle it either, and VICE will show pretty irritating results although it can handle 3 keys and matrix shortcuts)
2013-07-31 07:10
Hein

Registered: Apr 2004
Posts: 933
Quote: Quote:
Is there an indication as to why this will give unpredicted results when used on real hardware?

look at the matrix. when you press 3 keys of which two are in the same row, and two are in the same column, then due to the shortcut a 4th key will be detected. (press A,D,W -> you will also detect R). and there is no way around it, unfortunately. (dont test this on emu, chances are your pc keyboard cant handle it either, and VICE will show pretty irritating results although it can handle 3 keys and matrix shortcuts)


Ok, thanks.
2013-07-31 07:22
Oswald

Registered: Apr 2002
Posts: 5017
Quote: Quote:
Is there an indication as to why this will give unpredicted results when used on real hardware?

look at the matrix. when you press 3 keys of which two are in the same row, and two are in the same column, then due to the shortcut a 4th key will be detected. (press A,D,W -> you will also detect R). and there is no way around it, unfortunately. (dont test this on emu, chances are your pc keyboard cant handle it either, and VICE will show pretty irritating results although it can handle 3 keys and matrix shortcuts)


so if an avg pc keyboard cant detect it whats the fuss about detecting 3 keys? 2 ought to be enough for everyone :)

edit:Tested the one I'm sitting on. usually detects 3, and in 20 seconds found a case when it fails to detect a 3rd one.
2013-07-31 07:59
chatGPZ

Registered: Dec 2001
Posts: 11100
Quote:
whats the fuss about detecting 3 keys?

it'd be handy for a SID editor :) other than that i also see no use for it :)
2013-07-31 10:43
Hein

Registered: Apr 2004
Posts: 933
Quote: Quote:
whats the fuss about detecting 3 keys?

it'd be handy for a SID editor :) other than that i also see no use for it :)


Indeed. :)
2013-07-31 20:41
TWW

Registered: Jul 2009
Posts: 541
Just to clarify:

What I define as a "rollover" routine is a routine handling keys being pressed in sequence (first key 1, then key 2 then key 3 without letting go of any of the previous keys). Now before pressing a 4th key the 1st key should be released and so on.

Think of it as a ball "rolling over" the keyboard which then I presume is a metaphore for typing fast where a fast typer holds down more than 1 key at the same time.

Now this is a totally different application then detecting 3 keys at exactly the same time. For typing this is useless as you have no way of knowing which key was intended to be pressed first, second and third. So for a SID composer or some such, the reliable limit is two keys (unless you let go of one of the keys before the other which in case you may detect which was the correct keys. Let go of all at the same time, and you have no chance). For typing text, 3 keys work fine (aka. rollover typing). Just try my routine and type in sequence A+B+C+D then let go of the A and you'll see.
2013-08-01 06:55
chatGPZ

Registered: Dec 2001
Posts: 11100
what you define is kinda irrelevant, lets stick to what the common definition is: https://en.wikipedia.org/wiki/Rollover_(key) "Certain high-end keyboards have "n-key rollover". This means that each key is scanned completely independently by the keyboard hardware, so that each keypress is correctly detected regardless of how many other keys are being pressed or held down at the time."
2013-08-01 12:01
TWW

Registered: Jul 2009
Posts: 541
ShiIit GPZ..... Did you just create that page at Wiki??

"This page was last modified on 31 July 2013 at 20:16."

I'll never trust the internetz again.

hehe...
2013-08-01 12:06
chatGPZ

Registered: Dec 2001
Posts: 11100
i have not bothered with trying to beat sense into wikipedia retards ever since this hopeless case, no worries =) https://de.wikipedia.org/wiki/Diskussion:Rasterzeileninterrupt
2013-08-03 08:46
TWW

Registered: Jul 2009
Posts: 541
unglaublich (yeah I did german for some years at school... I even went to germany to pass my fricking exams (hehe))!

Now that shiz (wiki drama) is just messed up.

Anyway, I updated the Codebase "article" and both the code and shiz is altered according to 3 principles: #1: No more SHIFT LOCK (Hardest camel to swallow as SHIFT LOCK roxorz hard!) #2: Unrolled and optimized quite a bit #3: Return of non alphanumeric keys is done as flags in X & Y registers instead of codes in A (more API friendly?!).

The scope and aim of the routine is hopefully more clear as well. Those of you who wants a piano, design a new keyboard, add diodes and let it rock.

NB! This one is not tested fully yet and I am in the progress of rewriting the testprogram. I'll release it shortly.

Only doubt remaining from my side is:

When keys are hit at the exact same time, is it better to:

#1: Ignore and wait for valid input

#2: Return the keys in the order the routine discovers them and get it right some times

???
2013-08-03 10:10
chatGPZ

Registered: Dec 2001
Posts: 11100
please define "keys are hit at the exact same time" (in VICE this does _never_ happen, btw)
2013-08-03 11:30
TWW

Registered: Jul 2009
Posts: 541
Quote: please define "keys are hit at the exact same time" (in VICE this does _never_ happen, btw)

Within 1/60th of a second. I.E. One scan has no keys, next scan has two (or three) keys. (hence two (or three) new keys pressed since last time the keyboard scan matrix was read).

So from a programmer point of view, they where pressed at the same time not in sequence (and are thus impossible to determine which one the "typer" intended to hit first.

Before you ask: A sequence means keys pressed no faster than 1/60th of a second between each key press. Any faster then that, they will be detected as simultaneously.

You could do more rapid scanning but I suspect most of us has other things to do with that precious R-Time than scanning the keyboard 10 times each frame.
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
kbs/Pht/Lxt
Higgie/Kraze/Onslaught
Guests online: 77
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 The Ghost  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 It's More Fun to Com..  (9.9)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 Rainbow Connection  (9.5)
6 Wafer Demo  (9.5)
7 TRSAC, Gabber & Pebe..  (9.5)
8 Onscreen 5k  (9.5)
9 Dawnfall V1.1  (9.5)
10 Quadrants  (9.5)
Top Groups
1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Diskmag Editors
1 Jazzcat  (9.4)
2 Magic  (9.4)
3 hedning  (9.2)
4 Newscopy  (9.1)
5 Elwix  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.092 sec.