Dusting off my Processor Technology Sol-20

[Mike_Z]

Yes I turned XON/XOFF to none. I read in the Tera Term doc, the with that on it will stop XMODEM from sending. I also erased TERA TERM and downloaded it again from another source, but that didn't help. I can see the NAK's in the log file. Mike

 

[deramp5113]

Have you had logging enabled the whole time or only after you encountered problems? If the whole time, don’t use logging during the transfer.

Are you still running at 1200 baud? Bump up to 9600 and see what happens.

Mike

 

[Mike_Z]

Currently I have logging turned off. The log didn't seem to give enough information as to what the problem was. It did show that data and communication was working, but not why it stopped. I have increased the baud rate to 9600, with no change in behavior.

I was puzzled as to why after a number of packets transferred did TERA TERM close the TERA dialogue box and the transfer continued on the display? I believe that the transfer to the display was only one packet, the characters all looked the same and after 10 lines the transfer stopped. Suspecting TERA TERM I erased it and downloaded a new copy. No soap, same behavior. Then after looking around on the internet I found that EXTRAPutty could do XMODEM. I downloaded that, set it up and tried a transfer. It acted the same as TERA TERM. This, in my mind exonerated TERA TERM.

My next attempt at a transfer was to change disks. I was trying to transfer my newly made CP/M disk. So I tried my North Star DOS disk. Same behavior. Both of these attempts were in Drive #2. So I tried both disks in Drive #3, again same results. I figured that maybe some of the data being transferred was being interpreted as some kind of control signal to TERA TERM. To test that idea, I tried to transfer a blank newly formatted disk. This worked in both drives #2 and #3. The transfer was still slow, nearly 30 minutes was needed. But this had the benefit of telling me exactly how the transfer should work. First the SOL looks to the selected drive, copies 32K into memory and then transmits it. Once 360 packets are sent, the SOL stops reads the rest of the disk into memory and then continues the transfer. This was last night and at this point I was getting tired. I had planned to try and transfer a couple of text only files, ones that would not have any control characters in it, the next day.

This morning, before breakfast, I went down stairs to fire up the SOL and the XP machine. I wanted to see if I could still transfer a blank disk. It is cold in the basement, maybe 50°. I add the temperature, because I think it may be a factor. Anyway, after setting it up, to my amazement, the transfer started and zipped to conclusion in 2 minutes. I checked the capture file and it looked ok. So I loaded a North Star Dos disk and made the transfer again, it also worked. About 1/2 hour had pasted, the machine had warmed up, I tried the CP/M disk and it failed as it did yesterday. Then a try of the other disk and those failed also. I'm guessing that I have another connection problem. This time on the main CPU board? I started to remove the board to gain access to all the chips. I plan on reseating the chips, probably only a few at a time just in case something goes wrong and the entire machine stops.

Interestingly, I found on this board a hand painted serial number #01042. Thanks for the help, Mike

 

[deramp5113]

The content of the disk doesn't make any difference to the transfer, however, it could affect a failing UART. The UARTs used in the Sol-20 were unique in that they tended to fail in a mostly working condition instead of just failing completely. Also, I've found the socket connection for the UART to be mediocre in several Sol-20s I've restored.

I would first remove and reseat the UARTs in their sockets a few times and see if the problem goes away permanently. If not, swap the two UARTs (one is cassette, the other is serial port). If that fixes the problem, then you know the UART was bad.

MIke

 

[Hugo Holden]

When I got my SOL I had been reading a lot about intermittent behavior and these computers requiring regular fixes and like a lot of S-100 cards having intermittent issues and problems seeming to be temporarily fixed by re-seating IC's.

One thing is that PT and many of the S-100 card makers at the time used TI brand IC sockets that grip the pins from side to side over a very small surface area, rather than across the flat like most other dual wipe sockets. A grey or black crystalline oxide appears at the junction of the socket claw and the IC pin surface. You will see these fine lines under magnification if you remove some of the IC's. It must be completely removed from the surface for a reliable connection. It creates a resistance, but its oddly non-linear and it has diode like effects in some cases.

In one case where I was fault finding a 16kRA memory board (where I had not previously cleaned all the IC pins) I was able to see this effect on the scope. It was then I realized it was actually pointless to even bother fault finding a card, without cleaning up the IC pins first. It is a big job to clean up all the IC pins in the SOL, but if you don't you could be plagued with intermittent issues. 2000 grade paper works well to remove the oxide on the sides of the pins. A wash with contact cleaner also and I lubricate them too, with Inox's MX-3. It is also possible using a pin from a defunct IC soldered to a small wire handle to check the IC socket claw tension of every IC socket claw. I found some damaged ones due to previous brutal insertion of IC's. The IC pins often need to be straightened and formed so they line up with the socket entry holes, if not on the TI sockets they can either fold around (scroll up) or slip down beside the claw mechanism and create a very unreliable connection.

