The goal of this project was to program a flash chip with code to run on my Z80 computer. Due to problems with both the computer and the programmer, I only ran a small (7 bytes) I/O test.
The programmer is based around an ATmega328P microcontroller, which is programmed in assembly. The microcontroller shifts the address into 74164s, and then reads and writes the data in parallel.
In an age where Arduino is the most popular development board/IDE for AVR programming, assembly seems like a very strange choice; in fact, if I redid this project, I would probably use C instead. The reason I used assembly was because it was much faster than C when I tested it. I performed one test, using both Arduino and assembly, which counted from zero to 2^24 - 1 and shifted out the result. I do not remember the exact time it took to run each program, but it was somewhere around 44 minutes for the Arduino version and 4 minutes for the assembly version. The control over timing that assembly provided turned out to be another benefit. The code ran so quickly that it was necessary to insert nops while the flash chip performed a lengthy operation. I now realize that I could have used SPI to control the shift registers, which may have let me use C without worrying about timing.
I only used this device once, mainly because the size of the file would have to be limited to 2 KiB and manually entered into the program. I would like to make a new version in the future that eliminates these problems by streaming the data from the host PC to a buffer that would then be programmed into the flash chip.
Files:
Flash Programmer Schematic (pdf)Flash Programmer EAGLE Schematic (sch)
Flash Programmer Code with Z80 Test Program (asm)
Arduino Count and Shift Test (ino)
2025-05-31
I did redo this project and I did use C this time. The hardware is basically the same. I probably moved a few wires around to allow access to the UART. I didn't need to use SPI, and even in C I added delays. I haven't checked the assembly to see if the delays are actually needed, but the flash chips accept a large range of write timings so it doesn't hurt much if there's a longer delay between writes. This version does stream data from the host PC into a buffer which is then written into the flash chip.
Now for the more unusual features. The programmer is designed to program many types of parallel flash memories. Each part has its own script (written in a variant of duck-lisp) that has all the useful operations the chip can perform. There's functions for chip ID, chip erase, sector erase, byte-write, etc. When the host program is run, it compiles the script for the selected part and sends the bytecode to the programmer. The AVR has a very simple bytecode virtual machine that runs the bytecode. For functions such as chip ID and chip erase, the bytecode is run as soon as it is loaded into the programmer. For the "program" command, the bytecode for the "byte-write" operation is run for each byte that is programmed into the memory. No bytecode is needed for the "dump" command because I'm guessing the vast majority of flash chips are read in the same way and so the read operations are hard coded.
The purpose of this programmer is to program MicroComp's microcode and program memories.