SR-88 Mods

The Sound Master SR-88 is a royal pain to sequence with. Mostly because it only has clock (and trig) out in a nonstandard PPQN(pulse per quarter note).

There are a few solutions:

1. Make it generate a more normal 24PPQN. I like the idea of reworking its clock, speeding it up and dividing down internally. Maybe generate start/stop signals from the buttons then have a full DIN sync.
2. Add a clock/sync in. Slave it to something that makes a better master clock and/or is MIDI compatible.
3. Add trigger ins. The problem with both of the other approaches is that you still have to use its internal, very limited and fiddly sequencer. This avoids the clock and sequencer entirely. Trigger ins cure all ails.

Triggers it is. This is a pretty simple mod: just disconnect the TC5501 RAM from the sound generator and connect your triggers. This has already been documented here, but I found the images unclear. Since I'm performing the same mod, I used the opportunity to take my own pictures.

First cut out the TC5501 that generates the triggers. Just sever its data lines: pins 10, 12, 14, 16.

Then solder wires for the new jacks. Red wires are the original trigger outputs. White wires are the trigger inputs.

Attach switched jacks such that the original triggers are used in the absence of external triggers. Ground to the ring, red to the switch, white to the tip.

Mount the jacks and you're all done. I used the battery area since it had lots of room. Also shown is an added LM7805 regulator that allows the SR-88 to use a standard 9v power supply.

Sound Master SR-88 Schematic

I needed to fix up an old SR-88, but the available schematic was almost illegible. I grabbed the highest resolution copy I could find and tried to touch it up. Some of the lines were very nearly gone, so I had to guess at some of them. There are certainly some mistakes and oversights, but I think it's an improvement.

Interesting to note, is that the schematic very closely follows the board layout as seen from the bottom.

I started to redraw the schematic in eagle, but I quit once I debugged the SR-88. The CD4011 NAND was shot. This seems to be a common problem in these and similar machines.

Anyway, here is the partial redraw and one I rearranged to be more conventional.

DR 220 ROM

The DR 220's ROM is partially audio data and partially pattern/miscellaneous data.

The 220 comes in two flavors: 220A(coustic) and 220E(lectric). Most of the differences can be toggled and are contained in the gate array(IC1). The rest are in the sound ROM(IC2).

I haven't bothered breaking down the data portion since it doesn't appear to contain anything too interesting. Some simple tests suggest that it holds pattern/song data, instrument names for the lcd and instrument volumes. The volumes can be increased beyond what the normal interface allows, but it's buggy and can distort.

The audio is encoded as mono, signed, 8bit-packed, 12bit mu-law PCM @ 25KHz. A partial departure from the Roland standard.

None of the address lines nor data lines are jumbled and no samples are interleaved. It's pretty straightforward. Mu-law encoding is the big hurdle.

Mu-law is a logarithmic encoding that was used on some older drum machines: Linn, Oberheim, etc. The idea of it is to exploit our non-linear perception of sound. The encoding gives more precision to lower(quieter) amplitudes that we have better perception of. Conversely is has to remove some detail from higher(louder) amplitudes that we can't discern as well. It's a tradeoff for the more "valuable" part of the signal.

The nuts and bolts of the encoding work like scientific notation. Each number gets translated into a significand(mantissa) and an exponent. In the 220's case, the four least significant bits of each byte are the mantissa, the next most significant three are the exponent and the most significant is the sign bit. For whatever reason, the sign bit is nonstandard for mu-law. If the bit is set the byte must be inverted before being decoded.

TR-505 ROM

The TR-505 is very similar to the 626. Same sound chip, same general design.

The audio is encoded as 8bit, mono, linear PCM @ 25Khz. Standard Roland fare.

The sound ROM(IC11) has a smattering of jumbled data and address lines that makes it hard to read/write. Most of the pins can be unscrambled in software but, the actual chip(TC531000P) has a non-standard pinout. Its A16 is where most 28pin chips have an output enable line. A little rewiring is required to read it and a larger chip is required to duplicate it.

