Bak to the Drumulator.

It has been a while since I last posted about the Drumulator. On the one hand, I'm working on other projects in parallel. A project that seemed fairly simple at first glance—namely, implementing the Drumulator on an FPGA—wasn't quite as simple as it seemed. And worse still, as I made progress on the subject, I realized it was becoming increasingly difficult, to the point of reaching a breaking point: a total state of blockage due to my lack of expertise in FPGA programming.

I remained in this state for a very long time, which could be estimated at several years—in fact, far too many years, since I must have been stuck for about five years. Until the end of 2025, when, thanks to the contribution of AI used as a teacher, I was able to unlock my understanding of VHDL and thus make great progress.

The side effect of this new approach to FPGA programming is that I spent the first half of this year working on finalizing the digital part of the Drumulator, and as a result, I also resumed development of the MSX cartridge that I had attempted several times to build using fast microcontrollers, but with unreliable operation.

I also undertook training in 4-layer PCBs, because double-sided boards don't allow proper use of the range of FPGAs I'm currently using, the Efinix Trion FPGAs. And to complete my training on the subject, I decided to make a 4-layer PCB using a BGA-format FPGA. I've actually received the PCB. All that's left is to embark on the adventure of hand-assembling this board.

All of this is to say that I've been quite busy during this first half of 2026.

Since the start of the 'school year', I've therefore studied (again) the analog part of the Drumulator.

Thanks to my new 'skills' in FPGA development, I was able to consider a different way of operating this analog part. Also taking into account the final cost of the board, its ease of integration not only for the Drumulator but also possibly for another machine of this type, the simplicity of assembly, the quality of the audio processing, and finally the possibility of operating with a simple 5V power supply such as a USB charger, well, I ended up with something that has nothing to do with the original Drumulator circuit, while scrupulously respecting its spirit.

I no longer use multiplexing at the output of the audio converter. Each output now has its own converter. I also no longer use per-channel volume control via an external digital-to-analog converter. The volume will be calculated directly in the digital domain by the FPGA. Furthermore, I'm using 12-bit linear audio converters, rather than 8-bit companded ones as in the original. A simple conversion table directly converts the signal, and does so very simply since 8 bits only gives 256 values to process. Finally, the output capacitors on the audio path have been removed thanks to the 0V centering servo.

Moreover, all the filters present at the output have been kept strictly identical, in order to provide the exact audio feeling of the original Drumulator. This produces a circuit with a lot of components, but one that should be fairly easy to route. For information, here is the 3D rendering of both sides of the board before placement and routing.

 

We're still going to have to be patient to make the best possible circuit...

Various early-year updates. MSX cartridge & Drumulator.

Currently, I am working on two major projects. 

On one hand, there's the development of an MSX cartridge based on an FPGA. After several attempts to create this type of cartridge using different processors, I decided to switch to an FPGA. The task is quite complex as it involves being able to download an executable cartridge file from a PC, program the FLASH memory, and then make it accessible to the MSX once the programming is complete. I have, of course, already built a functional prototype using an Efinix FPGA. The results are very promising. So now I'm moving on to the hardware production of the cartridge. I have made FPGA boards before, but they were based on GoWin FPGAs. This is my first attempt with an Efinix Trion FPGA.

For now, I have just finished placing the components. This may not be the final version. I haven't routed the traces yet, so if I can't arrange the tracks properly, I may need to reposition some components. Basically, here's what it might look like:

The advantage of this version over the older processor-based ones is that now I will also be able to implement different types of mappers, and there is a good amount of RAM available. In fact, if there is space left after routing, I will consider implementing a battery backup for the RAM. This could enable the development of specific applications. And most importantly, I hope that this time, given the chosen technique, the cartridge will work on more than just my MSX motherboard!

And the second topic is still my attempt to implement a Z80 CTC timer within these Trion FPGAs. The goal remains to successfully boot the processor core of the Drumulator in this FPGA. I implemented this part of the Drumulator in FPGAs a few years ago, but by simulating the CTC's operation—that is, by providing only the necessary IRQ vector for the display, without implementing the entire 'handshake' system during the Z80's interrupt handling phase.

A month ago, I decided to 'give it another shot' by asking an AI for an initial implementation. I got a project that, predictably, didn't work at all, but it greatly inspired my current code. After several days of trying to correctly implement the Z80's interrupt acknowledge sequence and the actual IRQ routine return, I finally have regular interrupt generation. For those who know, I now successfully have the passing of the interrupt vector, its handling by the Z80, and thus the clearing of the interrupt 'pending' status. At the end of the IRQ phase, the CTC correctly decodes the RETI, allowing new interrupts to occur.

All of that is perfect, but... well, the display of the emulated Drumulator still doesn't work.

That's where I am at the moment: trying to understand why the Drumulator isn't starting. I should eventually figure it out, especially since it worked flawlessly a few years ago with a pseudo-CTC.