Boss DR-220 Gate Array (MB670120) Interface

    I've wondered for a while how exactly the CPU of the DR-220 controls its gate array. The CPU handles the screen, buttons, and triggers. The MB670120 gate array controls ROM, RAM, and the DAC + multiplexer for playing sounds. Interestingly, the two are separated onto different boards that are joined by a pin header. This makes it very easy to separate them and experiment.

Pinout

    The service manual tells us the connections on the header, but it lists the pins in no particular order. Here they are laid out in the order they appear on the board. The signals of interest are underlined, while the others are in grey.

CPU Dir	Feature	Pin	Pin	Feature	CPU Dir
Out	OE	30	1	WR	Out
Out	CS	29	2	GND
Out	ALEL	28	3	ALEH	Out
	GND	27	4	Trig-In	In
		26	5
		25	6
IO	B7	24	7	B6	IO
IO	B5	23	8	B4	IO
IO	B3	22	9	B2	IO
IO	B1	21	10	B0	IO
In	CLK1	20	11
	GND	19	12	GND
	+5V	18	13	+5V
In	CLK0	17	14	Trig-Out	Out
In	RST	16	15	CLK2	In

General Communication

    The manual also explains the mechanics of communication, but not the significance of it. The gate array determines what sounds to play based on the contents of RAM, and the CPU accesses RAM/ROM through the gate array.

    The CPU can't directly tell the gate array to do anything besides access memory for it. This means there's no instruction to "play a sound right now". Instead, it simply tells the gate array to store a specific value in a specific range of memory. A split second later, the gate array reads back the value, and plays the corresponding sound.

Timing

    The timing is provided by the manual. We're also told what signals are involved. I've redrawn the diagram here. 

MB670120 Gate Array Timing Diagram

    We have a parallel bus, but no dedicated address lines. Instead the bus is multiplexed, similar to some CPUs like the 8085. We specify a 16 bit address, one byte at a time. First the high byte is put on the bus, then the ALEH signal is brought low. This latches our values into an internal address buffer. The same is done for the low byte of that address and ALEL. The data is then put on the bus, and finally we strobe the write line. This stores a value into RAM.

    Curiously, the CPU can't read from RAM; Only the gate array can. This helps show that the RAM access is really just a way to communicate with the gate array.

Addresses

    The last bit of info that the manual gives us is the range of addresses (0-5), though it doesn't exactly say what they do. It turns out these 6 addresses correspond to 6 outputs(channels) of the multiplexer. Different samples(instruments) are hardcoded to these channels. Since we have 11 instruments, some have to strategically share channels.

Instrument	Address
BD	0000
SN	0001
LT	0002
MT	0002
HT	0002
RIM	0003
HCP	0003
OH	0004
CH	0004
RCY	0005
CCY	0005

Data

    So, what values do we put in the addresses to play sounds? The manual has no more answers.

By connecting a logic analyzer to our header, we can see the values sent to the gate array. With a little experimentation, it becomes obvious what the different values correspond to.

    A single byte per address specifies the volume, pause/play status, and instrument for the channel. That's really all we really need.

	Bit Values								Effect
Bit #	7	6	5	4	3	2	1	0
Name	?	Vol2	Vol1	Vol0	Play	Inst2	Inst1	Inst0
	X	X	X	X	0	X	X	X	Not Playing
	X	0	0	0	1	X	X	X	Min Volume
	X	1	1	1	1	X	X	X	Max Volume
	X	X	X	X	1	0	0	1	Play Inst #1
	X	X	X	X	1	0	1	0	Play Inst #2
	X	X	X	X	1	1	0	0	Play Inst #3

• The most significant bit appears to have no impact
• The next 3 MSBs set the volume (The range is greater than what the CPU actually uses)
• The next bit says if the channels should be playing or not
• The last 3 bits specify the instrument

    There's a maximum of three instruments per channel, but 3 bits give us 8 instrument values. Unfortunately, the unused combinations don't yield any interesting results. You'll simply get one of the normal sounds for the channel, not a combination or a hidden sound.

Wrapping up

    Now that we have the pinout, protocol, memory map, and packet structure, we can play some drums! The bus is parallel, the speed is relatively slow, and the timing is forgiving, so most old CPUs should have no problem talking to the gate array. Newer microcontrollers should have it easy too, besides coming up with a dozen outputs. Since we're using the bus in only one direction, we can use a shift register to get extra outputs.

    Now we can interface anything an arduino can be connected to. This opens up the machine immensely, given that it started with only a trigger in/out. MIDI would be an easy choice, but the sky is the limit.