How to have fun with klunky old terminals

12/14/2010 9:40 AM EST

I worked for SITA at the time and so I knew Airline terminal systems back to front. I had a couple of friends in British Airways and one of them had mentioned that they renewed their terminals every 5 years or so. So I found a lot of old BA terminals that were going to be thrown out in BA’s offices in South Africa, and they were only too pleased to get a few dollars for them.

They were literally dumb terminals, and big and ugly and heavy with it, but they had a lot of life left in them, I could get full service manuals for them and parts were usually easy to find. So I left SITA, bought BA’s old terminals for a song, and offered the travel agents leased terminal systems (hence no heavy capital expenditure, which was a huge attraction). I demonstrated them to the travel agents one day at Air Zimbabwe’s offices at Harare Airport; British Airways coincidentally and helpfully flew Concorde into Harare for the day, which alone made sure that most of the travel agents came out and saw what I had to offer.

The terminals were Z-80 based and connected to a “Cluster Control Unit” or CCU, also Z-80 based, with 8 RS-232 interfaces, one for the uplink to SITA, the airlines data network, and the other 7 for terminals and / or printers.

The RS-232 interfaces caused some of my problems. Zimbabwe has very heavy lightning during the summer thunderstorms but, compared to the ubiquitous 1488 and 1489 RS232 interface ICs, surge protectors were fairly expensive. So I lived with replacing blown interface chips. However the CCU had about 16 of them to cover the 8 interfaces, and finding out which particular IC was blown needed a lot of prodding around on the board. Sometimes a line would put out a positive OK but not a negative, and without data on the line, that was almost impossible to find.

So I designed and built a “USART emulator”. The CCU had four 2-channel Z80-SIO USART ICs (one of the interfaces was Synchronous with clock signals, and the rest were Async with a couple of handshake lines). My tester plugged in instead of the USART IC and drove all the interface output lines with a 1-Hz square wave (yes, from a 555!). A companion 25-way D-plug adapter showed, with LEDs, whether the RS232 lines on that interface were giving both + and – outputs. A loopback switch sent the RS232 signals back to the RS232 receivers and back to my USART tester, which showed with more LEDS if the input signals got back in ok. With the aid of a cross reference table showing which signals on which USARTs used which interface chip, the blown chips could rapidly be located and replaced. And socketed, though Murphy’s law ensured that I very rarely replaced the same chip twice!

The keyboards were another source of problems. Most of them were the capacitive type where a disk of insulated foil is brought down by a key press on top of two pads on a PC board, hence making a capacitive path between them. On the older keyboards the foil disks were held on to the key mechanism by a disk of soft foam, which with use and age began to disintegrate. I managed to find a solution for this. The foil laminated between two layers of plastic, which is used in the bladders in wine “boxes”, was almost identical to the original foil. And thick double-sided tape worked almost as well as the foam disks, though it gave a slightly harder “feel”. My main problem, though, was testing the keyboards before and after repair. Some of the most used keys – and hence the ones that failed most often - only had a noticeable function when the terminal was communicating with a host system, which I did not happen to have in my workshop. So I designed a keyboard tester – a 74LS373 latch grabbed the 8-bit keyboard output and displayed it on 8 LEDs. A transistor and speaker on the strobe line gave a nice audible click whenever a key was pressed. Simple but effective, and any dodgy keys could be immediately identified and fixed.

One day one of the Travel Agents asked me, “We have a PC on each of our desks, along with your terminal. Why can’t the PC be the terminal as well?” I started explaining that the terminals didn’t talk the same language as PCs….. but even as I did so I was thinking about ways round that. And really, PCs then always had an RS-232 serial port or two, so why not? The more I thought about it, the more I was sure it could be done.

I borrowed a protocol analyzer and captured some exchanges between a working terminal and the CCU controller. Most of the letters and numbers were ASCII, but some of the more proprietary keys (and these were VERY proprietary terminal systems) used various control and symbol characters, sometimes different codes for the same character depending on whether it was upline or downline. In addition, some of the characters on the terminal screen did not correspond to any standard PC characters. On top of that, the standard terminal screen was 30 lines of 64 characters, which did not fit into the standard PC DOS screen of 25 lines x 80 characters. Clearly I had a few hoops to jump through here.

I found a font editor program that could produce and edit fonts of any desired matrix size. Using an 8x8 character gave a screen of 43 lines x 80 characters on a VGA screen, enough to fit a “window” of 30 x 64 for my terminal screen. I could also edit some of the font characters to give me the special symbols that were used on my terminals. The Qbasic that came with DOS 6.2 was good enough for a “proof of concept” terminal emulator program, and worked so well that I stuck with it, using the Quickbasic compiler thereafter to generate a standalone EXE file.

I had a main loop that scanned the keyboard and the COM port for input, then performed character translations where needed on the keyboard input codes and sent them off to the COM port, and wrote incoming characters from the COM port to the screen. . I had to code for character sequences that were used for positioning the cursor, clearing the screen, etc but my protocol analyzer had given me all the information I needed to do that. The extra screen lines I used for a clock, my company name and phone number, the travel agent name, and some information as to which PC keys were mapped to special functions that were only found on my terminal keyboards. My program was very well received by travel agents who were already using PCs on their desks. And freed up some terminals (I only had a limited supply of them) to use at other travel agents.

Some agents had old XT monochrome PCs on which my program would not work. When I bemoaned this fact to a friend who worked in British Airways, he reminded me that BA could configure 16-line screens instead of the usual 30-line types. So I wrote another version of my terminal program to give a 16 x 64 window in a 25 x 80 screen and more old PCs could be used as terminals. More happy customers.

Then one of the travel agents asked if I had a solution for their problem: they had a small office within a United Nations office, with one staff member, and as they paid a fair bit per connection to the Air Zimbabwe system, it was not economic to get a separate connection for one small office. By this time I was on a roll. “Yes, I can help you there…” I wrote yet another version of my program to work via a dial-up modem. By sharing their fax/phone line at the UN office, and dedicating a spare phone line at their main office, they could now use a PC as a remote terminal. I got some cheap end-of-line modems from a supplier of mine, and got yet more happy customers.

My BA friend was amazed by the adaptations I had made to their old equipment, and told the manufacturer about them, and they were similarly astonished at the use to which their old equipment had been put – they were then making a newer (and more expensive) line of terminals including a PC card adapter, but they still didn’t do remote dial-ups!

My systems were used by most of the Zimbabwe travel agents for quite a few years, until Air Zimbabwe connected them to the Galileo system which offered much more functionality to travel agents than the basic Air Zimbabwe reservation system did. Although my systems were not state of the art technology, the challenges I had in maintaining them, and making them do things their creators never intended, gave me a lot of fun and satisfaction as well as providing me with a good income. And you can’t ask much more of life than that.

About Author David Ashton: "I’m not sure what I am….. I was born in London, UK, raised and trained and worked in Rhodesia, then Zimbabwe, and I now live in Australia. (So I’m a Pom-Rhodie-Zimbo-Aussie??) Work-wise it's much the same. I have run electronics labs and managed telecoms centres, run my own comms business, and I am now working as a telecoms specialist keeping a large comms network going. I’m a jack of all trades, and yes, admit I’m master of none, but I kinda like it that way. It makes it difficult to get bored."