Date   : Thu, 01 Sep 1994 13:12:16 +0000
From   : lamcw <lamcw@...>
Subject: Re: Keyboard & T1 interaction

Wrote Bonfield James:

;>i didn't think an interrupt was generated upon release of a key but it is an
;>interesting point. at the mo, i'm only doing an int when a key is pressed.

;Well, if it's working for you like this then obviously it's not required. It
;could also be the cause of things not working for me.

just because it works, it doesn't immediately follow it's correct.


;Now the 2 key at once thing seems curious. Assume we press A and B together.
;A == row 4, column 1,
;B == row 6, column 4

;Now we've pressed B first - that's OK.
;We then press A without releasing B. The column scan we detect B (it's in
;column 4 and we check in descening order) first. We then check 14, 24, 34 ...,
;and find again that 64 is set. But we've missed A completely! I can't see
;quite how this is supposed to work. It would appear that the OS then EORs this
;with &EC and notices that it's the same key detected twice. Presumably (I
;haven't checked this yet) it then scans further to find the real new key
;pressed.

;Also, when scanning 14, 24, 34 (etc), does the keyboard circuitry ONLY return
;when keycode 64 is held down. What about 44? Row 4 is set and so is column 4,
;but with different keys. I suspect it's the first of these two methods (ie
;only with 64) and hence we need to implement a single large array (16*8)
;rather than two small ones (a 16 and an 8).


an interesting point which made me think. the structure of the OSBYTE keybd
scan routine is roughly,


 LDX#9   ; located in &FE01 in OS 1.20; n.b. this is NOT an entry point

label400:

 <is column X active?>

 <if not goto label100>

 TXA

label300:
 STA &FE4F  <put into port B VIA>
 BIT &FE4F  <bit7 (N flag) set if key with code A is being pressed>
 BPL label200 <branch if not pressed >

 <yes, key with internal code A pressed. do some processing>

label200:
 CLC
 ADC#10
 BPL label300

label100:
 DEX
 BPL label400


(excuse my mix of assembly and C labels>

assume A and B keys pressed. column 4 is detected. now cycle thru rows.
try keycode &04 in &FE4F. is it pressed? no. okay try &14... and so on
until &64... bingo 'B' is being pressed. okay store this in a 3 byte ring
buffer (do various checks...). continue checking &74,&84,&94.

now we decrement X to check the columns again. col 1 is detected. so again
we cycle thru the rows and &01, &11, &21, &31, &41 whereupon 'A' is found.


the code for the OSBYTE routine is further complicated because there are 3
entry points. the carry flag set indicates an external OSBYTE call as oppose
to an 'internal' OS scan.

it occurred to me yesterday 'why bother to detect if column X is active? CHECK
EVERY COLUMN!!!!' i.e. check every single possible key (the code to check if 
a column is active is horrible)

once i'd done this fudge, my keyboard began working fine,
i could press SHIFT and CTRL with a second key. the keyboard is still just as
responsive and all the CTRL + key actions seem to work. but more importantly it
meant i could play CHUCKIE EGG.

purists out there will condemn me for this sinful fudge but it's a
simple solution to potentially messy problem.


chris lam,
aston univ.
u.k.