Filch MB6582 - It lives?

[Filch]

Hey Guys,

First wanted to say thanks to all the people who have made this project possible. I'm looking forward to coaxing the first sounds from my mbsid.

I'm currently testing with power connected. The wiki says to check the juice at J25 and should read at least 9, but likely around 11 depending on load.  I'm getting about 18.5 there and I'm wondering if that is too much going there?

[Wilba]

18.5V seems a bit high... J25 is between the bridge rectifier/filter capacitor and the voltage regulator, so it's converted the 9V AC into DC but it's still unregulated and "lumpy". I can't easily check what it would be without load, although I've just started populating another MB-6582 base PCB so I'll have to check while I build it.

It would be good to know, if you are definitely checking voltage difference between the two pins of J25, and what PSU Option you are using.

[Filch]

It's PSU option B and the smashTV parts kit.   I was checking the load between J3 ground and J25 9v. I guess I was testing this incorrectly and should be testing between the pins on J25?  I'm getting about 13.5v on J25 pins which sounds a lot better.

[Filch]

I'll take the silence as a yes I was testing incorrectly :)

Now to attach the LCD.

[Wilba]

You can take silence as "Wilba was working, asleep, or didn't see the new post" :)

PSU Option B adds the 9V DC (from the C64 PSU's separate 9V AC) on top of the regulated 5V DC from the C64 PSU. Thus you were measuring ~18V relative to the 5V DC's ground.

J25's only use is as a separate unregulated supply for powering a fan, if for example you didn't want to run it on the 9V or 12V (or 5V) rails which may introduce noise into the audio. That CAN happen, as I discovered, and ironically, it's the cheap black fan that happily runs slowly on 5V that makes no noise, and the more expensive, red LED fan that is both mechanically noisy and puts a whine in the audio too.

[Filch]

Thanks Wilba,  that's good info to know about the fan.

Right now I'm getting a lit, but blank LCD when powered up. I can see the core is sending out the sysex request at boot, only once, which is good. Although it appears it is not getting midi returned to it. I'm currently looking through the wiki on troubleshooting that to make sure my midi in is working.

[Filch]

To make sure I didn't have a bad midi cable, I started to swap the in/out cables I had setup. When I moved the cable that was in the MB IN to the Out,  my LCD backlight came on very dimly..... with the power switch off.  :o    This cable was still plugged into the MIDI Out of my audiocard, so Out to Out and my LCD backlight lights up slighty?  Is that normal?

As soon as I move the cable to the proper in/out , backlight goes out.  This only happens when I have midi out connected to midi out,  In to In does nothing.

[Filch]

Oddly enough, I'm getting feedback from the core now via midi out and I can successfully load MIOSv1.9F.  And after realizing I should be adjusting P2_Core1 and not P1,  I got my "ready"  :D

I was able to successfully load up the SID V2 application and I'm able to play notes via midi. I think I can officially say that my MB-6582 is alive. That midi out to out making my LCD light up a bit freaks me out a bit though.  I'm off to test the other chips now.

Thanks for the help. I'm sure I'll have more questions and issues when I start the control surface.

[Filch]

I've fitted in the rest of the chips, and when I turn it on it begins by saying "Cloning Slaves". I then get the Launching CS afterwards and then just a stuck tone at C3.  I have to hit the midi key in order to make it stop.  Not a deal breaker, but annoying if that's what I'm going to hear everytime I boot up.

And everytime I boot it says Cloning Slaves. Is it supposed to do that every time?

The LCD says shows up at boot :

Oscillator  L-01--

Trn Fin Por Phs PW

  0  0    0    0  800

Any ideas as to what I should be looking at?

[Wilba]

That midi out to out making my LCD light up a bit freaks me out a bit though.

Weird... It could be that the sound card is outputting 5V on that pin if the MIDI Out, which is now connected to the 5V tracks of the MB-6582 PCB through a 220 Ohm resistor (as well as grounds being connected) and this is just enough to power the backlight a little, but not enough to boot the PIC.

I probably would not worry about it, the fact that you have working MIDI In and MIDI Out means there's nothing wrong with your PCB.

I've fitted in the rest of the chips, and when I turn it on it begins by saying "Cloning Slaves". I then get the Launching CS afterwards and then just a stuck tone at C3.  I have to hit the midi key in order to make it stop.  Not a deal breaker, but annoying if that's what I'm going to hear everytime I boot up.

And everytime I boot it says Cloning Slaves. Is it supposed to do that every time?

The LCD says shows up at boot :

Oscillator   L-01--

Trn Fin Por Phs PW

   0   0    0    0  800

Any ideas as to what I should be looking at?

This sounds like the master PIC thinks buttons are being pressed and perhaps also that encoders are being turned. That could be missing pull-up resistors on the DIN inputs (i.e. R30-R39).  If you haven't got a control surface connected via the pads at the bottom, then it should not do anything - i.e. the base PCB can work fine without a connected control surface, even with the DIN and DOUT chips installed (U16-U23).

[Filch]

This sounds like the master PIC thinks buttons are being pressed and perhaps also that encoders are being turned. That could be missing pull-up resistors on the DIN inputs (i.e. R30-R39). If you haven't got a control surface connected via the pads at the bottom, then it should not do anything - i.e. the base PCB can work fine without a connected control surface, even with the DIN and DOUT chips installed (U16-U23).

I do have 6 pin resistor networks in all of R30-R39. Now I had to cut out R39 b/c I soldered it in backwards, and I had some 6B103G , instead of 6A103G and I used that. I couldn't see any technical difference between the two. Could that be the problem?

The master PIC was doing this when I had just the one PIC in.

*edit*

I think I found the issue.... will post after

[Wilba]

Yep, resistor network in R39 not being correct will be the cause. FYI the left-most pin (closest to the label) is the common pin of the resistor network (but you already knew that I'm sure).

[Filch]

I replaced the one resistor network with a proper 6A103G and now it's working right  :D

I'm amazed b/c both the 6A103G and the 6B103G are listed as 10kohm %2 resistor networks. Not quite sure what the difference was and I bought both. Thanks again for your help. If you hadn't steered me towards the resistor networks, I'd have been looking for something all night.

[Wilba]

Ahh... yeah that would be it.

Judging from part numbering of the resistor networks that SmashTV uses:

http://au.mouser.com/catalog/636/619.pdf

"A" means common bus, "B" means isolated.

So in this case, it was probably three isolated resistors, instead of five connected to 5V.

I think I better update the wiki to avoid this kind of mistake  :P

[Filch]

So after loading up the vintage patch bank and playing around (sweetness) , I decided it was time I should make sure all the other cores and outputs were working. Unfortunately, plugging my LCD onto cores 2 through 4, I get nothing from the LCD. No backlight, nothing.

I loaded MIOS Studio and was going to try to manually load the testtone application to the rest of the cores.  I set it to "Wait for upload request before starting" and Smart Mode. I placed J11 to core 2 and turned it on, I got the following reply from MIOS Sutdio

"Recieved unexpected MIOS SysEx message = 0007E400301F7 expected = 00007E4000"

I get this also from core 3,  and on core 4, I get no response. Am I going about this wrong or did I miss something?

[toneburst]

Did you swap the jumper on J11? I missed this the first time, and couldn't work out why I wasn't getting any MIDI data in or out of any of the cores. It should be between the right-hand set if pins to route MIDI to/from Core 1, between the next set of pins for Core 2, etc.

a|x

[Wilba]

There is no backlight on Cores 2,3,4. You may need to adjust contrast pot to see something.

That rather cryptic message is saying "Hey I expected a message from PIC ID #0, and got one from PIC ID #1". So basically, you're putting the jumper in J11 correctly, but not changing the "Device ID" in the upload dialog.

Always use "Smart Mode", but you only really need "Wait for upload request before starting" for uploading MIOS... applications can be uploaded at any time (unless the current application is badly behaving and has stopped responding to MIDI events).

[Filch]

"Change Device ID in MIOS"   ;)   - that makes complete sense now

PIC #0 - works great, LCD works

PIC #1 - still sends me the message, "00007E40030107 , expected 0007E4001".  So it looks like that PIC thinks it's

             PIC ID#3 (core 4)???

             I have J11 set for core 2. The MIDI IN Monitor shows that PIC is sending out that sysex string every second.

PIC #2 - I can load applications to it no problem, but still no LCD

PIC #3 - No response at all, no sysex string spit out, no LCD light

I remember I had swapped some cores to make sure I didn't have a problem with one of them during initial testing, it's likely that they got cloned w/o me realizing.

So seeing that the core I had in 2 thought it was 4, I swapped out my the pics for core 2 and 4.  Now PIC #1 spits out 0007E4001, like it should. And now it will properly take application loads.  Still no response from the Core 4, which is strange b/c it that socket must've been working at one point for that core to be programmed as thinking it was PIC #3.

In regards to the LCD, it's not contrast. The backlight would be on core 1, but blank screen b/c I had contrast wrong. I adjusted p2 for that core and I can see the text. On cores 2, 3, and 4, I get nothing, not even a backlight. I tried adjusting the p2 for those for kicks and there's nothing.

**edited pic #'s to reflect 0,1,2,3 not 0,1,3,4**

[Wilba]

The best way to debug this now (and avoid confusion) is to debug the PICs separately from the Core modules.

In other words, it doesn't matter which "Core" you use to upload, only that the PIC ID and the ID in MIOS Studio match.

So, since the master Core module is known to work, try uploading MIOS and the application using J11 set to 1 and always putting the PICs in the master Core module (far right). Once you get MIOS 1.9f installed on each PIC, you can check it's working by looking at the LCD connected to the master Core module, it should show "READY."

What's confusing me now is that you list PIC #0, #1, #3 and #4. The IDs should be 0,1,2,3 and go in Core modules 1,2,3,4 (my fault for labeling the Cores this way! I should have labeled them 0,1,2,3 like the PIC ID).

FYI repeated upload requests (like what you're seeing for PIC ID#3?) means there is no MIOS installed. Once MIOS is installed, then it only sends out one upload request on startup.

So what you can do now is try to upload MIOS and the testtone app onto each PIC in the master Core (Core 1). Then once you know all the PICs have the application, try (for example) PIC #0 in Core 2, 3, 4 (changing jumper in J11 to match) and then testing both MIDI Out (upload request), LCD, and MIDI In (try using the debug functions in MIOS Studio to send the LCD some text!)

btw I think you are a bit confused about the PIC ID... this is "burned" into the PIC when you burn the bootloader and doesn't change by uploading MIOS or applications... it's totally separate from the Core that you plugged it into. The Core modules don't have an ID,  they're all the same, connected to the same MIDI In, with J11 controlling which has MIDI Out, the only difference is three of them don't have LCD backlight and only the master Core is connected to the 8x Banksticks (patch memory).

[Filch]

I already started what you said and programmed each core individually. I'm clear about your pic 0-4, relating to core 1-4, (I used to do some programming back in the day), I think I may have relayed it confusingly. They all have the latest MIOS, and all have the

MB6582 app loaded. 

So now I understand that the core 2-4 don't get backlight power, and turning contrast, I can see the text there. I was expecting backlight so I thought it was not working properly and not looking hard for text. I see that now.

With that said, cores 1-3 are go. Core 4 is not. I'm getting just black bars on the LCD screen, no hello sysex string seen.  I swapped out Core 4 with 3 just to be 100% sure I wasn't having a PIC issue, and it works just fine. So something is wrong with the socket or something to do with that... I think.

**edit**

Think I found the issue, have an incorrect ceramic capacitor on core 4.

**edit 2**

Yah, correct capacitor would do the trick.  1000pf vs 33pf makes a pretty big difference.  Thanks so much for helping me sort it out.  Now off to do test tones.

[Filch]

Output 3 -  I'm getting sound, but only if I plug in the audio cable up to the second pin, if I plug it all the way in, I don't get the audio.  Output 1,2, and 4 are working fine.

I reflowed the contact points for Output 3, but I'm still only getting audio when plug halfway in to the second pin.

[Wilba]

I had something weird like this before, and traced it to using an adapter plug which was actually mono:

(Damn Futurlec shipped me one which was stereo to mono, in among ones which were stereo to stereo).

This is probably not your problem though, if you're using the same audio output cable and testing each audio socket in turn.

Hmmm....

I would suggest plugging in a cable to that socket, but leaving it disconnected at the other end (i.e. not going into sound card, mixer, amp etc). Then test continuity between the plug that the other end, and pads on the PCB, and then also check for shorts between the pads and ground etc. I suggest the plug being in the socket because when the plug is not in the socket, the outputs go through the switch part of the socket into the passive mixer resistors, which might confuse the test.

Explain more your symptoms as well... if you plug it in half-way, do you get audio only on the left channel?

[Filch]

Using same patch cord.

I noticed that output 4 is exhibiting the same symptom now.  Not sure if I just missed that fact during the first test, or it's situation has changed. I had all four outputs connected with a cable and I got audio from 1 and 2, nothing from 3 or 4 if I had it all the way plugged in, but audio from both if plugged up to pin 2.

I did a continuity test between each pin and the ground. Pin 1 for every socket had continuity to the ground.  None had continuity on the 2nd and 3rd pin, EXCEPT for output 3, which I'm getting continuity on the 3rd pin to the ground, which is different from all the other outputs. I thought that since the same thing is happening on my output 4, that I'd find it grounded out on the 3rd pin too, but not so. And since both pin 1 and 3 of output 3 are connected to the ground, obviously I connectivity between pins 1 and 3 on that output.

Now initially during my build, I had put in jumpers at J21B - J24B before realizing those would not be required with the board mounted jacks.  So I removed those, but the holes are still filled with solder. I don't think that's an issue, but thought I'd mention it.

**Edit**

With the board laying flat, and the outputs at the top,  R74 was grounded out on the left side, which goes to pin 3 of output 3. I removed that resistor and ping 3 is still grounding out. I can't see any bridge issues

**edit 2**

I found that the pin that is grounding out is the one that goes to J3_SID3 OUT.  None of the other J3 OUT's are grounded.

[Filch]

I'm trying to figure out where this is shorting at, but I'm at a loss at this point. Unfortunately my skills at reading a schematic are not very well trained. I'm trying to follow the trace along the components, but I'm getting lost. I don't see any solder bridges, so I'm a bit dumbfounded.

[Wilba]

OK so for all those pins which should not be connected to ground, you need to check the pads are not shorting to the ground plane (on the bottom)... and also check the tracks connected to that pin all the way back to the audio buffer.

I've just uploaded new PDFs of the base and CS PCBs (I had not done this for revision 2 boards yet).

So now it should be fairly easy to trace the top layer tracks using the PDF. For example, the short could be even at J3_SIDx/J23_SIDx, or J21B,J22B,J23B,J24B etc. (You're not grounding it by using a jumper on J3_SIDx/J23_SIDx? Jumpers should go between the left (IN) and middle (GND) pins only.)

There is probably no harm in desoldering the joints from the audio sockets (but not removing it) and doing the same for any connected pads, testing for shorts after each desoldered joint. Maybe the short is in the joint, a tiny hole in the solder mask making a short to the ground plane somewhere.

In an absolute worst case scenario, you could desolder and remove the audio sockets, but only if you really give up finding it elsewhere... even if you lift pads of the audio socket in the process, that's not the end of the world, you can just solder wires on the bottom side to replace the disconnected tracks.