Add I2C offset to get the keyboard init state

[stefan-b-jakobsson]

This PR makes it possible to get the state of the keyboard, that is if the keyboard has been initialized.

Example: PRINT I2CPEEK($42,$1B) returns 4 if the keyboard is ready.

The changes take 14 bytes.

[stople]

Note that this "kind of" locks the API in regards to this enum, and, may make it difficult to change the behavior later, for backward compatibility. But, if we think these are generic enough init states, I guess it is fine.

To think out alternatives, while we can. Should "0" mean "OK"? And 1-127 mean "init in progress", and 128-254 "errorcode"? "255" should probably not be used, as this is the return value for current versions.

[stople]

Is there some kind of established "standards" regarding keyboard init states/state numbers? Or, we just invent our own?

[stople]

And, this is keyboard only? Mouse is irrelevant here? Mouse have its own similar init state?

[stefan-b-jakobsson]

The keyboard init state is not a standard in any way.

We could absolutely change KBD_READY to 0 or 1, and reserve the remaining values for other states, as you suggest.

An alternative is to do this in the I2C send command:

smcWire.write(getKeyboardState() == KBD_STATE_READY);

Then it takes 22 bytes.

I realize I couldn't do it better in assembly:

  ; ... code reading kbd_state into for instance r16
  ldi r17, 0
  cpi r16, 0x04
  brne send
  ldi r17, 1
send:
  ... continue sending r17 value

[stople]

Maybe I just overcomplicate stuff. If we think these states cover our needs for now, we can use them as is. We can add new ones later, and even error codes as negative values if we like (2s compliment). If we cannot build upon the current implementation for whatever reason (e.g. we have to insert a new state between current state 2 and 3), we can simply call it "5" and give it a good enum name. Or, we can scrap this i2c offset and take a new one (return 255 means too old, 254 can mean "this is deprecated" or something.)

[stefan-b-jakobsson]

I made the following changes:

• READY state is now 0x01
• OFF state is still 0x00
• The other intermediate states begin from 0x02
• There's a promise in the README file that return value 0x01 means that the keyboard is ready. Other values mean that it is not, but the exact interpretation of other values are subject to change.

If we do it like this, the size of the feature is only 10 bytes.

[stefan-b-jakobsson]

The last code produces an unexpected result if no keyboard is attached, when reading the state in AUTOBOOT.X16.

• After power on, the state is 0x02, which is OK
• After pressing the reset button, it's 0x11, which is not a valid value. I haven't had time to check where that's coming from.

EDIT: Forget that, 0x11 is a valid state, KBD_STATE_RESET_ACK