CBMSTUFF FORUM - Firmware

WiModem232 Pro BETA

Wed, 24 Dec 2025 03:37:22 -0500

I have released a BETA version of the firmware for the WiModem232 Pro (only). This update has the entire TCP/IP handler re-written with multiple buffers and interrupt driven. This seems to resolve all of the Z-modem transfer issues I have seen.

In your terminal, type:

AT*BETA (press RETURN afterwards)

This will update the firmware to the latest BETA version.

To go back tot e original version, type:

AT*UPDATE (press RETURN afterwards)

Please leave feedback if you try this new version! Thanks!

Add parity to the baud-rate display

Sat, 30 Mar 2024 14:59:24 -0400

I have a Siemens terminal that insists on being 8O2 and it'd be handy to have the WiModem display parity info along with the bitrate.

BTW, it'd also be nice if it could support mark and space in addition to none, odd, and even.

I am using it to figure out the config of that terminal that I can't persuade to enter the setup screen (and, thus, I needed to figure out the settings it's stuck with).

Can it be done on the next update?

Note about v1.20 WiModem232 Pro update

Wed, 20 Mar 2024 07:00:27 -0400

I changed the way the SSID and password are stored, setting aside flash memory space to store the information instead of letting the system libraries handle it. When using the CABLE (NULL modem mode), the system stored SSID and password were being deleted by the direct connect WiFi configuration. This meant that going back to normal use required re-entering your SSID and password again (every time). So, this change prevents that from being necessary. However, anyone who updates to v1.20 (and later) from v1.10 and earlier is going to have to re-enter your SSID and password.

V6.0 FIRMWARE RELEASED!

Sun, 05 Mar 2023 20:55:03 -0500

I just released a major firmware update for the WiModem family! The new version fixes a few small issues and adds some needed features! See the firmware history for a full list of changes.

The issue with Mystic BBS using cursor keys has been resolved. When you press certain keys on a modern keyboard, it generates an ESCape code followed by a 2 byte function code. The WiModem sees the first character and sends it over the air to the router, followed by the remaining characters as individual transmissions. Router and over-air communications are very slow due to the latency. The Mystic BBS software is expecting the ESCape code and the function codes to arrive within a few characters times (microseconds) from each other, which is simply not possible in a WiFi environment when sent individually. There are two new options that can be tweaked in the future to resolve any potential issues related to the WiModems being too fast for their own good! This was the issue with the Mystic BBS software.

There is now an option to have the OLED screen power itself off after so many minutes. These displays really do not have screen burn-in issues, but some people like to have the display dark when not in use.

The packet handling code has been re-written yet again, yielding more performance for uploads/downloads.

The big new feature for the v6.0 firmware is NULL MODEM cable emulation! You can now use two WiModem or WiModem232 units together to emulate a NULL MODEM cable! This means that you can use a WiModem232 with a desktop computer via a standard COM port and send data to a RS232 device (like a printer or plotter) that has the other WiModem232 plugged into it! No more cable required! You can also connect two computers together to do super fast file transfers - typically 20% faster than just "dialing" from one computer to the other. NOTE: When you use the NULL MODEM mode and you return to normal modem operation, the previous router setting will be gone... so you will have to re-establish a connection to your router.

Next Firmware

Sun, 05 Mar 2023 10:22:22 -0500

Hello,

Is there an estimate as to when the next firmware will be released? Thanks!

V5.0 released - MAJOR UPDATE!

Mon, 07 Nov 2022 18:11:49 -0500

I finally managed to track down the issues that prevented the latest Espressif core to be used with the WiFi module.

I also discovered a data type that was being set wrong which would wrap around a byte inside of a word pointer. This means that any transfer block that exceeded 256 bytes would end up having the wrong data after the 256th byte. I guess this does not happen very often - it's on the DCE (computer) side, not the internet side. The baud rate throttles the buffering, and if the baud rate is fast enough with enough contiguous data (no pauses between bytes) this problem can occur (the modem could actually crash from this).

I added the ability to use your mobile phone to setup the WiModem232 router connection! This is super handy and gives you the ability to enter characters for the router and/or password that is not available on the C64 keyboard.

Lots of other little, yet worthwhile features were added. Check out the history for more details!

Stall during firmware upgrade?

Thu, 17 Feb 2022 17:02:12 -0500

