• Please review our updated Terms and Rules here

Dusting off my Processor Technology Sol-20

As Mike said, the upper case and repeat does the reset. If you look you will find this results in a change in logic state on one pin at the keyboard connector, it is one of the dedicated keyboard output lines , like the control line outputs for the BREAK and LOCAL keys and there is also a STROBE output to tell the sol the keyboard data is ready, these dedicated control lines are independent of the ASCII codes generated by the keyboard.

It is odd that TeraTerm doesn't work, I have no trouble at all with it with my SOL. If a panel looks greyed out in Tera Term, with no options highlighted it usually means the serial link is not working properly. It might pay to get a proper Null Modem cable I use one with a 25-9 pin adapter. There is a thread about this recently. Have a read of it, there are lots of traps to fall into and some mistakes in the Sol manual too:

http://www.vcfed.org/forum/showthread.php?76942-Help-with-serial-interface-PC-to-Sol-20

especially have a look at post #11.

When the SOL and the computer are correctly hooked up with the serial link, if you type then TERM and SET I=1 on the Sol, it makes the Sol act like a terminal and everything you type on the sol should appear in the TeraTerm window and if you type on the computer it appears on the Sol's screen (it tests the link) and you can then use the Send file option in TeraTerm, to send files, like .ENT files to the Sol's RAM. To transfer .COM files and others .ASM .HEX etc to disk on the SOL requires PCGET.COM running on a working CP/M disk and it requests they are sent via the Xmodem option.
 
Last edited:
Mike_Z said:
Being optimistic I sent PC2FLOP.COM and executed 100H. The SOL hung. I then resent PC2FLOP.COM and checked what was in the memory addresses 100H etc. I only saw the first two characters 31 and 2E, the start of LXISP, the rest was not even close to what is in the file.
Click to expand...

The .COM file is a binary file, so whatever escape character you're looking for in the code you added to LOADER.ASM is most likely going to be in the data being received. If you left the escape character as the space (20h) you mentioned earlier, then a 20h in the data aborts reception at just 31 bytes into the .COM file. Everything after the 20h will just be whatever garbage was already in RAM. Of course you'll also want to be sure you chose 8 data bits in the serial port setup on TeraTerm and that the "Binary" option is checked in the send file dialog.

Mike_Z said:
no matter what I do I can't get XMODEM or Y or Z to work. I set the flow control to none. Once XMODEM is started, I get a window that shows the filename name and a box that would have elapsed time, but is grayed out. To get a file to transfer I use send file.
Click to expand...

I'm confused about this one. What file were you trying to send with XMODEM? If you're still at the first step of trying to get PC2FLOP into the Sol-20 so you can run it, then you don't have an XMODEM program running on the Sol-20 to receive the transfer. In this case, then what you saw is correct, an XMODEM transfer will just hang from the sender's side because there is not an XMODEM program running on the Sol to communicate with.

Mike_Z said:
I also compared the HEX file and the COM file and they both are the same (at least the first few characters), but different from what is sent
Click to expand...

Yes, the .HEX file contains the same data payload (in ASCII hex, of course) as the .COM file since they are simply two different representations of the same data. What do you mean by "but different than what is sent?" Do you simply mean the files are different than what you see received into memory due to the failed reception? Or did you have something to monitor the data being sent by Teraterm and the data sent by Teraterm is different than the file?

Mike_Z said:
Real Term and the SOL communicated and I have a copy of PC2FLOP on my SOL-20 disk
Click to expand...

I'm very confused, how did you get PC2FLOP onto a disk? Do you have a bootable disk running CP/M already and once PC2FLOP was in RAM you executed a SAVE command in CP/M? I was thinking you didn't have a boot disk of any sort.

Mike
 
Hugo, I don't know what I did wrong in TeraTerm, but I can be a pretty good poster for operator error sometimes. But I can't argue with success of Real Term. I'll take a look at your suggestion. What I find odd is that the trouble was only with the COM file, yet the ASCII text files seem to work. Have to think about it for a while.

Mike, I understand about the escape character. If a data character is the same as the escape character that would end the transfer. That is why I needed the RESET command. When the repeat/upper case is pressed the 8080 goes to address 0000. Here is where I placed a jump to C000 or console, infront of the LOADER code. That should (and did) avoid the escape character problem.

