SVF, clipping and fixes

The SVF and Juno filters still clip, and that's the last big blocker before ordering more voice cards. This incredibly boring post tries to document everything that clips, what the max input levels are and to answer how we can adress it/what solution to choose.

 

Design goals

 

Here are the goals I've decided on after testing everything

 

SVF: 

• Unity gain through SVF (needed for chaining)
• Input: 2.5V max 
• No clipping with normal input
• No clipping with in sync resonance when resonance is < 80% 
• Remove BP gain (to prevent clipping.  NB: removing gain will invert phase and ruin AP/Notch s don't do that!). 
• Redesigned AP/Notch using non-gained BP
• Separate board from Moog filter to be able to change it later. 
• Consider if possible to move AP/Notch on-board 
• In software: Limit resonance to 80% and change taper law to logarithmic 

Juno:

• 50% attenuation through filter (needed to prevent clipping resonance)
• Input: 2.5V max in normal operation
• No clipping with input <= 2.5V, including in sync resonance
• No clipping with input < 10V if not using internal resonance (or specifically in sync reso) 
• Clipping OK if fed for example in sync reso from SVF and using in sync reso internally
• Keep current phase output to match Moog
• Move post filter gain on-board (to make adding a soft clipper possible later without changing mainboard)

Pre filter mixer:

• default to 2.5V max output
• allow 5V max output if cutting or soldering jumpers, for future-proofing - must put two 100k in series for normal operation, and have solder jumper for one of them to reduce resistance to 100k.

Output mixer:

• add 2x gain for Juno, to allow making up for attenuation? Default to unity gain in software. May clip when extra gain but that's a choice, not a bug. Can consider doing this with two 47k in parallel and a cuttable jumper to make gain drop back to normal

 

Input should be max 2.5V

This goal massively reduces clipping. It can be achieved either through changing the internal gain in the mixer OR by changing the wet/dry pan CVs. The CV generation is on the main board and unfortunately fixed, if we should change it we would need both to be 0-2.5V and 2.5V to 0, which isn't possible without another HW revision. The on-mixer change IS possible with the new slim version, perhaps even a switchable version could be made.

If doing the change on the mixer, we can increase the input resistors to 200k, or reduce the gain resistor for the two outputs. 

 

Tests

 

Cell 1 

Without resonance 

Tested with a direct input through a 100k resistor, no resonance, full filter sweep:

Max input triangle

LP1: -9.6 to 8.5 in, -8.5 to 9.3 out (but with slight compression)

HP1: -9.7 to 8.5 in, -9.3 to 8.6 out

BP1: -9.6 to 8.5 in, -4 to 5.5 out (no clipping at all)

BP1 gained: no clip either

Max input saw

LP1: -9.6 to 9.4 in, -9.1 to 8.9 out

HP1:-4.9 to 4.7 in, -4.9 to 6.1 out

BP1: no clip, also gain is not possible to measure properly

BP1 gained : -6.9 to 6.7 in, 

Comment: HP is very high above 0 but not very much below. 

Max inputs square

LP1: -9.1 to 8.6 in, -8.6 to 9.1 out. Locks up with too high input!

HP1: -4.3 to 3.9 in, -5.9 to 4.8 out.

BP1: No clipping 

BP1 gained : -6.8 to 6.3 in, -9.3 to 0.8 out (but not proper measurement as no square out)

With resonance at 0 (= full):
- NB: The clipping we see is always at 10V so it may be that it clips in the probes/logic analyzer before actually clipping. Op amp clipping is still fairly close though.

With resonance 

square: 

In general: self oscillation in sync, with freq as low as 4 x base freq, may clip. 

Also, self resonance at base frequency, once started, is unaffected by input amplitude. 

LP1: 

"normal reso": -9.8 to 9.7 in: -4.4 to 4.9 out

"in sync reso": Self reso, in sync, clips slightly. Independent of input signal amplitude

BP1:

"normal reso": -10 to 10 in: -4.8 to 4.9 out

"in sync reso": Self reso, in sync, clips slightly. Independent of input signal amplitude

HP1:

"normal reso": -10 to 10 in: -5.2 to 5.3 out

"in sync reso": Self reso, in sync, clips slightly. Independent of input signal amplitude

 

Saw: 

LP1:  

"normal reso": Self reso clips slightly when at a multiple of signal frequency, is not affected by changing input amplitude. When more than four times base frequency, no clip. For higher frequencies: -9.5 to 9.3 in: -3.5 to 5 out.

"in sync reso": -4 to 3.8 in, -10 to 10 out.

BP1:

"normal reso": -9.3 to 9 in, -2.5 to 2.5 out

"in sync reso": -4 to 3.8 in, -10 to 10 out, very slight clipping

HP1:

"normal reso": Clips when in 'sub sync', four times base freq for example.  

"in sync reso": -9.3 to 9 in, -4 to 3.8 out

Tri

LP1: 

"normal reso": -9.5 to 8.5 in, -2.9 to 1.9 out

"in sync reso": Hard to get a stable error, but clips a tiny bit sometimes when input is -9.5 to 8.5

BP1:

"normal reso": veldig lav output

"in sync reso": Hard to get a stable error, but clips a tiny bit sometimes when input is -9.5 to 8.5

HP1:

"normal reso": -9.9 to 8.5 in, -3.8 to 3 out at most.

"in sync reso": -2.5 to 2.0 in - very hard to get a stable error but clips a tiny amount at almost at any input. 

 

Cell 2 

Without resonance 

Tested with a direct input that has not been through Cell 1. First, no resonance:

Max input triangle to cell 2 through 150k that does not clip internally during normal filter sweep:

LP2: -9.6 to 8.6, out as -5.4 to 6.4 (inverted)

HP2: -9.6 to 8.6, out as -6.2 to 6 (inverted)

BP2: Doesn't really clip visibly but mostly because it never passes a clean triangle 

  

Max input saw to cell 2 through 150k that does not clip internally during normal filter sweep:

LP2: -9.7 to 9.5, out as -5.4 to 6.4 (inverted)

HP2: -8.1 to 7.9, out as -4.6 to 6.3 (inverted)

BP2: Doesn't really clip visibly but mostly because it never passes a clean triangle 

 

Max input square to cell 2 through 150k that does not clip internally during normal filter sweep:

LP2: not possible to see any clipping since output is also completely square. Output stops changing when input is +/-10V

HP2: -7.3 to 7.2, out as -6.4 to 5.3 at start, slants. (inverted)

BP2: Doesn't clip visibly, 10V in is -5.9 to 5.8 out.

 

So, max -7.3 to -7.2 in for a clean signal for all waveforms, that does not clip normally. 

 

With resonance 

With resonance at 0 (= full):
- Clipping is always at 10V so may be clipping in probes

square: 

LP2, BP2: 

"normal reso": -5.3 to 4.9 passes 

"in sync reso": -3.9 to 3.6 passes 

HP2: 

"normal reso": -5.4 to 5.8 passes

"in sync reso":     -2.7 to 2.4 passes 

 

Saw: 

LP2: 

"normal reso": -6.9 to 6.8 

"in sync reso": -6.7 to 6.6 

BP2:

"normal reso": -8.6 to 8.5 

"in sync reso": 5.7 to 5.5 (a bit unsure about this one)

HP2:

"normal reso": -6.4 to 6.2 

"in sync reso": -4.3 to 4.2 

 

Tri

LP2: 

"normal reso": +/- 10V approx

"in sync reso": -5.5 to 4.8

BP2:

"normal reso":: +/- 10V approx

"in sync reso": -4.4 to 3.8

HP2:

"normal reso":: +/- 10V approx

"in sync reso": -4.9 to 4.3

A possible fix, testing

 

Reducing output of mixer to +/- 2.5 instead of +/-5
 

Testing first with a square wave, -2.7 to 2.34 in

Measuring max output

Cell 1 

LP1

Normal: -2.9 to 3.3

Normal reso: < 5x base self osc: max +/-5V, normal reso -2 to 1.7 max

In sync reso: clips very slightly

HP1

Normal: -6.5 to 6.5 at max normal, but some kind of self oscillation when cutoff is too high

-- This is probably the param to watch, if this does not clip we can perhaps accept that reso clips? 

Normal reso: Up to around +/-6 at extremes.

In sync reso: Clips slightly

BP1

Normal: Around +/-2.5V (Normal with gain: -3.5 to 4)

Normal reso: Around 2-3V (With gain: Up to 8 but never clipping)

In sync reso: Clips slightly (With gain, clips more but still only at sync)

AP: 

-7.9 to 7 - but uses gained BP. Try again with non-gained BP?

 

Cell 2

 Measured at the output of the SVF, before the post filter gain stage. The post gain stage is 100/65 for LP and HP,  100/100 for cell 1 direct and 100/60 * 100/65 for BP

A 150k input resistor is used instead of 100k + 56k during testing, so gain is very slightly different. 

LP1 + LP2

Normal: -1.9 to 1.85

Normal reso: Above sync reso there are still tops up to 8V, but most max out at around 5 and "normal reso" is something like 2.5V

In sync reso: Slight clipping. Below sync frequency the output still high, up to 8.

HP1 + HP2

Normal: -4.75 to 4.6

Normal reso: Up to 8.5 at extremes. Never clips

In sync reso: Clipping starts much earlier than for HP1 alone

BP1 + BP2

Normal: -0.9 to 1

Normal reso: Maxes out at 7.5, more normal at 2

In sync reso: Clips the same places as BP1 but slightly harder

BP1 gained + BP2

Normal: -1.5 to 1.5

Normal reso: Maxes out at 9 but never clips

In sync reso: Clips slightly earlier.

 

Lower resonance

Resonance set at 0.2 in software (which is really 80% since pot is backwards).

Input: 2V square wave. 

Output without resonance: 2.2V

Cell 1

LP1:

Normal resonance: peaks at around 0.8V, flat part at around 0.3V

In sync: 3.2V 

BP1:

In sync: 3.2V 

HP1:

In sync: 3.2V 

 

Cell 2: NB: Raw outputs, no post cell gain: 

LP1 + LP2:

No reso, fully open: 1.5V NB! Means we have to have a post gain that will make in sync output higher!

Normal: 1.5V

In sync: 4.9V

BP1 + BP2 (no BP1 gain, raw output of BP1 fed into Cell 2 through 150k resistor) 

In sync: 5.1V

HP1 + HP2:

In sync: 6.2V 

 

Gain

Gains outside the SVF itself

Post cell 1: 

• BP 1 gain: 1.47 

Post cell 2 gains are as follows:

• Cell 1 direct: 1
• LP 2: 1.54
• HP 2: 1.54
• BP 2: 1.67 * 1.54  (67 to make BP 2 unity gain I guess) 

 

Estimated outputs of cell 2 with gain:

LP1 + LP2:

Normal: 2.31

In sync: 7.55

HP1 + HP2:

Normal:  ?

In sync: 9.55 

BP1 + BP2:

In sync, NO additional gain: 7.85

In sync, WITH additional gain after Cell 2: 13.1 - clips massively.

 

In other words, without BP2 makeup gain, all pass fine.

Also, it's highly likely that a normal output will never clip in a (modified) Juno filter. In sync resonance will however likely clip. 

BP, AP and Notch with no extra gain

To prevent clipping, we reverse the additional gain for the BP output. That also requires changes to the AP and notch circuits: 

The current circuit:

Three resistors must be changed:

• The input resistor to the BP inverter, R151, must be 100k for unity gain
• The unfiltered input to the Notch circuit, R148, must be replaced with an 82k resistor
• The unfiltered input to the AP circuit, R145 and R150, must be replaced with a single 75k resistor 

This leads to an approximate change of approximately -3dB for the BP/AP and notch outputs.  

 

Juno

 

Version 1.1.1 of the voice card has a Juno output gain of 100k/18k = 5.56, as the filter itself attenuates the input to 1/5. 

 

NB: version 1.1.3 of the voice card has changed the output gain circuit: output has a 100/39 = 2.56 gain op amp, so gain through the filter is at 0.5 (NB! Also inverts signal). This means output of core must be around 4V (10V/ 2.56) to not clip, including the in sync resonance. Previous measurements showed that in sync reso could get up to 6V, meaning it clips. This must be retested with a 5V and 2.5V max input.

 

Also, this means that even with a lowered input, we still need to attenuate both SVF and moog to match juno. 

 

Output before post gain:

 

Max input 

square: -1.6 to 1.7 at input of filter, -0.25 to 0.42 at juno output, would be 1.34 to 2.3 after post gain.

Can't get higher than 4.4V in from mixer. Will try chaining.

 

Things that may still clip, at least with 5V input

- 12dB HP filter chained through Juno if juno has resonance turned on - 12dB SVF filter outputs peaks at around 2x input. A 5V signal in will give 10V peaks around the cutoff frequency. This will appear at the Juno input which expects a max of 5V, and will likely clip there.

- SVF: Self oscillation with frequency same as signal base frequency will clip no matter the input amplitude (Cell 1 at least, and at full resonance. Lower resonance and 2.5V input does not clip.

 

Thoughts

 

If reducing to 2.5V max out of mixer, normal input to juno will also be 2.5V. Since we currently don't allow mixing chained signal with "bus B", whatever ends up at juno is what came out of SVF. 

 

The highest "normal" signal through the SVF is HP1 at 6.5, which after the final gain will be around 10V. This will probably still clip in the Juno filter. Test this.

Would reversing the order fix tings? Reducing input to max 2.5V, then reordering? What is the max out of the juno filter, and how would that affect the SVF? Also, what is the effect of changing the order, sound wise? It would require the juno filter to have unity gain (like it does now), so it depends on what happens if input is max 2.5V.

DAC on the same bus as DCO. Also, DCO nightmare...

As I'm preparing to put a 12bit DAC on the SPI bus shared with DCOs and the bit crusher, I had to make some changes to how to communicate with the DCO. 

 EDIT: I've written the code in a way that supports 3 bytes per DAC update so even 16bit DACs are supported in theory. For 12bit DACs, only two bytes are needed)

The DCO expected to receive three bytes with a 9us delay between sends and the CS line toggled only at the end of the last byte.

First I rewrote that, to accept single bytes. Then I changed the format so the first byte started with 1 and then had a fire bit command. The two last bits + 2 x 7 bits from the next made up the 16 bit frequency for example. That way, we can sync on the first byte instead, as it's the only one with a 1 as MSB.

Anyway, the bus can at best run at 4MHz when communicating with the DCO, or else each bit length becomes too short for the PIC16F. At 4MHz each bit is 0.25us long.

I want to run the DAC at 2ch * 48kHz = 96kHz. But if the DCO sends all its bytes in one go, it would take up too much time in a single period, preventing a stable DAC update frequency.

At the same time, I want to run the CV updater and DCO updates at 6kHz (well, ideally I wanted to update the CVs at 12kHz, but I can't seem to get a stable 192kHz interval (CV updating is split into 16 updates, 16 * 12kHz = 192kHz) so I think I have to settle for 96kHz. This fits well with the DCO which cannot be updated faster than 8kHz anyway, so 6kHz it is.

So, I came up with a system of 16 slots (96kHz/16 = 6kHz), each 1s/96000 or 10.4us long. The DAC can send its 3 bytes (with no delay between) in any slot, it would take slightly more than 6us. 

That leaves around 4us. Sending a single byte will take around 2us, so we can let any other peripheral send on the second half of the slot. Also, since DAC and DCO will be mutually exclusive (per channel), the DAC may send at the start and any other device (e.g. BC) in the second half. Also, by separating DCO frequency updates and DCO commands (sync, range etc) into separate slots, we can send both within a single 16slot cycle.

Anyway, I implemented this - and then the nightmare started.

The DCO had massive errors to the slope - every cycle overflowed, the saw was no longer a saw.

I spent almost two hole days debugging. Was it the protocol change, some previously untested code changes to the DCO or something in my controller code? 

Turns out, it's likely a problem with the MikroC compiler (again). When writing two chunks to the PIC internal FLASH rom, one with DAC values and one with DAC slopes, the values one got written to both positions! I am not sure if this started to happen now, but it would be weird if it has been that way for a long time.

The solution is to calculate the slope on the fly (it's simply a subtraction). But when I removed the code for writing the slope to FLASH, everything failed. So now I still calculate and write slopes during calibration, I just don't use it. 

I truly hate the MikroC compiler. I really need to port everything to MLabs.

In the process of figuring out what was going on, a few other things happened. First of all, one of the DCOs got stuck at a single frequency. Turns out, one of the SPI pins got pushed in/up through the board (cold solder joint probably). Then, another DCO simply didn't want to calibrate properly. It took a long time to realize that this only happens at the bottom end of the frequency spectre, around 40Hz and lower. At the moment, I think the DAC simply cannot supply a low enough voltage, so every cycle overshoots.

Then disaster struck. I put the DCO in the programmer backwards, sending +12V into one of the SPI  pins. The MCU still works, but SPI has stopped working so it's trash.

So right now I'm two DCOs short, and I have only one that can be calibrated down to the lowest frequency. Not sure what to do about that, but the others work down to around 40Hz which is good enough I guess. We'll see what the rest end up with.

Oh, and I managed to fix a long lasting bug - when changing to a lower frequency, the first cycle would end early because the previous interval's timer wasn't stopped. It seems to work fine now. 

BTW: I had another weird issue that I didn't get to the bottom of. One of the DCOs managed to reach all the way down to 4-5Hz, while the others only managed 8. I think 8 is right. Maybe the first one ran at half the expected speed (16Mhz instead of 32MHz)? 

BTW2: I first suspected that the overflowing waveform was caused by the interpolation between calibrated points being wrong. It did have something to it, the interpolation will be off by a few percent, bulging towards the end. But not as much as I saw. However, this lead me to try without any interpolation at all, just using the calibrated value for the start. That worked pretty well, it only sags by a few 10s of a volt at the end. Pretty interesting, by doubling the number of measured points we could maybe get away without the interpolation. 

BTW3: There is something strange at the startup of the DCO, when hammering the synth with midi, it feels like the DCO lags/hangs, before suddenly doing all the changes. This has not been investigated further.

Digital oscillators on the XM8

After deciding on creating a wavetable oscillator for the XM8, I've thought quite a bit about the digital oscillator structure. Here is my current solution

 

Two physical DACs

First of all, I will add a new PCM5102 I2S stereo DAC. This has built-in oversampling etc to prevent aliasing-noise. However, in old synths there were a lot of aliasing, which is part of what we now recognize as the vintage sound. I don't think the PCM5102 can recreate this.

However, my initial idea was to use the DAC8830 on the DCO boards for wave duties as well, and have the DCO MCU do the heavy lifting when it comes to wavetable morphing and other interpolation. The DCO DAC was then followed by an analog reconstruction filter.

 

The DCO as a DAC proxy

I now have a new idea. Let's instead use the DCO MCU as a simple DAC proxy. By copying the incoming SPI signal to the output whenever the DCO is in "direct to DAC" mode, the MCU doesn't have to do any work. We could probably speed up the SPI bus to max and easily get 44.1kHz (or 48kHz) sample rate on the DAC. The only thing left to solve is when to interpret the DCO incoming data as bytes directly for the DAC - we could increase bit length to 24 and use the first as command, but perhaps that makes it harder to use Teensy Audio. It should be possible to use custom SPI DACs with Teensy audio so let's hope this works. If not, there is still an available utility pin on the DCO that can be used for mode switching.

We would also have to send the chip select for the DAC, but only after two received bytes, not 1 as on the PIC16F SPI.

We can also get rid of the recon filter, after all the only reason we do it this way is to get the aliasing. Also, it would be possible to reduce the bit depth to 12bit if we want etc.

 

DAC routing

The analog board already has an input for digital waves per DAC, and a switch to select between that and the waveshaper output.

We can reuse that - and in place of the current reconstruction filter, we'll put a second switch selecting either PCM5102 or DAC8830. We also need the circuit to center and amplify the output from the DAC8830. Currently it's at 0 to 3v3. Finally, we need two available pins on the Teensy for controlling the switch.

 

Modifying the v1.0 Digital voice controller 

This requires the use of two additional pins on the recon filter socket - one for the PCM5102 input and one from the Teensy to control the switch. We should also cut the paths from the PCM5102 to the ext input (cut on the digital voice card side).

Summary

It will be possible to use one of three modes per oscillator: DCO, high quality audio DAC or aliasing basic DAC. It won't be possible to combine DCO with the other two at the same time on the same oscillator. I think this is a fair limitation that makes operation of the oscillators simpler - what you see is what you get, if you switch oscillator mode you also switch its output.

  

Wavetable oscillator

I need a more precise sine wave than I have at the moment, with a larger range than I can get from the DCO.

That gave me an excuse to go ahead and create the wavetable/PCM oscillator I've been thinking about - there's a slot on the digital board exactly for this.

My colleague Alexander used a PCM5102A DAC for his project, and after taking a closer look it seems this was the ideal choice for my oscillator as well. Even better, I realised I had a breakout board with that DAC already, from Aliexpress, so I could go right ahead and test it!

Here is my layout:

CLK: GND

BCLK: Teensy pin 21

LRCLK: Teensy pin 20

DATA: Teensy pin 7

 

NB: All data/clock pins have a 22Ohm resistor on them to slightly slow down the edges. This is both suggested by the teensy communit (100Ohm) and the breakout board (22Ohm). 

The rest of the configuration pins are already taken care of on the breakout board, but in any case they are:

 

DEMP: GND (Deemphasis off)

XSMT: +Vpp (Soft mute: un-muted)

FMT: GND (I2S)

FLT: GND (normal latency) - I've made this configurable in my circuit

 

For the rest of the pins, see my schematic: 

I've added two inverting gain op amps that brings the output up to +/-5V. FLT (filter latency) is configurable and can also be disconnected from the control pin by cutting the solder jumper.

 I've already implemented wavetable morphing, through any number of wavetables. I've added the four basic waveforms (sine/tri/saw/square) and converted the Prophet VS wavetables into a format that I can use. It sounds amazing!

Right now the oscillators are routed through the ext pot. I originally intended wavetable oscillator duty to be performed by the DCO circuits, so there's a switch between DCO and waveform after the waveshaper on the analog board.

Now I'm not so sure anymore. It would be nice to not use the ext route. Instead, wavetable-osc could be routed directly to the mixer, and to have separate volume control per osc. Instead of having one channel per wavetable oscillator I could let one channel go to each of the busses. I can mix the oscillators digitally instead, and have digital volume control of them.

This is much more flexible. I can use both DCOs and WT at the same time, or I can make them mutually exclusive in software. The only issue is that DCO and WT have to share the same panel pot, meaning we no longer get knob-per-function if both DCO and WT are available at the same time. Then again, this could also be configurable... 

Moog filter trimming

 At the moment, the moog filter has to be at full output to match Juno. That may change.

 

Also, to get a proper amplitude out, the trimmers has to be set as follows:

4p: 4.95V

2p: 1.67V

reso: 5V.

 

Even with this, the output signal jumps up and down when switching between juno and moog, indicating that it is not properly centered. Check the signal at filter output to see the real centering. 

Startup issues again

I've finally managed to test controlling the DAC more closely from software.

By disabling SPI output from the voice controller to the DAC during DAC power cycling, I was not able to reproduce the error. It simply seems like the DAC - or something around it - does not like SPI traffic while powering up. 

Introducing a delay before talking to DAC, and monitoring the 12V line from the main controller and then disabling DAC output if it goes away (and again, delaying when 12V is reintroduced), we should hopefully fix the issue. 

A little research into the startup problems

TL;DR: The DAC isn't starting up correctly, causing the CVs to either be the wrong value or to fluctuate.

There are two weird things that sometimes happen during startup. 

1) We get massive noise (but with a fixed frequency on the output

2) We get some kind of slew on the square wave, e.g. it is not flat on top.

Not sure if 2 happens at the same time as 1, but 2 can at least happen on its own

 

After a little measuring, I found that

1 comes from the waveshaper. It is present on all inputs but the DCO input is super clean.

2 comes from something between the square wave output of the waveshaper and the input of the bus mixer.

So what's between them? The waveform mixer and the oscillator output switch, but for the moment that's replaced with a jumper - so it's only the waveform mixer. It is implemented directly on the mainboard, except for the VCA chip.

Output on top, output from waveshaper on the bottom. WS looks good 

 

Input at the source mixer on the bottom. Here it's slanted.

The mixer PULA is the square wave input, the square wave amp sits before the pulse output on the waveshaper

This is interesting. The only thing between the waveshaper and the source mix board is that op amp. But the mixer also feeds into it, so maybe some of the other waveforms are leaking through?

Also note that the output wave has some strange spikes on it (the same ones for each cycle) that are not found on the mixer input. Approximately 12? 

 

Here is something more.

When square is slanted, triangle is not aligned:

The triangle does not match up

 

Triangle with a good signal

Trims when slew: 2.0, 2.8V (center, symmetry)

Trims when clean: 2.3, 3.0V (these are also what is expected).

Let's look at the DAC

With slew

DAC ref voltage: 2.1 to 2.386

Output on DAC ref voltage pin, too low and fluctuates

Output on one of the channels, is too low

When clean

DAC ref voltage 2.5V 

DAC ref voltage is perfect

Output on the same channel as above. Looks good.

 

 

DAC +5V and GND inputs are clean even with slew

 

As for resetting the issue - turning off and waiting a short time had no effect. But quickly turning off and on made it go away.

The errors appear without turning off +5V, only +/-12V. 

On some rare occations the output flatlines on startup. On a single one, DAC output latched at something else than 0 (?) and a mix of two sources (?) could be seen on the output.

With the new seventyPWR, I have only been able to reproduce case 1 two times. It may be caused by the DAC too?

Edit: I managed t reproduce the extremely noisy case after reconnecting the old PSU and running two voice cards.

GND on the DAC is stable, the +5V very slightly wobbles, but nothing extreme.

 

The Vref however, is 4.23V, way too high:

 

DAC ref voltage should be 2.5V but is 4.23! Also note that the noise on the voice output is following the same pattern for each cycle, it's not random noise

The DAC output looks like it follows the correct "pattern" but the amplitude is of course way too high too.

 

DAC output is higher than it should

Now, as for the waveshaper - DCO input looks as it should, but everything else is garbage. Interestingly, the symmetry and center trim inputs are not stable voltages, but jump up and down. Moving further down the signal path, the mixer input channel 2 CV is also not stable. 

Mixer input channel 2 CV

Waveshaper 2 center CV

Waveshaper 2 symmetry CV

Waveshaper 1 center CV

Waveshaper 1 symmetry CV

It simply looks like the CV mux is not able to generate stable CVs, either because the clocking is wrong or because the DAC output is too high, making it settle at the wrong voltage. In other words, the massive noise is ALSO caused by the DAC. That's nice to know!

Soft start / inrush current limiter circuit

I've been searching for a working soft start current circuit, my voice cards frequently lock up/start self oscillating on startup and I want to try this to see if it helps.

I found a working example on stack exchange, see KarlKarlsom's answer here: https://electronics.stackexchange.com/questions/294061/p-channel-mosfet-inrush-current-limiting

It is simulated here:

https://www.circuitlab.com/editor/#?id=n2hgzw3r66hb

Circuit cellar has a very similar design with explanation here:

https://circuitcellar.com/cc-blog/issue-304-eq-answers/

I created a version for -12V as well, with the help and misguidance of Claude Opus 4.6. Here is the result:

 Output from 2s square wave, red and blue are the outputs:

 

A deepdive into the JP8000 and TC170C140 ESP

This post sums up everything I've learned about the Roland/Toshiba TC170C140 ESP. Some of it comes from the Usual Suspects' presentation at 39C3, some from studying and running the JE-8086 code, and a little bit from the JP8000 service manual

 

Hardware

The TC170C140 ESP, from now on referred to as 'the DSP', has the following specs:

Two cores, each with:
- 24 x 8bit multiplier *
- Two accumulators
- Programs of 768 instructions
- 256 words of 24 bit internal RAM
- 3 pipeline slots for IRAM write **

One of the cores can communicate with external DRAM, referred to as ERAM. It looks like this is core 2.

Separate program memory areas per core
PR0: 24 bit, starts at 0x0000 in emulator. Used by core 1
PR1: 28 bit, starts at 0x0400 in emulator. Used by core 2

* The DSP does multiply high, so in practice multiplication can be thought of as multiplying two 24bit numbers but only using the 8MSBs of the second number, then keeping the upper 24 bits of the result. 

**  Not sure what they mean by this, perhaps the accumulators as they are pipelines with length 3 

 

Memory

IRAM - Internal RAM

- 256 words of 24 bit internal RAM, addressed as delay line/circular buffer 

GRAM - Probably global RAM

- 256 words of 24 bit shared internal RAM (GRAM), also used for audio I/O and communications between the DSPs, at least in the emulator 

- Shared between cores

IRAM/GRAM is not accessible from the host interface, but in the emulator at least, values are copied between DSPs directly from GRAM to GRAM.

ERAM - External Ram (DRAM)

- Only one core can access external RAM, from the program memory formats it looks like it's core 2

Accumulators

- both circular buffers with 3 steps

 

Instruction/bytecode format:

E = ERAM control, only found on core 2

P = op
M = mem
S = shiftbits
C = coefficient, a signed 8-bit integer
x = unused?

Bit format (28 bits) - usually only 23 are used:

EEEE EPPPPPMM MMMMMMSS CCCCCCCC

- In the DSP code, 

op = (instr >> 16) & 0x7C

e.g.

0b0PPPPP00

so all op codes are shown as * 4

Each instruction performs a multiply and accumulate (MAC) with variable shift right (3,5,6,7 bits):
 

acc += (mulInputA * mulInputB) >> shift

or 

acc  = (mulInputA * mulInputB) >> shift

 

Special instruction:
0x372800 -> sends result to CP // WHAT IS CP
 

 

Other instructions: 

• Store accA or accB to IRAM
• Store saturated or unsaturated (unsigned)
• Read/write GRAM
• Multiplication per variable
• Double precision multiplication ("DMAC") 
• Rectify clamp, interpolate helpers
• Control Flow
•  Jump always/zero/pos/neg*
•  Skip the following instructions based on condition

* Jump is never used in oscillator code/DSP 1 it seems, but perhaps in others?

The chip is in general extremely similar to LSP (See: "Sound Chip, whisper me your secrets", gulaschprogrammiernacht 23)
- same instruction format, memory addressing, external memory control, coefficient size 

 

MAC

Every instruction ends with a multiply and accumulate (MAC):

acc +=  factor1 * factor2 >> shift

The multiplication is 24 x 8 bits

 

To add a number without multiplying, one of the factors must be reduced to 1 by the shift operation. 

acc += factor * 1 

 

To not change anything, the second factor can be set to 0

acc += factor * 0 

This is used for most of the memory write functions.

 

The MAC result can either overwrite or be added to either of the accumulators.

The multiplier is usually used as a 24 x 24 bit multiply high where the second factor only has 7 bit precision (1 sign + 7 value bits + 16 0s). 

Can do 14bit precision with an additional instruction (DMAC). 

Can do up-to-24bit multiply-by-coefficient by running a special multCoeff instruction, then up to thee DMAC instructions with their separate 8 bit coefficients.

 

IRAM

IRAM is circular and the pointer to head is decremented for every full run of the program memory 

Within a single run you can read and write to the same position

Between runs you can get the previous version by reading the previous address

Accumulator

ACC is also a circular buffer, but a bit weird. For set and add the value from the previous instruction will be used directly, and the value is stored at the current head position

Reading saturated or raw however, reads the previous value at the same position as head, which is the result of MAC three instructions back. 

Also note, that if the accumulator is not changed by the instruction, the previous value is copied. After three steps, all the positions in the acc are the same, so in reality the value you read is the most recent write three OR MORE steps back. This also means that two additional changes to the accumulator may have happened since the value you read, you just don't have access to them yet - or, at least not the one two steps back, the previous one is available when doing MAC.

The pipeline is advanced for every instruction 

 

GRAM 

Communication between DSPs are through GRAM, output is found at x and inserted into y

 

Parameter changes

The code runs 88200 times per second, so it would be inefficient to always write parameters to IRAM. Instead, parameter changes happen directly by changing the instruction in program memory and are written to IRAM if needed. 

Each instruction can only take 8 data bits, so larger coefficients are set (and multiplied into one) by additional instructions.

 

How the JP8000 uses the DSP 

 

Algorithm changes

Since program memory is limited, only the program for the current type of oscillator is kept in the DSP. Whenever the user switches oscillator type (super saw, feedback oscillator etc), a whole code block is changed. 

 

Things that change the code in DSP 1:

0x006b to 0x00b9 - Oscillator 2 algorithm // Core 1

0x043c to 0x049e - Oscillator 1 algorithm // Core 2

0x0005 to 0x0008 - Ring modulator

0x0068 to 0x00b2 - Sync // surrounds osc 2 code

 

Input parameters, these are written as program code changes. 

0x0044: Oscillator balance

0x0400: X-mod depth

0x0404: Unknown coefficient 1

0x040e: Unknown coefficient 2

0x0420: Unknown coefficient 3

0x0425: Unknown coefficient 4

0x0430: Unknown coefficient 5

0x041b: Pitch, stored in IRAM pos 0x65 

0x043f: Detune

0x0442: Mix 

 

PS: LFOs and other pitch modifiers are done in the MCU and set as parameters after combination with the pitch. 

 

Other interesting addresses

0x0424: store pitch to iram1[0x65]
0x0454: Osc 1: Store updated value to iram1[0x05]
0x0455: Osc 2: Multiply pitch and detune, 14bit precision, and add

               pitch + previous value for osc.
0x0459: Osc 3: Multiply pitch and detune, 14bit precision
0x045b: Osc 2: Store updated value to iram1[0x07]
0x045c: Osc 3: Load pitch, add -1 * pitch * detune (from 0x0459++) 

               + previous value
0x045f: Osc 4: Multiply pitch and detune, 14bit precision
0x0461: Osc 3: Store updated value to iram1[0x09]
0x0462: Osc 4: Load pitch, add (pitch * detune (from 0x045f++) * 120)

               >> 5 + previous value
0x0465: Osc 5: Multiply pitch and detune, 14bit precision
0x0467: Osc 4: Store updated value to iram1[0x0b]
0x0468: Osc 5: Load pitch, add (pitch * detune (from 0x0465++) * 

               -102) >> 5 + previous value
0x046b: Osc 6: Multiply pitch and detune, 14bit precision
0x046d: Osc 5: Store updated value to iram1[0x0d]
0x046e: Osc 6: Load pitch, add (pitch * detune (from 0x046b++) * 

               44) >> 3 + previous value
0x0471: Osc 7: Multiply pitch and detune, 14bit precision
0x0473: Osc 6: Store updated value to iram1[0x0f]
0x0474: Osc 7: Load pitch, add (pitch * detune (from 0x0471++) *

               -45) >> 3 + previous value
0x0479: Osc 7: Store updated value to iram1[0x11]

0x047a: Set B = (Osc 7 * (mix >> 16)) >> 7
0x047b: B += (Osc 5 * (mix >> 16)) >> 7
0x047c: B += (Osc 3 * (mix >> 16)) >> 7
0x047d: B += (Osc 1 * 25) >> 7
0x047e: B += (Osc 2 * (mix >> 16)) >> 7
0x047f: B += (Osc 4 * (mix >> 16)) >> 7
0x0480: B += (Osc 6 * (mix >> 16)) >> 7
0x047a: Set B = (Osc 7 * (mix >> 16)) >> 7

 

Communication between DSPs 

DSPs are called asic in the code

 

3 addresses are copied, e.g. the output of 3 voices.

0x80 is in voice group 1, 0x82 and 0x84 in voice group 2 when starting up

 

DSP1.GRAM[0x80 + k] => DSP2.GRAM[k] 

  

6 addresses are copied, the output of the 3 first is equal to the input from DSP2 

0x86 and 0x8a  is in voice group 1, 0x88 in voice group 2 when starting up  

DSP2.GRAM[0x80 + k] => DSP3.GRAM[k]

 

Not sure what is copied here: 

DSP2.GRAM[0xa0] => DSP3.GRAM[0x20]

DSP2.GRAM[0xa2] => DSP3.GRAM[0x22] 

 

8 addresses are copied, likely the 8 voices. Not sure if the signal at this point contains envelopes and filter 

DSP3.GRAM[0x80 + k] => DSP3.GRAM[k]

 

Communication between DSP and DAC 

called postSample in the code, reads GRAM 0xe8 and 0xec from DSP3

 

To hear output of the other DSPs, change to 0x80 + k on DSP1/2/3. 

 

 

Where does the code run

On DSP1, and perhaps on the others as well:

Core 1 is oscillator 2

Core 2 is oscillator 1  

 

DSP 1 generates 3 voices

DSP 2 generates 3 voices and passes the three from DSP1 straight through to the output

DSP 3 generates the remaining 2 voices. Has 8 outputs, not sure if filter and envelopes are here or in DSP 4.

DSP 4 is likely FX and output summing. 

 

Pitfalls when trying to understand the code

Acc is a circular buffer, so the value read by sat/raw is not the previous value, it is the last time the accumulator changed three or more steps back.

IRAM is circular, so reading and writing to the same cell in different iterations happens at consecutive addresses. Important when searching for the source of a value that is read, it may be at address+1.

The DSP is 24bit, so all variables are 24bit and overflow as such. The multiplication intermediate result however, before shifting, is 32bit.

The DSP is fixed point, so think of numbers as decimal numbers having a range +/-1.0 even if they're represented as ints.

The multiplication is usually thought of as a multiply high 24 x 24 bits, but with bit 15:0 of the second factor set to 0 - it has 7 bit precision.

 

How I debugged the code 

I approached the code in two different ways: Disassembling/reading the machine code, step debugging and looking at the output wave files

I used the jeTestConsole app as a an entry point - it boots the JE8086 in headless mode and outputs the display text to the terminal. I extended it with keyboard event handling to be able to change stuff on the fly.

On startup of the script, I set the je8086 to a known state. It boots up as a normal JP8000, so by pressing EXIT and WRITE at the same time it enters manual mode:

device.getJe8086().setButton(devices::kSwitch_Exit, true); device.getJe8086().setButton(devices::kSwitch_Write, true);

The device boots up in split keyboard mode. While I tried to change this, for some reason it prevented detune/mix param values from arriving at the correct positions in the DSP. I have not investigated this further and I don't know if it was true when using midi to set the params (I exposed a setFader method similar to the setButton). Changing keyboard mode was however useful when figuring out what voices are calculated in what DSP.

I then switched to a known midi note so I could look at the pitch parameter.

The rest of the control was done interactively - setting detune and mix to known values, dumping memory etc. 

 

Things I did to make debugging easier

• Added asicId, coreId and the current value of the program counter, including the address offset for core 2, to the esp code. That made it possible to set conditional breakpoints in a single core on a single DSP, and easier to visually match the pc to a print out of the program memory.
• Added auto-calculation of high-res coefficients, iram contents before and after execution to make it easier to read when running the debugger. 
• Added debug output to writeuC, the function where MCU writes to DSP. There are three modes of writing to the program memory:
• Mode 0x54: Raw Program Memory Write (program changes)
• Mode 0x55: Coefficient Update (parameter values)
• Mode 0x56: ERAM Control Bits Update 
• Added way to dump/print disassembled pcmem on demand. The dump function is already included in both je8086devices.h and the DSP code. 
• Extended the disassembler. 
• Per-line comments, so running dump repeatedly added my own comments at the right lines
• More accurate description of what happens per instruction type, including multi-line comments if more than one thing happens.
• Human readable coefficient values as comments and directly in descriptions of instructions
• Hiding lines with opcode 0
• Adding blank lines when the accumulator was cleared, to automatically group instructions that belong together. 
• Auto-calculation of address of the last write to an accumulator when reading sat/raw, as these are often way back in the program memory.
• Added a way to get midi commands to the je8086
• Added a keyboard handler that could change parameters like detune, mix, pitch etc through midi parameterChange, as well as execute dump.
• For interactive debugging I switched from the JIT to interpreter version of the ESP, as it's way easier to read the full code than the JIT version. This change is done on line 149 in je8086devices.h

 

Example of disassembled output 

 

Fields, left to right: address in program memory, hex representation of instruction, [] = instruction split into fields, o=op code, m=memory address, s=shift bits, c=coefficient. Then store-to-ram operation if any. After the first |: op code and op code name, then the original disassembly-comment. Finally, my own description of the code. For sat(A) etc, there's an additional @ [0xXXXX], that's the address in program memory where the value of A was calculated.

Multi-line comment to make it easier to see exactly how kMulCoef is calculated

Opcodes w. description

The instructions are as described earlier in this post. This tells how to interpret each of them. 

List of all opcodes

 

 

Normal opcodes  

All codes except for 0x20 to 0x34 follow these rules:

 

shift is always set by shiftbits 

mulInputB is always coefficient

mulInputA has a default mapping, but may also be set more explicitly

result is written to either accumulator A or B

result either clears the current value of (A=) or adds to (A+=) the accumulator at the end

 

Each operation ends by doing 

acc = mulInputA * mulInputB >> shift (or +=)

 

Defaults for mulInputA

 

mem
1	0x10	16
2	0x400	1024
3	0x10000	65536
4	0x400000	4194304
default		iram[mempos]

 

Shiftbits 

 

the value of shiftbits selects the number of places to right-shift the result: 

0: 7

1: 6

2: 5

3: 3

 

Illustration of the three interp functions:

 

The the three variations of interp are a bit hard to understand. Here is a plot of each one:

 

interpStorePos

interpStoreNeg

interp

 

0x30 - special

Coefficient decides operation:

 

Coefficient format:

B = source for mulInputB - mulcoeffs, eram eller mulcoeffs 5??

F = Flips B amplitude around a midpoint between 0 and 1 (1-x) 

I = invert B 

L = If 1: Load mulInputA, if "weird"*: detect sign. 

    Save to iram[mempos]. 

    If 0: uses default mulInputA

A = Accumulator 

C = !Clear

Coeff: BBBFILAC 

* weird: Coeff =xxx111xx

 

0x34 - special

Mem decides operation:

 

mem & 0xF0 = 0xA0: 

 

4 LSB: MMMA, M = mulcoeff index, A = Accumulator 

Stores saturated accumulator to mulCoeffs 

mem > 0xC0:

 

Mem format: 

C: Clear

A: Accumulator

P: Operation

 

11CAPPPP 

 

Commands reads coefficient to jump etc

 

0x0: Jump on 0

0x1: Jump on < 0

0x2: Jump on > 0

0x3: Jump

0x4: Set INT pins
0x6: DMAC - double precision multiplication

0x7: Sets ERAM address
0xa: Write saturated accumulator to readback reg, read by uC

0xb: Write to ERAM
0xc:

0xd:

0xe:

0xf: Read from ERAM to IRAM[mem|0xF0] and to mulInputA

 

Parameter values

The tables below show the values send to the DSP when setting a MIDI CC or NOTE value. They are also found in my previous post, in a more copy-paste friendly format.

 

Detune 

 

First column is the midi value, the second is what the uC probably works on while the last, ESP, is what is sent to the DSP. 

 

Mix

First column is the midi value, the second what is sent to the DSP. 

 

Pitch

First column is MIDI value, second is what is sent to the DSP. The third, "actual", is the result of the pitch formula in my post about the correct version of the supersaw code. The last column is the difference between the two, showing the pitch error. For the lowest notes it is 1/1647, well below what we're able to hear. It increases as we go up the scale, but that's not a big problem, the relative difference is probably not increasing

 

JP80x0 midi to coefficient mapping tables

Pitch

Midi	Pitch
0	1555
1	1647
2	1745
3	1849
4	1959
5	2075
6	2198
7	2329
8	2468
9	2615
10	2770
11	2935
12	3110
13	3295
14	3491
15	3698
16	3918
17	4151
18	4397
19	4658
20	4936
21	5230
22	5541
23	5871
24	6220
25	6590
26	6982
27	7396
28	7836
29	8302
30	8794
31	9317
32	9873
33	10460
34	11082
35	11742
36	12441
37	13181
38	13965
39	14792
40	15672
41	16604
42	17589
43	18635
44	19747
45	20921
46	22164
47	23485
48	24883
49	26362
50	27930
51	29585
52	31345
53	33209
54	35179
55	37270
56	39494
57	41842
58	44329
59	46970
60	49767
61	52725
62	55860
63	59171
64	62691
65	66418
66	70358
67	74541
68	78988
69	83684
70	88659
71	93941
72	99534
73	105450
74	111720
75	118342
76	125382
77	132836
78	140716
79	149082
80	157976
81	167368
82	177318
83	187882
84	199068
85	210900
86	223440
87	236684
88	250764
89	265672
90	281432
91	298164
92	315952
93	334736
94	354636
95	375764
96	398136
97	421800
98	446880
99	473368
100	501528
101	531344
102	562864
103	596328
104	631904
105	669472
106	709272
107	751528
108	796272
109	843600
110	893760
111	946736
112	1003056
113	1062688
114	1125728
115	1192656
116	1263808
117	1338944

 

Detune:

Midi	uC
0	1
1	1
2	2
3	2
4	3
5	3
6	4
7	4
8	5
9	5
10	6
11	6
12	7
13	7
14	8
15	8
16	9
17	9
18	10
19	10
20	11
21	11
22	12
23	12
24	13
25	13
26	14
27	14
28	15
29	15
30	16
31	16
32	17
33	17
34	18
35	18
36	19
37	19
38	20
39	20
40	21
41	21
42	22
43	22
44	23
45	23
46	24
47	24
48	25
49	25
50	26
51	26
52	27
53	27
54	28
55	28
56	29
57	29
58	30
59	30
60	31
61	31
62	32
63	32
64	33
65	34
66	35
67	36
68	37
69	38
70	39
71	40
72	41
73	42
74	43
75	44
76	45
77	46
78	47
79	48
80	49
81	51
82	53
83	55
84	57
85	59
86	61
87	63
88	65
89	67
90	69
91	71
92	73
93	75
94	77
95	79
96	81
97	83
98	85
99	87
100	89
101	91
102	93
103	95
104	97
105	99
106	101
107	103
108	105
109	107
110	109
111	111
112	113
113	115
114	117
115	119
116	121
117	123
118	125
119	127
120	129
121	137
122	145
123	153
124	169
125	193
126	225
127	321

 

Mix

Midi	Mix
0	102400
1	118784
2	135168
3	151552
4	167936
5	184320
6	200704
7	217088
8	233472
9	249856
10	266240
11	282624
12	299008
13	315392
14	331776
15	348160
16	364544
17	380928
18	397312
19	413696
20	430080
21	446464
22	462848
23	479232
24	495616
25	512000
26	528384
27	544768
28	561152
29	577536
30	593920
31	610304
32	626688
33	643072
34	659456
35	675840
36	692224
37	708608
38	724992
39	741376
40	757760
41	774144
42	790528
43	806912
44	823296
45	839680
46	856064
47	872448
48	888832
49	905216
50	921600
51	937984
52	954368
53	970752
54	987136
55	1003520
56	1019904
57	1036288
58	1052672
59	1069056
60	1085440
61	1101824
62	1118208
63	1134592
64	1150976
65	1167360
66	1183744
67	1200128
68	1216512
69	1232896
70	1249280
71	1265664
72	1282048
73	1298432
74	1314816
75	1331200
76	1347584
77	1363968
78	1380352
79	1396736
80	1413120
81	1429504
82	1445888
83	1462272
84	1478656
85	1495040
86	1511424
87	1527808
88	1544192
89	1560576
90	1576960
91	1593344
92	1609728
93	1626112
94	1642496
95	1658880
96	1675264
97	1691648
98	1708032
99	1724416
100	1740800
101	1757184
102	1773568
103	1789952
104	1806336
105	1822720
106	1839104
107	1855488
108	1871872
109	1888256
110	1904640
111	1921024
112	1937408
113	1953792
114	1970176
115	1986560
116	2002944
117	2019328
118	2035712
119	2052096
120	2068480
121	2084864
122	2101248
123	2117632
124	2134016
125	2150400
126	2166784
127	2183168