I've been working on an annotated disassembly of the Yamaha DX7 ROM, it's been quite a trip so far. Figuring out all the hardware, how the operators and the envelope generators work by looking at the code, the midi implementation and so on.
I work a little bit on it every week on Saturday evening, it's my way of winding down from a busy week. Other people play Sudoku ;)
In case you're wondering why: I'd like to de-solder the CPU from a broken motherboard that I have (besides two working ones) to see how hard it is to take over the hardware by simulating the CPU with a RasPi, but for that I have to know exactly how the bloody thing works in the first place and it is quite a complex beast. The ROM is 16K.
This I would like to know more about. Last year I started to get into electronics by creating on my own synth using an Arduino. As a software boffin, it was marvellous to learn about PWM, timers and the MIDI protocol (along with everything else). Obviously, I read up on the various synths over the years to see how they did their sound generation.
Where do you even start with your project? How to you even get to the disassembled code?
Dump the ROM through an EPROM programmer used to read back the data, then try to figure out what chip it is (found a schematic somewhere), turns out there are two CPUs in it, one which is mask programmable which handles all the A/D and the buttons and keys, the second one which drives the whole thing. The two CPUs talk on some funky parallel link (think 'LapLink' but then for two old 8 bitters sitting 5 cm away from each other).
After you know the CPU it is relatively straightforward, you try to figure out the memory map by looking at the address decoding circuitry , and from there you can infer things like where the vectors are pointing (usually they are at the end of the memory map in CPUs from that era, alternatively at '0'). So that will give you a good idea where the ROM should be located, (in this case from $C000 upwards).
Then you spend lots of evenings with cups of tea and some quiet music on trying to figure out what all the instructions are trying to achieve. A good starting point is any ASCII strings, then tables of pointers to code and strings, then trace the boot vector until you come to the inevitable main loop and trace inwards from there. IRQ and NMI vectors are also useful entry points to dig around in (NMI not used here). It's a job that requires quite a bit of patience and a false start somewhere can cost you dearly. I love the little 'aha!' moments whenever I've sussed out what a particular bit of code does. For instance, the DX7 can display the battery voltage and the patch numbers and other information in decimal, like it should. So then you come across this repeated subtraction test with the contents of a table, turns out it is the binary-to-decimal convertor.
It's going to be a while before this is done but it is very interesting.
Brilliant comment, this is what I come to HN for. I'm starting to get into electronics myself and as a developer I fear it's only a matter of time until I get sucked into this side of things...
That chip reminds me of the Elektor 'GDP', the Graphics Display Processor, a pretty quick 2D accelerator. I wrote a MOS replacement driver for it for the BBC micro that was good enough to run almost anything on except software that wrote directly to the screen.
I did similar synth reverse-engineering of DS-10 synth from Korg for Nintendo DS, so not much desoldering involved :-) The goal was to get it running as a VST plugin, but ARM emulation wasn't fast enough, so I wrote a static-JIT decompiler and decompiled the synth portion of the code into C instructions (see "c-code.h").
That's a very cool project, kudos on the stamina, that must have taken you a really long time. And thanks for the reminder the fix the pictures on my own blog, exact same story.
I'd definitely read a full writeup on this if you ever get a chance. So many of these little proprietary systems risk being completely lost - just look at the amount of effort put in to be able to emulate the various SNES chips
I actually did this a few years ago, for my work on what's now the Dexed engine. But it's likely I've lost the work, it was probably on my work computer and I've left the job. Happy to chat if you want to see what rusty recollections I have.
Oh cool, that would be worth gold in terms of time saved.
I'm in the midst of a pretty intense commercial job this week (but not intense enough to stop me from commenting on HN ;) ), my email is jacques@mattheij.com (I do not see an email in your profile).
I'd love to verify details like the memory map and anything that you still remember about how the button dispatch worked so I can identify a lot of code or the guts of those two main synth chips would help me tremendously.
I work a little bit on it every week on Saturday evening, it's my way of winding down from a busy week. Other people play Sudoku ;)
In case you're wondering why: I'd like to de-solder the CPU from a broken motherboard that I have (besides two working ones) to see how hard it is to take over the hardware by simulating the CPU with a RasPi, but for that I have to know exactly how the bloody thing works in the first place and it is quite a complex beast. The ROM is 16K.