<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>
Date   : Wed, 31 Aug 1994 12:58:00 WET DST
From   : Bonfield James <jkb@...>
Subject: Re: Keyboard & T1 interaction

Chris Lam writes:

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

>there are two crucial routines for the keyboard. first is OSBYTE 121 & 122(?)
>(i think which scan the keyboard). there's some really horrible horrible
>code to check which column (of the keyboard matrix) is high and then which
>row is high. the intersecting point is the key pressed (look at the diagram
>in back of AUG). somehow you must emulate all this.

I've done all of this. I've been monitoring my debugging output and fixing
bugs here for some time now. It appears to be all working fine. It even seems
to have the keyboard interrupts enabled now (which was a bizarre sticking
point for some time).

The current situation is that BASIC does an OSWORD 0, which in turn does a
OSRDCH. OSRDCH loops around waiting for a key to appear in the 'input buffer'.
The interrupts are supposed to fill this for me. My problem appears to be that
the T1 interrupt doesn't recognise that the 6522 CA2 interrupt has spotted a
key. I'll add a disassembler (rather than an assembly execution tracer) to my
program too so that I'll be able to extensively hunt around and find which
condition isn't being met.

>second, is when you want to see if a certain key has been pressed. this will
>look like
>
>  LDX#int_code_of_key_to_check
>  STX &FE4F
>  LDX &FE4F
>  BMI yes_the_key_is_being_pressed
>
>i.e. the VIA will set bit7 of &FE4F.

I found a bit of code in the OS along the following lines:

f02a: A=06, X=06, Y=7f, S=fc, P=34 ; LDY #&03
f02c: A=06, X=06, Y=03, S=fc, P=34 ; STY &FE40
f02f: A=06, X=06, Y=03, S=fc, P=34 ; LDY #&7F
f031: A=06, X=06, Y=7f, S=fc, P=34 ; STY &FE43
f034: A=06, X=06, Y=7f, S=fc, P=34 ; STX &FE4F
f037: A=06, X=06, Y=7f, S=fc, P=34 ; LDX &FE4F
f03a: A=06, X=80, Y=7f, S=fc, P=b4 ; RTS
da15: A=06, X=80, Y=7f, S=fe, P=b4 ; CPX #&80

This doesn't seem to act quite right, and I had to change my code to fudge
this. This was actually produced when I hard wired one of the keyboard dip
switches to be set, for experimentation purposes.

It was the LDX &FE4F resulting in &80 (was &86) that was a bug for me for some
time. That's now fixed (luckily). It's due to action of reading from ORA when
DDRA has bits set to output. The required action depends on whether or not
input latching is enabled.

>;I simply can't believe how long it's taking me to get this keyboard IO
>;working.
>
>yes, frankly it's tougher than the CRTC and ULA. it's so poorly documented.

That's my opinion too. Much of my information so far has been gleaned from
examining the OS and working out what values are expected.

       James
<< Previous Message Main Index Next Message >>
<< Previous Message in Thread This Month Next Message in Thread >>