In development : the Drumulator in a FPGA

As the writing of the Drumulator VHDL code continues, I encountered an issue that kept me busy for a few days. Impossible to send the correct information to the sound sequencer!

The symptom was as follows. A series of bytes must be sent to the sequencer. On the series, only the first byte is correct. The following are a copy of the first.

This results in this type of chronogram:

As you can see, I get the same code four times. In this case, I should get 0x8D then 0xD7 then 0xF8 and finally 0xF9.

After spending many hours trying to figure out what was going on, I still checked the operation on my Drumulator.

In this case, I get 0x8D and 0xD7 for half of the signals captured. On the other half (not displayed here), I get the 0xF8 then the 0xF9. So it works as expected on the 'real' Drumulator. What????

Being virtually certain that it was not the decoding logic I implemented in the FPGA that was causing the problem, I attempted to look directly at the system version 3.0 code to determine what might be causing this error.

To do so, I installed a disassembler then I examined the generated listing:

In this listing, I found a series of OUTI instructions allowing the output of a series of bytes on an output port, with auto-increment. After studying the supposed operation of this instruction, it became fairly obvious that if I got all the same byte, there was a chance that an increment would not work.

So I went back to the git of the processor core repository and here is what I discovered:

This is how I discovered that this file had undergone a modification concerning the treatment of the OUTI op-codes (among others). 

Indeed, by comparing the parts of code which deal with the problem, we see that there has been a modification with the addition of IncDec_16 (3) <= IR (3); Plus a few other minor changes:

The code on the right is the most recent code.

It's a fact, the Z80 VHDL code I am using is a bit old. But a few days ago, I had checked that I hadn't 'missed' anything important. Yes, but....

The version I use is the 0242 and there is no mention on the intermediate version 0240mj1 :

There was therefore insertion of an intermediate version n° 0240 after the publication of version n° 0242 : big mistake!!!

And since a few days ago, I had not yet understood the possible problem of the OUTI instruction, I did not pay attention to this new version.

" Okay, Houston, we've had a problem here"

It's time to test the latest version of this T80 instruction decoder!

And the winner is :

With this version of the Z80 processor including the corrected OUTI instruction, I get the correct timing diagrams. This time the sequence 0x8D, 0xD7, 0xF8, 0xF9 is good : yessssss

The Drumulator in a FPGA

Two years ago (2018), I had 'fun' implementing the processor part of a Drumulator in an FPGA.

To do this work, I used a low cost ASK2CB FPGA board from DIGIASIC, equipped with a medium density FPGA. Using the Quartus software, I quickly reached a conclusive result:

'bAd because the SRAM is not initialized'

Not bad, isn't it? For a few weeks now I have been working again with FPGAs, in particular by developing a Z80-based development board :

During this work, I also developed a small keyboard communicating by serial port. Also, I tell myself that I could take the opportunity to complete my previous work, on the one hand by using this keyboard to simulate that of the Drumulator, and on the other hand, by implementing the sound generation of this machine.

The problem is that I have to use an FPGA board with more memory resources than the Digiasic which, even with the external SRAM, does not reach 64K bytes. 

So it's time to take out my Terasic DE2-70 board :

This board, even if it is old today, remains a real 'war monster' with his FPGA Cyclone II EP2C70F896C6N! Although this board does not have standard SRAM (only SSRAM), the internal memory in the FPGA will allow me to configure not only the system ROM, but also the 64K bytes of sound.

As an example, here is the comparison of the result of the compilation of the Drumulator processor core with the two FPGAs

With the 'little' FPGA :

With the 'big' FPGA :

And 'voilà', I just have to finalize the work previously started on this Drumulator!

For this goal, the first thing to do is to translate the previous work on the DIGIASIC board to the DE2-70 board. After a little work, it's done:

With a bit of red filter to take the photo.

The new three output PSU is validated.

The initial idea was to replace linear power supplies which sometimes get very hot, as well as the switching power supply directly connected to the mains which can present security risks.

