Difference between revisions of "83Plus:BCALLs:50E9"
From WikiTI
m (wrong OS version) |
(This is about the TI-Keyboard, folks) |
||
| Line 1: | Line 1: | ||
| − | [[Category:83Plus:BCALLs:By Name| | + | [[Category:83Plus:BCALLs:By Name:Input|KeyboardGetKey]] [[Category:83Plus:BCALLs:By Name|KeyboardGetKey]] [[Category:83Plus:BCALLs:By Address|50E9 - KeyboardGetKey]] |
| − | [[Category:83Plus:BCALLs:By Address|50E9 - | + | |
== Synopsis == | == Synopsis == | ||
| − | '''Unofficial Name:''' | + | '''Unofficial Name:''' KeyboardGetKey |
'''BCALL Address:''' 50E9 | '''BCALL Address:''' 50E9 | ||
| − | + | '''Minimum OS Version:''' 1.15 | |
| + | |||
| + | Attempt to receive a keypress from the TI-Keyboard. | ||
=== Inputs === | === Inputs === | ||
| Line 13: | Line 14: | ||
=== Outputs === | === Outputs === | ||
* A contains status code | * A contains status code | ||
| + | * The actual data retrieved from the keyboard appears to be trashed in the process of popping the error handler ?! | ||
=== Destroys === | === Destroys === | ||
| − | * | + | * AF, BC, DE, HL |
== Comments == | == Comments == | ||
| − | + | This B_CALL was introduced in OS 1.15. Programs should check the OS version before attempting to use this routine. | |
| − | * 00 = link | + | |
| − | * 01 = | + | Keep in mind that the keyboard communicates using a truly horrible perversion of the DBUS protocol, which works as follows: |
| − | * 02 = byte | + | * The keyboard sends the byte E0. |
| − | * 0F9h = | + | * It pulls both link lines low simultaneously for a short time (i.e., flags a DBUS error.) |
| − | * 0FAh = | + | * It sends the byte 01h. |
| − | * 0FBh = byte | + | * Finally, it sends the scancode or modifier mask. |
| − | * 0FEh = byte | + | As a result, there are a variety of possible error conditions. |
| − | * 0FFh = | + | |
| + | Possible status codes returned are: | ||
| + | * 00 = No link activity detected. | ||
| + | * 01 = Success. | ||
| + | * 02 = Link activity detected, but the first byte was not E0h, or E0h was not followed by a DBUS error. | ||
| + | * 0F9h = Link assist error, and no buffered data or link activity. | ||
| + | * 0FAh = Link assist error and buffered data detected, but the buffered byte was not E0h. | ||
| + | * 0FBh = Link assist error and buffered byte E0h detected, and two more bytes might or might not have been read. | ||
| + | * 0FEh = Second byte was not 01h (possibly unsupported future commands) | ||
| + | * 0FFh = Protocol error other than the one expected. | ||
== Links == | == Links == | ||
A full disassembly of this entry point on OS 2.41 is [http://www.brandonw.net/calcstuff/50E9.txt here]. | A full disassembly of this entry point on OS 2.41 is [http://www.brandonw.net/calcstuff/50E9.txt here]. | ||
Revision as of 14:03, 6 November 2006
Synopsis
Unofficial Name: KeyboardGetKey
BCALL Address: 50E9
Minimum OS Version: 1.15
Attempt to receive a keypress from the TI-Keyboard.
Inputs
- None
Outputs
- A contains status code
- The actual data retrieved from the keyboard appears to be trashed in the process of popping the error handler ?!
Destroys
- AF, BC, DE, HL
Comments
This B_CALL was introduced in OS 1.15. Programs should check the OS version before attempting to use this routine.
Keep in mind that the keyboard communicates using a truly horrible perversion of the DBUS protocol, which works as follows:
- The keyboard sends the byte E0.
- It pulls both link lines low simultaneously for a short time (i.e., flags a DBUS error.)
- It sends the byte 01h.
- Finally, it sends the scancode or modifier mask.
As a result, there are a variety of possible error conditions.
Possible status codes returned are:
- 00 = No link activity detected.
- 01 = Success.
- 02 = Link activity detected, but the first byte was not E0h, or E0h was not followed by a DBUS error.
- 0F9h = Link assist error, and no buffered data or link activity.
- 0FAh = Link assist error and buffered data detected, but the buffered byte was not E0h.
- 0FBh = Link assist error and buffered byte E0h detected, and two more bytes might or might not have been read.
- 0FEh = Second byte was not 01h (possibly unsupported future commands)
- 0FFh = Protocol error other than the one expected.
Links
A full disassembly of this entry point on OS 2.41 is here.
