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.

Efinix FPGA with the Sapphire SoC.

After my misadventures trying to create an MSX cartridge with the help of an embedded processor, I decided to dive headfirst into the fantastic world of SoCs.

So, of course, I have some experience with FPGA programming, but I have never attempted the experiment of implementing a processor that can be debugged in real-time.

In the past, I have implemented Z80 and even 68000 cores. But each time, it was to run code already developed for the version with a 'real' processor.

Here, the goal is to develop a new application. In fact, it's about porting the routines I already created for the STM32 processor-based MSX card to the embedded processor from Efinix. It is a RISC-V machine with very promising capabilities.

I struggled a bit to understand how the system works and to set it up. It's actually very simple, but when you've never done this kind of thing before and everything has to be figured out on your own, it takes a little time.

After a few tests done solely with the Efinix development board, I had a small extension board made with Flash, SRAM, and an isolated USB serial port. So, I'm resuming my development on this system after a few weeks' break. Naturally, even though I had taken notes during my initial tests, I encountered a few difficulties again, but nothing serious.

A quick and dirty card designed to run at low frequency anyway.

Issues with software instability; random problems with JTAG probe conflicts.
But overall, after two or three PC reboots, everything settled down and is working perfectly fine.

And, so, a little screenshot of the system in operation. I'm just using a slightly modified example program to regularly display text strings in a terminal.

Und fertig!

 

Drumulator and Efinix FPGA.

The fact is that I have made good progress on the transcription of the Drumulator into an FPGA.

But what craftsmanship job is the management of vectorized interruptions on the Z80! It 'smells' like the thing put in place last, with the resources still available for the circuit, and added on top of the logic of the processor itself! 

Well, that's the effect it has on me. So, it's a bit complicated to create a circuit that responds to this mechanism, especially the CTC circuit, very important in the Drumulator. I still got there.

But another problem arises. I wanted to recover the values ​​of the display digits in registers in order to be able to exploit them as I wanted, but using the small resources of the FPGA development board, I absolutely cannot get an idea of ​​how the multiplexing of the display is set up.

Obviously, everyone knows the principle of multiplexing, and basically, it works in the standard way on the Drumulator, but I retrieve multiple information in the registers. So, and as I have already set up the display of the Dumulator on an FPGA board equipped with 7-segment displays, I decided to create a small display/keyboard card functioning in the same way as the hardware implemented on the Drumulator. And in any case this card will allow me to work more easily with the Efinix FPGA board because it only has 8 user LEDs in total: it's really too few and it's a real criticism that the 'we can do with this board.

Here is what I sent to be done:

Although the Drumulator display only has 4 digits, I implemented 8, which will allow me to also display other debugging information if necessary.

So I'm putting this topic in standby until I receive the printed circuit  board and can mount and test this display/keyboard card.

Trion FPGAs

And meanwhile...
I am testing new FPGAs, in this case the TRION family from Efinix.

Why venture into other FPGAs, when I have already worked with those from Altera (now Intel) and those from GoWin? Mainly for a question of cost and availability of 'small' footprints.

I really started testing the development chain only a few days ago and I must say that I am progressing quickly and easily. I had already studied the entire processor part of the Drumulator drum machine a few years ago. I implemented this part in Altera FPGAs, then GoWin in 2020, but I stopped this subject because of the shortage of components, then subsequently, the very significant increase in component prices, particularly that of FPGAs GoWin, which more than doubled.

And then, I recently discovered FPGAs from the Efinix brand and in particular the Trion family of FPGAs. Given the price of these circuits, I decided to resume studying the Drumulator. For this, I acquired a basic development board :

After installing the Efinity development software, I set about transcribing my VHDL source code to this new development tool. Its handling is not at all complicated and resembles the development software of other FPGA manufacturers, although simpler.

Although all windows can be floating, when you have a screen of sufficient size, the most practical thing is to have them all in the same window. The window 'modality' system used by Efinix can sometimes be quite annoying.

