Downloading problems with WiModem 232 and a UDS-10
Don't know if it makes a difference or not, but when when using my Mega STe with the WiModem 232
and attempting to download TESTFILE from File Sig 3, it always fails at the same place...

Around 47-50 percent of the download.

Last night I also tried turning CRC off on both machines (the one running DarkForce and the one I call in
with) but it didn't make a difference.

Still trying to come to grips with the commands.

If I were putting commands into a text file that hangs up the modem,
for the WiModem 232, would it be:




Thanks, all your help is greatly appreciated.
You can use +++ATHV0Q1 etc. The WiModem232 can use most commands sequentially.

Failure mid file transfer is really odd - either it works or it doesn't. There is no middle ground. However, this issue could be with the buffer that is receiving the data and saving. I know with the Amiga that with a high speed setting you have to save to the RAM disk because otherwise any writes to the hard drive can hold off the data long enough to put it out of sync and cause an error like what you describe.
Okay, this stuff is starting to make my head hurt. Smile

I used your command from above:


and then:


and both successfully download TESTFILE from File Sig 3.

Why doesn't "ATDT" work? I mean, I've tried it with both AT*T0 and AT*T1, then saved using AT*W, then connected using "ATDT", but downloading then fails.

Shouldn't it be the same? Something odd there, seems to me.

Well, it SHOULD be the same thing. I experimented with switching AT*T1 and AT*T0 after typing +++ to get into command mode (typing ATO to get back online after making a change). I was able to switch back and forth between Telnet on and off while during the connection in my testing without any issues.

I will try calling without using *T1, or *T0, prefixes. I only use the *T1, prefix when I know a BBS requires Telnet. Otherwise I have AT*T0 as the default and use ATDT for making all connections.
Bob hasn't approved my account yet, so I can't try any file transfers on his BBS.
(08-02-2021, 02:30 PM)admin Wrote: Bob hasn't approved my account yet, so I can't try any file transfers on his BBS.

I contacted the SysOp - he's supposed to be working on it.

Hello Jim.

I've installed the WiModem 232 onto the Atari Mega ST4 that runs the DarkForce BBS for testing purposes.

This is running in "raw" mode and DTR set to 2.

It's accepting calls and hanging up without any problems.

I went through the menu and it seems to all be working for that part.

Downloading... the eternal thorn in my side. Smile

Using SyncTerm on a Windows 10 computer I successfully downloaded the TESTFILE in File Sig 3.
I also successfully downloaded a couple of .ZIP files without problems.

Now...with a WiModem 232 hooked to my Atari Mega STe, I called into my BBS with its' WiModem 232.
Connects fine and disconnects fine. Menu choices work fine.

However, it gives the same "CRC error" and "subpacket too long" error on downloads. Further, and I
find this really strange, when the download fails, the WiModem 232 disconnects the call.

I have RTS/CTS (CRC) turned on, on both the BBS computer and the Atari computer I called in with.

I also tried it with it turned off. Didn't seem to make any difference.

I also tried calling in with "ATDT*T0,". That didn't make any difference

Please login to the BBS at your convenience, for testing purposes.

Thanks, much appreciated.
That's good that you are not having any download issues with the BBS and ZIP files now.  That means that issue was resolved.  I did get a UDS-10 but I need to get a power adapter for it and set it up still.

The WiModem232 can't just disconnect by itself.  It has to be told to do this, either by the terminal program you are using (like if you are using AT&D2 with a DTR change or via command mode +++ ATH) or the remote disconnects.

I did try calling several BBS's with and without the *T0, and *T1, and that made no difference with any BBS.  That works correctly.

I will try calling your BBS.

Users browsing this thread: 1 Guest(s)