Drumulator clone with STM32 processors.

There are times, when you truly don’t know which direction to take. At first, I partially replicated the Drumulator's functionality in a GoWin FPGA. Later, I attempted the same adventure with an Efinix FPGA. That’s when I ran into the challenge of completing the machine—specifically, implementing the entire Z80 interrupt system in this Efinix FPGA. I didn’t succeed.

During this process, I realized that developing something "new" in an FPGA isn’t very practical. The reason? Well, there’s no real-time debugger like you’d find on any microcontroller. So, I tried using a processor instead and went with a very interesting RISC-V processor. Unfortunately, as I progressed, I realized I wouldn’t be able to fully achieve my goal this way.

Then, I came across STMicroelectronics' announcement of a new member of the STM32H5xx family. Looking at its specs, I noticed it was very similar to the previous RISC-V processor—but with every feature doubled: RAM, flash memory, and operating frequency. I figured it was worth giving this microcontroller a shot.

Then, after a period where I could no longer get STMicroelectronics' STM32Cube IDE to work properly on my Windows machines (dealing with installation crashes, missing packages, and other issues), I decided to try again with this new processor. I installed CubeIDE and CubeMX - miraculously, it worked perfectly on the first attempt.

So I embarked on this new adventure, building on the various tests I had previously conducted with the RISC-V processor regarding waveform generation. However, I decided to approach this as two separate projects: first developing the analog section for sound generation and processing, and then - if successful - completing the control panel.

After numerous iterations, here's what the analog board should look like.

This is a first draft. I haven't attempted to route this circuit yet. I may need to make some adjustments to the placement of certain component blocks. And even assuming the circuit works as intended, I'll still need to verify the audio quality - particularly how it handles (or fails to handle) the various interference patterns generated by the processor.

I'm not done yet.

The positive aspect is that with this circuit and the tests I conducted while designing my MSX cartridge (which uses the same processor), I should be able to implement waveform switching relatively simply. This approach eliminates the need for larger PCBs containing multiple memory circuits.

Well, having worked on multiple units of the original Drumulator circuit during repairs, I have to admit the final PCB is significantly more compact and uses far fewer components. It's nothing like the board in EMU's machine.

Of course, there's still the control panel to develop. But even that only requires a few additional elements compared to EMU's version - just some LED drivers, two keyboard multiplexing circuits, and that's about it...

UPDATE 08/01/2025

My Experience with EasyEDA Pro:

I tried using EasyEDA Pro to design the analog section of the Drumulator. After spending some time with it, I’ve concluded that this development tool is absolutely not for me—it just doesn’t suit my workflow at all. The limitations and its general behavior ended up frustrating me to no end. As a result, I’m going back to good old KiCad to redesign the board, with a few minor tweaks. The overall concept remains the same, but I’m changing how some components are physically laid out. Normally, I believe that fewer different elements in a system mean easier debugging and better reliability, but this time, I’m doing the opposite—adding more components to simplify things. Surprising, right?

Tech Rant: The State of Software & Forced Bloat :

And speaking of annoyances, I’m getting increasingly fed up with how systems and applications behave these days. The way they push—or rather, force—users to accept commercial nuisances is beyond frustrating. I’ve already stopped using Firefox except for certain sites that require specific resources. Otherwise, I never use Bing, and Opera and Firefox are now limited to just a few websites.

Unfortunately, I’m stuck with Android on my phone for now, but these so-called "updates" are just excuses to bombard users with checkboxes, tricking them into installing bloatware. And even then, some apps can’t be refused upfront—you have to uninstall them afterward. Needless to say, I won’t be switching to Apple. It’s the same nonsense, just worse and more expensive! This trend is spreading to more and more software.

My Solution? Linux + Minimalist Setup:

So, my plan is to set up a small Linux machine and keep my Windows PC strictly for development tasks. On Windows, I even use a portable browser instead of installing one. As for my phone, the only reason I’m still on Android is one essential app. The second I find an alternative, I’m switching back to my trusty Siemens B615! 

MSX FLASH cartridge.

I just received a few prototypes of my new FLASH cartridge for MSX computers.

In the past, I created several prototypes based on the copy/paste file principle under Windows.

This approach caused issues with the low-level connectivity of the USB bus, which meant that after developing the very first cartridge prototype equipped with a processor that handled all the operations, I had to switch to using two processors. That's when I created the second iteration of my cartridge.

With this second prototype, I was able to observe in situ all the transfer issues caused by the asynchronous nature of USB transfers. In particular, it's never possible to know whether a transfer was successful or not. Worse, there's no way to determine if a transfer is complete or not, hence the impossibility of controlling anything.

