Saturday, July 13, 2024

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.

No comments:

Post a Comment