TeleVideo Systems Part II - Keyboards

TeleVideo 965 Keyboard Emulation

The Terminal

TeleVideo 965 terminal with a PS/2 keyboard

I purchased a set of TeleVideo 965 terminals for a relatively good deal on eBay, hoping that I could make them work with existing TeleVideo keyboards I have.  I had some reason to suspect this - older terminals both used a 12V power supply to the keyboard and a TTL-level RS-232 connection between the keyboard and terminal logic.

Unfortunately, they weren't quite compatible, as I noticed the 965 has a 4-pin (handset-style) modular jack, and the slightly earlier 970 terminal I have has a 6-pin (RJ14 type) modular cable.

Older Terminal keyboards

TeleVideo 970 keyboard, missing F1 and CHAR INSERT

TeleVideo's original detached-keyboard terminals, the 925 and 950, both use a 4-pin modular jack. Going through the 925 schematics available on Bitsavers, it's apparent what the pinout is, and the supply voltage. The maintenance manual also lists the baud rate of 1200 baud for this keyboard.

The later model 970 keyboard added pins for a shield (likely to appease the FCC) and -RESET line to the terminal (the same keyboard was used on the TS-803 computer, and possibly others). Looking through the 970 technical manual on Bitsavers, you can see that the supply is 12V, like the earlier keyboard.  However, the baud rate is increased to 9600 baud, as I was able to verify with an oscilloscope.

Keyboard protocol analysis

I figured the best place to start was to decode what data the 970 keyboard was sending to the terminal.

TeleVideo 970 keyboard data capture on a 'scope

Hooking an oscilloscope to the keyboard pins, using a couple of spare modular jacks to connect pins through, I was able to verify the voltage of the connection, and the data coming out of the keyboard was 2 bytes of TTL level serial, at 9600 baud, 8/N/1.  I then connected the output of the keyboard up to a Linux PC using a generic TTL serial adapter.  From there, I was able to write a small program to log key presses and let me input what I was pressing, and dump the output into a CSV file for filtering through.

Keyboard decoding hardware setup

I discovered that the basic protocol is a byte to indicate the status of shift/modifier keys, such as shift, caps lock ("alpha lock"), control, and function, along with a second byte to indicate the key pressed, which was mostly the ASCII version of the key pressed.  This made the keyboard fairly simple to understand.  All I had to do is see how the modifier keys modified this second byte, and what all of the special function keys on the keyboard did.

At this point, I hoped that the terminal didn't have to send any data to the keyboard to initialize it.

Keyboard interface analysis

I assumed that the 965 keyboard interface would be similar to the older 970 interface, and used a multimeter to test the pins coming out of the terminal.  I quickly discovered that the terminal ran off of 5V instead of 12V, and was hoping that the baud rate was still 9600 baud.   

Keyboard simulator using "echo"

My first test was to use my Linux box to simulate a keyboard and send two-byte sequences to the terminal.  This worked perfectly, and I was able to get things I typed to show up on the terminal screen after looping back the primary serial port Tx/Rx pins.

Testing with an adapter

Keyboard with modular jack adapter

I grabbed a couple of surplus modular jacks I had laying around, connected wires between them, and attempted to run this, with just by-passing the 7805 voltage regulator on the keyboard.  This didn't quite work, as the voltage regular drew too much power, so I instead found a spare 12V DC wall-wart power supply to connect to my modular jack setup to power the keyboard.

To my surprise, this worked pretty much perfectly! So my earlier effort reverse-engineering the 970 keyboard protocol gave me exactly what I needed to replace the 965 keyboards.  I used the TTL serial adapter to record the commands that the terminal sent to the keyboard, and slowly figured out what some of them were -- reset, set/disable key repeat, etc.

Arduino PS2Keyboard library

My first thought at an adapter was to finally one of the Arduino boards that I had picked up at a Pi-day sale at Sparkfun.  With minimal searching, I found the PS2Keyboard library that was available for Arduino and worked on getting it to work with a PS/2 keyboard (I was using an IBM Model M since I had several of them laying around). After some work, I was able to get the example code to work.

My initial tests didn't work out, because I had messed up the pin-out on the PS/2 jack, and swapped +5V and the clock signal around, which gave strange results from the keyboard and attached oscilloscope confirmed there was a problem.  Fortunately, PS/2 interfaces are pretty hardy, and I didn't manage to break things.  If I had reversed data pins and the 12V power line to the TeleVideo keyboard, I'm sure it wouldn't have worked out well.