I read a little about XMODEM, I'm ignorant of the transfer programs. But now see that XMODEM would not work in this instance. Seems to work with packages of data. The receiver would need some special code.

I compared the HEX and COM files via a HEX editor program I have. Just to see if the first few bytes of the program are the same. Then this was compared to what the SOL-20 received from TeraTerm and saved at address 100 after a transfer. I only got the first two bytes correct on the SOL-20. Either the transfer stopped here or somehow the data was corrupted.

Getting the PC2FLOP to disk was the easiest part. After a good transfer using Real Term. I verified the code in the SOL at 0100H and ran it. Next I started DOS at E800, made a directory entry with CR, saved the code to the file using SF and then changed the file type using TY. I turned the SOL-20 off to clear everything, restarted it and could load and run PC2FLOP. Thanks for the help, Mike
 
Mike_Z said:
Hugo, I tried your TERM suggestion and do not get any results. First where should this command be entered? In CONSOLE, DOS or MONITOR? Mike
Click to expand...

This is a paragraph pasted from the Sol20.org site:


If you want to try and download these programs to your Sol, here's how to do it.

Grab the *.ent file you are interested from one of the tables below.
Connect a serial cable from your PC to your Sol
Set the baud rate, data bits, parity bits, and stop bits the same on the two machines. I have difficulty getting my Sol to transfer reliably if the baud rate is higher than 1200. YMMV.
Test that the link works. Use the TERM command to do so.
On the Sol, type "SET I=1". This makes it accept subsequent input from the serial port, as if you were entering it from the keyboard.
On the PC, transfer the *.ent file over the serial link as a straight ASCII file.
To run the program, type "EX xxxx", where xxxx is the load address, and off she goes!
Mike Douglas has having troubles getting ENT programs to load into his machine at 9600 baud. After puzzling over it a bit, he found that some .ENT files are saved with CR/LF line endings. He found that deleting the line feeds from the files and telling his term program (TerraTerm) to insert a 100 ms delay after each CR fixed it -- he could then reliably send data at 9600 baud. That 100ms is to give SOLOS enough time to scroll the screen after each line.



You just do it on the Sol , with Solos running in the usual way, after you have done a reset, or after the Sol is powered when it comes up with the usual cursor. The TERM command that you type on the Sol is just a good way to test the serial link and that it is working in both directions properly. As noted the SET I=1 command you type on the SOL, makes the SOL ready to receive a file to memory, typically a .ENT file that specifies the starting address and memory addresses that the file will get loaded to in the SOL's RAM. Sending a file to the SOL this way, with TeraTerm at least, the option to select is just "SEND" not the "transfer" options which include Xmodem. They are used when you want to transfer other file formats like .COM files etc.

When the .ENT file is sending, you will see the addresses and bytes appearing on the SOL's VDU, just as if somebody was typing them in at a high speed. So its easy to see that you got the whole file and it went to the correct addresses.
 
Last edited:
I spent some time looking over my documentation and I could not find anything regarding TERM. At last I found a one line statement "Terminal return to terminal mode" and nothing else. This is in the CONSOLE program. Nothing about SET. SO, I looked around the internet and found a book called SOLOS CUTER User Manual. In this there is more information about TE and SE. Actually it says you can set the port with TE 1 1. Once TE is entered you can not use the keyboard again to enter SET. Well...... I connected Real Term to the serial cable and did a TE. I could type on my XP machine and see the characters on the SOL. BUT typing on the SOL would not show on the XP machine. Closer inspection shows nothing was being sent over the cable from the SOL to the XP. I suspect there is a hardware failure on the transmit side of the SOL. I will have to look for the problem tomorrow.

One other question, the FLOP2PC doesn't have a COM file listed in your directory. DO I have to assemble this before I move it to the SOL?

Thanks Mike.
 
