Setting Minicom up on linux...

[Ronny Ribeiro]

Hello, everyone!

Following some directions I've found here in this group and also elsewhere I managed to get serial communication working on my PAL (thank you for sharing!). For the task I'm using PuTTY on Ubuntu linux. Everything is working perfectly and I got 9600 bps speed going without issues.
However, I would like to try Minicom for the task, specially because I can copy and paste some commands direct to the prompt (Jeff Tranter shows a connection between his KIM-1 and Minicom on Ubuntu linux, here is the link: https://www.youtube.com/watch?v=97PccuhGl9w). But it's not working - it keeps spitting garbage. I'm using 2400 8N1 setting (2400 bps, 8 data bits, no parity, 1 stop bit) and no flow control. The group permissions for my user are set correctly (I checked).
Jeff uses 2 stop bits on his settings, which I tried without success.
I've searched the internet for some help but I couldn't find any thing specific.
Is any linux user here using Minicom who could give me some hint?
Any help would be very appreciated :)

Best Regards,

Ronny

[Jim McClanahan]

For cut and paste to work, you will need to set both the delay after each character as well as the delay at the end of the line. On mine, that is found at Control-A, Z, and then D for the "newline" delay or F for the character delay.

Different applications need different settings. For example, when I was working on PBUG and the port of eWoz, the monitors handle inputs of hex data differently. PBUG reads and stores each pair of characters for a hex digit immediately. So for it, the pause between characters needs to be long enough for it to do a little bit of processing. On the other hand, eWoz reads the keystrokes into a buffer and then processes the buffer. That means that the bulk of the work happens after the "newline".

So eWoz needed a longer newline delay than PBUG. BASIC is another example of something that will read things into a buffer and then process them--sometimes it can take a second for a line of BASIC to be parsed, move code around in memory if it needs to create space, and then put the tolkenized line in place.

So there is no "right" setting for the values and it can take some tweaking. If you start with 20 ms between characters and 500 ms with the newline, you probably will start getting better results. 

The KIM ROM only decodes 7 bits. ASCII serial is sent LSB first (after the start bit). That means that bits 0-6 are sent and then the KIM ROM's serial routine starts processing it. So the 8th bit isn't read but doesn't hurt anything at higher baud rates because of the delay before the KIM starts looking for the next character. (In effect, it is kind of a "delay" before the next start bit.) I think the recommendation is to use two stop bits. (Parity isn't used--that would just set the value of 8th bit (with is Bit 7 if you start counting at zero instead of one).)

I have also found that manually setting the time the KIM uses to watch for the next bit one lower than what the KIM measures on it's own helps improve serial reliability. (I think this is probably as much because that extra time it provides after reading the 7th bit is a bit like a pause between characters also.) The values for different baud rates are on my github readme for the PAL-1:

https://github.com/w4jbm/PAL-1-6502-SBC

There is also a bit of info in there about the delays for reading MOS format hex files.

One last hint with minicom is that I seem to have better luck with the "past file" option at Control-Z, A, Y than with just doing a regular cut an paste. It does mean you have to put what you want to copy into a file (which, for me, is usually the case anyway).

Thanks,

Jim

[GN L]

Hi Ronny,
Just for your reference, here is my minicom configuration file I'm currently using.

I think the baud rate setting to 1200 is more stable.

[Ronny Ribeiro]

Hi Jim and Liu,

Jim, thank you for your thorough reply - the information were very useful.
But I must tell you that was setting me back in connecting to Minicom was an unfortunate detail: to connect to PuTTY I was firstly hitting backspace to start the connection and what I discovered is that this doesn't work with Minicom, which will always spit garbage back. When I tried to send a character like "A" it worked! And now I realized that the system is much more reliable than I thought: using Basic, I manage to connect 9600 bps, 8 data bits, no parity, 2 stop bits and delays of 100 ms for lines and 4 ms for characters.
Liu, it was very kind of you to send me your Minicom config file, thank you!

So that is it! Minicom up and connected to PAL!

Thank you for the help,

Ronny

[GN Liu]

Hi Ronny,

Congratulations and happy hacking 6502~

and the duplicated post is deleted.

Best,

Liu