JimDrew

New version of firmware has been released! --------------------------------------------------------------------------------------------- v2.60 - 02/03/18 Added buffer limit (*BL) value to AT&V output. Changed buffer code to allow space characters in the BUSY message. Added support for a/, which repeats the last AT command. Fixed issue with phone book entries not storing (AT&Zx=). Created new command ATI3 to show the connection time information. Changed +++ parser to match the Hayes specification, fixing problems with uploads with +++. Fixed input parser when no characters are in the buffer.

Yep... I was going through the code and cleaning it up and I killed a line of code at some point. I have also fixed the +++ parser. That was broken in a funny way where if your uploaded file had 3 or more + characters in a row it would put the WiModem232 into command mode! I am testing the new features as well and I will release this shortly.

Press RETURN a couple of times and try typing on a blank line. AT commands can do this right after you change baud rates. I need to figure out a way to flush the serial buffer after a baud rate change.

Thanks for the reports! I am pretty confident that I have solved the transfer issues by going with a fully asynchronous system. I am uploading at 115200 baud with my Amiga to Hyperterm on a PC. I just got a PCI-e serial card that is capable of 1mbps serial, so I am going to see where the limit really is.

I can't change anything to do with sensitivity with the firmware. That's a hardware thing. You might have had higher than normal 2.4GHz traffic, or a microwave oven turned on - yes really! Jim

New firmware for the WiModem232 is out. This version has a complete re-write of the ESP8266's cilent and server handlers to make them asynchronous. This solved (at least for me) all problems with sending data at high baud rates.

What CR/Enter problem are you having?

Have you tried turning telnet mode back on and using AT*T1 to see if it works with Heatwave? It could I guess since the news site and a couple of others seem to work ok now that I changed the telnet escaping. However, I will say that 99.99% of BBS's out there do not use telnet escaping because it cuts the through-put because of all of the escaping required with binary file transfers.

I think the biggest issue people are having is with older/slower computers that require hardware flow control to be enabled (AT&K1).

Type AT*N and look at the signal strength. If your router has a signal strength of at least -85db (lower the number the better) you can connect to the router via WPS or manually.

Yes, there are several people using the WiModem (not the WiModem232) for running a BBS. These people are using BBS software that looks at the DCD line to determine if the modem is connected. There is no DTR on a C64, so you have to use "+++" and ATH to hang up the modem with the C64. This is also used for the Amiga BBS's. With the WiModem232 you can have either RTS or DTR, or CTS or DSR. There is no way to have RTS/CTS and DTR (or DSR) at the same time. I didn't think this was necessary based on the C64, Amiga, and PC. If this is the case, I could change the hardware but we would lose the LED or the display because there are no extra pins on the CPU. I am almost out of WiMmodem232 boards so I can look at this.

I am surprised that AT*T1 works, however, I did make a change recently to the telnet escaping so maybe I fixed the issue we were having with Heatwave when telnet escaping was enabled. There is AT&Dx supported so it doesn't generate a ERROR response, but this does nothing. You would have to disable RTS/CTS in order to use DTS/DSR. They are mutually exclusive, but dropping DTR will not hang up the modem. I can look into supporting this, but no systems so far require this. What exact computer are you using?

There is a list of systems that have been confirmed tested on my website. Just like a real dial-up modem (which is what the WiModem232 emulates), a cable may be required. http://www.cbmstuff.com/forum/showthread.php?tid=419 As long as the computer follows the RS-232 spec (at least +/-12v signal level) it will work with the WiModem232.

Some clarification on flow control.... the WiModem232 is shipped with RTS/CTS handshaking configured and DTS/DSR tied together. This is the most common method used by all computers. When DTR is brought high by the computer, it also is brought high on the DSR side and the computer knows the modem is attached and ready for use. There is one thing that many people forget about, and that is actually turning on the hardware flow control. You enabled it with AT&K1. If you have it set to AT&K0 then it won't matter if you have RTS/CTS jumpered on the board as no flow control will be used. So, remember to enable hardware flow control if you need it.

I will look at adding some info to the display. I am thinking about making multiple pages that alternate or something like that. I really didn't know what to put on the display, and after 2 years it seems that (at least with the C64 crowd) nobody actually looks at the display. I just released a new firmware that correct a hardware flow control issue. After all of these little changes for other systems, I broke the C64 mode for 38400 baud (with inverted polarities), so I am looking into that.

ACK! You are correct! I meant Xon/Xoff flow control. Sheesh... too much cold medicine today!

ALL versions are now back in stock! I have made a lot of changes recently because the WiModem232 works with numerous different computers, and each have a few quirks that I had to address. I have been shipping this same product for the C64 for nearly 2 years, so I didn't expect many changes would be needed, but that was not the case. So, as people report little issues, I am addressing them and making updates available. Updates are super easy for me - I just push the update and it automatically tells the WiModem232 to display that an update is available via the OLED and also when issuing the ATI command.

Because the manual changes frequently, please provide a link to the manual on my website instead of attaching the manual directly. The manual you have posted is really old, and missing a lot of data. Thanks! Xmodem protocol is not currently supported. So, you can not use it as a flow control method (yet). It's something that I am working on adding.

Thanks for sharing! I just released a firmware update that corrects a race condition that has existed since the first WiModem for the C64 was released. Update your firmware using AT*UPDATE

If DTR and/or DSR is connected you might have to remove the DTR/DSR bridge that is on the WiModem232. That is the default jumper setting, which is needed for most Amiga terminal programs.

We have a winner... I think! I logged on and was able to use Xmodem-CRC to download the COPY-C file in the utilities menu! I tried using Xmodem-1K and got some sync errors immediately. I re-started the transfer and it started transferring and then part way through the transfer, the connection hung up! I called back and was able to download the TELCOARC file using Xmodem-1K (649 blocks in size - so, it's big). Now, here is the funny thing. I accidentally selected Ymodem-1K protocol with the Amiga terminal program and the download worked! I then downloaded it again using Xmodem-1K and that also worked. So, turning off escaping definitely works perfect. Downloaded a bunch of files, including the test files in the Telnet directory. Those files came out correct.

I am using Amiga and C64/128 systems for testing. I will try Heatwave right now if you have disabled the escaping!

I added the outbound escaping and I can now transfer files successfully between computers with escaping enabled on both. However, I still can't download files from Heatwave with our without the escaping enabled. :-\

There is no escaping done ever.. It's just raw data packets. I have been selling the WiModem for the C64 for nearly 2 years and the first I had ever heard about Telnet was about 2 months ago when someone was trying to contact tty.sdf.org:23 and the terminal software just sat there and then hung up. It turns out tty.sdf.org sends a request for the terminal type. Once I supported it, you can log in no problem. Edit: so I have looked into the Telnet a bit more and it seems that ONLY port 23 is suppose to be handled as a Telnet type connection. That makes sense because the only portals I have seen all have port 23 as their port. Everything else has no Telnet escaping at all.

IPF format is documented by several sources. Keir Fraser has his Disk Utils that supports it. You can use the SuperCard Pro hardware with Keir's utility to dump disks to various formats, including IPF. https://github.com/keirf/Disk-Utilities