I really don't know where I'm going with this!

Implementing an FPGA isn't very complicated in itself. Whether on the hardware or software side, all it 'takes' is the right learning and a little (or a lot of) motivation to get there. No, it's rather what comes after that gets tricky. The potential of these types of circuits is so vast that you can consider using them in a huge number of applications. The problem then boils down to development cost. It's tempting to pack as much logic as possible into the FPGA. As a result, you quickly find yourself needing a chip with a good number of I/Os, and therefore a large pin count — and thus, a BGA package.

The development cost of a PCB designed to host a BGA-packaged FPGA is not the same as that of a board equipped with a small microcontroller. Nor are the risks of malfunction.

Considering that my field is more on the 'mixed' side — that is, both digital logic and analog — I find it risky to dive into the design of large PCBs containing a BGA package. I prefer to go the module route. That is, to focus specific efforts on the most precise sub-assemblies possible.

I'll take my process of putting the Drumulator into an FPGA as an example. Designing a relatively large PCB with a BGA seems inappropriate for an amateur-style build. So I decided to create an FPGA module tailored to my needs. I should mention that I've already built this kind of module with GoWin FPGAs, but in a 144-pin package. As a result, I didn't implement any memory on that module at all. However, with the goal of providing a complete computing core, I need memory.

So I went with an implementation using a TRION FPGA coupled with static RAM, an EEPROM for storage, a real-time clock, and a battery for backing up the memory and time.

Obviously, I couldn't get away with a two-layer PCB this time. This time, it's four layers. To keep manufacturing costs acceptable, I'm also forced to use through-hole vias, which complicates the board design.

But anyway, after a certain amount of time, I managed to produce the design for the board I want to build.

 

I have to admit that it took me a while to route the entire board. I think I've done a better job than I did with the MSX cartridge. I suppose that's normal — it takes experience, and experience only comes through iteration.

That said, on this board, I paid particular attention to the connections between the FPGA and the SRAM. The traces are short, and I matched the lengths of all bus signals, so that a fairly high operating frequency can be used.

As for the available I/O connectors, generally speaking, the traces on the 'component' side will be fairly fast since they won't encounter any vias. That should compensate for the signal integrity loss caused by longer trace lengths. The other signals will have at least one via along the path, and some of them two, though the latter case is very rare.

I have no idea how I'm going to actually assemble this board. The PCB manufacturer I work with doesn't stock Efinix FPGAs. So either I find another supplier capable of assembling these FPGAs, or I mount them myself. In which case, I'll need to get a hot plate to solder the main components.

Moreover, I don't know whether the wiring as it stands will actually allow the JTAG programmer to work properly. To figure that out, I need to wait until I implement the MSX cartridge, so I can verify that the power supply I've set up is correctly matched to the FPGA, and that the JTAG connections are properly made.

So, designing this board has already been an adventure. I was really skeptical about whether I'd even get to the end of it. Assembling this board is going to be a new adventure. But hey, if I really want to move beyond the 'Sunday tinkerer' phase, I have to take it to the next level. And since I've now gained a good command of VHDL coding, I no longer have a choice — I have to go for it.

 

And now for something completely different!

While waiting to receive the printed circuit board for the MSX cartridge, I started working on making a compatible USB card for the AKAI S5000/S6000 samplers.

The reason is that I know someone who is developing a new version of AKSYS that works perfectly under Windows 10 & 11. It turns out that not all Akai S5/6000 machines were shipped with this card. That's a shame.

So I studied the card I own and looked into whether it might be possible to create a new version.

It turns out that it is.

On the one hand, a USB component compatible with the one on the original USB card still exists today. And on the other hand, I was able to retrieve the logic equations of the PAL chip that is on this card.

For now, these equations seem to be correct, since I was able to repair another original but faulty USB card using a GAL programmed with my equations. So I am hopeful that this will work, even though the decoding performed by the original PAL is quite unusual.

The card's schematic is also unusual. Without going into too much detail, some functions are implemented by first latching a kind of register — registers made out of resistors and capacitors.

In short, the read and write functions are not direct but require going through other operations first.

In any case, I have completed the schematic and then the PCB for this card :