Finally got to dust off the WiModem and try hooking it up to my Model 100 and it worked great, until I saw the new firmware notification and went ahead and did an AT*UPDATE.

Now the update has been stalled for over half-an-hour, with the bar stopping at about 3/4 full before spitting out some gibberish to the terminal.

I'm a little concerned I may have bricked it, and I'm not really sure what to do from here. Is it safe to unplug it and force a reboot?

Source code?

Tue, 17 Aug 2021 23:24:04 -0400

Is the source code to the WiModem232 firmware available anywhere?

Suggestion for next firmware

Wed, 11 Aug 2021 23:42:48 -0400

Suggestion for the next firmware version:

I've found that if a wireless network has a really long name it will overlap the baud rate value. My idea is to either truncate the end (or middle) of the wireless network name if it's long enough that it will overlap the baud rate to make sure the baud rate is readable.

Does that sound like a good and/or feasible idea?

Firmware update 3.30 problems

Mon, 01 Feb 2021 18:11:25 -0500

Hi, my wimodem was working fine and then this morning I updated the firmware to 3.30 now I can't connect to it
anymore. When I enter ATI or any command the characters entered are all wrong, a shows as a q and all other characters
are wrong. When I power up my wimodem it says it is looking for a router then it shows that it has found my router and everything
looks good I just can't talk to it, is there a way to reset it to the previous firmware? Has anyone else experienced this issue?

v3.20 changes

Thu, 26 Nov 2020 16:06:57 -0500

Starting with v3.20 firmware you can now change the number data bits, the parity, and number of stop bits. In the past, this has always been the standard of 8 data bits, no parity, and 1 stop bit (8N1).

You can now change any of those when setting the baud rate. To make the change, add the new config after the baud rate. Example:

AT*B300,8E1

This would set the baud rate to 300 baud and set the number of data bits to 8, the parity to EVEN, and the number of stop bits to 1. The following 12 options are available:

8N1
8E1
8O1
8N2
8E2
8O2
7N1
7E1
7O1
7N2
7E2
7O2

ATI now shows the baud rate along with the current data bits, parity, and stop bits.

New Baud Rate?

Wed, 25 Nov 2020 03:39:57 -0500

Is there a way to support 110 baud so I can use the WiModem with an ASR33 teletype (it would need two stop bits).

Suggestion to aid Videotex users.

Tue, 22 Jan 2019 11:56:15 -0500

Hi

I have been using the WiModem232 with OLED to access the UK'sTELSTAR videotext system and it works very well. However, one thing that would help enormously when setting up a call to a system such as this, is to interpret the character 0x5F as a CR when in command mode.

Videotext systems do not use as a line terminator but use 0x5F (#) instead. This means that it is often not possible to establish a call using something like ATDS=2 when using a viewdata terminal. This means that a call has to be established using a traditional terminal before connecting/reloading the viewdata terminal. Interpreting a 0x5F as a when in command mode would solve this.

If you wanted to go a stage further, what about an AT setting that configures the modem to auto-connect to the first stored number when first turned on.

Just a suggestion for your consideration. Great work on the device.

Details of TELSTAR are at https://glasstty.com/wiki/index.php/The_...tex_System

v2.70 - 02/07/18 Firmware Update

Fri, 09 Feb 2018 02:27:16 -0500

Tonight I powercycled my WiModem232 and saw there was a firmware update. After applying that update, my modem stopped sending any data to my terminal's screen. (Typed commands didn't echo, the answers to those commands didn't print out, and when connected to a BBS, the data being sent by the BBS did not appear on the screen)

I found that to resolve this issue (on my Apple //e with a Super Serial Card) that I needed to configure my modem to &C0 and *D1. Once I did that, I was again able to see output from the modem on my screen. I saved those settings and haven't had any issues since then. (Previous to this firmware update, I had to use &C0 and *D0)

I assume this difference has to do with the following changes:

Changed default DCD polarity to be LOW for WiModem232.
Fixed AT&C1 and AT*D to output the correct DCD state while in COMMAND.

I am truly mystified as to why my computer doesn't want to play nice with the modem when it's set to actually track DCD via &C1.

New Update

Thu, 18 Jan 2018 17:19:42 -0500

My WiModem232 showed a new update was waiting last night, but I forgot to do the update. What does this firmware change do if I may ask?

Thanks.

Beery