12 Aug
2016
12 Aug
'16
10:33 a.m.
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?
Sent from my Samsung device
-------- 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:
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
Am I the only person who rarely, if ever, has RS232 problems?
No.? ;-) 
12 Aug
12 Aug
7:01 p.m.
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
10:39 p.m.
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
13 Aug
13 Aug
12:39 a.m.
On 2016-Aug-12, at 7:39 PM, Brad H wrote:
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?
As far the hardware goes, yes, you can have both cards in there operating at different
speeds.
Your problem is getting SWTBUG to use the alternative serial card (port) for the loader
command, rather than the console port.
To my recollection it (SWTBUG) is not programmed to provide for that.
I have a vague recollection of some monitor that allowed one to redirect the I/O port for
the subsequent command or something like that
but it was probably for some other machine (don't have the command list for SWTBUG at
hand).
So you could modify SWTBUG (typically with hand-assembled patches) and add a new facility
and
burn a new EPROM to give you a monitor tailored for your system config.
Welcome to the world of hobbyist computing, 1976.
16 Aug
16 Aug
12:09 p.m.
Another question if I may -- for a short TXT loader file.. could I manually
enter the information contained therein with my terminal? I'm just thinking
for a quick memory test, etc -- it'd be six of one half a dozen of the other
in terms of time to hook up a PC terminal and send the file..
If I were to hit L to put the 6800 into load mode, could I then just type
out the contents of the loader file with the CT1024's keyboard?
12:28 p.m.
Yes, the monitor just sees bytes coming at it, it can't distinguish whether
they're typed or coming from a host/machine,
as long as the byte sequence accords with the Motorola S record format.
You can formulate your own S records and type them at the monitor, too.
On 2016-Aug-16, at 9:09 AM, Brad H wrote:
Another question if I may -- for a short TXT loader
file.. could I manually
enter the information contained therein with my terminal? I'm just thinking
for a quick memory test, etc -- it'd be six of one half a dozen of the other
in terms of time to hook up a PC terminal and send the file..
If I were to hit L to put the 6800 into load mode, could I then just type
out the contents of the loader file with the CT1024's keyboard?
12:55 p.m.
Thanks Brent. So when I hit the end of an 'S' record line.. is it just a
Line Feed I need to go to the next? Or just type the next S record right in
behind it?
Also curious about how you type S records at the monitor prompt. I'm
reading and trying to figure out how to do that.
Many thanks!
Brad
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Brent
Hilpert
Sent: Tuesday, August 16, 2016 9:29 AM
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Subject: Re: SWTPC 6800
Yes, the monitor just sees bytes coming at it, it can't distinguish whether
they're typed or coming from a host/machine, as long as the byte sequence
accords with the Motorola S record format.
You can formulate your own S records and type them at the monitor, too.
On 2016-Aug-16, at 9:09 AM, Brad H wrote:
Another question if I may -- for a short TXT loader
file.. could I
manually enter the information contained therein with my terminal?
I'm just thinking for a quick memory test, etc -- it'd be six of one
half a dozen of the other in terms of time to hook up a PC terminal and
send the
file..
If I were to hit L to put the 6800 into load mode, could I then just
type out the contents of the loader file with the CT1024's keyboard?
1:12 p.m.
Brad,
You don't type in S1 records at the monitor prompt. If anything you'd want
to download a text file that simulates monitor commands to load memory,
but it's a lot slower.
I haven't been reading all of the posts in this thread, but have you tried
following something like the instructions here to download a tape, I have
documented how to use a terminal to download TSC BASIC into an SWTPC using
a laptop serial port (or USB to Serial):
http://vintagecomputer.net/browse_thread_record.cfm?id=416&tid=2
b
On Tue, Aug 16, 2016 at 12:55 PM, Brad H <
vintagecomputer at bettercomputing.net> wrote:
Thanks Brent. So when I hit the end of an 'S'
record line.. is it just a
Line Feed I need to go to the next? Or just type the next S record right
in
behind it?
Also curious about how you type S records at the monitor prompt. I'm
reading and trying to figure out how to do that.
Many thanks!
Brad
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Brent
Hilpert
Sent: Tuesday, August 16, 2016 9:29 AM
To: General Discussion: On-Topic and Off-Topic Posts <
cctalk at classiccmp.org>
Subject: Re: SWTPC 6800
Yes, the monitor just sees bytes coming at it, it can't distinguish whether
they're typed or coming from a host/machine, as long as the byte sequence
accords with the Motorola S record format.
You can formulate your own S records and type them at the monitor, too.
On 2016-Aug-16, at 9:09 AM, Brad H wrote:
Another question if I may -- for a short TXT
loader file.. could I
manually enter the information contained therein with my terminal?
I'm just thinking for a quick memory test, etc -- it'd be six of one
half a dozen of the other in terms of time to hook up a PC terminal and
send the
file..
If I were to hit L to put the 6800 into load mode, could I then just
type out the contents of the loader file with the CT1024's keyboard?
1:18 p.m.
On Tue, Aug 16, 2016 at 1:12 PM, william degnan <billdegnan at gmail.com>
wrote:
Brad,
You don't type in S1 records at the monitor prompt. If anything you'd
want to download a text file that simulates monitor commands to load
memory, but it's a lot slower.
I haven't been reading all of the posts in this thread, but have you tried
following something like the instructions here to download a tape, I have
documented how to use a terminal to download TSC BASIC into an SWTPC using
a laptop serial port (or USB to Serial):
http://vintagecomputer.net/browse_thread_record.cfm?id=416&tid=2
b
>
NOTE - the method linked-to above describes how to download a script into
the SWTPc's ROM monitor that mimics the keystrokes that one would normally
have made manually type from a terminal. Takes a few minutes, but it
works. You can call it a headless bootstrap.
b
7:20 p.m.
Okay this is where I was getting a bit confused -- I had gotten the impression that S1
records were essentially what was punched out on paper tape and that on loading back in,
the teletype/paper tape reader was simply typing all this in as if someone was sitting
there. Looking at your TSC Basic file I see it invokes the memory examine and change
function with the M and then starts at an address and just keeps going?
So when you had a program saved to a tape, these would have been S1 records encoded in
Kansas City format?
Is there a large collection of these loader files somewhere? Or like a definitive list of
major software developed for the 6800?
I'm hoping to learn more on how to program these things -- I'm assuming there was
an assembler people used rather than just modifying memory addresses?
Thanks
Brad
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of william degnan
Sent: Tuesday, August 16, 2016 10:12 AM
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Subject: Re: SWTPC 6800
Brad,
You don't type in S1 records at the monitor prompt. If anything you'd want to
download a text file that simulates monitor commands to load memory, but it's a lot
slower.
I haven't been reading all of the posts in this thread, but have you tried following
something like the instructions here to download a tape, I have documented how to use a
terminal to download TSC BASIC into an SWTPC using a laptop serial port (or USB to
Serial):
http://vintagecomputer.net/browse_thread_record.cfm?id=416&tid=2
b
On Tue, Aug 16, 2016 at 12:55 PM, Brad H < vintagecomputer at bettercomputing.net>
wrote:
Thanks Brent. So when I hit the end of an 'S'
record line.. is it
just a Line Feed I need to go to the next? Or just type the next S
record right in behind it?
Also curious about how you type S records at the monitor prompt. I'm
reading and trying to figure out how to do that.
Many thanks!
Brad
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Brent
Hilpert
Sent: Tuesday, August 16, 2016 9:29 AM
To: General Discussion: On-Topic and Off-Topic Posts <
cctalk at classiccmp.org>
Subject: Re: SWTPC 6800
Yes, the monitor just sees bytes coming at it, it can't distinguish
whether they're typed or coming from a host/machine, as long as the
byte sequence accords with the Motorola S record format.
You can formulate your own S records and type them at the monitor, too.
On 2016-Aug-16, at 9:09 AM, Brad H wrote:
Another question if I may -- for a short TXT
loader file.. could I
manually enter the information contained therein with my terminal?
I'm just thinking for a quick memory test, etc -- it'd be six of one
half a dozen of the other in terms of time to hook up a PC terminal
and
send the file..
If I were to hit L to put the 6800 into load mode, could I then just
type out the contents of the loader file with the CT1024's keyboard?
11:28 p.m.
I don't believe anyone else has ever posted an SWTPC - specific monitor
script like I posted on my site designed for the specific purpose of
feeding monitor commands to load TSC BASIC via text file. You just have to
follow my directions exactly. Doing so will change swtpc monitor prompt to
a > prompt. Essentially what my script does is load a papertape stripped
with only the raw data. Try it.
B
On Aug 16, 2016 7:21 PM, "Brad H" <vintagecomputer at
bettercomputing.net>
wrote:
Bill Degnan
twitter: billdeg
vintagecomputer.net
Okay this is where I was getting a bit confused -- I had gotten the
impression that
S1 records were essentially what was punched out on paper
tape and that on loading back in, the teletype/paper tape reader was simply
typing all this in as if someone was sitting there. Looking at your TSC
Basic file I see it invokes the memory examine and change function with the
M and then starts at an address and just keeps going?
So when you had a program saved to a tape, these would have been S1
records encoded
in Kansas City format?
Is there a large collection of these loader files somewhere? Or like a
definitive
list of major software developed for the 6800?
I'm hoping to learn more on how to program these things -- I'm assuming
there was an assembler people used rather than just modifying memory
addresses?
Thanks
Brad
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of william
degnan
Sent: Tuesday, August 16, 2016 10:12 AM
To: General Discussion: On-Topic and Off-Topic Posts <
cctalk at
classiccmp.org>
Subject: Re: SWTPC 6800
Brad,
You don't type in S1 records at the monitor prompt. If anything you'd
want
to download a text file that simulates monitor commands to load
memory, but it's a lot slower.
I haven't been reading all of the posts in this thread, but have you
tried
following something like the instructions here to download a tape, I
have documented how to use a terminal to download TSC BASIC into an SWTPC
using a laptop serial port (or USB to Serial):
http://vintagecomputer.net/browse_thread_record.cfm?id=416&tid=2
b
On Tue, Aug 16, 2016 at 12:55 PM, Brad H <
vintagecomputer at
bettercomputing.net> wrote:
Thanks Brent. So when I hit the end of an
'S' record line.. is it
just a Line Feed I need to go to the next? Or just type the next S
record right in behind it?
Also curious about how you type S records at the monitor prompt. I'm
reading and trying to figure out how to do that.
Many thanks!
Brad
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Brent
Hilpert
Sent: Tuesday, August 16, 2016 9:29 AM
To: General Discussion: On-Topic and Off-Topic Posts <
cctalk at classiccmp.org>
Subject: Re: SWTPC 6800
Yes, the monitor just sees bytes coming at it, it can't distinguish
whether they're typed or coming from a host/machine, as long as the
byte sequence accords with the Motorola S record format.
You can formulate your own S records and type them at the monitor, too.
On 2016-Aug-16, at 9:09 AM, Brad H wrote:
Another question if I may -- for a short TXT
loader file.. could I
manually enter the information contained therein with my terminal?
I'm just thinking for a quick memory test, etc -- it'd be six of one
half a dozen of the other in terms of time to hook up a PC terminal
and
send the file..
If I were to hit L to put the 6800 into load mode, could I then just
type out the contents of the loader file with the CT1024's keyboard?
17 Aug
17 Aug
4:31 a.m.
Lets start with the easy bits. A quick google turned up some zips of S9 software but not
sure if its 6800 or 6809....
http://www.flexusergroup.com/flexusergroup/fug5.htm
Now S1 records vsus using the monitor.
If you are just typing yourself then getting a whole S1 record correct can be a problem.
Using the Monitor memory modify lets you change a byte at a time and go back if you made a
mistake.
When you saved to papertape or Audio Cassette (there were a number of formats as well as
Kanasas City) You generally got S1 records.
Dave
G4UGM
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Brad H
Sent: 17 August 2016 00:20
To: 'General Discussion: On-Topic and Off-Topic Posts'
<cctalk at classiccmp.org>
Subject: RE: SWTPC 6800
Okay this is where I was getting a bit confused -- I had gotten the impression
that S1 records were essentially what was punched out on paper tape and
that on loading back in, the teletype/paper tape reader was simply typing all
this in as if someone was sitting there. Looking at your TSC Basic file I see it
invokes the memory examine and change function with the M and then
starts at an address and just keeps going?
So when you had a program saved to a tape, these would have been S1
records encoded in Kansas City format?
Is there a large collection of these loader files somewhere? Or like a
definitive list of major software developed for the 6800?
I'm hoping to learn more on how to program these things -- I'm assuming
there was an assembler people used rather than just modifying memory
addresses?
Thanks
Brad
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of william
degnan
Sent: Tuesday, August 16, 2016 10:12 AM
To: General Discussion: On-Topic and Off-Topic Posts
<cctalk at classiccmp.org>
Subject: Re: SWTPC 6800
Brad,
You don't type in S1 records at the monitor prompt. If anything you'd want
to download a text file that simulates monitor commands to load memory,
but it's a lot slower.
I haven't been reading all of the posts in this thread, but have you tried
following something like the instructions here to download a tape, I have
documented how to use a terminal to download TSC BASIC into an SWTPC
using a laptop serial port (or USB to Serial):
http://vintagecomputer.net/browse_thread_record.cfm?id=416&tid=2
b
On Tue, Aug 16, 2016 at 12:55 PM, Brad H <
vintagecomputer at bettercomputing.net> wrote:
> Thanks Brent. So when I hit the end of an 'S' record line.. is it
> just a Line Feed I need to go to the next? Or just type the next S
> record right in behind it?
>
> Also curious about how you type S records at the monitor prompt. I'm
> reading and trying to figure out how to do that.
>
> Many thanks!
>
> Brad
>
> -----Original Message-----
> From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Brent
> Hilpert
> Sent: Tuesday, August 16, 2016 9:29 AM
> To: General Discussion: On-Topic and Off-Topic Posts <
> cctalk at classiccmp.org>
> Subject: Re: SWTPC 6800
>
> Yes, the monitor just sees bytes coming at it, it can't distinguish
> whether they're typed or coming from a host/machine, as long as the
> byte sequence accords with the Motorola S record format.
>
> You can formulate your own S records and type them at the monitor, too.
>
>
>
> On 2016-Aug-16, at 9:09 AM, Brad H wrote:
>
> > Another question if I may -- for a short TXT loader file.. could I
> > manually enter the information contained therein with my terminal?
> > I'm just thinking for a quick memory test, etc -- it'd be six of one
> > half a dozen of the other in terms of time to hook up a PC terminal
> > and
> send the file..
> >
> > If I were to hit L to put the 6800 into load mode, could I then just
> > type out the contents of the loader file with the CT1024's keyboard?
>
>
11:56 a.m.
On 2016-Aug-16, at 9:55 AM, Brad H wrote:
Thanks Brent. So when I hit the end of an 'S'
record line.. is it just a
Line Feed I need to go to the next? Or just type the next S record right in
behind it?
Either should be OK, an S record is terminated by the number of bytes in the byte count
field and
the monitor should be ignoring CR/LF in-between S records.
Also curious about how you type S records at the
monitor prompt. I'm
reading and trying to figure out how to do that.
In the same manner as being discussed, after starting an L command.
You typically aren't going to want to formulate your own S records other than as an
exercise,
the point was just that it is possible - it's all just ASCII text.
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.
Many thanks!
Brad
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Brent
Hilpert
Sent: Tuesday, August 16, 2016 9:29 AM
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
Subject: Re: SWTPC 6800
Yes, the monitor just sees bytes coming at it, it can't distinguish whether
they're typed or coming from a host/machine, as long as the byte sequence
accords with the Motorola S record format.
You can formulate your own S records and type them at the monitor, too.
On 2016-Aug-16, at 9:09 AM, Brad H wrote:
Another question if I may -- for a short TXT
loader file.. could I
manually enter the information contained therein with my terminal?
I'm just thinking for a quick memory test, etc -- it'd be six of one
half a dozen of the other in terms of time to hook up a PC terminal and
send the
file..
>
> If I were to hit L to put the 6800 into load mode, could I then just
> type out the contents of the loader file with the CT1024's keyboard?
2:48 p.m.
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.
Bill
6:26 p.m.
On 2016-Aug-17, at 11:48 AM, william degnan wrote:
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.
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.
7:02 p.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:
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.
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. 
7:10 p.m.
On Wed, 17 Aug 2016, Brad H wrote:
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.
How about cabling the laptop to the SWTPC, and cable the CT1024 to the
laptop (with 2 serial ports)
Write some trivial software for the laptop to take characters from the
SWTPC and echo them to the CT1024, as well as taking characters from the
CT1024 and echoing them to the SWTPC. Then you can use the CT1024, and
ignore the laptop "middle-man", except when you want to use the laptop as
a file transfer device.
9:22 p.m.
----- 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:
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.
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.
11:26 p.m.
>
> 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.
It would be a lot easier if everyone picked top or bottom posting when they
reply but I digress....
My suggestion to use the "monitor method" is a stop-gap just to get to the
point of loading in something useful when no other means was workinhg. I
agree any process that has no checksum will be unreliable. Whatever.. .
Let's say for now you have at least the monitor method until something
better comes along.
As far as splitters for serial, they're plentiful on ebay...serial switch
boxes that is. If you set your modern terminal sodtware to match the same
settings as the swtpc vintage terminal you would be able to switch between
them. I sometimes load in programs using a modern terminal to download a
papertape into the computer then switch to a vintage terminal for use.
Simple...assuming you can get your modern machine to match the vintagr, and
you have the cables. Otherwise you'll have to buy/make them.
Bill
18 Aug
18 Aug
12:08 a.m.
On 2016-Aug-17, at 8:26 PM, william degnan wrote:
Yes, we've had that debate a few times.
AIR, it was decided that bottom-posting was the 'list practice'.
> 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.
It would be a lot easier if everyone picked top or bottom posting when they
reply but I digress.... My suggestion to use the "monitor method" is
a stop-gap just to get to the
point of loading in something useful when no other means was workinhg. I
agree any process that has no checksum will be unreliable. Whatever.. .
Let's say for now you have at least the monitor method until something
better comes along.
But as far as MIKBUG/SWTBUG goes, you also always have the "L" command with
S-record method.
If the data in your TSC BASIC "M" text were converted to S-record format - a
trivial programming exercise -
it would be easier (no delays required) (and more reliable) to load into the SWTP.
They're both ASCII text input, just different formats.
I'm not clear why you resorted to the M-command method, was the TSC BASIC data not
originally
in S-records? - that would be the standard format for loading such software into an SWTP.
7:46 a.m.
On Aug 18, 2016 12:08 AM, "Brent Hilpert" <hilpert at cs.ubc.ca> wrote:
the
with S-record method.
The regular S1 tape exists in a few places, yes use L to load tape. This
is the best practice.
Purely as an experiment I made a monitor script so I could run at a slow
speed so I could watch the screen as commands were entered. I can't
remember if it was because the load (L) was not working or if there was a
cpu card issue.
I thought as a first step, given at the time in the flow of the thread the
OP was having issues, my monitor script would be worth trying.
Bill
On 2016-Aug-17, at 8:26 PM, william degnan wrote:
>>> 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.
>
> It would be a lot easier if everyone picked top or bottom posting when
they
reply but I
digress....
Yes, we've had that debate a few times.
AIR, it was decided that bottom-posting was the 'list practice'.
> My suggestion to use the "monitor method" is a stop-gap just to get to
> point of loading in something useful when no
other means was workinhg.
I
agree any
process that has no checksum will be unreliable. Whatever.. .
Let's say for now you have at least the monitor method until something
better comes along.
But as far as MIKBUG/SWTBUG goes, you also always have the "L" command
If the data in your TSC BASIC "M" text were
converted to S-record format
- a trivial programming exercise -
it would be easier (no delays required) (and more
reliable) to load into
the SWTP.
They're both ASCII text input, just different
formats.
I'm not clear why you resorted to the M-command method, was the TSC BASIC
data
not originally
in S-records? - that would be the standard format for
loading such
software into an SWTP.
19 Aug
19 Aug
8:39 a.m.
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?
It depends on what you mean by "the same line".
For ease of language here, I'm going to assume that the devices are a
computer, C, and two terminals, T1 and T2.
If you connect all the pins, it will work fine for the signals that T1
and T2 are driving to the same state. Signals driven to opposite
states may register as being in one of the two states or they may fall
into the undefined intermediate zone (between -3V and +3V, IIRC),
depending on the voltages T1 and T2 are trying to drive them to and the
exact impedances of the drivers. (It shouldn't fry anything, though;
one really nice feature of RS-232C is that the spec requires that any
pin or combination of pins can be shorted together and/or to any
voltage source within the allowed range (-25V to +25V, IIRC)
indefinitely without damage. I'm not sure this applies to ground pins,
though; it certainly doesn't in practice - I've seen ground loops.)
However, the terminal-driven data line (the one that T1 and T2 use to
send to C) is one of those signals. I would suggest using a breakout
box, or two connectors wired by hand with that signal omitted, to
isolate C from one of the two terminals on that pin. (I would actually
go as far as to connect only two pins, signal ground and C-to-T data,
to one of the two terminals.) It will mean you can't type on both T1
and T2 (or, rather, typing will be ignored on one of them); if you want
that to work, you will need at least a few active components between
them - two diodes and a pullup resistor strikes me as the bare minimum,
and even then you may have to play with the resistor value to get the
voltages within the correct ranges.
Another nice feature of RS-232C is that it is electrically very simple.
You can throw together serial-line stuff with alligator clip leads and
discrete components like diodes and resistors. You don't have to worry
about things like modulation schemes and lower-level protocols, the way
you do with things like USB or Ethernet.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
8:47 a.m.
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Mouse
Sent: 19 August 2016 13:39
To: cctalk at classiccmp.org
Subject: Re: SWTPC 6800
T2 are
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?
It depends on what you mean by "the same line".
For ease of language here, I'm going to assume that the devices are a
computer, C, and two terminals, T1 and T2.
If you connect all the pins, it will work fine for the signals that T1 and driving to the same state. Signals driven to opposite
states may register
as
being in one of the two states or they may fall into
the undefined
intermediate zone (between -3V and +3V, IIRC), depending on the voltages
T1 and T2 are trying to drive them to and the exact impedances of the
drivers. (It shouldn't fry anything, though; one really nice feature of
RS-232C
is that the spec requires that any pin or combination
of pins can be
shorted
together and/or to any voltage source within the
allowed range (-25V to
+25V, IIRC) indefinitely without damage. I'm not sure this applies to
ground
pins, though; it certainly doesn't in practice -
I've seen ground loops.)
However, the terminal-driven data line (the one that T1 and T2 use to send
to C) is one of those signals. I would suggest using a breakout box, or
two
connectors wired by hand with that signal omitted, to
isolate C from one
of
the two terminals on that pin. (I would actually go
as far as to connect
only
two pins, signal ground and C-to-T data, to one of the
two terminals.) It
will
mean you can't type on both T1 and T2 (or, rather,
typing will be ignored
on
one of them); if you want that to work, you will need
at least a few
active
components between them - two diodes and a pullup
resistor strikes me as
the bare minimum, and even then you may have to play with the resistor
value to get the voltages within the correct ranges.
Another nice feature of RS-232C is that it is electrically very simple.
You can throw together serial-line stuff with alligator clip leads and
discrete
components like diodes and resistors. You don't
have to worry about
things
like modulation schemes and lower-level protocols, the
way you do with
things like USB or Ethernet.
If you feel really lazy you can get serial switches in both 9 and 25-pin
varieties for almost less than the parts...
http://www.ebay.com/itm/131887801860
Dave
G4UGM
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
2928
days inactive
2935
days old
22 comments
8 participants
participants (8)
-
billdegnan＠gmail.com -
chrise＠pobox.com -
cisin＠xenosoft.com -
dave.g4ugm＠gmail.com -
hilpert＠cs.ubc.ca -
mhs.stein＠gmail.com -
mouse＠Rodents-Montreal.ORG -
vintagecomputer＠bettercomputing.net