Re-writing PS2Keyboard

After digging into what the library would do by itself, I quickly discovered what its limitations were.  There were a few things that I wanted to do with my adapter, such as support the non-alphanumeric keys on the keyboard and modifier keys, which were not really supported with the Arduino library.  So, I decided to scrap most of what the library included, and just focus on reusing the library parts that directly interacted with receiving data from the keyboard and turning the bit stream into PS2 scan codes.  From there, I could use some translation tables to convert that data into the TeleVideo keyboard protocol modifier bytes.

In researching this, I spent lots of time reading every reference I could find on the PS/2 keyboard protocol. The MCS electronics app note on interfacing to an AT keyboard was useful, along with this article on the PS/2 keyboard protocol, along with another article from the same author. I used a few different references on keyboard scan codes including this osdev wiki page and this other list. And a few more general references, including the IBM PS/2 Hardware Interface Technical Reference manual.

I decided on some translations to do for keys that differed between the two.  PS/2 keyboards don't have a "SET-UP" or "SEND" key, but both of those are important keys to support on the TeleVideo terminal. I was able to get this mostly working, which was fairly easy to debug by moving the RS-232 output on the Arduino between my Linux box and a terminal.

After getting this all mostly working, I was able to add in support to send commands back to the keyboard, mostly so that I could control the LED keyboard lights and make the interface a bit more user-friendly.

Schematics and Code

The connections to the Arduino were fairly simple, just wiring up to RS-232 from the terminal, and connecting power, ground, clock and data to the PS/2 connector.

Schematic of keyboard converter 

I have uploaded the code to Github here.

The future!

I have re-created the device using an Arduino Pro Mini, so that it can fit into a small enclosure and be a small adapter. I'd like to extend it to support other keyboard interfaces which are RS-232 compatible, like the earlier TeleVideo terminals, and DEC LK-201/401 keyboards.

Compiling SIMH emulators for Android

In order to make this process easier on my phone, I used a rooted firmware. It will take some more effort to get this to work as a packaged application.

Setting up the development environment.

To get started, you'll need a working native C compiler for Android. After a lot of trial and error, I ended up discovering what I had to do. I used an amd64 architecture version of Debian GNU/Linux, Ubuntu works the same way. Using a Linux host to compile the code if not essential will make your life a lot easier. Follow the official instructions to download the source to Android using git, and then build it.

