Uzebox Keyboard Interface: Difference between revisions

From Uzebox Wiki
Jump to navigation Jump to search
mNo edit summary
Line 18: Line 18:
* P2 Data  -> Data In from Keyboard
* P2 Data  -> Data In from Keyboard


Since the latch and clock lines are shared with the P1 port, they are constantly being toggled when reading P1 buttons. A special state is required to tell to the firmware that the following clocks pulse are to read keyboard key(s):
Since the latch and clock lines are shared with the P1 port, they are constantly being toggled when reading P1 buttons. A special state is required to begin a "transaction" (one or more consecutive transfers) with the keyboard:
* The Clock line is held low and Latch line high simultaneously for at least 1uS.  
* The Clock line is held low and Latch line high simultaneously for at least 1uS.  
* Then Clock is set high and Latch low and a 1us delay is observed.
* Then Clock is set high and Latch low and a 1us delay is observed.
Then a SPI-like transfer can begin by clocking out a command byte on the Latch/Data Out line while reading the next available character on the P2 data line. If not characters are available, a zero is received.  
Then a SPI-like transfer(s) can begin by clocking out a command byte on the Latch/Data Out line while reading the next available character on the P2 data line. If no characters are available, a value of zero is received. When done transferring data, you must send a command to close the transaction.


Commands can be sent to the firmware to perform certain actions or return other data than pressed keys. Currently only two command is supported:
Commands can be sent to the firmware to perform certain actions or return other data than pressed keys. Currently only two command are supported:
* KB_SEND_KEY (0x00): Indicate that the host intends to read another key.
* KB_SEND_KEY (0x00): Indicate that the host intends to read another key.
* KB_SEND_END (0x01): Indicates that this is the last character to be returned. This command should always be sent when done to perform cleanup and close the ATtiny SPI port. Otherwise the firmware will get confused when the next P1 polling happens.
* KB_SEND_END (0x01): Indicates that this is the last character to be returned in this transaction. This command should always be sent when done to perform cleanup and close the ATtiny SPI port. Otherwise the firmware will get confused when the next P1 polling happens.


The data received are PS/2 scan codes as returned by the keyboard without any transformation. This include key codes (key down) and break codes (key up).
The data received are PS/2 scan codes as returned by the keyboard without any transformation. This include key codes (key down) and break codes (key up).
The Attiny has an internal key buffer so the host can read fewer bytes per transaction than are actually available.


===Download===
===Download===

Revision as of 01:47, 3 January 2016

Uzebox Keyboard Interface embedded in a PS/2 keyboard
Interface embedded in SNES plug

The Uzebox Keyboard interface allows any PS/2 keyboard to be connected to the Uzebox via the Player 2 SNES port. The interface is made of single ATtiny25 with no other external components. With the use of SNES controller cord, the interface is so small that it can be easily embedded into a SNES plug or the keyboard itself.

Hardware Interface

The following image contains the circuit's schematic:

Uzekb schematic.gif

The only component required is an Atmel ATtiny25/45/85. Depending on the type of interface you want to make you will need a SNES controller for the cord and/or plug and optionally a PS/2 adapter.

The source Eagle file and PDF format can be downloaded in the Download Section.

Firmware

Protocol

The interface is connected to SNES P2 port and uses a protocol similar to SPI. The following pins are used:

  • Latch -> Data Out to keyboard
  • Clock -> Clock
  • P2 Data -> Data In from Keyboard

Since the latch and clock lines are shared with the P1 port, they are constantly being toggled when reading P1 buttons. A special state is required to begin a "transaction" (one or more consecutive transfers) with the keyboard:

  • The Clock line is held low and Latch line high simultaneously for at least 1uS.
  • Then Clock is set high and Latch low and a 1us delay is observed.

Then a SPI-like transfer(s) can begin by clocking out a command byte on the Latch/Data Out line while reading the next available character on the P2 data line. If no characters are available, a value of zero is received. When done transferring data, you must send a command to close the transaction.

Commands can be sent to the firmware to perform certain actions or return other data than pressed keys. Currently only two command are supported:

  • KB_SEND_KEY (0x00): Indicate that the host intends to read another key.
  • KB_SEND_END (0x01): Indicates that this is the last character to be returned in this transaction. This command should always be sent when done to perform cleanup and close the ATtiny SPI port. Otherwise the firmware will get confused when the next P1 polling happens.

The data received are PS/2 scan codes as returned by the keyboard without any transformation. This include key codes (key down) and break codes (key up).

The Attiny has an internal key buffer so the host can read fewer bytes per transaction than are actually available.

Download

Current version: 1.0

The firmware sources required for the ATtiny are available here: KeyboardFirmware V1.0

Precompiled HEX for ATtiny25/45/85: KeyboardFirmware-v1.hex

Test ROM

Demo ROM to test the keyboard. Requires Uzem v1.20 for emulation. [1]

Assembly Tutorial

TBD

Emulator support

Uzem automatically detects when the game uses the keyboard protocol and captures the PC keyboard input for it. P2 port is always used for the Uzebox keyboard. Naturally that means you can't also use the keyboard as a joystick at the same time. But you can use a regular pc jopystick/joypad for P1.