So, I have no idea whether this new card will work or not. The only way is to test it and compare the signals with the original card if it doesn't work.

Next steps after the first tests....

New batch of triple output PSU, for not only the PROPHET-VS!

A few years ago, I developed a regulated power supply with three outputs: +5V, +12V, and -12V, primarily intended to replace the one found in the Prophet VS.

The characteristic of this power supply is that it is fundamentally a high-performance switching power supply, but not directly connected to the mains voltage; instead, it is powered by a step-down transformer providing 18V AC or, better yet, 24V AC. Consequently, this power supply does not present the dangers inherent in using switching power supplies that are directly connected to the mains.

As a result, the overall efficiency of this power supply is much better than that of a purely linear supply. The 5V output comes exclusively from the switching power supply section, whereas the two analog-dedicated supplies, i.e., +12V and -12V, are derived from high-quality linear regulators, followed by filters to suppress any residual harmonics. The voltage supplied to the linear regulators is just above the input voltage required for their operation.

With all these precautions, the power supply runs globally very cool and is capable of delivering 1A on each of its outputs.

Additionally, a special connector provides everything a processor-based system needs in terms of RESET and faulty voltage indication, thanks to the addition of a specific component that performs monitoring and control operations with precision. This component is a MAX707CSA+T. Note that a CR2032 battery holder is available, providing a backup power pin on this connector.

Finally, three connectors — including one specific to 3.5-inch floppy disk drives — are provided to facilitate connections.

In fact, this power supply can be used both for repairing synthesizers, as in the case of the Prophet VS in this example, and for powering any device operating on 5V requiring high-quality symmetrical power supplies for an analog section.

A new batch of these power supplies has been produced.

 

 

 

 

 

The Z80 CTC: what a poem this thing is!

Over the past few days, I've returned to implementing the Drumulator in an FPGA. I won't go over the whole story again, but after multiple attempts and failures to produce a viable VHDL code for the Z80 CTC, I finally managed to create a 'minimal' version earlier this year (2026), thanks to a 'great' collaboration with AI that began in December 2025.

I knew that even if this time I managed to boot the Drumulator system on the Efinix FPGA board, my code wasn't very good—especially regarding clock domains, not to mention the rather poor operation of the entire channel clock management circuitry.

Confirmation that my 'CTC' wasn't working correctly came when I tried to implement the management of the Drumulator's data potentiometer."

The operation of this system is very simple to understand. The Drumulator initializes a pulse on the 74LS221 circuit. This pulse lasts for a 'certain time', corresponding to the charge of capacitor C77, charged by the current flowing through the potentiometer. This pulse acts as a gate, allowing the CLK.D clock to trigger one of the CTC counters — in this case, counter n°2, since it is connected to the CLK/TRG2 input.

However, this requires a specific programming of CTC channel 2, in counter mode. But that's not enough. The designers at EMU exploited the CTC's characteristics to the fullest. Thus, they fully utilized the operating behavior of the CTC's RESET system.

Last week, I completely rewrote the CTC code, this time fully managing the different clock domains and implementing the entire logistics chain for configuring the channel clocks. Apart from a small issue regarding the trigger edge of the Write signal, everything worked from the start.

But since the CTC is (in my opinion) now properly programmed, every little inaccuracy comes at a cost!

The first issue was initializing the counters to ZERO. I hadn't looked closely at the documentation on this point — well, because it didn't seem like the most important thing. Except that handling ZERO is important. In fact, it's very simple. The counter counts from 256 down to 0. Except that 0 triggers the counter reload and possibly the generation of the channel interrupt. The counter must therefore be 9 bits, not 8, and when you load the value 0x00, you actually need to load 0x100 — easy!

The other problem concerns the CTC's RESET system. Again, it's very simple once understood, but because it's not intuitive, it takes a little time to grasp how it works. It's a rather strange behavior — in any case, it doesn't match at all what one would expect from a 'standard' RESET. Since explaining it here would be a bit long, those who are curious can refer to the CTC documentation.

Since I now have a fairly good command of the Efinix debug tools, I was able to use them to trace the RESET behavior and finally understand where my misunderstanding lay. Now, it's understood."

