Tech Flashback: Flashing a Dial-Up Modem using Flashcom

After some dial-up modem adventures as of late, I realized my Netcomm Roadster II 56k Ultra SVD wasn’t quite as up to date as it could be. It had Firmware V1.53 on it, and the latest version was likely to be V1.57 as that was what my second Netcomm Roadster II 56k Ultra SVD was running. I had an itch to upgrade the firmware, even if it didn’t present me any immediate tangible benefits, because it just seemed like the right thing to do to get the most out of my hardware.

Step 1: Sourcing the Upgrade

The first, and arguably biggest, issue was that Netcomm had long stopped supporting the dial-up modems and their site literally has no more downloads nor drivers for them.

Luckily, we still have the Internet Archive, and while they didn’t make a perfect archive, I was lucky that the file I was after was in the archive after all. The modem model number is AM5690 specifically, so instead of trying to browse the archive, I decided to use a trick.

If you want to browse all the files ever archived for a particular site, it’s as easy as appending /* to the end of the archive link.

Note: If you try to access the link, you will likely hang your browser for a long while and get script time-out pop-ups due to the way it is coded. Just be patient and let the script continue to completion. If you don’t want to crash your browser, please don’t click the latter link.

e.g.*/ takes you to the main page listing all of the times Netcomm’s site was archived, but*/* takes you to a list of all the files ever archived from the site.

From there, when I punched in AM5690 under filter, I found what I was after in the form of am56906.exe. Bingo! I downloaded it and installed it …

Step 2: Installing and Failing at the Upgrade

As any retro-technologist will know, failure is normal especially when you’re not replicating the contemporary hardware and software. In this case, I was able to install the tool, but as soon as I tried to open the flashing software (Flashcom), I was greeted with:


Bugger it! It’s a 16-bit or 16/32-bit hybrid program of some sort. Can’t run that on Windows 7 x64.

Step 3: Working Around the Problem


I decided to harvest the provided files so I didn’t have to reinstall it, as ultimately, the files are the most important part. I grabbed my Windows 2000 Professional virtual machine, and decided to try there.

flashcom-aboutIt was indeed possible to run Flashcom. A few lessons were learnt along the way:

  • Serial port pass-through on VMs is iffy and will cause problems either at the VM hypervisor level (can’t get access to ports) or with timing. Avoid it at all costs.
  • USB to Serial converters aren’t all built the same. If you have some problems, it’s likely because you have either a chipset which isn’t good, or you have a cheap cable that doesn’t actually output RS-232 levels (e.g. WinChipHead CH340 bargain bin cables often do this). Stick with FTDI and Prolific with a MAX232 or equivalent output stage if possible.
  • Use USB pass-through to the VM as this works best, provided drivers are available for the guest OS.

I documented the flashing process completely in this video:

You might have actually done this in the past as you may have had an older modem with pre-V.90 firmware for K56flex or an ACF modem which could only have either K56flex or V.90 firmware loaded (1Mbit version), so I suppose it’s rather interesting to be “reliving” this in 2016.

Another way could be to source a more modern firmware upgrader (e.g. Flashcom32) from another modem vendor and modify their FLASHCOM.INI to flash the files supplied with this modem. Sadly, I didn’t have any other modem vendors that came to mind at the time.


FLASHCOM.INI is pretty simple in structure and basically lists the firmware files, validation checks to make sure the modem is eligible for upgrade and post-flash commands to be executed on the modem. The post-flash commands is a reset to factory defaults (&F) and write to storage profiles 0 and 1 (&W, &W1). Then it sets the transmit attenuation for data and fax to -10dB (S91=10, S92=10) as required for Australian operation.

Firmware Load Process

As it turns out, FLASHCOM isn’t actually necessary when flashing the modem. All of this could have been achieved with a regular terminal emulator and a few AT commands. If you refer to the Rockwell AT Command Reference Manual, downloads are initiated using the AT** command.

From there, either an unloader or loader module is sent in ASCII mode. This is a small piece of code sent to run in RAM to help read-out the flash to back-up the firmware, or to accept an XMODEM download of firmware and burn it to the flash. These routines are not integrated to the modem chipset itself, and if a problem occurs during flashing, users are advised to retry without interfering with the modem as the loader/unloader module is still in the RAM of the modem. If power is lost during flashing, a bricked modem is highly probable as the loader/unloader in RAM will be lost and the AT** download command is a firmware command that is incapable of programming a blank or corrupted flash chip.

As a side benefit to having the latest firmware on the modem is the fact that I have refreshed the data in the flash memory entirely thus charging the cells up to their appropriate levels. Data retention in flash is quite variable and can range from 10-100 years depending on its design and storage conditions, but it relies on trapping charges which are prone to slow leakage over time. Once the charge leaks to the point that a bit is changed, the firmware will be damaged and most likely, the device will exhibit erratic or no operation at all. I’ve lost a few older devices to what I believe to be flash memory corruption, so being able to reflash and rewrite the firmware is a big positive in keeping things running.

Firmware Structure

Looking back on this also gave me an opportunity to examine the firmware files themselves. The firmware is provided in an .s37 file which looks like the following:


The .s37 format is known as S-records or SREC format, and is basically a representation of sequences of records with addresses, data, and checksum in a printable hex format. This format has an advantage that it would not be corrupted upon transferring as plain text on 7-bit ASCII machines, and it’s relatively compact compared to having just ASCII 1’s and 0’s. It’s also highly relevant to embedded systems where there may be a vast number of flash addresses, but only certain modules or pages/regions need to be programmed.

Luckily, some tools have been developed to handle this – so I grabbed SRecord 1.64 and used srec_cat to convert the .s37 files into binary images:

./srec_cat am56906D.S37 -multiple -Output fw.bin -Formatted_Binary

Of note was that the .s37 files themselves had some multiple definition of addresses, which indicates that maybe there is a particular sequence of writes involved aside from just updating the firmware that “finishes” the loading process.

The resulting files were 259,422 and 259,719 bytes (253kiB) which isn’t the 256kiB you would expect for a 2Mbit flash, but, it seems likely that this is because the .s37 file can’t be bothered programming addresses at the end of the flash chip which aren’t used and just leaves them in their default state. Otherwise, those positions may be left for uses like storing the speed-dial entries and S-register settings for profile 0 and 1, which means that the firmware takes care of it, and overwriting it is unwise as it loses the user’s configuration at every upgrade.

I’m not familiar with the type of CPU used, and I’m not any good at code disassembly either, so I trawled for some text strings to see what I could find.

hex-view-1 hex-view-2 hex-view-3

I found some references to RAM code, which appears to be a table of modules of some sort.


We have all the statistic return strings, as well as the connect strings and rates here. It’s actually repeated a few times in the firmware.


There seems to be a listing of AT# voice commands here too – VTX for transmit voice, VLS for selecting the line, VRA for ringback timer, etc.


The modem ID string is found as well.

hex-view-8 hex-view-9

Various different connect result strings are shown including references to V.70 (DSVD) which isn’t available on this modem and SREJ (selective reject).


There seems to be also some generic code for the RPI Rockwell “offload” modems which offload error correction and compression to the host CPU. As this is an external modem, this is not a feature of this modem, but it suggests the firmware base may be kept common between hardware modems and RPI modems.


There are more ID strings, some customized, and Fax Class 2 command response codes (AT+F), along with responses to voice, and modulation select commands.


It’s 2016, and I’ve managed to flash the firmware of an external modem and upgrade it to the latest edition. It took some work, but at least I was able to do it through FLASHCOM in a semi-authentic way. Of course, having done that, I also realize that it’s possible to do it by other means – e.g. via a terminal emulator, or by pinching a newer version of FLASHCOM and modifying the INI file to reflect the right .s37 loader/unloader/firmware combination. Inspecting the firmware seems to show that srec_cat is capable of building a binary image of the firmware – whether this can be burnt onto a flash chip to resurrect a dead modem with corrupted flash is yet to be tested.

About lui_gough

I'm a bit of a nut for electronics, computing, photography, radio, satellite and other technical hobbies. Click for more about me!
This entry was posted in Computing, Telecommunications and tagged , , . Bookmark the permalink.

Error: Comment is Missing!