Asynchronous Communication is a concept where the computer is sending/receiving data between another computer, but in a fashion that isn’t involving the main CPU. This data-exchange happens asynchronously, without interrupting whatever the user is using the computer for. It is a form of “bit-banging” where sequences of bits/voltages are interpreted between the two computers. Before TCP/IP and Network Cards, this was how data was exchanged between computers. But it was point-to-point, directly between two machines. A “modem” was a small machine that handled this exchange across a phone-line, so the two machines involved didn’t need to be physically next to each other (but it was still a point-to-point connection: one machine “talking” directly to one other machine).
This was one of the prime jobs of an Operating System: asynchronously handling I/O, such as disk access or audio playback, and also external communication. Application software specifies what byte to send (e.g. the letter “A”), and the serial-communication device does the job of doing that bit-by-bit in an appropriate “handshake” protocol to ensure the full byte it sent correctly. The speed of this exchange is proportional to the clock rate of the system. Some of the earliest speeds were 50, 110, 300 “baud” (roughly bits per second). Throughout the 1980s, speeds of 1200 to 9600 baud were common, and the technology (of modems using copper lines) peaked at about 38400 – 57600 baud. Modern day embedded hardware still uses basically this same “bit-bang” concept, such as for firmware hardware updates, and operate at 10x the speed (across USB).
The WiModem232 simulates a Hayes dial-up modem that is connected to a serial port. The specific serial card for the IBM PC 5150 8-bit ISA that I have is labeled as follows:
- EV-170A / PWA-00158-00
The original IBM PC 5150 Asynchronous Communication Adapter was available at the 1981 August launch as an add-on card, using an 8250 chip (as described in the Reference Manual) limited to 9600 baud.
Background of “Hayes-compatible” Modem
D.C. Hayes developed modems for microcomputers in 1977 (along with defining a standard command convention known as AT-command). See here for details. The first known BBS (electronic bulletin board system) was setup in December 1978 in Chicago. These devices allowed a point-to-point two-way digital communication between any computer (Commodore machines could “talk” to Apple machines, both in turn could “talk” to IBM machines, and vice versa). The communication was largely limited to standard ASCII character, but certain character sequences could get interpreted as color changes or cursor repositions (by using “escape sequences” defined by ANSI).
Multi-line BBSs were soon built, which would coordinate the cross-communication between connected “users.” However, such a setup required the host to have an additional phone line for each user (supporting 16 users required 16 phone lines, which could get very expensive for the host). If the host had only a single line, then other callers would get a busy-signal until the line was available. I had a single-line BBS for many years in the early 1990s in north Florida, with a peak call rate of about 30 users per day. The users would post messages, download and upload files (leaving brief one line descriptions), or play some “DOORS” games (“doors” would transition the connection from the BBS software over to another program that managed the game, so like going through a door to another room).
Tones in the modem were used to “talk” to the phone line, to dial numbers, listen for rings, and establish a connection (CARRIER DETECTED). The connected systems then used a standard protocol to establish the maximum data-rate of that connection (baud rate). This is why often just after the initial connection, you may see some brief “garbage” on the screen: the machines are effectively asking “can you hear me now?” at different baud rates (or different parity-bit conventions).
“Hayes Modem” meant a fairly standard set of MODEM COMMANDS was established, referred to “AT” commands (ATtention). Commands such as ATDT to dial, ATH0 to hang up, ATM0 to mute the speaker, etc. Another special command was “+++” to switch the modem from data mode into command mode. This was typically used to hang up (NO CARRIER) during an intense data stream download, or to query status about the modem. The “ATO” command would resume data mode.
For home consumer modems, this standard was used until right around the turn of the century (1999/2000), but the peak was around 1996 where modems were reaching top performance that could be achieved on classic analog copper lines (see here). Early internet providers would host hundreds of modems and phone lines, which were used to bridge those users onto the internet (via SLIP/PPP). I saw one of these rooms, with very extensive amounts of wiring, when the Florida Digital Turnpike was opening around 1995.
Setting Up a (Modern) WiModem to Emulate Asynchronous Terminal Communication
NOTE: While I like the WiModem232, I don’t recommend it for the IBM 5150. Since the 5150 is limited to five slots, one slot may be consumed by a single serial/parallel port card. You may want to use that serial port for a mouse. You can still get the “BBS experience” using a NIC (network ethernet card, which is available in 8-bit ISA) and Telnet (where mIRC includes an ANSI capable Telnet client). That way, you don’t have to swap between plugging in the WiModem or a mouse. And the NIC can be used to transfer software media over to the IBM PC. That said, the same WiModem232 can be used across multiple vintage systems, so it’s interesting to still exercise on the IBM PC to see how it works.
NOTE: Terminal programs are a great reason to use something like DESQview to “multitask” between a DOS shell and the terminal program. While connected to a BBS, then you can swap to the shell (if both activities are under about 128KB or 256KB) and do light file/directory maintenance, or view text files.
The specific WiModem232 that I used is:
https://www.cbmstuff.com/index.php?route=product/product&path=59_66&product_id=60%3fThese are not manufactured in bulk in some factory. Please respect these are made-to-order in batches, so they could take a little longer for shipping and were possibly hand made just for you. Specs are also online to make your own.
To Connect the WiModem232
The sequence of photos at the beginning of this article shows how to connect the WiModem232 to the serial port. The steps are:
- Obtain a long 25-pin serial cable (about 6 foot). Because the WiModem232 operates over WiFi, a long cable can be used to help position the WiModem232 where there is better reception. If there is no reception issue, a short cable can be used.
- One 25-pin connector of the serial cable attaches to the WiModem232
- For the IBM PC, the other 25-pin connector will need a 25-pin to 9-pin serial adapter
- NOTE: Alternatively you can get a long 25-pin to 9-pin cable, just depends on how you want to do the setup or what you can find available.
- The 9-pin adapter then goes into the serial port at the back of the PC
- Connect the USB power adapter into the WiModem232 (the USB connection side can go into a USB power adapter, or a “hot port” USB on a laptop).
Historically, there were “external modems” and “internal modems.” An internal modem could be insert into an expansion slot, inside (internal) to the computer, and communicated directly across the bus (and drawing power from that). An “external modem” (which came first back in 1977) would be outside the computer and needs its own power plug, with a number of lights to indicate connection status, and would connect to a serial port. Most external modems were about half the size of a typical box of cereal, so it is very cute that the WiModem232 is able to be made so very small.
How to use a Terminal to talk to the WiModem (first time)
AT ATtention, verify modem operation (OK response)
ATI information
AT*N list (wifi) networks
AT*NS2,<password> join network index 2 using <password>
AT*B9600 adjust modem baud rate to 9600 (set terminal to match)
ATDT<ip or name>:<port> dial (call) address (use specified port)
+++ switch from data to command mode (type this quickly)
ATO resume data mode from command mode
ATH0 hang up the modem (NO CARRIER)
ATE0 turn echo off
(there are many other Hayes commands,
these are the most typical to get started)The “Wi” in WiModem means WiFi (Wireless Fidelity). Modems never originally used WiFi, so the initial setup of the WiModem is a bit “off script” to how an original modem was used. it is a necessary one-time step needed to connect this modem to your WiFi router.
To begin, you will need a Terminal Program. In the late 1970s, there were “Dumb Terminals” where your local machine in front of you was just a keyboard and some wires that talked to an actual host computer somewhere else. A Terminal Program turns your computer into a similar thing: it knows how to access the serial port, and sends commands that then interact with a host that might be connected on that serial port. Those commands in this case are the standard Hayes Modem commands. Once connected, your machine becomes the terminal that is connected to a host, and the host generates responses to your commands (in the old days, a “dumb terminal” might be used at a library to search for books — the terminal had no local storage, it just sent commands to some host machine, and that host responded with search results).
The two terminal programs for the IBM PC that I recommend are:
- For the 5150, I suggest PROCOMM Plus 1.1B from 1988 [ should work with 256KB RAM systems ]
- If you have a 8MHz 8088 (or IBM AT), I suggest QModem
- I don’t yet have a Terminal program suggestion for systems under 256KB
In the early 1990s, I used QModem almost exclusively. But on my 4.77 MHz IBM PC 5150, I’ve found that QModem actually has quite a bit of overhead that makes it a little more sluggish to use.
In the following sequence/example, I will start with QModem, but then you will see why I transition over to PROCOMM.
Regardless of what terminal you use, the same Haytes AT commands are used, and the same general workflow is used. However, each Terminal Program might use slightly different keyboard commands to do certain steps.
- When you first start a terminal, you need to connect it to the correct COM port. If it is the only serial port in the system, typically that will be COM1. This is a serial port configuration, not a WiModem232 thing. The WiModem is just hanging off the cable of the serial port.
- When the WiModem232 is first powered on, mine seems to always revert back to the “default” or initial baud rate of 300 baud. While the terminal program seems to always exit and save the last baud rate that it was set at.
- So the first job when you load the terminal, type a few things. If you see “garbage” characters, it is probably because the terminal is at a different speed than the modem and is interpreting the signals incorrectly.
- Press ALT-P for PORT settings and change the COM1 speed to 300. Generally at the bottom the terminal will show what the current baud rate speed is set to. Set the speed, then save the setting, or ESCape out of the dialog.
- Now type “AT” and you should see “OK” in response.
- If you don’t see “AT” but you do see “OK” that may mean echo is turned off. Try typing ATE1 to turn ECHO on, or check the Terminal Program settings to see if it has some ECHO setting.
- If you still don’t see “OK” in response to type “AT“, then the baud rate may still be set incorrectly. Or maybe you accidentally changed PARITY or STOP bits or something. Go back to ALT-P PORT settings and try different baud rates. The Parity, Data, Stop settings should be 8-N-1. Older systems or more exotic host may need different settings, but at least in the IBM PC domain then 99% of the time it will be 8-N-1 (8 data, NO parity, 1 stop bit).
- Once you see “OK“, then issue the command “ATI” (or “ati“), that is ATTENTION-INFORMATION request command.
- You should see IP information about the WiModem232 (like typing IPCONFIG or IFCONFIG in Windows command line). If you’re not connected to a router yet, you might not have an IP yet.
- Type “AT*N” to see a list of available WiFi connection.
- Type “AT*NS0,<password>” (Select 0, to select the first listed WiFi connection – or choose a different index like, 1, 2, 3, 4, etc. as desired). The <password> is your typical password used to connect to your WiFi device. Unfortunately it is going to be shown in plain text as you type it. You could turn ECHO off if you’re really worried about that (ATHE0, ATHE1). When ECHO is off, things you are typing are still transmitted to the modem, but they are not “echo’d” back to be displayed on the terminal screen.
- NOTE: Echo wasn’t just to be a sort of “privacy mode,” it was mostly just to avoid cluttering up the terminal console window (which is probably already displaying other information content) while trying to send commands to the modem.
- After a moment, you should get a response of whether the connection worked or not. If there is an error or failure, double check the password and try again.
- Your SSID and password should get remembered by the WiModem232, so you shouldn’t have to do AT*N and specify the password again next time. (unless you move locations or connect to a different router)
- Now the next thing to do is to increase your baud rate, because 300 baud is horrible.
- To do this, use the command “AT*B9600” and then you see an “OK” response. I’ve learned that the actual effect of a command doesn’t actually take effect until after the “OK” is displayed.
- If you type anything, it should now appear as garbage (or show nothing at all), because the modem baud data rate is different than what the terminal is set at.
- Now adjust the terminal program to match your 9600 baud setting (ALT-P, set the PORT speed to 9600).
- In my experience, 9600 baud is the fastest the 4.77MHz IBM PC 5150 can support. If you are connecting to a very old Commodore system, it might also be speed limited to 2400 or 9600. But if you have an IBM PC AT and are connected also to a more modern system, you might be able to use 38400 baud. It really just depends on what actual hardware is being connected. Note, the IBM PC might connect at 38400, but it may be unreliable and lose characters over time (like it may not reliably render ANSI displays or transfer files with protocols like ZModem). If you see “dropped characters” during a display, try reducing the baud rate and reconnecting to the host.
- Once you’ve connected, the first initial starter connection I suggest is Al’s Geek Lab that was presented on YouTube.
- To do so, enter the command “atdtalsgeeklab.com:2323” ATDT is the command to dial, followed by effectively the IP address to connect to, and then the port number. Historically the ATDT command would be followed by an actual phone number (like ATDT4627006), it would be cute if the WiModem232 internally had a stored directory to map phone numbers into IP addresses (so you could make up any phone number you wanted, it would be sort of like a speed-dial indicator to a user defined IP address and port).
- You’ll see that this is then effectively using your Terminal as a telnet connection – but over a serial port at a throttled down baud rate! Plus your terminal can support things like ANSI to do colors and cursor movements, which not all telnet clients support that.
- Once you connect to the BBS, things will be great until you get a blast of full screen ANSI. If you are still using QModem, then notice at the bottom of QModem says “RECEIVE BUFFER FULL.” That’s a bad sign, since it may mean inputs are being dropped (raw modem connections don’t have MTU blocks and retry protocols like a TCP/IP connection).
- Here is where I exited QModem and switched over to using PROCOMM. The WiModem232 maintains the connection, so you can switch between Terminal Programs. But after PROCOMM loads, be sure to set it to the PORT BAUD speed you were using (9600).
- NOTE: A Hayes modem convention is you can quickly type “+++” to interrupt the modem and issue commands. If you want to disconnect quickly, type “ATH0” to HANGUP (you should see a “NO CARRIER” response). In the sample images below, I did this and reconnect to AlsGeekLab using ATDT command used earlier.
- Then create an account and have fun! You can check the local weather, leave messages for other BBS visitors, and join a group chat (which is similar to an IRC, but works differently).
- There are many other BBSs to explore.
The WiModem232 is a lot of fun to use. I do wish it emulated “dialing a modem” when using the ATDT command (it could just randomly generate a “phone number” and play it audibly, so you could hear it dial the numbers and then work on establishing the baud rate, then the speaker would automatically go silent). Old internal models had a speaker for this purpose. If you don’t have a spare serial port to use for this modem, but do have a NIC adapter installed (see notes here), then you can also use mTCP Telnet (which does also support ANSI terminal emulation) to connect to BBSs using the NIC card instead. The speed will be much faster, but the ANSI emulation might not be as accurate (in mTCP, see ALT+H help and notice the ALT+N/ALT+B options that may help navigate some BBSs). Also the telnet connection will not have any file transfer protocols, so you may not be able to upload/download files – but PROCOMM or QMODEM will support those over the WiModem232!
NOTE: I noticed that both QModem and PROCOMM will say “OFFLINE” at the bottom of the screen, even after doing ATDT and connecting to another system. Historically, these programs would detect the presence of a “carrier” and switch to saying “ONLINE.”
The following is an example of how things might look when “dropped data” starts to happen due to the baud rate being too high. This is similar to how a terminal that lacks ANSI support might look (as it randomly drops or misses the Escape Sequence tokens). The MoDem device itself has a certain speed limitation, but the local CPU performance can also restrict how fast the baud rate speed can be. In my experience with the stock 4.77MHz IBM PC 5150 – it can handle 9600 baud while using PROCOMM, but struggles to keep up when using QMODEM terminal program. When this starts happening, reduce the speed in the terminal program and try again (or use a less CPU intense terminal program).
A good reference on how to debug Serial Connections between two systems is written at the end of this thread:
https://forum.vcfed.org/index.php?threads/osborne-1-how-to-enable-80-column-mode.57315/