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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

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.

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...)

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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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.


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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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.

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.)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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: