83Plus:Ports:01 - Revision history

NonstickAtom: More from the_mad_joob

2020-12-09T18:21:08Z

Fghsgh: more detailed information on delay

2020-03-09T03:07:43Z

more detailed information on delay

Fghsgh at 00:37, 4 March 2020

2020-03-04T00:37:09Z

Sorunome: /* Comments */

2016-09-11T20:47:00Z

‎Comments

Dr. D'nar: Oops.

2015-03-13T21:23:51Z

Oops.

Dr. D'nar: Replaced content with "A000 - Keyboard matrix Keyboard matrix == Synopsis == '''Port Number:''' A000 '''Function:''' Keyboar..."

2015-03-13T21:23:01Z

Replaced content with "A000 - Keyboard matrix Keyboard matrix == Synopsis == '''Port Number:''' A000 '''Function:''' Keyboar..."

Dr. D'nar: /* Example */ fix typo

2014-05-11T22:53:03Z

‎Example: fix typo

Dr. D'nar at 22:12, 11 May 2014

2014-05-11T22:12:46Z

Harold: /* Write Values */ active low.

2007-02-05T18:01:56Z

‎Write Values: active low.

Dan Englender: /* Comments */ but it's not

2006-08-26T14:32:16Z

‎Comments: but it's not

@@ Line 88: / Line 88: @@
 === Debouncing ===
-While a key is in a state between pressed and released, it will repeatedly turn on and off. If you are reading the keypad extremely quickly, it will appear as though the key is being pressed and released a number of times. You need to either wait longer between keypad scans, or you need to implement a proper debouncing algorithm. TI-OS does the first one by scanning the keypad in an interrupt that runs slowly enough for it to not have a noticeable effect.
+While a key is in a state between pressed and released, it will repeatedly turn on and off. Such behavior only occurs for keys that were just released. If you are reading the keypad extremely quickly, it will appear as though the key is being pressed and released a number of times. You need to either wait longer between keypad scans, or you need to implement a proper debouncing algorithm. TI-OS does the first one by scanning the keypad in an interrupt that runs slowly enough for it to not have a noticeable effect.
 == Example ==

@@ Line 82: / Line 82: @@
 in a,(1)</pre>
-The reason for this has since been discovered to not be caused by slow hardware, but rather by capacitance in the keypad. When unselecting a group, it takes a while before the charge has dissipated. Resetting the keypad every time after using it will make this discharge happen while you're doing something else, and activating a group happens instantly. The number of pressed keys and the number of groups being deactivated plays a role in the time the discharge takes, but generally, 7 clock cycles should be enough. However, this may vary from keypad to keypad.
+The reason for this has since been discovered to not be caused by slow hardware, but rather by capacitance in the keypad. When unselecting a group, it takes a while before the charge has dissipated. Resetting the keypad every time after using it will make this discharge happen while you're doing something else, and activating a group happens instantly. The more keys are pressed in the same keygroup, the faster the values are correct. The more keys are pressed in a different keygroup, but on the same bit, the longer you need to wait. A key that's pressed in a different keygroup on a different bit does not seem to influence the time required too much. Some combinations can take more than 50 clock cycles to deactivate, but for single keys being pressed, 8 clock cycles should be enough. However, this may vary from keypad to keypad.
 === Ghosting ===

@@ Line 54: / Line 54: @@
 * '''Note:''' Group FB Key FE is NEGATE, not to be confused with SUBTRACT.
-* '''Note:''' Group DF Key FE would be ON, but the ON key is tested elsewhere (a "special case" key - after all, it is the ON key).
+* '''Note:''' Group DF Key FE would be ON, but the ON key is tested through [[83Plus:Ports:04|Port 04]], bit 3.
 * '''Note:''' Group EF Key BF (APPS) is called MATRIX on the TI-83.
 == Comments ==
 You should disable interrupts or use a custom interrupt before manually reading this port, because TI's interrupt scans the keypad. If you leave TI's interrupt active when manually reading the keypad, sometimes it will fire between when you set and read the port, and you'll read garbage.
 Traditionally, a delay of a dozen or so clock cycles (6 MHz mode) is used between changing key groups and reading the result. The required delay seems to vary depending on the calculator; some require no delay, others a longer one. The delay is based on real time, not CPU clock cycles; you'll need to make your delay about 3 times longer in 15 MHz mode. However, as in the example, other people seem to find that resetting before every group change negates the need for a delay; some more experimentation is required.
@@ Line 78: / Line 81: @@
 ex (sp),hl
 in a,(1)</pre>
 == Example ==

@@ Line 59: / Line 59: @@
 == Comments ==
 TI's code always resets the keypad before scanning; sometimes, you may get incorrect values if you scan without resetting first.
 Traditionally, a delay of a dozen or so clock cycles (6 MHz mode) is used between changing key groups and reading the result. The required delay seems to vary depending on the calculator; some require no delay, others a longer one. The delay is based on real time, not CPU clock cycles; you'll need to make your delay about 3 times longer in 15 MHz mode. However, as in the example, other people seem to find that resetting before every group change negates the need for a delay; some more experimentation is required.
-You should disable interrupts or use a custom interrupt before manually reading this port, because TI's interrupt scans the keypad. If you leave TI's interrupt active when manually reading the keypad, sometimes it will fire between when you set and read the port, and you'll read garbage.
+For me (Sorunome) this didn't seem to work: Using the following code didn't always have the correct keygroup selected when scanning (on a TI-84+SE of a friend of mine):
 == Example ==

@@ Line 1: / Line 1: @@
-[[Category:84PCE:Ports:By_Address|A000 - Keyboard matrix]] [[Category:84PCE:Ports:By_Name|Keyboard matrix]]
+[[Category:83Plus:Ports:By_Address|01 - Keyboard]] [[Category:83Plus:Ports:By_Name|Keyboard]] [[Category:83:Ports:By_Address|01 - Keyboard]] [[Category:83:Ports:By_Name|Keyboard]]
 == Synopsis ==
-'''Port Number:''' A000
+'''Port Number:''' 01h
 '''Function:''' Keyboard Port
-The ports in this range are for accessing the keyboard
+This port reads key presses from the keypad. The keypad is divided into a series of groups.

@@ Line 1: / Line 1: @@
-[[Category:83Plus:Ports:By_Address|01 - Keyboard]] [[Category:83Plus:Ports:By_Name|Keyboard]] [[Category:83:Ports:By_Address|01 - Keyboard]] [[Category:83:Ports:By_Name|Keyboard]]
+[[Category:84PCE:Ports:By_Address|A000 - Keyboard matrix]] [[Category:84PCE:Ports:By_Name|Keyboard matrix]]
 == Synopsis ==
-'''Port Number:''' 01h
+'''Port Number:''' A000
 '''Function:''' Keyboard Port
-This port reads key presses from the keypad. The keypad is divided into a series of groups.
+The ports in this range are for accessing the keyboard
-−
-=== Read Values ===
-* Bits are set according whether corresponding keys from selected groups are pressed. Groups are selected through writing to the port. A pressed key reads a 0 bit. An unpressed key reads a 1 bit. The port reads FF after a reset (write FF).
-−
-=== Write Values ===
-* $FF : Reset the keypad. This unselects all groups and resets the keypad state.
-* Anything else : Any 0 bit adds the corresponding group to the list of monitored groups. When a key in a monitored group is pressed, the corresponding key bit reads 0, otherwise it reads 1 (active-low).
-−
-== Key Map ==
-The key map is laid out as follows:
-−
-{|
-−
-! Group Bit
-| 0 || 1 || 2 || 3 || 4 || 5 || 6 || 7
-|-
-−
-! Group Mask
-| FE || FD || FB || F7 || EF || DF || BF || 7F
-|-
-! Key Bit !! (Mask)
-|-
-! 0 !! (FE)
-| DOWN||ENTER|| (-) ||  .  ||  0  ||     ||GRAPH||     ||
-|-
-! 1 !! (FD)
-| LEFT||  +  ||  3  ||  2  ||  1  || STO ||TRACE||     ||
-|-
-! 2 !! (FB)
-|RIGHT||  -  ||  6  ||  5  ||  4  || LN  ||ZOOM ||     ||
-|-
-! 3 !! (F7)
-| UP  ||  *  ||  9  ||  8  ||  7  || LOG ||WIND ||     ||
-|-
-! 4 !! (EF)
-|     ||  /  ||  )  ||  (  ||  ,  || x<sup>2</sup> || Y=  ||     ||
-|-
-! 5 !! (DF)
-|     ||  ^  || TAN || COS || SIN ||x<sup>-1</sup> || 2nd ||     ||
-|-
-! 6 !! (BF)
-|     ||CLEAR||VARS ||PRGM ||APPS ||MATH ||MODE ||     ||
-|-
-! 7 !! (7F)
-|     ||     ||     ||STAT ||X,T,&#952;,''n''||ALPHA|| DEL ||     ||
-|}
-−
-* '''Note:''' Group FB Key FE is NEGATE, not to be confused with SUBTRACT.
-* '''Note:''' Group DF Key FE would be ON, but the ON key is tested elsewhere (a "special case" key - after all, it is the ON key).
-* '''Note:''' Group EF Key BF (APPS) is called MATRIX on the TI-83.
-−
-== Comments ==
-TI's code always resets the keypad before scanning; sometimes, you may get incorrect values if you scan without resetting first.
-−
-Traditionally, a delay of a dozen or so clock cycles (6 MHz mode) is used between changing key groups and reading the result. The required delay seems to vary depending on the calculator; some require no delay, others a longer one. The delay is based on real time, not CPU clock cycles; you'll need to make your delay about 3 times longer in 15 MHz mode. However, as in the example, other people seem to find that resetting before every group change negates the need for a delay; some more experimentation is required.
-−
-You should disable interrupts or use a custom interrupt before manually reading this port, because TI's interrupt scans the keypad. If you leave TI's interrupt active when manually reading the keypad, sometimes it will fire between when you set and read the port, and you'll read garbage.
-−
-== Example ==
- <nowiki>ld a, 0FFh ;Reset the keypad.
-out (1), a
-ld a, 0FEh ;Select group 0.
-out (1), a
-in a, (1) ;Test for keys.
-and 2 ;Test for Left Arrow key by making A 0 if left was pressed.
-call z, LeftArrowPressed ;If 0 then left was pressed.
-ld a, 0FFh ;Reset the keypad.
-out (1), a</nowiki>