Undercolor/850103/Cross Talk Pt II

Home Articles Companies Publications Hardware People Software Timeline ... Emulators Internet Resources
(Don't see something listed? Click "edit" and add it! Together we can build this database. When making a new info page, refer to this InfoBox Template for guidelines.)

---

UnderColor, Volume 1, Number 3, January 11, 1985

• Title: Cross Talk Pt II
• Author: William Barden, Jr.
• Synopsis: The last word on RS-232
• Page Scans: Link

Article

Last month, Bill explained what RS-232C is, told us about bauds, and presented some programs to use. This month he tells us what we can do with them! Refer to part one for the programs.

You can easily use the program to connect two Color Computers and pass data between them. Prepare a cable as follows:

Get two 4-pin DIN connectors from Radio Shack (274-007).Solder a three-wire cable between the two connectors, as shown in Figure 1. ln this configuration the TD signal from one side goes into the RD signal for the other system, and vice versa.

Load the program into both computers. Start the receiving system by calling the Input Character routine after POKEing the starting and ending locations of the memory area to be filled with data (or use the screen addresses). Next, start the transmitting system by calling the Output Character routine from Basic. If you’re using the terminal program above, you can start either system first.

If you’re using the program to transfer data between your Color Computer and another computer system, you may have some difficulties—not on the Color Computer end, but in the connection with the other system. Other computer systems use additional signals beyond the 22 RS-232C signals to establish a protocol. There are no clear-cut rules by which signals are used. It may be necessary to "dummy up" some of the signals on the other system to fool it into thinking the signals are being properly received from the Color Computer. This is done by routing an output signal to an input signal on the same end. It may be necessary to do this for several signals, and you may have to wire a special DB-25 plug to accomplish this. A convenient plug to use is the Radio Shack male DB-25 (276-1559). Regardless of the signals dummied up on the other end, there need be only three signals on the Color Computer end. A typical configuration is shown in Figure 2.

To Peripheral Device

You can also use this program to communicate with peripheral devices, such as printers and plotters. For reference only, the line printer-driver subroutine in ROM uses three lines, but not in the same way we’ve been connecting devices here. The RD line is used as a status line to indicate whether the line printer or other device is ready to receive data, as shown in Figure 3. This line must normally be kept at a voltage level of greater than +3 volts, or must be connected to an appropriate status signal from the device.

If you’re using the Character Output routine to transmit data to a printer you'll need only the TD and ground lines. Connect the TD line to the RD printer input and the ground line to the ground printer line. Again, it may be necessary to dummy up some of the other lines on the printer end, as shown in Figure 4.

Data-Buffer and Overrun

Using the RD line as a status indicator is an excellent idea. Don't forget—if you're sending data to a peripheral device, that device must be able to keep up with the data transmission rate. If a printer operates at 180 characters per second, for example, and you're sending data at 2400 baud (240 characters per second for 10-bit characters), you’ll quickly overrun the printer. Most printers or other peripherals have some buffering that allows the device to save a limited number of characters, usually hundreds. Buffering lets the device receive bursts of data at high-speed rates, and then empty the buffer (a temporary storage spot) during periods when no transmissions are taking place.

If data overruns the buffer, data following the overrun will be lost. To overcome this problem, other RS-232C lines, such as RTS (request to send), are typically used, but our program makes no provision for a return of status.

You might notice in the Basic terminal program that characters are occasionally lost. This usually occurs for repeated characters, such as the second O in good; it happens because of the speed restrictions of the Basic keyboard scan routine. Characters sent from within a program will not be lost.

We’ve barely scratched the surface of RS-232C. Use the program to experiment with your own data communications applications. At another time I’ll show you how a slight modification of the basic program can be used to implement your own terminal program for communication with CompuServe and other data communications networks. (end)

The assembly language program really just implements what we've discussed here. On the output side, a zero bit is output to PIA $FF20 for one bit time. Next, the number of specified data bits are output through the $FF20 PIA a bit at a time, starting with the least significant bit. Finally, a one stop bit is output to PIA $FF20 for one or two bit times. The output on the TD line is left in the stopped state.

On the input side, the RD line is monitored by reading PIA $FF22. Whenever a zero bit is detected, the program starts counting by a delay loop based on the baud. After 1 1/2 bit times the first data bit is read. The remaining bits are read and assembled into 7- or 8-bit characters. After the last data bit has been read, the program delays for the following stop bits.

Two delay loops delay either one bit time (DELAY) or one-half bit time (DELAYH). A delay count is obtained from a baud table indexed by the baud code (0-7). Note that the delay counts are slightly different for output and input, reflecting the slightly different numbers of instructions for each operation. As each instruction executes in a fixed time, the delay count is determined by considering the time through the program delay loop plus some additional "overhead" for other operations. You may try changing the table values slightly to alter the bit times if you add additional assembly language code in the program. Send constant characters to determine minimum and maximum values for error-free transmissions, and then choose an intermediate value for each baud.

The keyboard scan in the Input Character routine quickly reads all keyboard columns to determine if a key has been pressed. Using the Basic ROM subroutine proved to be too slow to avoid data overrun at higher bauds. Similarly, using the ROM subroutine for Display Character proved to be too slow at the end of a line when the screen was scrolled. Several characters are lost during the scrolling time.

Listings

None.