GameBoy Wave Channel Synth

[m00dawg]

Soft moved/continued from here.

In brief I'm trying to make a Eurorack module which implements the concept of the GameBoy's wave channel with reasonable accuracy. Like the GB, initially I'll have a 4-bit/32-slot wavetable which you will be able to see on an OLED (or hopefully eInk) display and "draw" using some tactile switches and a rotary encoder. It will support V/Oct plus a tune knob.

If I get this far, next step is to store the wave in flash (easy enough I'm just not worrying about it yet). Future plans would be for 8-bit waves, a non-morphing wavetable bank (like you can do in LSDJ), saving multiple waves / banks, and perhaps a separate LSFR noise oscillator. The LSFR probably wouldn't need a display.

As best as I understand it the GB wave channel used a timer to control how often to increment the position in the table which was then written to a 4-bit DAC. Higher pitched notes resulted in a shorter timer and, subsequently, marching through the array quicker thus increasing the pitch. That's really all there is to it and I find it a rather clever design. Sort of almost like a reverse sample and hold kinda. Intriguing concept given in the digital domain fixed sampling rates are by far the most dominant means I think of when thinking about audio.

To actually get this to work, I came up with several solutions as I ran into obstacles and found other potential ways of doing things. Not sure which I'll go with yet, but they are:

• Electro Smith Daisy using a timer to control the wave updates which, in turn, updates a value which the AudioCallback is reading from. This means there will be artifacts (I wasn't planning on doing liner interpolation)
• Using the Ornament and Crime (a uO_C in my case) which uses a Teensy to update the 12-bit DAC via a timer similar to the GameBoy. Custom firmware because O_C by itself has a fixed sample rate like the Daisy, but is only 16.67kHz
• Using a Teensy 4.0 with an SPI DAC (like O_C but with the OLED display connected to I2C). Given the high speed of the Teensy and the high speed of the DAC, I expect minimal jitter/artifacts using the timer method
• Finally, which is sort of becoming my favorite option, using a Teensy 4.0 with a R-2R discrete DAC or perhaps a parallel DAC IC. This feels closest to how the GB might work (though certainly isn't exactly the same)

I have simple implementations of all but the O_C. I have a uO_C from Calsynth and a Daisy SM in the mail. If I can get some sort of implementation on the O_C that might be ideal, and I might try a similar approach as I was thinking on the Daisy just to see if I can make it make noise. I plan on buying up a Teensy 4.0 to try as well once I put the part list together so I can grab all that at once.

Source code is here

And some cross-posted forums posts here:

• Original MW post (discussing if there was a way around O_C's fixed CV update rate), here
• Post on the Daisy forums on how ways I can get something similar on the Daisy (noting it has fixed speed DACs) here (although I got some excellent help on the Daisy Slack space I need to port back to that post and push to the repo)
• Post on the Teensy forums on doing Aruino PORT style fast writes here

[pld]

Sounds like a job for timers driving DMA -> SPI?

• Finally, which is sort of becoming my favorite option, using a Teensy 4.0 with a R-2R discrete DAC or perhaps a parallel DAC IC. This feels closest to how the GB might work (though certainly isn't exactly the same)

Maybe look into the T4.0 FlexIO. I only skimmed over it (because it wasn't relevant to porting o_C drivers) but with some hand-waving it might a better way of driving GPIOs via DMA.

[commodorejohn]

Intriguing concept given in the digital domain fixed sampling rates are by far the most dominant means I think of when thinking about audio.

That's really based on a post-standardization mindset - it wasn't until PC sound cards settled on divisions of the CDDA sample rate that that became the dominant approach to personal-computer audio. The Amiga, f'rexample, had audio channels with independent rate controls. (Though even in those systems, as with the GameBoy, they were all limited to convenient integer divisions of the master clock rate.)

[m00dawg]

[/quote]

Sounds like a job for timers driving DMA -> SPI?
...
Maybe look into the T4.0 FlexIO. I only skimmed over it (because it wasn't relevant to porting o_C drivers) but with some hand-waving it might a better way of driving GPIOs via DMA.

Oooh yeah DMA would be interesting! That'd be new to me so could be a fun project to figure that out on. There wasn't a ton of info by searching around but I did run into this lengthy and helpful description on how to use it here.

Intriguing concept given in the digital domain fixed sampling rates are by far the most dominant means I think of when thinking about audio.[/quote
That's really based on a post-standardization mindset - it wasn't until PC sound cards settled on divisions of the CDDA sample rate that that became the dominant approach to personal-computer audio. The Amiga, f'rexample, had audio channels with independent rate controls. (Though even in those systems, as with the GameBoy, they were all limited to convenient integer divisions of the master clock rate.)

That's a good point! I never had an Amiga alas though I did grow up on trackers, it was on the PC side of the house where indeed I was already using an SB16 and later a Gus PnP. Sample rates and, in particular, interpolation, wasn't something I thought much about. I recall thinking "Oh! Interpolation sounds better so I'll use it"

What I like about the independent rates is it seems quite a bit simpler and doesn't require interpolation at all albeit the accuracy, to your point on integers, might suffer. Daisy's audio engine uses a bunch of floating point math for instance although, like the PC sound cards, the audio DAC only supports fixed sample rates.

[commodorejohn]

The biggest bonus for independent sample rates, IMHO, is that any aliasing noise you don't remove (by interpolation or other filtering) at least has a tangible relation to the fundamental frequency of the sample; the Amiga is a crunchy, lo-fi beast, but it sounds damn great for it. Systems where everything is resampled to a single rate, less so.

[m00dawg]

Makes sense and kinda explains perhaps why the wave channel on the GB sounds so good (relative to what it is I mean).

[pld]

Oooh yeah DMA would be interesting! That'd be new to me so could be a fun project to figure that out on. There wasn't a ton of info by searching around but I did run into this lengthy and helpful description on how to use it here.

Heh, I'll have to read that to see what it's actually good for

There are a bunch of timers/PWM, events, DMA, and the xbar to link things together so I'd be surprised if there's not a fun solution there somewhere.

Since the onboard DAC is unused by normal o_C (exception: Plum variants) you could also use it from an app. E.g. I'm pretty sure the PDB isn't used by anything, so PDB->DMA->DAC should work and be independent of main sample rate (of course that doesn't come out the jacks then, but...)

[atomd]

I'd definitively not recommend R2R ladder as DAC. If you add buffer powered form clean power (to remove switching noise from uC) and proper domain crossing to not pollute clean power supply you'll get much worse jitter than by using quartz timed uC and external SPI DAC (SPI introduces constant latency that 1. can be compensated, 2. shouldn't matter as it's const).

Driving external DAC via circullar DMA controlled by TIM seems like perfect solution to be coded in 2 evenings. You put wavetable in ram, directly in DACs format and change output tune simply by reconfiguring DAC.

[m00dawg]

I'd definitively not recommend R2R ladder as DAC. If you add buffer powered form clean power (to remove switching noise from uC) and proper domain crossing to not pollute clean power supply you'll get much worse jitter than by using quartz timed uC and external SPI DAC (SPI introduces constant latency that 1. can be compensated, 2. shouldn't matter as it's const).

Driving external DAC via circullar DMA controlled by TIM seems like perfect solution to be coded in 2 evenings. You put wavetable in ram, directly in DACs format and change output tune simply by reconfiguring DAC.

Indeed I have a solution that essentially does that. I can't validate the code yet as I still need to get all the parts Actually both solutions use a timer, it's just whether or not I'm updating a DAC via SPI or parallel ultimately.

On that note, curious about the jitter. I would have thought it better since there aren't 3 frequencies to mess with (uC clockspeed, SPI bus speed, wavetable timer speed). I would imagine the latency for SPI is low enough not to be discernible at audio rates so no real problem there. The jitter being _higher_ for an R2R though I don't follow as well. Are you referring to the settling time? That does seem to cause harmonics in looking at one video using a discrete solution. Those were removed by an op-amp (which I don't follow as to why).

I summed up the costs to make a discrete solution and it's like $20 vs $7 for a parallel DAC with latching (which might help with the jitter you mention perhaps?) and multiple channel support (hello LFO - which for this app amounts to basically a 32-step sequencer, or sub-osc!). I think even less for an SPI DAC.

A parallel DAC, at least I think, is closer to how the GB probably worked. I haven't found schematics or anything to verify that though so might be completely wrong here.

There's also the pure software solution using, say, the Daisy. In fact a colleague at work gave an amazing talk at StrongeLoop several years ago for how he made a Hammond soft-synth on a Teensy. The talk covered how to generate oscillators and interpolate things very very well and is a solution I'm still evaluating, though would be very different and I think in some ways almost too clean without doing extra work. Part of what I want to try and capture is that gross aliased sound you get on the WAVE channel. When coupled with say rolling over a waveform you can create some gritty and growly awesome sounds.

I actually thought about doing both approaches as sort of a "bake off" or paying homage to the origin Pokemon games and have a Red and Blue version. Red being the Teensy + DAC (or a gritty aliased version on the Daisy though one that I don't think would be quite as accurate to the original) and Blue (a software clean version with aliasing removed with interpolation, etc.).

[m00dawg]

Evening update. Sort of a build log I suppose.

I've been trying to get enough components to breadboard some things out. Currently this is for the Red option noted above. I'm using a 2-channel TLC7528 8-bit DAC and TL074 4-channel op-amp. The second DAC channel is sort of a bonus I'll need to think about (single channel DACs were basically the same price) and as noted above I was thinking an LFO or sub-osc. Thinking that input would not be AC-coupled (the main one will be) and I could have a sub/lfo switch or something, I dunno.

Anyways while trying to figure out all the components, I underestimated how much effort it may take to work on the (currently single) CV input - the v/oct. I came up with a few circuits to provide a usable 0-5V (5 octave) range:

The top one avoids negative voltages but doesn't seem to go all the way to 3.3V and I suspect would require some sort of software adjustment look-up-table to map the 10-bit values correctly to V/Oct.

The bottom one seems MUCH more accurate between 0-5V but allows for small negative voltages (around -0.3V) which I thought might be a problem. I know Arduino's have some negative voltage protection but not sure about the Teensy. I can add a diode after the voltage divider and that solves that but I noticed that changes the value of say 4.9V and seems like it's less accurate (which makes sense given the diode is gobbling some voltage).

All this works in the simulator but I looked at a ton of designs, including Eurorack specific ones (such as some Mutable stuff as well as O_C) and they're all different and some did _not_ work as I expected. Many tie the op-amp to 3.3V but in the simulation I was having trouble getting all the way up to 3.3 doing that? And I have 2 available channels to the TL074 which is powered by +12/-12V so I wanted to come up with something else (or consider using another opamp though I was hoping to avoid that). A link to the circuit is available here.

Schematics of the rest of the design (noting I'm not buffering any of the inputs given the above) is here:

schematic.pdf

(80.44 KiB) Downloaded 6 times

[pld]

All this works in the simulator but I looked at a ton of designs, including Eurorack specific ones (such as some Mutable stuff as well as O_C) and they're all different and some did _not_ work as I expected. Many tie the op-amp to 3.3V but in the simulation I was having trouble getting all the way up to 3.3 doing that?

One detail is that it's a rail-to-rail opamp used (at least for o_C and afaik most of the Mutable designs) so it gets very close to 0 and 3.3V, or "in practice close enough". But maybe as a not-really-a-hardware-guy I've just gotten so used to the "summing -VREF and CV at negative input" that anything else seems overly complicated and someone can correct me

[m00dawg]

Oh right! I was too much in the weeds to think about rail to rail OPAs even though they were right in front of me while diving through Mouser. Good point! That might be still an option to consider then, at this risk of a higher parts count (but if it's reliable, perhaps worth it).

I also looked up the datasheet for the Teensy 4.0 chip. Max tolerance for GPIO appears to be -0.3 to 3.6V. The means my second circuit could only tolerate about -7V though if I replace the top diode with a germanium and the bottom with a shottky that goes up to more than -10V and still seems fairly accurate from 0-5V. I'm not sure if that's the "right" way to do it but, at least with the simulator it covers the expected range without hitting the max allowed -V rating of the GPIO pins....in the simulator (so real life of course I'd expect may very well be different).

Heck I even thought about moving back to an 8-bit platform (like the Teensy 2.0 or a similar Arduino) to see if I had more wiggle room since for this sort of brute force option I don't need a crazy fast uC. For the Atmega 32U4 it's -0.5 to 5.5V so still pretty narrow.

I tried to figure out in the simulator the result of summing -VREF (-12V in my case) and CV at the negative input would do but I think I'm missing the other half of that puzzle. That did lead me to see if I could find the Daisy schematics again. The SM isn't yet available but the Patch is and indeed they are doing something similar. That'll be something to play around with too then!

This is one big nod to the Daisy Patch SM since it is only $40 (a Teensy 4.0 is $20-ish) and has all the glue though tends to push towards a more software solution where I'm having to interpolate the 4-bit/32-slot wave and use a modern high quality DAC. I can avoid that by talking with the hardware directly and can then use the 12-bit SPI DAC but I've gotten a bit stuck there since the SM schematics aren't available and so it's a bit harder to infer how the hardware is setup (I'm guessing it's similar to the Daisy Patch but that's an assumption).

[m00dawg]

aha! So if I use an "ideal" op-amp in the simulator I can get rail-to-rail behavior. I looked up Daisy Patch's reference design and it indeed sums the CV in with a -10V AREF and it seems to work. There's some magic going on that I do not yet understand clearly. I say magic because the significant of the 66k5 resistor - changing that around changes things fairly significantly. Looking around for an explanation of how this is working. So far this seems like it may answer some of my questions (I need to spend time working out the equations though).

Here's the simulator layout (which is also available here):

Likewise the Daisy Patch schematics are here.

[m00dawg]

Moved the CV input convo out to its own thread here as I thought that might be a good general topic and can keep this one relevant to the actual synth itself.

[atomd]

Rail-to-rail op-amps are mostly used as simpler limiters to make sure incoming CV won't exceed power supply rails op IC.
Active clipping like the one you showed suffers from op-amp saturation recovery. You need to add quite a few more components to eliminate that. It's simpler to just clip with schottky diodes or RRO op-amp.

SPI clock is tied to core clock on most uc so you don't have jitter between them. Jitter in R2R ladder comes from secondary buffer powered from clean power. You need either opto-couplers or high value (relatively) resistors to couple data but more importantly to couple latch signals that'll introduce variable jitter.

DAC ICs implement this domain separation using variety of clever techniques that reduce this jitter a lot (sub ps usually). It doesn't matter if it's parallel DAC or SPI DAC. what's important it that it has separate latch signal and it let's you remove data transfer latency/jitter and core jitter from equation. Everything is timed by single timer.

[m00dawg]

Makes sense. I think anyway. In fact, I started thinking about this and may actually switch from making the audio out AC coupled and use a similar circuit to map the 0 to 5V output of the DAC to -5 and 5V to bring it to line level. This means one output can be used for audio rates or LFO/sequencer with the latter being not ideal if connecting the output directly to speakers (for some reason) but given, at least for this solution (versus the Daisy one), it won’t be of much use without a VCA, I think it may be a worthy trade-off.

DAC-wise, I think you've convinced me that an SPI DAC makes the most sense. Better availability and high accuracy, although the latter isn’t all that important given the application. In fact the main goal is something that sounds as close as I can reasonably get to the quirks of the GameBoy’s wave channel. Fidelity isn’t a requirement and in fact to some degree isn’t something I even want

Trouble is, I found a schematic for the GameBoy and it looks like the audio generation parts are all integrated into the custom Z80. That makes things a bit of a black box.

[emmaker]

DAC-wise, I think you've convinced me that an SPI DAC makes the most sense. Better availability and high accuracy, although the latter isn’t all that important given the application. In fact the main goal is something that sounds as close as I can reasonably get to the quirks of the GameBoy’s wave channel. Fidelity isn’t a requirement and in fact to some degree isn’t something I even want

Yes a SPI DAC is a good thing.

When talking about fidelity even though it's not a requirement it's easier to take something good and make it sound bad than it is to take something bad and make it sound good. So you have a lot more leeway/options starting with something decent sounding.

[m00dawg]

When talking about fidelity even though it's not a requirement it's easier to take something good and make it sound bad than it is to take something bad and make it sound good. So you have a lot more leeway/options starting with something decent sounding.

Yeah that's a fair point, especially in Eurorack world where this is sooooo many ways to augment the sound.

Given we have some amazing wavetable modules (Osiris is the one I picked up), it's kinda already possible to try and turn an Osiris into GB. The fidelity knob doesn't quite do it but other ways (maybe bitcrush via S&H). I am intrigued by how close I can get to "that GB sound" by adopting the variable sample rate approach. But I do still plan on the "bake off" between Daisy and this solution. On the Daisy it's closer to the idea of "starting good, make it bad." I kinda have to do it that way because the aliasing I'd expect on the Daisy (due to sample rate mismatches between the wavetable rate and the audio sampling rate) isn't the same as I would get via the GameBoy.

Some other plans is to bake in a coarse VCA to simulate the coarse volume options of the GB. I also realized that, at LFO speeds, I basically made a step sequencer so could be fun to exploit that - even simultaneously. I just need to add a trigger input and a 2 channel DAC (which I could also use as a sub osc maybe). But first things first is just seeing if I can make the concept work and go from there.

[commodorejohn]

Some other plans is to bake in a coarse VCA to simulate the coarse volume options of the GB.

I don't think you'd need a whole separate VCA for that - the volume control on the GB wave channel is very crude, and I'm pretty sure it just shifts the samples right 0-2 places before sending them to the DAC. (Which would also have a bit-crusher type effect on the output, as the LSBs are shifted off the end and discarded.) Should be dead easy to do if you're already hand-feeding samples to a separate DAC.

[m00dawg]

Oooh yeah super good point. I should've remembered that - I used that wiki as the basis for how I was approaching the code. And yep that would be a "better" approach (not in audio quality for sure, but for capturing the GB's sound) than using a VCA. Great point!

In related news I fired up the Daisy Patch SM to take it for a spin. Alas it doesn't seem like I'm doing something quite right using the DaisyDuino library. The TripleSaw example application doesn't produce any sound (when powered by USB or via Eurorack power) which uhh seems like a problem. My own app didn't make any noise either. I found what might be a bug in the library although that bug I don't think affects the audio DSP so I'm not sure what's going on there.

[m00dawg]

Soooo maybe new plan for the uC. I noticed Adafruit has the ItsyBitsy lines with the M0 having 1 on-board DAC and the M4 having two! There's $2 difference between them but basically the same pinouts. So I looked at my basic code to see if I can port it over (noting the timers are different than the Teensy 4.0 or Daisy) and I managed to get it to compile at least! At 120Mhz, it's not nearly as fast as the Teensy 4.0 - and it uses the M4 vs M7 architecture, but for the variable rate clocking I wanted to do, that's plenty.

This also simplified my code as now I just do an AnalogWrite in my timer callback, though I'm not sure if that will actually work as expected and may have to use DMA (especially if I wanna do the things like I mentioned before with a second output to serve as an LFO or sub-osc).

Updates are here:

https://gitlab.com/m00dawg/gave/-/tree/main/gave-m4
https://gitlab.com/m00dawg/gave/-/tree/ ... ad/gave-m4

PDF of the schematic (from KiCAD) is here:

gave-m4.pdf

(45.31 KiB) Downloaded 11 times

These probably aren't the final schematics but are enough for me to finally place a parts order and try things out on a breadboard. Also it's definitely not the final code (it's not even complete though the basic idea the forms the core of the GameBoy DCO idea is there).

[m00dawg]

Here's the latest board layout:

I made a few changes to the schematic (a few resistor values were off, added reverse polarity protection, a few other things). Completely unrouted at the moment but I have the components roughly were I think that'll need to be.

It's 10HP at the moment. Wondering if I can get away with 8HP. I do like that there is a big of room at the bottom for some future options (like some of the ones I mentioned earlier). I ordered most of the BOM to try all this on a breadboard so at this point I can take a breather and wait for parts to come in. I don't expect I'll get super serious about the board layout until I know the breadboard version works.

[Kelaifu]

this is shaping up really nicely, I think 8HP should be easily possible too, you can put the teensy 'behind' the potentiometers on the other side, there's room in between the pins, there's also room behind the screen for the power header etc too.

[m00dawg]

Yep that's similar to what I was thinking too. Minor thing I didn't consider, the PCB itself has to be smaller than the front panel so the above board has more vertical space than it should. But I still think it's doable to shrink down. I want to avoid SMD to make it easier for folks to build but that would shrink things way down too.

[Kelaifu]

as long as you keep the PCB central to the front panel, you are ok with a 107mm high PCB, most people try to keep it to 100mm to stay within the average PCB manufacturer's cheapest price bracket.