Are you ready for a computer peripheral that's fun, instructive, low in cost and provides an impressive demonstration that even your least technically inclined friends can understand? How about this one - a computer controlled drum set.

Yes, there are a lot of automatic percussion units available and yes, they're pretty much a drag. Useful, under just the right set of circumstances, but even then their incessant BOOM-chik-chik can really turn into a BUMMER.

Now, think about computer interfaced drums. You're not forced into using what somebody else thinks is a cha-cha; you write your own rhythm pattern for the specific thing you're doing, even if it's in 7/16 time. And the real world niceties like bridges and intro's? They're simply not possible with conventional electronic drummers. But with drums tied to a computer - no sweat.

If you're interested, we've got a lot of ground to cover; drum circuits, interfacing and programming. Let's get on with it.

DRUM OSCILLATORS

Most drum units generate their percussion sounds using a simple active filter section like that shown in figure 1. There are two ways to think of this circuit. Either it is almost an oscillator which when excited by a pulse "rings" for a short period of time; or, it is a high Q filter section which extracts from a pulse excitation function a single sine wave component. Either of these explanations is valid. Either produces an accurate description of what happens. When you hit the circuit with a pulse it responds by generating a damped sinusoid, which is the electrical analog of the mechanical action of a drum head.

Table 1 shows a realization of this circuit when using one stage of an LM3900 type quad current differencing amplifier as well as the component values required to generate a number of different drum/percussion sounds.

Snare drums and cymbals require a keyed noise source with filtering. Figure 2 shows a circuit that works well for snares - and don't forget that a drum circuit must be used at the same time to produce what is known as the "strike tone".

Building a complete drum set is simply a matter of duplicating these circuits for as many different sounds as you require and resistively mixing them all together to a common audio buss.

INTERFACE

There is only one difficulty with using drum circuits like those shown as a peripheral to a computer and that is that the computer is just too fast. Our filter circuits like a triggering pulse that is at least several milli-seconds long whereas the average write cycle of a microprocessor (and we will be playing the drums by "writing" into them) is on the order of a few micro-seconds. This typical response of our drums to a microsecond long pulse looks like this:

As you can see, it doesn't strain even my non-existent artistic abilities.

If you own one of the computers that's all pretty and boxed up, you can refer to a section of your systems manuals entitled "slow peripherals". In the parlance of the field that's what the drums are.

I'm going to assume that you're going to be using someone's low cost "evaluation" unit. And further, that your manuals are typical of most of the ones that I've seen in that they tell you only enough to make sure that your level of confusion is appropriate to this "complex" field. My comments here are specifically for National's SC/MP evaluation kit, but with slight modifications are applicable to most others.

Figure 3 (shown on the following page) shows an extremely simple interface adapter that has performed well for me. As you can see, it's nothing but three packages of quad CMOS NOR gates. Here's what happens.

As I said before, playing the drums from a program standpoint will be a memory write operation from the processors accumulator to the memory location occupied by the drum set. When the program says write (actually STORE) the group of ones and zeros which we will have loaded into the accumulator to produce the drum sounds that we want are put out on the machine's data lines while the address of the memory location into which we are going to write appears on the processor's address lines.

Very shortly after the valid address and data appear on their respective processor lines, the machine issues a WRITE command (in the SC/MP, the NWDS line goes to ground indicating a write). As we shall see shortly, when the machine issues both a write command and the address that we've selected for the drum board at the same time it causes the SEL (select) line on the interface to go high which is buffered by gates G1 and G2.

The output of G2 is coupled by the time delay circuit R1 and C1 to the input of G3. The output of G3, which was in a high state, switches low as soon as the SEL line is activated and produces two major results. First, any of the data lines which have a zero on them, when NORed with the output of G3, will cause the outputs of their respective gates (G4-G10) to change state. These gates changing state causes the drum oscillator attached to that gate to sound.

Also, the output of G3 is routed back to a pin on the processor called NHOLD. This is an interesting input to the processor, because when this pin is grounded it causes the machine to STOP with the data and address lines held in the same state they were in when the hold command was issued. This has the effect of latching the address and data lines of the processor for as long as NHOLD remains low (a time determined by the R1, C1 time constant) and serves to stretch the micro-second write cycle out to the few milli-seconds required by the drums.

We need to discuss programming some, but before we do let's consider for a moment which memory location(s) we want the drum set to occupy. If you are using one of the larger systems by SWTP, IMSAI or MITS (or even some smaller systems such as the F-8), the problem is academic. These machines have provisions for output ports and you will use them - why fight the system. In these cases the SEL and NHOLD lines can be used for the handshaking "data ready" and "data accepted" lines respectively.

On smaller systems you will want to base your decision on what the cost (both financial and emotional) will be of using a specific location or group of locations. May I make a suggestions that might not occur to you otherwise? Use the same group of addresses that is occupied by whatever ROM your system has. This is not "ordinary" (you never write into the ROM locations with the usual programming because it won't do anything - they're Read Only Memory) but, there's nothing wrong with it and they have the tremendous advantage of being locations that are already decoded. On the SC/MP this is accomplished as shown in figure 4.

PROGRAMMING

There's another big plus to using the ROM locations as an output port, this one from a programming standpoint. And we're both going to have to go slowly here because it can be confusing otherwise.

