Dave Yes.. I tried 7 bits.. different parity settings, speeds etc. Couldn't

I'm also not sure if bad RAM or bad TTL etc could be contributing to just

but as with all problem solving, Conan Doyle had it right when he said "after eliminating the impossible, whatever is left, however improbable, must be the solution"

wrote:

I don't think I have the right baud rate at all... as I mentioned, my MSI 6800 has a very well labelled serial card and I set it to whatever baud rate I was going for, set my terminal up and it wouldn't work. It was only by accident that I discovered if I set the terminal to 9600 baud it worked. Some of the other switches worked at the speeds labelled but I think 1200 or whatever was 9600. So I wouldn't be surprised at all if this thing was modified beyond. I have the MP-S, and I have the previous owner's handwritten sticker with the baud rates for each of the 5 DIP switches.. and so I've got it set at what should be 300, but I have tried other baud rates up and down the line without success so far. Going up just produces longer strings of random characters. Going down produces less. I am using a 25 pin femaile to 9 pin female null modem cable. The 9 pin goes into my old Thinkpad 380 and the 25 pin I have jumpered. I followed the guide here: http://www.swtpc.com/mholley/HiTerm/MPS_to_DB25.pdf Now, I don't have a DB25 female connector I could solder wires to. So what I did was, where required to loop pin 4 to 5, I just took some jumper wire, and went from pin 4 to 5 on the female 25 pin (at the computer end), 6 to 20, 6 to 8, and so on. You can get two jumper wire pins into a single shaft so the connections are all good. But maybe it doesn't work that way, I know null modem cables are a bit different. In any event, wired as such, the terminal got nothing from the computer at all. In the event, I ended up reducing to having the MP-S set up per the instructions, and then just had the TX RX and ground connected from the card to the female connector. With that setup, I get a response, albeit garbled. I'm certain cabling is an issue here. I get a bit dyslexic with pins and understanding how things change on a cable like a null modem. -----Original Message----- From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Fred Cisin Sent: Friday, August 5, 2016 8:52 AM To: General Discussion: On-Topic and Off-Topic Posts < cctalk at classiccmp.org> Subject: RE: SWTPC 6800 That quote is often horribly abused. Diagnosis by elimination is inherently faulty. Beginners, and "experts", will often use it to justify ridiculous premises, "because I eliminated everything else", while not having truly eliminated some of the most basic possibilities. "It must be the carburetor, because everything else is new" usually meant that they had not gapped the points properly, or had the wrong firing order. 37? years ago, it took me 3 weeks to get ink on paper with a serial printing terminal and a TRS80, because I made stupid assumptions because I thought that I had eliminated . . . and didn't even realize that there was a bad connection between the serial interface and the rest of the Expansion Interface. Why do you think that you have the right baud rate? It might be 9600, but if it was expecting a printing terminal, then it might be 300, 150, 134.5, 110, 75 In spite of "standardization" (everybody has a unique one of their own), sometimes you run into some handshaking using signals besides DSR, DTR, RTS, CTS. Such as CD (8), CD2 (12)!, RI(22) "misuse of the standard"? absolutely. (using db25 pinout - BTW, a DE9 is not a DB9. A real DB9 consists of a DB shell with 1 thru 8 and 20) It can be frustrating. There is at least one documented fatality from the frustration of serial cabling. Guy took a printer and computer to store to get it cabled; after 6 weeks without success, he shot the tech. Joe Campbell was sure that was an urban legend, so he tracked down the case, and mentioned it in one of his books. I don't intend to ever do it again; I'm getting rid of my ARC Data Tek 9600 DTS-1. -- Grumpy Ol' Fred cisin at xenosoft.com

On 08/05/2016 02:15 PM, Brad H wrote: Well, 110 bps is a bit on the slow side--great for teletypes, not so much for video terminals.

And I am not aware of any USB serial adapters that do 110 bps. If anyone knows of any, post brand and model numbers.

If and when you get consistent characters, no matter how wrong, then it's time to look at the bit patterns of what you get V what you expect (is anybody around who knows?) Since, obviously, if consistent, then it might be right except for one or more bits stuck on or stuck off. Yes, it is frustrating.

No. ;-)

On Friday (08/05/2016 at 06:50PM +0000), tony duell wrote: > Am I the only person who rarely, if ever, has RS232 problems?

No. ;-)

