Drumulator and Efinix FPGA.

A month after my last publication on the subject, a little progress...

And yes, I spent a lot of time on the EMU1 motherboard which, if it still doesn't work, gave me a lot of its secrets which will hopefully allow me to make it work again!

I am therefore resuming the implementation of the Drumulator in an FPGA. This time I test the small simulation board of the machine control panel.

In fact, I have a few issues that I didn't expect with this FPGA. Certainly, its cost is affordable compared to other offers on the market. But I discovered a pretty significant limitation of the implementation of these Efinix FPGAs.

In principle, it is of course possible to do the same thing as any other FPGA with the Efinix Trion range, except that...

It's not that simple. The internal resources are not as flexible as what you can find on other components, which means you have to rethink your way of doing things somewhat..

Basically, asynchronism is not the strong point of these circuits. Well, you will tell me that when we do FPGA, it is not to do asynchronous. Yes... or no. Actually it depends...

Well with the Trion range, the question does not arise : it's 'nyet, tovarishch' !

Once it is well integrated, you just have to review the design. And to validate my 'new' approach, I simply coded a basic Z80 system, accompanied by a very small program allowing me to test the display of the front panel of the Drumulator :

Which allows me to validate not only my way of doing things synchronously now, but also the functioning of the display system.

I can now get back to studying the CTC equipping the Drumulator and conductor of the entire machine.

The next goal is to obtain the same display directly from the Drumulator environment, that is to say with not only the CTC programmed in VHDL, but also the entire generation and reading of the interrupt vector, as well as than his acquittal. I admit that this whole vectorized IRQ system of the Z80 is still a 'happy mess' ;-)

I have (unfortunately) been working again for a few months in national education. Which leaves me less time to do electronics. I still hope to be able to make significant progress on the subject in the coming weeks...

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

Getting started with the Trion FPGA.

For the past few days, I have been trying to operate a minimal Z80 system with the aim of implementing the entire logic part of the Drumulator in a TRION type FPGA.

I will spare you the details of the necessary 'acclimatization' to a new development environment, both hardware and software. As far as I am concerned, this stage is always long and tedious for me, which is why I have never been 'pushed to study', as they say back home. (This is not the only reason, but it is 'technically', the main pretext used for exclusion from the French school system).

So, it is absolutely necessary for me to understand what I am doing. I started from the base, namely a system just capable of producing the 'famous' Hello World of electronics, namely, the flashing of LEDs. A small 'complaint' on the Efinix dev board, it does not include the minimum amount of hardware capable of producing an 'intelligent' display. No digital displays, nor LCD: too bad. You must therefore make do with the 8 basic LEDs present on the circuit.

I will therefore reproduce the animation, but with only one LED lit at a time', supplied as a demo program with the board.

In order to test the concept a little in depth, I decided to implement the LED output register as a memory register AND standard IO type output. So I produced a 'quick & dirty' conditional code allowing me to test both implementations.

(the code of death)

Regarding the equivalent VHDL code to select the LED output either in memory register mode or in out mode in the I/O zone, simply modify the code selecting the LED output register like this:

Not very complicated either!

Oh good? And several days for that? Absolutely. I had made some clock synchronization errors which meant that at the default speed, high clock speed, the system could not operate. Obviously, I then had to carry out debugging by testing the entire operating chain of such a minimum system. I could have used internal debugging, but I have to say that the Efinity development software is not really well integrated. It does not offer a signal shape viewer like GTK WAVE to display the result of an execution. In a nutshell, I didn't want to spend time trying to get difficult-to-install external free tools to work. I could also have used the I/O ports on the dev board and plugged in a logic analyzer. I have a logic analyzer on PC, but I really don't like its interface at all. And overall, I support these Windows-based systems less and less.

Additionally, I also 'wasted' time trying to figure out the file format needed to fill the BRAM area used in ROM with the 'C' code binary. In fact, the file to produce is much simpler than the Efinix documentation suggests. As is often the case, they explain the internal workings of filling the BRAM, while taking care not to correlate the explanation with a real example. So, it's pretty easy to understand how this is supposed to work internally, but gives absolutely no information about how it relates to the real world. So, it's quite complicated to understand how to simply present the binary file. The typical kind of documentation provided by Microsoft: drowning the person looking for it under a mountain of doc that ultimately has nothing to do with the question. The result is simple, the graphical interfaces supplied with small development systems are no longer updated, or work in Windows 7 mode, as long as it works. Microsoft had already 'gunned' the small structures which provided even professional software solutions in DOS and Basic, at the beginning of the 90s. Microsoft is now euthanizing all the medium structures which still work (or still try to do so) with Windows. Great!

