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!

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.

Develop with AI.

A few months ago, I tried to code a ZILOG CTC in VHDL. Indeed, I have a long-term project to implement the Drumulator rhythm box from EMU into an FPGA. Why, you might ask? Well, I really appreciate this machine for its simplicity. Plus, I consider it a good project for this kind of development. I've been coding the core of the machine for a few years. That's not really difficult since it just involves using the code of the Z80 processor called T80, which is directly available as open source. A few lines of combinatorial logic in the FPGA, and the Drumulator boots up. At least, its processor part.

The problem with the story is that all the real-time operation of the machine is managed by a Z80 CTC. During my tests, I simulated the operation of this CTC. Simulating means I ensure the CTC behaves the way I know it should respond. The only problem is that this virtual CTC is not programmable, and in fact, I only use the channel managing the display multiplexing. But anyway, the proof of concept was validated.

Indeed, after testing the analog part of this Drumulator, I decided to tackle this CTC anyway. I did find some VHDL 'codes' for a Z80 CTC on Internet, but I was never able to use them correctly for this Drumulator project. The reason is that these codes were designed to react according to the very specific needs of the people who coded them. In fact, they are not complete Z80 CTC codes.

So, a few months ago, I tried again to create this CTC. But in vain. I did manage to get something working with the display board I specifically developed for the Efinix development board, which features a Trion FPGA, but it was impossible to achieve stable operation of the Drumulator's keyboard/display interface. I ended up abandoning the subject because, on top of that, I lacked the proper tools for debugging the VHDL code.

Since then, I have reused the TRION development system for my MSX cartridge. The goal of this new cartridge implementation was to incorporate a processor directly inside the FPGA to handle file transfers from a PC. So, having used the internal processor provided by Efinix to debug the download process step by step, I thought I could use this internal processor to send stimuli to my CTC VHDL code, while also being able to retrieve the state of this CTC, again through the internal processor, and send the result to a text console. 

If needed, a few lines of VHDL code 'would be' added to allow the visualization of certain signals directly on the development board's LEDs. This therefore seemed like a very compelling possibility for developing and testing VHDL code. However, as I am not a VHDL coding expert, and having spent a considerable amount of time trying to code the CTC in VHDL, I had realized what could be called a mistake, not in analysis, but in the structure of the VHDL code. This made it harder to understand and very complicated to test without the proper tools. And that's where AI comes in.

I then posed what seemed like relevant questions to an AI and refined the subsequent questions to steer this AI in the direction that suited me best. After a few iterations, I realized that the essence of the CTC was there. Furthermore, the code structure was different from what I had personally developed, but this posed no problem for me in understanding its 'intended' functionality at first glance, and also in immediately identifying potential points of failure, and most importantly, for what reasons.

So, I began systematically testing the VHDL code provided by the AI with the help of the internal processor implemented within the FPGA. And, little by little, I first validated the writing to all the CTC registers, then the various selected modes of the CTC's 4 counting channels, and the reading of the registers. And then, inevitably, the time came to test the interrupt system. This is the stage, I believe, where I failed to validate my personal VHDL code developed a few months earlier. And this interrupt management aspect is crucial for the Drumulator, and obviously for all Z80 systems that use vectored interrupts.

I tested all aspects of vectored interrupt generation: the management of the IRQ pin, the interrupt vector, the daisy-chaining of interrupts, the IEI and IEO signals, and, most importantly, the handling of interrupt ACK from the Z80. It's the same as always—nothing is complicated once you understand how the CTC works, but coding everything correctly in VHDL is not that simple, at least for me.

As a result, I was able to start from the source code provided by the AI, modify it, adapt it, and test its functionality step by step as features were implemented. The outcome is that I managed to test 100% of the CTC's VHDL code functionality. However, I must note that I am not using this CTC with a "real" Z80 but with a Z80 simulated externally via the input/output ports of the embedded processor.

Obviously, I coded the I/O behavior of the embedded processor to react exactly as a real Z80 would. Therefore, I cannot say this CTC is 100% validated as being identical to the original CTC, but from a functional standpoint, it is. And I have a strong presumption that it will work with a VHDL Z80 implemented in this same FPGA. However, one should anticipate that there will be some 'edge effects' during the concrete implementation and use of this CTC.

So, what was the contribution of AI in all this? Well, the generated code served as a framework to follow for developing and testing the VHDL code. Paradoxically, the code produced by the AI seems quite clean and, above all, easy to follow. Obviously, where I thought it wouldn't work, it didn't. But I already knew the reason, so I only had to correct it. In fact, the AI doesn't handle different timing domains at all, but that's not a problem when you know how it's supposed to work.

Finally, I have a functional and tested Z80 CTC VHDL code, ready to be used for real with a Z80 also coded in VHDL inside a TRION FPGA. In terms of time spent, I would say the benefit is total. Of course, I have some knowledge of VHDL, as well as logic, programming, electronics, etc., so I wasn't starting from scratch. But in fact, the time spent on this project corresponded to 30% development and 70% testing, which is a very satisfying ratio for me.

Next step in this subject: attempting to get the Drumulator's processor section running, this time with the help of a "real" Z80 CTC.

NEW COMMODORE 64

Thanks to digital technology, we can now easily publish almost anything.

So why not? Well, because I just received the very first computer from the new company Commodore:
https://www.commodore.net

I received the machine after the holidays because I wasn't around. But anyway, the important thing is that the machine arrived!

YES!

I am happy to 'rediscover' Jeri Ellsworth on the staff of the new version of Commodore. I first came across her in the early 2000s when she created an FPGA-based motherboard with a processor slot that could serve as the foundation for a new C64.

Bil Herd, who needs no introduction, and of course Christian Simpson, whom I've also been following for quite some time, particularly during the design phase of the X16. I don't know the other people at all, but I wish them all great success within this new entity. 

I remember the 1990s and the collapse of all 'alternative' computing. I was utterly disheartened and suspected the following years wouldn’t be much fun for me. I wasn’t disappointed, and it lasted… 30 years! Thank you to everyone, even if it’s a little late for me now. Nevertheless, this reconnects me with the thread of 'my life' after all, and that’s a very good thing!