Forty Years of Personal Computing - Modems and Serial Ports

The GE TDM-114 Data Set. The big toggle
switch is my modification so I could turn it off.

GE TDM-114 Data Set

In the fall of 1979, I headed off to Georgia Tech and brought my computer with me to the dorms. My roommate that first quarter wasn't impressed. Nevertheless, I continued to work with the computer and learn new things.

In those days, Georgia Tech used a CDC Cyber 74 system for instruction, and one could dial into the system with a modem. I managed to locate a GE surplus modem for about $40. It was an acoustic coupler modem -- you would dial the phone manually, then jam the handset into the unit. Speakers and microphones would pick up the sounds from the phone line through the handset.

Rear View of TDM-114.

In my second quarter, I ordered a unit. When I got it, it did not work.  Fortunately, it came with a manual with a schematic and troubleshooting and adjustment guide. I didn't have any test equipment other than  a Volt-Ohm Meter (VOM). I don't remember how I fixed it. With youthful curiosity and dogged persistence, I managed to find a diode that didn't appear to be working, replaced it, et voila! It worked. 

Manual with unit.

This was a BELL 103 modem, which meant it supported speeds from 110-300 bps. Back in 1980, that wasn't as slow as it seems. Who am I kidding? It was really slow. It was what we had.

Schematic

Initially, I hooked the modem directly to my CT-64 Terminal system. It was fun being able to dial the Cyber 74 and work on programs from my dorm room. But, it was a pain to swap the cables around between the computer and the modem. It would be nice to leave the CT-64 plugged into the computer all the time, and plug the modem into another serial port. I needed more serial ports.

MP-S

I purchased two MP-S serial ports in early 1980. These boards use the MC6850 Asynchronous Serial Adapter (ACIA). The advantage of the ACIA is it could transmit and receive individual characters without any CPU attention. The big-banging serial port used by the MP-C required the CPU to actively perform all sending and receiving.

The MP-S is really simple, especially after removing the current-loop circuitry, as I've done.  I liked this about the design of the SWTPc 6800 Computer Sytem - I/O devices could be added very inexpensively. 

One board replaced the MP-C (since I was using SWTBUG by then) and communicated with the CT-64 at 1200 bps. The other used a different slot and was wired for 300 bps. Making them talk to each other was a small matter of software.

The Terminal Program

My initial attempt was a mad polling program in 6800 assembly language. It consisted of a crazy loop that looked for received characters from one port and transmitted them on another, and then did the same thing going the other direction. It even had buffering in each direction.  It probably wasn't even 100 bytes long. It worked well.

In the fall of 1980, it occurred to me this could be an interrupt-driven program. This took a bit of doing. You had to configure the proper interrupts and then have an interrupt service routine to determine the cause of the interrupt and service it. Get something wrong, and nothing would happen. This made it much more difficult to debug. 

I rose to the challenge and got it to run. I included even larger buffering than in the first program. I had hoped to use the MC6800's WAI (Wait for Interrupt) instruction, but ended up using the idle time to perform buffer housekeeping. 

The buffering came in handy. For a while, I had a switch on the CT-64 that would pause reception from the computer. I could run a long listing at 300 bps, flip the switch and read a screenful while the next screen slowly buffered in my computer. flipping the switch again and it would spool on the screen at 1200 bps -- the top speed of the CT-64.

This experience laid the groundwork for my first job -- at Hayes Microcomputer Products, Inc after I graduated from Georgia Tech. I spent nearly twelve years writing much more sophisticated terminal programs.