In the end: I obviously managed to make this minimal system based on Z80 work. The Efinity software also tells me that I can potentially make it work at more than 60MHz. So I tried to power all the logic directly with the 50MHz oscillator placed on the test board, and indeed, the result is completely functional.

A few seconds of illustration of how this first test works:

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 ;-)

GoWin FPGA & µPF--1

To finalize my uPF--1 compatible board, I decided to implement the Wichit Sirichote's project : 

I have already done this work a few years ago, but based on an Intel FPGA. Since then, I have improved in the VHDL language. 

So I take advantage of this to code the whole machine again in this GoWin FPGA, also taking advantage of the improvements made by the new versions of certain components and the SDCC compiler, as well as the modifications that I have made myself.

This little development machine is very interesting. It allows you to become familiar with the operating principles of microprocessors. 

Modern processors like ARM for example, still work the same way. Understanding how a Z80 works is a very good learning exercise. Much better I think than Arduinos, which, if they have a whole bunch of 'fun' advantages, mask a large part of the real functioning of the processors.

And now with the startup messages:

At the time, I called my work uPF--2. I will continue to name this little machine that way.

This is not a priority project. I will advance it as I can, over time...

Chinese components and GoWin FPGAs. Is it worth?

It's been a few years since I mentioned the rise of China in the supply of original components. GoWin is one of those companies that for several years has developed a series of FPGAs.

So I thought it was time to try this type of components. For this I managed to get the programming tool GWU2X :

The development software tool is available directly on the GoWin site. I also had to find a development board equipped with an original GoWin FPGA. I couldn't really find what suited me on the market, so I decided to develop my own board, in Qmtech format, since I had developed a few projects with this board format: 

Very recently, I managed to implement the 'Hello World' (the blinking led) on this board. The next step was very ambitious, namely trying to implement a complete Z80 system within this FPGA. 

So, I chose to try installing the Microprofessor version 1B system on the electronic board dedicated to this small vintage computer:

The uPF--1 original board

It took me a few hours to familiarize myself with the GoWin development environment, as well as to make the necessary small modifications to my VHDL code to make this FPGA compatible with the uPF--1 system. 

So, after a few hours of work, the result is there:

I did not attempt to implement all the hardware resources of the uPF--1, that was not the goal. I just wanted to see if I could get the same services with this FPGA as with the ones I usually use like Altera (Intel now) circuits. The goal is reached. I now think I can continue to develop using these GoWin circuits.

Conclusion: I appreciate these circuits which seem to me easier to use than the Xilinx or Altera circuits. The entire development chain is easy to understand. The necessary resources are available on the web. There are few ways of doing of the software development that could be improved a bit. But this is more of a personal matter...

In short: practical component to use. Easy to use development chain: cool!

GOWIN FPGA

I'm always looking for easy to use components. As far as FPGAs are concerned, their implementation is not always easy nor always cheap (multi-voltage, external EEPROM, etc.)

As a result, I had noticed that the series of FPGAs from the GoWin brand, seemed relatively simpler to implement than the major standards such as Altera or Xilinx.

So I decided to make a prototype board. I chose the module format offered by QMTECH because I have some developments that use them. This way, I can eventually place the GoWin module instead of the QMTECH modules.

The result looks like this:

To be able to program these FPGAs, it is absolutely necessary to obtain the programming dongle. I chose the 'GoWin USB cable' (GWU2X). It's inexpensive and easy to install. The procedure of installation is described in the dongle documentation.

Once these elements have been purchased and made, all that remains is to connect them. The detection of the FPGA is done without problem. 

I had obviously made a mistake by setting up a resistance of bad value, subsequently replaced by one of good value (red circles).

If I publish this little post, it is obviously because the functional test has passed. The 'Hello World' works without problems. The user LED is flashing correctly.

I just got an example from GoWin and modified the output pins according to the characteristics of my module. 

Most of the work is done, ie the discovery and implementation of the entire development and programming chain. It now remains to really take control of this FPGA. This is a 4 000 gates model. I'll see if I can implement a minimum Z80 system there...

For this, I will use my µPF2 compatible board in which was currently inserted a QMETCH module equipped with Altera FPGA:

My GoWin FPGA-based module fits perfectly in place of the Qmtech module:

For the moment I absolutely do not know if I will be able to place a minimum system in this GoWin FPGA. I know that the number of gates used in the original design is less than 4000 gates so it should be fine but on the one hand I have no experience on the GoWin development tool, and I don't know if I can transpose the number of gates used on this new FPGA. I hope that my experiments will allow me to answer these questions...

Gowin FPGA

 I just received the PCBs for testing the Gowin 144 pin FPGA :

Yes, seen like that, it's not very 'sexy'. But hey, it will be, I hope...