Possible filter bug?

[jbartee]

Another weekend gone, another 48 hours of sidsploration completed. :smile: I hate to pester everyone again, but I think I've discovered another possible bug.

Basically there are some "kinks" in the frequency cutoff curve (please keep reading! I'm not talking about the usual steppiness in the lower registers). If you start at maximum cutoff and slowly decrement, there are two locations where the cutoff frequency seems to abruptly jump up several values before continuing to decrement. What's interesting is these spots occur between 800 / 7FF and 400 / 3FF exactly. Interpolation flags make no difference, and fiddling with the ensemble filter maximum flag (specifically, setting it at 800 rather than FFF) has the odd effect of shifting the location by a value of 1… so the kinks then begin at 800 / 801 and 400 / 401.

I've reproduced this on multiple 6581's, and the effect occurs on both currently stuffed sids in my stereo setup at exactly the same frequency locations.

Note that this is not audible on fast filter sweeps, harmonically rich or distorted sounds, or very low sounds, although it is clearly still occurring. To hear it, set resonance to maximum, play a highish register saw wave, and use the menu encoder to flip cutoff between 800/7FF, and you can clearly hear the jump. I discovered it while attempting to reproduce the famous "Main Titles" lead from blade runner, which uses an envelope to very slowly modulate cutoff. It really stands out in that case, having these obnoxious little leaps in something that should be a beautiful, smooth curve. :ermm:

The question is whether this is some weirdness with the SID filter's nonlinearity, or a bug in the MBSID scaling. I really don't think this is a hardware problem in terms of my board construction, but it would be nice if someone could confirm the issue!

Edited March 23, 2010 by jbartee

[TK.]

Please post:

- a patch in .syx format (just open the SysEx tool of MIOS Studio, enable receive mode, press SHIFT+Dmp on your MBSID to send the patch)

- an audio sample in .mp3 format

- the exact filter settings in ensemble FIL page

Best Regards, Thorsten.

[jbartee]

Please post:

- a patch in .syx format (just open the SysEx tool of MIOS Studio, enable receive mode, press SHIFT+Dmp on your MBSID to send the patch)

- an audio sample in .mp3 format

- the exact filter settings in ensemble FIL page

Best Regards, Thorsten.

Okay, I'm on it. Gimme like 20 minutes :ahappy:

[jbartee]

Filter1.mp3

In this recording an envelope gradually decrements the cutoff

Filter2.mp3

In this recording I manually flip between 800 and 801 cutoff values, so you can hear the exact moment of the jump.

Kink.zip

This is the patch used to generate the first recording.

The FIL ensemble settings are as follows:

SID: 1

ACh: LR

Min: 000

Max: FFF

Log: o

I also want to correct something from my previous post- I had it backwards about the 1 digit shift. With ensemble fil at FFF, the jump occurs between 800 / 801 and 400 / 401. In my tests setting the fil max at anything below 800 shifts the location of the jump down 1 digit, to 800 / 7FF and 400 / 3FF.

[TK.]

Thats an intensive effect and I cannot believe that nobody discovered this before (I wasn't able to reproduce this)

For me it sounds like the internal SID filter stage isn't balanced

This can happen if the 6581 is supplied with a voltage (much) lower than 12V, e.g. 9V - or if you are using the wrong (or unequal) filter caps

Please check this first.

If you want to check the software, you could read out the filter values which are written into the two cutoff registers by sending

F0 00 00 7E 40 00 0D 02 00 06 15 00 00 00 02 00 00 00 00 F7

with MIOS Studio as illustrated in this snapshot:

It also shows the corresponding assignments of the filter values with the register readout.

In this example, I changed cutoff from 7FE to 805 and requested the cutoff values after each step by sending the sysex string described above.

Note that the SID filter works at 11 bit only, but MBSID uses 12bit. Combined with the calibration routine the next MSB will be reached at 801 and not 800 - thats no bug (correct by construction), and under proper conditions it will never result into an audible effect (like on your MP3s)

Best Regards, Thorsten.

[jbartee]

Well I guess it's back down the rabbit hole for a bit then.

I'm using the 470pF polystyrene caps that came with Smash's kit. I just double checked them to make sure they were the right ones.

The sids are getting silghtly less than 12 volts, but nothing close to 9... more like 11.8 volts, which should be fine (I think?)

There's nothing visually weird about the caps (obvious shorts or anything like that), although I have yet to to look on the underside of the board, as it's glued into my case and getting it out will require some significant effort. I do notice that on one of the sid boards, I get some pretty nasty hum/distortion if I touch the leads of either cap with my finger. Any idea what might be causing this? This doesn't happen on the other sid module. However, the filter jumps are occurring on both modules.

What I don't understand is how this can be happening on both boards... seems unlikely that it would be a faulty or out of spec cap or wiring error, since you would expect that to only affect one board. If it's really a hardware problem, it would have to lie with the power I guess, since that's the only thing in common between the two modules other than the data connections to the core.

I'm pretty confused... I guess the next step would try supplying the sid modules with a voltage as close to 12 as I can get. I'll pick up some regulators when i have a chance.

And of course I'm open to any and all advice. I'd love to get this fixed, but I'm not sure where to start really.

Edited March 23, 2010 by jbartee

[TK.]

It won't help to bring the voltage even closer to 12V

For me this case is open until anybody else was able to reproduce this - as mentioned above, it's easy to verify that the software writes the correct values into SID registers.

It could make sense to check this with 8580 or 6582 if available (but this will require to change the voltage/filter caps)

Best Regards, Thorsten.

[TK.]

Btw.: are your 6581's from the same batch, resp. produced at the same time?

Best Regards, Thorsten.

[jbartee]

Btw.: are your 6581's from the same batch, resp. produced at the same time?

They are from the same year, but not the same batch. Specific date codes: 2983 and 4883

It won't help to bring the voltage even closer to 12V

For me this case is open until anybody else was able to reproduce this - as mentioned above, it's easy to verify that the software writes the correct values into SID registers.

It could make sense to check this with 8580 or 6582 if available (but this will require to change the voltage/filter caps)

as 11.8 volts is within 5% tolerance I suppose you're right. I'll try verifying the software, abut if you couldn't reproduce the issue I seriously doubt it will turn up anything. I'm proceeding on the assumption that something is mucked up with my boards.

Unfortunately I have no 8580's or 6582's available to test with.

[TK.]

Now I tested it with a 6581 marked with 2584, another one marked with 4084

Both have a different filter response - but the interesting point: with both chips I can hear this unbalanced step as well (on the 4084 much more noticable than on a 2584)

Time to search in the internet for similar observations.

Best Regards, Thorsten.

[jbartee]

Now I tested it with a 6581 marked with 2584, another one marked with 4084

Both have a different filter response - but the interesting point: with both chips I can hear this unbalanced step as well (on the 4084 much more noticable than on a 2584)

Time to search in the internet for similar observations.

Best Regards, Thorsten.

Wow! What chips were you testing with that didn't produce the step? Perhaps there's something unusual (read: defective) about the earlier chips... although a defect running from 83-84 seems long). Good luck scouring the internet, I've already spent the better part of 5 hours searching and haven't found a single reference to this issue anywhere.

[TK.]

This is a very interesting page: http://www.bel.fi/~alankila/c64-sw/index-cpp.html

(btw.: wouldn't it be nice to use the improved filter models for the MBSID V3 VST/AU emulation? :)

It gave me the keyword R-2R ladder DAC.

As you can read in Wikipedia:

Accuracy of resistor ladders

Resistors used with the more significant bits must be proportionally more accurate than those used with the lower significant bits; for example, in the R-2R network shown above, inaccuracies in the Bit4 MSB resistors must be insignificant compared to R/32 (i.e., much better than 3%). Further, to avoid problems at the 10000 to 01111 transition, the sum of the inaccuracies in the lower bits must be significantly less than R/32. The required accuracy doubles with each additional bit—for 8 bits, the accuracy required will be better than 1/256 (0.4%). Within integrated circuits, high accuracy R-2R networks may be printed directly onto a single substrate using thin-film technology, ensuring the resistors share similar electrical characteristics Even so, they must often be laser trimmed to achieve the required precision.

I don't think that the Rs were laser-trimmed in those years ;)

So, how to solve this: I could add a fast accessible calibration table so that the "bad steps" can be excluded or smoothed out. It would consume 4k (not sure if so much is still available), but everybody would have to adapt it manually for his SID by editing the table and rebuilding the application.

Best Regards, Thorsten.

[jbartee]

Good work! 1980's tolerances strike again. The wikipedia article is super informative.

I think the calibration table is a great idea... at least for me it would be no problem at all to edit and rebuild, and it would be great to kill those bad steps for good. I'd much rather do it this way then try to track down 6581's without the screwed up r-2r dacs, or worse yet "upgrade" to the 8580's (which are not my bag at all).

Edit: ouch, 4k. Here's hoping there's enough available space!

Edited March 24, 2010 by jbartee

[jbartee]

Also, perhaps we should start refering to this issue as " The Non-Monotonic Filter Problem," or NMFP for short, as this seems to be the technical term. :smile:

EDIT:

I just found this graph in the resid page you linked:

http://www.bel.fi/~alankila/c64-sw/fc-curves/curves.png

The majority of these display some pretty hardcore spikes around 1024, so I guess this could be a fairly common issue with 6581's.

I've bought some matched R4AR's that should get here in a week or so, it will be interesting to see if the issue persists with later rev 6581's. That is assuming they don't end up being remarked Chinese garbage and the filters work enough to allow testing!

Edited March 24, 2010 by jbartee

[nILS]

Somewhere in the depths of the sidplay source code I've found some references to the jumps, which seem to be the normal non-linearities in 6581s. Supposedly they're pretty much completely gone in 8580/6582s.

[jbartee]

Sigh. It's such a dilemma for me with 8580's. I vastly prefer the timbre of the 6581 filters... there's a certain warm distortion in the lower registers of the LP filter that just makes me incredibly happy, and it's the sound I remember from my old breadbox as a kid. But on the other hand the reduced bugginess of the 8580 is incredibly appealing. This latest discovery just makes it even worse - a beautiful filter that has a seriously messed up bug, or a functionally correct filter that sounds (to me) clinical and dry.

Since it looks like this is the natural behavior of the 6581's (it's kind of hilarious that sidplay attempts to emulate it!) maybe it's not worth Thorsten's time and effort to build a workaround, especially since I seem to be the only one who's really noticed/cares about the issue. Unless TK is just feeling incredibly generous of course. :tongue: Otherwise I suppose I'll begin my quest for the 6581 "holy grail," since there are clearly some that fall on the good end of the bell curve with little to no jumps in the filter curve.

Edited March 24, 2010 by jbartee

[jbartee]

And here it is, commented in filter.cc in the latest resid source:

"The function mapping FC to cutoff frequency has the shape of the tanh function, with a discontinuity at FCHI = 0x80. In contrast, the MOS8580 almost perfectly corresponds with the specification of a linear mapping from 30Hz to 12kHz."

[TK.]

The filter calibration table is now part of RC36

(yes, I know that it's cumbersome to find the best matching values, since the firmware will be reseted after each .hex file upload...)

I avoided to call this effect NMFP ;)

Best Regards, Thorsten.

[jbartee]

Wow Thorsten, you're fast. Thank you once again for the awesomeness! Also lol @ NMFP.

I wonder if you can walk me through the process here a little bit, since I'd rather not wait till the rc36 release to get this calibrated. The table can be compiled as a seperate hex file, or does the entire firmware need to be recompiled?

EDIT: Oh, my bad, I just saw that RC36 is now available. Sweet.

Edited March 24, 2010 by jbartee

[TK.]

It's explained in the CHANGELOG and in the src/sid_filter_table.inc file - what detail are you missing?

Best Regards, Thorsten.

[jbartee]

It's explained in the CHANGELOG and in the src/sid_filter_table.inc file - what detail are you missing?

Best Regards, Thorsten.

No details missing! I posted "blind" before noticing that it had already made its way to the repository / official rc36 release.

[jbartee]

(yes, I know that it's cumbersome to find the best matching values, since the firmware will be reseted after each .hex file upload...)

It occurs to me that what we really need is a calibration tool that will let you visually remove segments of an envelope, hear the resulting change in realtime on your mbsid, and then automatically determine precisely which regions should be omitted from the table. I think I can do this in max 5 by modulating cutoff using an nrpn, and then using a simple algorithim to convert from the current 14-bit step to the correct 12-bit step for use in the table. This way you could calibrate the filter in realtime, and only edit / upload the hex file once. If I get anywhere I'll post the patch here, as well as build a mac (and maybe windows if there's any interest) executable.

I have a little time off in a couple days, so watch this space :smile:

[TK.]

Thats a nice idea! :)

Do you have C++ knowledge? I could prepare an empty stub for a new MIOS Studio 2 tool where you could insert your code.

Advantages: proven MIDI handling, platform independence, and reusable for similar tools in future.

Best Regards, Thorsten.

[jbartee]

I agree it would be best to integrate into mios studio, but sadly my knowledge of C++ is extremely noobish. I'm trying to learn more but I doubt I haz the skillz currently to pull this off with "real code." I've already started building the max implementation however, and if someone with more chops wanted to adapt the architecture, it would probably be pretty straightforward.

Edited March 25, 2010 by jbartee