I spent some time looking over my documentation and could not find anything regarding TERM or SET. At last I found a one sentence statement "TErminal return to terminal mode". AND nothing else about TE and absolutely nothing about SET. So I looked around the internet and found a booklet called SOLOS CUTER User manual. Here there is more about these and other commands. My documentation call this program CONSOLE, whereas the User Manual calls this program SOLOS CUTER. Actually once the TE (not TERM) is entered, you can use the keyboard to enter a SET command, the SOL is already in the terminal mode. You can enter TE 1 1. The numbers set the in and out port numbers. Anyway, with the SOL in the terminal mode, I can type on the XP machine and see the text on the SOL, but typing on the SOL will not show up on the XP. I connected my scope to the SOL transmit line and there is nothing when I type on the SOL. There is a hardware failure somewhere inside the SOL. Tomorrow, I'll open it up and start to look for the problem. Thanks for the help, Mike
 
No, I don't believe I have a 2k SOLOS. My personality module only has one 2708 chip in it, the other socket is empty. So maybe I only have a subset of it? Mike
 
Mike_Z said:
No, I don't believe I have a 2k SOLOS. My personality module only has one 2708 chip in it, the other socket is empty. So maybe I only have a subset of it? Mike
Click to expand...

That sounds awkward, it is hard to know what you have then.

Ideally you would get another 2708 and erase and program both of them with the SOLOS file. Or you could buy a known good working module. I bought one of these to test it and it works perfectly:

https://www.ebay.com/itm/Processor-...249295?hash=item4b55df5e8f:g:pW8AAOSwdHpb9ovo

But its in AU and might take a while to get.

Here are some remarks I made in an article I wrote about the personality modules in the SOL:

Processor Technology made a number of hardware variants with different ROM IC’s on
them. One module, the subject of this article, had four UV Eproms, the MM5204 each
holding 512 bytes. This was the most physically attractive of the modules. Other
variants included a module with four 6834 IC’s, a module with two 2708 IC’s and yet
another module with only one 9216 ROM which contained the whole 2048 bytes.
The modules which had four IC’s used the 74LS155 as an address decoder, while the
2708/9216 module used a 74LS08 as the decoding was simpler.


(So double check that you don't have the 9216 IC and not the 2708, just in case, its odd that one 2708 is missing)
 
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.
 
Took a break for lunch and then tried again. First I checked each byte of PC2FLOP that I see in memory against the COM file. Looks OK. Then I set up the CPM22b14-48k-SDC-SOL.NSI file in TERA TERM XMODEM to send. Started PC2FLOP and watched the process. TERA TERM started to send. About half way through the transfer, it stopped and the SOL accessed Drive 2, I guess to write what it had received. Here is where everything stopped last time. This time, TERA TERM and the SOL picked right up and continued. Once TERA TERM completed the transfer, SOL again accessed Drive 2 and then said a successful transfer was made. Well, well, well! Probably operator error the first time!

My next question is how to access CPM? Do I need a boot loader or what? Maybe more tomorrow. Thanks Mike
 
GEEeezzzz...... I just moved the CP/M disk to drive 1 and typed in EX E800 and CP/M started. I think I have to take some time to play with this. Mike
 
Well.... that sure is neat! CP/M on the SOL-20 seems to work just as I remember it. But that is not the objective. I want to get this disk image transfer stuff to work. First thing is I want to try and duplicate how I transferred CP/M. I noticed that I have two CP/M files. CPM22-48K-35T.DSK which is 151K long and will not transfer and CPM22b14-48K-SDC-SOL.NSI which is 88K long and is the file that I can transfer.I tried to find the .DSK file in Mike's files but didn't. Anyway, I start with N* DOS running on the SOL, format drives 2 and 3, make sure LOCAL is turned off and entered GO PC2FLOP. Select drive 2, the SOL looks to #2. Start TERA TERM Select SERIAL, then on setup serial PORT = COM1, SPEED = 1200, DATA = 8 bits, PARITY = none, STOP BITS = 1, FLOW CTRL = XON/XOFF and no delays. Next select file menu, transfer, XMODEM and Send. Pick filename and open. The TERA TERM dialogue send box opens. Then on the SOL select port 1. The TERA TERM dialogue box starts to show packets sent. It takes 7 min 12 seconds (360 packets) and then the SOL stops to save the data to disk. After the save, SOL restarts the transfer. The entire transfer takes 13 minutes and 55 seconds 701 packets. AND to top it off the CP/M disk works.

Next I want to try going the other way. Get FLOP2PC into the SOL and see if it works as well. Thanks for the help, Mike
 
Mike_Z said:
I noticed that I have two CP/M files. CPM22-48K-35T.DSK which is 151K long and will not transfer
Click to expand...

"CPM22-48K-35T.DSK" is for the Micropolis disk controller running in the Sol-20, not the single density North Star controller. You MUST use the disk transfer utilities and the disk images from the appropriate directory that corresponds to your controller (e.g., North Star single-density controller, North Star double-density controller, Micropolis controller).

Mike_Z said:
I start with N* DOS running on the SOL, format drives 2 and 3, make sure LOCAL is turned off and entered GO PC2FLOP. Select drive 2, the SOL looks to #2. Start TERA TERM Select SERIAL, then on setup serial PORT = COM1, SPEED = 1200, DATA = 8 bits, PARITY = none, STOP BITS = 1, FLOW CTRL = XON/XOFF and no delays. Next select file menu, transfer, XMODEM and Send. Pick filename and open. The TERA TERM dialogue send box opens. Then on the SOL select port 1. The TERA TERM dialogue box starts to show packets sent. It takes 7 min 12 seconds (360 packets) and then the SOL stops to save the data to disk. After the save, SOL restarts the transfer. The entire transfer takes 13 minutes and 55 seconds 701 packets. AND to top it off the CP/M disk works.
Click to expand...

1) You do not have to format the disks ahead of time
2) You should change your Sol-20 and terminal emulator to 9600 baud and the transfer will only take a couple of minutes.
3) FLOW CTRL should be set to NONE.

