SWTPC 6800

[Ethan Dicks]

On Fri, Aug 5, 2016 at 2:58 PM, Chris Elmquist <chrise at pobox.com> wrote:
> 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.  ;-)

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