Apple //c raw terminal to Wimodem-232

[Micah Cowan]

I'm stumped as to what I'm doing wrong/missing.

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?

Thanks,
-mjc

[Andrew Roughan]

Post by Micah Cowan
...
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
However, if I type an "AT" command, I never get any response (expecting
- 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>.
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. > What am I missing?

After a modem connects to another modem it passes through whatever it
receives until you send the sequence that it is looking for to indicate
that you want to send it a command.
Have you tried ‘+++’ before your AT?

Regards
Andrew

[Micah Cowan]

Post by Andrew Roughan
After a modem connects to another modem it passes through whatever it
receives until you send the sequence that it is looking for to indicate
that you want to send it a command.
Have you tried ‘+++’ before your AT?

Good idea - but no, that didn't help.

-mjc

[Hugh Hood]

Micah,

To expand upon that which Andrew suggested, try a <pause>+++<pause>
before the AT, with <pause> being defined as a 1 second delay.

It's been years since I messed with modems, but I think that's what was
needed to get the modem into 'command' mode.




Hugh Hood

Post by Micah Cowan

Post by Andrew Roughan
After a modem connects to another modem it passes through whatever it
receives until you send the sequence that it is looking for to indicate
that you want to send it a command.
Have you tried ‘+++’ before your AT?

Good idea - but no, that didn't help.
-mjc

[awanderin]

Hugh Hood <***@earthlink.net> writes:

Does it work with a PC running Windows? How about a PC running Linux or
perhaps a Mac? Try to figure out if the device works at all with
anything.


--
Jerry awanderin at gmail dot com

[Micah Cowan]

Does it work with a PC running Windows? How about a PC running Linux or
perhaps a Mac? Try to figure out if the device works at all with
anything.

Thanks, but as I've stated in my original post, the device has already been proven to work even just on the Apple //c, from Proterm, so there's no need to try operating it from other configurations to see if the device works - it does. It already works with Proterm - I'm trying to get it to work equally well from the I/O port firmware's built-in terminal mode, so that I can then hand control of my Apple over to the modem (while connected elsewhere). The problem is (presumably) a gap in my understanding, either in what sort of configuration step I may be missing in initializing the connection, or else in entering commands that will elicit a response from the device. (Unfortunately, pausing longer around the +++ entries provided no progress.)

-mjc

[Hugh Hood]

Post by Micah Cowan
I'm trying to get it to work equally well from the I/O port
firmware's built-in terminal mode, so that I can then hand control
of my Apple over to the modem (while connected elsewhere).

Micah,

This is a long shot, here goes --

The terminal mode *may* be sending out characters with the high bit set.
If the Wimodem sees the 'AT' with high-ascii characters, it *may* not
recognize them.

So, you can put the IIc in 'space parity' mode in order to send just
7-bit text with the 8th bit = '0'.

The command is: <ctr-A>7P

Note: This works on the SSC, so I'll assume it works on the //c. It does
NOT work on the //gs.

Apologies for my errant send to your email account. Let's keep this on
the group.




Hugh Hood

[Oliver Schmidt]

Hi,

I'm wondering why nobody has mentioned so far:

If one software works and another soft(or firm)ware doesn't then it may
relate to hardware handshake lines.

Regards,
Oliver

[Micah Cowan]

Post by Oliver Schmidt
If one software works and another soft(or firm)ware doesn't then it may
relate to hardware handshake lines.

It turns out that Hugh's suggestion of <ctrl>A 7P was the one to set me on the right path - but if it hadn't been, how would I played with this sort of thing? Would it involve poking values into the right memory locations, would I need to call some MLI routine directly, or would there likely have been other <ctrl>A commands I could use?

Cheers,
-mjc

[Micah Cowan]

Post by Hugh Hood
So, you can put the IIc in 'space parity' mode in order to send just
7-bit text with the 8th bit = '0'.
The command is: <ctr-A>7P

Okay, this is _totally what was wrong_! Issue solved :D Not such a long shot after all, turns out, and I really, _really_ appreciate your coming up with that suggestion.

I needed to follow it up with <ctr-A>1D as well to ensure the actual textual data only took up 7 bits. CR LF translation is _not_ necessary (but doesn't hurt anything either).

And here's where I find out that, despite my attempt to thoroughly describe all information that could help someone help me find a solution, I realize after the fact that there was probably additional information I might have provided that could have helped clue someone in to this being the likely explanation: while I would place the Apple II's I/O port in its (default) mode of 8N1, when I successfully got serial terminal stuff working to a Windows PC running Tera Terminal, I was using 7N1 as the setting on that side. I didn't understand why that could even work (I guess the "stop" bit has a special shape so an "extra" data bit occurring before it can just be ignored?), but as I'd gotten some amount of my information from this page here, which indicated they'd had to do that, I just sort of shrugged and moved on: http://c64retr.blogspot.com/2013/11/serial-port-communication-on-apple-iic.html

.

Oh yeah - Apple //c firmware doesn't appear to have a "slot-chaining" feature like the SSC, so after I get things set up, I go into the monitor and enter my own slot-chaining CSW routine, enabling output to go both to the screen and also to the remote end:

300: 20 F0 FD 20 07 C2 60
36: 0 3

Note that this will only work when no OS is loaded (as DOS and ProDOS use their own CSW, and will swap it in whenever they find someone else's there) - you'd need to poke that second line into some other location for DOS, and in ProDOS you'd run PR#A$300. Also if you're curious about the JSR $C207, that's what the I/O port firmware resets CSW to after you call it with C200, the direct jump to the PR# handler (so it's not trying to figure out if it's being called via PR#2 or IN#2)

If the connection drops while that CSW is active, it'll enter a feedback loop over the return character, requiring a Control-Reset to break out. But if I know in advance I'll be dropping the connection, I just issue a PR#0 first.

Thanks again! It's quite exciting to operate my Apple //c from my PC keyboard over wifi!

[Micah Cowan]

Post by Hugh Hood
Apologies for my errant send to your email account. Let's keep this on
the group.

Whoops - that was my bad, not yours. Using Google Groups, which is sending all the responses to my gmail account. It looked different from just a normal email in how it was showing up in my Inbox, and I thought that replying to it in my Gmail would be equivalent to replying to it in Google Groups.... apparently not.

-mjc