ROM, even in minimal systems, represents a chunk of memory - ordinarily at least 256 bytes. This means that in a machine like the SC/MP, which has 16 address "lines" (some are multiplexed onto the data bus, but forget that) only the most significant 8 bits are required to address the output port.

Most machines have a scheme of addressing memory which is referred to as "indexed" and they have, internally, one or more 16 bit wide "index" registers that can be used to "point" to a specific memory location. Since most of the processors used by hobbyists work on only 8 bits of information at a time it is obvious that it will take two "groups" of instructions to load the 16 bits into the index register - one "group" to load the "low order" 8 bits and a second "group" to load the "high order" 8 bits. But if we're using 256 bytes of memory occupied by ROM as a single output port, we don't have to worry about the low order 8 bits, they can be anything and we will still be addressing the output. Since they can be anything a still work, we don't have to worry about loading them and as a result we've saved at least three ( and probably much more in a complete program) lines of program code.

Programming for the drums can be as simple or elaborate as you like. Regrettably, there is sufficient space here for only a few tips. The instructions for the experimenter's kit goes into much greater detail with sample program listings for a variety of machines.

Let me point out a few hardware considerations that will affect programming. Each bit of data in the accumulator at the time of the write operation will determine whether a specific drum sounds or doesn't sound. A typical coding arrangement was shown in figure 3 and with this arrangement the drums would be coded like this (remember that a 0 sounds the drum).

drum sound	binary	hex	octal
heavy bass	11111110	FE	376
light bass	11111101	FD	375
snare	11111011	FB	373
tom-tom	11110111	F7	367
conga	11101111	EF	357
clave	11011111	DF	337
woodblock	10111111	BF	277

This is confusing. It would be much easier if when we were programming we could just write a 1 for the drum we want to sound. We can do that if we write a program flow that reads a byte of drum data but before writing it to the drums does an Exclusive Or Immediate with FF₁₆. As many of you will realize, this has the effect of complementing every bit of data so that the drum sounds we want can be written in memory in this more logical form:

drum sound	binary	hex	octal
heavy bass	00000001	01	001
light bass	00000010	02	002
snare	00000100	04	004
tom-tom	00001000	08	010
conga	00010000	10	020
clave	00100000	20	040
wood block	01000000	40 100

This is particularly easy if we want to sound two drums simultaneously; for example a heavy bass down beat and a snare drum at the same time would be in binary 00000101 (05₁₆) (005₈).

For very simple repeating patterns, this complementing action even has an advantage in that we can use FF₁₆ as a repeat indicator that is stored along with the drum data. Program flow would be 1) load drum data, 2) complement (XOR IMM. FF₁₆), check for zero (11111111 complemented is 00000000) and if zero start again, 4) if not zero, write accumulator to drums, 5) delay (tempo) 6) get next data and go to 2.

Various machines have an amazing variety of ways to test the accumulator (test for: zero, not zero, pos., neg., carry, overflow, etc.) but one thing they all have is a test for zero.

Notice that the 8th data bit in the arrangements that I've shown does not have a dram associated with it. There are two reasons, first, we've got a bunch of drum sounds already and secondly, we can use that 8th bit in our programming as an indicator that the data we've loaded is not to be played as drums, but to be interpreted as an instruction. A simple example would be to suppose that we have a rhythm pattern we wish to play 16 times and then stop. We can use a program based on the flow chart shown in figure 5 to accomplish this. Notice that in this case the program reads the drum data, tests to see if it is in fact an instruction, and if not plays it. When it does get to the byte that is the instruction it decrements the "count", saves the data back in the location it got it from and iterates the pattern. On the last pass through the program the decrement operation on the "instruction data" results in the last seven bits being 0, which tells the machine that it is through (or to go to the next pattern, or whatever). There are, of course, as many ways to handle this as there are people to write programs.

Looking back over this I can see that for some I will have covered a lot of ground in not quite enough space to make it all clear. To others I will have said nothing that wasn't already obvious. If you're in the first group, think about the experimenter's kit. I have a lot more space there.

If you're in the second group, hang in there - next time we're going to look at D/A converters with an eye toward full computer synthesizer interface. I promise, some of those things are not obvious at all.

EK-2 Computer Drums Experimenter's Kit - kit consists of circuit board and all parts necessary to build the interface and drum circuitry described in this article. Includes more detailed analysis and sample programs for a variety of processors including SC/MP, 6800, 6502.

EK-2 COMPUTER DRUMS $19.95 plus $1.00 postage & handling

---

JOHN'S CONTEST - RESULTS

You may remember that we had a contest in the last issue to find an easier way to design the "Tracking Top-Octave" circuit that I had shown in Lab Notes. Everyone who was interested enough to enter received a copy of the "correct" answer and the contest was won by David Harper of Houston, Texas.

Unfortunately, along with piles of entries, we also received a copy of a patent that pretty accurately described where we were headed. As of this writing I have not been able to negotiate an acceptable licensing arrangement, so I guess that this will not be a new product any time soon.

The correct answer is:

The divider shown in Lab Notes is not needed. The top octave chip is already a divider.

Could look like this:

Switch selects octave above or octave below VCO reference.

I want to once again thank everyone who entered. As I said in my letter, the next time we have a contest, all correct entries are going to go in a barrel and we'll choose one. The Post Office's handling of the mail makes a "first correct entry wins" contest impossible.