[Coco] Was DCD ever useful on the RS-232 Pak?

[Allen Huffman]

Tonight I finished “yet another” prototype of my CoCoWiFi decide, this time using the ESP-32S NodeMCU module. This module cost a few dollars more, but also includes Bluetooth.

The Zimodem firmware (https://github.com/bozimmerman/Zimodem <https://github.com/bozimmerman/Zimodem>) builds differently for ESP8266 versus ESP-32.

They used the ESP8266 code a Commodore WiFi modem project. Commodore has inverted signals, so HIGH and LOW are swapped. What we would see as “no carrier”, Commodore sees as “carrier detected”. This means using the stock firmware, we have to go in and reconfigure it to be normal RS-232 signals.

This can be done, but it’s tricky, because if you use the RS-232 Pak, changing the wrong setting (like DCD) will suddenly make us unable to talk to the ESP module.

The ESP-32 build of Zimodem is meant for “the rest,” so all the signals are fine out-of-the box, including DCD being forced on so you can communicate with it on the RS-232 Pak. It also works on the bitbanger.

HOWEVER, I am now wondering what use DCD ever was on the RS-232 Pak. If there is no carrier detect, the RS-232 Pak won’t talk. If you want DCD on for a BBS, so you get carrier detect when a caller is online, and it drops when they disconnect, then once they disconnect (and there is no DCD), you have zero communication with the modem.

This is the situation I am in. As soon as I toggle on true DCD detection, I am then locked out of Zimodem. If I have auto-answer on, and someone connects, I get DCD and stuff works. As soon as they close the connection, I can no longer send commands (no TX lights blink, even) to the zimodem.

Can someone refresh my memory to how this worked back in the 80s and 90s? I ran multiple BBSes but don’t really recall how this worked.

		— A