----- Original Message ----- From: "Brad H" <vintagecompu...@bettercomputing.net> To: "'General Discussion: On-Topic and Off-Topic Posts'" <cctalk@classiccmp.org> Sent: Wednesday, August 17, 2016 7:02 PM Subject: RE: SWTPC 6800
... > If you have two serial devices on the same line and one is just listening > while you work with the other, *can* that work, or would it just confuse > things? Google "RS232 splitter"; usually all it takes is paralleling the terminal RXDs so that the computer sends to both, and a couple of diodes to isolate the TXDs from each other so that a positive space from the 'active' terminal doesn't argue with a negative mark from the inactive one. m ================================================================ > Thanks guys. > > I think I'll have to figure out here how to get my laptop and the CT1024 > working in tandem with this 6800. I mean, I could solve all of this by > simply using the PC terminal only, I know that works.. but, it just doesn't > have that vintage 'feel' to it that the CT does, esp. as I'm using it with > an old Sanyo B/W 9" monitor. > > If you have two serial devices on the same line and one is just listening > while you work with the other, *can* that work, or would it just confuse > things? What I have is a serial cable that has two heads at each end.. for > adaptability purposes -- at each end is a female DB25 and female DB9. So > It's possible to hook up the PC terminal to the DB9 and the CT1024 to the > DB25 at the same time at the one end. > > -----Original Message----- > From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Brent > Hilpert > Sent: Wednesday, August 17, 2016 3:27 PM > To: General Discussion: On-Topic and Off-Topic Posts <cctalk@classiccmp.org> > Subject: Re: SWTPC 6800 > > On 2016-Aug-17, at 11:48 AM, william degnan wrote: >>> Bill's method, of executing an M command from a text file, achieves >>> the same thing: filling memory. >>> Something it's missing versus the S-record/loader format method is a >>> checksum or any data check. >>> One may may not be concerned about line noise over a short RS-232 >>> line, but if there are problems like dropped characters, receivers >>> overruns, framing errors, etc., due say to speed or line config >>> issues the M command method isn't going to tell you about it, while >>> the S-record method will/should (in most cases) report a data error. >>> >>> >> My instructions suggest one use a character delay. I found that the >> monitor program will bomb if it gets its instructions too fast anyway. >> For the OP, I felt this was the simplest straight-forward method to >> get TSC BASIC running. I tested and documented the process, worked >> for me very reliably and it eliminiates the need to do anything other >> than get to the monitor prompt to work. > > No doubt you can get it to work, and it can be a useful ability in some > situations. > But monitors and loaders tended to be written with different objectives. > > Monitors targetted interactive use, not receipt of back-to-back characters, > which would be why you have to add per-char delays. > The monitor is likely dropping a character or starting a read in the middle > of one and getting garbage because it went away for too long while looking > up the command. > It only has the stop bit period, or even less time, to do processing after > receipt of a character. > > Loaders expect back-to-back characters and are written or optimised > accordingly, not that one can't still run into problems, which is why the > checksums can be good. >