----- 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.