I therefore opted for an intermediate solution which consists in using a standard transformer to lower the mains voltage, and a triple low-voltage switching power supply to take advantage of a better performance than that provided by a purely linear power supply. The two outputs provided for supplying analog parts are fitted with linear regulators following the switching regulators for better noise rejection.

The result is this reduced size power supply (160 x 80mm):

I have already had the opportunity to perform some tests when I had not placed all the defined components, especially the output filter capacitors. I had to temporarily place models with through legs. For these tests, I used all the boards of a Korg T1. 

It works fine!

This time I used the final version of the power supply to power the board set of a Dynacord-ADS sampler, a famous vintage German samper :

www.deepsonic.ch

This sampler consumes more current than the T1. In fact, a little more than 2A for the 5V part for the version I own:

For this test I did not use the floppy disk drive which actually consumes very little on standby. I was however able to test the audio output which does not present any residual noise. The ADS has a switch on the front panel allowing the generation of a nice sinusoidal output.

Final thoughts: This power supply works perfectly and is able to deliver at least 2A on all its outputs without requiring a cooling system. Note that if the + 5V AND the + 12V should each output 2A, one of the diode bridges should be capped with a small cooling system since it should provide 4A, but this situation rarely happens. For ease of implementation, I may change the output capacitors to through-leg models in the production version of this power supply.

A new PSU for your old Synthesizer.

I've been looking for a power supply that can replace the ones found in some vintage audio equipment for some time. But I never found the type of product that was right for me. There are quite a few DIY-made solutions but again, these solutions didn't really suit me.

For example, I used a power supply whose primary part is a switching PSU that converts the main AC to 28V DC which is then transformed into + 5V + 12V and -12V. This system works very well. I used it in a Dynacord ADS sampler :

But the main AC is converted by a switching module. It's certainly an easy to use solution but always ends up causing problems because of the main capacitor directly subjected to a high electric potential. If this capacitor is not of very good quality, the power supply quickly loses its performance.

Others are creating new switching power supplies without an intermediate stage. In the following example, the main AC is directly converted into the different standard low DC voltage. This is manufactured by synthronics and is intended to replace the original power supply of a Prophet-VS :

This power supply is certainly of very good quality, but if something goes wrong, I wouldn't really feel able to fix it.

Other topologies are also used, for example the power supply for the JX10 from supersynthprojects.com, made up of several switching power supply modules:

In this case, each module is directly connected to the main AC, which has the effect of multiplying the potential sources of problems related to the direct connection to the main AC.

In addition, all these power supplies are specific and rather dedicated to a particular device. Not really flexible, in fact.

And by the way, what is the main problem encountered when creating this type of power supply? and why does everyone seem to want to use switching power supplies? 

The reason is in one sentence: heat dissipation. And especially in digital / analog machines where voltages of 12V and 5V are required. The 12V can be generated from a rectified and filtered voltage of 15V for example.

But mostly, the 5V is generated from the same primary 15V. And in a classic linear regulator topology, this therefore gives 10V to 'lose'. Under 1A, 10W of heat is produced. The regulator heats up, it is then necessary to equip it with a heatsink to dissipate this heat flow so that it is not destroyed.

The solution I adopted is a mix between low voltage switching regulation and linear regulation. The lowering of the mains voltage is carried out by a standard transformer. There are therefore no longer any capacitors subject to the main AC and in the event of a problem, the power supply can be easily repaired because the components are standard and easily available. 3D image of the power supply board:

This power supply provides + 5V, + 12V and -12V. Each output is able to provide 2A, possibly 3A but I have not carried out tests at this last intensity. 

In addition, I added the availability of a battery-backed voltage, particularly useful to have a 'place' already planned to insert this kind of backup in older machines that do not have a battery holder. I also added a circuit capable of providing write protection usable for SRAM protection, as well as a reliable RESET signal. Two power connectors are available plus a floppy drive type connector. 

All these characteristics should make this power supply usable in a large number of machines, while providing a very good level of safety since the main AC is no longer directly handled.

This gives a fairly compact circuit board :