Also on that other issue I had with sometimes incomplete file transfers; it took me quite a while to work out it was a timing issue (my timing that is). Because there were varying delays between when I started the the program like PCGET in the SOL, to when I went to the other computer to initiate the transfer, therefore when it worked sometimes and not others I was baffled why. I knew my hardware was good as it happened with two separate disk controller cards, and I'm using NOS disk drives. Although in theory it should not do this, however, with regularity, if the data transfer is initiated after the disk drive times out in on the SOL, I always get an incomplete file transfer. If I do it before that time, the transfer is always 100% complete. As I mentioned I do not know the cause of this issue, but because it is such an easy work around I have not investigated it further. But if this was happening in your case, it could explain why you are successful sometimes with a file transfer and not others and the effect seems (like it did to me initially) random,
much like an intermittent hardware fault.

 

[Mike_Z]

Well.... first I made a list of all the chips that are on the I/O schematic. I thought that should cover this problem. Then one by one I removed each chip and cleaned it. I use some vinegar and scrub each chip with an old tooth brush, then flush it with clean water. A little hot air from a heat gun drys them nicely. Next I use a single edge razor blade and scrap the leads, then straighten them and finally re install them maybe 3 or 4 times. I disassembled the machine so that I could remove the main CPU board. Here I found that under the board there were self tapping screws sticking up and nearly touching the CB. These screws hold the power supply frame. I removed the screws and ground them down so now there is at least 1/8" between the board and the tip of the screws. I did not swap the UARTS. The IC sockets are TI, but the pin holders look like copper not the silver alloy the chip leads are. They don't look corroded. Other than inserting the chip into them a few times, I left them alone. Replacing them can be a problem, especially to the traces on the board.

Next, I tried a transfer and it worked, but the machine was still cold. I allowed the machine to warm up for 1/2 hour and then it failed in the same manner. So, I tried swapping the cassette and I/O UARTS. Again the transfer worked fine first try. While the machine warmed up, the dog and I went for a walk, since the weather has warmed into the 40's. That took an hour or so. I tried the transfer again and it worked as the first one did. I spent the rest of the afternoon transferring back and forth between the XP and the SOL, with no trouble. Must have made a couple dozen transfers. You seem to be correct about the UART failure mode. I looked up on eBay to see if I could get a replacement and sure enough some guy was selling them, so I ordered two.

With this under my belt, I want to now try the PCGET and PCPUT programs. They are in with the CP/M disk image. I thought that maybe I'll copy them to the North Start DOS disk and see if they also work there. Things are looking up, time will tell, Thanks for the help, Mike.

 

[deramp5113]

With this under my belt, I want to now try the PCGET and PCPUT programs. They are in with the CP/M disk image. I thought that maybe I'll copy them to the North Start DOS disk and see if they also work there. Things are looking up, time will tell, Thanks for the help, Mike.

Unlike PC2FLOP and FLOP2PC which I designed to run without needing an operating system, PCGET and PCPUT are CP/M programs. They will not execute properly under North Star DOS. I have not written single file transfer utilities for North Star DOS and I don't know of such utilities.

Mike

 

[deramp5113]

You seem to be correct about the UART failure mode. I looked up on eBay to see if I could get a replacement and sure enough some guy was selling them, so I ordered two.

That UART is made by several manufacturers under different part numbers. Compatible UARTS include AY-5-1012, AY-5-1013A, TMS6011, AMI S1883, COM2502, COM2502H, COM2017, Western Digital TR1402/1602/1863/1865, Intersil 6402.

Mike

 

[Hugo Holden]

That UART is made by several manufacturers under different part numbers. Compatible UARTS include AY-5-1012, AY-5-1013A, TMS6011, AMI S1883, COM2502, COM2502H, COM2017, Western Digital TR1402/1602/1863/1865, Intersil 6402.

Mike

That intermittent UART failure, is it with one particular type , such as the TMS6011 or does it happen with all of them ? I think some of the AY- types I have seen have ceramic bodies with metal caps and the TMS ones are plastic.

 

[deramp5113]

I've seen the partial failures with the AMI and the TI (TMS) parts because I've had equipment with those brands in them. I don't know whether the others are the same or not.

Mike

 

