Hi brains trust, I recently ordered this 'The Old Net' RS232 Wifi Modem from Tindie: https://www.tindie.com/products/theoldnet/rs232-serial-wifi-modem-for-vintage-computers-v4
Overall I'm really happy with it, and it seems to work perfectly with my vintage Macs. However I'm having the strangest issue with my Apple //e and the Super Serial Card.
Literally, no matter what settings I try, no matter what cabling I use, no matter what software, it's like the 'echo' Hayes setting is stuck on. Everything I type is echoed back to the screen. Eg when connected to a BBS I type 'A', I get 'AA'. When configuring the modem if I set ATE0 I should see no typed text whatsoever, but I still see what I type as if this is set ON.
This only happens with the Wifi Modem. If I hook up to my PC or Raspberry Pi using TCPSer, this does not happen. I find this really strange, as I can't pin down where the problem is, as both the Apple //e and Wifi Modem work perfectly with other devices, just not with each other. These are the fixes I've tried so far:
- Different DIP settings (anything that will actually produce a working terminal prompt) including SW 1-7 off or on toggle (which is mentioned for similar products).
- Different Super Serial Card (I own two, both tested working)
- Different cabling (I have tried both straight through and null modem cabling, with the terminal block rotated on the card accordingly)
- Different software (I have tried ProTERM and ZLink, no difference. I have also tried numerous BBSes and my input is always echoed)
- Different modem settings (I have tried reversing pin polarity, toggling handle Telnet, quiet and verbose mode, different baud rates, and of course the echo setting).
- If I do enable echo on the modem (or locally on software), my text is echoed twice in the modem config screen and three times when connected (eg typing 'A' produces 'AAA)'.
- Modem factory reset (no change)
- Modem firmware update (no change)
At this point I'm frustrated, I have no idea what to try next, I don't have another Apple //e to test on.
Something suspicious I've noticed is that the 'R2IN' pin on the MAX3232 is not connected to the board, I don't know enough about how this should work to know if this is important (it seems like this is normally connected to TX on the DB9 port, but in this case R1IN is connected there instead). Just seems odd?
Any help would be appreciated!
Does your wifi modem or terminal software have an option for half-duplex?
So, I don't know if this will be helpful or if you already know what I'm going to say.
Serial comms work broadly speaking in two possible modes, half duplex and full duplex. There is another mode called simplex, but it is only used for one-way communications (where there is no reply possible). In half duplex, communication can occur in both directions but not simultaneously. An example is an old teletype with a current-loop interface connected to a minicomputer. Because the current loop is used to pass characters in both directions, it's not possible to receive a reply until the side that is transmitting stops talking and waits for a response. Although this seems archaic, current-loop interfaces were in use well into the 1980s and terminals like the VT220 included them.
In full duplex communication can take place simultaneously in both directions. So the lines that carry characters from DTE to DCE and vice versa are independent and both active at the same time. There were modems that were half duplex and those worked in full duplex. A telephone line doesn't have independent wires for sending and receiving; there is just a single consumer loop made of two wires. So for a modem to support full duplex it needs more elaborate circuitry that can cancel echoes and separate bands for sending and receiving. Even if there are independent send and receive wires between the DTE and the modem, communication may be forced to be half duplex due to the modem design.
The RS232 serial standard provides for wires carrying data in both directions simultaneously, and control signals in both directions so that the DTE and DCE can sense when the other side is ready to receive data or it must wait. These days the so-called flow control is most often carried over the RTS and CTS wires, but that was not their original purpose and older equipment doesn't work that way. Instead so-called software flow control is needed in which the receiver of data responds with a ^S or DC3 character (called "XOFF") meaning "stop", and when it is ready to process more data it sends a ^Q or DC1 character (called "XON") meaning "continue". This makes the serial channel non-transparent, in other words with software flow control it is not possible to send arbitrary binary data.
This is all relevant to the user of serial cards and comm software, because they need to know what form of serial protocol their equipment uses to correctly configure the port and the software. If the keys they type are expected to appear on the screen, then an arrangement must be made for either local or remote echo. Half duplex is only compatible with local echo, because while the user is typing, the remote system must wait until the user is finished. Local echo means that as the user types each key, the computer both sends the key to the DCE and also displays it on the screen. Remote echo means that as the remote system receives each key from the user, it sends it back so it will be displayed. Double characters are an indication that both local and remote echo have been enabled which is obviously undesirable. If neither local nor remote echo are enabled then typed keys are not displayed at all.
Make sure that SW1-5 and SW1-6 are both ON. SW1-7 should be ON, SW2-7 should be OFF.
You can test the serial connection from BASIC, which eliminates the comm program as a source of problems. If you have the SSC in Slot 2, you would type PR#2 (return) to BASIC to connect the keyboard to the SSC, and then Control-A, T, (return) to tell the SSC to enter Terminal mode. You can then type directly to the modem and see what the modem sends back.
Control-A, E, (space), D, (return) to disable local echo, and Control-A, E, (space), E, (return) to enable it.
The position of SW2-6 may also be relevant because it controls whether the SSC sends interrupts to the software running on the Apple. There are ways that unhandled interrupts may cause characters to be received more than once.
Hi all,
Even though the modem seems to work correctly on all my other equipment, I'm pretty sure that the problem lies with it somewhere. I want to try and reconnect that broken pin on the IC that I found but I'm worried that I'll break something else if this was done intentionally, I may check with the seller first.
Just a quick update, I connected the cut leg on the MAX232 IC to the board and this stopped anything from happening. Disconnecting it restored the modem to the previous state (with the echo). I don't know what to try next.
Well, if there's an echo coming from "somewhere", and the modem is working properly on other computers with serial connections, then the only thing left is the cable. Since the SSC is probably the oldest serial hardware (and it was designed for compatibility with an even older card), it makes sense to start looking at how its serial comms is implemented.
The schematic (for at least one version of the SSC) is here. It shows which DB25 pins are connected to which pins on the 10-pin right angle connector, and labels their function also. The function of SW1-7 and SW2-7 is explained more clearly by the schematic than any of the manuals (the switches must always be in opposite positions: with SW1-7 on and SW2-7 off, the card is in "RS232-C mode" in which the DCD signal comes from the DCD pin of the connector; with SW1-7 off and SW2-7 on, the DCD signal comes from DB25 pin 19, Secondary CTS which must be for compatibility with an older Apple standard).
The function of the printer/modem block is to redirect all of the pins of the cable. It is not the same as a null modem although it does swap TXD/RXD and DTR/DSR. The RTS/CTS signals do not get connected correctly with the block turned so hardware flow control will be broken.
I took a look at the documentation for the Wifi Modem, which appears not to be complete. But it does have its own echo mode, so the observed 'AAA' is consistent with