Hi Everyone, I am quite a young vintage computer collector and never got to experience the era of BBS. Upon looking through the internet I found that there are a few BBS's left that can be dialled into with an acoustic coupler.Description of problem
However, When trying to connect to a BBS, the monitor doesn't respond even though the Acoustic coupler is still able to maintain the call with the number I am connecting to. I can hear a continuous tone from the coupler as well as random noise data coming from the phone handset. I am assuming this random noise coming from the listening end of the telephone handset is data coming in. Both the 'Transmit Data', 'Receive Data' and the 'Carrier Ready' lights are stationary and do NOT flicker. The Receive lightone may occasionary go off and on but only briefly, the majority of the time it's on while the call is ongoing. Keep in mind the call does not drop for over 5 minutes but nothing shows up on the screen except what is shown in the photo at the bottom. Transmit Data = XMT, Receive Data = RCV, Carrier Ready = CRX for photo reference.
More details of the system below.
I am using an Apple IIe with a Super Serial Card which connects to a 300 baud Star Modem (I beleive it's 103-232 compatible)
- The Super Serial Card connects to the acoustic coupler through via a Male DB25 to Female DB9 Stright Through Cable to a DB9 Male to Male Connector to a Female DB9 to Male DB25 Stright Through Cable which connects to the Acoustic Coupler. I am not sure if it's the cable configuration/type? Maybe I should be using Null Modem instead of stright through. Will this make a difference with the type of issue I am describing?
- I am using a terminal emulator for the Apple II called proTERM. This program initially requests a type of modem that is installed into the Apple II. I wasn't sure what to select but the most relvant options avaliable are;
- Null Modem Driver - I chose this one.
Null Modem Driver RTS/CTS
There were some other options but they included Vendors that I didn't have.
3. The parameters used in proTERM 300 Baud, 8N1 and Full Duplex. I am not sure if these settings need to match those on the DIP switches of the Apple Super Serial Card. There are many Variables that could be casuing this issue. The photo below illistrates the online parameters used.
The BBS I found called Level 29: The BBS is located at "https://bbs.retrobattlestations.com/" and allows modems of 300 Baud to connect to it.
For the Telephone handset I am using a Western Electric Model 2500 DMG which connects to my router with Voip Capability.
IMPORTANT CONTEXT
That's the best looking acoustic coupler I've seen in decades.
Do you know the brand?
Livermore star.I had to get it shipped from the US. Found it on eBay
A nullmodem connection is a direct connection between two computers. So that's a raw connection, directly transmitting data. A nullmodem cable also crosses Rx and Tx - to connect two computers.
A modem was usually connected with a straight connector.
I never used accoustic couplers. But later modems all used a pretty common standard with an AT command set. The important thing is: unlike a nullmodem connection, a modem starts up in command mode. So, the computer first talks to the modem. The computer used a series of AT commands, to setup baudrate etc. Eventually, once everything was set up, the computer would ask the modem to leave command mode - and start passing through the line data instead.
I don't know anything about your specific modem, but I'd guess that it won't work when you select the nullmodem driver in your terminal. The nullmodem driver would directly expect a raw data connection. It would never tell the modem to leave command mode and start passing the data.
Do you have a manual for your modem? I have no idea if the AT command set was already standard for accoustic couplers - or if other standards were used then. I'd first check details on its command-set. Then use a terminal program just to talk to the modem itself - to verify the cable and local setup is all fine. Once that is working, the next step is to set up the terminal program, so it can talk to the modem... It might be sufficient to configure the command (byte sequence) to make the modem switch to data mode.
I never used one. But I believe that has a test mode that can be used to test the connection to the Apple and take the phone line out of the equation. You take the receiver off the coupler and switch it to test (looks like it's labeled tst on the coupler switch). You should hear a loud tone that the coupler both generates and hears. For this to work, the room should be quiet. In test mode, the screen should show anything you type.
My 2c, get a Wimodem232 and call it a day if you want to connect to BBSs. Messing around with an acoustic coupler or any other pots modem isn't really worth it these days. Plus it opens up many more BBS options that are telnet only and no longer offer dial up.
WiModem232 is a great product. I own 2 myself, one I leave set up for Mac or IIgs and the other is configured for ProTerm on the IIe.
The issue you are experiencing is because the Super Serial Card cannot receive data from your modem unless the Carrier detect pin is asserted.
Because you have no carrier detect on the acoustic coupler you will not be able to receive any data from the modem. Although...the SSC will allow outgoing communications.
The solution to this problem is a modified serial cable with a loop-back line from the DTR pin to the CD pin.
So on the modem side, open up the DB25 connector and tie the DTR pin 20 to the CD pin 8.
That will fool the SSC into thinking there is a call on-line.
Further...I highly recommend you get yourself a Wimodem232 from cbmstuff.com.
https://www.cbmstuff.com/index.php?route=product/product&product_id=60
It emulates a real modem (your IIe will not know the difference) and it will open up a whole world of telnet BBS systems (including mine - thebrewery.servebeer.com:port 6400)
There are 6 or so Apple II related BBS systems, and dozens of Commodore, Atari and others.
A "Null Modem" is a concept where two computers (or devices like computers) are connected together directly, without any actual modem used. Since you are trying to use a modem, you are specifically not utilizing a null modem.
"Modem" and "Null Modem" are mutually exclusive concepts.
The origin of these concepts is that communications need to define the function of each pin on the interface, including the signal direction (in or out). Since serial communications are very old—beginning in the electromechanical era—they don't have the ability to both send and receive over the same pin. So there is a pin over which data is only sent, and a pin over which data is only received. There are also many status signals, each assigned a permanent direction: in or out.
But as I'm sure you can appreciate, a signal sent out from device A at one end of a cable, is going in to device B at the other end. Even though the directions are permanent, they are relative to which end of the cable you choose to look at. The way serial communications makes sense of this is that it defines two different types of devices, called Data Terminal Equipment (DTE) and Data Communications Equipment (DCE). A normal cable, wired straight through, connects a DTE port (such as a computer serial card) to a DCE port (such as a modem). This means that a pin on the cable assigned to be TXD (Transmit Data) is interpreted to be transmitting from the DTE side to the DCE side, or in other words, the TXD pin on a DCE port is receiving data from the cable into that device. RXD (Receive Data) is likewise, mutatis mutandis.
So cables only connect DTEs to DCEs, which is fine when you have a typical remote connection using modems:
DTE and DCE
However, when connections are made locally between DTEs, the problem is that the pin definitions don't match up. Both DTEs use the TXD pin to send data, so it won't work to connect them with a cable that links the same pin on both sides together. The solution is to use a null modem, which simply means a box or cable that "crosses over" TXD with RXD (as well as the requisite status signals):
Null Modem
Since a modem is a DCE, you wouldn't use a null modem cable to connect a terminal/computer to a modem. Additionally, the gender of the connectors on DTE vs DCE is usually different, with male DB25 connectors on DTEs, and female DB25 connectors on DCEs. This facilitates connection with normal serial cables, which are straight through, DB25F to DB25M. However, the Apple Super Serial Card decided to do things differently, and has a female DB25 connector, which makes things interesting. Your cabling using DE9F-DB25M serial cables should work; it might be harder to find the correct DB25 male-male cable with straight through wiring.
Note that the SSC has an onboard crossover when the jumper block is pointing towards "TERMINAL". You need to set it pointing towards "MODEM" to use the card as a DTE port. This is another quite confusing aspect of the card.
Since your modem predates the Hayes command set, it does appear correct to use the "null modem driver". In this mode ProTerm doesn't send any commands to the modem, but just assumes that connection is already established.
Bell 103 modulation is slightly different from ITU V.21 although they perform the same.
The SSC jumpers for baud rate, parity, and duplex can be overridden by software commands, so the ProTerm settings should take precedence.
If the modem doesn't provide CD, DSR and CTS status signals, there could be a problem because I don't see how you would turn hardware flow control off in the SSC.
289358265_722530315675256_5440987691753828858_n.jpg
289284556_1165390687370138_7705569481124240038_n.jpg
289115529_1256471551824833_435162868515195784_n.jpg
289408842_598598651557997_655430997492240139_n.jpg
Hi baldrick,I am a bit confused on what you mean by with regards to the modified serial cable with a loop-back line from DTR pin to the CD pin. You also mention that I have no carrier detect on the acoustic coupler. I have a Carrier Ready indicator that goes on when I make a call. Is that not the same thing?
I have not worked with accoustic couplers for a couple of eons, so consider this more reflective conjecture than proven technical troubleshooting. I suspect the Carrier Ready indicator on the modem/coupler is more of an "off hook / dial tone detected" indicator. If baldrick is correct, the Super Serial Card (SSC) basically ignores data unless it detects the proper voltage on Pin 8, the Carrier Detect (CD) signal. While modem is working and the SSC can send data, it ignores anything coming back, hence no communication without the proper voltage on Pin 8. You can "borrow" the proper volatage from Pin 20 (DTR) to fool the SSC in to always be in an accepting data state. Assuming you have a removeable hood on the computer end of the cable, simply connect Pins 8 and 20 and test again. If you have a factory sealed cable. you will probably need to order some parts and make your own cable.
An RS-232 Breakout Box can be very helpful for diagnostic work. Here is an example
https://www.amazon.com/dp/B09T3PNYYP/ref=sspa_dk_detail_3
FWIW - Using the accoustic coupler sounds pretty retro cool, but you are likely to be underwhelmed after an hour or so of 300 bps. I to suggest a more modern modem for the authentic experience. Even a 1200 or 2400 bps external modem would provide a much better authentic bbs experience for very little money.
It means that you can jumper the pins together. That way, when the computer sends out the DTR signal (when you put ProTerm in "online" mode) it gets that signal reflected back through the CD )carrier detect) pin. So the Super Serial card "thinks" there is a call online with a remote device and it allows incoming communications.
Normally, modems do not assert the CD signal until a remote call is connected. That is, the modem dials out, receives a carrier signal, negotiates a connect speed and then once the call is negotiated the modem asserts the CD signal and sends it to the Super Serial card.
If you use ProTerm's "dial" menu then this is usually seamless because as I said before, the SSC will happily send signals to the modem but can only receive signals from the modem if CD is asserted (turned on).
But many of us like to type in our own "AT" codes to control "smart" Hayes type modems, so many modem manufacturers have a set of DIP switches on the modem, one of which turns CD permanently on so that these problems can be avoided. There are also special "AT" commands that you can send to the modem to do this in software.
However, you have an acoustic coupler. Most acoustic couplers from the old days only had Rx, Tx, GND (signal ground) and maybe DTR. The ones I remember had only those. CD wasn't really used by acoustic couplers because the human would physically dial the outgoing number on the telephone and wait for the remote carrier, inserting the handset into the acoustic coupler only when the remote carrier was heard by ear. Looking at your manual pages, it appears that you have a CD pin on it. But you don't necessarily have to use it that way, you can use my method. Also, ignore the RTS and CTS - they're really not needed with an Apple II. Just make sure your baud rate on your ProTerm is set to 300 baud.
Anyway, the fact remains. The Super Serial Card cannot receive any signals from your (or any) modem unless there is a physical signal at CD.
Tying the CD pin to DTR (which is a signal the SSC sends OUT to the modem) will fool the SSC into thinking there's a remote call online, thus allowing you to receive comms from your acoustic coupler.
According to the manual above the coupler has a CD signal on pin 8. And as I understood, the tests from the manual are also working fine - including the echo test. So, the SSC can send and receive data to the coupler. If the echo test with the coupler indeed works, this would eliminate cabling issues.
Did you verify all the other SSC settings (DIP switches) - baud rate, parity, stop bits etc? Since even when these were not properly set up, the echo test would still work (since the SSC sends and receives with the same settings).
You need to know what your current cable pinouts are. A breakout box can help, or you can test for continuity according to the diagram below. You can have a straight through modem cable where all 25 pins are connected and each end provides appropriate signaling to the opposite end. We are unsure if each end is asserting the proper lines in your case. Or, you can simply fake the handshaking at each end to get what is expected. I favor faking the handshake because so many RS-232 devices implement the various handshaking options differently. For instance, using the Secondary CTS rather than primary CTS allowed you to sell a custom cable at ridiculous prices. In your application, handshaking should not be needed, other than asserting CD on pin 8 at the SSC end.
Try a cable like this one and I bet it works.
In theory, you should be able to just whistle a sweeping tone into the coupler's reciever, and see a small amount of garble in your screen where the modem's trying to interpret your whistle as data. If this isn't happening, there's a break in your cabling somewhere -- generally, with anything old-school serial, you're going to want to have a null modem adapter at the ready, incase your send and recieve lines are switched. Try the above test with a null modem adapter somewhere in the middle between the computer and the modem. If you see nothing during both tests, chances are there's a problem with the modem itself, not the cable.
Here is the image I thought I referenced in the above post
https://www.applefritter.com/files/2022/07/03/modem_FakeHandshake.jpg
The above image was wrong. I am reminded it never pays to get in a hurry. Sorry.
Try a cable like this one.
See this image
https://www.applefritter.com/file/modemfakehandshakev3jpg