Driving a YM2151 FM synth chip

As great as the famous C64 SID chip is, it is not the only way to produce great music and sound effects. There is another category of sound chips based on frequency modulation (FM) synthesis.

A very popular choice, mainly in Japanese arcades and consoles as well as some keyboard synthesizers / pianos, is the Yamaha YM2151. This is in fact one of several chips in the family of OPL, OPN, OPM and OPS chips. These acronyms indicate how many oscillators per channel the chip contains but they all fall in the wider family of FM synthesis chips.

The YM2151 (and others in its category) do not output analog sound, instead they output digital data over a serial channel. This typically goes to a separate D/A chip like a YM3012 stereo DAC or a YM3014 mono DAC. The YM2151 and its companion DACs are available for purchase on ebay for just $3 each so the enthusiast can experiment with them without considerable cost.

The fact that the chip does not have an integrated D/A and requires additional external components might be considered a drag by some, but in this particular instance, for someone like me, the fact that the chip outputs digital data is actually a bonus since that output can be fed back into an FPGA (without going through a D/A and A/D conversion) and further processed numerically.

To be honest, the idea for this mini project came to me after browsing though various schematics of arcade games. I came across a high res scan of a schema for the arcade version of Double Dragon

This was one of those rare schemas that are clean and legible but also just real easy to follow (despite it being over 20 pages), it's just a pleasure to look at and it just makes sense. The signals that cross pages are also very easy to follow because the designer labeled them not just with the page they connect to but the coordinates on that page as well. This is one of these games that have a separate sound board, complete with its own CPU. The interface from the game board to the sound board is via a simple 8 bit port with a single strobe (write) signal. I had the feeling I could just implement most of this sound board on a FPGA and then simply drive the external YM2151 chip with the signals produced by this sound board implementation.

Wiring all the external chips on a prototyping board is not really that hard, below is the basic schema that needs to be followed. This schema is a composite after cutting/pasting parts from different pages of the original schema to illustrate just the YM2151 connections to the D/A and audio amps.

View attachment: YM2151_schema_snd.png

So in order to implement the sound board on a FPGA I need to figure out how the main game communicates with the sound board. Focusing on the main game CPU is the wrong approach here though, this is like taking the long way to get somewhere, the right thing to do is look at the sound board CPU and see how it needs to be "tickled". Here is the schema with irrelevant bits taken out.

View attachment: YM2151_schema_adec.png

The data latch IC17 is written to by pulsing the signal line *3806 low then high. This clocks in the value from the DB data bus into the IC17 latch. In parallel however, the signal *3809 also clocks the flip-flop IC39. Because the D input is tied high, the pulse on its clock line cause the D input to be latched to the Q output (not shown) and its complement /Q at pin 9, meaning /Q goes low whenever the clock (line *3806) rises. This cause the active low /IRQ line to the 6809 CPU IC49 to go low triggering an interrupt.

Disassembling the sound ROM we see that the CPU vector table contains:

ROM:FFF0                 fdb start               ; RSVDROM:FFF2                 fdb start               ; SWI1ROM:FFF4                 fdb start               ; SWI2ROM:FFF6                 fdb vec_FIRQ            ; FIRQROM:FFF8                 fdb vec_IRQ             ; IRQROM:FFFA                 fdb start               ; SWIROM:FFFC                 fdb start               ; NMIROM:FFFE                 fdb start               ; RST

So following the IRQ vector we get to:

ROM:880D vec_IRQ:                                ; DATA XREF: ROM:FFF8oROM:880D                 lda     $1000ROM:8810                 cmpa    byte_2          ; if same as currently playing melodyROM:8812                 beq     locret_881A     ; exitROM:8814                 ldb     byte_0ROM:8816                 bne     loc_881BROM:8818ROM:8818 loc_8818:                               ; CODE XREF: ROM:881DjROM:8818                                         ; ROM:8823jROM:8818                 sta     byte_A          ; store index of melody to playROM:881AROM:881A locret_881A:                            ; CODE XREF: ROM:8812jROM:881A                 rti

Simple stuff so far. When the IRQ vector is called it reads address $1000 and ignoring some of the bits in the middle, it stores that value to byte_A (RAM address $000A) and exits the interrupt handler via the RTI instruction. The reason we ignore some of the code in the middle is because I've already analysed it for you and I can tell you it's not relevant for our discussion.

So why does the IRQ handler read address $1000? Well if we lay out the address lines as A15, A14, ... A1, A0 then $1000 is binary 0001 0000 0000 0000 on the corresponding address lines. So the top 5 address lines A15,14,13,12,11 are 00010 when reading from address $1000.

Looking at the schema we see these lines are connected to address decoder IC79 (pin 5 on that IC is not labeled in this cut down schema but tracing it on the real schematic shows it going to A15 on the CPU). IC79 is a 3-to-8 decoder meaning the 3 bit binary signal presented to its inputs 1, 2 and 3 is decoded so the corresponding output 0 through 7 goes low. Pins 5 and 6 are active low chip enables (meaning they must be low for the chip to do its job). So when the CPU places address $1000 on the address bus, the chip sees 00010 on its pins 5,4,3,2,1, meaning the two enables are enabled (low) and the remaining binary data 010 represents decimal number 2, so output 2 goes low. This output goes to our familiar flip-flop active low clear input. When the clear input is activated by a low signal the flip-flop clears its state, so the Q output (not shown) goes low (cleared) and its complement /Q goes high.

So the operation is now clear, whenever the *3806 signal goes low then high, the DB is latched into IC17 (which goes to the CPU data lines through another buffer to avoid contentions with other stuff on the data bus) and an IRQ is triggered. The CPU stops whatever it is doing and services the IRQ by executing the IRQ routine which clears the IRQ signal by reading address $1000 and storing the DB data from the IC17 latch into the CPU internal memory at address $000A.

This is pretty cool because I can now go to MAME and set a breakpoint at the sound CPU address $880D and every time an IRQ occurs, I can see what value was being written. Using this trick I can see that the following values cause the following things to happen.

$FF clears/stops any melody sound currently playing$FE clears/stops any sound effect currently playing$01 through roughly $30 play different effects or melodies on the YM2151$80 through ?? play different sound effects but not through YM2151.

The sound effects triggered with values > $80 do not use the YM2151 but instead play these effects through separate DAC chips IC80, IC81 and associated circuitry consisting of discrete programmable counters and digital comparators (the relevant schema for these is not shown anywhere in this post). There are in fact two identical circuit duplicated so two effects can be played simultaneously. I won't show an analysis of the circuitry for the effects but roughly it works like this.

Each channel has a 64KB ROM with sound effects stored inside. The CPU writes to the programmable counters to preset them with the starting address in the ROM and also to the digital comparators with the end address in ROM of the sound effect. The counters start counting up from the programmed address until the end address is reached at which point the programmable comparators issue a reset to stop the sound playing and the counters stop counting.

For example the CPU can preset $1234 into the counters and $2345 into the comparators and the ROM would be presented with addresses $1234, $1235, $1236, ... up to $2345 on it's address bus then the address would freeze there. The ROM output is connected to the DAC chip causing the value from the ROM data bus to be turned to analog sound into the speakers. The address counters are clocked with a presumably low clock which it seems is generated by the DAC chips, probably a few KHz.

More to follow...

EDIT: Any code for this project will be available here. So far I have added there the full schematic of the sound board, all three pages into one image for convenience. My development hardware will be a Papilio Plus with an Arcade Mega Shield (plus any external chips of course).