[sdiy] Xpander

[Brian Willoughby]

On Oct 18, 2020, at 1:28 PM, Tom Wiltshire <tom at electricdruid.net> wrote:
> On 18 Oct 2020, at 21:07, Gordonjcp <gordonjcp at gjcp.net> wrote:
>> On Sun, Oct 18, 2020 at 12:20:00PM +0100, Tom Wiltshire wrote:
>>> The Prophet T8 worked the same way, with the main processor writing to a common RAM area shared with the voice (“final”) processor.
>>> 
>>> Given the speed of serial comms at the time, it makes a lot of sense. In many ways it *still* makes a lot of sense.
>> 
>> I don't know, the Juno 106 communicates between the main CPU and the voice CPU at MIDI speeds but with only two-byte messages.
>> 
>> Nobody's ever accused the 106 of being laggy.
> 
> Fair enough. The truth is that humans are really slow, so parameter updates don’t have to be that fast. As long as those note on/off messages get through in a timely manner, probably no-one will notice.

Another important consideration is that the keyboard switch matrix is always read serially, only 8 at a time. So, even if you manage to play 10 keys exactly simultaneously, the scanner will only read a few of those at a time. Of course, there could be a problem if the serial bit rate were very low and the scan rate were very high, but that combination can easily be avoided.

The Ensoniq KPC (Keyboard Processor) board (SQ-80 and EPS and forward) uses a synchronous serial interface to the main synth. This can potentially run faster than asynchronous serial (like MIDI). The KPC handles note on/off, velocity, and aftertouch, so there's potentially a lot more traffic. However, the KPC still only works on a small group of keys at a time, so the serial nature of the communications should not be a problem.

Once you start putting messages other than keyboard-related stuff, there's a risk of things colliding unless you have a parallel interface.


> Still, parallel comms is always going to be faster, and I like the “transparency” of using a shared RAM to get data from one system to the other. It’s quite neat, in a rather 1980’s way!

It's not just 1980s. DMA is still very useful with embedded designs today. Running a DAC from a memory buffer via DMA can be a lot more efficient than having the CPU hand-deliver each sample. DMA is even useful with serial communications, especially for audio streams or any synchronous serial interface where data is delivered on a regular basis. It's better to let DMA directly access the RAM while the CPU does other tasks, and then interrupt the CPU at the end of a full buffer transfer to run the non-transfer aspects of the algorithm.

There are (were) even special DRAM chips with two address busses, so that software could update pixels while a graphics card could step through the frame buffer for display purposes. Those chips were purpose-built, given the common need, but Oberheim basically designed a bespoke interface to take advantage of the parallel memory bus.

It would be interesting to calculate the bandwidth of the Oberheim parallel interface to see what clock speed would be needed over a serial interface to achieve the same thing. I don't mean the theoretical bandwidth, since the voice CPU could be halted indefinitely - without much purpose - but I'm thinking of the actual bandwidth utilized.

Brian