[CSDb] - User Forums - looking for rom independent keyboard read routine

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.

... 30 posts hidden. Click here to view all posts....

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: 11114

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.

Previous - 1 | 2 | 3 | 4 - Next

Refresh

Subscribe to this thread: