I wasn't suggesting it should all be used on a single sample! 64KB is enough to load lots of simple instruments, which could be one-shot percussion or voice samples (set the wrap behaviour so that the pointer halts at the end) as well as periodics.

But obviously the counter has to be able to access the entire address space of its attached memory, or some of the latter *definitely* goes to waste.

Well, yes in the sense that memory the voices can't address is memory that has no business being in the sample side of the architecture at all. But also no, in the sense that bits that can't directly serve as address bits to the sample memory can still serve a purpose as fractional values that allow for greater precision in frequency selection, which is a non-negligible factor in musical applications (you don't have to go very far up the scale in simple integer-clock-divider counter designs before the closest available output frequencies start being measurably off from the correct notes.)

Additionally, you don't necessarily need to max out the possible size of the sample memory, depending on other design choices. If, say, your maximum loop length is 256 samples, and your hardware design allows for a total of 8 8-bit voices, there's really no point in providing a sample memory larger than 4 KB, unless you're using techniques that change voice samples often enough that sample-copying overhead beomes a significant factor.

Right, which is why I suggested a 20-bit counter of which the top 16 bits form the sample address, and the bottom 16 bits are addressed by the variable increment. The top 16 bits would also be where you should attach the wrap comparator and subtraction.

In practice you're unlikely to find a 32Kbit RAM to implement a 4Kx8 memory anyway, rather 64Kbit and up. If it's convenient to implement a 64KB memory - why not?

True, but you could implement it as 2x2KB RAMs, which are still readily available (if not exactly cost-effective at large volumes.) Or kick it up to 8KB and get it on a single part instead. (In fact, 8KB for 8 voices with a maximum sample length of 512 and minimum of 8 would leave a generous 64 bytes leftover for configuration registers, if you chose to do it that way.)

As for the "why," it's all dependent on the design strategy and how the OP wants to interface things. It's probably simpler to provide a fixed 4KB memory region that the synthesizer hardware uses than a mappable 4KB window into a larger region. Having each voice use a fixed range of addresses instead of a semi-arbitrary address within a large wavetable also means that's one less register for the software to keep track of, or if a select register is provided, it's at least significantly fewer bits. And going for a fixed wavetable region rather than (say) having the synthesizer hardware DMA samples from main RAM means there's no cycle-stealing going on outside of CPU accesses to wavetable RAM, if that's a thing the designer cares about.

I'm not saying that one technique is the only and inevitable ultimate and the other must ever grovel before it. I'm just saying that there are merits to both strategies and it depends to a significant degree on what the designer wants.

_________________
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?

Quite right, and that's one of the advantages of the phase-accumulator design. I was speaking more in terms of simple linear down-counter designs like (for example) the NES pAPU, where the counter is simply loaded with a value and then decremented until it reaches 0, at which point the position within the waveform is incremented. In that system, output frequencies can only be even divisions of the master clock rate, so that there are only two possible frequencies within an octave of the maximum rate, four within two octaves, etc. etc. But really my point is just that extra bits can still serve a purpose even if they don't get directly hooked to the wavetable address.


True enough - there's a variety of benefits provided by multi-sampled waveforms. You could also do something like assign completely different timbres to the higher and lower ranges of a channel that the music alternates between a bass part and a treble part, to reduce the overhead of making the most of limited polyphony, or anything else you can think of.

_________________
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?

It's notable, I think, that the Music 5000 has a 24 bit phase accumulator. I think that's an indication that 16 bits isn't enough. According to this, you'd need 23 bits if you were clocking samples at 48kHz. Of course, standards for 'musicality' are variable, unless you're selling your kit as a musical instrument.

_________________
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?

Or slave one phase-accumulator's increment rate to another wavetable, for a much more space-efficient implementation.

I think this question stems from my ignorance of some implementation details (I looked up a few data-sheets of various counters and was still confused) but if the phase accumulator is tied to the same Φ2 as the CPU, doesn't that clock-speed impact the lowest representable frequency? Taking Garth's example, using a 16bit accumulator to index into an 8bit memory address space, the slowest sample period is 1 sample per 256 16bit increments. But isn't the speed of that incrementation dependent upon the Φ2? It seems to me like you could easily overshoot and make it impossible to represent the lower frequency range. I assume that carefully adjusting the Φ2 and the number of bits used by the counter could result in something that’s “just right,” representing the necessary range of frequencies, but I don’t think that’s what everyone is saying should be done. Garth mentioned using the interrupt handlers to control when playback happens, but I still need to read the interrupt primer . In any case, I seem to be missing the more elegant solution that would handle this issue!

What exactly is the difference between a circular buffer and a buffer that is indexed by a counter that wraps over? It seems to me that if you’ve implemented the modulo operation that would wrap say, an 8bit address to a 4bit one, you’ve effectively tied the ends of a 16bit wide buffer together, right?


I’ll definitely need help with anti-aliasing at some point. I'm not too concerned now in as much as this design phase is pretty theoretical for me at the moment. Hell, I didn’t even know what was possible when I started the thread! Anyway, my current ‘lesson plan’ is to watch all of Ben Eater’s 8-bit breadboard videos (I’m about half-way through), then reading/rereading the primer. After that I’ll move on to deciding which kind of prototyping material to use, after which I’ll hopefully have a solid understanding of which design to use and why.

_________________
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?

Just for reference, then, this was the page I found:

From Digital Waveform Generation By Pete Symons

_________________
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?

Ah, what I meant by "circular buffer" was specifically for cases where you want to stream audio data continuously from some source, rather than using the sound hardware as an instrument. It's like a more general form of double buffering.

As for concerns about not being able to go slow enough - if you run into that problem in any practical scenario, just add more bits at the less-significant end of the counters.