So, I had to change my approach and opted for a more reliable protocol. I decided to use the Ymodem protocol instead, which allows for full control over the sequence of operations. On Windows, I relied on the Hterm tool, as it provides a stable implementation of the Ymodem protocol.

I also chose a new STM32H5xx-type processor, which has more built-in resources than the RISC-V circuits I used before, greatly simplifying the schematic.

The result of this new design is as follows:

Now that I have the new cartridge in front of me—so much simpler than previous iterations—I have to admit I’m wondering whether I’ll actually manage to implement all the planned functions.

I also need to integrate a software reset system I’ve been designing. This last point is critical because it should allow rebooting the MSX computer without touching the ON/OFF switch.

Moreover, since the very beginning of this cartridge’s development, I’ve absolutely refused to rely on a configuration phase—for example, toggling between programming mode and usage mode by selecting an option at the MSX’s startup.

To me, it’s utterly unbearable to have to press a key within an extremely tight timeframe (inevitably shorter than the LCD screen’s video signal detection delay) just to choose a mode. The result? You have no idea what you’re doing. Frankly, this approach is just idiotic!

Now, the only remaining step is to port my earlier tests from the dev board to this final version. After that, I'll need to confirm the hardware implementation works flawlessly.

STM32 processors, in fact...

I mentioned in a previous post that I wasn't about to use the STM32 family of processors again. I had been testing with an STM32H5xx processor, using the STM32CubeIDE development software and its 'friend', STM32CubeMX, since for the first time in a long time, the software suite was working for me.

It's true that the new STM32H5xx processor family is interesting for several reasons. On the one hand, these processors are fast, they can operate at up to 250 MHz and, above all, some models offer 512 KB of flash memory and more than 272 KB of SRAM memory.

I then thought that this could allow me to develop a new version of the MSX cartridge that could be loaded via the USB port.

In my previous cartridge version, I used the principle of external mass storage. To simplify, the MSX cartridge behaves like a USB flash drive. Subsequently, the file recovered on a FAT12 file system type media, was recovered and copied in RAW format to the cartridge second processor.

This is what the cartridge looked like:

In fact the right processor retrieved the file through the USB port connected directly to a PC. Then sent the retrieved file directly in RAW format to the second processor which 'provided' the data directly to the MSX computer.

This system wasn't easy to develop for a number of reasons. Most importantly, file transfer from a PC is unreliable. Not because the data could be corrupted, but simply because it's completely impossible to know if the entire file has been transferred!

And that's not practical at all!!!

Additionally, the processors used were a bit more modest in terms of Flash and SRAM resources.

So, I wondered if it would not be relevant to try the adventure again on one of these STM32H5xx processors.

However, I had two 'problems' to resolve. The first is that I no longer have to use file transfer in the file system sense, but rather a transfer in the sense of direct byte transmission. So I chose to use a serial file transfer using the YMODEM transfer protocol.

The Ymodem protocol allows you to receive the name and size of the file, which can be interesting, but above all the transfer is done in specific blocks with possible CRC correction, which suits me very well.

The second problem for me is not having to use what seems to be something downright overly complicated on the system provided by STmicro (see my previous post) : the USB function of the STM32 processor. So, I decided to go straight for a small external USB/serial converter circuit.

This last point will also allow me to set up good galvanic isolation between the PC and the MSX computer.

In short, this change of direction should allow me to make the operation of my MSX cartridge more reliable. Because although I have never had any operational problems with my own MSX computer, it has happened that it did not work correctly on other MSX, without me being able to determine the reason for these malfunctions.

Here is what the first prototype of this new study looks like, based not on a RISC-V processor but on an ARM processor from the STM32H5xx family :

To summarize, this new version offers a faster processor, a more secure and controllable file transfer system, and better galvanic isolation.

I have already carried out some preliminary tests on a study board, namely transmission with Ymodem and programming of the internal flash of the processor.

Additionally, I should be able to install a more convenient status indicator system than the two original LEDs.

This new cartridge should also allow me to automatically reboot the MSX computer without using an external system. It should also be able to integrate different mappers for a total of 256KB of memory. Finally, my system should also be able to be updated using the same file transfer mechanism. I have already successfully performed code relocation tests on this new processor.

Transfer times should remain fairly short, given that I chose a speed of around 230Kbauds, which did not cause me any transfer problems during my tests. A full cartridge should therefore be able to be transferred in around ten seconds, plus the writing time in FLASH, which will also remain very low.

And so, I now think of using this processor in my study on the construction of the Drumulator type drum machine...

A few days later...

The request for a prototype PCB has been made. I'll then be able to work directly on a properly assembled circuit. This will already save me a lot of unpleasant surprises, especially those caused by assembling the processor by hand...