• Please review our updated Terms and Rules here

Help with serial interface PC to Sol-20

It can be very frustrating getting the serial link working, for the first time at least.

If you go to the SOL-20 org site, the .ENT files are there , you just click on them and on my computer the file just appears on the VDU, you can save it or copy and paste it into notepad.

http://sol20.org/programs.html

When the serial link is not working, initially at least, there are a lot of variables that could stop it: Incorrect cable wiring, a hardware fault in the SOL ,including defective IC's and faulty DIP switches. Then there is incorrect settings of the switches in the SOL, or incorrect settings in Teraterm.

Since we know for a fact that the cable arrangement I posted works (at least with my computer with a real RS-232 serial port) and that Teraterm definitely works, you could try getting that cable arrangement, using a computer with a serial port (mine is just a 2004 vintage HP pavillion running XP) then try again, making sure that if you send a .ENT file you use the SEND option in Teraterm (not the TRANSFER option, Xmodem etc which is used for transferring .COM and .ASM files etc).

Then if that still does not work it would narrow it down to a hardware fault in the SOL, or incorrect switch settings in the SOL or a bad DIP switch, faulty IC , UART or transceiver IC track modifications, breakage etc .

My SOL did have a fault with one on the Serial transceiver IC's also it had a defective DIP switch, these transceiver IC's can get damaged by electrostatic discharges from long cables or voltage transients caused by hot plugging if the peripheral device does not have is common lines at ground potential.There are also reports of the UART's failing.

In any case, with the sol, its easy to put the scope on the input pin of the UART, to see if the data is arriving there. And using the TERM command, easy to see if the sol is able to send data to the "terminal" to confirm a two way link is working.
 
Managed to find a bit of time now...

There are multiple things that can go wrong with a 'simple' RS232 interface! For example:

1. Voltage levels.
2. Wiring.
3. Handshake.
4. Serial configuration.
5. Software.

Let me address each one in turn.

1. Voltage levels.

Older equipment (e.g. the SOL-20) generally (and I use that term a little loosely) adheres to the RS232 Standard for voltage levels. PCs and even more modern equipment don't. So linking a 'vintage' piece of equipment up with a piece of 'modern' equipment that claims compatibility to the RS232 Standard is just fraught with problems. You need to check the details of the voltage levels for each piece of equipment to ascertain the suitability.

2. Wiring.

I would initial stick with the 'transmit and pray' method. This means a three-wire interface consisting of 0V/GND, Transmit and Receive. The 0V/GND needs to be wired from the SOL-20 to the PC. Do not confuse GND/0V with shield. Sometimes they can be used interchangeably, other times not. In general (...) the transmit (TX) of one side will need wiring to the receive (RX) of the other. So the TX/RX should be 'crossed' between the SOL-20 and the PC. However, a word of waring, you can come across 'true' RS232-compliant equipment that is described as 'Data Terminal Equipment - DTE) and 'Data Communications Equipment - DCE) where the TX is actually receive and the RX is actually transmit! I would ignore this point for the moment and assume Transmit is really transmit and receive is really receive...

3. Handshake.

Handshake between the two computer systems can come in three forms:

1. None.
2. Hardware.
3. Software (XON/XOFF).

I would propose you use NONE for the time being (transmit and pray mode).

However, if you are going to use this mode - you need to ensure that one (or both) ends can be reconfigured to NOT use the hardware handshake mode. If this can't be done, then you have to resort to 'looping back' the hardware handshake signals on the offending end to make it 'think' that it has been given permission to transmit and that the remote end is present to send data to it. If hardware handshake is not used, the software method could be used (this is normally used on DEC equipment for example) where a particular character is sent from the receiver to tell the transmitter to stop sending. A separate character is then sent to resume data transmission when the receiver is happy. If both ends are using this mechanism - all is well. If one end is using this mechanism, the other end gets very confused! Make sure XON/XOFF support is not enabled at both ends.

4. Serial configuration.

Both ends of the communication link have to agree on the serial protocol in use. In the SOL-20 this is via DIP switches S2, S3 and S4. The default recommendation in the manual is S2 all OFF, S3 -4 ON all others OFF and S4 all OFF. This gives 300 BAUD, full duplex, 8 data bits, 2 stop bits and no parity. What are your switches set to out of interest? Whatever the SOL-20 switches are set to - this configuration must be entered on the PC end. There is still a potential inconsistency with the 'no parity' option though. Does this mean that the parity bit is present - but a 'no care' bit or does it mean that the parity bit is actually missing from the serial stream? The Standard is not exactly clear and some manufacturers/UARTs interpret it one way and others another.