This is the prototype of the power supply. For the tests some unavailable capacitors were momentarily replaced by non cms models. The final version will of course include all the right components. 

After checking that everything was working fine, I connected this power supply directly to a Korg T1 motherboard:

Everything works fine and after a few hours the power circuits are barely hot. Finally, the only modification I will have to make for the final version will be to replace the current limiting resistors of the LEDs. They really light up too much ;-)

Depending on the current expected to be supplied, an 18V and 4A transformer per winding should be sufficient for most uses. This PSU will be available in the coming weeks ... depending on the activity of the Covid ...

ZIF sockets & Bank switch on E-mu Drumulator.

Following the publication of a Youtube video from SynthMania concerning the installation of ZIP sockets in a Drumulator, I will discuss an even more interesting modification than the one presented by him. You can find his video here:

In his video, Paolo Di Nicolantonio, indicates how it is possible to place ZIF sockets in a Drumulator, in order to be able to replace the original sound bank by another sound bank. And first of all, what is ZIF support?

It is a support which allows the easy insertion and extraction of an integrated circuit. To do this, it has a lever which allows the component legs to be released or locked, without mechanical stress. This kind of support can be presented in different ways:

Most of the time the left version is used.

Now, what does a sound bank look like on a Drumulator? In fact it's quite simple ... in principle. A sound bank is made up of four read only memory. Each of these memories contains one or more sounds for a total capacity of 64k bytes. Note one very important thing: each start and end memory address of each sound is written 'hard' in the machine's system memory.

Where are these four ROMs located in the Drumulator? Inside the red rectangle:

In conclusion, each time you want to change the soundbank of a Drumulator, you have to remove these four circuits and replace them with the four new ones. However, this is not very practical!

Hence the following idea: why not have at least two banks always available inside the machine, which we could choose using a switch? In this case, the problem is that it is absolutely necessary to build a printed circuit board to receive not four, but eight ROMs. This type of extension existed at the time:

In this case, the expansion board allows the choice between three sound banks. It's interesting, but not necessarily easy to install due to the large size of the board.
Another approach is to provide only two banks, and in addition, to concatenate the four ROMs of a bank into a single ROM. In fact, two banks can be contained in two 64K byte ROMs instead of eight 16K byte ROMs like the original ones. Here is the result of such a modification :

The cable visible in the picture is connected to a switch that allows you to choose between the two sound banks. It's simple to set up and very effective. Note that ZIF sockets can be inserted to allow easier replacement of ROMs in the event that two sound banks are not enough. The only constraint consists in programming a ROM of 64K bytes with the contents of the four ROMs of 16K bytes. This is done very easily using a ROM programmer and its software.

However, as I mentioned above about the start and end addresses of each sound, this system works fine as long as you are working with the same types of sounds that have the same start and end memory addresses. 

If you want to use different sounds with different lengths than the original ones, you must also set the system ROM with these new settings. This is not an easy task. A well-known company, Digidrums, offered various soundbanks for sale. Each soundbank consisted of five ROMs. The four containing the sounds, and the one containing the modified system.

In short, to be able to switch between two sound banks, and in the event that one is a Digidrum bank, you must also be able to switch the system. Another expansion board is therefore required to perform this task : 

This board performs this task but also brings some other improvements. It allows SRAM to be backed up with a standard battery. It also offers two SRAM banks allowing the saving of two sequences that can also be selected using a switch. It improves the write protection of the SRAM, it has the MIDI input interface and finally allows to control the switch of the sound ROMs corresponding to the selected system.

The simplicity and efficiency of this board, however, requires programming a single 64K byte ROM with the two envisaged versions of the system. Likewise, this is easily done using an EPROM programmer and its software.

This is what it looks like inside the machine. The system is being assembled. The old MIDI interface has not yet been removed and the switches have not been mounted on the rear panel:

Note that by searching the Net, it is possible to find utilities that allow the creation of a complete set of four sound ROMs plus the system ROM from personal samples, in the same way as the Digidrum was doing. While remaining of course within the maximum limit of 64K bytes of samples.

More info here: