How to Solve Common QuickBasic Communications Port Problems

• Microsoft QuickBASIC for MS-DOS, versions 4.0, 4.0b, 4.5
• Microsoft BASIC Compiler for MS-DOS and MS OS/2, versions 6.0, 6.0b
• Microsoft BASIC Professional Development System (PDS) for MS-DOS, versions 7.0, 7.1

SUMMARY

This article outlines troubleshooting advice for using serial communications in Microsoft QuickBasic versions 4.0, 4.0b, and 4.5, in Microsoft Basic Compiler versions 6.0 and 6.0b for MS-DOS and MS OS/2, and in Microsoft Basic Professional Development System (PDS) versions 7.0 and 7.1.

This article gives a sample OPEN COM statement that should work correctly. Additional communications troubleshooting hints are also given. For a related article, see the following article in the Microsoft Knowledge Base:

Q39386 Error Message Explanations When Using COM1: and COM2:

MORE INFORMATION

If you have problems using "COM1:" or "COM2:", try the following OPEN statement, which makes Basic as tolerant as possible of hardware-related problems:

OPEN "COM1:300,N,8,1,BIN,CD0,CS0,DS0,OP0,RS,TB2048,RB2048" AS #1

1. The higher the baud rate, the greater the chances for problems; thus, 300 baud is unlikely to give you problems. 2400 baud is the highest speed possible over most telephone lines, due to their limited high-frequency capability. 19,200 baud, which requires a direct wire connection, is most likely to cause problems. (Possible baud rates for QuickBasic are 75, 110, 150, 300, 600, 1200, 1800, 2400, 4800, 9600, and 19,200.)



2. Parity usually does not help you significantly; because of this, you should try No parity (N).
   
   For those devices that require parity, you should use the PE option (Parity Enable) in the OPEN COM statement, which is required to turn on parity checking. When the PE option turns on parity checking, a "Device I/O error" occurs if the two communicating programs have two different parities. (Parity can be Even, Odd, None, Space, or Mark). For example, a "Device I/O error" occurs when two programs try to talk to each other across a serial line using the following two different OPEN COM statements:

   
         OPEN "COM1:1200,O,7,2,PE" FOR RANDOM AS #1 

   and

   
         OPEN "COM2:1200,E,7,2,PE" FOR RANDOM AS #2 

   If the PE option is removed from the OPEN COM statements above, no error message displays.



3. The above example uses 8 data bits and 1 stop bit. Eight data bits requires No parity (N), because of the size limit for Basic's communications data frame (10 bits).



4. The BIN (binary mode) is the default. Note: The ASC option does NOT support XON/XOFF protocol, and the XON and XOFF characters are passed without special handling.



5. Ignoring hardware handshaking often corrects many problems. Thus, if your application does not require handshaking, you should try turning off the following hardware line-checking:

   CD0 = Turns off time-out for Data Carrier Detect (DCD) line
   CS0 = Turns off time-out for Clear To Send (CTS) line
   DS0 = Turns off time-out for Data Set Ready (DSR) line
   OP0 = Turns off time-out for a successful OPEN




6. RS suppresses detection of Request To Send (RTS).



7. For buffer-related problems, try increasing the transmit and receive buffer sizes above the 512-byte default:

   TB2048 = Increases the transmit buffer size to 2048 bytes
   RB2048 = Increases the receive buffer size to 2048 bytes

   A larger receive buffer can help you work around Basic delays caused by statements like PAINT, which use the processor intensively.

1. You should use the INPUT$(x) function in conjunction with the LOC(n) function to receive all input from the communications device (where "x" is the number of characters returned by LOC(n), which is the number of characters in the input queue waiting to be read. "n" is the file number that you OPENed for "COM1:" or "COM2:").
   
   Avoid using the INPUT#n statement to input from the communications port because INPUT#n waits for a carriage return (ASCII 13) character.
   
   Avoid using the GET#n statement for communications because GET#n waits for the buffer to fill (and buffer overrun could then occur).
   
   Also, avoid using the PUT#n statement for communications, and use the PRINT#n statement instead. For example, in QuickBasic 4.0b and 4.5, in Basic Compiler 6.0 and 6.0b, and in Basic PDS 7.0 and 7.1, using the PUT#n,,x$ syntax for sending a variable-length string variable as the third argument of the PUT#n statement sends an extra 2 bytes containing the string length before the actual string. These 2 length bytes sent to the communications port may confuse your receiving program if it is not designed to handle them. No length bytes are sent with PUT#n,,x$ in QuickBasic 4.0. (QuickBasic versions earlier than 4.0 don't offer the feature to use a variable as the third argument of the PUT#n statement.)



2. For an example of data communications, please refer to the TERMINAL.BAS sample program that comes on the release disk for QuickBasic versions 4.0, 4.0b, and 4.5, for Microsoft Basic Compiler versions 6.0 and 6.0b, and for Microsoft Basic Professional Development System (PDS) versions 7.0 and 7.1. Many communications problems may actually be due to inappropriate source code design and flow of control.



3. Many communications problems can only be shown on certain hardware configurations and are difficult to resolve or duplicate on other computers. We recommend experimenting with a direct connection (with a short null-modem cable) instead of with a phone/modem link between sender and receiver to isolate problems on a given configuration.



4. The wiring schemes for cables vary widely. Check the pin wiring on your cable. For direct cable connections, a long or high-resistance cable is more likely to give problems than a short, low-resistance cable.



5. If both "COM1:" and "COM2:" are open, "COM2:" will be serviced first. At high baud rates, "COM1:" can lose characters when competing for processor time with "COM2:".



6. Using the ON COM GOSUB statement instead of polling the LOC(n) function to detect communications input can sometimes work around timing or buffering problems caused by delays in Basic. Delays in Basic can be caused by string-space garbage collection, PAINT statements, or other operations that heavily use the processor.



7. Make certain that the appropriate hardware handshaking lines (i.e. CS, DS, CD, etc) are being checked by Basic. Although disabling these timeouts (setting the corresponding value in the Basic OPEN statement to zero) is useful for determining what lines your hardware uses, it should not be considered a general purpose method for establishing serial communications, since ignoring hardware handshaking may increase the possibility of a timing problem that could lead to a hang.

"C Programmer's Guide to Serial Communications" by Joe Campbell, published by Howard W. Sams & Company.

"8088 Assembler Language Programming: The IBM PC" Second Edition by Willen & Krantz, published by Howard W. Sams & Co. (1983, 1984). Pages 92-93, and Chapter 7 (Pages 166 to 188).

Additional query words: QuickBas BasicCom 4.00 4.00b 4.50 6.00 6.00b 7.00 7.10

Keywords :
Version : MS-DOS:4.0,4.0b,4.5; :6.0,6.0b,7.0,7.1
Platform : MS-DOS
Issue type :