The Drumulator is a computer controlled digital synthesizer designed specifically to produce digitally recorded drum sounds using relatively inexpensive hardware. This has been accomplished by making extensive use of software, both by the main Z-80 CPU, and by the special purpose register file controller. As a result, the theory of operation of many of the Drumulator functional blocks requires an understanding of both the hardware and the effective function of the driving software. SEE PAGE 29
The major force behind the Drumulator is a Z-80 microprocessor, which controls a number of peripheral circuits. This is illustrated in the block diagram. We'll discuss each block in detail, concentrating on the theory of operation of the individual block, with a short section on how it relates to the whole.
The power supply generates a variety of power sources used for the analog and digital circuitry of the Drumulator. It also generates two status signals to guarantee data retention in the non-volatile Memory during power up and power down.
The on-board power switch and fuse route the AC to the transformer; note the 115/230 VAC switch. Capacitor C-104 to some extent filters out RF energy pulses that might sneak in from the line and upset the processor.
The transformer produces 10VAC to be full-wave rectified into the raw +V supply (about 12V under load) used for the LED array and regulated by an LM323 to +5 volts for the logic. It also produces 36VAC center-tapped to be full wave rectified and used to generate the regulated +15 and -15 supplies for the analog circuitry. VR6 and the VPP supply are not used in current Drumulator revisions, although there is space for them on the circuit board.
C22, the 10 uF capacitor associated with the LM323, is necessary for stability during power-up and power-down. C25, associated with the 7915-15 regulator, is also required for stability.
The CA3086 transistor array is used to detect valid power conditions. When the +V supply (unregulated +5) reaches about 7.5 volts, the anode of zener diode D54 will be near 1.3 volts, turning transistor 3-4-5 on. This in turn will unsaturate transistor 1-2-3, allowing signal +50K to become true. This is used to terminate the "reset" signal to the Z-80 processor. At the same time, the CMOS compatible signal +PWROK will become true, allowing writing of the non-volatile memory. Note that a low line condition will cause many processor resets to occur, preventing anything but the first few pages of code to be executed.
The litium battery supplies, through D3, 3V power to the non-volatile RAM during power-off. Regulator VR1 produces 5.6 volts, dropped to 5V by diode D1, for the non-volatile RAM during operation.
The Z-80 CPU runs the show. It fetches instructions from the program ROM, manipulates data using the scratch pad and non-volatile RAMS, and sends it to the various input/output functions.
The Z-80 CPU requires a clock to operate. The PHI clock for the Drumulator runs at 2.5 MHz. This is generated from a 5 MHz crystal oscillator by a counter. The counter also generates a 833 KHz clock called CLK.
The Z-80 CPU also needs the RESET signal high before it will do anything useful.
The Z-80 CPU must decide whom it is talking to, and to do this it uses a 74LS138 decoder. The outputs select which of several output latches are the destination of CPU I/O Write data. The Z-80 uses some SSI gates to select the pushbutton read function CSRPB to do an I/O read.
The Z-80 accepts an interrupt signal from the Z-80 CTC. This signal is extensively used by the Drumulator for virtually every function. It will be discussed in more detail under the Z-80 CTC section.
The Drumulator software resides primarily in the program ROM, a 2764 EPROM. This software will undoubtably be occasionally revised, so be sure you know the software 'Rev number' which can be obtained by pressing MEM-CASS if the instrument runs, or the 'Release date', which is a number like 830405 on the EPROM label. This will be necessary when considering software bugs or talking to us for help.
The EPROM simply responds to a select condition, when both its OE and CE pins are brought low, with the 8 bits of data specified by the 13 bits of address. Note, by the way, that the EPROM is copyrighted. Should you need to make a copy of it for service reasons, please ask for our written permission.
The Drumulator requires a certain amount of general memory to accomplish its function. This read/write memory is two 2114 RAMs. They will respond with data specified by address when their CS inputs are low and their WE inputs are high. They will accept data at the address when CS is low and WE is low.
The Drumulator's permanent memory, where it saves all the segments, songs, and mixes, is in two battery backed-up 6116 CMOS memories. Note that these are placed in 28 pin sockets—this is in case we decide to use another component here. In the meantime, the power is supplied through a special +5M circuit that always stays on—either from a regulator or battery. It responds with data when CS and OE are low, and accepts data when CS and WE are low. Note, however, that CS is generated by a 4023 NAND gate that also gets its power from +5M, and accepts a signal PWROK so that the NV RAMS can only be selected when the power is on. The RAMS and CMOS IC typically draw about 2 microamps of current from the battery when power is off.
The Drumulator produces a metronome by simply triggering a one-shot that makes a 2 msec pulse, perceived as a click. To make an accented click, we send several. To make a beep, we send a bunch. Simple, huh. This signal goes directly to the output and through a volume pot into the mixer.
The Drumulator generates data for sync and cassette entirely in software, and simply outputs the data into a latch. Hence the synch output just takes the data bit value from DO whenever the CPU sends it (CSWSYNC), and remembers it 'till next time.
The Drumulator display is a multiplexed display using high (12V) voltage drivers. It is driven by the CPU on timing generated by CTC interrupts. Hence this stuff must work before you'll see much of anything.
The CPU first turns off all 8 cathode drivers by writing 0 to the 74LS273 display latch (CSWDISP). The ULN2803 turns off current to all LEDs. The CPU then selects the next anode by writing the appropriate bits to the display select latch (CSWPBL bits 3,4,5), which the 74LS145 decodes and drives the appropriate transistor into saturation. Note the transistors float on +V, a ripply signal. The appropriate LED group anode is thus pulled high. Finally, the CPU writes the correct data for this LED group to the display latch, and current is supplied to the appropriate segments for about 1.6 msec., when we begin the process again (we're lucky Z-80's are easily bored).
The Drumulator pushbuttons are scanned by the same interrupt-driven routine that runs the multiplexed LED display. The routine is similar. First the CPU notes by selecting the data input port CSRPB which of the 4 pushbuttons currently selected were pushed, and which were released. It then sends to the pushbutton latch (CSWPBL bits 0,1,2) a code representing the next group to be selected. The 74LS42 selects that group. The diodes on the pushbuttons prevent pressing two at once from confusing the processor.
The external gate inputs and footswitches are scanned by the CPU just like pushbuttons. However, since these signals are simply voltages presented by external devices, a transistor is required to convert the signal into the equivalent of a switch.
In the case of the external gate inputs, a positive voltage at the input allows the transistor to saturate when the bus is selected, simulating a pushbutton. 12
In the case of the footswltches, the transistor's base is normally supplied with current, so the equivalent 'pushbutton' looks to the CPU like it is pressed until the footswitch is closed, bringing the base to ground and making the transistorized 'pushbutton' appear unpressed. Fortunately for us, the clever designers of the Drumulator figured out this apparent twist of logic and convinced the CPU to behave exactly the opposite of normal, that is to execute the footswitch function when the 'pushbutton' appears open.
Up until now, things probably have seemed to be pretty normal and like most microprocessor systems. The Z-80 CTC, however, adds what are called multi-level interrupts to the system, and they can occasionally get a little hairy. A description of the interrupt process will probably help.
When the Drumulator starts up, it realizes that it should do certain things periodically (like update the multiplexed display and recall sequence data). So it programs the CTC to remind it by a tap on the interrupt line every so often. When the CTC interrupts the CPU, the CTC takes the IEO line low (a useful debugging aid for interrupt system problems) and the interrupt line low. The CPU then 'acknowledges' the interrupt, which tells the CTC to bring the interrupt line high again (but leave IEO low), and then the CPU executes the program it needed to be reminded to do. When that program is completed, the CPU 'returns' from the interrupt routine. The CTC is smart enough to notice this, and then brings the IEO line high. Hence: if the INT line stays low the CPU is never acknowledging the interrupt (this is done by bringing IORQ and M1 low simultaneously), and if INT is high but IEO stays low, the CPU is never finishing the routine (probably incorrectly reading the program ROM).
If all this has bewildered you, remember, things could be worse. Try the register file section if you don't believe me.
Anyway, the CTC is used primarily for the LED and pushbutton scan interrupt and the sequencer timing interrupt. This takes up two channels of the CTC.
A third channel is used as a counter to interpret the slider. Every scan cycle (about 1.6 msec), the CPU triggers the slider one-shot (CSWPOT), which then generates a pulse that varies in length from about 10 to 400 usee. This then gates the 833 KHz clock into the counter, which has been programmed to count the pulses that get through. The result is that the CPU knows the resistance of the slider.
The fourth channel is used by the sync and cassette functions (and the pad and external computer modes). The sync input is 'conditioned' by an op-amp connected in a non-inverting amplifier mode with hysteresis. This neatly squares up the ugly signals generally supplied by cassettes. This signal is then limited in swing by D48 and D49 to avoid injuring the already abused CTC. The CTC can then interrupt the processor on the rising or falling edge of the signal. The processor can look at the state of the signal using CSRPB, but it never bothers.
The cassette interface works entirely by measuring the timing of the edges supplied to it (timing is everything—right?). This means that if the timing gets screwed up, usually by a bad slew rate or insufficient gain anywhere along the way, it won't read properly.
All of the stuff up to now may have been fascinating, but doesn't have much to do with music, huh. Well this doesn't either, but it does explain where the sound comes from. So listen carefully.
The Drumulator's sound generator is really a special purpose processor that has its own program (called microcode) and all the other things processors like (such as registers, clocks, etc). The processor is simple, so we call it a controller (like calling a small human a child), and it consists of two parts: the register file and the 'control sequencer'. Naturally, we've applied for patents on all this stuff.
The register file consists actually of 19 registers, each 16 bits wide. 16 of these are located in the 2114 RAM chips, and can be accessed by using the RA address lines. The 74LS374's 1J and 2J are the input register, and can be written by the CPU, which is how the CPU tells the controller to make a sound. The 74LS377's are the memory address register, and they tell the sound ROM the address for the particular sound sample valid in this time slot. The 74LS374's 5H and 6H are the sum register; this holds the incremented value that was supplied by any register on the previous controller state cycle.
These registers are controlled by a variety of signals. The input register can be selected by bringing IOE low to enable its output. Similarly the sum register can be selected by SOE. The memory address register can be programmed to capture data by bringing DLEIow. Finally, any one of the 16 general purpose registers can be enabled to read by selecting it using RA0-RA3, or to write using RA0-RA3 and bringing WRP low. The only signal out of this mess is CARRY, which tells when the incrementer has reached a zero count.
The control sequencer runs the show for the register file. Each controller 'channel cycle' consists of 5 'state cycles'; there are 8 channel cycles in a sample period, one for each of the eight Drumulator output channels. Within each state cycle, the microcode PROM determines exactly what the register file will do depending on certain conditions. This is outlined in the timing diagram below, which you can use for reference if you want to be even more bewildered.
Counter 7D produces the 5 'state cycles', sending these to the microcode PROM. In addition, flip/flop 11D (both halves) performs as a 'request latch' to inform the control sequencer and microcode PROM that the CPU has written data to the input register. Finally, latch 12E will remember the state of the carry when the control sequencer last requested it be saved, and will tell the microcode PROM. Using these 5 bits of data (3 representing state, 1 for request, 1 for carry), the microcode PROM can perform any of the register functions mentioned above, and: Reset the request latch Enable the carry latch
Choose which of two sources (the current output channel or the CPU selected channel) will produce the general purpose register address
Enable the current output channel counter to be incremented.
The multiplexing between the two addresses is accomplished by the 74LS157. The counter 10D's most significant 3 bits represent the current channel, the least significant bit determines whether the 'size' or 'location' of this channel's general purpose registers are to be addressed. The same applies to the CPU-supplied channel number data stored in latch 13H.
The microcode is written to accomplish the following:
Check the size remaining to output for the current channel's sound. If it is zero, do nothing. Otherwise, decrement the size and re-write it for next time.
Determine the location in the sound ROM of the current channel's current sample. Output it to the sound ROM using the memory address generator. If the size was zero, do nothing. Otherwise, increment the address and re-write it for next time. If the Z-80 has written data into the input register, transfer it into the general purpose register specified by the Z-80. If not, do nothing. Otherwise reset the request latch. Proceed to the next channel.
The result is a series of addresses which are output to the sound ROM, each representing the current sample of the current sound. If the sound is complete, the address will be the last address of the sound, whose data will cleverly be set to zero. Simultaneously appearing on the channel select lines CNLS0-CNLS2 is the number of the current channel (whose data point address appears on the MA0-MA15 lines).
The SHD line is synchronized by the clock circuitry to provide a sample/hold strobe signal that is synchronous with all this to aid in demultiplexing.
Relax, it's downhill from here on.
The sound ROM is actually 4 93128 16K x 8 bit mask read only memories, giving a total of 64K bytes of sound data. This is not stored in a very logical location of particular sounds in particular ROMS, other than the fact that we used all of ROM 1E for the ride cymbal. The sockets are, however, compatible with the 27128 EPROM, and details on programming your own ROMs are available from E-mu. Note, however, that producing such ROMs will require several thousand dollars of specialized equipment, and that E-mu doesn't supply custom ROMs.
The sound ROM produces 8 bits of data representing a sound data point from the 16 bit memory address. The output of the sound ROM is thus the data for channel 0, then channel 1, and so on through 7, and then back to channel 0 again for a new sound data point, etc.
The main digital to analog converter is a 6072 companding DAC. This produces, from the stream of sound data, a multiplexed analog signal representing in sequence the current analog sample level for each of the 8 channels in sequence. These levels are still synchronous with the CNLS0-CNLS2 signals supplied by the control sequencer. The signal appears as a -5 to +5 signal at the output of 2D.
The levels of the sounds are stored in 74LS670 dual-port memories 10H and 11H. This data was supplied by the Z-80 for each of the 8 channels before a sound was requested from the register file controller. During each channel cycle, the signals CNLS0-CNLS2 select one of the 8 read addresses from the level RAM, which produces a 4 bit level value. This is then interpreted into a logarithmic (dB) coding by the log PROM, and sent to the level DAC to be applied to the sound.
The multiplexed analog signal from the main DAC is multiplied by the level DAC to produce a new multiplexed signal that represents each sound data point at its correct playback level. The level DAC is a CMOS multiplying DAC that produces as the output of 6C the signal at its input multiplied by the level numeric value presented at the digital inputs.
Now it's time to separate out the sounds for each of the eight output channels. This is done by the sound demultiplexer, which is really eight sample/holds. During each channel cycle, the CNLS0-CNLS2 inputs to the DMX-88 demultiplexer select the channel whose analog sample data has been produced on MUXIN. Then the SHSTB signal pulses high, charging the channel's hold capacitor to the sample voltage. This is done for all 8 channels in sequence. The 8 TL084 sections buffer the channel voltages.
Two of the channels—the ride and hi hat cymbals, can use as much high frequency energy as they can get, and hence are unfiltered. Four others, the snare/rim, bass, claps, and cowbell/clave, are filtered with five-pole 1 dB ripple Chebyshev filters placed at appropriate frequencies to optimize the sound outputs. Note that these filters are somewhat sensitive to electrostatic coupling. This is where the high frequency buzz that can be heard at very high gain on the bass output enters the circuit.
The remaining two channels for the toms use dynamic (voltage controlled) filtering to optimize the sound. The signal passes through an SSM2044 type voltage controlled filter. The control input of this filter has an AR type transient on it.
This AR transient is initiated by the Z-80 CPU, which sets the FILT line to zero for about 5 msec. This discharges the 10 uF capacitor through the 100 ohm resistor, creating the attack portion of the transient. When the CPU brings the FILT line high, the decay is produced by charging the 10 uF cap through the 30K resistor. The initial frequencies of the filters are adjustable, and are best set by bringing the filters into oscillation using the test points provided.
The eight channel outputs are finally summed and level controlled to produce the infamous mix output.
Was this article helpful?