Along with doing that, I tested this on the Android emulator, which is a part of what you just downloaded and built, under out/host/linux-x86/bin. Put that directory in your path, and run the "android" command, create a virtual platform, and boot it. From the command line, if you built a virtual device named "Android21", for example, you'll want to run "emulator -avd Android21 -shell" so that you can get a shell on the virtual device. To copy files over to the image, the easiest method that I've found is to shut down the emulator, mount the virtual sdcard image (for these examples, I'm using "Android21" as the virtual device name):

$ sudo mount -o loop ~/.android/avd/Android21.avd/sdcard.img /mnt

$ sudo cp whatever /mnt

$ sudo umount /mnt

In addition, you will want the "agcc" script to make it easier to compile things. Download it from here. I modified my copy to use gcc-4.4.0 instead of gcc-4.2.1. You will need to add the location of arm-eabi-gcc to your path, and change all references of "4.2.1" in the agcc script to "4.4.0" and add that to your path. arm-eabi-gcc can be found under the prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin path of where you built the android sources.

Fixing the Android SDK and SIMH makefile

The current version of the Android libc (bionic) headers has a problem compiling when bionic/libc/kernel/arch-arm/asm/byteorder.h is included. In order to make the file compile, comment out these lines, lines 22-27 in my copy:

/*#ifndef __thumb__

* if (!__builtin_constant_p(x)) {

*

* asm ("eor\t%0, %1, %1, ror #16" : "=r" (t) : "r" (x));

* } else

*#endif */

Once you do that, you will need to need to download the SIMH sources. Unpack them, and modify the the makefile in the top directory, to make the following changes:

On line 12, remove -lrt from OS_CCDEFS, so that it reads:

OS_CCDEFS = -lm -D_GNU_SOURCE

Change all references of "gcc" to "agcc".

Only some of the simulators actually compile, and I haven't tried to compile network support for any of it. In order to get network support, you would need to compile libpcap as well. For now, that is left as an exercise for the reader. :)

After those changes, I just did make vax vax780 to build the MicroVAX 3900 and VAX-11/780 simulators, which can be copied over to your phone or emulator. You will probably get a bunch of warnings about the use of variable-size enums versus 32-bit enums. They seem to be harmless, and I'm pretty sure that you can ignore those warnings.

If you're too lazy to compile it

If you don't feel like spending the time to set up a development environment, and compile SIMH by yourself, I have a pre-compiled version for Android available. I used SIMH v3.8-1, which is the newest release as of this posting. You can get a pre-compiled copy of the Android emulator to test on from the pre-compiled Android SDK. After you download and unpack that, you will need to put the tools directory inside the sdk into your path.

Preparing your phone and copying things over

You will need a rooted phone to make this work easily. Rooting your phone is left as an exercise for the reader. Once you have root permissions, you will need to USB debugging on your phone. On my Evo, it's under Settings -> Applications -> Development -> USB debugging.

You will need an application that will work as a terminal emulator on your phone. You can use "adb shell" from the Android SDK, which will give you a shell from your phone on your computer. To run completely hosted from the phone, use something like ConnectBot.

From this point you can copy files necessary for the emulator to your phone. I copied the necessary files all to my phone's SD card:

$ adb shell mkdir /sdcard/simh

$ adb push BIN/vax /sdcard/simh

$ adb push VAX/ka655x.bin /sdcard/simh

...

Now, use adb shell to do a few things on the phone itself. Pay attention to what your phone is saying, as the first time you try to "su" on your phone, it may pop up a dialog asking if this is ok. Whether or not you see that will depend on exactly how you rooted your phone. If "adb shell" gives you a "#" prompt straight away, you don't need to use su, as you're already root.

$ adb shell

$ su -

# mkdir /data/simh

# cat /sdcard/simh/vax

# chmod 755 /sdcard/simh/vax

It is necessary to put any executables on the internal storage (eg in /data/simh like I did), because you cannot directly execute binaries from the sdcard, at least in Android 2.1.

Running a SIMH emulator

Once you've done that, as root on the phone, do something like:

# cd /sdcard/simh

# /data/simh/vax

And then just use SIMH as you normally would.

Connectbot allows for multiple simultaneous sessions, so you could do "set console telnet=2300" inside the emulator, and then open another telnet session in connectbot to 127.0.0.1:2300 to connect to a separate console. Connectbot simulates "screen" as a terminal emulator, which seems to do an adequate VT100 emulation for most things. The most I've tested it so far it running /usr/games/worms from 4.3BSD, after "setenv TERM vt100". If you have your device on a WiFi network, you could even use another machine to telnet into SIMH and be the console, or another emulated serial terminal on the system.

That's it! If you don't know what to do from here, take a look around the SIMH site, you can run things like ancient versions of UNIX, OpenVMS through HP's hobbyist program, NetBSD, or play with the other emulators and other OSes. Where you go from here is up to you.

EDIT Aug 8, 2010:

I forgot to add the pictures that I have taken of this. Check them out on flickr. I also now added the picture to the top.

Back again

After a bit of a hiatus from posts, I'm back again.

I've finished a big hurdle in the start of downsizing and creating focus in my computer and interesting technology collection, and after finally buying a house, I have completely finished moving out of a ~2500 sq ft warehouse that I was using to store my collection. At its peak, it was stacked high with equipment, and paths to navigate through the space were sometimes non-existent.

I have since resolved to limit the size of my collection, and thus the number of projects that I want to do. As a direct result of my massive work in downsizing (with critical help from friends for some larger items and a push to finish up towards the end of July - but otherwise mostly done by myself over the January through July of 2010), I now have time to work on projects instead of just spending all of my time moving things back and forth.

I replaced my old iPhone 1.0 with an HTC Evo, running Android, back in June when they came out, and have been exceedingly happy with it. As a direct result of how easy it is to hack and develop on, I have started some projects involving running computer simulators on it. Currently, I have the set of VAX emulators (VAXstation 3900 and VAX-11/780) from Bob Supnik's Simh emulator collection running both 4.3BSD and OpenVMS, with a minimal amount of work.

I have posted pictures of 4.3BSD running both on the Android emulator, and my phone on my Flickr account.

My next post will describe what I had to do to get Simh to compile and run on my phone, and after playing with that, my next target is the Hercules IBM Mainframe emulator.