Drumulator OS : done!

And yes, the Drumulator system is finally working in the Trion FPGA. Actually, I managed to get the Drumulator system running in an FPGA—Altera at the time—a few years ago already, but by simulating only one interrupt on CTC channel 1, the channel responsible for scanning the display and keyboard.

I knew from then on that to properly implement this drum machine's system, I had to fully and correctly implement the Zilog CTC in the FPGA. Meaning with the entire IRQ recognition system, interrupt vector delivery, and IRQ enable management.

In the meantime, I turned my attention to other, easier subjects. And then, after experimenting with GoWin FPGAs, I decided to switch to Efinix circuits—simply because they are much cheaper than GoWin ones. 

And I have to say, the philosophy behind Efinix's development system actually suits me well. For example, I had never implemented a fast 'proprietary processor' in an FPGA before. I was able to implement Efinix's Saphir processor without much difficulty. The only small point that gave me some trouble was implementing the JTAG interface for this soft processor. Afterwards, I tried using the debugging tools in the Efinix software without success. Once again, I was referring to other FPGA manufacturers and looking for a similar approach. Then one day, without really overthinking it, I simply set up a debug session and launched the built-in logic analyzer. These tools are very simple to use and effective.

After that, I wondered which tool to use to visualize the captured signals. GTKWave—and it's perfect:

I was able to test the CTC's operation using the internal Saphir processor I had implemented, by sending configuration data and observing the CTC's behavior. I was aware that I couldn't test everything—especially the Z80 system's interrupt recognition and acknowledge mechanism. That's where the internal logic analyzer proved to be extremely helpful. It allowed me to verify signal timing, which is essential in a system that uses multiple interrupts coming from the same source.

Still, the system behavior remained completely erratic. But I knew that an uninitialized data RAM could cause the system to go haywire.

So I pre-initialized the data RAM to 0xFF, and this time the system seemed stable. In order to properly format the loading data—whether for ROM or RAM—I wrote a small utility to easily process the required files:

Since I hate wasting time with Microsoft tools that don't address standard needs at all, require years of learning, and stray far from real-world issues, I simply asked the AI to generate the skeleton. I got it in about 30 minutes—just enough time to clarify a few points and let the AI algorithm adapt. And there it is!

At that point, all I had left to do was connect the keyboard and test the Drumulator's initialization sequence: ERASE / CASSETTE / ENTER.

And voilà — the data RAM properly initialized, and a Drumulator running flawlessly.

I still need to implement the data potentiometer control system, since it also uses the CTC. And knowing that I've already implemented the drum machine's waveform sequencer, I can now say I have all the fundamental building blocks to rebuild a Drumulator — and hopefully improve it in one way or another.

At startup, the unit should display 01E, as shown in this image taken from the web:

And here is the result on the control panel I created for testing:

The photo isn't great, but hey, the main thing is there ;-)

I tested a few possible actions using the user manual. The display behaves exactly as described in the manual. So I now consider the implementation of the Drumulator core in FPGA to be validated.

And if I sum up the work done over the past two or three months:

• Development of a minimal VGA interface prototype.
• Development of the MSX cartridge prototype (PCB prototype in progress).
• Porting of the Drumulator core to FPGA.

All of this on Efinix Trion FPGAs — I'm quite pleased with myself!