jbartee

bump? It's just that the behavior is somewhat odd. I know the sid doesn't like to have its audio out hot plugged but I would have thought the buffering transistor at the end of the chain would take care of that. Since no one as responded, I guess I'll assume that it's not indicative of some systemic problem with my build.

Yeah, it just worked out that one had trouble receiving and the other had trouble sending.

Posting right before I go to bed = didn't thoroughly read thread before commenting. Anyway, I'm running Java 1.6.0_17 JaseM, I wouldn't rule out some bizarre incompatibility with you midi interfaces. I tried four (!) different interfaces before I was finally up and running. I ended up using both a firewire and a usb midi interface, using the midi out on one and the midi in on the other. SysEx just kind of sucks. It's super picky.

The latest version of Mandolane solved my java related midi problems on 10.6.2 It requires a license, but you can use it for 30 days in demo mode, more than enough time to see if it solves your issue. http://www.mandolane.co.uk/

Hi again everyone. This issue is a little difficult to explain, so bear with me! I've got my MBSID basically working, but I've been encountering a strange issue. When using the MBSIDV2 editor and engaging the filter, my MBSID will occasionally go dead if I switch between audio outputs too much/too fast. I have one audio cable going to an amplifier, so I've been just swapping that one cable between the first and second sid output. If I go back and forth several times, one or both sid chips will suddenly stop outputting any audio, and sometimes the MBSIDV2 editor will give me a "MBSID not responding" error. Turning the MBSID off and on again fixes the issue, until I engage the filter and plug/unplug audio again. It's somewhat sporadic; it doesn't do it every time I swap audio cables, but if I sit there and plug/unplug/plug/unplug it will reliably stop outputting after four or five insertions. So... is this a known bug, or some fatal problem with my hardware? It's not really an issue since in a real world application I won't be hot swapping audio cables like this, but I'm worried that it might be indicative of a deeper problem.

I just wanted to report back that I got everything working. After trying several midi interfaces, an old Evolution U-Control UC-33 that I borrowed from the university finally did the trick. I actually used the midi in from the FireWire 410 and the midi out of the U-Control in concert; an odd solution but if it works it works! MIOS as well as the sid application are uploaded and working splendidly. Just a heads up for other newbs, that 1k pull up resistor I mentioned at the beginning of the thread is essential. Without it the core gets locked in some kind of (I'm guessing) brown out reset pattern whenever it tries to load the control surface. I thought I'd mention this because if you're working off smash's boards, there's no dedicated spot in the layout to wire up this resistor and as far as I can tell it's not mentioned in his assembly guides.

Thank you. Don't know how I missed this. I just finished everything on the midi troubleshooting page except for the last few hardcore loopback checks. I will proceed on the assumption that the boards are fine and try to upload MIOS using another interface and/or operating system. Thanks again!

I was using an m-audio FireWire 410. With the switch to snow leopard, it has a brand new 64bit driver that still has some kinks in it... perhaps that could be affecting it. The only other midi interface I have is a BCR2000, which is on the blacklist, but only listed as problematic for OS X? I might try it on my girlfriend's PC and see if it works.

Okay. I've been slowly working through this document already, to no avail so far. But I still have some checks left to do. I'll report back when I've troubleshooted everything. Thanks!

Thanks for getting back so fast. If it's simply corrupted firmware then that's a major relief. Out of curiosity and a desire to avoid similar occurrences in the future, how might this have happened? Simply turning the core on and off too quickly perhaps? So assuming it's a matter of uploading MIOS, I'm back to my original problem of screwed up sysex. I guess I could try a different interface/operating system, but I'm basically stabbing in the dark on this issue. Any ideas?

Hi everyone, So a few days ago I finished wiring up a a core module and two sid modules (both from smashtv). At first everything seemed to be going smoothly; all the voltage tests were good and when I stuffed the IC's and hooked up my LCD I got a nice big "READY." I then proceeded to hook the core up to my computer to upload the midibox sid hex files, and ran into my first problem. The core sends an upload request which MIOS studio receives, but then it immediately hits checksum errors and midi in overruns when attempting to upload the first hex block. For refference, I'm runing the latest version of MIOS studio on snow leopard 10.6.2, with Mandolane installed. Midi seems to be working. In order to solve this I tried a couple things. I had read something funny about the LCD possibly affecting sysex reliability so the first thing I did was solder a 1k pull up resistor between +5 volts and d03 of j15, as per this schematic: http://ucapps.de/mbhp/mbhp_lcd_4bit_mios8.pdf . This had no effect. Then I thought perhaps I had wired up the connection from the core to the sid modules incorrectly, so redirected SC to SC instead of to MD. I now realize this was an error. I have restored it so it is once again SC to MD. Throughout these alterations everything remained fine. Then after a minute of having the machine off I went to turn it back on and... boom. No readout on the LCD. It just hovers at the block character screen and never gets to the mios boot up/ready screen. I have no idea what caused this. I have been over the connection from the core to the LCD meticulously with my multimeter and everything checks out. What's funny is that the PIC is still sending out upload requests every two seconds, so it at least seems to have some life. I am completely stumped at this point and am in desperate need of some assistance. Have I fried my PIC, my LCD, or both? Also, assuming I can fix my current problem with the core, I still need to figure out why I can't upload hex files to begin with. Thanks in advance, Jordan

Thanks! That clarifies everything.

Thanks so much for the quick reply Wilba. This information is super helpful. As a matter of general good practice, should I build in a 2200 uF electrolytic before the voltage regulator, in my external power supply? Or can the smoothing all take place after regulation on the PCB's? I suppose it couldn't hurt to have both.

Hi all, I've looked around the forums trying to find an answer to this and didn't see anything, but feel free to issue a prompt STFU if this is covered somewhere. I'm currently building a MBSID in a keytar form factor using the original C64 case for the body. Since the old breadbox needs to house a keyboard in addition to most of the circuitry, I'm pretty short on space and thermal management is a big concern for me. Therefore I want to get all voltage regulators out of the case since these are the likely candidates for generating the most heat. I've built an external power supply loosely based on the optimized PSU but using the guts from a couple modern AC adapters instead of the old c64 brick which I don't think would pump out enough amperage for what I want to do. My PSU supplies 5 and 12 volts regulated, in addition to a 9 volt line to run the midi keyboard. The PSU is very basic and doesn't do anything to the power except output DC and regulate it with a 7805 and 7809. When I hook this up to Smash's core and sid modules, I will obviously leave his regulators unstuffed, and I suppose I should throw out the bridge rectifiers as well since there's no AC to deal with. But what about the various capacitors on the power rail (C4, C5, C6 on the core module for instance?) I'm guessing these are working as reservoir caps to reduce ripple? If so that's a good thing to have. Could I just supply my power directly upstream of C5 (core) or C9 (sid) and be done with it (jumpering the 7805/7805, of course)? Or is there something I'm missing that is going to lead me to blow up my boards? I'm moderately experienced with electronics, but more on the microcontroller level -the ins and outs of power management are somewhat elusive to me! Thanks in advance, Jordan