Nothing special for those who have a little mastery of VHDL, a language that I use mainly for writing code. The development board only contains a minimalist 'user' interface. A few LEDs and a few switches and that's it. It has no displays at all. So, it becomes a little complicated to test my Drumulator source. So I coded a driver allowing it to be sent to a serial interface, what the Drumulator should normally display on its four digits.

After some trial and error with the Efinity development software, I ended up obtaining a complete compilation of my source. All that remained was to test it on the development board.

But before that, you must install the USB drivers allowing programming of the FPGA. In fact, it is necessary to use the Zadig configurator in order to configure the two interfaces offered by the development board. The SPI interface and the JTAG interface.

'As they say', there is no reason why the installation of USB drivers should not work. And, normally, we must actually get the two drivers installed in the system.

At this stage, all that remains is to program the board with the generated code. For my first tests, I use JTAG programming, which allows the FPGA configuration memory to be directly programmed without touching the SPI interface and therefore without modifying the external configuration EEPROM. This allows you to find the demo code present when the board was delivered and therefore to check that it still works. We never know...

And there you have it, the whole procedure went well. Firstly, as I did not connect anything to the development board, I simply activated part of the LEDs with the memory zone selection signals, as well as creating, but externally to the Drumulator system, a low frequency blink clock for an LED. This will allow me to verify that at least the entire development.programming chain is functional, the traditional Hello World, in a way.

I developed a small expansion for the development board. The idea is to be able to test digital audio using boards recovered from an Akai digital recorder, as well as to test an HDMI type video output. These two topics are based on LVDS transmitters/receivers.

Otherwise, we can clearly see that the 'left' LEDs are lit. In fact, if you look closely, you can see that the one on the far left is slightly less bright than the others. This suits me well, this LED corresponds to access to the ROM of the Drumulator. It is therefore the most frequent access, which therefore represents a more intermittent ignition time, and therefore lower brightness.

And, what can't be seen in the picture, the LED on the far right is blinking slowly, indicating that the entire development chain is working.

Provisional conclusion: I am now sure that the entire development chain works, as well as the programming system of the development board. I also have strong presumptions about the functioning of the Drumulator core in this FPGA. I still have to connect a USB/serial adapter to my computer to check that I am receiving something when the board starts up.

I haven't coded the conversion of Drumulator segment type data to its ASCII character equivalent, so if it works, I will potentially receive anything, maybe even non-printable characters. It doesn't matter for the moment, the goal is already to see communication. And then it will be quite difficult to display anything else, given that I have not yet connected any switches to the heart of the  'Drumulator', I will not be able to generate any other information transmission. But hey, everything in its time...

Just for fun?

It's been two to three years since I fully understood the 'democratic' operating (or dysfunctional) system of France. I know for example that, given my social class of origin which is totally foreign to the French bourgeoisie, and the way in which the oligarchy (the upper French bourgeois classes in power) has made the creation and exploitation of a viable business in France totally impossible for people not from the bourgeoisie, I know that it is totally impossible for me to 'succeed' professionally both as an employee and as an independent. This situation, absurd if we consider the collective aspect, leads to the economic results of France today as well as the result in the 2024 municipal elections in favor of the National Rally.

For decades I had felt that something was wrong in this country, but hey, to understand, you have to 'politicize' yourself. Which was not the case for me until recently.

Brief! However, it has been a very long time since I realized that what I was asked to do, within the framework of a job, did not correspond at all, neither to my real skills, nor to my desires. Reasons why I have always developed electronic projects privately. Lately I have even tried to insert myself into topics trying to promote my achievements and possibly market them. In vain. On this subject, however, I haven't really managed to understand yet. I have an idea, but I'm not sure.

By developing small electronic systems, I acquired some small skills. I am therefore going to implement them in what was my childhood dream: creating electronic devices dedicated to music. I have in stock an 8-way CV/GATE interface to be finished, as well as a MIDI connection system a little more adequate than the current MIDI network to be finished. So I'm going to devote myself to it.

And, since I have just repaired a Drumulator again, I like this machine and I have already prototyped pieces of it, I will start by trying to create a complete clone. I will put the progress of the project on this post.

Why the Drumulator?

My last repair dated 2024/06/30

Because it is a rather particular machine which, despite the theoretical simplicity of its operation, produces very good percussion sounds. This is because the sound production system is based on playing non-linear 8-bit samples. To simplify, it uses a particular coding that was used in analog telephone networks to artificially increase the audio quality of communications. Its 8-bit resolution thus increases to a 12-bit equivalent. Obviously, as the conversion cannot be linear, this gives a very 'punchy' but nevertheless very well defined rendering, perfect for percussive sounds.

Clone this machine, yes, but in a hardware way or in a software way?

In fact, I have already had the opportunity to develop the processor core of this machine in FPGA, as well as the wave sequencer. I did this on an Altera FPGA, then GoWin. I wanted to use Gowin FPGAs, but between the time I carried out my first tests and when I could have started producing a prototype, the price of Gowin FPGAs was multiplied by three!

At that time, about four five ago (2019), the price of a used, working Drumulator was around €250 in France. Which did not leave much room for the creation of a profitable machine from a financial point of view. The price of a Drumulator has now increased significantly, and is around  €700 ~ €800, leaving room for a clone.

https://fr.audiofanzine.com/bar/e-mu/Drumulator/

I also spotted FPGAs from another manufacturer whose characteristics are quite interesting and whose selling price corresponds to the development of equipment that must be sold at a reasonable price: the Trion family from Efinix

Obviously, moving from one FPGA family to another is not particularly trivial. Not because it involves changing the type of technology, but rather because it is 'yet' a leap into the unknown. When you 'habit' with a component, you navigate within your 'comfort zone'. Obviously, changing manufacturer means changing development software, physical constraints on the component itself, etc... We never do it lightly. But hey, at some point you have to go.

If I start this topic about an FPGA Drumulator, it's because I have already carried out some tests with the Efinity development software, from Efinix. And I know I can compile a complete Z80 system inside a Trion Fpga component.

But as of now, I have never actually programmed the study board I purchased.

For the moment, I have just implemented a Z80 core associated with the original Drumulator ROM in version 3.0. I have no means of display or input. I will therefore ensure that the message which should normally be displayed on the four digits of the Drumulator is displayed on my PC screen. To do this, I will just need to implement a system that translates the codes sent to the digit into a character string suitable for display on a terminal.

I will keep this principle subsequently, because I intend to dedicate the management of the front of the machine to a processor which will be connected by serial port to the FPGA.

So: attempt to activate the core of the Drumulator with display on the serial terminal of the 'famous' message "Bad"!

GoWin FPGA, why?

I discovered GoWin FPGAs a few years ago. I have nothing to say about these FPGAs. They work well, the software also works correctly. Everything is for the best in the best of all possible worlds then?

Hmm, not really! I ordered these FPGAs at the beginning of 2021. And, thanks or because of the shortage of components at that time, the price increased by 50%. Which makes these circuits, how to say... less interesting to use now.

Indeed, I design electronic systems for the 'enlightened' amateur domain, and not for the professional domain. The spectrum of manufacturing prices cannot be high. I therefore have to use components with the best quality/price ratio.

This is the reason why I decided to test a new family of FPGAs. I chose the Efinix brand and the FPGA TRION range. I know absolutely nothing about these components. Before ordering a development kit, I tested the IDE and, despite a small compilation problem, quickly corrected with a patch provided by Efinix, I was able to compile a previous Gowin FPGA project without problem, namely the FPGA implementation of the µPF1. 

Although for the moment I have not produced anything concrete with these new components, I believe I was able to successfully complete the 'feasibility' tests.

So, I ordered an Efinix kit:

The adventure goes on ;-)