It gets a bit more interesting. POC V1 uses a WYSE 60 dumb terminal for the console, driven by TIA-232. The WYSE 60 went out of production a number of years ago and the supply of new ones has dried up. There are remanufactured units and software-compatible replacements still available, but their future is uncertain, given that the general computing spectrum has moved away from host-based systems employing serial terminals (terminals, when used, are generally thin clients that are really disk-less PCs). This has made me decide that perhaps I should consider designing an integrate console into POC V2.

Obviously, the console needs video and a keyboard. Sounds (e.g., squawks and beeps) are optional, but are handy to get the user's attention when needed. I can worry about sound later. Actually, the video part isn't too tough to implement. In another topic, there is discussion about the Picasso serial-to-VGA adapter, a device that is driven by bi-directional, TTL-level TIA-232 and produces text and/or graphics on a standard VGA video monitor. This device could be made to be the video part of POC V2's console by direct-connecting it to channel-A of the DUART. The DUART's channel-B would continue in its role as a high speed serial I/O connection to the outside world. The circuitry is very simple: RxD, TxD, Vcc, ground and an active-low reset. No line drivers are needed.

The keyboard part is a little more interesting. PC keyboards are ubiquitous and cheap, so that can be considered to be the weapon of choice. The keyboard's PS/2 interface is a serial synchronous setup, which requires bit-banging to read in data (or command the keyboard to do something), along with a decoding algorithm to turn keystrokes into ASCII codes. It's possible to do this through a 65C21 or 65C22, but that's a bit of work to properly code and also burdens the MPU with with the decoding work.

Considering all that, I decided to adapt Daryl Rictor's PS/2 keyboard interface to POC V2. Daryl's design uses an Atmel microcontroller (AVR) to handle the keyboard stuff and offload all keyboard processing from the MPU. The interface looks like an I/O device with an 8-bit data port and a two wire handshake, which presents no special problems in adaptation. Again, the circuitry is simple and due the manner in which the AVR does its work, interrupts can be used to read in and buffer keystrokes for later use by the foreground application. A separate interrupt-drive piece of code can be used for sending commands to the keyboard (e.g., turning on the Num Lock feature).