Drumulator : with RISC-V processors.

Well here we are...

First in a long series of iterations on building a Drumulator clone. As a reminder: after trying to create a Drumulator using FPGAs, I gave up following the time wasted on the last used circuits from the Efinix brand.

Additionally, real-time debugging is much easier with microprocessor tools than with FPGA tools. Well, basically, for the type of subject in question here, it ultimately seems much more relevant to me to start on a microprocessor basis than on an FPGA basis.

In addition, this should also allow me to offer more capacity for the machine envisaged, while retaining exactly the same characteristics, including the non-linear 8-bit sampling which gives all its charm to the Drumulator.

To begin this series of micro-developments, I will focus on the sound generator since, ultimately, it is this generator which is the heart of the machine.

On the original machine, it is a whole series of logic circuits associated with static RAM which manages this subject. Moreover, EMU calls this sound generator, a 'sound sequencer'. The goal here being to do the same thing but using the minimum number of circuits and the minimum number of electrical connections, I am therefore going with a converter whose digital data will be supplied by the SPI bus.

In the continuation of this development, I will also try the use of an SPI type wave memory, in order, again, to minimize the need for connections. All this will have the effect of reducing the cost and electromagnetic radiation.

So, for now, my very first test is to set up a reliable SPI link to the digital to analog converter.

I'm not going to detail the whole process here, but basically it involves generating an SPI bus with the characteristics expected by the audio converter. That is to say, the number of bits expected, the different polarities of the signals and the frequency acceptable by the converter, here 10Mbits maximum per second.

So I configured the registers of the processor used to match the needs of the converter. I even made the maximum frequency dynamic to always configure the maximum frequency achievable by the processor according to the configuration of its clocks, but while always remaining less than or equal to 10MBits per second.

The signals seem completely correct and, in any case, present exactly the programmed pattern:

u16  Data = 0x555D;

I will now tackle the generation of interrupts. In fact, the data to be sent to the converter must be sent a certain number of times per second. It seems to me that it is around 22KHz for the Drumulator. I'll look up the actual value later. For the moment, it is a question of generating the same SPI signals not inside an infinite loop in the main() function, but directly by interrupt...

Drumulator : with RISC-V processors?

When you want to recreate an existing machine, is it better to recreate the hardware to install the original software, or to create new hardware but with the need to also recreate the software system?

After years of various tests, I chose: I recreated absolutely everything.

I recreated the Drumulator hardware in a number of FPGAs. Since these circuits are very expensive, I changed FPGAs several times, ending up with GoWin FPGAs in 2021. However, these GoWin FPGAs have increased significantly in price after 2022, making these circuits much less interesting. After further research, I finally found the Efinix brand FPGAs.

It took me some time to get used to these new circuits. But I managed to implement the Drumulator processor core. Unfortunately, if the system seems to work well, a few moments, quickly, the display shows anything. Despite having tested the entire Z80 interrupt management system, I am still unable to understand what is happening. Especially since I took the VHDL source code that allowed me to implement this Drumulator in the Altera and GoWin FPGAs.

Seeing time passing without being able to get out of this impasse, I decided to abandon this way of doing things and recreate the machine from scratch. In fact, and to repeat a remark from a former electronics professor who told me in the early 90s, "you are really a guy from the 80s technos", that is to say that I am rather very comfortable with microprocessors, well I will use one or more small fast RISV-V type processors. They are really not expensive and allow to perform fast tasks, knowing that they are capable of operating at 144MHz.

I have already had the opportunity to make a timer compatible with the TMS1121/1122 in this way. Indeed, it took me a little time to make the software because, contrary to what one might think, it is not at all obvious to move from a type of operation imposed by the programming system of the time, namely assembler, to an advanced language of the C type. It is mainly a problem of structuring the code and data.

But hey, I got there.

Not to mention that the development software allows real-time debugging with display of variable, register and memory values, all in a very dynamic way.

All this is not possible with FPGAs and especially the associated software which are, at least for Efinix, very slow and not practical at all, from my point of view.

In addition, the idea being to create a system as simple as possible, with a printed circuit board as simple as possible. The use of these small RISC-V processors will allow me to synthesize the machine into several parts which will, therefore, be more easily modifiable or even upgradeable.

The heart of the machine being the sound generation sequencer, I will start by recreating this part inside a RISC-V processor.

The operating principle of this sequencer is very simple. A certain number of times per second, the sequencer compares a base register of a sound address, with the value of the end address of the sound considered. As long as these two registers are not equal, the sequencer retrieves the data from the current register, in fact the base one which is incremented at each reading, sends this data to the converter while selecting the assigned physical output, thus increments this register. The operation is repeated as long as the base register has not reached the value of the end of sound register. This is also repeated for the eight outputs in the same period of time. And so on.

The experiment here will consist of checking that I can actually perform all these operations in the allotted time, knowing that I want to use components operating on SPI bus so as not to have to route a large number of tracks on the printed circuit.

This means that I will use an SPI DAC but also an SPI type sound memory. I must therefore perform an initial SPI reading of the memory then an SPI writing in the DAC. This process must be repeated eight times in the same amount of time, all a certain number of thousands of times per second.

Will this be possible?

In principle this should be possible. The SPI buses will be configured at 10Mbits/s due to the characteristics of the SPI components. This will give a transfer possibility of one Mbyte or 500K words (of 16 bits) for each component. Knowing that the sampling frequency is a little more than 20KHz, 22Khz I think, the transfer capacity must be 22,000 * 16 (8 words in SPI reading and 8 words in SPI writing) or a transfer of approximately 352,000 words of 16 bits per second. We are well below 500,000. This should therefore work without problem, knowing that purely processor operations on address pointers are very simple.

To return to the long-overlooked policy of small steps, the first operation consists of configuring the SPI port of a RISC-V processor to allow it to communicate at around 10Mbits with a 12-bit audio converter.

For this I will take an audio board that I developed two years ago now, containing everything necessary for the development of the eight outputs of the Drumulator:

As for the development board, I will use a test board that can be easily found on the Internet:

I have already tried to do this type of operation with the DAC board using an ARM circuit from STmicro. But there is nothing to do, I can't get used to the development environment as well as the different ways of using ST libraries depending on whether you want to work at a low level, i.e. close to the hardware, or at a higher level. I really prefer simple environments and development software that is not too graphical, which requires you to program the necessary registers with full knowledge of the facts without potentially being 'fooled' by the development software. In short, with ARMs, I did not achieve a satisfactory result. I hope to achieve this with this RISC-V processor.