Basic Project Advice for 6502-based Synthesizer?

[commodorejohn]

cynlic wrote:

I wonder, would the bit depth of the sampletable be any kind of limiting factor?

It will indeed, but no more so than any other audio project. Lower bitdepths result in more quantization noise compared to the ideal signal the sample is trying to approximate, but that's just the way it is with digital audio. For your purposes, and given the kinds of sounds you're trying to work with, I don't think that (say) 8-bit sample depth should be much of an issue.

Edit: ah, Garth beat me to the punch.

[GARTHWILSON]

The maximum S/N ratio you can get with a perfect 8-bit converter and no jitter is 50dB (from 8bits * 6.02dB + 1.76dB).  (That's while there's signal.  With no signal, the converter's output remains constant, with no noise at all if the reference voltage is quiet; so it's not like cassettes which gave tape hiss between songs.)  [That's from the 6502 primer, in the circuit potpourri page's section on jitter.  There's quite a lot of additional related information there too, so I won't repeat it all here.]

If volume reduction comes externally from a multiplying DAC or digital pot, the S/N ratio won't really suffer when you go below full volume.

[BigDumbDinosaur]

BigEd wrote:

In the head post, it looks to me like the project idea is a microprocessor controlled (analogue?) synth:

Quote:

I’ve begun to wonder if I could use a 6502 as a sort of controller for a DIY synthesizer in the same way that the 6502 at the heart of the NES interacts with the system’s Audio Processing Unit.

In which case the 6502 needs to set up each note and update according to the envelope: it's not running at waveform speeds.

Ed brings up an important point.

Despite the complexity of what it was doing, Commodore's SID was controllable with relatively simple software.  The amount of MPU time required to do so was very small relative to the total available MPU time.  Despite the C-64's slow 1 MHz clock, music synthesis negligibly affected its performance, even in fast "shoot-em-up" games.

[Chromatix]

Not to mention the music it can play to accompany gnarly demo FX:

https://www.youtube.com/watch?v=ZazU4H2OZFg
https://www.youtube.com/watch?v=470On9iqPXc
https://www.youtube.com/watch?v=W-Crwct7U0c

For this reason, I consider the C64 a prime example of why the 6502 should primarily be a supervisor of specialised hardware, rather than trying to brute-force it in software.

[commodorejohn]

It's certainly hard to argue with the results.

Personally, I consider software synthesis to be best applied as a testing ground for ideas before they're migrated to hardware.

(And I just know someone is gonna fire back that they consider hardware synthesis to be best applied as a prototype stage for eventual software implementation...)

[DerTrueForce]

I think software hitting its limits can be an indicator of where it could benefit from hardware acceleration. It certainly makes much more sense to me to do it in software first, where it's not as expensive, and then implement it later, if necessary or desired.

[GARTHWILSON]

Chromatix wrote:

For this reason, I consider the C64 a prime example of why the 6502 should primarily be a supervisor of specialised hardware, rather than trying to brute-force it in software.

If the computer has to run a game and do video at the same time, then yes, it would be short on computing power.  If the music is all you want to do though, especially with a WDC 65c02 that's 20 times the speed of the Commodore 64 (ie 20MHz, and more instructions and addressing modes), I think it's well within the capabilities.  Going to a 65816 would further increase the computing power by approximately double.

[Chromatix]

Well, if you *think* you can do it in software, then by all means write the code, count the cycles, suck it and see. It'll be a tradeoff between hardware cost and software cost.

But I do have to ask the question: how will you run your user interface in between producing samples?

[GARTHWILSON]

Chromatix wrote:

Well, if you *think* you can do it in software, then by all means write the code, count the cycles, suck it and see. It'll be a tradeoff between hardware cost and software cost.

But I do have to ask the question: how will you run your user interface in between producing samples?

Run the sample timing on interrupts, never software timing.  The only cycle-counting is done to get a rough idea of what percentage of the processor time is being used by the interrupt-service routine (ISR).  The ISR adds the current DDS increment value(s) to the phase accumulator(s) and feeds the next sample(s) to the DAC(s).  One of the background tasks handles changing the increment value(s) and possibly the table addresses when appropriate), and the ISR uses these when it's ready.  The incrementer values and table addresses definitely do not get changed for every sample.

As I said earlier, I designed a semi-medical device several years ago in my job which, although did not do music, did generate three separate, clean sine-wave outputs up to about 12kHz (frequencies set by the doctor), simultaneously, two of them modulated by a square wave (with the rate set by the doctor), while also scanning and debouncing a keyboard and taking commands from it, logging the effects on the patient, and other functions, and none of these produced any hiccups in the audio generation.  The amplitude was changed only at zero crossings (taken care of by the ISR) so there was no spike produced there either.

