I have been experimenting with hooking up low-cost ESP8266 WiFi modules to the Radio Shack Color Computer (or anything with an RS-232 port) using cheap RS232-to-TTL adapters. Most of these adapters only support 3-wire RS-232 (transmit, receive and ground). This is fine for most uses of the CoCo’s built-in Serial I/O port (bitbanger) since it is only a 4-pin DIN connector with TX, RX, GND and CD, and most things do not rely on carrier detect.
But, for the Deluxe RS-232 Program Pak, a hardware 6551 UART chip is used and that chip requires to see carrier detect before it will receive any data. A workaround is to simply tie some of the TTL converter pins together to make it always present DCD to the RS-232 Pak:
This works fine if you are just connecting to remote systems, but if you want to run a BBS, those often rely on carrier detect to know if a caller is online. If a caller disconnects without properly logging off, the system may sit there forever (worst case) or until some software timeout is reached and the system resets. During that time, it would be possible for the next person connecting to resume that session.
This was a real and common issue with BBSes back in the 1980s, for this very reason – lack of carrier detection.
Another issue is the lack of hardware flow control. There could be times when the ESP8266 could try to send data faster than the computer could process, and there is no way (other than XON/OFF, which can’t be used for binary transfers) to tell it to pause sending.
I have found RS232-to-TTL adapters that provided 5-wire signals (adding RTS and CTS), which is needed for this hardware flow control. Those are a bit more costly (I found one for $9 on Amazon), and still do not address the carrier detect issue.
Once again, David Chesek comes to the rescue. He located an adapter that supports all the RS-232 signals, including RI (ring indicator). It is available for $11.50 plus shipping from a company in Las Vegas called Pololu (and might even be manufactured there):
I took a gamble (pun intended) and ordered a few. I will report back as soon as I receive them and have had a chance to try them out.
Meanwhile, knowing such a thing exists, I did more searching and found a similar one on e-Bay from a seller called MDFLY. They have them for $3.25 plus shipping, and are shipped from California:
The board layouts are quite different, but the functionality should be similar. I will be comparing both of these (and noting shipping time) when I have them.
With either one of these boards, properly wired to additional pins on a full ESP8266 development module, it should be able to provide hardware flow control and carrier detect. (Sorry, the ESP-01 module only has two I/O pins, so we’d have to pick and choose what to support on that one — like DTR and DCD for BBS use, or CTS/RTS flow control.)
Built-in serial ports disappeared from modern computers a long time ago, but USB RS-232 adapters are available in case one is ever needed. For our 1980s Color Computer, RS-232 is one of the only available interfaces to the outside world.
The built-in 4-pin DIN connector (marked Serial I/O) is not a real serial port. Instead, it is just a set of pins that can be toggled on and off (to RS-232 voltage levels) through software. By writing software with the proper timing, this port can send out serial data. This technique is called “bit banging” and it was very common in systems of this era. (And, today, if you use an Arduino, the “SoftwareSerial” routines which turn any I/O pin into a serial port are doing the same thing.)
There are many modern things that use serial for communication, but they are doing so at chip-level voltages – called TTL level (transitor-transitor level). An example of this would be the I/O pins of a Raspberry Pi or Arduino. There are also a myriad of small devices that work over a TTL-level serial port, such as USB interfaces, WiFi modules, Bluetooth, and many more.
To interface one of these with an old computer with an RS-232 port, you can use an RS-232 to TTL adapter such as this one from Amazon:
This device has a DB-9 RS-232 port on one side, and pins on the other that represent the common signals of Transmit (TX), Receive (RX), Ground (GND) and voltage. Voltage is usually 5v or 3.3v depending on the device and what it will connect to. (An Arduino UNO has 5v I/O pins. A Raspberry Pi and some other models of Arduino use 3.3v pins.) The adapter has to match. Some are smart, and adjust based on the voltage they are given. Thus, if you are hooking an RS-232 device to an Arduino, you would power this TTL adapter from a 5V pin of the Arduino, and it should operate at 5v. Some adapters claim to adjust, so if you hook them up to a 3.3v pin on an Raspberry Pi, they work at 3.3v. The RS-232 side should be the same (traditional RS-232 voltage levels) in either case.
I have recently been experimenting with devices such as the ESP8266, which is a tiny (and cheap!) module that provides WiFi for about $2, and interfaces with TTL level serial. Using the CoCo’s built-in Serial I/O (bitbanger port) and a cable, I was able to hook the CoCo to one of these RS-232 TTL adapters and then hook that to the ESP8266. It worked great, limited only by the baud rate of the bitbanger! (Most older CoCo 1/2 terminal programs could only go about 1200 baud. The CoCo 3 has at least one terminal program, Twilight Term, that can operate a 9600 through the bitbanger port.)
Since the bitbanger port only has TX, RX, CD and GND (and CD is not really used unless software specifically uses it), hooking it up like this worked well. But, when trying to connect to the more robust RS-232 Pak (which can operate at speeds of up to 115200 baud), I ran into some problems.
The 6551 can transmit data just fine, but in order for it to receive, it expects to see a carrier detect signal (DCD). If you just hook up the RS-232 Pak cable to the TTL adapter, using only TX, RX, and GND, that signal will not be active and terminal programs will not read any of the incoming data. You can send, but not receive.
In order to make this work, you have to trick the RS-232 Pak into thinking there is a DCD signal. From exploring various mailing lists, Facebook groups, and web postings, I found several suggestions on how to do this. The overall method looked like this:
By tying certain lines together on the end that goes to the RS-232 Pak, the Pak will think there are signals present that really are not there. This makes it work, since it now thinks there is a carrier detect.
The above modification can be done on an RS-232 to TTL adapter with a soldering iron and a bit of wire. A small solder blob can be used to connect pins 7 (RTS) and 8 (RTS), then another blog can connect pins 1 (DCD) and 6 (DSR), then a jumper wire can be ran from that solder blob over to 4 (DTR).
Dave Chesek did a modification on is cable and it looked like this: (And apologizes to Dave if he isn’t proud of his soldering skills. They are much, much nicer than what I can do!)
I picked up a pair for around $8 because I wanted to find out which of the various suggestions would actually work. Through process of elimination, I found that the DCD+DSR+DTR was needed, but RTS+CTS was not. (And, some RS-DOS terminal programs worked with just DCD+DTR, which was one of the suggestions I was given.)
I hooked up short jumper wires like this:
For the CoCo’s RS-232 Pak, this works great for various RS-DOS programs I tested (Greg-E-Term, Ultimaterm) and OS-9/NitrOS-9 (Supercomm).
I had read that the RS-232 Pak won’t send without a certain signal being present, but from my experiments this week, this does not seem to be the case. Only the DCD situation must be taken care of.
With this information, you can now get an RS-232 Pak out to an RS232-to-TTL adapter and then hook up various devices. In the case of my ESP8266 experiments, I was powering the TTL adapter off the ESP8266 module. If I were trying to use something stand-alone, like an HC-05 bluetooth module, I would need an additional 5v or 3.3v power source to power the module and the adapter.