Even with the pins in order, the sounds are still scrambled. The short interleaved samples and the long chunked-up samples are sorted just like the 626, so I'll just reiterate a bit.
The short samples are combined: one sound on the odd addresses and one sound on the even addresses.
The long samples are put into "piles": A,B,C,D. Each pile contains every fourth byte. A has every fourth byte starting from 0, B has every fourth byte starting from 1, C every 4th from 2, D 4th from 3.

As one final point of confusion, A0 is inverted. Some basic glue logic was used to generate A0 (and A13-A16) and it was probably just easier to invert A0 in the ROM rather than invert the signal. Based on the binary I've found, no other address lines are inverted.

Here is the ROM table from the service manual.

TR-626 ROM

The 626's ROM is entirely audio data. Its data bus is wired directly to an R2R DAC and nothing else.

The audio is encoded as 8bit, mono, linear PCM @ 25KHz. This is a standard used by a few Roland machines: 707, 505, etc.

It's the simplest audio encoding and the ROM is effectively a WAV file without the header. Audacity can import it as an 8bit, unsigned, mono "raw binary". If you try this you'll find some recognizable drum sounds, but lots of static and strange noises.

The trouble comes from how the address lines are ordered and manipulated. First off, address lines 6 & 8 are swapped. Since the board is single sided, this was probably done for layout purposes.

The rest of the problems stem from the fact that two gate arrays control different portions of the address bus. IC14 (MB63H114) handles lines 1-12(A1-A12). IC13(MB671189PF) has A0 and A13-A17.

Some of the shorter samples are "interleaved", one sample on the odd addresses, the other on the even. IC13 forcing A0 constantly low(or high), while A1-A12 count normally, will select one of the two samples.

The longer samples (cymbals) are fragmented into 8k chunks. With some experimenting, I found that these chunks are just the opposite of the interleaved samples. They are ordered like dealt cards: 1 card(byte) for hand(chunk) A, 1 byte for chunk B, 1 for A, 1 for B, etc.

So, if you pick the bytes alternately, you'll get the original sample.

The service manual actually explains that this is the result of a kind of "retcon". IC13 is there to give IC14 access to a larger ROM. IC14 was not designed with this in mind. IC14 stops counting up once it reaches its max value of 2^12. IC13 gets around this by assuming the role of the least significant bits(the bits that count up the fastest) and making IC14 count the more significant, "slower" bits. By the time IC14 counts up to 2^12 the combination of IC13 and IC14 has actually counted up to, say, 2^14.

The service manual also gives us a nice table with some confusing naming conventions. The negative address lines indicate that you shift all the other lines left to make room. The A0 column serves to show if a sample is on the odds or evens.

ROM unscramblers

A set of python scripts for decoding and/or unscrambling various drum machine ROMs. 
They have been tested with python 3 in Windows.

TR-505 unscrambler assumes the ROM binary already has the address and data lines in the correct order.
It fixes the inverted address line, recombines the cymbals and separates the short, interleaved samples.

By special request, I've uploaded a 505 re-scrambler. Again, this doesn't take into account the jumbled address/data lines. You'll need to use a tool like EPROM pin swapper to reorganize things. Even then, the replacement EPROM will need to be rewired a bit. I touch on it in my TR-505 post.

TR-626 unscrambler accounts for the swapped address lines.
All interleaved samples are separated. All cymbals are recombined.

626 scrambler accepts a WAV file as a command line argument. Outputs a bin file ready to burn to an EEPROM.

DR 220 expander takes the 220's 8bit mu-law encoded ROM and converts it to a 16bit PCM binary: effectively a headerless WAV file.

Mu-Law expander takes most mu-law encoded ROMs (eg. DMX, Linn Drum, Drumtrax) and outputs a 16bit PCM binary.