Sending ASCII control strings using C8P modem port to RS-232C device

[lowrybt1]

I'm working with a vintage/working RS-232C Heathkit power line communication device (GD-1530) that takes ASCII command strings sent from a PC and converts them into X10 signals that control AC modules throughout the house. The protocol is 1200 Baud/8N1 with no flow control. The Heathkit device expects the signals to arrive via pin 2 of a DB-25 connector with ground on pin 7.

Using Cool Term in Windows and a FTDI USB-Serial converter, I've determined that the Heathkit device is working. The Heathkit device expects to receive command "words" consisting of 2 or 3 bytes ending with a 3rd or 4th byte that is CR (13). The Heathkit device also appears to want to receive the bytes in one pulse (forgive the loose/incorrect terminology here), by which I mean the device recognizes command words sent in line mode (as a serial string) not in raw mode -- i.e., does not respond when each character is typed one-by-one into the terminal window followed by a RETURN/ENTER keypress.

Heathkit instructions recommend using the statement PRINT #1 to send command words via the ACIA serial printer port. Unfortunately, the serial printer port on the OSI side expects CTS handshaking which the Heathkit device does not provide. So, the C8 hangs whenever I try using PRINT #1 to send commands to the device. Elsewhere on the forum, Danny has mapped out the few simple steps to modify the 505B board to eliminate this problem. This being my one and only 505 board and given my limited experience modifying hardware, I'm hesitant to modify the board. So, I'm making an attempt to send commands via the modem port with the following test program, poking a command word "A1" followed by a CR byte by byte:

5 POKE 64512,21 : REM set Baud to 1200 and data word format to 8-N-1
10 A$="A1"+CHR$(13)
20 FORB=1TOLEN(A$)
30 A=ASC(MID$(A$,B,1)):POKE64513,A
35 NEXTB

Using an RS-232C tester, I can see that signals are going out via modem port pin 2 and that signals are being received on pin 2 of the Heathkit device when this program is run. (By the way, I am using a straight-through cable, not a null modem cable since the Heathkit device receives on pin 2 and the modem send using pin 2). This approach is not working. My guess is that it has something to do with timing. I think the poked value for 64512 is correct for 1200/8-N-1.

I suspect the next step is to modify the ACIA to eliminate the CTS issue with this device.

But one last check: is there anything about utilizing the modem port I might be missing here?

Tom

[Mark]

Sorry, this got kinda rambly....

So the 505 board RS-232 was made to control a printer and modem using one ACIA.
The PIA at $F703 control line B2 (CRB2) is used as the control line for a data selector that switches between CTS/DCD for modem and CTS for printer. Printer I/O is assumed to be output only (except for CTS) and is wired to the J8 connector. The modem is used on the J9 connector. The DCD input signal is only used for the modem. When printer is selected the DCD line is wired low (active) internally.
J9 is the port nearest the DB-9s on the A15 board. RS-232 IN on the OSI is only wired to J9 by default I think. See page 76 in the SAMS C4P manual.

CTS is just a voltage level. In needs to be active (on) in order to send data, you should be able to jumper RTS out to CTS in on J9 in order to send.(pin 20 to pin 5 according to the schematics) I'm not sure what the default wiring is set to.

So to enable modem, I think you may need to set $F700 to $34 or POKE 63235,52. Set it to 60 ($3C) to revert back (or these values may be reverse!!)
-- At reset the 6820 PIA is set to all inputs and I think the control lines are passively pulled high which may be just fine for modem use, the pokes sets CRB2 to output and change the value from high to low.

Sorry about being so vague. When I got my C4PMF with 505 board years ago, I disconnected all the OSI RS-232 mumbo jumbo & built an external selectable baud-rate generator with onboard cassette & RS-232 interface as I wanted to be able to load old cassette as well as do serial I/O, so my C4P is no longer stock & I can't test these signals.

