9 Feb
2025
9 Feb
'25
6:08 p.m.
I was about to ask if anyone ever built a "Parallel Modem" - but I searched
around first, and lo and behold, Microcom did ! (v.fast / v.34 era, c.
1996)
The drivers refer to Win3.1/Win95 era (I'm not seeing where they had DOS
support).
But I'm still not sure if I'm understanding the product (which I found
described here
Microcom Parallel Port Modem <https://strom.com/pubwork/cw294.html>
From a programming perspective, you just set your parallel bits and mash
the STROBE pin, right? Then figure some reasonable delay between
iterations of doing that. You don't need starts/stop or parity bits. So
I get how that is more efficient (but question is, why wasn't it built
sooner? I think it's a long answer when you look at the historical build up
of modems, and that serial-port based modems were "fast enough" at the time)
So.. If you had a slow system that couldn't really take advantage of a
~7MHz 16550 serial card (or I guess like a laptop that was stuck with an
older UART) That might be the use-case where this parallel v.fast might
help (by being able to "feed the modem" fast enough to actually take
advantage of the faster modem speed?) Or is there some other scenario
NOTE, in the articled linked above, it does mention that it is only "value
added" if you have this parallel-modem on both sides of the connection.
(this is because you'll be flow controlled to whatever is the slower device
in the connection?)
Related but different question:
Is there any "natural rate" (Hz) of a modem? Meaning is 1200/2400
baud-equivalent modem an accelerated-by-enhanced-encoding version of 300
bps? and 9600 likewise an accelerated-by-encoding version of 2400? is
300bps itself some kind of special accelerated-by-encoding? I see 1200
baud was also still sub 3KHz (did any modem protocol go above 3KHz?).
Or maybe I need to ask it this way: did 300 baud modems use a more 1:1
translation of the data-word bits into Hz signal over the modem (giving a
more "natural" translation rate?) But then beyond that speed, does a modem
need to "cache" a few bytes and determine some encoding scheme to then give
modems an apparent speed boost? (is that "kind-of" like USB's 8B/10B?
(not in implementation, but in the general concept that a different
encoding can result in improved data throughput, without actual faster
movement of that data?)
I guess it gets into the "secret sauce" approaches of how vendors figured
out these encoding approaches (v.32bis, etc), and give their product
competitive advantages (but only if you could convince enough ISPs to adopt
your protocol, by buying your modem device).
My daughter made me finally watch Blackberry recently, it's an interesting
telling of that story (of a small business selling their tech to USR, and
also that they tackled a version of encryption)
-Steve
9 Feb
9 Feb
7:24 p.m.
Hi Steve,
In my opinion that article leaves a LOT to be desired from a technical standpoint. I
think a lot of the stuff he states as facts are misleading at best.
I remember when those came out. IIRC they were mostly marketed toward laptops without
serial ports. But as stated some desktops did use problematic (slow) 8250 UARTs which had
trouble over 9600bps.
> So.. If you had a slow system that couldn't really take advantage of a
> ~7MHz 16550 serial card (or I guess like a laptop that was stuck with an
> older UART) That might be the use-case where this parallel v.fast might
> help (by being able to "feed the modem" fast enough to actually take
> advantage of the faster modem speed?) Or is there some other scenario
As hinted at above, it is probably a faster system (cpu wise) that could do the best with
a parallel modem. Keep in mind, the modem MUST have the equivalent of a uart built in.
But three writes for each byte and probably 3 or 4 reads per byte will slow down a slower
computer.
> NOTE, in the articled linked above, it does mention that it is only "value
> added" if you have this parallel-modem on both sides of the connection.
> (this is because you'll be flow controlled to whatever is the slower device
> in the connection?)
Reading that stuff made me wonder if microcom was paying him. I find that a wee bit
fishy.
Anyway. My 1/2 cent worth.
Will
On 02/09/2025 1:08 PM EST Steve Lewis via cctalk
<cctalk(a)classiccmp.org> wrote:
From a programming perspective, you just set your
parallel bits and mash
the STROBE pin, right? Then figure some reasonable delay between
iterations of doing that. You don't need starts/stop or parity bits. So
Writing to a UART (e.g. 8250, 16450, etc) is in general faster than writing to a parallel
port. For the uart, you simply write a byte and you're done. As you say, for the
parallel port, you write the data, then you have to write the control port to turn on
strobe, then write the control port again to turn it off, possibly with (short) delays in
between. You probably need to read a status from both to see if the port is ready, but
that is similar in both cases.
Reading is even worse. A "standard" parallel port only had 4(or 5) input bits
so you had to read at least twice to get a byte. Also, many of the pins were open
collector (resistor pullups) intended to drive longish external cables, so that made the
parallel port itself relatively slow. But plenty fast for V34.
7:35 p.m.
On Feb 9, 2025, at 1:08 PM, Steve Lewis via cctalk
<cctalk(a)classiccmp.org> wrote:
I was about to ask if anyone ever built a "Parallel Modem" - but I searched
around first, and lo and behold, Microcom did ! (v.fast / v.34 era, c.
1996)
I don't know what "parallel modem" would mean. Can you explain?
...Related but different question:
Is there any "natural rate" (Hz) of a modem? Meaning is 1200/2400
baud-equivalent modem an accelerated-by-enhanced-encoding version of 300
bps? and 9600 likewise an accelerated-by-encoding version of 2400? is
300bps itself some kind of special accelerated-by-encoding? I see 1200
baud was also still sub 3KHz (did any modem protocol go above 3KHz?).
Or maybe I need to ask it this way: did 300 baud modems use a more 1:1
translation of the data-word bits into Hz signal over the modem (giving a
more "natural" translation rate?) But then beyond that speed, does a modem
need to "cache" a few bytes and determine some encoding scheme to then give
modems an apparent speed boost? (is that "kind-of" like USB's 8B/10B?
(not in implementation, but in the general concept that a different
encoding can result in improved data throughput, without actual faster
movement of that data?)
For the most part the answer is "no".
The job of a modem is to carry a digital signal over a wire, at a given speed and given
level of data integrity, and with a given channel bandwidth.
When the channel bandwidth in Hz is well above the bit rate in bps, the job is easy, an
FSK modem can do the job. That's what the first modems looked like (and perhaps even
earlier devices used to deal with radio transmission for Baudot teleprinters, commonly
referred to as "tuning units").
When data rates go up and bandwidth doesn't, you need more complex modulation schemes.
Modulating a carrier produces sidebands, so roughly speaking your baud rate can't
exceed half the channel bandwidth. (I'm sure I'm handwaving a lot here.) You
can't do 9600 bps FSK in a voice channel, it won't fit. It would fit just fine if
you have a 40 kHz channel, so it's certainly possible to do FSK over VHF radio at that
speed if you're authorized that much bandwidth.
So for high speed on a telephone line the exercise becomes "more bits per baud"
-- not one bit per signal element as you get from FSK or PSK, but two (QPSK) or 4 (QAM16)
or even 8 (QAM256). Note that those hairy modulation schemes require a pretty clean
channel; you're not likely to find them on shortwave radio systems for that reason.
Indeed, doing data transmission over radio is an entirely separate art with a host of
interesting and exotic methods. Some of them can reliably send data using transmission
weak enough you can't hear them if you listen to the signal with an ordinary audio
receiver.
paul
11:04 p.m.
Interesting stuff. I ran a BBS in the early 1990s - but I never really
dug into the technicals of how a modem worked.
So, I'll describe a Parallel Modem like this: how the data from your PC
is sent/received to/from the modem is independent of how that same data is
communicated over the (then) copper phone line.
As Will mentioned, if you didn't have a local UART, then you could instead
put that hardware on the modem side and let it handle the byte-to-bit
translation. But ever since the IBM PC (and really even a few years
earlier, as I'm reading about the S-100 serial card of the POLY-88 c. 1976,
or the 0.916Hz clocked UART used on late model PDP's), nearly every system
had a serial card with a "local UART" (or similar, like the VIA/PIA
shift-register some other economy systems used; these shifters can let you
kind of "emulate a UART in software" by at least doing the byte-to-bit
conversion for you, you just have to bit-twiddle in the start/stop bits
yourself).
So why add that cost into a modem (of an additional UART that an end-users
probably already has), and also: what would you connect it to? If you
connect it to a serial port, then you've defeated the whole purpose. Well,
a UART itself is basically a parallel device (from the bus lines to the
processor - or memory?). So if you built such a thing, it would make sense
to connect it to the host systems parallel port. Hence, a parallel-modem
is just one that send/receives its byte across a parallel-port connection.
There is a cross-over point where the performance of the local system (a
combination of its raw CPU speed, memory, and getting data from a hard
drive into said memory) isn't suitable - maybe less so on the TX/send side,
but moreso on the RX/receive side. The article mentioned is talking
486-era systems. In the early days, a 1MHz CPU system would be "bogged
down" on something as "simple" as scrolling the screen. By the time of
486-days, a system would be bogged down by normal multi-tasking (not Win95
style, but maybe OS/2?). But as mentioned, a UART is a mostly "fire and
forget" thing - write your byte, it gets packed into start/data/parity/stop
sequence (the data probably reversed). But on the receive side, your
system has to do something with the data, and do it before the UART FIFO
becomes full (or better, before it becomes halfway full).
The modem gets that byte, strips off the "extra" bits, reverses the data
back, and modulates it on out (at a rate that
it-and-whatever-modem-it-has-connected-to has negotiated as an acceptable
speed; your serial port might be set to 19200, but that BBS on the other
end might be using a 2400 baud modem; hence all that modem-noise during an
initial connection as they fight it out, and the BBS-host software might
spew a few garbage bytes as it tries to match on its serial connection and
asks "can you comprehend me now?" type questions; in the end, your Carrier
Detect lights goes on).
But, you're right - I'm still not yet rationalizing out how this
parallel-connected-modem would help (even if a corporate or classroom
scenario, with a room of 50 systems). I do know that "laplink" style
parallel cables were said to be faster than null-modem cables in raw data
transfer between systems. BTW, every "DB25" connector in the PC world
I've
seen, it's got 8-pins for data. Even the UserPort in the Commodore world
has that - I've not commonly seen 4-data-pin parallel cables? So yes, you
could "talk to a modem faster" using a parallel exchange (is it faster
because of the 8-data-pins or faster because of not having to deal with the
start/parity/stop bits? or both).
-Steve
On Sun, Feb 9, 2025 at 1:35 PM Paul Koning <paulkoning(a)comcast.net> wrote:
On Feb 9, 2025, at 1:08 PM, Steve Lewis via
cctalk <
cctalk(a)classiccmp.org> wrote:
I was about to ask if anyone ever built a "Parallel Modem" - but I
searched
around first, and lo and behold, Microcom did !
(v.fast / v.34 era, c.
1996)
I don't know what "parallel modem" would mean. Can you explain?
...Related but different question:
Is there any "natural rate" (Hz) of a modem? Meaning is 1200/2400
baud-equivalent modem an accelerated-by-enhanced-encoding version of 300
bps? and 9600 likewise an accelerated-by-encoding version of 2400? is
300bps itself some kind of special accelerated-by-encoding? I see 1200
baud was also still sub 3KHz (did any modem protocol go above 3KHz?).
Or maybe I need to ask it this way: did 300 baud modems use a more 1:1
translation of the data-word bits into Hz signal over the modem (giving a
more "natural" translation rate?) But then beyond that speed, does a
modem
need to "cache" a few bytes and
determine some encoding scheme to then
give
modems an apparent speed boost? (is that
"kind-of" like USB's 8B/10B?
(not in implementation, but in the general concept that a different
encoding can result in improved data throughput, without actual faster
movement of that data?)
For the most part the answer is "no".
The job of a modem is to carry a digital signal over a wire, at a given
speed and given level of data integrity, and with a given channel bandwidth.
When the channel bandwidth in Hz is well above the bit rate in bps, the
job is easy, an FSK modem can do the job. That's what the first modems
looked like (and perhaps even earlier devices used to deal with radio
transmission for Baudot teleprinters, commonly referred to as "tuning
units").
When data rates go up and bandwidth doesn't, you need more complex
modulation schemes. Modulating a carrier produces sidebands, so roughly
speaking your baud rate can't exceed half the channel bandwidth. (I'm sure
I'm handwaving a lot here.) You can't do 9600 bps FSK in a voice channel,
it won't fit. It would fit just fine if you have a 40 kHz channel, so it's
certainly possible to do FSK over VHF radio at that speed if you're
authorized that much bandwidth.
So for high speed on a telephone line the exercise becomes "more bits per
baud" -- not one bit per signal element as you get from FSK or PSK, but two
(QPSK) or 4 (QAM16) or even 8 (QAM256). Note that those hairy modulation
schemes require a pretty clean channel; you're not likely to find them on
shortwave radio systems for that reason. Indeed, doing data transmission
over radio is an entirely separate art with a host of interesting and
exotic methods. Some of them can reliably send data using transmission
weak enough you can't hear them if you listen to the signal with an
ordinary audio receiver.
paul
11:27 p.m.
On Sun, 9 Feb 2025, Steve Lewis via cctalk wrote:
BTW, every "DB25" connector in the PC world
I've
seen, it's got 8-pins for data. Even the UserPort in the Commodore world
has that - I've not commonly seen 4-data-pin parallel cables?
The stock IBM 5150 parallel port has 8 pins of data. BUT, that's 8 pins
of OUTPUT (plus 4 pins of handshake)
The "handshake" lines could be used as input, but not the data lines.
THAT is why you hear "only 4 pins of data input"
BUT, there is a trivial hardware modification that you can make to the IBM
5150 parallel port to make the 8 data pins usable as bi-directional.
(Many aftermarket parallel ports doo not need that nodification)
The need for that modificaation is WHY you keep hearing that the parallel
port only has four bits of input.
IFF you make a "Centronics" TO parallel port adapter (36 pin female blue
ribbon input to 25 pin DB25 male output with appropriate wiring in the
adapter, then it is possible to be able to take a machine that has
parallel [Centronics compatible] output, but no serial port, etc. (there
did used to be such!)
And tell it that it is connected to a printer. The PC would then need to
act as a "printer emulator", to take incoming data from the parallel port
and save it. I built such 30+ years ago, but I never got the software to
be adequate to make it a commercial product. Hardly anybody could even
uderstand what or why it was.
'course, you could accomplish the same task with an external parallel to
serial printer buffer, and come in through the serial port.
--
Grumpy Ol' Fred cisin(a)xenosoft.com
10 Feb
10 Feb
3:27 a.m.
The stock IBM 5150 parallel port has 8 pins of data. BUT, that's 8 pins
of OUTPUT (plus 4 pins of handshake)
The "handshake" lines could be used as input, but not the data lines.
THAT is why you hear "only 4 pins of data input"
Thanks for the clarification. Had forgotten about all that.
On Sun, Feb 9, 2025 at 5:27 PM Fred Cisin via cctalk <cctalk(a)classiccmp.org>
wrote:
> On Sun, 9 Feb 2025, Steve Lewis via cctalk wrote:
> > BTW, every "DB25" connector in the PC world I've
> > seen, it's got 8-pins for data. Even the UserPort in the Commodore world
> > has that - I've not commonly seen 4-data-pin parallel cables?
The stock IBM 5150 parallel port has 8 pins of data. BUT, that's 8 pins
of OUTPUT (plus 4 pins of handshake)
The "handshake" lines could be used as input, but not the data lines.
THAT is why you hear "only 4 pins of data input"
>
> BUT, there is a trivial hardware modification that you can make to the IBM
> 5150 parallel port to make the 8 data pins usable as bi-directional.
> (Many aftermarket parallel ports doo not need that nodification)
> The need for that modificaation is WHY you keep hearing that the parallel
> port only has four bits of input.
>
> IFF you make a "Centronics" TO parallel port adapter (36 pin female blue
> ribbon input to 25 pin DB25 male output with appropriate wiring in the
> adapter, then it is possible to be able to take a machine that has
> parallel [Centronics compatible] output, but no serial port, etc. (there
> did used to be such!)
> And tell it that it is connected to a printer. The PC would then need to
> act as a "printer emulator", to take incoming data from the parallel port
> and save it. I built such 30+ years ago, but I never got the software to
> be adequate to make it a commercial product. Hardly anybody could even
> uderstand what or why it was.
>
> 'course, you could accomplish the same task with an external parallel to
> serial printer buffer, and come in through the serial port.
>
> --
> Grumpy Ol' Fred cisin(a)xenosoft.com
>
9 Feb
9 Feb
11:57 p.m.
On Sun, Feb 9, 2025, 4:04 PM Steve Lewis via cctalk <cctalk(a)classiccmp.org>
wrote:
Interesting stuff. I ran a BBS in the early 1990s -
but I never really
dug into the technicals of how a modem worked.
So, I'll describe a Parallel Modem like this: how the data from your PC
is sent/received to/from the modem is independent of how that same data is
communicated over the (then) copper phone line.
As Will mentioned, if you didn't have a local UART, then you could instead
put that hardware on the modem side and let it handle the byte-to-bit
translation. But ever since the IBM PC (and really even a few years
earlier, as I'm reading about the S-100 serial card of the POLY-88 c. 1976,
or the 0.916Hz clocked UART used on late model PDP's), nearly every system
had a serial card with a "local UART" (or similar, like the VIA/PIA
shift-register some other economy systems used; these shifters can let you
kind of "emulate a UART in software" by at least doing the byte-to-bit
conversion for you, you just have to bit-twiddle in the start/stop bits
yourself).
So why add that cost into a modem (of an additional UART that an end-users
probably already has), and also: what would you connect it to? If you
connect it to a serial port, then you've defeated the whole purpose. Well,
a UART itself is basically a parallel device (from the bus lines to the
processor - or memory?). So if you built such a thing, it would make sense
to connect it to the host systems parallel port. Hence, a parallel-modem
is just one that send/receives its byte across a parallel-port connection.
There is a cross-over point where the performance of the local system (a
combination of its raw CPU speed, memory, and getting data from a hard
drive into said memory) isn't suitable - maybe less so on the TX/send side,
but moreso on the RX/receive side. The article mentioned is talking
486-era systems. In the early days, a 1MHz CPU system would be "bogged
down" on something as "simple" as scrolling the screen. By the time of
486-days, a system would be bogged down by normal multi-tasking (not Win95
style, but maybe OS/2?). But as mentioned, a UART is a mostly "fire and
forget" thing - write your byte, it gets packed into start/data/parity/stop
sequence (the data probably reversed). But on the receive side, your
system has to do something with the data, and do it before the UART FIFO
becomes full (or better, before it becomes halfway full).
The modem gets that byte, strips off the "extra" bits, reverses the data
back, and modulates it on out (at a rate that
it-and-whatever-modem-it-has-connected-to has negotiated as an acceptable
speed; your serial port might be set to 19200, but that BBS on the other
end might be using a 2400 baud modem; hence all that modem-noise during an
initial connection as they fight it out, and the BBS-host software might
spew a few garbage bytes as it tries to match on its serial connection and
asks "can you comprehend me now?" type questions; in the end, your Carrier
Detect lights goes on).
But, you're right - I'm still not yet rationalizing out how this
parallel-connected-modem would help (even if a corporate or classroom
scenario, with a room of 50 systems). I do know that "laplink" style
parallel cables were said to be faster than null-modem cables in raw data
transfer between systems. BTW, every "DB25" connector in the PC world
I've
seen, it's got 8-pins for data. Even the UserPort in the Commodore world
has that - I've not commonly seen 4-data-pin parallel cables? So yes, you
could "talk to a modem faster" using a parallel exchange (is it faster
because of the 8-data-pins or faster because of not having to deal with the
start/parity/stop bits? or both).
Not necessarily. Uarts work great for dialup because the fifo handles all
the offload from the CPU. Parallel ports are half duplex with terrible
async interfaces to get the CPU's attention. Also, the bit banging you need
to do is CPU inefficient. While there were layer DMA things, they were all
half duplex too. The Parallel Port is great when you are dumping images to
the page. Or when you send a request and expect a reply soon. It's not so
good for having random characters show up, maybe in the middle of sending
data... and the modem would need a buffet which would make latence
interesting. After dealing with parallel port zip drives and ethernet
drivers (which had the same issues a parallel modem wiuld have had), i love
the simplicity of the 16550 UART interface. So possible, but a boatload
more driver code and some tricky timing and compat issues.
Warner
-Steve
On Sun, Feb 9, 2025 at 1:35 PM Paul Koning <paulkoning(a)comcast.net> wrote:
300
8B/10B?
bandwidth.
On Feb 9, 2025, at 1:08 PM, Steve Lewis via
cctalk <
cctalk(a)classiccmp.org> wrote:
I was about to ask if anyone ever built a "Parallel Modem" - but I
searched
around first, and lo and behold, Microcom did !
(v.fast / v.34 era, c.
1996)
I don't know what "parallel modem" would mean. Can you explain?
> ...Related but different question:
>
> Is there any "natural rate" (Hz) of a modem? Meaning is 1200/2400
> baud-equivalent modem an accelerated-by-enhanced-encoding version of
> bps? and 9600 likewise an
accelerated-by-encoding version of 2400?
is
> 300bps itself some kind of special
accelerated-by-encoding? I see
1200
> baud was also still sub 3KHz (did any modem
protocol go above 3KHz?).
>
> Or maybe I need to ask it this way: did 300 baud modems use a more 1:1
> translation of the data-word bits into Hz signal over the modem
(giving a
more
"natural" translation rate?) But then beyond that speed, does a
modem
need to "cache" a few bytes and
determine some encoding scheme to then
give
> modems an apparent speed boost? (is that "kind-of" like USB's
(not in
implementation, but in the general concept that a different
encoding can result in improved data throughput, without actual faster
movement of that data?)
For the most part the answer is "no".
The job of a modem is to carry a digital signal over a wire, at a given
speed and given level of data integrity, and with a given channel
When the channel bandwidth in Hz is well above the bit rate in bps, the
job is easy, an FSK modem can do the job. That's what the first modems
looked like (and perhaps even earlier devices used to deal with radio
transmission for Baudot teleprinters, commonly referred to as "tuning
units").
When data rates go up and bandwidth doesn't, you need more complex
modulation schemes. Modulating a carrier produces sidebands, so roughly
speaking your baud rate can't exceed half the channel bandwidth. (I'm
sure
I'm handwaving a lot here.) You can't do
9600 bps FSK in a voice
channel,
it won't fit. It would fit just fine if you
have a 40 kHz channel, so
it's
certainly possible to do FSK over VHF radio at
that speed if you're
authorized that much bandwidth.
So for high speed on a telephone line the exercise becomes "more bits per
baud" -- not one bit per signal element as you get from FSK or PSK, but
two
(QPSK) or 4 (QAM16) or even 8 (QAM256). Note
that those hairy modulation
schemes require a pretty clean channel; you're not likely to find them on
shortwave radio systems for that reason. Indeed, doing data transmission
over radio is an entirely separate art with a host of interesting and
exotic methods. Some of them can reliably send data using transmission
weak enough you can't hear them if you listen to the signal with an
ordinary audio receiver.
paul
10 Feb
10 Feb
12:47 a.m.
On Sun, 9 Feb 2025, Paul Koning via cctalk wrote:
In the simplest case I can certainly envisage delegating the input and
output shift registers to an integrated external modem unit talking some
kind of protocol (which could be Hayes even at the software level) to the
host computer over a parallel port, just as printers used to, some even
offering the choice between a parallel and a serial connection.
A UART could then be integrated within the external unit, or skipped
altogether, just as it used to be the case with "winmodems" where all the
modulation/demodulation stuff was done directly by the host CPU and sent
or received to or from the modem chipset just for DCA/ADC conversion, such
as with sound cards (the MC'97 codec standard was developed exactly for
this purpose, complementing AC'97 for audio devices).
Maciej
I was about to
ask if anyone ever built a "Parallel Modem" - but I searched
around first, and lo and behold, Microcom did ! (v.fast / v.34 era, c.
1996)
I don't know what "parallel modem" would mean. Can you explain? 
12:09 a.m.
On Sun, Feb 09, 2025 at 12:08:47PM -0600, Steve Lewis via cctalk wrote:
[...]
So.. If you had a slow system that couldn't really
take advantage of a
~7MHz 16550 serial card (or I guess like a laptop that was stuck with an
older UART) That might be the use-case where this parallel v.fast might
help (by being able to "feed the modem" fast enough to actually take
advantage of the faster modem speed?) Or is there some other scenario
Note that all but the dumbest modems reclock the data before transmission
and the XON/XOFF or CTS/RTS flow control is handled locally, buffering in
the modem as necessary. At faster speeds there's no longer a 1:1
relationship between the signal level on the RS-232 cable and the screeches
going down the phone line. Start and stop bits are not transmitted, giving a
25% speed boost from that alone.
A parallel-connected modem is a bit pointless except in weird environments
where one's serial port is broken or otherwise unusable. Information theory
tells us that you can't get more than 64kb/s out of a dialup link, because
that's the speed of the underlying digital channel used by the PSTN. Due to
the reclocking, you actually need a serial port capable of 80kbaud to not
drop data, and the next-highest standard baud rate is 115,200 baud, which
any half-decent PC serial port can handle.
To pre-empt the obvious retorts from the peanut gallery, sure, one may well
have an original IBM XT or BBC Micro or whatever whose serial port drops
bytes when driven faster than 9600 baud. Guess what: the machine's so slow
that it can't handle the firehose of data even if its serial port wasn't a
basket case.
I don't know where you get "~7MHz 16550 serial card" from. The 16550 (and
predecessors) sample the incoming serial signal with a clock 16x the baud
rate. For 115,200 baud, that's 1.8432MHz, and it is no coincidence that this
is a standard crystal frequency and also the maximum speed of a lot of
UARTs.
[...]
Is there any "natural rate" (Hz) of a modem?
Meaning is 1200/2400
baud-equivalent modem an accelerated-by-enhanced-encoding version of 300
bps? and 9600 likewise an accelerated-by-encoding version of 2400? is
300bps itself some kind of special accelerated-by-encoding? I see 1200
baud was also still sub 3KHz
These easy-to-ask questions have very long answers. But mostly, it was *not*
a case of merely increasing the baud rate or the number of bits per baud
with a different modulation scheme, but multiple concurrent advances which
did those *plus* some other techniques which would maintain signal integrity
despite the reduced SNR.
If you want the full gory detail, the relevant ITU standards are
freely-available. Bring a good signal-processing textbook.
(did any modem protocol go above 3KHz?).
V.90 used the full 4kHz analogue bandwidth for the downstream. Yes, even the
frequency extremes which were heavily-attenuated by the line filters. It'd
just listen much harder.
3:01 a.m.
I don't know where you get "~7MHz 16550 serial card" from. The 16550 (and
predecessors) sample the incoming serial signal with a clock 16x the baud
rate. For 115,200 baud, that's 1.8432MHz, and it is no coincidence that
this
is a standard crystal frequency and also the maximum speed of a lot of
UARTs.
I was meaning something like the later modem SIIG serial cards that used a
7.3728 MHz clock (4x the 1.8432 "original"). I have one of these that is
combined with a 16550 UART.
Even before the IBM PC of c. 1981, I've come across PDP-11 systems with
3.6864MHz clocked UART (and some S-100 based systems, at this ~3 and also
~5 MHz clocks). Another PDP card that I have has a 0.9216 MHz clock (so
57600 bps cap). And yes, the PC-market settled on that 1.8432MHz tempo.
I just recently realized, the earlier POLY-88 system (8080-based) had a
"native" clock rate of exactly 1.8432 MHz, that being about 5 years earlier
than the IBM PC. So maybe it's not really fair to blame that on the pick
on IBM.
In my experience, a 12MHz '286 couldn't fully utilize the 1.8432MHz 8250
(i.e. in my testing, I was able to receive at 57600 over a null modem cable
on said '286, in a sustain {ZModem} stream without any errors; but at
115200 the system just got too many errors to be a worthwhile transfer).
That's how I mean there is a crossing point where the combined CPU, memory
speed, hard drive speed of the system is "under powered" for the full
potential of its UART. But it was a number of years before
"modulation-tech" modems blasted past even 9600 baud (at least at the
consumer level), so that 1.8432 MHz pick was fine for most of the 80's.
Bit of a tangent:
I noticed those modern-era FTDI USB/serial adapters, their specs list 128
byte FIFOs. Maybe those "parallel modem" Microm devices just had larger
onboard buffers, kind of "leap-frogging" the 16 byte buffer that many 16550
UARTs had? I've noticed those more modern FTDI USB/serial adapters have
128 bytes buffers (some 64 byte).
Anyway, if your multi-tasking 386 or 486 was struggling to support a higher
baud rate - I've read you could desolder a 8250 and plop in a 16550
directly, and gain the 16 byte buffer at least. If that still doesn't
help, then try one of those new 7.3728 MHz equipped 16550's?? In the
README docs included with the A00 FOSSIL driver c. 1990 (who ran a
multi-line FIDO BBS), I recall that author mentioning options like this -
and how it was the increase in multi-tasking operating systems causing
stability issues in older serial cards.
Anyway, the "parallel modem" is interesting in that makes it clear that
RS-232 isn't essential for modem communication. RS-232 was just a "means
to an end" of delivering data quickly to/from a modem device. I guess
using RS-232 gave the benefit that your modem didn't need to be physically
nearby (and I recall ISP offices where the modems in a closest down the
hall) - due to "screaming" at +/-12V ? This might be relevant in
situations where you didn't have a phone line in every room (not just in
homes, but also old offices)
-Steve
On Sun, Feb 9, 2025 at 6:18 PM Peter Corlett via cctalk <
cctalk(a)classiccmp.org> wrote:
> On Sun, Feb 09, 2025 at 12:08:47PM -0600, Steve Lewis via cctalk wrote:
> [...]
> > So.. If you had a slow system that couldn't really take advantage of a
> > ~7MHz 16550 serial card (or I guess like a laptop that was stuck with an
> > older UART) That might be the use-case where this parallel v.fast might
> > help (by being able to "feed the modem" fast enough to actually take
> > advantage of the faster modem speed?) Or is there some other scenario
>
> Note that all but the dumbest modems reclock the data before transmission
> and the XON/XOFF or CTS/RTS flow control is handled locally, buffering in
> the modem as necessary. At faster speeds there's no longer a 1:1
> relationship between the signal level on the RS-232 cable and the screeches
> going down the phone line. Start and stop bits are not transmitted, giving
> a
> 25% speed boost from that alone.
>
> A parallel-connected modem is a bit pointless except in weird environments
> where one's serial port is broken or otherwise unusable. Information theory
> tells us that you can't get more than 64kb/s out of a dialup link, because
> that's the speed of the underlying digital channel used by the PSTN. Due to
> the reclocking, you actually need a serial port capable of 80kbaud to not
> drop data, and the next-highest standard baud rate is 115,200 baud, which
> any half-decent PC serial port can handle.
>
> To pre-empt the obvious retorts from the peanut gallery, sure, one may well
> have an original IBM XT or BBC Micro or whatever whose serial port drops
> bytes when driven faster than 9600 baud. Guess what: the machine's so slow
> that it can't handle the firehose of data even if its serial port wasn't a
> basket case.
I don't know where you get "~7MHz 16550 serial card" from. The 16550 (and
predecessors) sample the incoming serial signal with a clock 16x the baud
rate. For 115,200 baud, that's 1.8432MHz, and it is no coincidence that
this
is a standard crystal frequency and also the maximum speed of a lot of
UARTs.
>
> [...]
> > Is there any "natural rate" (Hz) of a modem? Meaning is 1200/2400
> > baud-equivalent modem an accelerated-by-enhanced-encoding version of 300
> > bps? and 9600 likewise an accelerated-by-encoding version of 2400? is
> > 300bps itself some kind of special accelerated-by-encoding? I see 1200
> > baud was also still sub 3KHz
>
> These easy-to-ask questions have very long answers. But mostly, it was
> *not*
> a case of merely increasing the baud rate or the number of bits per baud
> with a different modulation scheme, but multiple concurrent advances which
> did those *plus* some other techniques which would maintain signal
> integrity
> despite the reduced SNR.
>
> If you want the full gory detail, the relevant ITU standards are
> freely-available. Bring a good signal-processing textbook.
>
> > (did any modem protocol go above 3KHz?).
>
> V.90 used the full 4kHz analogue bandwidth for the downstream. Yes, even
> the
> frequency extremes which were heavily-attenuated by the line filters. It'd
> just listen much harder.
>
>
11 Feb
11 Feb
4:32 p.m.
On Sun, Feb 09, 2025 at 09:01:51PM -0600, Steve Lewis via cctalk wrote:
[...]
In my experience, a 12MHz '286 couldn't fully
utilize the 1.8432MHz 8250
(i.e. in my testing, I was able to receive at 57600 over a null modem
cable on said '286, in a sustain {ZModem} stream without any errors; but
at 115200 the system just got too many errors to be a worthwhile
transfer). That's how I mean there is a crossing point where the combined
CPU, memory speed, hard drive speed of the system is "under powered" for
the full potential of its UART. But it was a number of years before
"modulation-tech" modems blasted past even 9600 baud (at least at the
consumer level), so that 1.8432 MHz pick was fine for most of the 80's.
The actual clock speed of the UART is an implementation detail. The limiting
factor to reliable PC serial throughput is often interrupt latency rather
than raw baud rate, and that is due to cheaping out on implementation and
not that the CPU is too slow to process a piddling 12K of data per second.
The 8250, 6551, Amiga serial port, etc do not have FIFOs and so generate one
interrupt per byte. The CPU has to respond to the interrupt and retrieve the
incoming byte before the next byte has arrived. At 9600 baud, that needs to
happen within 1ms. At 115,200 baud, it's 87µs.
Older operating systems -- especially from the era where non-FIFO serial
ports were still standard -- would leave interrupts disabled for extended
periods. It was a cheap way for single-CPU systems to perform
uninterruptable critical sections. A special kind of critical section is the
handling of some other interrupt (e.g. keyboard or disk). Thus the maximum
potential interrupt latency is increased by these little bits of work which
randomly pop up at inconvenient times. You would have probably observed that
the serial error rate increased during disk I/O.
1ms is a fairly reasonable rule-of-thumb for maximum interrupt latency on a
general-purpose computer of the mid-80s, and thus 9600 baud or so is about
all you're going to get reliably. So you could have an infinite UART clock
and infinite baud rate, but so long as the data comes in no faster than 1ms
per byte, it'll still work reliably. Your specific 286 was doing somewhat
better than that; perhaps your terminal client was disabling interrupts and
bit-banging the serial port during transmission of ZMODEM blocks.
(As to that 87µs, I wouldn't rely on even the latest whizz-bang machine to
consistently beat that deadline. The interrupt has to wend its way through
the PCI bridge and the IO-APIC, and then the CPU has to notice the
interrupt, then complete whatever work is stuck in the pipeline or otherwise
get into a state where it can do a mode switch and call the ISR. Most
interrupts will be handled in a handful of microseconds, and maybe even mere
hundreds of nanoseconds, but the worst-case interrupt latency is rather
closer to infinity than we'd all like. But this is classiccmp, not
moderncmp.)
Doubling the UART clock rate will double the maximum baud rate, but that
wins you nothing if the machine can't handle all of those interrupts in
time. In the case of the PC, it also means that the wrong value will be
programmed into the UART's divider for a given baud rate because a 1.8432MHz
base clock is assumed.
The proper solution to dodgy PC serial port performance was of course to
upgrade to the 16550 which had a FIFO which could buffer a few bytes while
the PC got round to answering the interrupt. It's not the greatest UART and
adds novel failure modes, but it does have the extremely useful property
that it is register-compatible with the 8250 and so older software can still
drive it without needing to be patched.
The 16550 (at 1.8432Mhz) still has the same top speed of 115,200 baud, but
that's just fine for the kind of applications which use physical
RS-232-compatible serial ports such as dialup modems and serial mice. RS-232
only guarantees up to 20 kilobaud anyway, and anything faster is out of spec
and works through luck. Fortunately, we had a lot of luck by the late 1990s
when V.90 dialup came around. Want to go even faster over long cable runs?
We have Ethernet for that sort of thing, and it's rather more reliable at
it.
4:49 p.m.
On 2025-02-11 9:32 a.m., Peter Corlett via cctalk wrote:
The proper solution to dodgy PC serial port
performance was of course to
upgrade to the 16550 which had a FIFO which could buffer a few bytes while
the PC got round to answering the interrupt. It's not the greatest UART and
adds novel failure modes, but it does have the extremely useful property
that it is register-compatible with the 8250 and so older software can still
drive it without needing to be patched.
I thought many 16550 had dud fifo's.
Interrupts under DOS was hit and miss.
The 16550 (at 1.8432Mhz) still has the same top speed
of 115,200 baud, but
that's just fine for the kind of applications which use physical
RS-232-compatible serial ports such as dialup modems and serial mice. RS-232
only guarantees up to 20 kilobaud anyway, and anything faster is out of spec
and works through luck. Fortunately, we had a lot of luck by the late 1990s
when V.90 dialup came around. Want to go even faster over long cable runs?
We have Ethernet for that sort of thing, and it's rather more reliable at
it.
Sneaker net with van is better yet, moving large data.(10 TB per tape) :).
5:44 p.m.
16450 was the one with buffer issues
On February 11, 2025 11:49:23 AM EST, ben via cctalk <cctalk(a)classiccmp.org> wrote:
On 2025-02-11 9:32 a.m., Peter Corlett via cctalk
wrote:
The proper solution to dodgy PC serial port
performance was of course to
upgrade to the 16550 which had a FIFO which could buffer a few bytes while
the PC got round to answering the interrupt. It's not the greatest UART and
adds novel failure modes, but it does have the extremely useful property
that it is register-compatible with the 8250 and so older software can still
drive it without needing to be patched.
I thought many 16550 had dud fifo's.
Interrupts under DOS was hit and miss.
The 16550 (at 1.8432Mhz) still has the same top
speed of 115,200 baud, but
that's just fine for the kind of applications which use physical
RS-232-compatible serial ports such as dialup modems and serial mice. RS-232
only guarantees up to 20 kilobaud anyway, and anything faster is out of spec
and works through luck. Fortunately, we had a lot of luck by the late 1990s
when V.90 dialup came around. Want to go even faster over long cable runs?
We have Ethernet for that sort of thing, and it's rather more reliable at
it.
Sneaker net with van is better yet, moving large data.(10 TB per tape) :).
12 Feb
12 Feb
5:09 p.m.
On Tue, 11 Feb 2025, Christopher Zach via cctalk wrote:
16450 was the one with buffer issues
The 16450 was hardly different from 8250:
"The NS 16450 is an improved specification version of the INS8250A
Universal Asynchronous Receiver/Transmitter (UART). The improved
specifications ensure compatibility with the NS32032 and other
state-of-the-art CPUs. Functionally, the NS16450 is equivalent to the
INS8250A."
The broken-FIFO one was the short-lived 16550, while 16550A was the fixed
one. Also I do believe it was NS, having been guilty for the broken FIFO,
that only used the 16550 vs 16550A terminology and other implementers just
called their functional-FIFO parts 16550, which is why people commonly say
16550 having one with a FIFO in mind.
Maciej
11 Feb
11 Feb
7:09 p.m.
On Tue, Feb 11, 2025 at 9:49 AM ben via cctalk <cctalk(a)classiccmp.org>
wrote:
Yea, 16550 compatible UARTs are still around, and go up to baud rates of
10Mbps at least in the embedded space where you often use it to jam in the
first bootstrap program (or the unbricking program).
Warner
On 2025-02-11 9:32 a.m., Peter Corlett via cctalk
wrote:
No. The 16550''s were good enough to do line rate 115200 on a 16MHz 386
under both FreeBSD and Linux (though the clist overhead was a little high
on FreeBSD in comparison to Linux).
The proper solution to dodgy PC serial port
performance was of course to
upgrade to the 16550 which had a FIFO which could buffer a few bytes
while
the PC got round to answering the interrupt.
It's not the greatest UART
and
adds novel failure modes, but it does have the
extremely useful property
that it is register-compatible with the 8250 and so older software can
still
drive it without needing to be patched.
I thought many 16550 had dud fifo's.
Interrupts under DOS was hit and miss.
The 16550 (at
1.8432Mhz) still has the same top speed of 115,200 baud,
but
that's just fine for the kind of applications
which use physical
RS-232-compatible serial ports such as dialup modems and serial mice.
RS-232
only guarantees up to 20 kilobaud anyway, and
anything faster is out of
spec
and works through luck. Fortunately, we had a lot
of luck by the late
1990s
when V.90 dialup came around. Want to go even
faster over long cable
runs?
We have
Ethernet for that sort of thing, and it's rather more reliable at
it.
Sneaker net with van is better yet, moving large data.(10 TB per tape) :).
5:42 p.m.
The 8250, 6551, Amiga serial port, etc do not have
FIFOs and so generate one
interrupt per byte. The CPU has to respond to the interrupt and retrieve the
incoming byte before the next byte has arrived. At 9600 baud, that needs to
happen within 1ms. At 115,200 baud, it's 87µs.
Older operating systems -- especially from the era where non-FIFO serial
ports were still standard -- would leave interrupts disabled for extended
periods.
At least for the 6551 cartridges on the Commodore 64/128, they were wired to
send NMIs. 57600bps generally worked just fine with later ones like the
Turbo232 (the SwiftLink was limited to 38400).
The 6551 in the Plus/4 is rigged to send IRQs, but I've not used one for serial
communications, so I can't say if it was substantially different in its
performance.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser(a)floodgap.com
-- Furious activity is no substitute for understanding. -- H. H. Williams -----
10 Feb
10 Feb
7:14 a.m.
Peter Corlett:
These easy-to-ask questions have very long answers.
But mostly, it was
*not*
a case of merely increasing the baud rate or the number of bits per baud
with a different modulation scheme, but multiple concurrent advances which
did those *plus* some other techniques which would maintain signal
integrity
despite the reduced SNR.
Apologies for the very open ended question. I found some old 1992
newsgroups thread that guided me towards the answer (including a long
excerpt from "Computer Select CD-ROM" with lots of CCITT referencing).
Interesting on comparing 1992 perspectives and contemporary confusion,
versus today's modern references on the topic.
If I'm understanding it right, a "sort of" answer to my own question is:
2400 baud (v.22bis) was an "amplification" (not the right word, but
"phase
magic") of 600 baud. While as has been mentioned, 9600 baud (v.32) was a
similar "amplification" of 2400 baud.
One thing I didn't realize was v.32bis (14400) was a dynamic speed (it
could slow down and speed up based on line quality). I don't recall
experiencing that, as far as varied transfer rates.
Someone here mentioned "Winmodem" and wow, I recall using one of those - I
think it was maybe one of the last modems I used, at around 28,800 baud? I
never got to experience the 33.6K or "57.6K" stuff. Even back then I
recall the v.42 "compression" stuff being confusing (to me), since I
didn't
know what the dial-up ISP at the time would support. And if I recall
correctly, the "WinModem" was somehow tied or dependent on Windows OS (or
they only build drivers for Windows) and it started to hit me how "DOS is
dead."
Neat review.
-Steve
On Sun, Feb 9, 2025 at 6:18 PM Peter Corlett via cctalk <
cctalk(a)classiccmp.org> wrote:
> On Sun, Feb 09, 2025 at 12:08:47PM -0600, Steve Lewis via cctalk wrote:
> [...]
> > So.. If you had a slow system that couldn't really take advantage of a
> > ~7MHz 16550 serial card (or I guess like a laptop that was stuck with an
> > older UART) That might be the use-case where this parallel v.fast might
> > help (by being able to "feed the modem" fast enough to actually take
> > advantage of the faster modem speed?) Or is there some other scenario
>
> Note that all but the dumbest modems reclock the data before transmission
> and the XON/XOFF or CTS/RTS flow control is handled locally, buffering in
> the modem as necessary. At faster speeds there's no longer a 1:1
> relationship between the signal level on the RS-232 cable and the screeches
> going down the phone line. Start and stop bits are not transmitted, giving
> a
> 25% speed boost from that alone.
>
> A parallel-connected modem is a bit pointless except in weird environments
> where one's serial port is broken or otherwise unusable. Information theory
> tells us that you can't get more than 64kb/s out of a dialup link, because
> that's the speed of the underlying digital channel used by the PSTN. Due to
> the reclocking, you actually need a serial port capable of 80kbaud to not
> drop data, and the next-highest standard baud rate is 115,200 baud, which
> any half-decent PC serial port can handle.
>
> To pre-empt the obvious retorts from the peanut gallery, sure, one may well
> have an original IBM XT or BBC Micro or whatever whose serial port drops
> bytes when driven faster than 9600 baud. Guess what: the machine's so slow
> that it can't handle the firehose of data even if its serial port wasn't a
> basket case.
>
> I don't know where you get "~7MHz 16550 serial card" from. The 16550
(and
> predecessors) sample the incoming serial signal with a clock 16x the baud
> rate. For 115,200 baud, that's 1.8432MHz, and it is no coincidence that
> this
> is a standard crystal frequency and also the maximum speed of a lot of
> UARTs.
>
> [...]
> > Is there any "natural rate" (Hz) of a modem? Meaning is 1200/2400
> > baud-equivalent modem an accelerated-by-enhanced-encoding version of 300
> > bps? and 9600 likewise an accelerated-by-encoding version of 2400? is
> > 300bps itself some kind of special accelerated-by-encoding? I see 1200
> > baud was also still sub 3KHz
>
These easy-to-ask questions have very long answers.
But mostly, it was
*not*
a case of merely increasing the baud rate or the number of bits per baud
with a different modulation scheme, but multiple concurrent advances which
did those *plus* some other techniques which would maintain signal
integrity
despite the reduced SNR.
>
> If you want the full gory detail, the relevant ITU standards are
> freely-available. Bring a good signal-processing textbook.
>
> > (did any modem protocol go above 3KHz?).
>
> V.90 used the full 4kHz analogue bandwidth for the downstream. Yes, even
> the
> frequency extremes which were heavily-attenuated by the line filters. It'd
> just listen much harder.
>
>
7:33 a.m.
On Mon, Feb 10, 2025, 12:14 AM Steve Lewis via cctalk <cctalk(a)classiccmp.org>
wrote:
Peter Corlett:
Yes and no. Winmodem lacked the smarts to generate or decode the signals
needed for v..33, etc. Instead, the modulation and demodulation was all in
software that then was played much like a sound card. Way cheaper to make,
but that took a lot of CPU. And the mod/demod ran only under Windows at
first. Not under DOS, Linux or FreeBSD, at least not until much later for
Linux...
Warner
These easy-to-ask questions have very long
answers. But mostly, it was
*not*
a case of merely increasing the baud rate or the number of bits per baud
with a different modulation scheme, but multiple concurrent advances
which
did those *plus* some other techniques which
would maintain signal
integrity
despite the reduced SNR.
Apologies for the very open ended question. I found some old 1992
newsgroups thread that guided me towards the answer (including a long
excerpt from "Computer Select CD-ROM" with lots of CCITT referencing).
Interesting on comparing 1992 perspectives and contemporary confusion,
versus today's modern references on the topic.
If I'm understanding it right, a "sort of" answer to my own question is:
2400 baud (v.22bis) was an "amplification" (not the right word, but
"phase
magic") of 600 baud. While as has been mentioned, 9600 baud (v.32) was a
similar "amplification" of 2400 baud.
One thing I didn't realize was v.32bis (14400) was a dynamic speed (it
could slow down and speed up based on line quality). I don't recall
experiencing that, as far as varied transfer rates.
Someone here mentioned "Winmodem" and wow, I recall using one of those - I
think it was maybe one of the last modems I used, at around 28,800 baud? I
never got to experience the 33.6K or "57.6K" stuff. Even back then I
recall the v.42 "compression" stuff being confusing (to me), since I
didn't
know what the dial-up ISP at the time would support. And if I recall
correctly, the "WinModem" was somehow tied or dependent on Windows OS (or
they only build drivers for Windows) and it started to hit me how "DOS is
dead."
Neat review.
-Steve
On Sun, Feb 9, 2025 at 6:18 PM Peter Corlett via cctalk <
cctalk(a)classiccmp.org> wrote:
screeches
which
On Sun, Feb 09, 2025 at 12:08:47PM -0600, Steve
Lewis via cctalk wrote:
[...]
> So.. If you had a slow system that couldn't really take advantage of a
> ~7MHz 16550 serial card (or I guess like a laptop that was stuck with
an
older
UART) That might be the use-case where this parallel v.fast might
help (by being able to "feed the modem" fast enough to actually take
advantage of the faster modem speed?) Or is there some other scenario
Note that all but the dumbest modems reclock the data before transmission
and the XON/XOFF or CTS/RTS flow control is handled locally, buffering in
the modem as necessary. At faster speeds there's no longer a 1:1
relationship between the signal level on the RS-232 cable and the
going down the phone line. Start and stop bits
are not transmitted,
giving
a
25% speed boost from that alone.
A parallel-connected modem is a bit pointless except in weird
environments
where one's serial port is broken or
otherwise unusable. Information
theory
tells us that you can't get more than 64kb/s
out of a dialup link,
because
that's the speed of the underlying digital
channel used by the PSTN. Due
to
the reclocking, you actually need a serial port
capable of 80kbaud to not
drop data, and the next-highest standard baud rate is 115,200 baud, which
any half-decent PC serial port can handle.
To pre-empt the obvious retorts from the peanut gallery, sure, one may
well
have an original IBM XT or BBC Micro or whatever
whose serial port drops
bytes when driven faster than 9600 baud. Guess what: the machine's so
slow
that it can't handle the firehose of data
even if its serial port wasn't
a
basket case.
I don't know where you get "~7MHz 16550 serial card" from. The 16550 (and
predecessors) sample the incoming serial signal with a clock 16x the baud
rate. For 115,200 baud, that's 1.8432MHz, and it is no coincidence that
this
is a standard crystal frequency and also the maximum speed of a lot of
UARTs.
[...]
> Is there any "natural rate" (Hz) of a modem? Meaning is 1200/2400
> baud-equivalent modem an accelerated-by-enhanced-encoding version of
300
bps? and
9600 likewise an accelerated-by-encoding version of 2400? is
300bps itself some kind of special accelerated-by-encoding? I see 1200
baud was also still sub 3KHz
These easy-to-ask questions have very long answers. But mostly, it was
*not*
a case of merely increasing the baud rate or the number of bits per baud
with a different modulation scheme, but multiple concurrent advances
did those *plus* some other techniques which
would maintain signal
integrity
despite the reduced SNR.
If you want the full gory detail, the relevant ITU standards are
freely-available. Bring a good signal-processing textbook.
It'd
(did any modem protocol go above 3KHz?).
V.90 used the full 4kHz analogue bandwidth for the downstream. Yes, even
the
frequency extremes which were heavily-attenuated by the line filters.
just listen much harder.
8:58 a.m.
On 2/10/2025 1:14 AM, Steve Lewis via cctalk wrote:
If I'm understanding it right, a "sort
of" answer to my own question is:
2400 baud (v.22bis) was an "amplification" (not the right word, but
"phase
magic") of 600 baud. While as has been mentioned, 9600 baud (v.32) was a
similar "amplification" of 2400 baud.
Not sure if it's been linked, but I found a list of baud->bps mappings
at Wikipedia:
https://en.wikipedia.org/wiki/Modem
For those who are OK using that resource to answer questions. I found
it interesting at 1200 bps had two options (1200baud * 2 tones or 600
baud * 4 tones)
Jim
--
Jim Brain
brain(a)jbrain.com
www.jbrain.com
4:08 p.m.
On Feb 10, 2025, at 3:58 AM, Jim Brain via cctalk
<cctalk(a)classiccmp.org> wrote:
On 2/10/2025 1:14 AM, Steve Lewis via cctalk wrote:
Not 4 tones; 4 modulation states per signal element, that is what QPSK means.
The difference is that the 202 standard was designed to run half duplex over a standard
phone line, or full duplex if you had a 4 wire (leased line) circuit. It's a very
simple device that actually works at any speed up to 1200 bps (or a hair more, as PLATO
did). The 212 modem using QPSK is a clocked system, but it can carry 1200 bps full duplex
over a single phone line, with half the channel bandwidth used for one direction and half
for the other.
The 202 specification was used in early amateur radio packet radio systems, FSK over
shortwave radio links or AFSK (FSK modulated audio tones modulated onto an FM radio
channel) for VHF. That works nicely because amateur radio is normally half duplex, and
202 modems were readily available at the time or could be easily built by amateurs if
needed. The only additional work is receive clock recovery, because 202 modems aren't
clocked so for synchronous transmission (packet radio is HDLC) you need to recover the bit
clock.
paul
If I'm understanding it right, a "sort
of" answer to my own question is:
2400 baud (v.22bis) was an "amplification" (not the right word, but
"phase
magic") of 600 baud. While as has been mentioned, 9600 baud (v.32) was a
similar "amplification" of 2400 baud.
Not sure if it's been linked, but I found a list of baud->bps mappings at
Wikipedia:
https://en.wikipedia.org/wiki/Modem
For those who are OK using that resource to answer questions. I found it interesting at
1200 bps had two options (1200baud * 2 tones or 600 baud * 4 tones)
4:46 p.m.
On 2/10/2025 10:08 AM, Paul Koning wrote:
Apologies, I was
trying to use simpler terminology, given the writer's
attempt to understand the overall relationship.
On Feb 10, 2025, at 3:58 AM, Jim Brain via cctalk
<cctalk(a)classiccmp.org> wrote:
On 2/10/2025 1:14 AM, Steve Lewis via cctalk wrote:
Not 4 tones; 4
modulation states per signal element, that is what QPSK means. If I'm understanding it right, a "sort
of" answer to my own question is:
2400 baud (v.22bis) was an "amplification" (not the right word, but
"phase
magic") of 600 baud. While as has been mentioned, 9600 baud (v.32) was a
similar "amplification" of 2400 baud.
Not sure if it's been linked,
but I found a list of baud->bps mappings at Wikipedia:
https://en.wikipedia.org/wiki/Modem
For those who are OK using that resource to answer questions. I found it interesting at
1200 bps had two options (1200baud * 2 tones or 600 baud * 4 tones)
The difference is that the 202 standard was designed to run half duplex over a standard
phone line, or full duplex if you had a 4 wire (leased line) circuit. It's a very
simple device that actually works at any speed up to 1200 bps (or a hair more, as PLATO
did). The 212 modem using QPSK is a clocked system, but it can carry 1200 bps full duplex
over a single phone line, with half the channel bandwidth used for one direction and half
for the other.
I realize it's extremely late and probably of no value except for
historical purposes, but having a way to visualize the various standards
in this space with respect to duplex, baud/bps rate, etc. would be of so
much value. Like the poster I replied to, how a modem worked always
seemed so oblique, especially as the speeds increased beyond 9600, even
without the added complexity of things like MNP and the negotiation
"dance" later modems held on the line. It was fascinating to hear about
and use, but I always felt I should know more about it. Yet, most
material in the day either waved a hand over the whole topic, or tried
to regurgitate the CCITT documentation. Specifically, in your above
statement, I'm still struggling to understand the duplex aspect of the
various standards. As a ham operator and having went through my EE
degree, I understand duplex, but since I always thought of the phone
line as a full duplex medium, how it would be used as a half duplex
channel eludes me. I'm OK with some terminology simplification, as
shown above, if it could help show how the bandwidth of the telephone
line was divided up in the various standards and how a 202 standard
managed to emulate a full duplex conversation (if it actually did this)
over the half duplex 2 wire telephone circuit. (And I use emulate in a
loose sense, I suppose. Back in the day, when IBM and LU.2 was a thing,
I worked at a company that created a general comms package that could
pass data over various protocols, including TCP/IP, LU6.2, NetBIOS, IPX,
and LU.2, which I believe was half duplex. But, the generic package
promised full duplex comms, so we (not me, but the team) had to build a
way to emulate a full duplex connection over that half duplex
technology. It worked, at least well enough to support the apps used
with it, but even it was "magic" to me, and I read all the source code)
Jim
--
Jim Brain
brain(a)jbrain.com
www.jbrain.com
7:50 p.m.
On Feb 10, 2025, at 11:46 AM, Jim Brain
<brain(a)jbrain.com> wrote:
On 2/10/2025 10:08 AM, Paul Koning wrote:
Yes, a phone line is full duplex, to humans. What actually happens is that the line
carries both directions, superimposed -- you hear both sides in the headphone. That works
well for us because we know how to sort the two signals.
A telephone line modem can be done three ways, roughly:
1. Half duplex: the channel is only active in one direction at a time. (202 modem)
2. Full duplex band split: one direction uses the lower half of the bandwidth, the other
the upper half. (212 modem)
3. Full duplex full bandwidth: each direction uses the full bandwidth but carefully
subtracts the local signal from what is seen on the line to arrive at the signal from the
other side. (V.32 etc., I believe)
The "negotiation" you're referring to may include things like equalization
and calibrating the local side suppression for case (3), since those things vary from one
connection to the next (and, possibly, over time even for one continuing connection).
A 202 modem, on a POTS line, did not emulate full duplex. It could only run half duplex,
with the usual RS-232 modem control signal handshakes to do line turnaround. Some
(perhaps most or all, I don't know) of 202 modems can be connected to a 4-wire
channel, essentially two phone lines in parallel where each pair carries one direction,
the two pairs in opposite directions. You could get that sort of line from Ma Bell but it
would be a permanent circuit, not a dialed phone line.
As for datacomm protocols like TCP/IP and such: IP sits above the data link layer so
it's not really in the picture. Looking at DECnet, the original data link (DDCMP) has
support for both half and full duplex. Interestingly enough, multipoint involves one
station (the "master") polling the others ("tributaries") for traffic,
so it seems an obvious half duplex setup, but DDCMP 4.0 supports multipoint both on half
and full duplex lines.
Above the data link you'd typically see what looks like a full duplex system, but if
the data link is half duplex then at that layer the "both directions at the same
time" property disappears. Since it's packet switching with indeterminate timing
that is fine. If you want hard-synchronous transmisson it isn't, but that isn't
in the domain of IP.
The distinction doesn't just appear in modems: DDCMP over "integral modem"
coax links can be half duplex (one coax) or full duplex (two coax cables). Original
coaxial cable Ethernet is half duplex, while the introduction of twisted pair enabled full
duplex but at least in the lower speeds doesn't require it. The various token schemes
(802.5, 802.4, FDDI) are all inherently half duplex.
paul
...
The difference is that the 202 standard was designed to run half duplex over a standard
phone line, or full duplex if you had a 4 wire (leased line) circuit. It's a very
simple device that actually works at any speed up to 1200 bps (or a hair more, as PLATO
did). The 212 modem using QPSK is a clocked system, but it can carry 1200 bps full duplex
over a single phone line, with half the channel bandwidth used for one direction and half
for the other.
I realize it's extremely late and probably of no value except
for historical purposes, but having a way to visualize the various standards in this space
with respect to duplex, baud/bps rate, etc. would be of so much value. Like the poster I
replied to, how a modem worked always seemed so oblique, especially as the speeds
increased beyond 9600, even without the added complexity of things like MNP and the
negotiation "dance" later modems held on the line. It was fascinating to hear
about and use, but I always felt I should know more about it. Yet, most material in the
day either waved a hand over the whole topic, or tried to regurgitate the CCITT
documentation. Specifically, in your above statement, I'm still struggling to
understand the duplex aspect of the various standards. As a ham operator and having went
through my EE degree, I understand duplex, but since I always thought of the phone line as
a full duplex medium, how it would be used as a half duplex channel eludes me. I'm OK
with some terminology simplification, as shown above, if it could help show how the
bandwidth of the telephone line was divided up in the various standards and how a 202
standard managed to emulate a full duplex conversation (if it actually did this) over the
half duplex 2 wire telephone circuit. (And I use emulate in a loose sense, I suppose.
Back in the day, when IBM and LU.2 was a thing, I worked at a company that created a
general comms package that could pass data over various protocols, including TCP/IP,
LU6.2, NetBIOS, IPX, and LU.2, which I believe was half duplex. But, the generic package
promised full duplex comms, so we (not me, but the team) had to build a way to emulate a
full duplex connection over that half duplex technology. It worked, at least well enough
to support the apps used with it, but even it was "magic" to me, and I read all
the source code)
11 Feb
11 Feb
4:10 a.m.
Jim Brain
I realize it's extremely late and probably of no
value except for
historical purposes, but having a way to visualize the various standards
in this space with respect to duplex, baud/bps rate, etc. would be of so
I recently came across this on YouTube - it's from 13 years ago, but I
found it insightful . It's a Spectrogram of a modem dial-in connection.
I'm not sure if it's from simulation or an actual measurement - either way,
I think it's reasonably representative of the idea of tones being split
into signal, all involving FFT's.
Dial Up Modem Handshake Sound - Spectrogram - YouTube
<https://www.youtube.com/watch?v=vvr9AMWEU-c>
(the first comment on that video is helpful) And from the above video, that
led me to this:
dialup-final.png (2500×1304)
<https://oona.windytan.com/posters/dialup-final.png>
Then from the CCITT standards, I recall the verbiage of it talking
specifying "re-serializing" the signal. So in a way, these modulated
signals are another form of parallel back to the serial? Or "serial to
multi-phase back to serial" ? But - but - I thought we needed quantum
computers to represent more states than 0 and 1 at the same time? ;)
But the CCITT get dizzying to try to categorize - there seems to be a
"synchronous" and "asynchronous" version of nearly all of them, or
half vs
hull duplex variants? But one thing I did come across in exploring them:
the concept of echoing? I'm just guessing, but I recall one issue with
parallel ports is that a close enough wires and high speeds, you get
"cross-talk"? I suspect TX/RX lines of serial end up close together, is
"echoing" somehow residual of a RX echo'ing back out on the TX? (I'm
really
guessing on it, speculating before I read up more about it) In short, this
echo'ing effect I think partially explains why at high speeds they could TX
faster than RX?
Another thing I've recently read: 1200 baud v.22 isn't noted until 1980.
Maybe it was technically available a couple years earlier (you still see
that today, how WiFi vendors claim some new fast speed, chomping at the bit
to jump the market before competitors - and doing so at risk before the
standard is really ratified; that game was played also with modems --
ending up with a "mixed bag" on performance, especially when using devices
across vendors?).
Anyway, thinking on it: 1980-ish makes sense. You had 300 baud modems from
1963 to 1980, because to pull off any fancier modulation - you need a
clever FFT on a chip, a general-processor CPU (up to that point) wasn't
fast enough to pull it off. [ and I do mean in the more consumer-grade
stuff ] Is that a reasonable characterization? (on why 300 baud was "the
standard" for so long, and then suddenly the next decade after that with
incrementally better multi-phase encoding to could sustain faster
equivalent baud rates?)
-Steve
On Mon, Feb 10, 2025 at 10:46 AM Jim Brain via cctalk <cctalk(a)classiccmp.org>
wrote:
> On 2/10/2025 10:08 AM, Paul Koning wrote:
> >
> >> On Feb 10, 2025, at 3:58 AM, Jim Brain via cctalk <
> cctalk(a)classiccmp.org> wrote:
> >>
> >> On 2/10/2025 1:14 AM, Steve Lewis via cctalk wrote:
> >>> If I'm understanding it right, a "sort of" answer to my
own question
> is:
> >>> 2400 baud (v.22bis) was an "amplification" (not the right
word, but
> "phase
> >>> magic") of 600 baud. While as has been mentioned, 9600 baud
(v.32)
> was a
> >>> similar "amplification" of 2400 baud.
> >> Not sure if it's been linked, but I found a list of baud->bps
mappings
> at Wikipedia:
> >>
> >> https://en.wikipedia.org/wiki/Modem
> >>
> >> For those who are OK using that resource to answer questions. I found
> it interesting at 1200 bps had two options (1200baud * 2 tones or 600 baud
> * 4 tones)
> > Not 4 tones; 4 modulation states per signal element, that is what QPSK
> means.
> Apologies, I was trying to use simpler terminology, given the writer's
> attempt to understand the overall relationship.
> >
> > The difference is that the 202 standard was designed to run half duplex
> over a standard phone line, or full duplex if you had a 4 wire (leased
> line) circuit. It's a very simple device that actually works at any speed
> up to 1200 bps (or a hair more, as PLATO did). The 212 modem using QPSK is
> a clocked system, but it can carry 1200 bps full duplex over a single phone
> line, with half the channel bandwidth used for one direction and half for
> the other.
I realize it's extremely late and probably of no
value except for
historical purposes, but having a way to visualize the various standards
in this space with respect to duplex, baud/bps rate, etc. would be of so
> much value. Like the poster I replied to, how a modem worked always
> seemed so oblique, especially as the speeds increased beyond 9600, even
> without the added complexity of things like MNP and the negotiation
> "dance" later modems held on the line. It was fascinating to hear about
> and use, but I always felt I should know more about it. Yet, most
> material in the day either waved a hand over the whole topic, or tried
> to regurgitate the CCITT documentation. Specifically, in your above
> statement, I'm still struggling to understand the duplex aspect of the
> various standards. As a ham operator and having went through my EE
> degree, I understand duplex, but since I always thought of the phone
> line as a full duplex medium, how it would be used as a half duplex
> channel eludes me. I'm OK with some terminology simplification, as
> shown above, if it could help show how the bandwidth of the telephone
> line was divided up in the various standards and how a 202 standard
> managed to emulate a full duplex conversation (if it actually did this)
> over the half duplex 2 wire telephone circuit. (And I use emulate in a
> loose sense, I suppose. Back in the day, when IBM and LU.2 was a thing,
> I worked at a company that created a general comms package that could
> pass data over various protocols, including TCP/IP, LU6.2, NetBIOS, IPX,
> and LU.2, which I believe was half duplex. But, the generic package
> promised full duplex comms, so we (not me, but the team) had to build a
> way to emulate a full duplex connection over that half duplex
> technology. It worked, at least well enough to support the apps used
> with it, but even it was "magic" to me, and I read all the source code)
>
>
> Jim
>
> --
> Jim Brain
> brain(a)jbrain.com
> www.jbrain.com
>
>
6:27 a.m.
On 2/10/2025 10:10 PM, Steve Lewis via cctalk wrote:
dialup-final.png (2500×1304)
<https://oona.windytan.com/posters/dialup-final.png>
This is the one I
remember seeing in the past, though seeing this (like
a spectrograph like you see on some PSK31 apps) in the video format with
the annotations as they appear would be the coolest thing ever to help
understand this. Yes, the first comment on the video was very helpful,
though I had to keep stopping the video at the various times to get a
handle on the portion of the sequence
Jim
--
Jim Brain
brain(a)jbrain.com
www.jbrain.com
10 Feb
10 Feb
10:40 p.m.
Steve wrote:
I was about to ask if anyone ever built a
"Parallel Modem" - but I searched around first, and lo and > behold, Microcom
did ! (v.fast / v.34 era, c. 1996)
There was a company called Xircom that made parallel port modems. These were full modems
that were small enough that they plugged into a laptop serial port, and got their power
from the laptop via the external mouse/keyboard port. They had a feed-though connector so
you could still connect and external mouse/keyboard if you wanted. The idea was
portability, and not having to have extra cables (e.g., serial cable) to carry around. I
think that these may have been available up to 2400 baud, maybe higher, but can't
remember. This was at a time before laptops only had black and white LCD screens, floppy
drive (no hard disk), and a parallel and serial port, and huge batteries that didn't
run the machines for very long. I did use one of these Xircom modems on a Tandy Radio
Shack Model 100 portable computer, and it worked well and did not seriously impact runtime
on battery when it was being used. There was a special machine language program that you
had to load that logically switched out the serial port to go through the parallel port as
needed by the modem. I used on briefly on an old Toshiba Win95 laptop with a color
display (don't remember the model), and it also worked well there. After laptops
started having PCMCIA ports, Xircom made some modem cards in PCMCIA form-factor, and they
had a little dongle that plugged into them that provided the RJ11 jack to plug the phone
line into. I think these could go up to 14.4Kb, maybe more. I have at least one of the
old Xircom parallel modems, and perhaps a couple of the Xircom PCMCIA modem cards in a box
somewhere. Definitely devices that aged out fairly quickly as technology advanced and
modems were built-into laptops for a while. Then modems, serial ports, floppy drives,
optical media, and even parallel ports disappeared from laptops in favor of USB and WiFi,
and even built in cellular Internet.
Rick
13 Feb
13 Feb
11:44 p.m.
Correction to my posting of 2/10/2025
There was a company called Xircom that made parallel port modems. These were full modems
that were small enough that they plugged into a laptop serial <parallel> port, and
got their power from the laptop via the external mouse/keyboard port. They had a
feed-though connector so you could still connect and external mouse/keyboard if you
wanted. ...
-Rick
11:50 p.m.
On Thu, Feb 13, 2025, 4:44 PM Rick Bensene via cctalk <cctalk(a)classiccmp.org>
wrote:
Correction to my posting of 2/10/2025
There was a company called Xircom that made parallel port modems. These
were full modems that were small enough that they plugged into a laptop
serial <parallel> port, and got their power from the laptop via the
external mouse/keyboard port. They had a feed-though connector so you
could still connect and external mouse/keyboard if you wanted. ...
So which is it? My memory of the time was they were RS-233 devices that got
their power from the keyboard port via a pass through cable. If they were
parallel port, the PP provides enough power...
Xircom also had parallel port ethernet products...
I never saw a modem that was connected that way from them.
Warner
-Rick
14 Feb
14 Feb
12:24 a.m.
On Thu, Feb 13, 2025 at 3:50 PM Warner Losh via cctalk
<cctalk(a)classiccmp.org> wrote:
On Thu, Feb 13, 2025, 4:44 PM Rick Bensene via cctalk <cctalk(a)classiccmp.org>
wrote:
The Xircom PE3 (Pocket Ethernet Adapter III) needed power either from
a PS/2 port or an AC adapter.
Phantom Power Cable
The Phantom Power Cable supplied with the Pocket Ethernet Adapter III
allows you to power all Adapter models (except PE3-10BX) directly from
a PS/2-style C6-pin mini-DIN) mouse port on your computer. The cable
includes a pass-through connector that allows a mouse to be plugged in
on top of the Phantom Power Cable connection.
Wall-Mount AC Power Adapter
AC power adapter specifications are listed below for the US.A. and Canada
Input Voltage: 120 VAC / 60 Hz
Output Voltage: 12 VDC unregulated, 300ma (500ma for Model PE3-10BX)
https://www.minuszerodegrees.net/manuals/Xircom/Xircom%20Pocket%20Ethernet%…
https://www.brutman.com/Dos_Networking/xircom_pe3.html
Correction to my posting of 2/10/2025
There was a company called Xircom that made parallel port modems. These
were full modems that were small enough that they plugged into a laptop
serial <parallel> port, and got their power from the laptop via the
external mouse/keyboard port. They had a feed-though connector so you
could still connect and external mouse/keyboard if you wanted. ...
So which is it? My memory of the time was they were RS-233 devices that got
their power from the keyboard port via a pass through cable. If they were
parallel port, the PP provides enough power...
Xircom also had parallel port ethernet products... 
13 Feb
13 Feb
11:54 p.m.
On Thu, 13 Feb 2025 at 18:44, Rick Bensene via cctalk <cctalk(a)classiccmp.org>
wrote:
There was a company called Xircom that made parallel port modems. These
were full modems that were small enough that they plugged into a laptop
serial <parallel> port, and got their power from the laptop via the
external mouse/keyboard port. They had a feed-though connector so you
could still connect and external mouse/keyboard if you wanted. ...
I remember those, and when I went searching to look for more information on
them I found something I hadn't stumbled on before - apparently Xircom made
a parallel port ethernet adapter. It must have been pretty painful. The
parallel port wasn't a great high speed interface; I unfortunately had a
parallel port ZIP drive and it was a dog.
-Henry
14 Feb
14 Feb
12:32 a.m.
Henry wrote:
I remember those, and when I went searching to look
for more information on them I found something I > hadn't stumbled on before -
apparently Xircom made a parallel port Ethernet adapter. It must have
been pretty painful. The parallel port wasn't a great high speed interface…
----
Yes, I have one of those parallel port Ethernet devices too. But, remember, back at that
time, Ethernet was commonly 10Mb/Sec. I think that 100Mb/Sec was only located in high-end
datacenters and was very expensive. For a laptop that didn’t have a PCMCIA port, and you
wanted it on an Ethernet network, this was an acceptable way to go. Performance wasn’t
great, but most of the time laptops like this were used for TELNET connections to other
hosts on the local network for “GREEN SCREEN” type applications that ran entirely on the
remote host. Performance in such cases wasn’t nearly as much of a concern as it would be
in the not too distant future.
I will try to find my Xircom parallel port Modem and Ethernet adapters in a box somewhere
in my storage area and take a photo of them. If I can find them, I’ll post a link here to
the photos so those in disbelief can see them.
-Rick
From: Henry Bent [mailto:henry.r.bent@gmail.com]
Sent: Thursday, February 13, 2025 3:54 PM
To: General Discussion: On-Topic and Off-Topic Posts <cctalk(a)classiccmp.org>
Cc: Rick Bensene <rickb(a)bensene.com>
Subject: Re: [cctalk] Re: RS232 - parallel modems!?
12:43 a.m.
On Thu, Feb 13, 2025, 5:32 PM Rick Bensene via cctalk <cctalk(a)classiccmp.org>
wrote:
Henry wrote:
That would be cool. I found this link for all the networking gear:
https://www.ardent-tool.com/Xircom/Xircom_Pocket_Adapters.html
And found parallel port multiplexers.
Do you have drivers for them?
Warner
-Rick
I remember those, and when I went searching to
look for more information
on them I found something I > hadn't stumbled on before - apparently
Xircom
made a parallel port Ethernet adapter. It must have
been pretty painful. The parallel port
wasn't a great high speed
interface…
----
Yes, I have one of those parallel port Ethernet devices too. But,
remember, back at that time, Ethernet was commonly 10Mb/Sec. I think that
100Mb/Sec was only located in high-end datacenters and was very expensive.
For a laptop that didn’t have a PCMCIA port, and you wanted it on an
Ethernet network, this was an acceptable way to go. Performance wasn’t
great, but most of the time laptops like this were used for TELNET
connections to other hosts on the local network for “GREEN SCREEN” type
applications that ran entirely on the remote host. Performance in such
cases wasn’t nearly as much of a concern as it would be in the not too
distant future.
I will try to find my Xircom parallel port Modem and Ethernet adapters in
a box somewhere in my storage area and take a photo of them. If I can find
them, I’ll post a link here to the photos so those in disbelief can see
them.
From: Henry Bent [mailto:henry.r.bent@gmail.com]
Sent: Thursday, February 13, 2025 3:54 PM
To: General Discussion: On-Topic and Off-Topic Posts <
cctalk(a)classiccmp.org>
Cc: Rick Bensene <rickb(a)bensene.com>
Subject: Re: [cctalk] Re: RS232 - parallel modems!?
12:47 a.m.
On 2/14/25 1:43 AM, Warner Losh via cctalk wrote:
That would be cool. I found this link for all the networking gear:
https://www.ardent-tool.com/Xircom/Xircom_Pocket_Adapters.html
And found parallel port multiplexers.
Do you have drivers for them?
I think DOS packet drivers supported the PE3. I haven't found the source
code of it, although the packet drivers are GPL and source should be
available (unless Xircom cheated).
regards,
chris
15 Feb
15 Feb
8:46 a.m.
On Thu, Feb 13, 2025 at 8:20 PM Christian Groessler via cctalk
<cctalk(a)classiccmp.org> wrote:
On 2/14/25 1:43 AM, Warner Losh via cctalk wrote:
Yes, They did. I used them in the 90s.
We used them at work in 1995-97 for laptops to go out in the field
before most laptops had PCMCIA (we were still supporting 386 and 486
laptops at the time, very few of them were good enough to run Windows
95).
At home, I have a Zenith dual-"720K" 8088 laptop and I used to mostly
use it as a telnet "terminal" with DOS 3.3, Kermit, and the PE3 packet
driver.
That would be cool. I found this link for all the networking gear:
https://www.ardent-tool.com/Xircom/Xircom_Pocket_Adapters.html
Do you have drivers for them?
I think DOS packet drivers supported the PE3. I haven't found the source
code of it, although the packet drivers are GPL and source should be
available (unless Xircom cheated).
I don't have source AFAIK. I'm in favor of it, but I was unlikely to
be rebuilding DOS drivers at any time.
Cheers,
-ethan
14 Feb
14 Feb
1:13 a.m.
On Thu, Feb 13, 2025 at 4:32 PM Rick Bensene via cctalk
<cctalk(a)classiccmp.org> wrote:
I will try to find my Xircom parallel port Modem and Ethernet adapters in a box somewhere
in my storage area and take a photo of them. If I can find them, I’ll post a link here to
the photos so those in disbelief can see them.
I was initially skeptical that Xircom made a parallel port modem.
Apparently they actually did, at least a combo Ethernet+Modem. Don't
know if they also made a modem only version.
https://archive.org/details/pem113
Welcome to a new level of connectivity convenience. Xircom's Pocket
Ethernet+Modem provides PE3 equivalent Ethernet LAN adapter functionality
for DOS and Windows combined with a fully featured V.32bis modem. The PEM is
available in two models, the PEM-10BT(for the 10BASE-T twisted pair with RJ-45
connector) and the PEM-10B2(for the 10BASE-2 thin Coax with BNC connector).
5:26 p.m.
Rick Bensene:
I will try to find my Xircom parallel port Modem and
Ethernet adapters in
a box somewhere in my storage area and take a photo of them. If I can find
them, I’ll post a link here to the photos so those in disbelief can see
them.
That'd be neat to see, if you do find the Xircom parallel modem. I've seen
combo ones and their "parallel-ethernet" devices (which seem to go for
quite a premium these days), but not the modem only. Suppose they weren't
too popular, as even laptops started to have built in modems.
These days, I do use an SDLPT, that lets you use SD-cards to transfer data
into a system over the parallel port. I suppose that's the same general
principle (of read/writing one full byte at a time to a device). I
haven't measured its performance yet (but would characterize it as being
comparable to a physical 3.5" floppy disk drive kind of performance - I
think copying Quake took over 40 minutes, something like that; but I'd like
to get more accurate about it, down to an actual bytes-per-second rate).
Measuring that might give me an answer on how fast something like
Laplink/Interlink cable should be able to perform.
As another experiment, I'll drop that ~7MHz 16550 serial card into a 386,
and see if I can get a 386 to push data out on RS-232 faster than 115200.
It should, but we'll see!
And I think I will do an RS-232 themed talk in June VCF, if a spot is still
open - I think I have enough now to make it interesting. One area I'm a
little stuck on is verifying that anyone actually did make an RS-232
keyboard. Even for TV Typewriter, I'm not sure if I'd characterize that as
RS-232 related. And Gordon Bell integrated an ASR-33 (current loop) to the
PDP-1, but might not be accurate to call that RS-232 (but can't a current
loop based thing be adapted to voltage?). I thought the POLY-88 keyboard
was RS-232, but it'll be awhile before I can get back to that equipment.
-Steve
On Thu, Feb 13, 2025 at 6:32 PM Rick Bensene via cctalk <
cctalk(a)classiccmp.org> wrote:
> Henry wrote:
>
> > I remember those, and when I went searching to look for more information
> on them I found something I > hadn't stumbled on before - apparently Xircom
> made a parallel port Ethernet adapter. It must have
> > been pretty painful. The parallel port wasn't a great high speed
> interface…
>
> ----
>
> Yes, I have one of those parallel port Ethernet devices too. But,
> remember, back at that time, Ethernet was commonly 10Mb/Sec. I think that
> 100Mb/Sec was only located in high-end datacenters and was very expensive.
> For a laptop that didn’t have a PCMCIA port, and you wanted it on an
> Ethernet network, this was an acceptable way to go. Performance wasn’t
> great, but most of the time laptops like this were used for TELNET
> connections to other hosts on the local network for “GREEN SCREEN” type
> applications that ran entirely on the remote host. Performance in such
> cases wasn’t nearly as much of a concern as it would be in the not too
> distant future.
>
I will try to find my Xircom parallel port Modem and
Ethernet adapters in
a box somewhere in my storage area and take a photo of them. If I can find
them, I’ll post a link here to the photos so those in disbelief can see
them.
>
> -Rick
>
>
>
> From: Henry Bent [mailto:henry.r.bent@gmail.com]
> Sent: Thursday, February 13, 2025 3:54 PM
> To: General Discussion: On-Topic and Off-Topic Posts <
> cctalk(a)classiccmp.org>
> Cc: Rick Bensene <rickb(a)bensene.com>
> Subject: Re: [cctalk] Re: RS232 - parallel modems!?
>
11:27 p.m.
I believe that at least Kaypro used a TTL form of RS-232 for the keyboard;
in fact, ISTR using an RS M100 notebook (+/- 5V) in place of a keyboard in
distant days.
On Fri, Feb 14, 2025 at 12:27 PM Steve Lewis via cctalk <
cctalk(a)classiccmp.org> wrote:
Rick Bensene:
I will try to find my Xircom parallel port Modem
and Ethernet adapters in
a box somewhere in my storage area and take a photo of them. If I can
find
them, I’ll post a link here to the photos so
those in disbelief can see
them.
That'd be neat to see, if you do find the Xircom parallel modem. I've seen
combo ones and their "parallel-ethernet" devices (which seem to go for
quite a premium these days), but not the modem only. Suppose they weren't
too popular, as even laptops started to have built in modems.
These days, I do use an SDLPT, that lets you use SD-cards to transfer data
into a system over the parallel port. I suppose that's the same general
principle (of read/writing one full byte at a time to a device). I
haven't measured its performance yet (but would characterize it as being
comparable to a physical 3.5" floppy disk drive kind of performance - I
think copying Quake took over 40 minutes, something like that; but I'd like
to get more accurate about it, down to an actual bytes-per-second rate).
Measuring that might give me an answer on how fast something like
Laplink/Interlink cable should be able to perform.
As another experiment, I'll drop that ~7MHz 16550 serial card into a 386,
and see if I can get a 386 to push data out on RS-232 faster than 115200.
It should, but we'll see!
And I think I will do an RS-232 themed talk in June VCF, if a spot is still
open - I think I have enough now to make it interesting. One area I'm a
little stuck on is verifying that anyone actually did make an RS-232
keyboard. Even for TV Typewriter, I'm not sure if I'd characterize that as
RS-232 related. And Gordon Bell integrated an ASR-33 (current loop) to the
PDP-1, but might not be accurate to call that RS-232 (but can't a current
loop based thing be adapted to voltage?). I thought the POLY-88 keyboard
was RS-232, but it'll be awhile before I can get back to that equipment.
-Steve
On Thu, Feb 13, 2025 at 6:32 PM Rick Bensene via cctalk <
cctalk(a)classiccmp.org> wrote:
Henry wrote:
> I remember those, and when I went searching to look for more
information
on them I found something I > hadn't
stumbled on before - apparently
Xircom
made a parallel port Ethernet adapter. It must
have
that
been pretty painful. The parallel port
wasn't a great high speed
interface…
----
Yes, I have one of those parallel port Ethernet devices too. But,
remember, back at that time, Ethernet was commonly 10Mb/Sec. I think
100Mb/Sec was only located in high-end
datacenters and was very
expensive.
> For a laptop that didn’t have a PCMCIA port, and you wanted it on an
> Ethernet network, this was an acceptable way to go. Performance wasn’t
> great, but most of the time laptops like this were used for TELNET
> connections to other hosts on the local network for “GREEN SCREEN” type
> applications that ran entirely on the remote host. Performance in such
> cases wasn’t nearly as much of a concern as it would be in the not too
> distant future.
>
I will try to find my Xircom parallel port Modem
and Ethernet adapters in
a box somewhere in my storage area and take a photo of them. If I can
find
them, I’ll post a link here to the photos so
those in disbelief can see
them.
>
> -Rick
>
>
>
> From: Henry Bent [mailto:henry.r.bent@gmail.com]
> Sent: Thursday, February 13, 2025 3:54 PM
> To: General Discussion: On-Topic and Off-Topic Posts <
> cctalk(a)classiccmp.org>
> Cc: Rick Bensene <rickb(a)bensene.com>
> Subject: Re: [cctalk] Re: RS232 - parallel modems!?
>
15 Feb
15 Feb
5:43 a.m.
Thanks, I had forgotten about the Kaypro. Looks like it uses a "custom"
4-pin wire (one of them being 5V power). So just level-shift the TX/RX
pins through a MAX232 IC and it would talk to another R-232 system at 300
baud eh? Might have to seek out a lone Kaypro keyboard to give it a try.
I suspect some of the "serial style" mid-1980s IBM Model M keyboards are
similar. But I'm still wondering if anyone used this concept in the late
1960s - teletypes were expensive, flipping switches was tedious, so
keyboard alternates were hot items by early 70's (hence the TVT popularity).
On Fri, Feb 14, 2025 at 5:28 PM Mike Stein <mhs.stein(a)gmail.com> wrote:
I believe that at least Kaypro used a TTL form of
RS-232 for the keyboard;
in fact, ISTR using an RS M100 notebook (+/- 5V) in place of a keyboard in
distant days.
On Fri, Feb 14, 2025 at 12:27 PM Steve Lewis via cctalk <
cctalk(a)classiccmp.org> wrote:
Rick Bensene:
I will try to find my Xircom parallel port Modem
and Ethernet adapters
in
a box somewhere in my storage area and take a
photo of them. If I can
find
them, I’ll post a link here to the photos so
those in disbelief can see
them.
That'd be neat to see, if you do find the Xircom parallel modem. I've
seen
combo ones and their "parallel-ethernet" devices (which seem to go for
quite a premium these days), but not the modem only. Suppose they weren't
too popular, as even laptops started to have built in modems.
These days, I do use an SDLPT, that lets you use SD-cards to transfer data
into a system over the parallel port. I suppose that's the same general
principle (of read/writing one full byte at a time to a device). I
haven't measured its performance yet (but would characterize it as being
comparable to a physical 3.5" floppy disk drive kind of performance - I
think copying Quake took over 40 minutes, something like that; but I'd
like
to get more accurate about it, down to an actual bytes-per-second rate).
Measuring that might give me an answer on how fast something like
Laplink/Interlink cable should be able to perform.
As another experiment, I'll drop that ~7MHz 16550 serial card into a 386,
and see if I can get a 386 to push data out on RS-232 faster than 115200.
It should, but we'll see!
And I think I will do an RS-232 themed talk in June VCF, if a spot is
still
open - I think I have enough now to make it interesting. One area I'm a
little stuck on is verifying that anyone actually did make an RS-232
keyboard. Even for TV Typewriter, I'm not sure if I'd characterize that as
RS-232 related. And Gordon Bell integrated an ASR-33 (current loop) to
the
PDP-1, but might not be accurate to call that RS-232 (but can't a current
loop based thing be adapted to voltage?). I thought the POLY-88 keyboard
was RS-232, but it'll be awhile before I can get back to that equipment.
-Steve
On Thu, Feb 13, 2025 at 6:32 PM Rick Bensene via cctalk <
cctalk(a)classiccmp.org> wrote:
Henry wrote:
> I remember those, and when I went searching to look for more
information
on them I found something I > hadn't
stumbled on before - apparently
Xircom
made a parallel port Ethernet adapter. It must
have
that
been pretty painful. The parallel port
wasn't a great high speed
interface…
----
Yes, I have one of those parallel port Ethernet devices too. But,
remember, back at that time, Ethernet was commonly 10Mb/Sec. I think
100Mb/Sec was only located in high-end
datacenters and was very
expensive.
> For a laptop that didn’t have a PCMCIA port, and you wanted it on an
> Ethernet network, this was an acceptable way to go. Performance wasn’t
> great, but most of the time laptops like this were used for TELNET
> connections to other hosts on the local network for “GREEN SCREEN” type
> applications that ran entirely on the remote host. Performance in such
> cases wasn’t nearly as much of a concern as it would be in the not too
> distant future.
>
I will try to find my Xircom parallel port Modem
and Ethernet adapters
in
a box somewhere in my storage area and take a
photo of them. If I can
find
them, I’ll post a link here to the photos so
those in disbelief can see
them.
>
> -Rick
>
>
>
> From: Henry Bent [mailto:henry.r.bent@gmail.com]
> Sent: Thursday, February 13, 2025 3:54 PM
> To: General Discussion: On-Topic and Off-Topic Posts <
> cctalk(a)classiccmp.org>
> Cc: Rick Bensene <rickb(a)bensene.com>
> Subject: Re: [cctalk] Re: RS232 - parallel modems!?
>
6:37 p.m.
In the keyboard section of the attached document there are instructions for
testing with a terminal & USB>TTL RS-232 adapter.
On Sat, Feb 15, 2025 at 12:43 AM Steve Lewis <lewissa78(a)gmail.com> wrote:
Thanks, I had forgotten about the Kaypro. Looks like
it uses a "custom"
4-pin wire (one of them being 5V power). So just level-shift the TX/RX
pins through a MAX232 IC and it would talk to another R-232 system at 300
baud eh? Might have to seek out a lone Kaypro keyboard to give it a try.
I suspect some of the "serial style" mid-1980s IBM Model M keyboards are
similar. But I'm still wondering if anyone used this concept in the late
1960s - teletypes were expensive, flipping switches was tedious, so
keyboard alternates were hot items by early 70's (hence the TVT popularity).
On Fri, Feb 14, 2025 at 5:28 PM Mike Stein <mhs.stein(a)gmail.com> wrote:
> I believe that at least Kaypro used a TTL form of RS-232 for the
> keyboard; in fact, ISTR using an RS M100 notebook (+/- 5V) in place of a
> keyboard in distant days.
>
> On Fri, Feb 14, 2025 at 12:27 PM Steve Lewis via cctalk <
> cctalk(a)classiccmp.org> wrote:
>
>> Rick Bensene:
>>
>> > I will try to find my Xircom parallel port Modem and Ethernet adapters
>> in
>> > a box somewhere in my storage area and take a photo of them. If I can
>> find
>> > them, I’ll post a link here to the photos so those in disbelief can see
>> > them.
>>
>>
>> That'd be neat to see, if you do find the Xircom parallel modem. I've
>> seen
>> combo ones and their "parallel-ethernet" devices (which seem to go
for
>> quite a premium these days), but not the modem only. Suppose they
>> weren't
>> too popular, as even laptops started to have built in modems.
>>
>> These days, I do use an SDLPT, that lets you use SD-cards to transfer
>> data
>> into a system over the parallel port. I suppose that's the same general
>> principle (of read/writing one full byte at a time to a device). I
>> haven't measured its performance yet (but would characterize it as being
>> comparable to a physical 3.5" floppy disk drive kind of performance - I
>> think copying Quake took over 40 minutes, something like that; but I'd
>> like
>> to get more accurate about it, down to an actual bytes-per-second rate).
>> Measuring that might give me an answer on how fast something like
>> Laplink/Interlink cable should be able to perform.
>>
>> As another experiment, I'll drop that ~7MHz 16550 serial card into a 386,
>> and see if I can get a 386 to push data out on RS-232 faster than 115200.
>> It should, but we'll see!
>>
>>
>> And I think I will do an RS-232 themed talk in June VCF, if a spot is
>> still
>> open - I think I have enough now to make it interesting. One area I'm a
>> little stuck on is verifying that anyone actually did make an RS-232
>> keyboard. Even for TV Typewriter, I'm not sure if I'd characterize that
>> as
>> RS-232 related. And Gordon Bell integrated an ASR-33 (current loop) to
>> the
>> PDP-1, but might not be accurate to call that RS-232 (but can't a current
>> loop based thing be adapted to voltage?). I thought the POLY-88 keyboard
>> was RS-232, but it'll be awhile before I can get back to that equipment.
>>
>>
>> -Steve
>>
>>
>>
>> On Thu, Feb 13, 2025 at 6:32 PM Rick Bensene via cctalk <
>> cctalk(a)classiccmp.org> wrote:
>>
>> > Henry wrote:
>> >
>> > > I remember those, and when I went searching to look for more
>> information
>> > on them I found something I > hadn't stumbled on before -
apparently
>> Xircom
>> > made a parallel port Ethernet adapter. It must have
>> > > been pretty painful. The parallel port wasn't a great high speed
>> > interface…
>> >
>> > ----
>> >
>> > Yes, I have one of those parallel port Ethernet devices too. But,
>> > remember, back at that time, Ethernet was commonly 10Mb/Sec. I think
>> that
>> > 100Mb/Sec was only located in high-end datacenters and was very
>> expensive.
>> > For a laptop that didn’t have a PCMCIA port, and you wanted it on an
>> > Ethernet network, this was an acceptable way to go. Performance wasn’t
>> > great, but most of the time laptops like this were used for TELNET
>> > connections to other hosts on the local network for “GREEN SCREEN” type
>> > applications that ran entirely on the remote host. Performance in such
>> > cases wasn’t nearly as much of a concern as it would be in the not too
>> > distant future.
>> >
>> > I will try to find my Xircom parallel port Modem and Ethernet adapters
>> in
>> > a box somewhere in my storage area and take a photo of them. If I can
>> find
>> > them, I’ll post a link here to the photos so those in disbelief can see
>> > them.
>> >
>> > -Rick
>> >
>> >
>> >
>> > From: Henry Bent [mailto:henry.r.bent@gmail.com]
>> > Sent: Thursday, February 13, 2025 3:54 PM
>> > To: General Discussion: On-Topic and Off-Topic Posts <
>> > cctalk(a)classiccmp.org>
>> > Cc: Rick Bensene <rickb(a)bensene.com>
>> > Subject: Re: [cctalk] Re: RS232 - parallel modems!?
>> >
>>
>
9:26 p.m.
I don’t see the attachment.
Sent from my iPhone
On Feb 15, 2025, at 13:22, Mike Stein via cctalk
<cctalk(a)classiccmp.org> wrote:
In the keyboard section of the attached document there are instructions for
testing with a terminal & USB>TTL RS-232 adapter.
> On Sat, Feb 15, 2025 at 12:43 AM Steve Lewis <lewissa78(a)gmail.com> wrote:
>
> Thanks, I had forgotten about the Kaypro. Looks like it uses a "custom"
> 4-pin wire (one of them being 5V power). So just level-shift the TX/RX
> pins through a MAX232 IC and it would talk to another R-232 system at 300
> baud eh? Might have to seek out a lone Kaypro keyboard to give it a try.
>
> I suspect some of the "serial style" mid-1980s IBM Model M keyboards are
> similar. But I'm still wondering if anyone used this concept in the late
> 1960s - teletypes were expensive, flipping switches was tedious, so
> keyboard alternates were hot items by early 70's (hence the TVT popularity).
>
>> On Fri, Feb 14, 2025 at 5:28 PM Mike Stein <mhs.stein(a)gmail.com> wrote:
>>
>> I believe that at least Kaypro used a TTL form of RS-232 for the
>> keyboard; in fact, ISTR using an RS M100 notebook (+/- 5V) in place of a
>> keyboard in distant days.
>>
>> On Fri, Feb 14, 2025 at 12:27 PM Steve Lewis via cctalk <
>> cctalk(a)classiccmp.org> wrote:
>>
>>> Rick Bensene:
>>>
>>>> I will try to find my Xircom parallel port Modem and Ethernet adapters
>>> in
>>>> a box somewhere in my storage area and take a photo of them. If I can
>>> find
>>>> them, I’ll post a link here to the photos so those in disbelief can see
>>>> them.
>>>
>>>
>>> That'd be neat to see, if you do find the Xircom parallel modem.
I've
>>> seen
>>> combo ones and their "parallel-ethernet" devices (which seem to go
for
>>> quite a premium these days), but not the modem only. Suppose they
>>> weren't
>>> too popular, as even laptops started to have built in modems.
>>>
>>> These days, I do use an SDLPT, that lets you use SD-cards to transfer
>>> data
>>> into a system over the parallel port. I suppose that's the same
general
>>> principle (of read/writing one full byte at a time to a device). I
>>> haven't measured its performance yet (but would characterize it as
being
>>> comparable to a physical 3.5" floppy disk drive kind of performance -
I
>>> think copying Quake took over 40 minutes, something like that; but I'd
>>> like
>>> to get more accurate about it, down to an actual bytes-per-second rate).
>>> Measuring that might give me an answer on how fast something like
>>> Laplink/Interlink cable should be able to perform.
>>>
>>> As another experiment, I'll drop that ~7MHz 16550 serial card into a
386,
>>> and see if I can get a 386 to push data out on RS-232 faster than 115200.
>>> It should, but we'll see!
>>>
>>>
>>> And I think I will do an RS-232 themed talk in June VCF, if a spot is
>>> still
>>> open - I think I have enough now to make it interesting. One area I'm
a
>>> little stuck on is verifying that anyone actually did make an RS-232
>>> keyboard. Even for TV Typewriter, I'm not sure if I'd characterize
that
>>> as
>>> RS-232 related. And Gordon Bell integrated an ASR-33 (current loop) to
>>> the
>>> PDP-1, but might not be accurate to call that RS-232 (but can't a
current
>>> loop based thing be adapted to voltage?). I thought the POLY-88 keyboard
>>> was RS-232, but it'll be awhile before I can get back to that
equipment.
>>>
>>>
>>> -Steve
>>>
>>>
>>>
>>> On Thu, Feb 13, 2025 at 6:32 PM Rick Bensene via cctalk <
>>> cctalk(a)classiccmp.org> wrote:
>>>
>>>> Henry wrote:
>>>>
>>>>> I remember those, and when I went searching to look for more
>>> information
>>>> on them I found something I > hadn't stumbled on before -
apparently
>>> Xircom
>>>> made a parallel port Ethernet adapter. It must have
>>>>> been pretty painful. The parallel port wasn't a great high
speed
>>>> interface…
>>>>
>>>> ----
>>>>
>>>> Yes, I have one of those parallel port Ethernet devices too. But,
>>>> remember, back at that time, Ethernet was commonly 10Mb/Sec. I think
>>> that
>>>> 100Mb/Sec was only located in high-end datacenters and was very
>>> expensive.
>>>> For a laptop that didn’t have a PCMCIA port, and you wanted it on an
>>>> Ethernet network, this was an acceptable way to go. Performance wasn’t
>>>> great, but most of the time laptops like this were used for TELNET
>>>> connections to other hosts on the local network for “GREEN SCREEN” type
>>>> applications that ran entirely on the remote host. Performance in such
>>>> cases wasn’t nearly as much of a concern as it would be in the not too
>>>> distant future.
>>>>
>>>> I will try to find my Xircom parallel port Modem and Ethernet adapters
>>> in
>>>> a box somewhere in my storage area and take a photo of them. If I can
>>> find
>>>> them, I’ll post a link here to the photos so those in disbelief can see
>>>> them.
>>>>
>>>> -Rick
>>>>
>>>>
>>>>
>>>> From: Henry Bent [mailto:henry.r.bent@gmail.com]
>>>> Sent: Thursday, February 13, 2025 3:54 PM
>>>> To: General Discussion: On-Topic and Off-Topic Posts <
>>>> cctalk(a)classiccmp.org>
>>>> Cc: Rick Bensene <rickb(a)bensene.com>
>>>> Subject: Re: [cctalk] Re: RS232 - parallel modems!?
>>>>
>>>
>>
16 Feb
16 Feb
4:11 a.m.
Wayne, the attachment has showed up for me (using regular "gmail" web
client). I'm not sure what part of the system here decides to filter out
attachments. But to Mike, I wanted to report Thanks for the attachment, it
did work for me at least.
Had an interesting talk with Usagi today around his LGP-21 (yes from 1963),
debating whether the ASR-33 was RS-232 or not. He thinks not all ASR-33
were current-loop, but whether they were adapted after the fact, we're not
sure (there was also KSR-33 and RO-devices).
Also, today I discovered the world of early building security systems that
used RS-232 to do biometrics (hand scanners of literal hands and such).
-Steve
On Sat, Feb 15, 2025 at 3:26 PM Wayne S <wayne.sudol(a)hotmail.com> wrote:
I don’t see the attachment.
Sent from my iPhone
On Feb 15, 2025, at 13:22, Mike Stein via cctalk
<cctalk(a)classiccmp.org>
wrote:
In the keyboard section of the attached document there are instructions
for
testing with a terminal & USB>TTL RS-232
adapter.
> On Sat, Feb 15, 2025 at 12:43 AM Steve Lewis <lewissa78(a)gmail.com>
wrote:
>
> Thanks, I had forgotten about the Kaypro. Looks like it uses a "custom"
> 4-pin wire (one of them being 5V power). So just level-shift the TX/RX
> pins through a MAX232 IC and it would talk to another R-232 system at
300
> baud eh? Might have to seek out a lone
Kaypro keyboard to give it a
try.
>
> I suspect some of the "serial style" mid-1980s IBM Model M keyboards are
> similar. But I'm still wondering if anyone used this concept in the
late
> 1960s - teletypes were expensive, flipping
switches was tedious, so
> keyboard alternates were hot items by early 70's (hence the TVT
popularity).
>
>> On Fri, Feb 14, 2025 at 5:28 PM Mike Stein <mhs.stein(a)gmail.com>
wrote:
>>
>> I believe that at least Kaypro used a TTL form of RS-232 for the
>> keyboard; in fact, ISTR using an RS M100 notebook (+/- 5V) in place of
a
>> keyboard in distant days.
>>
>> On Fri, Feb 14, 2025 at 12:27 PM Steve Lewis via cctalk <
>> cctalk(a)classiccmp.org> wrote:
>>
>>> Rick Bensene:
>>>
>>>> I will try to find my Xircom parallel port Modem and Ethernet
adapters
>>> in
>>>> a box somewhere in my storage area and take a photo of them. If I
can
>>> find
>>>> them, I’ll post a link here to the photos so those in disbelief can
see
>>>> them.
>>>
>>>
>>> That'd be neat to see, if you do find the Xircom parallel modem.
I've
>>> seen
>>> combo ones and their "parallel-ethernet" devices (which seem to go
for
>>> quite a premium these days), but not the modem only. Suppose they
>>> weren't
>>> too popular, as even laptops started to have built in modems.
>>>
>>> These days, I do use an SDLPT, that lets you use SD-cards to transfer
>>> data
>>> into a system over the parallel port. I suppose that's the same
general
>>> principle (of read/writing one full
byte at a time to a device). I
>>> haven't measured its performance yet (but would characterize it as
being
>>> comparable to a physical 3.5"
floppy disk drive kind of performance -
I
>>> think copying Quake took over 40
minutes, something like that; but I'd
>>> like
>>> to get more accurate about it, down to an actual bytes-per-second
rate).
>>> Measuring that might give me an
answer on how fast something like
>>> Laplink/Interlink cable should be able to perform.
>>>
>>> As another experiment, I'll drop that ~7MHz 16550 serial card into a
386,
>>> and see if I can get a 386 to push
data out on RS-232 faster than
115200.
>>> It should, but we'll see!
>>>
>>>
>>> And I think I will do an RS-232 themed talk in June VCF, if a spot is
>>> still
>>> open - I think I have enough now to make it interesting. One area
I'm a
>>> little stuck on is verifying that
anyone actually did make an RS-232
>>> keyboard. Even for TV Typewriter, I'm not sure if I'd characterize
that
>>> as
>>> RS-232 related. And Gordon Bell integrated an ASR-33 (current loop)
to
>>> the
>>> PDP-1, but might not be accurate to call that RS-232 (but can't a
current
>>> loop based thing be adapted to
voltage?). I thought the POLY-88
keyboard
>>> was RS-232, but it'll be awhile
before I can get back to that
equipment.
>>>
>>>
>>> -Steve
>>>
>>>
>>>
>>> On Thu, Feb 13, 2025 at 6:32 PM Rick Bensene via cctalk <
>>> cctalk(a)classiccmp.org> wrote:
>>>
>>>> Henry wrote:
>>>>
>>>>> I remember those, and when I went searching to look for more
>>> information
>>>> on them I found something I > hadn't stumbled on before -
apparently
>>> Xircom
>>>> made a parallel port Ethernet adapter. It must have
>>>>> been pretty painful. The parallel port wasn't a great high
speed
>>>> interface…
>>>>
>>>> ----
>>>>
>>>> Yes, I have one of those parallel port Ethernet devices too. But,
>>>> remember, back at that time, Ethernet was commonly 10Mb/Sec. I think
>>> that
>>>> 100Mb/Sec was only located in high-end datacenters and was very
>>> expensive.
>>>> For a laptop that didn’t have a PCMCIA port, and you wanted it on an
>>>> Ethernet network, this was an acceptable way to go. Performance
wasn’t
>>>> great, but most of the time
laptops like this were used for TELNET
>>>> connections to other hosts on the local network for “GREEN SCREEN”
type
>>>> applications that ran entirely on
the remote host. Performance in
such
>>>> cases wasn’t nearly as much of a
concern as it would be in the not
too
>>>> distant future.
>>>>
>>>> I will try to find my Xircom parallel port Modem and Ethernet
adapters
>>> in
>>>> a box somewhere in my storage area and take a photo of them. If I
can
>>> find
>>>> them, I’ll post a link here to the photos so those in disbelief can
see
>>>> them.
>>>>
>>>> -Rick
>>>>
>>>>
>>>>
>>>> From: Henry Bent [mailto:henry.r.bent@gmail.com]
>>>> Sent: Thursday, February 13, 2025 3:54 PM
>>>> To: General Discussion: On-Topic and Off-Topic Posts <
>>>> cctalk(a)classiccmp.org>
>>>> Cc: Rick Bensene <rickb(a)bensene.com>
>>>> Subject: Re: [cctalk] Re: RS232 - parallel modems!?
>>>>
>>>
>>
3:48 p.m.
On 2/15/25 22:11, Steve Lewis via cctalk wrote:
Had an interesting talk with Usagi today around his LGP-21 (yes from 1963),
debating whether the ASR-33 was RS-232 or not. He thinks not all ASR-33
were current-loop, but whether they were adapted after the fact, we're not
sure (there was also KSR-33 and RO-devices).
I believe there was an optional RS-232 to current loop
converter board that could be supplied by Teletype so the
ASR33 could be used with a standard RS-232 modem for dial-up
use. It was a fairly small card about the size of a credit
card IIRC.
Jon
14 Feb
14 Feb
12:52 a.m.
On Feb 13, 2025, at 6:54 PM, Henry Bent via cctalk
<cctalk(a)classiccmp.org> wrote:
On Thu, 13 Feb 2025 at 18:44, Rick Bensene via cctalk <cctalk(a)classiccmp.org>
wrote:
The later parallel ports include several faster modes than the original one. The best of
these is "EPP" mode which is fully bidirectional, with interlocked high speed
handshakes. I think you can get fairly close to (original) Ethernet speeds with those.
I once built a software-defined radio using one of those for its baseband data/control
interface, it worked quite well. The state machine fits in a small CPLD (Lattice
isp2032).
paul
There was a company called Xircom that made parallel port modems. These
were full modems that were small enough that they plugged into a laptop
serial <parallel> port, and got their power from the laptop via the
external mouse/keyboard port. They had a feed-though connector so you
could still connect and external mouse/keyboard if you wanted. ...
I remember those, and when I went searching to look for more information on
them I found something I hadn't stumbled on before - apparently Xircom made
a parallel port ethernet adapter. It must have been pretty painful. The
parallel port wasn't a great high speed interface; I unfortunately had a
parallel port ZIP drive and it was a dog.
-Henry
3:58 p.m.
On 2/13/25 18:52, Paul Koning via cctalk wrote:
The later parallel ports include several faster modes than the original one. The best of
these is "EPP" mode which is fully bidirectional, with interlocked high speed
handshakes. I think you can get fairly close to (original) Ethernet speeds with those.
I once built a software-defined radio using one of those for its baseband data/control
interface, it worked quite well. The state machine fits in a small CPLD (Lattice
isp2032).
I'm pretty much an expert on EPP mode operation. (I make a
line of CNC motion control boards that interface to the PC
via EPP-mode parallel port.) Mostly, you can get up to
about 1 mbyte /second with this.With no cable between the
external device and PC, it might go a little faster.
Jon
4:16 a.m.
On 2/13/2025 5:54 PM, Henry Bent via cctalk wrote:
On Thu, 13 Feb 2025 at 18:44, Rick Bensene via cctalk
<cctalk(a)classiccmp.org>
wrote:
Yep, I used both the PEII and the PE3.
https://www.ardent-tool.com/Xircom/Xircom_Pocket_Adapters.html
Hard to install on a parallel port, due to the little thumbscrews, but
worked fine
The PE3 was awesome, though, for a device without Ethernet. The
track-like thumbscrew was awesome if you needed to detach the unit. At
the time, I was using a PC110 IBM Pocket COMputer with two docking
stations and some store and forward packet SW to have my personal data
at work and home. Using the PEIII on the dock was so helpful. The PC110
had 2 Type I-II/1 Type III PCMCIA slot, and it needed the whole slot for
the 260MB PCMCIA drive, so using a PC card for Ethernet was not possible.
Not sure if that dock had EPP, but even the simple Parallel port was
acceptable on speed for me, even for early Windows 95 web browsing.
The link above shows they made a ArcNet adapter, a Token Ring Adapter,
and it says there was an EtherTalk adapter, not sure of the use case.
Here's a link to some drivers for the PEIII:
https://retrocmp.de/transfer/xircom-pe3.htm
Never saw the combo modem+ethernet, but the I was impressed by the
PEIII. When I finally was able to get a Type II HDD, I was able to use
a PC card Ethernet adapter and the PEIII I think got shared with someone
at a show.
Jim
--
Jim Brain
brain(a)jbrain.com
www.jbrain.com
There was a company called Xircom that made
parallel port modems. These
were full modems that were small enough that they plugged into a laptop
serial <parallel> port, and got their power from the laptop via the
external mouse/keyboard port. They had a feed-though connector so you
could still connect and external mouse/keyboard if you wanted. ...
I remember those, and when I went searching to look for more information on
them I found something I hadn't stumbled on before - apparently Xircom made
a parallel port ethernet adapter. It must have been pretty painful. The
parallel port wasn't a great high speed interface; I unfortunately had a
parallel port ZIP drive and it was a dog.
-Henry 
4:01 p.m.
On Mon, 10 Feb 2025 at 23:48, Rick Bensene via cctalk
<cctalk(a)classiccmp.org> wrote:
There was a company called Xircom that made parallel port modems. These were full modems
that were small enough that they plugged into a laptop serial port, and got their power
from the laptop via the external mouse/keyboard port.
Er, is it possible that you are mixing up modems with Ethernet
adaptors? Xircom was well known for parallel-port Ethernet adaptors,
such as seen here:
https://www.ardent-tool.com/Xircom/Xircom_Pocket_Adapters.html
I supported several and they worked very well, even with Linux. With
an ECP/EPP+ port they could be quite fast.
https://en.wikipedia.org/wiki/Parallel_port#EPP_and_ECP
After laptops started having PCMCIA ports, Xircom
made some modem cards in PCMCIA form-factor, and they had a little dongle that plugged
into them that provided the RJ11 jack to plug the phone line into.
Sure, many companies did. Xircom was far from alone. Most had dongles.
Indeed one of the only type II cards that _didn't_ were 3Com XJACK cards.
https://en.wikipedia.org/wiki/XJACK
I think these could go up to 14.4Kb, maybe more.
(!)
Far more. I am not sure I ever saw one that slow. 28.8 was normal,
33.6 briefly, and the one I used longest was 56K.
For me the nifty device was their RealPort range which needed a type III slot:
https://docs.rs-online.com/04a6/0900766b8002b85f.pdf
They also did very clever "Realport 2" cards which could be mirrored,
one inserted upside down, so you could insert 2 of them into a pair of
type 2 slots in one physical type 3 slot *with one running upside
down,* for 2 x full-sized connectors.
https://www.ebay.com/itm/312549616539
Xircom was also one of vanishingly few companies to offer working USB
drivers _for Windows NT 4_ -- an OS that did not support USB.
https://forums.scotsnewsletter.com/index.php?/topic/7054-usb-on-nt4/
--
Liam Proven ~ Profile: https://about.me/liamproven
Email: lproven(a)cix.co.uk ~ gMail/gTalk/FB: lproven(a)gmail.com
Twitter/LinkedIn: lproven ~ Skype: liamproven
IoM: (+44) 7624 227612: UK: (+44) 7939-087884
Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
48
days inactive
55
days old
44 comments
20 participants
participants (20)
-
ben -
Cameron Kaiser -
Christian Groessler -
Christopher Zach -
Ethan Dicks -
Fred Cisin -
Glen Slick -
Henry Bent -
Jim Brain -
Jon Elson -
Liam Proven -
Maciej W. Rozycki -
Mike Stein -
Paul Koning -
Peter Corlett -
Rick Bensene -
Steve Lewis -
Warner Losh -
Wayne S -
wrcooke＠wrcooke.net