Chip-8 on the COSMAC VIP: Keyboard Input

This is part of a series of posts analysing the Chip-8 interpreter on the RCA COSMAC VIP computer. These posts may be useful if you are building a Chip-8 interpreter on another platform or if you have an interest in the operation of the COSMAC VIP. For other posts in the series refer to the index or instruction index.

INSTRUCTION GROUP: EX9E
Skip if VX = current key press.

INSTRUCTION GROUP: EXA1
Skip if VX ≠ current key press.

INSTRUCTION GROUP: FX0A
Wait for a keypress and store the value in VX.

The COSMAC VIP is equipped with a hexadecimal keypad with the following layout:

Chip-8 provides three instructions for responding to input from this keyboard. EX9E and EXA1 are intended for situations in which the keyboard must be read without interrupting the main programme flow, real-time games for example. I analysed these instructions in an earlier post on skip instructions.

The final instruction, FX0A, is intended for situations in which you want to wait for a key press – turn-based games for example. This instruction is part of the FXXX instruction group, so it is subject to an additional stage of decoding. I explain this in an earlier post.

The keyboard on the COSMAC VIP is interfaced to the CPU via a CD4515 latched, four-to-sixteen-line decoder. An OUT 2 instruction will deposit a key code on the data bus and the four least significant bits of this will be latched into the decoder. The 4515 will decode this 4-bit value and pull the corresponding output line low. Each of these lines is connected to the external flag line EF3 via one of the keys on the keyboard. If the key is pressed, completing the connection, then EF3 will also be brought low. The output lines are mapped as you would expect, with 0 through 9 representing keys 0 through 9 and 10 through 15 representing keys A through F. This is shown in the simplified logic diagram below.

To scan for a key press, it is therefore necessary to cycle repeatedly through the key codes testing each one until a key press is detected. Because the 4515 is only connected to the four least significant bits of the data bus, it is not necessary to mask the four most significant bits of the value placed on the data bus. Instead a full 8-bit value can be used and decremented or incremented after each test. The 4515 will read one cycle of an 8-bit value as 16 cycles of a four bit value.

Because the mechanical key switches are wired directly to the EF3 line, the VIP’s keyboard will exhibit a problem known as bouncing. As the key is pressed then released you rarely get a perfect on and then off connection. Instead, as the contacts in the switch are being moved together or pulled apart a connection may be made and broken several times over a few milliseconds until it settles into its final on or off state. This can lead to spurious readings or noise on the EF3 line. This is combatted by including a short delay after reading the key before checking for its release.

The code for this function in the interpreter is quite simple, because it uses a routine in the ROM to do most of the work. It simply calls the keyboard reading function in the ROM. This returns the value of the pressed key in the accumulator and this is then stored in VX. Here’s the code:

The ROM routine does the hard work of actually reading the key. The flowchart shows how this works:

Something to note about this code is that because the sound timer is used to effect debounce delays, this has the useful side effect of sounding a tone while the key is held down. One peculiarity about this code is that two different techniques are used to check whether the sound timer has reached zero. One is to check that the sound time has actually reached zero. The other is to check whether Q is set (as it will be reset once the sound timer has reached zero). It’s odd that both techniques are used in the same routine. In fact the ROM’s author seems to have changed his mind while he was writing the code but then not got around to tidying up his work, because in the sequence in which Q is checked there is a redundant instruction to get the sound timer value into the accumulator.

Execution time for this instruction obviously depends on how quickly the user responds, but theoretical minimum execution times are given below:

The small overhead for the second stage decoding of type FXXX instructions must be added to these figures. In reality execution times will naturally be much longer than this because nobody could physically press and release a key that quickly. Even without taking the human delay into account, these execution times are much longer than most other instructions. This is because each time this instruction is used at least 8 full frames must elapse before the routine can return because of the debounce delays.

The programmer of a contemporary interpreter should implement this instruction. They are though, likely to have an easier time of things because most modern keyboards have a hardware debounce, so there is no need to attend to this in software. Of course an added complication is that the keys 0 to 9 and A to F on a full keyboard are not placed in an optimal position for games, so you will almost certainly want to provide a means of mapping these to other keys.