2020-10-19 07:49:14 UTC
My goal is to use the Apple //c's Serial I/O Port 2 firmware's built-in "terminal" mode to control my (Hayes compatible) Wimodem-232. I am able to communicate with the modem fine, and receive text back from the modem fine, but even fiddling around with line endings and the like, it never responds to any AT commands I send it in that manner.
Probably unimportant, but if you're curious my purpose (for now - I'd want to be able to do this regardless just so I know how) is to set up remote control of my Apple //c via a wifi connection to netcat or the like running on a modern PC, and be able to copy/paste (say) AppleSoft program listings between them (I am currently able to do this fine via a direct serial-to-USB connection, using a null modem cable, which I've also used successfully with ADTPro). For right now, though, just trying to successfully direct the Wimodem from a direct terminal mode, without the use of actual terminal software.
I am able to drive the Wimodem-232 just fine using ProTerm 2.2, connecting to remote BBSes, and webservers (and getting HTML back if I'm quick enough typing my HTTP requests by hand), so I know for certain that it is possible for me to drive the Wimodem-232 from my //c, given the right incantations. When I type "AT" in command mode, I get an "OK" response back, etc.
Here's what I'm doing to get a raw terminal connection to the modem:
1. At boot, I type Control-Reset to get out of boot-from-disk mode and into AppleSoft (note: no OS loaded).
2. I then type: IN#2 <Return>
3. Followed by: Control-A T
4. Further followed by: Control-A 15 B (no spaces, no <Return> - this is Apple //c firmware and not a SSC or the like, so processing stops immediately when the B is typed). This puts me into 19,200-baud, at which point I'm able to communicate fine with my Wimodem-232 (which has been configured to boot up in 19,200 mode).
Now, at this point, if I power on the Wimodem, I will see text to the effect of "Looking for router..." etc. Once it's either found or failed to find a router, I can type text and have it echoed back from remote, which tells me that it is indeed seeing the characters I've typed correctly (local echo is off, so if I power off the modem I stop seeing what I'm typing; if I turn local echo on with Control-A I, then I see every character typed twice).
However, if I type an "AT" command, I never get any response (expecting an "OK"). This remains the case if I:
- Type "AT" <return>-or-Control-M
- Type "AT" <return>-or-Control-M Control-J
- Type "AT" Control-J
- activate automatic linefeed insertions with Control-A L, and then type "AT" <return>. I can see that this works as intended when I turn off control processing with Control-A Z, after which I see the echoed-back linefeeds
I'll note that I tried all of these things twice in succession, in case I'd found the correct line ending to fix things, but it had included some of the previous line-ending attempts as part of the current line.
I'll also note that I did try things like "ATQ0" to explicitly turn quiet mode off and indicate that I want "OK" responses and the like, even though this isn't necessary when I use ProTerm. I repeated all the above attempted line-endings for "ATQ0". I also tried an "ATDT hostname:port" command that, even if it didn't illicit a response, should've shown changes on the Wimodem's OLED screen if it had been obeyed. Tried it with and without auto-linefeed turned on.
At this point I'm at a complete loss as to why ProTerm gets the expected behavior, but the I/O port firmware's raw terminal doesn't. Clearly ProTerm does some sort of setting or other thing that I'm not doing, but what? It seems to me that I've ruled out CR LF issues at this point. What am I missing?