SWTPC 6800

[Mike Stein]

----- Original Message ----- 
From: "Brad H" <vintagecomputer at bettercomputing.net>
To: "'General Discussion: On-Topic and Off-Topic Posts'" <cctalk at 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-bounces at 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 at 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.
>