[sdiy] MIDI velocity

rsdio at audiobanshee.com rsdio at audiobanshee.com
Sat Apr 9 23:55:49 CEST 2016


On Apr 6, 2016, at 3:21 PM, Richie Burnett <rburnett at richieburnett.co.uk> wrote:
>> What are some examples of commercial keyboards with ASIC solutions?
> I just looked at a few old Yamaha and Roland service manuals, like the D10 / D50 / D70 and alpha Juno 2 for instance.  The keyboard and MIDI interface is managed by an 8-bit micro, but there is always a "gate array" with a small (2KByte) SRAM tagged on to it that actually drives and senses the velocity sensitive keyboard matrix.  I don't know how much of an active part the gate array and the tiny RAM chip play in measuring the key velocities though. Maybe the gate array is purely for I/O address decoding and glue logic, or even just to provide sufficient drive current to charge and discharge the capacitances of the switch matrix!  I really don't know.

Reviewing several Roland schematics going back to the JU-1, this "gate array" seems to be a common part that they've been evolving over their product line. It seems to be a solution for the typical glue logic that reduces the chip count. The old CPU designs - 8049, 8051, 8032, 8097 - all had a multiplexed Address and Data bus. The ALE (Address Latch Enable) allowed the Data bus to be used in the first external memory cycle to transfer an additional 8 bits of Address that is supposed to be Latched externally. Any design with more than 256 I/O (or memory) addresses needs to Latch these bits separately in order to decode the full address. This old technique was necessary for DIP packages with fewer pins, but the tradeoff is that all external accesses required two cycles minimum.

Since most I/O would be discrete chips that would be selected by one or more address decoders, the "gate array" ends up being a handy place for all of the logic. As one example, the keyboard column strobes (Roland calls them rows, apparently) could have been 8 or 16 individual bits, but that has been reduced to only 3 or 4 bits that feed a decoder with 8 or 16 outputs. Roland tends to use active low logic for the keyboard strobes, so decoders with active low outputs can be driven by 4 bits to access the full keyboard switch matrix.

It's likely that the SRAM is completely unrelated to the basic keyboard scanning, other than the fact that the CPU probably stores state variables there. My point is that the "gate array" is not accessing the SRAM on its own, or at least it seems highly unlikely. But what the "gate array" does do is decode the full 16-bit Address to derive the select strobes for the SRAM so that it is addressed separately from the custom I/O expansion ports. In this sense, I think it's fair to think of Roland's "gate array" as a custom external memory/I/O controller.


In a modern design, it's far less likely that you'd need ALE circuitry or Address bus latching. You're probably dealing with a dedicated Address bus and standard decoders. Similarly, today's CPU chips often have dedicated external memory pins that can be programmed to automatically support SRAM, DRAM, NAND, or anything else you might need. Thus, most of what was in Roland's "gate array" design has been moved inside the modern CPU. About all you'd need is an external 4-to-16 decoder, unless you have an extra 12 GPIO pins that you could use instead of the decoder. The firmware is only slightly different whether you have a decoder or not.

In other words, the answer to your pondering about whether you can design a keyboard scanning circuit around a CPU without a custom gate array is that it should be quite easy with today's CPU chips.


>> All of my (our?) favorite vintage synthesizers were designed with 8-bit processors like the 6800, Z-80, or 8049/8051 running at about 1 MIPS. They usually had a few 8-bit ports and all use a switch matrix for the keyboard. Some of the Technical Service Manuals actually mention the exact scan rate, and it's usually on the order of 1 millisecond. That's for non-velocity-sensitive keyboards, so perhaps the scan rate is higher for velocity. It would be interesting to find a Service Manual for a velocity-sensitive keyboard that actually describes the scan rate. My experience is with really old keyboards, so if anyone has pointers to this information on velocity synths, I'd appreciate it!
> 
> Sadly none of the service manuals I've looked at give any timing diagrams for the scanning of the velocity sensitive keyboard.  I could feasibly crack open my Alpha Juno 2 and measure it if I had to, but a scope probe dangled over the keys with sufficient gain might show a hint of the scanning waveform!

Although the JU-1 Service Manual shows the 4 ms keyboard scan rate and 8 ms button scan rate, these timing diagrams seem to be completely missing from the newer keyboards that support velocity. The JU-1 does not support velocity, so it doesn't tell us very much that they're able to wait 4 ms between keyboard matrix accesses. Note that the firmware scans all 7 rows (columns) every 4 ms, rather than scanning 1 row (column) each time. This results in a burst of higher frequencies on the strobe lines followed by almost 4 ms of silence.

In my firmware designs, I spread things out so that each interrupt handles only a single column. I think this reduces the maximum frequencies seen on the strobe lines (although square waves do have nearly infinite harmonics). This requires a faster interrupt (8 to 16 times more frequent), but with 48 MHz processors running 12 MIPS that's not as much of an issue as it was when 8-bit CPU chips had lower clock rates. The downside is that more interrupts can sometimes cost more in terms of context switching, but at least the interrupt service handler duration is quite a bit shorter - particularly because it's possible to write code with no wait states or timing delays inside the interrupt.

Velocity scanning might benefit from a hybrid timing, where pairs of columns are scanned together to handle velocity sensing, but each next pair is postponed until the next interrupt.

Brian Willoughby
Sound Consulting



More information about the Synth-diy mailing list