And the result is:

The Drumulator is in tempo adjustment mode. This is done using the potentiometer stuck between the black and yellow terminals of the breadboard,

It works very well. However, on my breadboard, I powered the logic circuit not with 5V but with 3.3V. As a result, the trigger thresholds are no longer exactly the same. I was able to easily correct the operating range so that the minimum and maximum value ranges correspond correctly to the extreme positions of the potentiometer wiper, simply by adjusting the CLK.D clock that triggers counter n°2. 

Now I have all the technical aspects of the Drumulator implemented. I even have the metronome output! I don't think I will handle synchronization because everything is done via MIDI now. I'm also not going to implement the cassette interface since no one uses it. I'll consider using another backup system instead of the cassette.

I think I'll stop my FPGA-based investigations on the Drumulator for a while. Now I need to create an FPGA core for this Drumulator. I've started designing the printed circuit board. But before moving on to the physical realization of this circuit, I will now finalize the MSX cartridge. It is with this cartridge that I will see whether my Efinix FPGA implementation has been done correctly.

I've been tinkering with FPGAs for years. But I hadn't acquired the general mindset to adopt for programming them. AI was a very good trigger, showing me the way of what needed to be done and what was best to avoid. With this help, I accomplished in 4 months what I hadn't managed to do in over 10 years. Beyond the pleasure of (a small) success, it is also and above all the pleasure of the intellectual groundwork progression that this gave me!

MSX cartridge, it's progressing...

So this time I'm not really making progress in terms of building this MSX cartridge, but I'm tackling all the programming aspects of the future equipped cartridge, which therefore includes an Efinix Trion FPGA.

For now, I've implemented a fairly standard FPGA connector on the MSX cartridge. The problem is that I haven't really experimented with programming Efinix FPGAs using an external JTAG probe. I've simply planned what seems to be the minimum in terms of hardware and am doing all my tests using the JTAG probe on the Efinix development board.

So I got this type of JTAG programming board based on an FTDI 2232H component :

That's about 30 dollars!

Setting up this type of interface involves three steps, after which it will be configured as a JTAG probe by the Efinix programming software:

1.     Configure the hardware resources of the interface.
2.     Install the necessary Windows driver so that the 'new' interface is recognized.
3.     Establish connections with the FPGA's JTAG connector.

For step #1, it is necessary to modify the operating mode of the two ports (A & B) of the FTDI 2232 circuit. To do this, you need to download the FTprog software from the FTDI website, scan for FTDI-type USB interfaces, then configure the two ports as follows:

You just need to configure both ports A & B in 245 FIFO mode. The driver type does not need to be changed. You can also modify the string descriptor to have something more explicit displayed when the interface is detected in the Efinix software. In fact, and after several issues while figuring this out, I copied exactly the same information as that written in the JTAG interface of the development board. The key takeaway, at a minimum, is to configure ports A & B in 245 FIFO mode. 

And that's it. Never modify the VID and PID because after that it may become very complicated to make the FTDI component reachable again by 'standard' software. I had to find a utility on the Internet to perform a 'brute force' erase of the configuration EEPROM, which made it possible to find the interface again using the FTprog software.

For step #2, it is now necessary to modify the drivers for the two interfaces corresponding to ports A & B of the FTDI component. By default, both interfaces are configured with an FTDI driver. To change this configuration, you need to download and install the well-known Zadig utility. You can find documentation on the Internet about its use, which is very simple. At this point, you just need to replace the original drivers of both interfaces with the WinUSB driver. Do this for both interfaces. Because yes, it seems that the Efinix software prefers the JTAG interface to be set up on port B, but doesn't dislike the situation if port A is not also configured like port B. I have no explanation for this, but judging by the messages provided by the Efinix programming interface, I received 'blue' warning messages indicating that a JTAG interface was present on port A but that 'usually' or 'normally' (I'm not really sure), it's better to have it on port B of the 2232 chip. So be it!

I have already done the job, which is why the driver shown is already the WinUSB driver on the left side of the window. Initially, at this location, you will see the FTDI driver.

After these modifications, you will get the two interfaces shown like this in the devices:

