Received a good question from Andy P. today, asking about the current draw for the OLEDs keeping in mind the DX7 has a very old power supply.**
MTG DX7 OLRD
Here are some numbers I came up with for a limited, but representative, sampling of what I have on hand. These are actual current measurements, not voltage drop across diode measurements.
- Original non-backlit LCD … 1mA
- Yamaha’s updated backlit LCD … 24mA
- My drop-in replacement backlit LCDs … 18mA
- My drop-in replacement OLEDs … 21mA to 26mA
So I guess that the drop-in backlit LCDs save a little bit of power over the original and the OLEDs are about the same or maybe a few mA more. It should be noted that Yamaha offered the backlit kit for non-backlighted DX7’s for around $100USD back in the day. So I think we can conclude that the original DX7 had enough reserve current handling capacity for and additional 20-something mA at least.
** I haven’t had to rebuild any of these power supplies yet, but I have seen SXP90’s and DX7S’s that definitely stopped functioning due to power supply issues.
I’m having surgery this week. Soldering and programming to resume as soon as I’m able, but I imagine that’s many weeks away. Here’s my surgeon doing the same procedure. Eeek.
I retrieved some old embedded fun I had in the 90’s off an old disk. More to come at some point once I find the other disk. Anyway this is a recreation of an old website I had. Retro fun.
If you are in the UK or EU (ouch), here is a source for a DIY MIDI IN/OUT/THRU bare PCB that can be used with the TurboCPU. No DAC option, but otherwise it’s pretty similar to the MTG MIDI board. Two wires need to be flipped and a couple parts I substituted with my preferred values, but it’s the only viable TTL-to-MIDI board I’ve seen anywhere that sticks to the spec just like the MTG one does. All the Arduino one’s I’ve seen suck.
Here is the bare board:
Here is the schematic:
Here it is connected to a test setup on my bench:
Alternate MIDI Board
Power (red) and ground (black) go “straight through”, but the Tx/Rx data lines need to be crossed (yellow, blue). I also changed a few components. Here is the parts list I used:
R1, R2 470R Make sure to use high efficiency LEDs
R4 - Not used, leave empty
R5 to R9 220R
IC2 6N137 Different IC than the schematic!
Also refer to the TurboCPU Installation instructions for more guidance such as wiring the jacks.
This one isn’t a huge bug, but anyone with an original DX7 running OS version 1.7 or earlier (on an expander based on it) can see this bug. If you edit a patch and set an oscillator mode for Fixed Frequency, you can see that the display shows the frequency table is corrupted in one place.
The table should go (for example with a starting freq of 100Hz):
166.0Hz -> 169.8Hz -> 173.8Hz -> 177.8Hz
but the buggy version has this:
166.0Hz -> 169.8Hz -> 133.8Hz -> 177.8Hz
DX7 v1.8 and later has fixed the table bug
It sure would be nice to find some Yamaha Service Notes with information on the changes from one version to the next. Also this version boots significantly slower. All the expansions I’m selling either have these both fixed or were not affected by them.
DX7 v1.7 and earlier has this table bug
While looking into the DX7 and some of the expansions for it, I needed a way to capture all the possible velocities that a given MIDI keyboard could put out. Not all of them send all 127 possible velocities.
I threw together a quick PC application to show and log them. Here is the main form of said application:
MIDI Velocity Test results for the Oxygen 8 controller
Here is a link to the software. I may continue to update it, not sure. If you have issues with it let me know. It’s a Windows 32-bit application and I’ve tested it on Win8.1 .
A lot of comments, cliche’s, criticisms and chit-chat exists about the original DX7 Velocity limitations. I will address a few of those, mainly from the perspective of someone looking at the underlying code. It’s another level of fun for someone sitting or standing in front of one and playing it.
NOTE: This is only about the MIDI-OUT, I’m not commenting here about the internal sounds. That’s another matter, albeit related somewhat.
Original DX7 Velocity Curve
The curve. This is what the DX7 MIDI-OUT Note-On velocity curve is supposed to look like and it does. Almost. The X axis (horizontal) is the time it takes for the key travel and the Y axis (vertical) is the resulting MIDI Note-On velocity. So, to the left we see very quick key travel meaning high velocity. As you go to the right you see slower key travel and lower velocity. It looks like a piece-wise approximation of a curve but I have not figured out the math for the curve at this point.
First thing you notice is 32 points. That’s it. That’s the resolution of the DX7’s MIDI Note-On velocity. And that also includes 0 (zero) AKA Note-Off. What’s interesting as I look at the BIN files for the various versions (I don’t have them all) is that the OS code is buggered. The $7F value cannot be accessed by the code. Impossible. It’s a glaring bug. I think the highest the code will allow is something like $7B, but in order to achieve that you need a hammer almost.
I can see this behaviour in firmware versions 1.7 and 1.8 of the Mark I DX7.
FWIW, I think the DX7S has a 64-byte table and the DX7II has a 128-byte table. I haven’t done a lot of work on those yet as I don’t have either keyboard.
I am planning on fixing this as much as I can in the expansions that I sell. Two of them, the DX7 4X EXP and DX7 8X EXP have a Velocity Offset setting that can add a value to the table value I’ve been discussing. This solves the major issue and the one most people are familiar with, that it’s hard to get the upper values. As they say, “you can’t get much above 100”.
While peeking around at the various DX7 firmware versions I was able to identify the code that is responsible for the DX7 transmitting $FE (MIDI Active Sensing) constantly. I did not have the time to look at adding a menu item for it, so I just disabled it. If anyone is disgruntled by the DX7 sending MIDI $FE (Active Sensing) then this will alleviate your pain.
This link points to the updated v1.8 firmware that I renamed v1.8a:
This link points to the updated Special Edition ROM firmware, SER7, that I renamed SER7a:
One other issue that kind of irked me about the DX7 is the burst of MIDI Note-Off events and controller settings that occur at power on. I haven’t had time to sort that out yet.
The Hitachi 6303 is a variation on the Motorola MC6800/6801/6803 Motorola microprocessors and microcontrollers from the late 70’s and early 80’s. I have an interest in reverse engineering embedded systems from that era. Previously I have created a 6809 EPROM Monitor program called Micro09 and later a variation call Micro11 for the Motorola 68HC11. The latter is still available on the web in a few places. This new one, Micro6303, is basically the same beast, except for the 6303.
Micro6303 Main Menu
In all cases the idea of a Monitor is to create a development OS of sorts that can run on a minimal hardware setup. A serial port is used for communication with the embedded system and a timer is used for single-stepping code. The HC11 and 6303 have the timer and Serial Communications Interface on the chip, so that simplifies the hardware required to bring a system “up”. But still quite a few components are required compared to today’s flash microcontrollers.
Micro6303 CPU Window
Anyway, without further adieu, here are some screen shots of the Micro6303 EPROM Monitor including the Cold Boot screen, the Main Menu and the CPU Window which is the facility for single-stepping and setting breakpoints. It is a work in progress and I will release binaries in the near future.
This is a kit loosely based on the R50iii that was a factory modified/upgraded R50 or R50e. The factory had the advantage of starting with new blank circuit boards which current R50 owners do not. Still, this expansion is pretty easy to install except for 3 wires that do need to be soldered by a steady hand.
MTG Kawai R50 3x
MTG Kawai R50 3x expansion board