On Fri, Aug 5, 2016 at 2:58 PM, Chris Elmquist <chrise at pobox.com> wrote: No, but I used to manufacture sync serial hardware and have deep knowledge of how async serial in general, and RS-232/EIA works in particular, and still have all the test gear from 30 years ago. I get why people find serial comms frustrating and do not take my experiences as "typical". I pretty much don't hook up anything new that isn't on a "traffic light". I have several - DE9-DE9 for modern stuff, and multiple DB25-DB25 for old and new stuff. *Mostly*, if you plug everything in and you get at least TxD and RxD to light up, you at least have figured out where the primary gozintas and gozoutas go and can stop adding null-modem adapters. Past that, you have to know if either end requires hardware handshaking and either plumb the right signals (vintage setup documentation is invaluable for this) or bridge the appropriate lines (documentation again) so that one or both sides _thinks_ there's hardware handshaking. If you defeat it, you might run into overrun conditions, but at least you should be able to establish basic comms and pass a few characters. To that end, you do have to match speeds on both sides, and the usual best place to start is 8-N-1 for data bits, parity, and stop bits. I've run into multiple situations where 7-E-1 or 7-N-1 is the right answer. With enough experience, the "baud barf" from mismatched speeds takes on an often recognizable pattern that can be used to quickly figure out what the speed ought to be, but lacking instrumentation like a serial analyzer or an oscilloscope, one can try "all the speeds" until cleartext comes through. I also try the speeds in "most popular order", 9600, 1200, 300, 2400, 4800, 19200, 600... in the hopes of saving time. Every once in a while, you run into some oddball stuff, like 9600/150, etc., split speeds from the days of timesharing setups where the CPU wanted to get data to the users as fast as possible but wanted to minimize input interrupts and more closely match the input flow to (slow) human typing speeds. This wasn't common with microcomputers, but I've seen it with PDP-11 and PDP-8 setups and isn't something to look for first, but it does exist and highlights how strange things can get if all you've ever done is plug a high speed modem into a PC for dial-up internet. One important tip about USB serial dongles (and some laptops DE9 serial ports) - I've had problems with some of them and 1970s gear because the EIA/RS-232C (1969) level specification is +5V to +15V for space (0) and -15V to -5V for mark (1) (with +/-3V min sensitivity) and a lot of old gear is expecting +/-12V and not happy with lower-voltage lines and thin wires that don't help signal losses. One case in particular was a 1977-era Bridgeport Series II CNC mill with a LSI-11/03 CPU and a lot of custom Bridgeport boards. Everyone else who tried to talk to the Bridgeport before me had zero success. I checked all the things on the list and finally pulled out the laptop and set up a Dell desktop which worked the first time. When connecting to pre-1982 gear, I'd definitely try it from a desktop if a laptop is just not working. Checking the lines with an oscilloscope could also help verify this what's giving the grief (I did not have one handy when we were trying to get that CNC mill working). In terms of serial analyzers, there are several types out there, and the ones that I've had the most time on are the HP 4951/4952 series. There are different models with different features, but if you are going to shop for one, ensure it comes with the "keyboard lid" because that's where the line drivers and serial connectors are. The large connector on the back goes to a "pod" that happens to snap on the front of the unit when the keyboard is flipped up. It's much easier to find the base units than loose pods, IME. Check which pod. I've seen many with DB25s, which is probably what you want, but I've also seen DC-37 connectors, and non-EIA (RS-232) level shifters. The good news is that among these different models, the pods should be interchangable, so if you end up picking up 2 units (not unusual) with different base capabilities (some have DC-150 cassette tape, some have 3.5" floppy, plus some minor differences) and only one has a DB25 EIA pod, you can at least migrate it between the units. I find the serial analyzers invaluable for snooping on the details of what's happening on the wire, but any analyzers I have seen have a handy "autoconfig" button to sniff traffic and configure the line for monitoring, so it's often a quick click to get all the parameters if you don't already know them. Where they really shine is looking for troubles at the application layer, debugging Kermit or XMODEM traffic that isn't working for any obvious reason. The advanced stuff you can do is to write programs for some analyzers to simulate a host or a client for software debugging or to reproduce a problem for deeper analysis - this is far beyond the usual "why can't I get this terminal working with this vintage machine" but when you need it, you need it. In summary, I start by scoping the line with an LED traffic light (swapping lines or making custom cables where necessary), then move on the speed and parity settings (and changing the easier-to-change end), then look deeper when the easy stuff doesn't work. Easy problems take minutes or less. Hard problems can take a long time to resolve. -ethan