Dx7 Patches
32 patches by MGF Audio. Due to Dexed's DX-7 compatibility, you can also load these into your Yamaha or NI's FM8. Sounds range from bass, pads, leads and effects and aim for a modern touch. Download (2.2 KB). Purchase our DX7/TX7 synth patches by clicking on the ADD TO CART buttons. After your payment has been securely processed, you can download the patches, contained in ZIP files. ManyMIDI - 4009 DX7 Synth Patches (SysEx format) Set #1 (All except Percussion/FX) - $29.95.
Ted Felix
I finally got myself a DX7. The story begins for me back in High School in 1985. The keyboardist in a band I was in had a DX7 and left it at my house for a weekend along with the manual. I started programming it and was hooked. Haven't touched one since then. Fast forward to August 2012, and I own one. Bought it locally via Craigslist. Only one previous owner (and his father). Came with a TSA approved case and a two bank RAM cartridge. And, unfortunately, a finicky E! Grey Matter Response upgrade.
E! Problems
The keyboard worked fine at first, although it seemed strange that the last half (patches 17-32) of a couple of the banks in the internal E! memory had garbage in them. I figured it was just a fluke, so I backed up the banks and then filled them back up with the factory ROMs. This seemed to work fine. But then after letting the keyboard sit for a few days, I turned it on and the last half of several of the banks was garbage. Time to take it apart and see what's going on.
The previous owner had had it worked on to replace the battery. I'm guessing the battery wasn't actually bad. Instead, the memory was going just like it was for me. Turns out the E! card was not fully seated into the main board. In fact, the design of the E! card precludes it being fully seated. The pins aren't long enough to be inserted completely into the ROM socket on the mainboard and this lifts the pins that go into the SRAM socket. I haven't come up with a clever solution for this yet.
Additional symptoms of a loose E! board are mainly refusal to boot with displays ranging from '88' on the LED display and a row of blocks across the LCD to random segments lighting on the LED display.
Going Back To Stock
I decided to revert back to the original stock setup, but this DX7 didn't come with its original pre-E! chips. Fortunately, there are plenty of resources for DX7 repair on the Internet. Installing the E! card requires pulling IC14 and IC21. So, going back to stock means replacing them.
IC14 - Firmware ROM
IC14 turns out to have been a Toshiba TMM24128AP (16Kx8bit ROM). On ebay you can find folks selling a 'Special Edition' (SER-7) version of this ROM for the DX7. I also found that a .bin file of the original DX7 ROM (v1.8) is available in the YamahaDX Yahoo group's file collection. If you ask nicely, one of the ROM sellers on ebay will be more than happy to burn that .bin image to a ROM for you. I now have both the SER-7 special edition ROM and the original v1.8 DX7 ROM.
IC21 - Static RAM
IC21 is one of the three SRAM chips on the mainboard that comprise the internal memory. It is a Mitsubishi M5M5118P-15L (2Kx8bit SRAM). These can be found on ebay for around $10. I got one on ebay and it is working perfectly.
Reboot
At power on, the DX7 realized its static RAM was filled with garbage so it prompted for a cart to be inserted. Apparently it will initialize itself from a cart after the battery is replaced. Unfortunately, the only cart I had was E! formatted, so it didn't recognize it. Always be prepared with a cart when replacing the battery. It turned out that bank B on my RAM cart was properly DX7 formatted, so I copied that into the internal memory and all was fine. I probably could have initialized it from MIDI also, but I didn't try that.
Success
Now my DX7 works perfectly. The two-bank memory card that I have is more than enough to allow me to load up banks from the Internet, pick the best voices, and copy them to the memory card. When a memory card bank is full, I copy back to the internal memory and dump to the computer for backup. With the original chips in place, I've had no trouble at all with the DX7. Occasionally, a bank from the Internet will crash it. Also, it has trouble handling certain MIDI messages. But then the DX7 MIDI implementation was always a bit weak as it predated the MIDI standard.
Sysex And Patches
The DX7 can transfer patches back and forth via sysex. See page 56 in the manual for instructions for configuring the DX7 to send/receive. (Function 8, set MIDI channel to 1, and SYSINFO to AVAIL. Then turn off memory protection for internal memory. Make sure you back it up first.) There are many tools for transferring sysex to/from a computer. In Linux, amidi is the command line tool for this. Here's how to send a .syx file:
When using amidi to receive sysex data, I noticed an extraneous 3 bytes on the front of the file (B0 60 7F). I think this is me pressing the OK button on the DX7 to start the transfer. I remove the three bytes with ghex, and the bank works fine. Using tail works fine too:
Originally I was using 'cat' to record sysex in Linux. This turns out to be a bad idea as it captures the 'Active Sensing' (keep-alive) FE bytes on the line. I used a hex editor (ghex) to remove the FE bytes from the front and end of the sysex dumps. This leaves me with a 4104 byte file for each bank. amidi does not have this problem so I recommend avoiding cat.
dx7dump
My little command line utility for Linux will turn a DX7 sysex dump into something you can read at the dinner table. Sure could've used this back in 1985...
dx7dump - Formats DX7 sysex files into human readable text.
Sample output:
The parameters are organized the same way they are on the DX7's front panel. This makes it easy to enter a patch from this listing. Only one parameter is on each line to make it easier to compare patches using diff (or meld). A more vertically compact format could be developed. Feel free to branch and develop.
'Not enough bytes' - If you build dx7dump in Windows, you'll likely see this message. This is because Microshaft's C 'standard' library opens files in 'text mode' which translates any CRLF's it finds into LF's, thus making the file smaller (and completely trashing it in the process). It also stops reading when it encounters the first 0x1A (Ctrl-Z, end of file). The fix is to link in binmode.obj which defaults fopen() to opening files in binary mode. (One could also change the fopen() mode to 'rb' or use _set_fmode(_O_BINARY). Since 'b' is explicitly ignored in Linux, we can probably go with it.)
Velocity Sensitivity
I've come to the conclusion that the velocity sensitivity on the DX7 is quite poor. Yamaha appears to agree with me as their ROM patches generally have the velocity sensitivity set to 3 or less. I assume the issue is the age of the technology. In 1983 there was a limit to how fast you can scan a keyboard. That limit translates into reduced velocity sensitivity. However, I think that with a velocity curve that better matched the numbers coming from the keyboard, the DX7 might have performed better. As it is, setting the velocity beyond 3 seriously reduces the output range of an operator.
A quick count of the number of operators on each ROM that use a specific velocity reveals that my suspicion is correct. Velocities above 3 are of limited value. Of the 797 operators with a velocity of 1 or greater, the majority (559 or 70.1%) use a velocity between 1 and 3.
This chart shows a count of the operators that use a specific velocity value in each of the Yamaha factory ROMs.
| Velocity | ROM 1A | ROM 1B | ROM 2A | ROM 2B | ROM 3A | ROM 3B | ROM 4A | ROM 4B | Total |
|---|---|---|---|---|---|---|---|---|---|
| 0 | 90 | 87 | 95 | 136 | 79 | 59 | 88 | 105 | 739 |
| 1 | 28 | 28 | 35 | 15 | 19 | 18 | 34 | 21 | 198 |
| 2 | 36 | 30 | 26 | 17 | 28 | 39 | 26 | 31 | 233 |
| 3 | 13 | 20 | 11 | 9 | 17 | 26 | 17 | 15 | 128 |
| 4 | 2 | 7 | 5 | 6 | 15 | 28 | 8 | 10 | 81 |
| 5 | 5 | 2 | 7 | 2 | 8 | 6 | 8 | 1 | 39 |
| 6 | 4 | 2 | 1 | 1 | 7 | 5 | 1 | 1 | 22 |
| 7 | 14 | 16 | 12 | 6 | 19 | 11 | 10 | 8 | 96 |
Note the spike at velocity 7. It would be interesting to track those patches down and find out how those 7's are used.
Patch Editors?
I need to track down a good patch/bank editor. Especially now that I only have three total banks of memory without the E! upgrade. Some to try:
JSynthLib sounds the most promising right now. Although its UI is a bit hard to get used to. It's free (as in GPL) and cross-platform (as in Java, hence the 'J').
FM-Alive's DXM3 is a patch editor for Windows for a fee.
Links
SER-7 Info - Direct from Yamaha. You can still order these on ebay.
Dave Benson's DX7 Page - Great starting point. Manuals, sounds, etc...
Yahoo's YamahaDX Group - Lots of info and files and folks to talk to. This is where you'll find the ROM image for IC14.
Steve Sims - DX7 Rhodes patch is fantastic.
Hexter - Excellent DX7 emulator for Linux. Plays the real patches and sounds like the real thing.
Bristol - DX7 (and others) emulator for Linux. Really nifty as it brings the parameters to the front panel as knobs, making programming and experimenting really easy. This is not a complete DX7 simulation, but it is fun to play with. It's a tad buggy. Would be nice if they would use hexter as the backend.
Native Instruments' FM8 - Professional FM synth for Windows. Pretty pricey.
<- Back to my Technology page.
Copyright ©2012, Ted Felix.DisclaimerTed Felix
I finally got myself a DX7. The story begins for me back in High School in 1985. The keyboardist in a band I was in had a DX7 and left it at my house for a weekend along with the manual. I started programming it and was hooked. Haven't touched one since then. Fast forward to August 2012, and I own one. Bought it locally via Craigslist. Only one previous owner (and his father). Came with a TSA approved case and a two bank RAM cartridge. And, unfortunately, a finicky E! Grey Matter Response upgrade.
E! Problems
The keyboard worked fine at first, although it seemed strange that the last half (patches 17-32) of a couple of the banks in the internal E! memory had garbage in them. I figured it was just a fluke, so I backed up the banks and then filled them back up with the factory ROMs. This seemed to work fine. But then after letting the keyboard sit for a few days, I turned it on and the last half of several of the banks was garbage. Time to take it apart and see what's going on.
The previous owner had had it worked on to replace the battery. I'm guessing the battery wasn't actually bad. Instead, the memory was going just like it was for me. Turns out the E! card was not fully seated into the main board. In fact, the design of the E! card precludes it being fully seated. The pins aren't long enough to be inserted completely into the ROM socket on the mainboard and this lifts the pins that go into the SRAM socket. I haven't come up with a clever solution for this yet.
Additional symptoms of a loose E! board are mainly refusal to boot with displays ranging from '88' on the LED display and a row of blocks across the LCD to random segments lighting on the LED display.
Going Back To Stock
I decided to revert back to the original stock setup, but this DX7 didn't come with its original pre-E! chips. Fortunately, there are plenty of resources for DX7 repair on the Internet. Installing the E! card requires pulling IC14 and IC21. So, going back to stock means replacing them.
IC14 - Firmware ROM
IC14 turns out to have been a Toshiba TMM24128AP (16Kx8bit ROM). On ebay you can find folks selling a 'Special Edition' (SER-7) version of this ROM for the DX7. I also found that a .bin file of the original DX7 ROM (v1.8) is available in the YamahaDX Yahoo group's file collection. If you ask nicely, one of the ROM sellers on ebay will be more than happy to burn that .bin image to a ROM for you. I now have both the SER-7 special edition ROM and the original v1.8 DX7 ROM.
IC21 - Static RAM
IC21 is one of the three SRAM chips on the mainboard that comprise the internal memory. It is a Mitsubishi M5M5118P-15L (2Kx8bit SRAM). These can be found on ebay for around $10. I got one on ebay and it is working perfectly.
Reboot
At power on, the DX7 realized its static RAM was filled with garbage so it prompted for a cart to be inserted. Apparently it will initialize itself from a cart after the battery is replaced. Unfortunately, the only cart I had was E! formatted, so it didn't recognize it. Always be prepared with a cart when replacing the battery. It turned out that bank B on my RAM cart was properly DX7 formatted, so I copied that into the internal memory and all was fine. I probably could have initialized it from MIDI also, but I didn't try that.
Success
Now my DX7 works perfectly. The two-bank memory card that I have is more than enough to allow me to load up banks from the Internet, pick the best voices, and copy them to the memory card. When a memory card bank is full, I copy back to the internal memory and dump to the computer for backup. With the original chips in place, I've had no trouble at all with the DX7. Occasionally, a bank from the Internet will crash it. Also, it has trouble handling certain MIDI messages. But then the DX7 MIDI implementation was always a bit weak as it predated the MIDI standard.
Sysex And Patches
The DX7 can transfer patches back and forth via sysex. See page 56 in the manual for instructions for configuring the DX7 to send/receive. (Function 8, set MIDI channel to 1, and SYSINFO to AVAIL. Then turn off memory protection for internal memory. Make sure you back it up first.) There are many tools for transferring sysex to/from a computer. In Linux, amidi is the command line tool for this. Here's how to send a .syx file:
When using amidi to receive sysex data, I noticed an extraneous 3 bytes on the front of the file (B0 60 7F). I think this is me pressing the OK button on the DX7 to start the transfer. I remove the three bytes with ghex, and the bank works fine. Using tail works fine too:
Originally I was using 'cat' to record sysex in Linux. This turns out to be a bad idea as it captures the 'Active Sensing' (keep-alive) FE bytes on the line. I used a hex editor (ghex) to remove the FE bytes from the front and end of the sysex dumps. This leaves me with a 4104 byte file for each bank. amidi does not have this problem so I recommend avoiding cat.
dx7dump
Free Dx7 Patches
My little command line utility for Linux will turn a DX7 sysex dump into something you can read at the dinner table. Sure could've used this back in 1985...
dx7dump - Formats DX7 sysex files into human readable text.
Sample output:
The parameters are organized the same way they are on the DX7's front panel. This makes it easy to enter a patch from this listing. Only one parameter is on each line to make it easier to compare patches using diff (or meld). A more vertically compact format could be developed. Feel free to branch and develop.
'Not enough bytes' - If you build dx7dump in Windows, you'll likely see this message. This is because Microshaft's C 'standard' library opens files in 'text mode' which translates any CRLF's it finds into LF's, thus making the file smaller (and completely trashing it in the process). It also stops reading when it encounters the first 0x1A (Ctrl-Z, end of file). The fix is to link in binmode.obj which defaults fopen() to opening files in binary mode. (One could also change the fopen() mode to 'rb' or use _set_fmode(_O_BINARY). Since 'b' is explicitly ignored in Linux, we can probably go with it.)
Velocity Sensitivity
I've come to the conclusion that the velocity sensitivity on the DX7 is quite poor. Yamaha appears to agree with me as their ROM patches generally have the velocity sensitivity set to 3 or less. I assume the issue is the age of the technology. In 1983 there was a limit to how fast you can scan a keyboard. That limit translates into reduced velocity sensitivity. However, I think that with a velocity curve that better matched the numbers coming from the keyboard, the DX7 might have performed better. As it is, setting the velocity beyond 3 seriously reduces the output range of an operator.
A quick count of the number of operators on each ROM that use a specific velocity reveals that my suspicion is correct. Velocities above 3 are of limited value. Of the 797 operators with a velocity of 1 or greater, the majority (559 or 70.1%) use a velocity between 1 and 3.
This chart shows a count of the operators that use a specific velocity value in each of the Yamaha factory ROMs.
| Velocity | ROM 1A | ROM 1B | ROM 2A | ROM 2B | ROM 3A | ROM 3B | ROM 4A | ROM 4B | Total |
|---|---|---|---|---|---|---|---|---|---|
| 0 | 90 | 87 | 95 | 136 | 79 | 59 | 88 | 105 | 739 |
| 1 | 28 | 28 | 35 | 15 | 19 | 18 | 34 | 21 | 198 |
| 2 | 36 | 30 | 26 | 17 | 28 | 39 | 26 | 31 | 233 |
| 3 | 13 | 20 | 11 | 9 | 17 | 26 | 17 | 15 | 128 |
| 4 | 2 | 7 | 5 | 6 | 15 | 28 | 8 | 10 | 81 |
| 5 | 5 | 2 | 7 | 2 | 8 | 6 | 8 | 1 | 39 |
| 6 | 4 | 2 | 1 | 1 | 7 | 5 | 1 | 1 | 22 |
| 7 | 14 | 16 | 12 | 6 | 19 | 11 | 10 | 8 | 96 |
Note the spike at velocity 7. It would be interesting to track those patches down and find out how those 7's are used.
Patch Editors?
I need to track down a good patch/bank editor. Especially now that I only have three total banks of memory without the E! upgrade. Some to try:
Dx7 Patches For Digitone
JSynthLib sounds the most promising right now. Although its UI is a bit hard to get used to. It's free (as in GPL) and cross-platform (as in Java, hence the 'J').
FM-Alive's DXM3 is a patch editor for Windows for a fee.
Links
SER-7 Info - Direct from Yamaha. You can still order these on ebay.
Dave Benson's DX7 Page - Great starting point. Manuals, sounds, etc...
Yahoo's YamahaDX Group - Lots of info and files and folks to talk to. This is where you'll find the ROM image for IC14.
Sysex Dx7 Patches
Steve Sims - DX7 Rhodes patch is fantastic.
Hexter - Excellent DX7 emulator for Linux. Plays the real patches and sounds like the real thing.
Bristol - DX7 (and others) emulator for Linux. Really nifty as it brings the parameters to the front panel as knobs, making programming and experimenting really easy. This is not a complete DX7 simulation, but it is fun to play with. It's a tad buggy. Would be nice if they would use hexter as the backend.
Native Instruments' FM8 - Professional FM synth for Windows. Pretty pricey.
<- Back to my Technology page.