> > I then tried 7 N 1 (that's how my CT1024 terminal is set up). This time I > > got more consistent characters. If I hit reset, there is also a response. > > 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.
Am I the only person who rarely, if ever, has RS232 problems? I don't guess, I don't try things until it works. I make measurements and figure out how it must work. In this case, I would guess the serial chip is either a dumb UART (one of those 40 pin ones) or a 6850. Both have the advantage (here) of needing an external baud rate clock. So, stick a 'scope, frequency counter, LogicDart, whatever you use on the Transmit clock pin. Measure the frequency and remember that almost all serial chips need a 16* baud clock. So divide what you measure by 16, set that baud rate. Set 1 stop bit on the terminal. If the system sends 2, it won't matter. It's asynchronous, it's just an extra bit delay between characters. Try 8 bits, no parity. Most machines sent 8 bits, the high bit might be a parity bit. If some characters get through, others are corrupted into graphics-type things (extended character set) then work out if the high bit is being set on odd or even parity, and re-set the terminal to 7 data bits and the appropriate parity bit. If all else fails, stick a logic analyser on the Tx Data pin of the UART, trigger on the falling edge, and grab the bitstream as it comes out of the UART. See if you can make sense of it. -tony
