83Plus:BCALLs:50E9

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.