SWTPC 6800

[Brad H]

Okay so I gave it a try.  As it turned out, I had a serial cable that had
both DB-25 and DB-9 heads at both ends.  So I thought I'd try using the
prolific USB to serial adapter I had here with my modern laptop so I could
easily download text files and run them. 

Yeah no.

The prolific cable allows you to set speeds as low as 110 but it does not
like them.  At 110 you just get garbage.  At 300, a prompt, but then
garbage.

There's no way to have both the MP-C and MP-S cards in the same machine and
have the computer connected to one at a faster rate of speed is there?

-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Chris
Elmquist
Sent: Friday, August 12, 2016 4:01 PM
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Subject: Re: SWTPC 6800

On Friday (08/12/2016 at 07:33AM -0700), Brad H wrote:
> 
>     
> I've a question.  I've now got my CT1024 working properly with my 6800..
is there an easy way to load txt loader files into it while it is still
connected to the CT?  Or do I have to load something in via PC first and
then swap cables?

The "usual" method in the day was that the paper tape reader on the
M33 teletype connected to the 6800 as the console was used to load your
s-records in through MIKBUG.  When you started the tape reader, it was just
like you were typing it on the TTY's keyboad.

Later, a cassette interface such as SWTPC AC-30 or the PERCOM CIS-30 was
used and it sat between the terminal's RS232 interface and the SWTPC's
console interface.   When you were loading a tape, the terminal got
disconnected (electrically) and the data coming off the tape was sent to the
console input of the 6800.

So, in simple terms, the cassette interface was in series with the terminal
and could preempt the terminal when loading from tape.  To save to tape, the
output from the 6800 would essentially go to both the tape and the terminal
at the same time.

The modern equivalent is probably an RS232 A/B switch that either connects
your CT-1024 or a PC to the 6800's console.  When you want to "load a tape"
you flip the switch so that the PC connects to the 6800 and sends the
s-records in.  After the load is complete, you flip the switch back and the
CT-1024 becomes the console.

You could also diode-OR the transmit data from the CT-1024 and a PC to the
6800's receive data input and wire the transmit data from the 6800's output
to both the CT-1024 and the PC but this might be sketchy depending
on the PC's RS232 interface characteristics.    But I have done this
successfully with other RS232 interfaces where I wanted two devices to be
able to send to one receiver without having to physically disconnect or flip
a switch.

Chris

> -------- Original message --------
> From: Pontus Pihlgren <pontus at Update.UU.SE>
> Date: 2016-08-11  11:27 PM  (GMT-08:00)
> To: "General Discussion: On-Topic and Off-Topic Posts" 
> <cctalk at classiccmp.org>
> Subject: Re: SWTPC 6800
> 
> 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

--
Chris Elmquist