5 May
2008
5 May
'08
3:55 p.m.
As I think most of you know, I have a fairly diverse collection of
classic computers (I suspect some others do too).
Quite often I need to transfer data between 2 machines. Maybe to
download a file from this PC, which I've in turn downloaded from a web
site, to run on one of the classics. Maybe to print out some listing from
a classic. Whatever.
My machines vary in size from the pocket computers up to machines that
it's not practical to move. They're scattered throughout a house. They
are, alas, not in a machine room. Most of the machines (and all the ones
I want to consider for this) have an RS232 port, either built-in or as an
option (which I have). Most of the machines run kermit. Or I can simply
print to the RS232 port on one machine and capture the incoming
characters on the other
So, I think the problem reduces to 'how to interconnect RS232 ports'. let
me add some constraints :
Must work over a distance longer than the RS232 spec allows (i.e. the
answer is probably not 'A long RS232 cable' :-)).
Prefereably no cables at all. One solution I've come up with is to use a
couple of line drivers and a long cable between them. A long cable that
my parents, or the cat, will get tangled up in :-(
No line-of-sight between the machines
Must work at 300 and 1200 baud. 110 and 9600 baud would be a bonus
I only need one pair of machines linked at a time. I don't need a
network. So if the solution involves a radio link, the fact that there's
only one channel available would not be a problem.
Must not make use of any flow control lines on the RS232 port, since some
of my machines don't support them.
Using classic, or at least repairable, hardwre is a bonus :-)
I said 'RS232'. I mean asynchronous serial, of course :-). If somebody
has a solution for TTL or 3.3V level serial ports, I can trivially
convert the signal levels
I've been looking at some of the license-exempt radio modules, but they
either are half-duplex or amke use of the flow control lines (typically
they buffer <n> bytes internally, then de-assert a flow control line
while they pack up that data and send it to the other end).
So far the best I've come up with is to link one machine to a palmtop
(HP95LX), then transfer the data to that, carry the palmtop to the other
machine and transdfer the data on. It's not ideal, but it does work.
Any other ideas?
-tony
5 May
5 May
4:19 p.m.
Tony Duell wrote:
So far the best I've come up with is to link one
machine to a palmtop
(HP95LX), then transfer the data to that, carry the palmtop to the other
machine and transdfer the data on. It's not ideal, but it does work.
Any other ideas?
Hmm, I've got a deep mistrust of any 'data over the mains' technology, but
might that be an option here? I assume *most* of your systems are physically
plugged into the mains anyway, so it'd meet the ideal requirement for no extra
cabling. Data rates presumably not lightning fast, of course...
Sneakernetting data around isn't such a problem in a classic context, though -
most old machines need you to be physically present in order to do anything
(interesting) with them, so carrying the data back and forth isn't any great
hardship.
Some sort of RS232 star-based topology could be fun, though :)
cheers
Jules
4:44 p.m.
Packet radio ?
Or 400Mhz transmitting modules those are very small and able to transmit
digital signals.
There is one setback you can't use full-duplex.
Rik
----- Original Message -----
From: "Jules Richardson" <jules.richardson99 at gmail.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Monday, May 05, 2008 10:19 PM
Subject: Re: Interconnecting classic computers
Tony Duell wrote:
So far the best I've come up with is to link
one machine to a palmtop
(HP95LX), then transfer the data to that, carry the palmtop to the other
machine and transdfer the data on. It's not ideal, but it does work.
Any other ideas?
Hmm, I've got a deep mistrust of any 'data over the mains' technology, but
might that be an option here? I assume *most* of your systems are
physically plugged into the mains anyway, so it'd meet the ideal
requirement for no extra cabling. Data rates presumably not lightning
fast, of course...
Sneakernetting data around isn't such a problem in a classic context,
though - most old machines need you to be physically present in order to
do anything (interesting) with them, so carrying the data back and forth
isn't any great hardship.
Some sort of RS232 star-based topology could be fun, though :)
cheers
Jules
6 May
6 May
5:35 p.m.
Tony Duell wrote:
It's certainly something I'd considered.
So far the best I've come up with is to link
one machine to a palmtop
(HP95LX), then transfer the data to that, carry the palmtop to the other
machine and transdfer the data on. It's not ideal, but it does work.
Any other ideas?
Hmm, I've got a deep mistrust of any 'data over the mains' technology, but
might that be an option here? I assume *most* of your systems are physically plugged into the mains anyway, so it'd meet the
ideal requirement for no extra
cabling. Data rates presumably not lightning fast, of course...
Even those machines that are battery-powered are likely to be near a
mains socket, at least when I wasnt ot link them to another machine. So
that's not a problem.
Do true full-dupliex data-over-mains 'modems' exist? The chip I looked at
for this years ago seemed to be half-duplex only (it had a
trasnmit-enable input, and you were supposed to only have one
transmiotter enabled at a time out of all the chips on your mains
wiring).And that certainly wouldn't do here.
Sneakernetting data around isn't such a problem in a classic context, though -
That depends on how many machins you have to climb over to get between
the 2 you want to connect :-)
most old machines need you to be physically present in
order to do anything
(interesting) with them, so carrying the data back and forth isn't any great
hardship.
Some sort of RS232 star-based topology could be fun, though :)
I actually have soemthing called a Netcommander in front of me. It's a 16
port any-to-any RS232 switch (I also have smaller versions with 6 RS232
ports and 4 centronics ports). Since it allows different baud rates on
all the ports, it must make use of the flow control lines (otherwise what
happens if you try to send a lot of data from a 9600 baud port to a 300
baud one), but this might not be a problem if the 2 ports are set to the
same speed.
Anyway, the big prolem with it is that it's one small box, and it's only
16 ports. I could link 16 classic computers to it, but (a) I've got a lot
more than 16 machines and (b) it would involve cables running everywhere,
soemthing I need to avoid. It would be interesting to use that to link up
16 'favourite' machines, but that leaves a lot more that I have to think
of another (temporary) solution for.
-tony
7 May
7 May
1:17 p.m.
Tony Duell wrote:
True, I've seen your house :-)
The Netcommander sounds interesting - but as you say, it requires extra
cabling. If extra cabling's unavoidable, maybe something like Econet is a
better bet* as you'll have less cabling in total and more capacity (but it
makes the big assumptions that you have an expansion bus you can make use of
on each of your machines, and that you can write protocol software)
* by hanging an Econet module off the back of each machine (rather than
rolling your own around the 68B54 ADLC)
cheers
Jules
Do true full-dupliex data-over-mains 'modems'
exist? The chip I looked at
for this years ago seemed to be half-duplex only (it had a
trasnmit-enable input, and you were supposed to only have one
transmiotter enabled at a time out of all the chips on your mains
wiring).And that certainly wouldn't do here.
Hmmm not sure. Although I don't really see why not; coax-based Ethernet's a
"single wire" design and works OK - so I don't see why the same sort of
design
couldn't be done over mains wiring.
Sneakernetting
data around isn't such a problem in a classic context, though -
That depends on how many machins you have to climb over to get between
the 2 you want to connect :-) 
4:35 p.m.
Tony would like to reduce, eliminate the wires. Bluetooth, ultrasonic,
FM, would all work.
If you can stand hearing 1070Hz, 1270Hz, 2025Hz, and 2225Hz tones,
and you're not making too much noise,
howzbout: implement Bell 103 with modems with microphones and speakers,
and just skip the whole interconnecting wire business. You'll be able to
keep track of the transfers, and prob'ly even have fewer people coming
around to waste your time.
--
Grumpy Ol' Fred cisin at xenosoft.com
4:45 p.m.
And thusly were the wise words spake by Fred Cisin
Tony would like to reduce, eliminate the wires. Bluetooth, ultrasonic,
FM, would all work.
If you can stand hearing 1070Hz, 1270Hz, 2025Hz, and 2225Hz tones,
and you're not making too much noise,
howzbout: implement Bell 103 with modems with microphones and speakers,
and just skip the whole interconnecting wire business. You'll be able to
keep track of the transfers, and prob'ly even have fewer people coming
around to waste your time.
I think the cat(s) would take issue with that and proceed to destroy
the cause of said tones...
Cheers,
Bryan
5:37 p.m.
> howzbout: implement Bell 103 with modems with
microphones and speakers,
On Wed, 7 May 2008, Bryan Pope wrote:
I think the cat(s) would take issue with that and
proceed to destroy
the cause of said tones...
When my dog hears a modem connecting and "negotiating", he tells me about
it and gets a treat (my hearing is bad). He certainly wouldn't mind, why
wouldn't the cats get used to it?
4:47 p.m.
On Wed, May 7, 2008 at 1:35 PM, Fred Cisin <cisin at xenosoft.com> wrote:
<snip>
If you can stand hearing 1070Hz, 1270Hz, 2025Hz, and
2225Hz tones,
and you're not making too much noise,
howzbout: implement Bell 103 with modems with microphones and speakers,
and just skip the whole interconnecting wire business. You'll be able to
keep track of the transfers, and prob'ly even have fewer people coming
around to waste your time.
<snip>
That idea is AWESOME. I just want to put that out there :)
John
--
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn
5:38 p.m.
If you can stand hearing 1070Hz, 1270Hz, 2025Hz, and
2225Hz tones,
and you're not making too much noise,
I might nt be making much noise, but the fans and hard drives in my
classics are hardly silent...
howzbout: implement Bell 103 with modems with
microphones and speakers,
and just skip the whole interconnecting wire business. You'll be able to
keep track of the transfers, and prob'ly even have fewer people coming
around to waste your time.
:-)...
However, one reason to avoid wires to to avoid upsetting Pentina the cat.
I think your proposed solution is likely to really other him, alas.
-tony
8:23 p.m.
> howzbout: implement Bell 103 with modems with
microphones and speakers,
> and just skip the whole interconnecting wire business. You'll be able to
On Wed, 7 May 2008, Tony Duell wrote:
I might nt be making much noise, but the fans and hard
drives in my
classics are hardly silent...
The standard solution to SNR problems is typically, if you can't reduce
the noise, then increase the signal amplitude
However, one reason to avoid wires to to avoid
upsetting Pentina the cat.
I think your proposed solution is likely to really other him, alas.
I don't suppose that training Pentina to carry SD cards from one machine
to another is an option - cats know that they don't need to work
8 May
8 May
3:02 p.m.
On Wed, 7 May 2008, Tony Duell wrote:
Indeed. And presumaly (to (mis-)quote the Radiophile magazine refering to
fault that cause audio amplifiers to burst into oscillations), this will
'rattle windows within a 500 yard radius of the workshop, frighten horses
in the street and cause the elderly and infirm to perform standing jumps
of Olympian standard' :-)
I might nt be making much noise, but the fans and
hard drives in my
classics are hardly silent...
The standard solution to SNR problems is typically, if you can't reduce
the noise, then increase the signal amplitude However, one reason to avoid wires to to avoid
upsetting Pentina the cat.
I think your proposed solution is likely to really other him, alas.
I don't suppose that training Pentina to carry SD cards from one machine
to another is an option - cats know that they don't need to work
7 May
7 May
5:24 p.m.
The Netcommander sounds interesting - but as you say, it requires extra
cabling. If extra cabling's unavoidable, maybe something like Econet is a
better bet* as you'll have less cabling in total and more capacity (but it
makes the big assumptions that you have an expansion bus you can make use of
on each of your machines, and that you can write protocol software)
Neither is true in gerneral, alas. I have machines with RS232 ports that
have no accessible expansion bus (the Sharp PC1350 and the HP110 are 2 I
can see without getting up). I'd also love to see you write an econet
program for a Philips P850 (2K owrds of core), an HP9830, etc (and yes, I
do have RS232 ports for those machines). Actually, doesn't an original
IBM PC have prolems keeping up with Econet? I was under the impression
that the Acorn econset interface card for that machine has a 6502 on it
to run the econet protocol software.
* by hanging an Econet module off the back of each machine (rather than
rolling your own around the 68B54 ADLC)
That, at least for me, would be the trivial bit.
-tony
5 May
5 May
4:21 p.m.
To be honest, I would just get a cheap x86 laptop with a USB port and
use a USB<->RS232 dongle.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
6:34 p.m.
On Mon, 5 May 2008, Richard wrote:
To be honest, I would just get a cheap x86 laptop with
a USB port and
use a USB<->RS232 dongle.
YIKES!!
I would never suggest USB to Tony!
When Joe Campbell was writing his serial books, he was running 9600
through a SPOOL (~1000 feet) of wire. Apparently the cable lengths in the
RS232 specs are somewhat conservative in their "limits".
--
Grumpy Ol' Fred cisin at xenosoft.com
6:43 p.m.
In article <20080505153243.V67797 at shell.lmi.net>,
Fred Cisin <cisin at xenosoft.com> writes:
I would never suggest USB to Tony!
If he doesn't like USB, he can always board swap something else in
there.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
11:33 p.m.
On May 5, 2008, at 7:01 PM, Fred Cisin wrote:
or upgrade all of his computers to PCs running Windoze Vista?
I thought you typed "upgrade".
-Dave
--
Dave McGuire
Port Charlotte, FL
I would never suggest USB to Tony!
If he doesn't like USB, he can always board swap something else in
there.
11:51 p.m.
On May 5, 2008, at 11:41 PM, Fred Cisin wrote:
FECESious? ;)
-Dave
--
Dave McGuire
Port Charlotte, FL
> or upgrade
all of his computers to PCs running Windoze Vista?
On Mon, 5 May 2008, Dave McGuire wrote:
I thought you typed "upgrade".
I guess that it's futile to be facetious with this group!
6 May
6 May
5:54 p.m.
> > I would never suggest USB to Tony!
>
> If he doesn't like USB, he can always board swap something else in
> there.
Can I? Are there really USB-capable laptops with useful expansion slots?
or upgrade all of his computers to PCs running Windoze Vista?
s/up/down/ :-)
And I'll only conside this if said PCs also come with the 'extra' I have
for the classic machines I'm discussing. Namely a scheamtic.
-tony
5 May
5 May
7:03 p.m.
On Mon, May 05, 2008 at 04:43:47PM -0600, Richard wrote:
In article <20080505153243.V67797 at shell.lmi.net>,
Fred Cisin <cisin at xenosoft.com> writes:
tea -> monitor
-ethan
--
Ethan Dicks, A-333-S Current South Pole Weather at 5-May-2008 at 23:00 Z
South Pole Station
PSC 468 Box 400 Temp -65.7 F (-54.3 C) Windchill -97.8 F (-72.1 C)
APO AP 96598 Wind 8.9 kts Grid 55 Barometer 697.0 mb (9993 ft )
Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html
I would never suggest USB to Tony!
If he doesn't like USB, he can always board swap something else in
there.
7:13 p.m.
On Mon, May 05, 2008 at 03:34:45PM -0700, Fred Cisin wrote:
When Joe Campbell was writing his serial books, he was
running 9600
through a SPOOL (~1000 feet) of wire. Apparently the cable lengths in the
RS232 specs are somewhat conservative in their "limits".
We used to run CAT3 (telco) wire across a 5000 sq ft building from user
terminals to our machine room (via the Nevada Western RJ-11 modular gear
I mentioned earlier this year). We couldn't get reliable 19200 comms,
but we were solid at 9600 for interactive sessions or Kermit transfers
and the like.
There was only one thing that we noticed that was strange - typically to
log in, you'd tap the return key a couple of times to get the host port
to lock onto your current baud rate. We usually saw one lowercase 'u'
echoed per press of the return key prior to getting the login prompt.
Once we got characters from the host, we didn't see the strange echo.
We always attributed that to an unloaded line from the host and
crosstalk between the Tx and RX pair between the terminal and the
host, but perhaps someone else has a theory.
In any case, we were well past the normally accepted cable length and
had probably millions of keystrokes go through intact.
For a single point-to-point extra-long serial cable, one can explore
expensive, low-capacitance transmission cable, or perhaps RS-422/RS-232
converters, but I think Tony was less interested in long cables to
trip unwary mammals anyway (or else short-haul fiber modems could be
a possibility).
I have some of the same requirements as Tony for interconnecting older
devices, but my solution was to blow a hole in the computer room wall
and run fiber, 10Base2, CAT5, and 25-pr Telco cable between the second
floor and the basement, reducing the trip hazard.
-ethan
--
Ethan Dicks, A-333-S Current South Pole Weather at 5-May-2008 at 23:00 Z
South Pole Station
PSC 468 Box 400 Temp -65.7 F (-54.3 C) Windchill -97.8 F (-72.1 C)
APO AP 96598 Wind 8.9 kts Grid 55 Barometer 697.0 mb (9993 ft )
Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html
6 May
6 May
5:36 p.m.
To be honest, I would just get a cheap x86 laptop with a USB port and
use a USB<->RS232 dongle.
How is this an improvement on using one of my many portable machines with
built-in serial ports (and indeed terminal emulators/kermit in ROM)?
I already use an HP95LX palmtop for this. OK, it's limited to 512K memory
unless I stick a card in it, but that's plenty of space for classic
computer-related files :-)
-tony
6:43 p.m.
In article <m1JtUq2-000IygC at p850ug1>,
ard at p850ug1.demon.co.uk (Tony Duell) writes:
Then I don't understand; it sounds like you already have a solution.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
To be honest,
I would just get a cheap x86 laptop with a USB port and
use a USB<->RS232 dongle.
How is this an improvement on using one of my many portable machines with
built-in serial ports (and indeed terminal emulators/kermit in ROM)?
7 May
7 May
4:44 p.m.
In article <m1JtUq2-000IygC at p850ug1>,
ard at p850ug1.demon.co.uk (Tony Duell) writes:
Then I don't understand; it sounds like you already have a solution.
No, I haev a workaround. It's not a direct connection between the 2
machines, it's a sort of sneakernet[1] where I have to plug the palmtop
into one of the mahcines, transfer the file to it, then carry it to the
other machine nad transfer the file across to that machine.
I was asking if anyone had suggestions for a direct connection method,
mainly for those times ehen I want to do something other than transfer a
file.
[1] A term that I find doubly inapproptiate. Firstly the term 'sneaker'
is not used in the UK, that form of footwear are normally called
'trainers'. Secondly I don't own any such footwear...
-tony
To be
honest, I would just get a cheap x86 laptop with a USB port and
use a USB<->RS232 dongle.
How is this an improvement on using one of my many portable machines with
built-in serial ports (and indeed terminal emulators/kermit in ROM)?
8 May
8 May
3:50 a.m.
You're not related in any way to a person called T. Pratched[1]
If you were, you could use the Semaphore network ;-)
Rik
[1]Pratched, founder of the so called discworld and it's inhebitants
----- Original Message -----
From: "Tony Duell" <ard at p850ug1.demon.co.uk>
To: <cctalk at classiccmp.org>
Sent: Wednesday, May 07, 2008 10:44 PM
Subject: Re: Interconnecting classic computers
In article <m1JtUq2-000IygC at p850ug1>,
ard at p850ug1.demon.co.uk (Tony Duell) writes:
Then I don't understand; it sounds like you already have a solution.
No, I haev a workaround. It's not a direct connection between the 2
machines, it's a sort of sneakernet[1] where I have to plug the palmtop
into one of the mahcines, transfer the file to it, then carry it to the
other machine nad transfer the file across to that machine.
I was asking if anyone had suggestions for a direct connection method,
mainly for those times ehen I want to do something other than transfer a
file.
[1] A term that I find doubly inapproptiate. Firstly the term 'sneaker'
is not used in the UK, that form of footwear are normally called
'trainers'. Secondly I don't own any such footwear...
-tony
To be
honest, I would just get a cheap x86 laptop with a USB port and
use a USB<->RS232 dongle.
How is this an improvement on using one of my many portable machines
with
built-in serial ports (and indeed terminal emulators/kermit in ROM)?
4:04 a.m.
Ough, your right ...
----- Original Message -----
From: "Fred Cisin" <cisin at xenosoft.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Thursday, May 08, 2008 9:55 AM
Subject: Re: Interconnecting classic computers
On Thu, 8 May 2008, Rik wrote:
You're not related in any way to a person
called T. Pratched[1]
If you were, you could use the Semaphore network ;-)
Rik
[1]Pratched, founder of the so called discworld and it's inhebitants
... except that it is spelled Terry Pratchett.
4:10 p.m.
You're not related in any way to a person called T. Pratched[1]
Not that I am aware of...
If you were, you could use the Semaphore network ;-)
Hmmm.. Assuming Semaphore means what I think it does in this context, it
would e fairly easy to make a semaphore transmitter that is driven by an
RS232 port, the receiver is a lot more work. And what aobut the data
rate? If you need to keep up with 1200 baud, that's about 120cps, those
arms are going to be flying about, unless you have some kind of data
buffering at the transmitter end (which brings us back to another solution).
Not to mention, of course, that this is strictly line-of-sight, something
that's not possible here.
-tony
6:29 p.m.
On Thursday 08 May 2008, Tony Duell wrote:
If you're going to go that route, you might as well use carrier pigeons.
At least that method will also provide some entertainment to your
cat(s). Said cats may end up mangling the data carriers (and data),
though.
--
Purdue University Research Computing --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
If you were,
you could use the Semaphore network ;-)
Hmmm.. Assuming Semaphore means what I think it does in this context,
it would e fairly easy to make a semaphore transmitter that is driven
by an RS232 port 
8:20 p.m.
Patrick wrote:
If you're going to go that route, you might as
well use carrier pigeons.
At least that method will also provide some entertainment to your
cat(s). Said cats may end up mangling the data carriers (and data),
though.
If you do that, you should make sure it is RFC 1149 compliant, so that
it can interoperate with anyone else you encounter that is also using
avian carriers. If you need QoS you might have to use RFC 2549.
Eric
10:32 p.m.
Eric Smith wrote:
Patrick wrote:
I figure the cat pounces for any bir ^H^^H^H lost messages, and dispatches
new messages quicker.
If you're going to go that route, you might
as well use carrier pigeons.
At least that method will also provide some entertainment to your
cat(s). Said cats may end up mangling the data carriers (and data),
though.
If you do that, you should make sure it is RFC 1149 compliant, so that
it can interoperate with anyone else you encounter that is also using
avian carriers. If you need QoS you might have to use RFC 2549
Eric
5 May
5 May
4:34 p.m.
So, I think the problem reduces to 'how to
interconnect RS232
ports'. let me add some constraints :
Must work over a distance longer than the RS232 spec allows (i.e. the
answer is probably not 'A long RS232 cable' :-)).
Prefereably no cables at all. One solution I've
come up with is to use a
couple of line drivers and a long cable between them. A long cable that
my parents, or the cat, will get tangled up in :-(
It were me, I'd probably look into Bluetooth- or Zigbee-based serial
extenders.
Disclaimer: I don't know what the regulatory issues might be with those
devices in the UK.
While this doesn't meeet your usual criteria for being able to repair
the device, it might be viable for you on the theory that the devices
are relatively inexpensive and could be treated as an interim solution
-- somewhat disposable, replaceable with a long cable if necessary, etc.
Presumably there'll be some new toy with the same function in a couple
of years.
In the long cable division, there are a number of products around that
extend rs232 by using baluns at each end, and cat-5 cable for the bulk
of the run. Still commits bondage on the cat :), but works around the
rs232 distance limitations. These I suspect you could reverse engineer
and build yourself.
I've also seen serial-to-ethernet devices. These plus a pair of wifi
access points...but we're getting expensive now.
De
4:49 p.m.
Dennis wrote:
It were me, I'd probably look into Bluetooth- or
Zigbee-based serial
extenders.
I'm not sure about Zigbee, but the useful range of Bluetooth is very
short. There are claims of over 30 meters, but as far as I can tell
that must be under laboratory conditions, e.g. in a faraday cage.
In the real world, more than about 3 meters line of sight works poorly,
as does non-line-of-sight at any distance.
Eric
5:08 p.m.
> It were me, I'd probably look into Bluetooth-
or Zigbee-based serial
> extenders.
I'm not sure about Zigbee, but the useful range of
Bluetooth is very
short. There are claims of over 30 meters, but as far as I can tell
that must be under laboratory conditions, e.g. in a faraday cage.
In the real world, more than about 3 meters line of sight works poorly,
as does non-line-of-sight at any distance.
Well, 30 meters is probably with the full gale laboratory tailwind, but
I accidentally left the phone behind and went down the hall 15+ meters in
this pile of a building where I work (brick and plaster walls, often
seems made mostly of Faradayium) and my bt headset didn't lose
connection. So it does have some range sometimes. Success would
definitely depend on the devices in question and the construction of the
building. I don't know if Zigbee has better range or not.
De
6 May
6 May
9:51 a.m.
You'd think there would be a relatively big market for serial-to-Ethernet
"just works" bridges. You'd think it wouldn't be hard. Then again,
some
of the USB-to-serial adapters I've tried weren't foolproof.
At 05:43 PM 5/5/2008, Adrian Wise wrote:
Possibly a bit OTT but these guys seem to have what you
want:
http://www.bb-elec.com/product_family.asp?familyid=145
"legacy" serial over WiFi.
Ah, there they are. One menu up.
I guess it depends on how far is "far". Did Tony say he wants to
stretch a cable from home to the pub? :-)
- John
11:08 a.m.
John Foust wrote:
You'd think there would be a relatively big market
for serial-to-Ethernet
"just works" bridges. You'd think it wouldn't be hard. Then again,
some
of the USB-to-serial adapters I've tried weren't foolproof.
There is, and they're called terminal servers or console servers,
depending on which way they're pointed. Digi, Xyplex, DEC, Livingston,
and umpty-eleven other companies have made them.
Doc Shipley
11:22 a.m.
At 10:08 AM 5/6/2008, Doc Shipley wrote:
There is, and they're called terminal servers or
console servers, depending on which way they're pointed. Digi, Xyplex, DEC,
Livingston, and umpty-eleven other companies have made them.
Looking at it that way, I've owned a few... but I think my brain was
tuned to the frequency of "new", one-to-one and $40 and a web interface.
- John
5:57 p.m.
John wrote:
You'd think there would be a relatively big market
for serial-to-Ethernet
"just works" bridges.
Probably, if someone came up with a reasonable definition of what
"just works" actually means for such a device.
If I plug this hypothetical "just works" serial-to-Ethernet box onto
a serial port on an old computer, and plug the ethernet into the
switch along with my desktop computer, laptop, and wireless router,
what exactly should the box do? And what should I, as the user, do?
Eric
6:02 p.m.
In article <49629.64.62.206.10.1210111061.squirrel at ruckus.brouhaha.com>,
"Eric Smith" <eric at brouhaha.com> writes:
If I plug this hypothetical "just works"
serial-to-Ethernet box onto
a serial port on an old computer, and plug the ethernet into the
switch along with my desktop computer, laptop, and wireless router,
what exactly should the box do? And what should I, as the user, do?
I'd expect the box to initiate a telnet session to the ethernet side
and look like a "computer" to the terminal side.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
6:23 p.m.
John wrote that he thought there was a market for a serial-to-Ethernet
"just works" adapter.
I wrote:
If I plug this hypothetical "just works"
serial-to-Ethernet box onto
a serial port on an old computer, and plug the ethernet into the
switch along with my desktop computer, laptop, and wireless router,
what exactly should the box do? And what should I, as the user, do?
Richard wrote:
I'd expect the box to initiate a telnet session to
the ethernet side
A telnet session to where?
How does the box get its IP address? I suppose one possibility would
be DHCP, but that isn't consistent with "just works" because someone
has to have configured a DHCP server. Even if there's already a DHCP
server (e.g., in the wireless router in my example), the user won't
know what IP address it assigned to the box.
How does the box know the serial port parameters to use? If it's
doing telnet, it could expect the other end to tell it using the
RFC 2217 Telnet Com Port Control Option, but that's not ideal
because very little host software supports that option.
and look like a "computer" to the terminal
side.
OK, I'll bite. What does a computer look like?
Obviously all these questions can be answered, but it's not clear
how to answer them such that the product "just works". In fact,
it seems to me like it's impossible to meet the "just works"
objective.
Eric
6:42 p.m.
In article <59118.64.62.206.10.1210112636.squirrel at ruckus.brouhaha.com>,
"Eric Smith" <eric at brouhaha.com> writes:
Richard wrote:
It would be like a terminal server. When you type "telnet" at a unix
or DOS prompt, it asks you where you what host to which you want to
connect. I don't see this as any different.
I'd expect the box to initiate a telnet
session to the ethernet side
A telnet session to where? How does the box get its IP address?
How does any box on an ethernet network get its IP address? Nothing
different here. If the box needs some sort of configuration, you'd do
that through the terminal.
All the other questions are answered similarly; what's being proposed
here is not new -- terminal servers have been doing this for 20+ years
at this point.
Obviously all these questions can be answered, but
it's not clear
how to answer them such that the product "just works". In fact,
it seems to me like it's impossible to meet the "just works"
objective.
There's always someone who will say it doesn't "just work". If you
want to be super-anal about it you can find fault with any product,
even something as simple as a toothpick.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
7:45 p.m.
Richard wrote:
All the other questions are answered similarly;
what's being proposed
here is not new -- terminal servers have been doing this for 20+ years
at this point.
I know, since I'm one of the software engineers that developed firmware
for such products. I can't claim knowledge of what John meant by "just
work", but those of us that designed the things don't consider them to
just work", and neither do our customers.
If you
want to be super-anal about it you can find fault with any product,
even something as simple as a toothpick.
I'm not finding fault in anything. I think John had a legitimate
point that there would be a market for such a thing that "just worked",
and it would be a much bigger market than the stuff that you can
actually buy now. Unfortunately, I think it's impossible.
Eric
9:38 p.m.
At 06:45 PM 5/6/2008, Eric Smith wrote:
I'm not finding fault in anything. I think John
had a legitimate
point that there would be a market for such a thing that "just worked",
and it would be a much bigger market than the stuff that you can
actually buy now. Unfortunately, I think it's impossible.
So what's on the list of things that go wrong, or just "not right"?
Hardware handshaking? Buffer overruns? Other timing issues?
All perfectly plausible to me, but then I ask if the same issues
aren't already present on PC USB-to-serial adapters or for that
matter aren't already present in Tony's example on classic hardware.
Tony's question seemed to me more about delivering a byte elsewhere
on a serial port, and not about specific machine-to-machine
and app-to-app compatibility quirks.
- John
7:29 p.m.
At 04:57 PM 5/6/2008, Eric Smith wrote:
If I plug this hypothetical "just works"
serial-to-Ethernet box onto
a serial port on an old computer, and plug the ethernet into the
switch along with my desktop computer, laptop, and wireless router,
what exactly should the box do? And what should I, as the user, do?
I imagined it would work like a zillion other $40 web-configured
network bridge/router devices these days. Emphasis on "bridge".
Out of the box, it wakes up on a static IP. I can point a web
browser at it and change the settings: at this IP, at this baud rate.
I do the same to the second box: this IP, these serial settings.
Maybe it converts between mismatched baud rates, too.
So both devices are on the net, and they talk to each other. I connect
one's serial port to one old computer, I connect the other to the other
old computer's serial port. A serial port bridge, over Ethernet.
They talk. One end sends a byte, it gets delivered to the other end
and emitted, and vice-versa. Isn't that what Tony wants?
I'm waving my hands as to whether the ends are DTE or DCE, and how much
they're buffered. I'll wave my hands about how bytes are packaged
to be sent in Ethernet-sized packets. I'll also wave my hands about
what other useful status info the web interface might show, and
I'll dodge any arguments about whether a serial interface for its
configuration would be more sensible than http.
- John
12:20 a.m.
On May 5, 2008, at 4:49 PM, Eric Smith wrote:
It's also not likely that Bluetooth will be around for much
longer. Zigbee solves many of its problems, it's much easier to work
with, and is gaining popularity fast.
Tony, you might look into the XBee modules from Maxstream. The
are serial<->Zigbee bridge modules that are very easy to configure
and use. They are also cheap at ~$20/ea. They may solve your problem.
-Dave
--
Dave McGuire
Port Charlotte, FL
It were me,
I'd probably look into Bluetooth- or Zigbee-based serial
extenders.
I'm not sure about Zigbee, but the useful range of Bluetooth is very
short. There are claims of over 30 meters, but as far as I can tell
that must be under laboratory conditions, e.g. in a faraday cage.
In the real world, more than about 3 meters line of sight works
poorly,
as does non-line-of-sight at any distance.
6:12 p.m.
Tony, you might look into the XBee modules from
Maxstream. The
are serial<->Zigbee bridge modules that are very easy to configure
and use. They are also cheap at ~$20/ea. They may solve your problem.
Thanks for the suggestion. I had heard of them, but I've never tried them
(I think they were mentioned in Elektor a coupel of years back, for
example).
I've not managed to look at the manuals for them yet, but my main worry
is that they'll require some kind of hardware flow control. Surely, since
they can work at just about any abud rate, and since the 2 ends of the
link don't have to run at the same rate on the host port (do they?) they
must use flow control (otherwise what happens if a machine witha 9600
baud port is talking to to a 110 baud teletupe :-)). Maybe this isn't a
problem if the 2 ends are set to the same rate, I will look into it.
And certianly the price is low enough to be worth experimenting with.
-tony
7 May
7 May
4:47 p.m.
[Xbee modules]
I've not managed to look at the manuals for them
yet, but my main worry
is that they'll require some kind of hardware flow control. Surely, since
I have now read the manuals on their wesite, and from what I can gather
they do use RTS/CTS flow control (as I expexted). It's not always needed,
you can get by without it if there's no chance of a buffer overrun (e.g.
you leave long enough gaps between the characters, maybe also if you have
a low enough baud rate (and the same rate at both ends, I guess).
They look interesting to experiment with (and they're cheap enough to do
just thatt), but I am not (yet) convinced they're exactly what I am
looking for.
-tony
9 May
9 May
11:01 a.m.
New subject: Transistor ID
I'm trying to identify a transistor from an early '60s vintage radar
processor panel:
http://sturgeon.css.psu.edu/~mloewen/Oldtech/Panels/Budd-7L.jpg
The transistor is labeled "GT1890G052", and I haven't been able to find
anything on the web. They're apparently used to switch 3-lead neon
indicator lamps.
Mike Loewen mloewen at cpumagic.scol.pa.us
Old Technology http://sturgeon.css.psu.edu/~mloewen/Oldtech/
4:51 p.m.
New subject: Transistor ID
Mike Loewen wrote:
I'm trying to identify a transistor from an early '60s vintage radar
processor panel:
http://sturgeon.css.psu.edu/~mloewen/Oldtech/Panels/Budd-7L.jpg
The transistor is labeled "GT1890G052", and I haven't been able to
find
anything on the web. They're apparently used to switch 3-lead neon
indicator lamps.
I found a few cross-refs for GTxx and GTxxxx numbers, but not specifically for GT1890.
According to these refs, a prefix of "GT" was used by General Instruments,
General
Transistor, and AEI (England).
.. not much help, I know.
Not likely to be very critical though, surely ..figure out whether they're NPN
or PNP and choose an appropriate breakdown voltage (?). I wonder if the 3-lead
neon lamps were used to reduce the breakdown voltage requirements.
10 May
10 May
5:30 a.m.
On Mon, 2008-05-05 at 13:49 -0700, Eric Smith wrote:
Dennis wrote:
Get an old satellite dish, remove the LNB, cut a piece of wood to fit
with a slot that will take a bluetooth USB dongle and then point it at
someone a mile away. You should be able to associate to their phone.
Gordon
It were me, I'd probably look into Bluetooth-
or Zigbee-based serial
extenders.
I'm not sure about Zigbee, but the useful range of Bluetooth is very
short. There are claims of over 30 meters, but as far as I can tell
that must be under laboratory conditions, e.g. in a faraday cage.
In the real world, more than about 3 meters line of sight works poorly,
as does non-line-of-sight at any distance.
6 May
6 May
5:42 p.m.
It were me, I'd probably look into Bluetooth- or
Zigbee-based serial
extenders.
Yes, I have, and still am, considerign those. Somebody else suggested the
Xee module, I had haeard of that. But do any of them work without any
flow control lines back to the host? The simple radio module (on the
433MHz band) that I looked at certainly eneded the RTS/CTS flow control
or something equivalent.
While this doesn't meeet your usual criteria for being able to repair
the device, it might be viable for you on the theory that the devices
I did say that was a 'bonus' here, not required :-)
In the long cable division, there are a number of
products around that
extend rs232 by using baluns at each end, and cat-5 cable for the bulk
My junk box cotnains at least 2, (and I think 4) Gandalf LDS120 units.
These are 'limited distance modems' or some such, they were designed to
transmit data up to 9600 baud over, I think, leased lines. They are built
fro mthe sort of technology I like (op-amps, LM339 comparators, maybe
simple logic chips), and certianly could be used for this. A piece of
4-core telephone cable will work with these up to any distance I am
likely to need.
of the run. Still commits bondage on the cat :), but
works around the
And that's the problem. I can tell my parents 'There's a serial cable at
tripwire-height across the stairs', but I can't tell the cat that I've
run run across the cat flap :-).
But it may well be what I use for the moment...
-tony
7 May
7 May
12:41 a.m.
Hi
Why not use RS422/485. I've only seen this mentioned once.
I used to used RS485 drivers to run serial signals all around
a noisy burn-in room to control a number of systems.
These are designed to drive longer distances.
Dwight
_________________________________________________________________
Make Windows Vista more reliable and secure with Windows Vista Service Pack 1.
http://www.windowsvista.com/SP1?WT.mc_id=hotmailvistasp1banner
6:05 p.m.
Tony Duell wrote:
Yes, I have, and still am, considerign those. Somebody
else suggested
the
Xee module, I had haeard of that. But do any of them work without any
flow control lines back to the host? The simple radio module (on the
433MHz band) that I looked at certainly eneded the RTS/CTS flow
control
or something equivalent.
If you build something yourself (which would obviously then
meet the "maintainability" requirements), you could throw
in some reasonable buffering. 128MB SDRAM is dirt cheap
(?1 or so) and that is likely to be enough buffering
for almost any classic machine. So even if your radio chip
wants to pause for breath, your classic computer doesn't
need to know.
Basically this is a (bidirectional) print buffer with
a radio welded on the end.
You'll obviously need N of them, one per simultaneously
active classic machine.
Antonio
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 269.23.9/1418 - Release Date:
06/05/2008 17:17
8 May
8 May
12:02 a.m.
128MB SDRAM is dirt cheap (?1 or so) and that is
likely to be enough
buffering for almost any classic machine.
Yes, but what about the logic necessary to drive it, refresh it, etc?
I certainly know *I* have no idea what is required, and doubt what's in
my TTL drawers would do the trick.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
6:05 p.m.
der Mouse wrote:
None trivial to be sure, but probably not rocket science. I'm sure
I've seen a project or two in Elektor (iirc) that used SDRAM. But
a quick flick through a few likely issues failed to produce
anything.
I've never had to interface to SDRAM, so I cannot say how hard it
is. But the data sheets are readily available.
Antonio
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 269.23.10/1421 - Release Date:
07/05/2008 17:23
128MB SDRAM is
dirt cheap (?1 or so) and that is likely to be enough
buffering for almost any classic machine.
Yes, but what about the logic necessary to drive it, refresh it, etc?
I certainly know *I* have no idea what is required, and doubt what's
in
my TTL drawers would do the trick.
8:18 p.m.
Antonio wrote:
I've never had to interface to SDRAM, so I cannot
say how hard it
is. But the data sheets are readily available.
"Plain" SDRAM is not too hard to deal with (only slightly more complex
than the older FPM and EDO DRAM), and uses ordinary 3.3V CMOS
levels, though parts intended for "mobile" use may use 1.8V or 2.5V
CMOS levels.
DDR, DDR2, DDR3, etc. use the "Stub Series Terminated Logic" (SSTL)
I/O standards that are not compatible with normal logic levels. As a
consequence, they are relatively difficult to interface.
http://en.wikipedia.org/wiki/Stub_Series_Terminated_Logic
Typically DDR SDRAM is connected directly to a processor or north bridge
with an embedded controller and drivers. Most Xilinx FPGAs have I/O
buffers that can be configured for SSTL.
Eric
9 May
9 May
6:29 p.m.
Yes, but what
about the logic necessary to drive it, refresh it, etc?
I certainly know *I* have no idea what is required, and doubt what's
in
my TTL drawers would do the trick.
None trivial to be sure, but probably not rocket science. I'm sure
I've seen a project or two in Elektor (iirc) that used SDRAM. But
a quick flick through a few likely issues failed to produce
anything.
I've never had to interface to SDRAM, so I cannot say how hard it
is. But the data sheets are readily available.
It's what the data sheets don't mention that comes back to bite you :-).
Particlaurly things like supply decoupling, ground planes, ground bounce,
and other RF-related subjects that, if you don't take care, will result
in a memory system that'll pass diagnostics but will fail in obscure ways
in real use (don't ask....)
-tony
8 May
8 May
2:58 p.m.
If you build something yourself (which would obviously then
meet the "maintainability" requirements), you could throw
Well, I am not going to make the radio modules myself (no way can I meet
type approval, even if I meet the technical specs), but I would certainly
consider making something _round_ said modules.
in some reasonable buffering. 128MB SDRAM is dirt
cheap
(?1 or so) and that is likely to be enough buffering
for almost any classic machine. So even if your radio chip
Now that's something that had not really struck me (which is why this sort
of discussion on the list is so useful) -- that the file sizes I am going
to be transfering _are_ limited. 128Mbytes is larger than the available
mass storage (let alone RAM memory) on most of my classics, so except in
very unusual ciercumstances, the data I wish to transfer is going to be a
lot smaller than that. Which means a buffer is certainly an option.
wants to pause for breath, your classic computer
doesn't
need to know.
Basically this is a (bidirectional) print buffer with
a radio welded on the end.
Does it need to be idriectional? A buffer between the classic machine
output and the radio module input should be enough. But I suppose if I
put one in the other way too, I can use it to do effectively baud rate or
data format conversions.
Of course I can output a 'buffer getting full' signal to those classic
machines that accept hardware flow control, the others will proably not
eend enopuug h data all that fast to need it.
-tony
4:49 p.m.
Tony Duell wrote:
Y'know, I remember electronics kits as a kid always seemed to include both an
AM transmitter and receiver project...
I'm sure they weren't legal, even back then - unless there is (or was) some
loophole for devices with really limited range/power.
(Hmm, ALOHA would be on-topically vintage for your systems, too :-)
If you build
something yourself (which would obviously then
meet the "maintainability" requirements), you could throw
Well, I am not going to make the radio modules myself (no way can I meet
type approval, even if I meet the technical specs)
5:32 p.m.
Y'know, I remember electronics kits as a kid
always seemed to include
both an AM transmitter and receiver project...
I'm sure they weren't legal, even back then -
unless there is (or
was) some loophole for devices with really limited range/power.
I think there must be - below some minimum power, pretty much anything
must go in most bands; otherwise, things like spark plugs in car
engines would be illegal because they splatter a little power all
across the RF spectrum. (Not much power, but pretty much clear across
the band.)
However, it may be that, instead, there's a carveout for radiation
which is incidental rather than a primary function, and not
information-carrying, or some such. I know little-to-nothing about the
relevant regulations in any jurisdiction, and they often don't make
logical sense.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
5:39 p.m.
Tony Duell wrote:
Y'know, I remember electronics kits as a kid always seemed to include both an
AM transmitter and receiver project...
The Philips EE series of kits had reciever projects, but I don't think
there was a single transmitter. Many other kits did, indeed, have
low-power AM radio transmitter projects
If you
build something yourself (which would obviously then
meet the "maintainability" requirements), you could throw
Well, I am not going to make the radio modules myself (no way can I meet
type approval, even if I meet the technical specs) I'm sure they weren't legal, even back then -
unless there is (or was) some
loophole for devices with really limited range/power.
I am pretty sure they were technically illegal in the UK (I don't know
about other countries [1]), but that given the very low range (you were
lucky for it to work across a room), and the fact it wasn't likely to be
in operation for very long, then the chances of getting caught were
essentially 0 (I certainly never heard of anyone having problems ffrom
uilding such projects).
[1] Although I remember a warning in the manual for one such kit which
was something like 'Connecting a long antenna to this project will
violate FCC rules'
Longer-range devices, used for longer periods, as here, are a different
issue, of course.
-tony
6:15 p.m.
Tony Duell wrote:
Well, I am not going to make the radio modules myself
(no way can I
meet
type approval, even if I meet the technical specs), but I would
certainly consider making something _round_ said modules.
I assumed that you'd start with a module for the RF stuff: but
that's essentially no different to plonking a 7474 on a board
(you could build it from discretes, but there's a nice
convenient package ...)
Now that's something that had not really struck me
(which is why this
sort
of discussion on the list is so useful) -- that the file sizes I am
going
to be transfering _are_ limited. 128Mbytes is larger than the
available
mass storage (let alone RAM memory) on most of my classics, so except
in
very unusual ciercumstances, the data I wish to transfer is going to
be a
lot smaller than that. Which means a buffer is certainly an option.
I mentioned 128MB simply because it is the *smallest* SDRAM I have
to hand in any reasonable quantity (I have a handful of 32MB and
64MB). 512MB is cheap too. I don't know at what point you go beyond
the likely capacity of any classic. There's not a lot of point in
going this route with anything that has an ethernet connection. In
my case that would leave machines like a PET, C=64, RML 380Z
and so on. 128MB would be overkill for any of those.
Of course, the other issue is speed. Assuming 19200 baud that's
~2KiB/s on a good day. It would take a chunk of time to fill
128MB.
Does it need to be idriectional?
I wasn't sure how you envisaged using this mechanism. If it's
always the case that machine A "prints" to machine B (i.e. A
sends, B collects) then the modules do not strictly need to be
bidirectional. But I suspect that it would be much more convenient
to have a single style of module that does both "send" and
"receive" and then just build enough of them to handle
your needs. Otherwise the sender and receiver will always be
at the wrong ends of a 30' walk :-)
Antonio
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.524 / Virus Database: 269.23.10/1421 - Release Date:
07/05/2008 17:23
9 May
9 May
6:42 p.m.
Tony Duell wrote:
Indeed I would. There seem to be fairly dumb modules, and those Xbee
things, and the latter are not significantly more expensive or harder to use.
Well, I am not going to make the radio modules
myself (no way can I
meet
type approval, even if I meet the technical specs), but I would
certainly consider making something _round_ said modules.
I assumed that you'd start with a module for the RF stuff: but that's essentially no different to plonking a 7474
on a board
(you could build it from discretes, but there's a nice
convenient package ...)
there is one difference. The 74x74 schematics -- to component level --
are in the data sheet. The internals of these radio modules are not
disclosed anywhere from what I can see. Which might matter if either the
system doesn't behave in the way I expect, or if I am trying to do
soemthign unconventional with it.
And of course testing a 74x74 is a lot easier than testing a radio module
with an embedded microprocessor.
Now that's something that had not really
struck me (which is why this
sort
of discussion on the list is so useful) -- that the file sizes I am
going
to be transfering _are_ limited. 128Mbytes is larger than the
available
mass storage (let alone RAM memory) on most of my classics, so except
in
very unusual ciercumstances, the data I wish to transfer is going to
be a
lot smaller than that. Which means a buffer is certainly an option.
I mentioned 128MB simply because it is the *smallest* SDRAM I have
to hand in any reasonable quantity (I have a handful of 32MB and
64MB). 512MB is cheap too. I don't know at what point you go beyond
the likely capacity of any classic. There's not a lot of point in going this route with anything that has an ethernet
connection. In
Well, assuming the machine you want to connect it to also has an ethernet
interface, and that you have suitable software on both machines already.
my case that would leave machines like a PET, C=64,
RML 380Z
and so on. 128MB would be overkill for any of those.
Of course, the other issue is speed. Assuming 19200 baud that's
~2KiB/s on a good day. It would take a chunk of time to fill
128MB.
I get it as about 19 hours (assuming 10 bits/character, so 1920
characters/second). For that sort of thing I'd want to split the trasnfer
up into smaller sections , so that if anything went wrong I wouldn't have
to do the whole lot again.
Does it need to be idriectional?
I wasn't sure how you envisaged using this mechanism. If it's
always the case that machine A "prints" to machine B (i.e. A
sends, B collects) then the modules do not strictly need to be
bidirectional. But I suspect that it would be much more convenient
10 May
10 May
4:43 a.m.
On Tue, 2008-05-06 at 22:42 +0100, Tony Duell wrote:
I'm fairly sure you could use something to fake the flow control lines.
My first thought would be to use some sort of microcontroller to buffer
a few bytes from the serial port, drop the link into tx, send them, and
go back to rx again.
This is basically what commercial 433/466MHz links do.
Gordon
It were me,
I'd probably look into Bluetooth- or Zigbee-based serial
extenders.
Yes, I have, and still am, considerign those. Somebody else suggested the
Xee module, I had haeard of that. But do any of them work without any
flow control lines back to the host? The simple radio module (on the
433MHz band) that I looked at certainly eneded the RTS/CTS flow control
or something equivalent. 
5 May
5 May
4:53 p.m.
On Monday 05 May 2008 15:55, Tony Duell wrote:
As I think most of you know, I have a fairly diverse
collection of
classic computers (I suspect some others do too).
Quite often I need to transfer data between 2 machines. Maybe to
download a file from this PC, which I've in turn downloaded from a web
site, to run on one of the classics. Maybe to print out some listing from
a classic. Whatever.
My machines vary in size from the pocket computers up to machines that
it's not practical to move. They're scattered throughout a house. They
are, alas, not in a machine room. Most of the machines (and all the ones
I want to consider for this) have an RS232 port, either built-in or as an
option (which I have). Most of the machines run kermit. Or I can simply
print to the RS232 port on one machine and capture the incoming
characters on the other
So, I think the problem reduces to 'how to interconnect RS232 ports'. let
me add some constraints :
Must work over a distance longer than the RS232 spec allows (i.e. the
answer is probably not 'A long RS232 cable' :-)).
What does the spec say about length with regard to that? I was of the
impression that you could get by with lower baud rates if you were using
longer cables.
Prefereably no cables at all. One solution I've
come up with is to use a
couple of line drivers and a long cable between them. A long cable that
my parents, or the cat, will get tangled up in :-(
Even as a temporary measure? I've got a couple of long wires running around
here...
No line-of-sight between the machines
Must work at 300 and 1200 baud. 110 and 9600 baud would be a bonus
At those (relatively) slow rates you should be able to do something fairly
easily, I'd think.
(Snip)
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
5:20 p.m.
Roy J. Tellason wrote:
This page makes interesting claims:
http://www.lammertbies.nl/comm/info/RS-232_specs.html
a whopping 500ft @ 9600baud (presumably using Cat5 cable or something of
similar quality)
Must work over
a distance longer than the RS232 spec allows (i.e. the
answer is probably not 'A long RS232 cable' :-)).
What does the spec say about length with regard to that? I was of the
impression that you could get by with lower baud rates if you were using
longer cables. 
5:25 p.m.
Roy J. Tellason wrote:
On Monday 05 May 2008 15:55, Tony Duell wrote:
I used to run a ppp link to a neighbors apartment at 115200. It was
about a 100 foot long shielded serial cable. Half duplex transfers ran
great, running heavy transfers in both directions would get errors,
which ppp would nicely recover from.
My big motivation at the time (1989 or so) was access to his laser
printer. I used to dump 150dpi full page images over that link. It was
slow, but reliable.
I have no idea what "the spec allows" but a shielded cable can get you a
long ways. :)
--
Tim Riker - http://Rikers.org/ - TimR at Debian.org
Embedded Linux Technologist - http://eLinux.org/
BZFlag maintainer - http://BZFlag.org/ - for fun!
????????u poo? ??n??u??s ?no? u? 8-??n s?
Must work over a distance longer than the RS232
spec allows (i.e. the
answer is probably not 'A long RS232 cable' :-)).
What does the spec say about length with regard to that? I was of the
impression that you could get by with lower baud rates if you were using
longer cables. 
6:43 p.m.
Tony Duell wrote:
So, I think the problem reduces to 'how to
interconnect RS232 ports'. let
me add some constraints :
Must work over a distance longer than the RS232 spec allows (i.e. the
answer is probably not 'A long RS232 cable' :-)).
Prefereably no cables at all.
Possibly a bit OTT but these guys seem to have what you want:
http://www.bb-elec.com/product_family.asp?familyid=145
"legacy" serial over WiFi.
I've used their RS232 <-> current loop converters, but no experience of
any of their products at this end of the complexity spectrum.
Adrian
6 May
6 May
5:52 p.m.
Possibly a bit OTT but these guys seem to have what
you want:
http://www.bb-elec.com/product_family.asp?familyid=145
At least 2 prolems :
1 : The price. It's looks like it'd cost me about $600 for a couple of
units. For that sort of mony, I'll run 'permanent' RS232 cables to all
the rooms where I hace classic computers...
2 : It appears I need an ethernet port to configure them. I really don't
fancy trying to write suitable configurtation software for one of my
PDP11s or PERQs...
-tony
1:25 p.m.
Must work over a distance longer than the RS232 spec
allows (i.e. the
answer is probably not 'A long RS232 cable' :-)).
Don't give up on long cables until you try them. Especially if the
drivers approach the spec's maximum voltages, serial lines work at
distances far greater than the spec says - the spec is pessimistic.
Few environments are as electrically noisy as what the spec is designed
for, and keeping the driving voltages near the maximums permitted
increases the noise margin substantially.
If a simple serial cable doesn't work, measure the voltage produced by
the drivers and add additional circuitry, if necessary, to jack it up
to the 12-15 volt range. It would probably help to decrease the output
impedance as much as the spec allows, too. (I'm sure you, of all
people, don't need to be told how to do either one. :)
At one point, years ago, my house netlink was run over a four-wire
"metallic circuit", which was then-telco-speak for dry copper the whole
run, without any loading or equialization or such. While I did use
modems for normal use, I fould I could run it at something like 50 baud
without any modems at all - and that was probably two miles or so of
(POTS quality) wire.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
7 May
7 May
5:03 a.m.
I have been using a pair of wireless modems for just this, they are on the
somewhat slower side, maxing out at 14.4 in async mode, but atleast I dont
have to roll out long serial cables, I got them for free, meant for some
industrial application, seems they can run as rs485,
http://www.l-com.com/productfamily.aspx?id=2893 . Rather expensiv if its
just to be more conviendent than running cables over the floor.
Regards Jacob Dahl Pind
10 May
10 May
4:03 a.m.
On Mon, 5 May 2008 20:55:51 +0100 (BST)
ard at p850ug1.demon.co.uk (Tony Duell) wrote:
Must work over a distance longer than the RS232 spec
allows (i.e. the
answer is probably not 'A long RS232 cable' :-)).
Prefereably no cables at all.
Build two RS232 to Ethernet translators using e.g.
this:
http://www.lochraster.org/etherrape/
(Atmel AVR microcontoler based SBC with various interfaces like RS232,
Ethernet, I2C, IR, ... Completely open with shematics and software
source.)
If you got it to work with an Ethernet cable between them replace the
cable with a pair of cheap, used 11 MBit/s wireless accesspoints in
bridging mode. (I.e. the accesspoints are transparent to the Ethernet.)
--
tsch__,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
11 May
11 May
9:14 a.m.
Tony Duell wrote:
As I think most of you know, I have a fairly diverse
collection of
classic computers (I suspect some others do too).
...
Must not make use of any flow control lines on the
RS232 port, since some
of my machines don't support them.
...
Using classic, or at least repairable, hardwre is a
bonus :-)
...
I said 'RS232'. I mean asynchronous serial, of
course :-). If somebody
has a solution for TTL or 3.3V level serial ports, I can trivially
convert the signal levels
...
I've been looking at some of the license-exempt
radio modules, but they
either are half-duplex or amke use of the flow control lines (typically
they buffer <n> bytes internally, then de-assert a flow control line
while they pack up that data and send it to the other end).
Any other ideas?
Well, here's what I'd do, which you might not agree with.
I'd wire up as much of the house with plain old CAT-5 cable, and use
RS232 to CAT-5 conversion plugs. Then I'd have either a patch panel or
a terminal server in a central place. If you need to connect two
machines, connect an ethernet cable between two ports of the patch
panel. Alternatively, if you want them to talk to a modern machine,
you could either connect the modern machine to the patch panel, or if
you don't want to bother plugging things in all the time, plug all of
the ports into the terminal server.
(Finding someone with an old terminal server they're wanting to upgrade
is a possibility here. There's also a slightly better option of finding
classic Hostess multi-port serial cards in ISA form and running them on
an old XT with say Xenix or an early BSD or Linux and using that as both
storage server and as a terminal server - you could use the rzsz or
kermit programs to transfer data for example. The guys that used to run
BBS's on PC's might still have these boards in storage for example.)
For areas where you don't want to wire, or can't wire through walls, you
could go wireless. I'd use cheap game console ethernet to 802.11b
converters connected to single port terminal servers - or if there are
several machines next to each other in an area where you can't wire from
a distance, a multi-port terminal server.
While you might think that some places might be hard or impossible to
wire, if you look a bit deeper, you might be able to go through the
attic, a basement, parallel or through heating/cooling ducts, or even
outside the house. In this case, I'd strongly suggest shielded CAT-5.
This is how I've wired my house for ethernet - I moved in before the
proliferation of WiFi, so it wasn't a consideration. I ran shielded
Cat 5 from the attic which is my computer room all over the house.
Several lines went down next to the central staircase - just stapled to
the stairs, down through the basement and into the den and living room,
others went through the ceiling of the garage into the kitchen and along
side the walls. (Besides, despite the low wattage of 802.11b/g, I'm not
so sure I'd want my kids bombarded with what are essentially
microwaves. Had 802.11a been a bit more successful, I might have gone
that route since it's outside of the resonance frequency of water.)
Perhaps some combination of these things will work best - personally,
for your specific project I'd favor the CAT-5 with one (or more) ports
to each machine going to a central patch panel as it offers the highest
flexibility. Adding a terminal server or several would depend on how
much of a need you'd have for it and whether you could find agreeable ones.
Some of the early terminal servers did stupid things such as sending a
break signal to every port when they were power cycled, these caused
havoc to Sun machines (and I imagine anything else that dropped into a
debugger or equivalent) when they received these on their consoles.
Others won't let you tie two ports together, and others won't work at
low speeds. So perhaps a PC with several multi-port serial boards is best.
5893
days inactive
5899
days old
75 comments
27 participants
participants (27)
-
apw＠adrianwise.co.uk -
arcarlini＠iee.org -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
bpope＠wordstock.com -
cisin＠xenosoft.com -
dkelvey＠hotmail.com -
doc＠mdrconsult.com -
dr.emiel＠xs4all.nl -
drb＠msu.edu -
eric＠brouhaha.com -
ethan.dicks＠usap.gov -
gordonjcp＠gjcp.net -
hilpert＠cs.ubc.ca -
jfoust＠threedee.com -
jkunz＠unixag-kl.fh-kl.de -
jules.richardson99＠gmail.com -
legalize＠xmission.com -
mcguire＠neurotica.com -
mloewen＠cpumagic.scol.pa.us -
mouse＠Rodents.Montreal.QC.CA -
pat＠computer-refuge.org -
rachael＠telefisk.org -
ray＠arachelian.com -
rtellason＠verizon.net -
slawmaster＠gmail.com -
Tim＠Rikers.org