MX29F1615 Programmer

This page describes the MX29F1615 programmer and associated software which were designed and built by Chris Hooper.


I own several Commodore Amiga computers from the 80's and 90's. These computers were originally designed with ROM chips to hold the majority of the operating system so that they could start up quickly and not consume precious RAM for system software. Commodore used a 40 pin (and later 42 pin) ROM chip that had a pinout which was luckily not obscure at the time. There were EPROMs, such as the 27C400 or 27C800, which match the pinout of the 512K and 1MB ROM chips. These work great even today, but require 20 minutes or so of soak time in a UV eraser before they can be reused.

While searching for a modern alternative, I came across the excellent GGLABS F2R16 flash ROM replacement for the Amiga. With an adapter, this part could be programmed in the same programmer (TL866II+ in my case) which could program the 27C400 series EEPROMs. This worked great, but the individual parts at about $40 each were more expensive than I had hoped, doubly so because some of my Amigas (A3000) require two ROMs.

In one of the Amiga forums, I found mention of the MX29F1615 EEPROM. They were a very reasonable price on eBay, so I ordered a few. After trying for several days to program these with the TL866II+, and having very little success, I decided to develop my own programmer. How hard can it be, right? (sarcasm) As of 2023, they are still a very reasonable price on eBay.


The current version of the board is Rev 6. This board fixes a couple minor usses in the Rev 5, slightly reduces the size of the board for better fit, and adds a couple new GPIOs for new features. Please see the Hardware History page for information on all board versions.


All source code will be made available in github, but is not checked in yet. Anything I write for this project will be open source and free to use for any purpose.

Getting source code


Loading firmware on the programmer

Verifying function

Using the software

Debugging software

Software Development History

I started implementing firmware on the STM32F4-Discovery board before Rev 1 of my board arrived. I decided to try the STM32CubeMX software to generate the initial environment in order to reduce initial development time. In the IDE, I selected the STM32F4-Discovery board which chose the appropriate ST-Micro CPU and GPIO configuration appropriate for the board. The IDE was configured to generate a Makefile so that I could use gcc-arm-none-eabi. To write the STM32 flash using the onboard ST-Link, I used st-flash from texane st-utils. You can get a copy of this repository to build the tools with But it's not necessary to do this manually because the Makefile will acquire and build ST-Utils when using the make flash command.

The command line handling and some command code was integrated from a memory display/edit utility that I previously wrote.

From the start, I wanted to make this project completely open source. After getting barely functional programmer firmware up and running, I started looking into what it would take to make it open source. Based on my understanding of the ST-Micro License agreement, I openly share source of the ST-Micro HAL library. For that reason, I decided to port my firmware to use libopencm3 instead.

THe MX29F1615 programmer source assigns the libopencm3 git repository as a submodule. You can use the git submodule command to pull in code from this library:
    $ git submodule init
    $ git submodule update
I may choose to make this automatically done by the Makefile in the future.

As of January 6, 2021, the source code supports the STM32F407, STM32F103, and STM32F107 processors. It supports these three processors with either the STMCubeMX-generated HAL library as well as the open source libopencm3 library. The main Makefile supports libopencm3 and boards are selected by setting the BOARD_REV macro in the Makefile. To use STMCubeMX, you will find the individual *.ioc in the top directory. They provide the configuration used by STMCubeMX to generate the appropriate HAL sourtce. With only minor modifications to the HAL source, the firmware will run under each of the three CPUs. I am still working out how to minimize the number of modifications required for the HAL library source.