I'm still looking for my AC-30; as soon as I find it it's yours. See ya off-list...
m ----- Original Message ----- From: "Brad H" <vintagecompu...@bettercomputing.net> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk@classiccmp.org> Sent: Friday, August 12, 2016 9:17 PM Subject: Re: SWTPC 6800 > > > Interesting. I thought the CT-1024 was sort of the intended companion for the > 6800 (It came out first, I think). I wonder what they expected people to do > if they had just those two devices? > I'll probably try cable swap and see how onerous that is. I'm hoping to one > day acquire an AC-30.. of course then I'd need to find tape files... > Do you know of any good repository for the kind of loader files you can load > via serial? I've found a few here and there but not all of them. > > > Sent from my Samsung device > > -------- Original message -------- > From: Chris Elmquist <chr...@pobox.com> > Date: 2016-08-12 4:01 PM (GMT-08:00) > To: "General Discussion: On-Topic and Off-Topic Posts" > <cctalk@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 <pon...@update.uu.se> >> Date: 2016-08-11 11:27 PM (GMT-08:00) >> To: "General Discussion: On-Topic and Off-Topic Posts" >> <cctalk@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 <chr...@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 > >