This was all in software, on a 20MHz PIC16 (not even PIC16F1) microcontroller which does just under 5MIPS which is approximately the same number of MIPS as a 20MHz 65c02 except that the '02 has a better instruction set so it actually has hotter performance at a given clock rate.  The doctor we did it for was pleased.  For cooperative multitasking, I used the cyclic-executive method I describe in my '02-oriented multitasking article at http://wilsonminesco.com/multitask/ .  My article on 65c02 interrupts is at http://wilsonminesco.com/6502interrupts/ .

[cynlic]

Lots of interesting stuff here, y'all.

I would say that BDD and Chromatix's suggestion that the 6502 be used more as a source of control values for an independent IC or circuitry, not synthesis, seems simpler to implement for a beginner like myself. I think once I get the basics of digital electronics (hell, even just basic electronics…) down, all of the suggestions here will be quite instructive, and I'll be able to tackle more CPU-intensive solutions. I’ve always had the unhelpful urge to jump into the deep end before I'm ready, which I'm trying to control at the moment.

That being said, I do have a quick question or two about Chromatix’s proposed sample-oscillator design.

Chromatix wrote:

The next option is to do DDS using a largish RAM chip and a free-running counter, in which you can adjust the value added per cycle, the wrap address and the wrap decrement under CPU control. The counter should have more bits than the RAM chip has address lines, and you just use the high-order ones (for better frequency precision).

1. Do I have it right that because you’re only using the, say, the higher 8 bits of a 16 bit counter, increasing the value by which the counter increments is more precise/granular because the upper bits will be flipped slower than if it were an 8 bit counter?
2. Is there a way to ensure that wrapping over the sample table will happen at zero-crossings in hardware? Obviously if you did this you wouldn’t be able to represent completely arbitrary waveforms, but it might be nice to have at least some kind of mode that does this so that modifying the sample memory during playback won’t risk gnarly clicking.

[GARTHWILSON]

cynlic wrote:

1. Do I have it right that because you’re only using the, say, the higher 8 bits of a 16 bit counter, increasing the value by which the counter increments is more precise/granular because the upper bits will be flipped slower than if it were an 8 bit counter?

