RS-232 Serial Communication Notes

6-8-99, 11-20-04

Notes I made during experiments connecting two computers together via their serial ports.

Handshaking

• Bios (DOS) will not output any char until DSR is active. ZPC (a 1980's Heath Users Group program that emulates an IBM PC on a Heath/Zenith H/Z-100 computer), in its notes on INT14, says the default for IBM is to use both CTS and DSR. It probably provides, and requires, all defined status lines. So, probably, does Windows for OutputDebugString() [Except that it must refer to ControlPanel to get the communication settings, and if so, why does it ignore the "NO Handshaking" one? Maybe it doesn't use ControlPanel, but just the DOS settings directly?]. If there is not a legitimate device providing all required handshaking, it won't work.
• QBASIC provides a means of ignoring DSR and other signals. MSDOS doesn’t, which means you can’t ignore them in a generic DOS C++ program. Qbasic and commercial modem programs probably bypass bios to communicate with the chip directly.
• Borland C++ Library Reference p.475 implies (and Inside Visual C++ p.244, even more so) that WinAPI OutputDebugString() may be sent to multiple destinations, i.e. it tries AUX, tries..., and generates an interrupt which may or may not be acted on by some process, and sends a "notification" to (any?) process(es?) that have registered themselves to receive it. (See DIAGXPRT.IDE.)
• When properly cabled, you can write to a modem with Qbasic "Open Com" without using any modifiers to ignore signals.
• MSDOS generic output (such as dir > com1) is the least forgiving. If it works, the setup is probably right.
• H89 Configur.com should be able to test both RTS and DSR, either high or low.

Hardware

COM1, COM2

• P5-90 computer CMOS stores no communication parameters.
• Chips do not stay initialized with the last values used.
• AUX is COM1
• COM1 and COM2 seem to be redefinable mnemonics. In Control Panel, you can specify the ports and IRQs. And the P5-90 CMOS booklet refers only to "first serial port" and "second serial port". So the names aren't inherently linked to either port. If you reversed the serial port addresses in CMOS (or in Control Panel Ports > Advanced Setup), you should get COM1 on the DTE plug.
• When COM1 and COM2 are connected to each other, MSD after system boot reports all lines not detected, but communications between them does work everywhere, including Windows, even with hardware handshaking specified in Control Panel. When I ran MSD in a window, it did detect proper signals from the port it was able to access (the other was in use by Terminal.exe).

Serial Communication Chips

• The 16550AF is probably a descendant of the INS8250, and must be backwards compatible for old programs to work. Which means ancient (Heathkit) H-89 serial code (Modem8, MEX, etc.) is probably more IBM compatible than the H-100 is, and might be useful as a reference.

Modem Programs and Serial Programming

There are at least two programs on the site dealing with RS-232 programming, including serial communications C++ classes for MSDOS and Windows. A site Search on RS232, RS-232, or serial might turn up more.

IBM BIOS uses INT 14h for serial communications operations. If you use this, you can do serial programming independent of the actual com port addresses, and don't have to program the ACE chip yourself. INT 14h appears to be able to set all parameters except hardware handshaking options. (Haven't researched this.)

But you can program the ACE yourself, and get more flexibility. Commsupp (IBM PC serial support for DeSmet C) does this, and is the best starting point for such a program.

See also:

1. Help notes at Borland bioscom(), _bios_serialcom().
2. ZPC INT14.ASM and the ZPC manual. (One question to research: ZPC can specify desired type of hardware handshaking. How can it do it, if the real INT 14h can't?)
3. ASM source for Mex or other H89 programs. The 8250 methods would apply to IBM, though the asm statements would have to be translated.