[Mike_Z]

For the record, the chips in my SOL-20 are AMI. The ones I purchased are TMS6011. I've been playing with PCGET and this program seems to work quite well. I'm currently attempting to get WordStar 3.0 installed. I use WordStar on my other CP/M machine instead of the Editor. One thing I noticed right away is how small these disk drives are, 87.5 KB. The 8" on my other CP/M machine are around 240 KB. Anyway I could just squeeze the needed files onto on disk. Now I have to find the correct video type so that the menus look correct. Mike

 

[Agent Orange]

This thread persists in "not read area" so I just attempting this to see if it goes parks itself.

 

[Mike_Z]

What???

 

[Hugo Holden]

For the record, the chips in my SOL-20 are AMI. The ones I purchased are TMS6011.Mike

So one of your AMI UART chips was definitely intermittent and the partial file transfer fault completely went away when you replaced it ?

This is really important information or a person could struggle for a very long time with a fault like that. It is a good thing Mike (Deramp) knew about this.

I have not seen it for a while, but I once had an .ENT file stop in the middle of a transfer for no obvious reason. At least if anything like this happens in the future I will know where to look.

 

[Agent Orange]

What???

After it was read it should not appear as being unread. So, I added a small blurb and it fix it at least in my account. It's okay now so do not get upset as it's nothing you did. It happens with this board every once in a while.

 

[Mike_Z]

I'm not upset, just confused. Thanks Mike

 

[redjr]

I'm dusting off my ole Sol-20 too. Just finished reading through this thread. Lot's of good information that I will likely rely on once I get mine fired up and something flashing. Will be working on the keyboard for awhile longer first. PSU is good, so that's a start. Only peripheral I have is a 5.25" floppy, but no disks. Are they still 'obtainable' (eBay)? Not even sure what type it is sector wise. Years ago I was using a North* compatible controller (and dual drives), and personality module from Micro Complex. Reliable stuff as I recall. Got the necessary software discussed here downloaded already. Hopefully, this thread will provide a 'guided tour' of some things I've long forgot and used about the Sol. Only roadblock is, I suffer from age related memory and recall issues as well.

 

[redjr]

Thanks Mike, I transferred FLOP2PC to the SOL successfully and it seems to work, at least I get similar screen messages as PC2FLOP. I'll try to transfer later.

From what I can tell, I have a monitor program called CONSOL which is 1K. My guess is that it doesn't have the cassette tape routines. Anyway it works for what I need.

It turns out that there is no hardware failure in My SOL-20. My problem, which I don't recall, is that the LOCAL key has to be OFF in order to send data from the SOL. With the LOCAL off I can use the TE command and type between the XP and the SOL just fine. I did slow the baud rate down to 1200. Unsure if that will help.

I tried to use PC2FLOP with REAL TERM and the XMODEM doesn't seem to function, the program just hangs. SO I moved back to TERA TERM. After starting PC2FLOP, I select drive 2 and port 1. The SOL looks on drive 2, maybe for space or format?. I then tried to send the CPM disk image. The transfer starts. I can see on TERA TERM that packets are being sent. At 1200 baud this takes a lot time, but once the transfer approaches 32K, the SOL stops and accesses Drive 2, supposedly to save the data. But then everything stops, the program doesn't restart and finish the transfer. The file is 48K. So I think I need to try a smaller file. maybe later, Mike.

Mike_Z, I know this thread is almost a yr old, but I thought I would ask anyway. What were your final settings in the terminal program you ultimately used to get a consist, reliable connection to the Sol-20? And what kind of cable were you using. I'm trying to go from a modern computer that does not have a 9-pin serial port, so I'm using a USB cable with a chip in it. Maybe that's my problem. have just about done every combination of terminal apps, baud rates, and keep coming up empty. I can usually get some characters on the Sol after going into TERM mode. But, they're just gibberish. I'm using the stock SOLOS module. After I SET I=1, nothing I copy-n-paste into the terminal app shows up at all. So, I thought I would try to mimic your software settings in hopes of getting a little closer to success!

 

[redjr]

Did you turn off XON/XOFF? This can cause problems in XMODEM which does its own packet by packet handshake with ACK/NAK.

Mike

The only terminal app I've been semi-successful with is MobaXterm. That one at least responses to my command, but with gibberish. I can't even get TeraTerm to respond using the SOLOS TE command. I am getting a warning message when I startup TeraTerm, about SSH. So not sure if that is hindering anything. I can dismiss it and TeraTerm starts up.

 

[redjr]

Sorry my attachments ended up in the wrong place!