The 16-bit increment value to the 16-bit phase accumulator gives a possible 32K frequencies.  The minimum value that actually increments it is of course 1, and the maximum to get under the Nyquist frequency is $8000 (although in reality you'll limit it to something less than that).  So as you can see, you get very fine frequency resolution.  Suppose you're using only the high 8 bits to choose a position in the table.  In this case, the table will have 256 entries.  I suggest 8 bits per entry, but you're not limited to that.  The number of bits per entry is separate from the number of bits needed to address the whole table.)  At the very low end of the frequency range with an increment value of 1, it will take 256 increments, and therefore 256 sample periods, to get from one table entry to the next.  IOW, the output will remain the same for that many sample times.  Getting through a 256-entry table then requires 64K increments.  As you increase the increment value, it will take fewer and fewer increments, and thus sample periods, to get to the next sample value.  You could interpolate to substitute for a larger table with greater resolution, but in most cases the price doesn't warrant the software overhead.  The anti-alias filter will kind of do that anyway.  As your increment value gets above 256, table entries will start getting skipped in order to avoid falling behind.  It's ok though.  Then as you get still higher, you'll start skipping lots of table entries.  Again, it's ok, and the frequencies of the distortion products may be beyond the hearing range or the anti-alias filter anyway.  Speak up if/when you need a design for an anti-alias filter you can make with cheap, commonly available parts.

Quote:

2. Is there a way to ensure that wrapping over the sample table will happen at zero-crossings in hardware? Obviously if you did this you wouldn’t be able to represent completely arbitrary waveforms, but it might be nice to have at least some kind of mode that does this so that modifying the sample memory during playback won’t risk gnarly clicking.

Make your table(s) so they're like an endless tape loop, so there's no hiccup in going from the end back around to the beginning to start over.  They will typically start and end at the zero crossing (or $7F crossing), but not necessarily.  Just so it's continuous.  Also, the waveform will have to be periodic, meaning it's the same every time you go through the table; but otherwise, what's between the ends of the table can be arbitrary.

[Chromatix]

Yup, that's basically what I had in mind. If you build your counter so that it can wrap from and to arbitrary addresses, you can choose the location and length of your sample freely, and make sure *yourself* that it wraps at a zero-crossing.

Though what I'd do is to index over 64K addresses using a 20-bit counter, giving you 4 "fractional" bits. The increment value can be an offset 16 bits (so you now have 64K possible frequencies covering 16 octaves, depending on your sample length), while the start and wrap addresses can be 16 bits without offset. You can also try to use the wavetable RAM as a circular buffer for continuous playback; you'll need to be able to read back the upper 8 or 16 bits of the counter for that.

You can implement multiple counters, and process them in turn using a common ALU and bus structure. Something like the old AMD bitslice ALUs might be useful to make implementation easier; they have built-in register banks to store the counters, built-in add, subtract and compare operations, and so on. Extending the sample resolution to 16 bits would be a matter of adding a second 64KB RAM chip using the same address lines, and extending the mixer and DAC with the additional data lines.

This basic approach (though details of implementation obviously differ) went into the early Ensoniq 55xx chips which were used in high-end 1980s synthesizers and the Apple ][GS, having been designed by the same guy responsible for the SID.

[commodorejohn]

64K samples for a cyclical waveform is probably hella overkill, though, at least for the OP's purposes. (Plus, it means loading new waveforms will take non-negligible time.) For simple chiptune-ey timbres, 16-32 samples for a single waveform cycle is quite sufficient, and Garth's suggestion of 256 samples is absolutely spacious.

I mean, in a hypothetical system with a master clock rate of 5 MHz, a cycle of middle C is only ~19K sample periods long to begin with, which means that over a third of the samples would be completely wasted anyway. And that's supposing that you don't time-multiplex the same hardware over multiple channels, in which case it gets even more inefficient.

(Of course, a large master wavetable that individual voices can use samples of different lengths from is the most balanced compromise in this situation - I know the Korg DW-8000 did this, switching to progressively downsampled versions of its basic waveforms as oscillator pitch moves up the scale, and I wouldn't be surprised if other wavetable designs do as well, since it also has the advantage that the higher-octave samples can be properly downsampled without having to have the hardware do so in real time. Provided that possible sample lengths are limited to powers of 2, it's not difficult to implement in hardware, either.)

[GARTHWILSON]

commodorejohn wrote:

I mean, in a hypothetical system with a master clock rate of 5 MHz, a cycle of middle C is only ~19K sample periods long to begin with, which means that over a third of the samples would be completely wasted anyway. And that's supposing that you don't time-multiplex the same hardware over multiple channels, in which case it gets even more inefficient.

If you produce 16K samples per second, a cycle of middle C would be about 61 samples.  16K per second, if the phase-2 rate is 20MHz, is a sample every 1250 phase-2 cycles, or one very roughly every 300 instructions.  The ISR should handle all the sounds produced every time it runs; IOW, you only have one timer interrupt for this, and every time the interrupt hits, all the samples are spit out, however many channels you have, or possibly summed channels, then you prepare the samples for the next run.  The reason to do it in this order is to keep conditional branches in the computations from producing jitter.

[hoglet]

commodorejohn wrote:

64K samples for a cyclical waveform is probably hella overkill, though, at least for the OP's purposes. (Plus, it means loading new waveforms will take non-negligible time.) For simple chiptune-ey timbres, 16-32 samples for a single waveform cycle is quite sufficient, and Garth's suggestion of 256 samples is absolutely spacious.

When Ed and I were messing with the Acorn/Hybrid Music 5000 system a couple of years ago, we extracted the waveforms of the default voices. You can see them here:
https://github.com/hoglet67/Music5000/w ... efinitions

There are 128 samples for each waveform.

Here's a few notes from further down that page that talk about how the waveform generation works:

Code: Select all

These three 8-bit registers combine to give a 24-bit frequency register.

The Music 5000 runs off a 6MHz clock and takes 128 clock cycles to update all channels. This means each channel is updated at 46.875KHz. Every time the channel is updated, the 24-bit frequency value is added to a phase accumulator. The top 7 bits of the phase accumulate (which look like a ramp) are then used as in index into the 128-byte Wave Definition.

Here's an example.

Assume the Wave Definition contains a single cycle of a sine wave, and you want to generate a 1.0 KHz tone.

The frequency register needs to be set to:

2^24 * 1.0 / 48.875
= 343267
= &053CE3
So:

Frequency Lo = &E2
Frequency Mid = &3C
Frequency Hi = &05
Bit 0 of Frequency Lo must be zero, or the channel is disabled.