5. Software.

The initial thing is to get at least basic and reliable communication in both directions between the SOL-20 and the PC.

I don't think that the SOL-20 default serial configuration of 300 BAUD is an accident. The manual states (I think) 1200 BAUD as being a maximum rate and that has also been reported by other users. I would (initially) stick with 300 BAUD and then (when you have it working reliably) increase it until it starts to fail and then dial the speed down again by 'one notch'...

There are also a few other 'configurable parameters' you should be aware of:

1. Intercharacter delay. The BAUD rate is how the UART communicates (at the hardware level). However, if you try to send characters at the maximum rate from a modern PC that can still overrun a vintage computer. Each character received has to be processed before the next one can be processed. If the sender sends the characters too fast, then this can result in data loss still. There is a box to configure the number of milliseconds between each character transmitted on the PC.

2. Interline delay. Likewise, some software buffers the characters and waits for a <RETURN> before processing the command contained on the line of characters. This may mean that the SOL-20 'goes deaf' after a <RETURN> and subsequent characters may be missed. This is what milliseconds/line parameter is.

I would initially set up the msec/char and msec/line parameters to something long and then dial them back to optimise the transfer times.

3. How is an 'end of line' determined? Is it a <CR> or a <LF> or a <CR><LF>? How is the file stored? Does it have a <CR> followed by a <LF> for example - both characters of which are transferred from the PC to the SOL-20? You have the option of the PC adding a <LF> to a <CR> - this would potentially make the character stream to the SOL-20 <CR><LF><LF> for an end of line. Will this make sense to the SOL-20 or upset it I wonder?

So, these are some things that can trip you up. Either way, the most important thing is to see how the SOL-20 switches are configured and work from there. Even more importantly IS TO DOCUMENT EVERYTHING YOU TRY IN A METHODICAL MANNER. If you just keep doing random things - you very quickly get confused. If you write down details of the configuration and the observed response you (a) know which configurations you have already tried that don't work and (b) you can review your notes over a glass of wine for patterns.

Hope this is of some help?

POSTNOTE: I would put both the PC and the SOL-20 into terminal emulation mode so that anything typed on the SOL-20 keyboard goes to the PC and should be displayed there and anything typed on the PC keyboard should be sent to the SOL-20 and displayed locally on the VDU. This will allow you to enter the complete ASCII character set at both ends and ensure they are correctly displayed at both ends. You could then try sending a file of known text from the PC to the SOL-20 and make sure it turns out correctly on the SOL-20 console. If this looks OK, next would be to try in console mode and download a program from the PC to the SOL-20. However, in this mode, you may have to lengthen the milliseconds/line to account for the SOL-20 SOLOS monitor 'doing something' with the received line of characters.

Dave
 
Last edited:
Thanks for for taking the time to reply with that well thought out explanation about serial communications. I think you covered all the basics. Maybe this should become a sticky.

I'm scraping everything I've done and trying a real COM port in lieu of the modern and more ubiquitous USB port. My modern day computer did not have a RS232 COM header on the mobo. So instead, I was trying to use a smart USB cable to DB25 connector, where I could wire the necessary pins accordingly. This may be the culprit of my basic connection - even though all the parameters/settings seemed ok.

I know TeraTerm has been the software of choice here so I'll stick to that app until I get it working. I think starting at 300 baud is a wise suggestion, and it did cross my mind, but I never tried it.

Hopefully, I will have some time later today or tomorrow to methodically try your suggestions to get a serial link working with my Sol.

BTW, years ago in my vague memory, being the geek that I was at the time, I purchased a RatShack Model 100 portable computer. At the time, I remember I was able to control the Sol from another room(easy chair) over the serial port using it. I can't recall, but I think it may have been limited to using 300 baud. I was using only three wires at the time TX, RX, and ground (telephone wire). And it worked! Slow as hell, but worked. Hope I can do a bit better(faster) with this latest connection, 40yrs later. :)

Rick
 
>>> Thanks for for taking the time to reply with that well thought out explanation about serial communications.

You're welcome.

It looks like (from the SOL-20 technical manual) that J1 has the requisite hardware handshake lines (RTS, CTS, CD, DTR etc.). However, J1 also has the 20 mA current loop signals on it, so you definitely want to make sure that J1 pins 11, 12, 13 and 23 does not have anything connected to them at all.

