On Sun, Feb 9, 2025, 4:04 PM Steve Lewis via cctalk <[email protected]> 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 <[email protected]> wrote: > > > > > > > > On Feb 9, 2025, at 1:08 PM, Steve Lewis via cctalk < > > [email protected]> 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 > > > > >
