SWTPC 6800

[Pontus Pihlgren]

Very interresting read, thank you Ethan.

/P

On Tue, Aug 09, 2016 at 10:55:54AM -0400, Ethan Dicks wrote:
> 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