[HN Gopher] Reverse-engineering the Yamaha DX7 synthesizer's sou...
       ___________________________________________________________________
        
       Reverse-engineering the Yamaha DX7 synthesizer's sound chip from
       die photos (2021)
        
       Author : throwup238
       Score  : 72 points
       Date   : 2024-01-11 12:30 UTC (1 days ago)
        
 (HTM) web link (www.righto.com)
 (TXT) w3m dump (www.righto.com)
        
       | aamargulies wrote:
       | Grey Matter Response reverse-engineered the DX7 with a logic
       | probe to create their E! product:
       | 
       | https://www.muzines.co.uk/articles/grey-matter-response-e/20...
       | 
       | E! was so good that Yamaha suspected them of industrial
       | espionage.
       | 
       | A logic probe.
        
         | ajxs wrote:
         | Reverse-engineering a binary is hard enough in 202x with modern
         | tooling. Doing what they did back in the 80s is truly
         | impressive!
        
       | mmastrac wrote:
       | Ken, if you have some spare bandwidth I have some high-res decap
       | photos from the chip in the Casio SK-1!
       | 
       | I worked on trying to reverse engineer the instruction set from
       | that chip, but most of the code is in a mask ROM that probably
       | needs some debug wires to extract.
        
         | nobleach wrote:
         | The demo song from that thing will forever live rent-free in my
         | head. Sometimes I sing it to myself, and then pretend I've
         | switched the lead instrument to a sample. (hi, hi hi hi, hi hi
         | hi, hi hi hi hi hi....)
        
         | ajxs wrote:
         | There's a zip file here with the Casio SK-1 ROM:
         | https://dbwbp.com/index.php/9-misc/37-synth-eprom-dumps
         | 
         | Maybe this could help. Is there some mask ROM on the CPU that
         | isn't included here?
        
           | mmastrac wrote:
           | Correct. Those have been available for ages, but there's a
           | mask ROM on the CPU that is undumpable, at least at this
           | time. I have a huge collection of datasheets and I was unable
           | to even figure out what the instruction set was.
        
       | dvas wrote:
       | This is great! What a lovely read.
       | 
       | Reminds me back of my teenage years mesmerised by
       | software/hardware synths, daws and everything and anything
       | related to audio tech. Hours spent trying to understand different
       | waves, oscillations, LFOs, modulation, AM, FM and so on and so
       | forth. I could go on all day. Great memories.
       | 
       | Anyhow, would be interesting to go down a rabbit hole reading up
       | on the waveform representation for the DX7. Now that I remember,
       | I will go ahead and look for SH-101.
        
       | jacquesm wrote:
       | Here are all the other articles and their previous HN
       | discussions:
       | 
       | https://hn.algolia.com/?q=righto.com+yamaha+dx7
        
       | showerst wrote:
       | Thanks Ken, that was the best rickroll I've seen in years.
        
       | ajxs wrote:
       | I wrote the article mentioned by Ken:
       | https://ajxs.me/blog/Yamaha_DX7_Technical_Analysis.html
       | 
       | I've unwittingly become a bit of a Yamaha FM Synth historian!
       | 
       | Here are some other contributions to reverse-engineering the DX7:
       | 
       | A fully documented disassembly of the DX7 ROM:
       | https://github.com/ajxs/yamaha_dx7_rom_disassembly
       | 
       | A new firmware ROM that makes the DX9 function more like a DX7:
       | https://github.com/ajxs/yamaha_dx97
        
         | djaychela wrote:
         | Thanks for this. I've got a dx9 I paid very little for and the
         | lack of velocity sensitivity has always annoyed me about it. I
         | shall give the firmware a go!
        
           | ajxs wrote:
           | I edited my post to say "more like" a DX7. Unfortunately
           | velocity sensitivity can't be added because the physical
           | keyboard doesn't support it. The firmware _does_ add velocity
           | sensitivity to incoming MIDI data though!
        
       | jim-jim-jim wrote:
       | I am unfamiliar with low-level workings like this, so forgive me
       | if I'm talking out of my ass, but received wisdom from places
       | like KVR Audio suggests that on modern machines, fixed point
       | decimal math tends to be slower than just using floats because
       | the integer registers are already clogged with routine operations
       | like incrementing loops, etc. But some claim that anything that
       | needs a phase accumulator as a wavetable index, like FM, still
       | benefits from being kept as integers due to the expense of
       | converting a floating point accumulator to an int address. FM
       | doesn't have much arithmetic relative to its reads.
       | 
       | I wonder how true this still is. I've been having fun simply
       | assuming it is, and these teardown articles and the other HN
       | discussions around them have been very helpful.
        
         | raphlinus wrote:
         | I am very familiar with such low level workings. On a modern,
         | fast machine, the amount of computation required by FM
         | synthesis is so small compared with the machine's throughput
         | that it just doesn't matter.
         | 
         | Yes, on modern chips float math will generally be faster than
         | fixed point. This is not so much because the integer units get
         | clogged, as that there's a huge amount of chip area and
         | optimization that goes into the float units (often SIMD, and a
         | lot of FM synthesis can benefit from this, though feedback
         | creates data dependencies). For example, multiply-and-add is
         | usually one cycle in float, but would always be two separate
         | instructions in integers.
         | 
         | My recollection is that older ARM chips have a special issue
         | with latency of data dependencies originating from the float
         | unit (NEON, which is optimized for SIMD vector operations) to
         | the integer unit. I suspect this is no longer the case, or is
         | less of an issue.
        
       ___________________________________________________________________
       (page generated 2024-01-12 23:00 UTC)