Implementing the hardware handshaking would be a useful 'next step' after you have got the three-wire interface to work reliably. The wiring builds upon what you have already done. I will have a look and see if SOLOS supports this mode of operation for the serial port.

EDIT1: Just found details of the parity bit. If it is disabled (via the switch) the serial bit stream does not contain a parity bit at all (the data bits are followed immediately by the stop bit(s)). So that answers that question. Make sure the PC matches with regard to the parity configuration in this case.

EDIT2: Found reference to the fact that SOLOS does not use the hardware handshakes at all. So you have to ensure that the transmitter runs slow enough so as to not overrun the receiver under all cases...

Dave
 
Last edited:
@Dave,

Very good pointers. I will start with the minimum and work my way up to faster baud rates to see what the Sol tolerates. In any event, I have a DB25 connector that me to move the pins around as necessary, so will help in troubleshooting. I'll make sure the pins with the 20mA on them are not connected.

Rick
 
Sounds like a plan.

J1 pin 2 is transmit data (SOL-20 to PC).
J1 pin 3 is receive data (PC to SOL-20).
J1 pin 7 is GND/0V.

No other pins should be required.

On an IBM-PC (assuming a 9-pin connector):

Pin 5 is GND/0V.
Pin 2 is receive data (SOL-20 to PC).
Pin 3 is transmit data (PC to SOL-20).

So (if I have my pinout data right) it is:

Pins 2-2 (SOL-20 to PC).
Pins 3-3 (PC to SOL-20).

J1 pin 7 with PC pin 5 (GND/0V).
 
With my SOL, using Teraterm I always use the 1200 Baud rate without problems, but I might have neglected to mention, in those two boxes on the panel in Teraterm, enter a 10mSec character and line delay. I figured that this would make sure the SOL could always keep up. Since I got into the habit of doing that, I'm not sure if I did not have those delays present whether the 1200 Baud rate might upset things.

So Dave's advice about getting it running at 300 Baud first is very sensible, but it might pay to put those two 10mS delay values in too, just in case.

Also, one final cat in the pigeons for the Sol serial link. There are some errors relating to the switch settings printed in the Sol's hardware manual. I documented these, I will have a look and post again.Or I will take a photo of the switches in my Sol that are set up and definitely work for 1200 Baud.
 
It would be nice to note any corrections in the manual if you can locate them. I've printed most of the pertinent parts. Noted about the 10ms. I think I'll add them ne6xt time I try. It was all yard today, so wasn't even in my shop.

Off-topic.... Just watched a good documentary title 'Above and Beyond' on Amazon Prime. It's a great inspiring story about one man during WWII. He's the stuff of legends in a small Belgium town - to this day. It's only 1-hour.

Back on topic. :)
 
1) Dave's post #46 for Sol-20 DB-25 to PC DB-9 pinout/wiring is correct.

2) The TE command will work fine at 9600 baud.

3) Sending a .ENT file works fine at 1200 baud without any inter-character or EOL delays.

4) If the .ENT file has only CR at the end of each line (no LF), then you can send the file at 9600 baud as long as you specify a 100ms delay after each line (make sure CR is set as the "New Line" character in TeraTerm). This gives time for the screen to scroll. I've placed a few .ENT files with the LFs removed at https://deramp.com/downloads/process...are/sol20.org/. Look for files with "(no LFs)" in the file name.

5) Note that the "SET I=1" command aborts back to normal keyboard input on any error. This includes any command typo (including lower case instead of uppercase letters) as well as tripping up on a residual character left in the UART from a previous operation. You'll find yourself having to often re-issue the "SET I=1" command anytime you see "?" pop up on the screen.

6) If you're still having problems, note the UARTs used in Sol-20 are notorious for failing in a mostly-working state. This can make diagnosis difficult. You may try swapping the cassette and serial interface UARTs and see if the problem follows the UART.

Mike
 
I'm not sure how you are going with the SOL serial Link.

I have attached a picture of the switch settings in my SOL that work for a 1200 Baud, 8 bit word, no parity, one stop bit set up with Tera Term.

Only two of the switches need to be switched on.

(as can be seen the actual switches are replacement types in my SOL, Omron, that plug into DIL sockets, because the original switches in my sol had become defective. But yours are probably ok as your computer has likely been stored very well).
 

Attachments

  • switches.jpg
    switches.jpg
    122.8 KB · Views: 1
Thanks for the info Hugo. I've been busy with other things and haven got back to my Sol. Tomorrow I plan on getting the testing back on track.
 
You must log in or register to reply here.
Back
Top