'Trion T20 Development Board' is the information I entered into the new FT2232H chip using the FTprog software.

For step #3, All that remains is to connect this new JTAG interface to the Efinix development board. Nothing complicated, except that you still need to be careful about certain points that are not really detailed in the documentation.

The first point concerns the JTAG interface integrated into the development board. I haven't mentioned it until now, but I am using the T20 BGA 256 board. This board has a JTAG connector that is connected on one hand to the FTDI 2232H chip integrated into the board, and on the other hand directly to the FPGA's JTAG port. Since there cannot be two masters on board, you absolutely must disable the internal JTAG interface of the development board. The JTAG connector has a pin labeled 'FRST' which, as its name seems to indicate, stands for FtdiRST. Simply connect this pin to ground by connecting it to the ground pin located right next to it. 

Then, simply connect the classic JTAG signals, namely TMS, TCLK, TDI, and TDO, between the external JTAG probe and the JTAG connector of the development board, not forgetting to connect ground. And... it's almost done.

Yes, almost done, but not quite. In its current state, you will be able to use this external probe, which will be properly recognized by the Efinix programming software. You may even be able to read the FPGA's identification number on your board, but you will not be able to program it.

Because 'the funny thing' is that the Efinix software must temporarily put the FPGA into RESET before starting its programming. I searched through quite a few docs to find out why the Efinix programmer could successfully read the FPGA's ID but was unable to program it, and it took me a little while to find the answer.

Well, in fact, another pin of the FTDI chip is used to reset the FPGA: it's pin ADBUS4 of the 2232H. 

Follow the arrows.

The two points indicated by arrows need to be connected. The goal is to bring the ADBUS4 pin to 'the' available pin on the external JTAG connector. For your information, the JTAG interface I received is version V3.6, and you can find its schematic at this location: GitHub

I simply used a small piece of wire to connect these two points on the solder side. Once the board is put back in its case, this wire is unlikely to move or potentially break a solder joint.

 Simple, isn't it?

Following all these steps, simply summarized here but which actually took me quite some time, I was able to program the FPGA of the development board in JTAG mode without any issues. That was a good start. But you are certainly aware that while this allows the FPGA to be configured, it is a dynamic configuration stored in the FPGA's internal RAM. As soon as the FPGA is reset, it cannot find a configuration file because the external EEPROM has not been programmed. And you are also certainly aware that it is possible to program an external EEPROM connected to the FPGA via the JTAG port of the same FPGA. This is a specific programming mode that the Efinix software allows you to use.

The advantage of this system is that to be able to develop, meaning to quickly modify the FPGA's RAM, the JTAG interface does that, and once development is complete, it is also possible to program the final firmware into the EEPROM using the same JTAG interface. There is no need to provide an additional SPI interface to access the external EEPROM. 

So I programmed the Drumulator firmware, which I am still developing, into the EEPROM of this board using the JTAG port, and here is the result :
 

Better than a long speech: it works!

After these adventures, I now have all the elements to continue working on my MSX cartridge. However, I need to add the RESET pin to the JTAG connector because that is not the case for now.

If you have read this article, I hope you found it useful. Not that everything described here is complicated — and it isn't — but when you don't know about it, it's much less straightforward to grasp.

MSX cartridge, it's progressing...

On this cartridge, I'm at the stage of trying to create the PCB. In my last post on this subject, I was at the beginning of creating the PCB and I had absolutely no idea whether I would manage to make something clean. Well, now I have the answer: 

All the tracks are routed. I still have a bit of work to do on improving the routing, with no major functional impact — more about streamlining. While working, I switched to version 10 of KiCad. I've known KiCad for over 20 years. A lot of things have improved, but I feel that since it went into 'semi-professional' mode, there are ways of doing things that have more to do with professional software than with solutions accessible to the greatest number of people.

A small message to the KiCad developers: By all means, improve its operation and features, but don't turn it into a clone of professional solutions that require months of training and practice to create an amateur circuit. You're now moving a bit too far away from the accessibility that has made KiCad successful so far. As for me, I think I won't update KiCad any further, especially since dark theme is finally available with version 10.

