jbartee

Are you referring to the schematic for the optimized PSU ( http://www.ucapps.de/mbhp/mbhp_8xsid_c64_psu_optimized.pdf )? Your link just goes to the ucapps homepage. If yes, that schematic will only work if you don't have the voltage regulator on the core stuffed. The crucial thing to understand is that core J1 lives upstream of the voltage regulator, and core J2 lives downstream (see the bottom right corner of this schematic: http://www.ucapps.de/mbhp/mbhp_core_v3.pdf ). Core J1 feeds power through the bridge rectifier, big filtering caps and the inputs of the 7805. Core J2 is meant to supply other boards with the regulated output of the 7805. Since the regulator is unstuffed in the optimized psu, power can be supplied directly through Core J2, bypassing all the power related components on the top of the board. If you are powering your core through Core J2 directly from your 12v PSU however then you are way exceeding the voltage requirements of the core. You want to be feeding the core through core J1. You should then power the sid module through vs and vd on core J10 (as smash recommends in his build guide here: http://www.avishowtech.com/mbhp/mbhp_SIDR3a.html ). Unless you're using the optimized psu, J2 shouldn't be used as a power input. Edit: after scolding you on your links, mine were broken! :rolleyes: They're fixed now.

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.

They are from the same year, but not the same batch. Specific date codes: 2983 and 4883 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.

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.

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.

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

The f0 0000 7e 40 0001 f7 is no cause for alarm, this is simply the core outputting an upload request. It's odd that it corresponds to throbbing noises from your sid however! One thing that stands out right away is you shouldn't be using core J2 for anything. the 5 volt line to the SID board is supplied from core J10. You should have a 1-to-1 connection between core J10 and SID J2. Looking at the schematics I'm actually not sure if there's much of a difference compared to how you have it wired, but it's better to do things by the books. Also, the "heartbeat" could be indicative of the sids not receiving power properly... Just to clarify, the sid module needs two different voltages: a 12 volt line that powers the sids themselves, and a 5 volt line driving the other ICs. Double check the power running to the sids... did you directly connect the 12 volt output of your PSU to pins 2 and 3 of the voltage regulator as nILS outlined?

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!

Hi Jordan. My name is also Jordan. Therefore I feel some solidarity. :thumbsup: I don't want to alarm you, but it's possible you've blown out your sid and/or pic. Absolutely do not plug any more power into the board until you get this figured out. I know you already did this, but I think you should perform the voltage tests again. If the regulator was actually smoking, that clearly indicates a short somewhere between power and ground. Hopefully you haven't also burnt out your sid... they do get pretty hot under normal operation (the 6581's especially) so it's hard to tell if the heat was from a critical failure or not. We won't know till we can get some sound out of it. If you can take some pictures of your boards (including your power board!), that would greatly help in troubleshooting this.

Ahh okay, I see. The tm-1 certainly seems like it has some compatibility problems. Anyway, glad you got it sorted!

Awesome! Out of curiosity, does the tm1 send correctly if you disable turbo mode? (don't feel obligated to check this, it would just be interesting info)

since the midi in seems to be working otherwise, I'd guess that the problem lies with your midi interface failing to send sysex messages properly. I had to try several interfaces before I found one that worked. The tm-1 is known to be a little finicky in this regard, with some users reporting sporadic connect/disconnect problems etc. It's hard to be 100% certain, but I'd try a few different midi interfaces and see if that solves the issue before moving on to other trouble shooting methods.

just compiled and uploaded and it completely fixes the issue. Thanks again!

Beer bought. :smile: Thanks for the link to the repository, I'll have a go at compiling it later tonight. It's definitely a little strange no one noticed the bug before... I guess actually seeing it is totally reliant on the order you have your patches saved in though.

Tk, you have no idea how relieved I am that I don't have to tear my box back open in order to fix this... thank you times 9000. And seriously, how can I buy you a beer (or otherwise donate?) PS: Where can I download the fix? :tongue:

Okay, I just reuploaded both mios and the midibox sid app using mios studio 2. No errors and everything progressed smoothly, but the matrix problem persists. I've also tried using the editor to upload blank initialized banks to the ensemble and patch banksticks, thinking that perhaps I had some corrupt patches, but this hasn't fixed it either. Is there a way to completely reformat the banksticks and start totally from scratch?

Thanks TK. Anything I can do to help narrow this down just let me know. I uploaded mios and the mbsid application a few times already, always with smart mode and with no errors shown, but I will try again tonight just to be sure (edit: this will also give me an opportunity to try out the new mios studio 2!). I haven't messed around with pin configurations at all, I only enabled analog inputs at j5 and switched some of the encoder modes. It's still entirely possible that I've just screwed something up, but the matrix works flawlessly otherwise... Also, I will buy you a beer if I can figure out how... you don't have a convenient donate button in your sig! :)

Thanks so much for responding Wilba. I haven't changed the setup.asm except to enable analog inputs at j5 and change some encoder types to non detented. My matrix is wired slightly oddly in that that it has a unique current limiting resistor at each led, and the dout boards are running off their own power supply instead of tapping power from the core (I did this to overcome some brightness problems and eliminate psu noise). However, this issue existed back when I had everything wired exactly as described in the schematics and was using the default setup.asm. So it looks like software I guess... it's as if the memory for meter mode isn't being cleared properly on patch changes. It's not a big problem or anything, I was just worried it might be a "canary in the coal mine" and indicative of some big blunder I made. It still seems a little strange that no one else would have noticed this bug since it's kind of hard to miss; anyone seen anything like this on their modulars? EDIT: also, I have bought you a beer. It's been long overdue. :smile:

anybody? This one has me really confused. Just a short, "yes my machine does the same thing," or "I have no idea what you're talking about" would really help stop pulling my hair out over this issue. In particular, I'm interested to hear from people who've built modular mbsids.

Interesting, I guess this behavior is unique to the Wilba machines then, since my modular mbsid definitely doesn't work that way.

you could try reversing the connections to the two data pins on the encoder.

Everything is almost done. Over the last couple weeks I've been troubleshooting (and, thankfully, resolving) a number of minor issues with my build, but there's one little problem that just won't go away. Sometimes when switching between presets the led matrix will get stuck with garbage from the previous preset. This only seems to happen in the lead engine, and only in meter mode. This happens whether or not meter mode is enabled when switching patches. Initializing an engine change clears it, or simply engaging the appropriate LFO's will clear the stuck LEDs as well. LEDs only get stuck on, never off, and the specific LEDs that get stuck on always correspond to the animated zones from the previous preset's meter display. This seems to happen only when an LFO or envelope is being used in one preset, and then not used in a successive preset- the unused LFO leds just don't get cleared for some reason. This can happen across engines too, but the behavior is slightly different. If I'm actually in meter mode in the drum engine and switch to a preset in the lead engine at the exact moment that any random leds are lit, those leds will remain lit in the new preset's meter mode. It's a minor problem really, but kind of obnoxious. The problem is so specific and reproducible and reliant on behaviors governed by the software that I don't think it could be a construction error on my part... but you never know. Any thoughts, help, advice etc? I've troubleshooted it as far as I can on my own and can't seem to resolve it.

After working on this some more today I was able to completely eliminate the hum by powering the dout boards from a totally separate 5 volt regulator (in my case, it is now sharing the regulator that supplies the integrated keyboard). What's weird is that it's still running off the same transformer. It's got to be some weird transient decoupling issue or something (<--- don't really know what I'm talking about, but seems more plausible than anything else I can think of). In any case, running the douts off their own regulator with their own filtering caps did the trick. I should point out that I initially simply switched the main 1 amp regulator in my psu with a 1.5 amp regulator, and this had no effect whatsoever, so this wasn't a simple current problem. Anyway, if anyone turns this thread up in a search and you're having led matrix related noise in your audio, it shouldn't be there and the fix is fairly simple once you know what to do.

Okay. I just spent a couple hours trying to sort this out. The noise seems to be emanating from the sid chips themselves. If you engage all (in my case) six oscillators, the hum completely disappears. if however you have even one oscillator disabled(so that when you play a note, only 5 out of six oscillators sound), the hum is present. The good news is I found a *kind of* solution. I put one 2200 uf capacitor in line with the power input on each dout board, and this has dropped the hum by about 15-20 db, so it's much better now, and really barely audible (most present on high notes, since lower frequency stuff completely masks it). This isn't a real solution however as the hum is still present. It's also just confused me more, since it seems the hum is not directly emanating from the power (ie, not a simple ground loop or something similar), but is still somehow directly affected by changes to the power rail. It's like some kind of complex cross talking going on. If anyone wants to chime in, I'd really appreciate it! EDIT: another possible not-really-solution would be to implement a simple matrix-off mode in the sid application. It could be as simple as a third mode toggled with the M_Mode button. This way we could at least disable the whole thing when fidelity is really important, like making a studio recording for instance. Sadly I lack the assembly language skills to do even a simple mod like this. I'm really wondering how widespread this issue is. It seems probable that it is somehow linked to the sid's leaky DCA, so someone using an 8580 might not even hear it without *really* listening for it (Mike, were you using a 6581 or an 8580/6582?). Or maybe we just screwed something up. But the issue seems systemic to me, I just can't make sense of its complex behavior.

Sorry to resurrect an old thread, but my midibox sid (modular, not wilba) is doing exactly the same thing. It's really strange; if no leds are lit, there's no hum, and also if all the LEDs in the matrix are lit, the hum disappears, but if even one led is on, I get this constant hum. It's not 50/60 hz as far as I can tell. Depending on the number of leds lit, it sounds like it's varying the pw of the hum too, or at least pushing forward different overtones. It's loudest in the multi engine, and actually the different engines seem to invert the behavior. In the multi engine, I don't hear any hum unless a note is played. In the lead engine, it's the opposite! There is hum only if no oscillators are sounding. This is really a difficult problem to track down. Mike (or anyone else), did you ever get this fixed/figure out what was going on? (EDIT to clarify: no leds or all leds doesn't produce hum, but any number in between does. Also, if I hold down one of the row buttons and cause an entire row to blink, there is no hum until I select which led in the row will remain lit using a column button, and then the hum starts. Holding down a column button to produce a blinking column causes hum immediately.)