BASIC character by character is probably sending data too slow (thus the print#1 recommendation). You can try this program, slightly modified from the one posted a couple days ago to see handshake status & possibly send a little faster.

If you are seeing data out with your program I'd expect PRINT#1 to work too - more investigation needed. Though it may be due to the automatic CR/LF sent at the end of the print command. Try POKE 2684,44 to turn off LF, (32 to restore) and then PRINT#1,"A1" the CR is sent automatically. (Tested on OS65D3.3)

Code: Select all

REM CHECK C4P ACIA
10 ACIA=64513:CTRL=64512
20 POKE CTRL,3:POKE CTRL,21
30 V=PEEK(CTRL)
40 IF VAND8 THEN PRINT"XMIT BLOCKED BY CTS"
50 IF VAND4 THEN PRINT"RECV BLOCKED BY DCD"
60 IF VAND2 THEN POKE ACIA,65:POKE ACIA,49:POKE ACIA,13
70 IF VAND1 THEN PRINT CHR$(PEEK(ACIA))
80 GOTO 30

Once the communication is sorted out there are a number of ways to send the data you desire with a USR routine or disk call, or even some assembly language typed into the extended monitor. I'll send an update when I remember how to do that with disk basic Good Luck!

[Edited: $38->$3C , maintain PIA DDR mode]

[lowrybt1]

Thank you Mark. I'm going to give this a try. Tom

[bxdanny]

Tom,

Let me just add that, if it is a timing problem of the sort that has been suggested, it seems most unlikely that any software-only solution would get the timing between bytes exactly right.

If you don't want to make a cut on the CPU board, how about bending up pin 24 of the ACIA out of the socket, and connecting a jumper from the bent-up pin to ground?

[lowrybt1]

Here's an update.

Mark, POKE 63235,52 does appear to put the C8P's ACIA's CTS line into a state that permits the sending of data through the serial printer port using the Print#1 command without the machine freezing.

I've been able to successfully send sample X10 ASCII command words over the C8P's serial printer port at 1200 Baud/8N1 to Cool Term running in Windows with no flow control, using a FDTI adapter. As mentioned in an earlier post, I've also been successful sending X10 ASCII commands to the HeathKit X-10 device using Cool Term and the same FTDI cable. The HeathKit device is configured for 1200 Baud/8N1 with no flow control. So, it appears that I'm able to send command words from the C8P using the serial printer port and there is evidence that the HeathKit device is receiving and process commands sent via Cool Term over an FTDI cable.

Despite these result, there's no joy when sending command words directly from the C8P's serial printer port using Print #1 to the HeathKit X10 device. I'm using a straight-through cable and a RS-232C tester to ensure that signals are being sent from C8P and received on the HeathKit device side. (Making certain that the signal is arriving at the correct RX pin on the HeathKit side and that both sides are configured from 1200/8N1.)

This inability to drive the HeathKit device directly from the C8P serial port leaves me thinking the following:

1. there might be some subtle issue between the C8P and the HeathKit device when it comes to timing/framing and/or signal voltage; or

2. possibly the Print#1 command tacks on some leading and/or trailing bytes that the HeathKit device can't understand. The HeathKit is listening for command words that are 2 or 3 ASCII characters/bytes plus a CR (ASCII 13). The first byte must always contain the ASCII code for an alpha character. The second and third bytes can contain the ASCII code for either numeric or alpha characters.

The HeathKit manual contains test programs in MBASIC as implemented in HDOS for the H89. These programs use the following syntax to send command words/characters/bytes to the HeathKit device:

HDOS
1 OPEN “O",#1,"LP:" : REM opens the serial port using HDOS Line Printer driver
2 PRINT #1 "A1" : REM send command word to address X10 device #1 in House A
3 CLOSE #1 : REM sends command/clears buffer

My understanding is that Print#1 as implemented in OS-65DV3.3 BASIC handles opening the port, sending bytes to the port, terminating the send with a CR (ASCII 13); no need to clear any buffer.

Unless I am missing something about the way that Print#1 works, my next step is to follow through on Danny's recommendation to ground pin 24 of the ACIA pin to eliminate CTS as a potential factor.

Tom

[Mark]

Nice progress!
I looked at what was written to the ACIA port in WinOSI by setting a write breakpoint on $FC01in the Debugger/Monitor

Yes, by default PRINT#1,"anything": sends "anything<CR><LF>", tacking on the end of line characters.

To prevent automatic inclusion of <LF> you can use POKE 2684,44 in OS65D3.2+ to turn it off, however just as with standard print you can suppress the automatic end of line by appending a ";" in BASIC, as in:

Code: Select all

5 CTRL=64512: POKE CTRL,3:POKE CTRL,21:POKE 63235,52:REM SET ACIA & DCD
10 A$="A1"+CHR$(13)
20 PRINT#1,A$;:REM NO automatic EOL sent

This sends exactly the command you are looking for.

[bxdanny]

I'm pretty sure that the quoted MBASIC code from the manual would actually transmit FIVE characters, namely "A1" plus characters 13, 10, and 26 (<cr><lf><eof>). Certainly, in the CP/M and MS-DOS versions of MS BASIC, closing a disk file that was opened for Output appends the CHR$(26) end-of-file mark to the end, and I expect that the HDOS version will act the same way, and will not internally distinguish between "LP:" and a disk file. So it seems unlikely that suppressing the LF in the command string transmitted would make it work. It seems unlikely that adding the CHR$(26) would make it work either, but I guess both are worth trying.

Tom, can you measure what the voltages (for both high and low) are at the printer port output of the OSI? And what they are at the serial port output of the PC? Are they basically the same, with a true negative voltage coming from the OSI serial port? The 505B schematic shows that, by default, the output from the OSI swings only between +5V and ground, but that pads are provided to enable output to reach -9 volts. To get negative output, which some RS-232 devices require, you would need to cut W42 and connect W43 instead.

[Mark]

After looking at the sample code Try PRINT#1,"A1ON" or PRINT#1,"A1ON"+CHR$(13); after the normal pokes to get com working. - Perhaps the command was missing.

<back to original message>
Ooh, good call!

Turns out the Heathkit RS-232 input is just an opto-isolator, so it shouldn't care about voltages too much -- unless I'm mistaken, the opto is turned off during the space condition where the RS-232 would be negative, and on during the mark condition. (If not then a negative voltage is required!)

Full Schematic

RS232

heathkit.jpg (104.84 KiB) Viewed 14140 times

When connected to the OSI, measure the voltage at Heathkit U4 pin7/CPU pin 1. Then set an RS-232 BREAK condition with POKE 64512,117, you should see the voltage at pin 7 U4 go low. Return to normal with POKE 64512,21 where the voltage should be pulled high again to near 5v. If this works, then the signal is getting to the Heathkit.

If not then perhaps the OSI RS-232 +5v RS-232 mark voltage isn't high enough? The Heathkit R11 may need to be adjusted a bit lower if the 5V voltage isn't enough to trigger the opto. RS-232 can go to +/- 25V, but it usually only half that on vintage computing. The OSI looks to be +5V and 0V, unless jumpered as bxdanny mentioned.

I tried booting CPM 1.4 on WinOSI to see what BASIC LPRINT did -- turns out it uses the UART at $FB0x as I/O (which I had to map to that emulation), and it also adds <CR><LF> by default. The sample code in the heathkit docs adds <CR> and uses LPRINT; to stop automatic <CR><LF> - but the trailing ; was missing, so what it sent was "A1ON"<CR><CR><LF>

It seems you could jumper the Healthit for 300 baud, and use POKE 64512, 16 to set 300 baud on the OSI to slow things down

It really shouldn't be this hard.

[lowrybt1]

Thank for pursuing this further Danny and Mark.

I'll try sending the command words with the MBASIC terminating characters you identified, Danny. And I''ll check voltages all around. During the past day, I reconfigured the Heathkit for 300 Baud and checked/tested the ASCII command syntax and saw no impact. What I can say with confidence is this:

*The Heathkit behaves as it should when I send commands to it from CoolTerm running on my wintel laptop using the obligatory FTDI cable. These commands are terminated with a <CR> only.
* Likewise, the OSI serial port output (from modem and serial printer port) is received correctly by CoolTerm using the FTDI cable.
* When I send commands from the OSI serial port to the HeathKit unit using a plain-old 6ft long straight-thru serial cable, no joy.
* When I use the plain-old 6ft long straight-thru cable as an extension to the FTDI cable, command words sent from the OSI serial port reach CoolTerm intact, and command words sent to the Heathkit from CoolTerm have the desired effect.

I'm looking at the 505B schematics to get familiar with the locations of W42 and W43.

Tom

[lowrybt1]

Voltages

OSI serial port: 22mV, 4.78V with serial break toggled on
At pin 7 of Heathkit U4 optoisolator: 5.11V, 4.11V with OSI serial break toggled on

FTDI cable: -6.70V, 7.46V with serial break toggled on

TB