9 Feb
2025
9 Feb
'25
10:08 a.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
11:24 a.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.
11:35 a.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
3: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
3: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
7:27 p.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
>
3: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
4:47 p.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? 
4:09 p.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.
7:01 p.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:14 p.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.
>
>
11:33 p.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.
10 Feb
10 Feb
12: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
0
days inactive
1
days old
12 comments
8 participants
participants (8)
-
Fred Cisin -
Jim Brain -
Maciej W. Rozycki -
Paul Koning -
Peter Corlett -
Steve Lewis -
Warner Losh -
wrcooke＠wrcooke.net