Mike
 
Thanks Mike, sometimes, in my old age I don't pay as close attention as I should.

I formatted them to make sure the media I'm using doesn't have any bad sectors on them. My 40 year old media is not the greatest. In the beginning, when I started this, not during Adam and Eve, I used the 9600 baud and was having difficulty, but most likely for different reasons. I switched to 1200 baud after reading about someone who was having trouble at the higher speed. I'll try the 9600 again later. Apparently the XMODEM in TERA TERM will do the XON/XOFF and that setting in the serial port is not needed? I'll give it a try and see what happens. So far so good. I still want to try the FLOP2PC and the PCGET and PCPUT programs. Thanks Mike
 
Having trouble again. I transferred FLOP2PC to the SOL and I checked that all the code was transferred correctly. The program seems to run. The menu is similar to PC2FLOP. I select drive #2 and port #1. Start Tera Term. The SOL looks at drive #2 and then starts to send packets to Tera Term, but very slow. Sometimes 10 packets are sent, sometimes 20 to 50, but then suddenly the XMODEM dialogue box closes and the transfer continues on the display. After a while everything stops. I setup the XMODEM log and it shows that data was being transferred, I recognized the CP/M signon. But there is no clue as to why Tera Term closes the XMODEM box randomly. Right now I'm stumped. Mike
 
Perhaps not the same problem. I had some sort of similar difficulties to this with my setup with CP/M the N* double density controller, Teraterm and using Xmodem to send files to the Disk in the SOL.

I found that if I started the PCGET program in the SOL and waited too long before I sent the file from the XP computer in Xmodem mode, the controller timed out with no activity in the SOL. Then, oddly, only something like 1/2 the file got transferred. So now I have the program ready & selected in the Teraterm panel, as soon as I start PCGET, I send it within a few seconds from the XP computer and I never get this partial file transfer problem. I have no idea what causes that effect.
 
Mike_Z said:
The SOL looks at drive #2 and then starts to send packets to Tera Term, but very slow. Sometimes 10 packets are sent, sometimes 20 to 50, but then suddenly the XMODEM dialogue box closes and the transfer continues on the display. After a while everything stops. I setup the XMODEM log and it shows that data was being transferred, I recognized the CP/M signon. But there is no clue as to why Tera Term closes the XMODEM box randomly. Right now I'm stumped. Mike
Click to expand...

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

Mike
 
You must log in or register to reply here.
Back
Top