I recommend performing the general tests described here: PCBs.
It is then worth temporarily tying the 8 data lines to 8 of the address lines via resistors so that the data read will be the same as the address on the chosen address lines. This would prove that everything is connected up sensibly.
It is also worth verifying the operation of OE (pin 22) and the state of VPP (HIGH) and CE (LOW).
https://diyelectromusic.files.wordpress.com/2024/01/img_7662.jpg?w=1024In the photo, I’ve soldered up a simple test jig to tie D0-D7 to A0-A7 via resistors. I’m also using some “LED bytes” that have been doctored slightly to fit an Arduino, to indicate the status of the data lines which is pretty useful for seeing what is going on.
Then it would be useful to have a ROM for which the contents are known and then dump that entirely, for example to the Arduino serial console, to ensure that all data is being read correctly.
IMPORTANT: At this point in time, this board has not been tested for reading or writing to a 28Cxxx device. It has only been used for reading from a single 27C256 device.
PCB Errata
There is a problem with the trace that follows down the right-hand side of the board from D4 to the latch pin of the 595 (pin 12). It passes too close to one of the Arduino’s mounting holes and consequently is shorted to GND.
To fix it, it is possible to scrape off the track from around the hole and then use a patch wire. Having already built my board, this is the approach I took but if something conductive is used in the mounting hole in the future it may well short things out again.
It is probably better to cut the traces, prior to soldering any components, in the following places:
I’m not sure what I managed to disable in the design rules checker to miss the fact that that trace was too close to the hole. Oh well. I’ll have to investigate the board constraints I’ve been using.
As already mentioned, while this should in theory support reading and writing of 28Cxxx devices, as described in Ben Eater’s Github, at present it has only been used with 27C256 devices and only for reading.
I’ll attempt to get hold of some approrpiate devices and give it a go at some point. Watch this space!
I was very lucky to be offered a non-working Yamaha DX100 from Simon Walters. On arrival I can see it attempts to boot but apart from the odd character on the screen, I wasn’t really getting anything useful happening.
My thinking here is that as it is a pretty nice synth with most of its functionality on a single PCB with connectors to the peripherals, if all else fails I could stick a Pi inside and turn it into a DX100 shaped MiniDexed DX7!
But I’ve decided to have a proper look to see if I can do some “proper” digital electronics fault-finding for once to see if I can get anywhere.
Spoilers – it still isn’t working, but I’m still working on it! This is a post of what I’ve looked at so far. A massive thank you to the various synthdiy and electronics people on Mastodon who answer my (sometimes) silly questions!
Warning! I am not an electronics person. I strongly recommend that you don’t base your own attempts at fixing a beloved vintage synth on anything I’ve said here. I was given this synth rather than it being sent it to a recycling centre so this is a low-risk learning activity for me. I am not responsible for any damage to expensive or irreplaceable electronic musical instruments! There are plenty of places to take something for a proper repair 🙂
If you are new to microcontrollers and electronics, see the Getting Started pages.
The DX100 is effectively a “minikeys” version of the DX27 and the PCB itself would appear to be shared between the two.
There is a test mode which apparently is initiated by powering up with voice select 1 and 2 pressed. The thing itself is powered from either a 12V centre-positive supply or 9V worth of C-cell batteries.
As I started exploring it, its ability to show anything on the screen appeared to get less and less and finally it reached the point of showing nothing except some “power on” blocks on the display at all. I don’t believe I did anything to cause that other than turning it on and off a few times with various buttons being pressed as part of my initial exploring.
At this point I decided it was time to actually take the thing apart and take a look.
Disassembled
The repair and review video linked above shows the insides in detail. Here are my own photos.
The battery connections has a connector so it can be easily detached from the main PCB to allow the casing to be set aside.
The PCB is single sided with link connectors on the rear which are also indicated on the silkscreen on the copper side.
Each device is labelled on the copper side, including pin numbers for all the ICs.
everything from the PCB to the peripherals uses a connector so can be disconnected.
You really get the feeling that this synth was built to be fixed and maintained!
The only negative I’ve discovered is that the service manual is more of a disassembly manual and parts list. At least the version found online doesn’t even include a schematic but I did (thankfully) find an independent copy of the schematic online when doing an image search.
But weirdly the service manual does include a memory map for the CPU, RAM and ROM and a pretty good high-level description of the key circuit features! Go figure 🙂
Diagnostic Approach
Seeing as the synth is not booting at all, I started from what I considered to be the basics. This is the block diagram from the service manual.
So the plan is to check the power, then basic logic signals, then get more into the digital CPU side of things and see how things go.
Onboard Battery
There is a PCB-mounted battery to maintain the contents of the RAM when in operation. Now as I understand things, the synth should boot successfully with a dead battery and give a warning on the display, so I really didn’t think this was the issue, but as the battery was essentially reading zero voltage, that was an easy thing to replace straight away.
The service manual lists the battery as “Lithium battery, 3V – CR2032T”. I found a similar one online, but the pins were in a slightly different place. But a small bend and this could be replaced quite easily.
Note: there is a solder bridge that presumably allows the batter to be disconnected if required. Once again, the PCB is nicely labelled to ensure the battery is connected the right way round and there are two test points on the easily accessible side of the board if required.
The battery itself is on the non-copper side so the PCB has to be fully removed to replace it.
Whilst on the topic of power, and seeing that replacing the battery made no difference, the next thing to check was the power circuit.
There is a section in the service manual that explains that the power circuitry creates +5V and -3V supplies from the provided 12V. This is provided using a 7808 and 7905 (IC19 and IC20 in the schematic).
One thing I did notice though – none of the capacitors appear to match the physical footprint left for them on the PCB itself, so I wondered if someone has been through and replaced all the electrolytics at some point in the synth’s history. If you look at the photo of the regulators, you can see how there are shorter, upright capacitors compared to those in the repair video that had longer capacitors bent over to fit the space left on the PCB.
Following the schematic, I then went through and measured the VCC/GND connections on all the main chips and they all checked out. As far as I can see, they are all connected to +5V and measurements confirmed this. Again having the pin numbers printed on the silkscreen side of the PCB made this very easy to do!
Basic Logic Operations
So the next thing to look at was the basic logic operations. By that I mean checking the following:
The reset (RST) circuit.
The clocks
Chip enables (CE) and chip selects (CS).
Read/write pins (RW).
Address lines.
Data lines.
This is the reset circuitry:
https://diyelectromusic.files.wordpress.com/2023/12/image.png?w=588So that was fairly easy to check on an oscilloscope. Reset is an active low signal and once again the service manual has a detailed paragraph on its operation. I’ve not checked the exact timings, but I can certainly see it being low on power up and changing to high to allow everything to proceed.
The only thing to verify is that this behaviour is actually observed at the CPU itself. /RST is on pin 6 and that all seems ok.
There are two clocks: a “main” 3.58MHz clock which drives the CPU (and is further divided by 4 internally) and a “sub clock” of 500kHz which apparently goes through a divider to give the 31250 required for MIDI.
https://diyelectromusic.files.wordpress.com/2023/12/img_7555.jpg?w=1024The photo shows the main clock signal. The initial measurement was very rounded to the point where I couldn’t imagine it working as a clock at all, but then it turned out I’d inadvertently set my scope probe to x1 rather than x10. x10 gives a much sharper signal.
The sub-clock was an almost perfect square wave, so I considered the clocks were fine.
Basic logic operations
The next angle of attack was to check for some kind of activity on the various chip select pins.
Similarly for the address lines – I can see good clean signals on the address lines. Note that I’m not using a logic analyser here, I’m just checking for general activity using an oscilloscope at this stage.
It is worth taking a short diversion into the operation of IC14 and the main ROM/RAM.
The service manual includes a memory map and if this is mapped onto the address lines A11-A15 we can see how that logic is implemented via IC14, which is a 40H138 3-to-8 line decoder, to generate the various chip select lines.
There is a general enable (E, pin 6), two additional enable lines (/G2A, /G2B, pins 4 and 5), three selection lines (A, B, C, pins 1,2,3) and eight outputs (/Y7 to /Y0, pins 9 to 15). Given this knowledge and decoding the addresses in terms of A11 to A15 we can see how the decoding works.
If A14 or A15 are high then IC14 is not enabled, so A11-A13 are ignored.
If A15 is high then the ROM is selected and A0-A14 are significant for reading the contents of the ROM only.
Both A14 and A15 have to be low for A11-A13 to be significant for IC14, then the various outputs are selected based on the values of A11-A13.
A13=0 selects the RAM (both Y1 and Y2 select the RAM).
A13=1 selects the other peripherals, depending on the value of A11 and A12: LCD, A/D converter, or OPP sound chip.
The mapping of address lines to chips matches the address ranges and sizes:
The ROM is 32kB: $8000-$FFFF
The RAM is 2kB: RAM1 at $0800-$0FFF and RAM2 at $1000-$17FF
So double checking activity both on the inputs and outputs of IC14 and on the various signals when they reach the appropriate chips seems to suggest that address decoding is happening.
So generally, the signals on the address lines seem quite sensible on first pass (again only with an oscilloscope) but the signals on the data lines are a little odd.
Now I did read somewhere (I forget where) that if not selected and actively being driven/read then data lines will float all over the place, so it may be that an oscilloscope measurement on a single data line isn’t helping. Even though there are similar traces for all lines I’ve looked at, I probably need to trigger off the CE lines to see what is going on when the data is meant to be valid.
One other thing of note though – the data lines are pretty much fed directly into the LCD controller chip, which is a HD44780 device on a separate PCB and connected using wires. This means that all data lines are available on a connector on the edge of the PCB…
Basic clocks, reset and logical signals seem to be doing something.
Address line decoding is doing something, but data lines appear indeterminate.
So the next angle of attacks are:
Attempt to get some proper data line traces triggered off one of the chip enable pins.
Consider testing the HD44780 display independently, e.g. with an Arduino to ensure it works. If it doesn’t consider testing an off-the-shelf display instead with the DX100.
Using an Arduino (e.g. following Ben Eater’s circuit) attempt to read the ROM contents to see if they seem…. sensible. The ROM is the only IC that is socketed so that should be fairly straight forward. The ROM appears to match the pin-out of a 27C256 EPROM, which is slightly different to the 28C256 EEPROM. There is a (apparently discontinued) 29C256 that is largely pin-compatible… so some research is required here.
Getting a logic analyser on some of those address and data lines to try to see what is going on.
As I say, if it turns out to be beyond my capabilities, and I run out of people to pester, then my own project might be to hook up a Pi Zero and give it a MiniDexed inside. That should be possible to do in a non-destructive way which means at some point in the future I might be able to revisit the PCB and have another go.
I’ve finally gotten myself a Raspberry Pi 400 computer. I’ve wanted one for a while to use as a MIDI player for my Lo-Fi Orchestra. The idea is that eventually I might be able to run it without a large display, but instead use something like the Adafruit Cyberdeck and a PiTFT display (or similar) to give a nice, portable solution.
Warning! I strongly recommend using old or second hand equipment for your experiments. I am not responsible for any damage to expensive instruments!
These are the key Arduino tutorials for the main concepts used in this project:
If you are new to microcontrollers and single board computers, see the Getting Started pages.
Parts list
Raspberry Pi 400 and power.
Adafruit Cyberdeck for Raspberry Pi 400.
Adafruit 2.8″ PiTFT Plus capacitive touch LCD display (for use with a Pi 2/B+ onwards, not the original PiTFT which was just for the Pi 1).
Mouse, HDMI display, etc to set up the Raspberry Pi 400.
Raspberry Pi 400 Setup
I bought a kit so I had an SD card all ready to go with Raspberry Pi OS, so I booted that up and went through the “first run” configuration to get the basic computer up and running.
I used the command line raspi-config utility to set the hostname to something other than the default “raspberrypi”.
Then I used the add/remove software to install some interesting looking apps. There are a lot of sound and music apps including a range of soft-synths, digital audio workstations, sonic programming environments, sound and MIDI utilities, and a lot more.
For my initial purposes I wanted a command-line MIDI player, so I installed pmidi.
Then I used the Raspberry Pi configuration tool to set instruct the system to boot into the command line.
I ignored the talk of a virtual environment, and went ahead and run the suggested commands, although I cloned the Adafruit repository into a newly created tmp directory:
The suggested command uses a rotation of 90 degrees, but when I first booted everything up the display was upside down on the Cyberdeck. I had to re-run with the value rotation=270.
On first running, I was informed I was running a 64-bit kernel but a 32-bit userspace, so was asked to reboot to enable a 32-bit kernel. For what I’m planning on using this for, a 32-bit kernel should be fine so I let it reboot and run the command again.
It takes a few minutes on boot for the display to become active. If a HDMI monitor is still connected then the progress of the startup can be seen there and you can see the point where the display flickers and it switches over to the PiTFT.
Note: This just enables a text console on the PiTFT. There are separate commands to be used to enable the graphical framebuffer which will allow the desktop environment to run on the PiTFT. Full details are available in the Adafruit learning guide.
I’m also not doing anything with the touchscreen at the moment.
One nice thing about having the PiTFT in console mode is that using the ‘startx’ command will start up the desktop on any attached HDMI monitor. This gives a “best of both worlds” option, at least for me.
PiTFT GPIO Usage
The PiTFT display and touch screen use both the I2C and SPI buses, plus two additional GPIO pins. The four buttons are connected to a GPIO pin each.
The most interesting point for me here being that both RX/TX are free, so could be used for MIDI, and GPIO 18,19,20,21 are free so an I2S audio device could be added too.
Additional RPi Configuration
I’ve also enabled SSH access and the serial port using the RPi configuration tool. I’ve disabled the serial console however. As mentioned above, eventually I’d like to be able to use the serial port for a MIDI interface.
I’ve created a directory on the Pi that can be shared out. To do this requires the Samba client so using the add/remove software I’ve installed the following:
samba-2.4.13.13+… SMB/CIFS file, print and login server for Unix.
samba-common-2.4.13.13+… Common files used by both the Samba server and client.
samba-common-bin-2.4.13.13+… Samba common files used by both the Samba server and the client.
The standard install includes many CIFS utilities for mounting Windows shares already.
To configure an area for dropping files, I’ve created a directory in my home area and shared it out using samba.
pi@raspberrypi:~ $ mkdir midi
To configure samba, edit (via sudo) the /etc/samba/smb.conf file:
# Add the following at the end<br></br>[Midi]<br></br>path=/home/(user)/midi<br></br>browseable=no<br></br>writeable=yes<br></br>read only=no<br></br>create mask=0777<br></br>directory mask=0777<br></br>public=no<br></br>guest ok=no<br></br>write list=(user)
Samba also needs to be told about the user too:
pi@raspberrypi:~ $ sudo smbpasswd -a (user)
Note: I’ve disabled the sharing of the home directories by default by commenting out the [homes] line and all following commands in that section.
At this point, browsing to the share \raspberrypi will not show any visible shares (as browseable and public are set to “no”), but browsing to \raspberrypi\midi should connect to the directory on the Pi 400.
Now I can drop over MIDI files and they will be available on the Pi.
Playing MIDI files
The first thing is to find the “port number” of the MIDI interface being used.
I’ve plugged in my Roland UM-ONE and use the command “pmidi -l” to list the playable output ports as shown below.
Then pmidi can be given that port number and a MIDI file to plau and it will just get on with it.
pi@raspberrypi:~/midi $ pmidi -l<br></br> Port Client name Port name<br></br> 14:0 Midi Through Midi Through Port-0<br></br> 20:0 UM-ONE UM-ONE MIDI 1<br></br><br></br>pi@raspberrypi:~/midi $ pmidi -p 20:0 LoFi Orchestra - Carol of the Bells.mid
Here is the output of dmesg showing the UM-ONE detected displayed on the cyberdeck.
This is a great start with many of the building blocks in place. There are some issues though – sometimes it seems to “forget” to use the cyberdeck and I have to re-run the install script with a monitor attached. I don’t know what is causing that so naturally that isn’t any good for a proper solution.
But as can be seen in the video at the start of this post, in general, this seems to work!
Next steps:
Fix the issue naturally!
It would be nice to find a way to automatically select any plugged in MIDI interface when it comes to playing a file.
It would be nice to have some kind of application running to list files and play them.
I’d like to have a RPI400 MIDI interface that I can use directly too. Perhaps some variant of my Raspberry Pi Zero MIDI PCB.
It is 3V3 compatible for use with the Raspberry Pi but the 74HCT14 acts as both a buffer and level shifter so that the MIDI OUT and THRU portions of the circuit present a 5V MIDI design to the outside world. This means that the HCT variant of the 74HCT14 is required, not the HC version. It also means that the H11L1 is powered from 3V3 and the 74HCT14 from 5V.
The schematic itself allows for the use of either TRS (Type A) or DIN MIDI sockets.
I did consider the idea of detachable MIDI DIN sockets too (the schematic includes both) but in the end opted for simplicity and went just with TRS. That option is reserved for a future edition should I wish.
It can’t be seen in the PCB view above, but there is actually a missing link that I’ve missed off when routing the board (the perils of have silkscreen overlaps and elements in your schematic unused in the PCB is not probably paying attention to the DRC…). The 74HCT14 should have pins 2 and 3 tied together, but no link was included. A simple solder bridge should suffice.
This is my Lo-Fi Orchestra performance of the Carol of the Bells, heavily based on Robert Buckley’s amazingly rhapsodic arrangement of the carol entitled “Let the Bells Ring”.
Taking a typical “low to high” soldering approach, this is the suggested order of assembly:
Disc capacitors.
Button switches.
GY-PCM5102 module (if used).
4-way header for display.
GPIO header.
Rotary encoder.
Build Options:
With DAC: As described below with a GY-PCM5102 module on the board. The display will have to be fitted in a 4-way header socket and raised above he PCM5102 once fitted.
External I2S DAC: It is possible to use something like the Pimoroni Audio DAC SHIM between the Zero and the MiniDexed IO board. More details here: A DX7 USB Dongle.
Note: in the case where the SSD1306 is soldered directly to the board, e.g. if no PCM5102 is used, the 100nF ceramic capacitor for its supply pins will have to be bent over flat prior to mounting the display.
The key elements of the minidexed.ini configuration required to support this board are as follows.
# If in USB Gadget mode - see <a href="https://diyelectromusic.wordpress.com/2023/11/22/a-dx7-usb-dongle/">A DX7 USB Dongle</a>.<br></br>USBGadget=1<br></br><br></br># Either pwm or i2s<br></br>SoundDevice=i2s<br></br><br></br>LCDEnabled=1<br></br>SSD1306LCDI2CAddress=0x3C<br></br>SSD1306LCDWidth=128<br></br>SSD1306LCDHeight=32<br></br>SSD1306LCDRotate=1<br></br>SSD1306LCDMirror=0<br></br>LCDColumns=20<br></br>LCDRows=2<br></br><br></br>ButtonPinPrev=0<br></br>ButtonActionPrev=<br></br>ButtonPinNext=0<br></br>ButtonActionNext=<br></br>ButtonPinBack=5<br></br>ButtonActionBack=click<br></br>ButtonPinSelect=11<br></br>ButtonActionSelect=click<br></br>ButtonPinHome=6<br></br>ButtonActionHome=click<br></br>ButtonPinShortcut=11<br></br><br></br>EncoderEnabled=1<br></br>EncoderPinClock=10<br></br>EncoderPinData=9
Closing Thoughts
Whilst it is somewhat irritating to have made the 10p/10n mistake yet again, I’m quite pleased with how these boards have come out.
I have a stackable TRS MIDI interface in the works too which should be able to work with this IO board too.
This is a bit of an odd one, but I was asked to put something musically related together as a game to get in the spirit of the season, so I thought something along the lines of an Arduino adjustable tone generator with the aim being the player has to tune it by ear to as close to concert A – 440Hz – as possible.
This shows how I used my Nano Audio Experimenter Sheild PCB to do it. Note, as with most of my builds, this isn’t particularly mechanically satisfying, but it did the job 🙂
Warning! I strongly recommend using old or second hand equipment for your experiments. I am not responsible for any damage to expensive instruments!
These are the key Arduino tutorials for the main concepts used in this project:
The frequency is set using all three pots. This gives a lot more variability as a game than using a single pot. The OLED display is used to show the frequency once it has been chosen. This happens while the switch is pushed.
The Arduino tone function will be used, which provides a 0-5V DC biased square wave output. Sending this through the audio filter and output stage means that the voltage is reduced (via the resistor potential divider) and the DC bias is removed (via the coupling capacitor) so it can be used as a more typical audio line output and connected to an old amp or similar.
There are a number of options where a GPIO pin is available via a header which can then be used to connect to a simple push switch:
Top: D9 is exposed in the PWM output jumper (which is set to select D3).
Far Right: D4-6 are exposed for use with an analog multiplexer.
Right: D7 is also exposed both in the jumper that can be used to set the behaviour of S4 and (assuming the jumper is actually set to make the link) D7 becomes exposed on the far right header too.
Far Right: A3 is also exposed on the far right header and so could also be used if required.
The downside of all of these is that my ready-made board requires header pin sockets which isn’t particularly robust for a game.
Advanced Option
But then I realised there is one additional pin exposed in a way that could still be used as an input but with a far more robust connector. D1 (TX) is linked to the MIDI OUT 5-pin DIN socket too, albeit via a 220Ω resistor. This means that I also have the option of connecting a switch across a 5-pin DIN Socket’s pins 2 (GND) and 5 (TX) and using that instead. The 5 pin DIN socket makes a much stronger and robust connection to the board, even if it is a little unconventional.
WARNING: The switch must NOT be connected between pins 4 and 5, which are the normal MIDI connections or from pin 4 to GND. Depending on the configuration used, there is a risk of connecting 5V to GND in the Arduino Nano and shorting something out. You might get away with it, depending on which resistors you end up having in the circuit (5V / 220Ω is just under 30mA), but it is really important to double checking the wiring before use!
Here is a “from the front/plug side” and “from the back/wiring side” view of a 5-pin DIN plug showing which pins are 5 and 2.
RX isn’t an option as a populated MIDI circuit has an optoisolator between the external DIN socket and the GPIO pin.
Of course if a new PCB is being used, the MIDI section can be left unpopulated and it would then be possible to directly connect one of the MIDI sockets to either RX or TX. But for this project I’m just planning on reusing my generic, fully populated board, hence RX is not an option.
The Code
The basic tone generation is simply the Arduino tone function (more here). The frequency is a simple sum of the three potentiometers giving a range from 0 up to 3069. In musical terms this spans the range of notes from A0 (and lower) almost up to G7 (just over 3kHz).
Once the choice of frequency has been made, by ear alone, the button can be pressed and the display used to show both the frequency chosen and the numerical difference from 440Hz. The winner is the person closest to 440Hz.
To add an additional feeling of skill, but in reality to add a dose of luck, I’ve added two decimal points in the display which are actually randomly chosen each time the button is pressed. The idea being that if two players both get a pretty close 440Hz then the winner is essentially selected by random!
In order to avoid having to do decimal arithmetic in the code however, when calculating the difference I’m multiplying the frequency by 100, adding in the (random) decimal as if it was just a number between 0 and 99 and then comparing the result to 44000.
D3 is selected as the audio output and D4 is selected as the trigger button for the display using the following two lines:
int SPEAKER = 3;<br></br>int TRIGGER = 4;
Additional notes from the code:
I’ve implemented a software smoothing algorithm for the reading of the potentiometers in an attempt to remove some jitter. Although again a small amount of jitter brings another element of luck into the game.
When printing out, I have to take care of blank spaces in the frequency to keep the decimal point aligned for anything from 1 to 4 digits; but also have to allow for an extra leading zero in the case of randomly selecting a decimal in the range 0.01 to 0.09.
I’m using the Adafruit GFX and SSD1306 libraries for the Arduino.
When the button is pressed, the display changes to show the frequency. When it is released the frequency is hidden again.
This was a bit of a diversion and I could have easily knocked something up from solderless breadboard or stripboard with some pots and a display. But being able to just grab the PCB and experiment with the code made putting it together pretty easy.
The amazing Rene Stange added USB Gadget (i.e. device) support to the Circle bare metal Raspberry Pi environment a while ago so I’ve now incorporated that into MiniDexed. This allows MiniDexed to be used as a USB device – i.e. it can just be plugged into a PC and used via USB MIDI directly, as long as your Raspberry Pi supports USB Gadget mode and you have some means of audio output.
This post looks at how to make a “USB dongle” that is basically a USB MIDI accessible DX7.
A quite note before I start however. Why would someone want to do this? There are several VST DX instruments for PCs if you want DX sounds in your DAW and Dexed itself gives you full access to a DX7 via a software interface.
So there is probably very little practical reason to do this. But personally, I just couldn’t resist the idea of having a plug-in DX7 on a USB stick!
If you are new to microcontrollers and single board computers, see the Getting Started pages.
Parts list
Raspberry Pi Zero, Zero W or Zero W2.
I2S or alternative audio output for a Pi Zero.
USB “STEM”, “Zero Dongle” or other USB device connection (micro USB to USB A).
Note: the Pi Zero and Zero W will give access to a single MiniDexed tone generator. The Pi Zero W2, will support 8 tone generators.
Warning: When using a Raspberry Pi in USB Gadget mode, do not plug in its usual power supply! It should be USB “bus powered” only.
The Hardware
Whilst any Raspberry Pi that supports USB Gadget mode could be used with a suitable lead to power and link to MiniDexed, to make a USB “dongle” requires the use of a Pi Zero (any flavour) and a “dongle style” add on.
It will also need a means of outputting audio from the Zero as MiniDexed only supports USB MIDI, not USB audio.
There are several options for audio out on a Pi Zero. By far the easiest is some kind of off-the-shelf I2S audio interface.
A really good, low-profile one ideal for use as a dongle is the Pimoroni Audio SHIM, which can be found here. It doesn’t even need soldering, it can push-fit over the Pi’s GPIO headers, but any I2S audio interface for the Pi can be used as long it doesn’t interfere with the USB plug for the “dongle”.
My ideal combination is the USB STEM and the Pimoroni Audio SHIM as it is both low-profile and has the USB plug at one end and the audio output at the other.
Hopefully by the time you read this, USB Gadget support in MiniDexed will be merged into the main code (it is PR567). Details of how to configure it can be found on the wiki here, but the key MiniDexed configuration (minidexed.ini) required for this configuration is as follows:
USBGadget=1SoundDevice=i2s
The rest of the configuration is largely ignored, but things like the LCD, buttons and encoder can simply be disabled (set to 0) as they are not required.
A Single DX7
As mentioned previously if using a Zero V1/W then a single tone generator is available. The MIDI channel it uses will be as defined in the default performance.ini file. It is set to OMNI by default. To change it, change:
MIDIChannel1=<MIDI channel 1 to 16>
The default MIDI configuration for MiniDexed assumes voice changes will be made with a combination of bank select Control Change and Program Change messages with each bank containing 32 voices. But the following configuration allows four banks to be spread across all 128 Program Change values:
ExpandPCAcrossBanks=1
When plugged into a PC it will come up as “MIDI Gadget” as a USB MIDI compatible device. Here it can be seen in MidiOx, being selected as the MIDI output.
I have a MidiOx instrument file with all the voices for Roms 1a/1b/2a/2b/3a/3b/4a/4b selectable via Bank Select messages, and Roms 1a+1b+2a+2b configured for use as a single 128-voice bank via Program Change messages.
Find it on GitHub here. This needs to be copied to the “instr” directory of the MidiOx installation.
In MidiOx, View -> Instrument Panel, select “INS File: DX7ROMS.INS” and then choose one of the following for “instr”:
“YAMAHA DX7 ROMS” for the individually selectable 8 ROMs.
“YAMAHA DX7 VOICES” for the first four ROMs to be linked as a 128-voice single bank.
Both views (and voice selections) are shown below.
If using a Zero 2W then 8 tone generators are available. In that case there is a choice. It can be treated as eight independent tone generators, in which case the MIDI channels for each TG should be set independently.
The following configures TGs 1-8 for MIDI channels 1-8.
At this point, the MIDI interface is the same as before, but changing the MIDI channel will change the tone generator being used.
Alternatively, it is possible to now treat the 8-way TG MiniDexed as a single instrument with much more complex sounds.
If the following setting is enabled in minidexed.ini:
PerformanceSelectChannel=1
This will interpret Program Change messages on MIDI channel 1 as selecting “performances”. Each “performance” is a configuration of up to 8 tone generators with a range of voices and effets.
At present, MiniDexed loads performances into consecutive “slots” meaning that the numbers in the MiniDexed repository do not relate to the “patch numbers” used over MIDI. The MIDIOx file supports the files in the repository at the time of writing. If new performances are added in some of the gaps (and there are gaps) in the numbering, then the names will be out of sync with what is installed.
Personally I think we need to change this and make the numbers relate to the MIDI program numbers. Watch this space!
Closing Thoughts
As mentioned in the introduction, with a good selection of software synths available that provide a DX7 on a computer for use with a DAW, there is limited use for a “DX7 on a USB stick”.
But I still think this is a pretty neat thing to be able to do, if nothing else, just for the fun of knowing that a $2000 synth from the 1980s can now be replicated with ~$20 worth of hardware that can be plugged into any PC and just “played”.