Of course, I have absolutely no idea whether this board will work or not. This is my first implementation of an Efinix FPGA. But you have to start somewhere. And, as a result, this allows me to compare this type of FPGA with equivalent FPGAs from Gowin. While it's true that Gowin FPGAs are much more expensive than Efinix FPGAs, the 144-pin Gowin version equivalent to the Efinix version used here, requires far fewer external components to get it running and is, in my opinion, easier to implement on a circuit. The Gowin module I made worked fine with just a two-layer board. Here, I was forced to go with a four-layer board.

If this Efinix FPGA implementation works, I will nevertheless have a functional template for implementing the component. This will allow me to create more complex designs more easily in the future with these components. 

The Drumulator in a FPGA.

Might as well say it right away: it works.

And to specify what works: well, actually, everything!

That is to say, when I press the 'pads', I do get the correct sounds.

Quick summary of the background: a few years ago now, I decided to 'transfer' an entire Drumulator into an FPGA. Well, for the digital part, obviously.

And to be exhaustive, my adventures with FPGAs started a long time ago. I had stopped in 2014 with the integration of a Prophet VS's processor board inside an Altera FPGA. At that time, the work was relatively simple, since it involved assembling distinct IP blocks. But obviously, when it came to creating the missing components from scratch, that was a whole different story. I had to get into the 'hard' part of VHDL coding (the language I primarily use). So I had chosen to start with what seemed to me at the time to be a simpler machine than the Prophet VS, namely the Drumulator.

In reality, it wasn't any simpler. There too, everything went very well as long as I emulated the Zilog CTC with a super simple interrupt generator that actually simulated the operation of the vectorized interrupt system. Obviously, that wasn't going to be enough because the CTC generates multiple interrupts, so it was absolutely necessary to manage the Z80's vectorized interrupt system.

It was from that moment that the troubles started again. I had to once again confront VHDL.

The fact is, I have no formal training in the subject, to begin with. Doing logic isn't very complicated, but switching to the formalism of a hardware description language like VHDL requires an 'approach' that I didn't have. Basically, I didn't know where to start to truly get into this subject.

And that's when AI allowed me to do it. In fact, I used it as a teacher. Now obviously, I knew a bit of VHDL, which helped me a lot. As for the AI, I had at my disposal a teacher who never got tired of answering, had answers to almost everything, was available 24/7, and practiced no form of social class discrimination, and therefore no filtering in the acquisition of knowledge. Which is obviously contrary to what I experienced throughout my schooling in France, since this country practices social discrimination endemically. Coming from the very bottom layer of French society, I had no chance of accessing anything remotely advanced in electronics. The French education system respected its social objective to the letter.

AI therefore allowed me to bypass this system and, assuming I possess at least the minimum capacity to level up, with the training provided by AI, I managed in three or four months to get past a major hurdle.

I close this parenthesis with this magnificent image of the development system used for my FPGA work:

So, for now, I haven't implemented an analog output multiplexing system. The Drumulator uses the time switching principle to generate its eight voices. Each output is reconstructed by an operational amplifier followed by its small holding capacitor. Very standard. Except that I'm using serial buses to manage this whole system. The DAC is not a parallel data bus DAC but works using an SPI bus. The same goes for the final volume control circuit and the final audio channel switching.

Moreover, the sequencing system that generates the sound waves works in a fully pipelined manner. Managing the other serial buses will be done by adding stages to this pipeline. The only thing I paid attention to is that the circuits used are fast enough so that all the information has time to be transmitted between each new sample output.

The sound produced by my system is slightly different from the sound produced by the Drumulator. On one hand, I don't have the analog filtering system, and above all, I'm not reading the samples at the exact frequency of the Drumulator, and actually, I'm not entirely sure that the values used to translate the 8‑bit samples into 12 bits for the DAC are completely correct.

A few years ago, I implemented the Drumulator's sound generation system on an ARM processor, just to get familiar with the companding system it uses. I had manually calculated the conversion table based on the original component documentation. To go all the way,  this time I also asked the AI to calculate this table for me. I must admit the result is quite convincing.

To illustrate all this, I'll try to make a short video with sound...