This circuit adds to the previous one a module called key_decoder which is a state machine that attempts to translate the raw incoming byte sequences for the keypress and key-release events into single-byte representations of these events using an ASCII-based encoding. The high-order bit of the output byte is turned on if the key is being released; otherwise it is off indicating a key press. The output ASCII characters were generally chosen to correspond to the key being pressed; e.g. the letters A-Z represent the keys labeled as such, SP represents spacebar, CR the Enter key, etc. For keys with more than one symbol printed on them, the usual upper symbol is chosen; e.g. "!" represents the key that has "! 1" printed on it. For special keys without normal ASCII representations such Shift, Alt, Ctrl, and the various function keys, I have chosen fairly arbitrary ASCII representations for them. These are detailed in the Notes mentioned below.

Unfortunately, the present decoder circuit is not very reliable, and often outputs the wrong character. It needs to be made substantially more reliable before it could reasonably be used as the basis for further keyboard-based applications. Also, be aware that it still operates at the level of keypress/key-release events, not typed characters; e.g., hitting shift+4 on the keyboard in an attempt to generate the "$" character will instead generate a sequence of 4 bytes representing the four events (press shift key)(press $/4 key)(release $/4 key)(release shift key). A further state machine would be needed to translate these event sequences into the character the user actually intends to type.

Version 5.1 improves the reliability somewhat, but there still are frequent problems.

Version 6 solves the reliability problem completely - the key decoder works perfectly now (except that when Num Lock is turned on, some undocumented sequences are sent for the Home, Insert, etc. keys). The problem with the earlier versions was just that the setup time constraint for writing the output to RAM wasn't met. The present version makes sure that its output is valid significantly prior to the rising edge that it uses to signal that the output is ready.

Version 6.1 (archive filename VGA_char_RAM2_v61.zip) adds a falling-edge-triggered "delayed_pulse_fe" element clocking the RAM address counter. This avoids races between the actual write to RAM and the incrementing of the counter.

Version 6.2 (archive filename VGA_char_RAM2_v6r2.zip) vastly simplifies the key decoder design (new entity version key_decoder_v2) and in a way that allows it to handle certain key combinations (e.g. NumLock+Home, Shift+PrntScrn) that were not properly handled previously. As an added benefit, the Pause/Break key now generates a make+break sequence rather than just a make code, so applications don't have to treat it specially. The new design is documented in the "Simplified Key Decoder.doc" Word document. It seems to work perfectly based on testing done to date.

This (incomplete, but working) example is intended to become a complete text-entry demonstration. So far it just displays my raw ASCII keycodes for the keys pressed. 

Version 2 initializes the character RAM properly upon startup, highlights the current cursor position using inverse video, and uses a modified version of the keycode-to-ASCII map, which permits the expected character to be displayed in more cases - in particular, now working correctly are the unshifted keys that normally generate backquote (`), square brackets ([ ]), backslash (\), semicolon (;), apostrophe ('), comma (,), equals (=), and keypad plus (+).  The function keys also now all generate control characters, although that mapping is highly arbitrary.  But you can now type pretty much any ASCII sequence that you want, excluding most lowercase letters, as well as colon (:), less than (<), quotation marks ("), tilde (~), vertical bar (|), and the EM (end-of-medium), SUB (substitute), and RS (record separator) control characters. 

For more complete coverage of the ASCII character set in the output, later versions are intended to handle the SHIFT and CAPS LOCK keys properly, and to generate arbitrary ASCII control characters by toggling bit 6 of the output character if the control key is depressed.  Also, we will eventually do something sensible in terms of text formatting with keys such as Enter, Tab, Backspace, Insert, Delete, Home, End, Page Up, Page Down, Keypad Enter, and the arrow keys.