Butterfield On RS-232 Interfacing

I have a RS-232 interface made by Quantum Data, Inc., connecting my Data Products DP-50 Daisy Wheel printer to my VIC-20.1 am having a problem printing anything in my program. I keep getting out of memory. I am able to use my un-word processor I got from Microdata. It prints fine. However, it's in machine language and my programs are in BASIC. I can also list my programs by using:

10 open 128, 2, 0, chr$ (4 + 2) : cmd l28 : list

Here is the buffer Control Protocol for my printer (handshaking).

Data Terminal Ready, goes false (-V) when the interface buffer has less than 16 locations remaining and goes true (+ V) when the buffer has more than 96 locations available. Remote/Software Provision: The terminal inspects the incoming data stream for the ASCII ETX control character (67 Coded Decimal Value) and automatically transmits an ACK control character (70 Coded Decimal Value) when the ETX is pulled from the interface buffer. By transmitting the data in blocks separated by ETX characters, the host system can synchronize the rate of block transmissions to the actual average printing speed.

So it looks like I have to set up a buffer for handshaking. I am lost; can you help me? I have one other problem in setting up this buffer. If I want to print lower case letters I will need some conversion in setting up my buffer. This is because my printer uses true ASCII characters, not Commodore. Are you still with me or have I lost you as I am lost?

Daryl E. Williams

The August issue of COMPUTE! should have been some help on how VIC uses RS-232 (page 99, "VIC Communications: The RS-232 Interface").

First, a little exercise in terminology. Usually, VIC is the "terminal" and is working a communications line through a modem. However, if we want VIC to talk to a printer, VIC can't be the terminal – we already have one of these – so VIC must become the "line," acting the part of the modem. No problem here except that connections change names as they pass between the two units. One device's Send is the other's Receive, of course. The DTR sent by the printer becomes the DSR (Data Set Ready) connection on the VIC, and vice versa. Similarly, the RTS (Ready to Send) output and CTS (Clear to Send) input must be flipped over between the two devices.

RS-232 is hard to pin down; it can be used in many ways. If we wish, we can simply send on the send line and receive on the receive line and not worry about the other wires. This is the basic "three-wire" operation (the third wire is ground); it has no handshake. Alternatively, we can use DSR to see if the other guy is willing to receive from us, and DTR to signal whether we are ready to take from him. This is one of the options on your printer.

Now, VIC reads the handshake lines from the printer (VIC sees them as DSR and CTS) and is capable of restraining traffic. Unfortunately, there's a bug in the present VIC software, and the handshake won't work. Your program can still check this information directly: DSR, the printer's DCD, can be seen with PEEK(37136) AND 128; and CTS, the printer's RTS, can be seen with PEEK(37136) AND 64. But you must do this in your BASIC program.

The alternative you mention is a remote/software handshake. Not hard to do for a printer that is so equipped. Just PRINT #n, CHR$(67); that sends the ETX. Now wait in a GET #n loop until you get a character back from the printer. The character will be CHR$(70), but that doesn't matter. When it arrives, you'll know that the printer is " caught up."

No need to set up a buffer: opening the RS-232 does that for you automatically.

Final problem: PET ASCII is not the same as ASCII. The conversion rules – assuming your PET is in text mode (upper/lowercase) – are as follows: ASC values less than 65: no change. ASC values from 65 to 96: add 32. ASC values from 193 to 224: subtract 128. Any other characters are not really ASCII compatible (for example, graphics), and you can make arbitrary decisions on their translation.

This is all very nice as a set of rules, but starts to look clumsy when you want to translate "The quick brown fox…" for the printer. Each character will need to be extracted with MID$, changed to its ASC number, translated to the new ASCII numeric, and then sent on its way with PRINT #n, CHR$(..);. Slow and unsatisfying, but workable. The translation part can be speeded up somewhat by setting up an array of pre-translated values, so that a PET ASCII value of 70 would translate immediately to T(70), in this case 102. We can now start boiling down translation of string S$ to something like:

FOR J = 1 TO LEN (S$) : PRINT #n, CHR$ (T (ASC (MID$ (S$,J)))); : NEXTJ

(Whew!)

The whole thing becomes faster and easier with either of two other solutions: hardware or machine language. It turns out the manipulations above are really simple bit rearrangements. A few hardware gates on the interface will do the job easily. Similarly, a few machine language instructions can test for certain bits and then AND them away or OR extra bits into place. But we must deal with new questions here: how do we get into the information stream to make these changes? It can be done, but there's no space for a brief answer here. Perhaps your word processor can be easily modified for your printer; you might query the supplier.

The following machine language conversion code lakes a PETASCII value in the A register and converts it to ASCII before output. The hardware conversion is very similar to this simple machine language process.

        CMP #$40
        BCC NOTALF
        CMP #$60
        BCS NOTALF
        ORA #$20
NOTALF  AND #$7F

The jargon of RS-232 can intimidate the beginner. It can be puzzling to find that most of the 25 connections are left unused in the average system; they are there for features that we don't need. And the VIC's non-working handshake doesn't help clarify things.

But the pieces are all there, and they can be made to work. The VIC gives you a lot of help on RS-232: a bit more effort might pay real dividends.

Jim Butterfield

COMPUTE! welcomes questions, comments, or solutions to issues raised in this column. Write to: Ask The Readers, COMPUTE! Magazine, P.O. Box 5406, Greensboro, NC 27403. COMPUTE! reserves the right to edit or abridge published letters.