Wilba

I had a closer look at your last posted upload message log... This was strange to me: MIOS Studio reports receiving a "MIOS SysEx Message" so the complete message would have been something like: "F0 00 00 7E 40 00 01 40 00 0E 0C 01 F7" which looks suspiciously like two messages merged, the upload request: "F0 00 00 7E 40 00 01 " (missing "F7" at end) and a frame error: "40 00 0E 0C 01 F7" (missing "F0 00 00 7E" at start) Now this could just be a dodgy "merging" of SysEx messages in the Java MIDI drivers... or maybe something wierd on the PIC... I don't really know... but you should at least try using MIDI Yoke routing tricks to see if this at least gets rid of the "unexpected MIOS SysEx messages" so all you get are just framing errors. Similarly, these "Received SysEx message of less than 8 bytes" suggests there's something wierd going on in the SysEx receive buffers... that some kind of merging is occurring... hmm... Can you try using MIOS Studio and also post a dump of the MIDI In monitor as well as the upload log? So let's for a moment assume the framing errors are valid. The framing errors might be happening in two directions - bytes might be dropped from PIC to computer... perhaps a cause of this merging Framing errors might be happening if the baud rate is not the same between the PIC's UART and the computer's UART. Since the baud rate is relative to the PIC's clock, and thus it's crystal and oscillator configuration, if the crystal is dodgy then that might be the cause... or even if the PIC's configuration bits weren't correct... the computer's UART might be tolerant of the PIC sending data slighly out of sync... The other possibility is that the PIC is receiving data but due to a faulty optocoupler, wiring, soldering or PCB fault, the bits it's receiving aren't right... the start/stop/parity bits of the serial data are wrong, the UART can't make sense of a random bitstream and throws up framing errors.

I've been lurking a while... might as well add my 2 cents (and a fresh pair of eyes) Explaining something makes you fully understand it. And it's cathartic. Just to clarify, exactly what "loopback" test was this? Did you plug a MIDI cable directly between MIDI In and MIDI Out on your computer's MIDI adapter?? If you've done this, confirm you get "local echo" (play some notes on the keyboard, or send SysEx or parameter changes or whatever, and confirm the MIDI In and Midi Out monitors show the same stuff). MIOS Studio is written in Java and some people have trouble with the MIDI drivers in Java, and suggest using MIDI Yoke to solve the problem... creating a routing between the "virtual" MIDI Yoke ports and the real MIDI ports. Did you confirm the ID programmed in the PIC is the same as the ID you are using to upload? (You've probably checked this, the PIC's ID is sent in the upload request). I feel sorry for you and know how frustrating it can be to debug something like this. You can always post the Core to me and I'll confirm it's a PIC or PCB issue and not your MIDI interfaces!

In that datasheet, the asterisk next to the "A" in the pinout is matched with the asterisk next to the "LED weiß Voltage", indicating that when it is a white LED backlight (i.e. white on blue LCD, etc) then you only need 60 mA and the voltage drop is 3.5v not 4.2v. I'm no expert either, I'm only highlighting a possible mistake... and it wouldn't hurt to use a bigger resistor, whereas you might burn out those white LEDs if you use one too small.

The Core has a circuit for controlling LED backlight current, it is usually connected to pins 15,16 of the LCD as per diagrams. Why don't you use this? Second, the white LED is 3.5V forward voltage... typically white LED backlights are only on the edge, not an array all around the LCD... hence the two different forward voltage specs (3.5v and 4.2v). SO I suggest you double check that 13 ohm resistor! You might be powering the white LEDs at 115mA!

You set the MIDI channel in the "CFG" submenu (parameter "Chn")

Yes it it is possible... My combined DIN/DOUT board for my SID synth doesn't have any of these extra capacitors and it works fine... I believe the reason C5 is on the DOUT and not the DIN is because DOUT outputs more current (drives LEDs), while DIN only outputs the one signal back to the Core. So yes, just put one of C5 for your one board, near where the +5v comes into that board.

For those of us poor people who don't have that much analog or SID synth experience, it would help to study those SidStation patches... I for one would love to hear the Giraya patches that are in this SidStation demo: http://www.sidstation.com/sidsound/sidonly/Joeri-GirayaDemo.mp3

If the fuse is blown, there'd be no power at all. If there's still some voltage on the output, perhaps the transformer is half fused or something, resulting in less output. You'll probably need a new C64 PSU. Before you plug it in, though, you should work out if your "bankstick bits" is what caused your previous one to fail. Use your multimeter to check short circuits between +5V and ground.

You have to learn how to troubleshoot! Disconnect the bankstick bits, retest voltages. Disconnect C64 PSU, test voltages coming out of it. If everything tests OK in isolation, then pull out the bankstick chip(s), look for short circuits in your bankstick bits, etc.

I can get your standard stuff, but not but not polystyrene caps or ultra bright diffused LEDs. Maplin does not have what I want.

Maybe SID 1 and SID 2 are both set to the same MIDI channel. The Link button ONLY enables/disables routing of incoming MIDI events to the slaves. This is a one-way connection, the master Core doesn't know if there are slave Cores/SIDs there or not. So with Link off, only SID 1 will play incoming notes (on assigned MIDI channel), with Link on, SID 1 and all slave SIDs will play incoming notes (on assigned MIDI channels). Also, the cool "play note" feature (hold down SID button, then press menu button) works by simulated MIDI note events, so if SIDs are assigned to the same MIDI channel, playing one SID with this feature will cause all SIDs on the same MIDI channel to start playing also.

Perhaps you should check out what Ixox is doing, and see how he's changed the code to suit his redesigned control surface... http://www.midibox.org/forum/index.php?topic=7569.msg51431

If you look at the wiring for the step C control surface: http://www.ucapps.de/midibox_sid_cs/mbsid_din_default.pdf observe that it extends the step A and step B control surfaces: http://www.ucapps.de/midibox_sid_cs/2x20_enc.pdf http://www.ucapps.de/midibox_sid_cs/2x20_enc_multi.pdf This is why there's only one "step C" version of the code, because the wiring for the simpler control surfaces are just a subset. So if you start with a simpler control surface, you can add some extra buttons/LEDs/encoders later. Some people have just added two to control the filter, and some have added one for every displayed parameter in the LCD (a fairly minimal code change). I wasn't too clear before, I was trying to work out why you want to have knobs assigned to CCs, and in MB-SID this wouldn't work too well as some CCs store more than one value (i.e. mod matrix assignments) so controlling with a knob wouldn't work well.

yeah, probably not dual ganged for stereo though... I know what the ideal solution is, it's just a matter of finding these perfect pots... my DIY solution is cheap and involves no hunting around for ages, which frankly I am sick of doing, I still can't find 22nF polystyrene caps, or <2% tolerance silver mica caps, or ultra bright diffused 3mm green LEDs, or knobs like TK's MB-SID... ;)

very cool... I like it.

The sid_play.inc file in the sidplayer zip has a link to the protocol which was reverse engineered by some smart Finnish guy, but alas the link to it is broken. Maybe TK has a copy?

I can only relate that once I had wierd upload errors on a previously working Core and replacing the optocoupler solved the problem. I don't know why it went bad though ???

Yeah, but I haven't found one with a good range... it needs to be at least 500k, and dual gang... Also note that any kind of feedback, even feedback going in through 1 Mohm, introduces noise... there's a distinctly audible difference in noise between a grounded input and input connected to output through 1 Mohm. From my initial playing with this new knob, I don't anticipate the need to automate its setting, I doubt I'll be tweaking it during live playing or recording... but I've noticed controlling the SID filter resonance can tweak how much the feedback has an effect - it's like they get multiplied together or something, I'm no filter expert... but maybe tweaking the resonance parameter is enough for most people. I fully recommend spending a couple bucks on a 500k or 1M pot and giving it a go...

I don't understand why you want the buttons and encoders to be assigned to specific CCs like that. It would involve a lot of custom programming to the MB-SID app, and I can't see the advantage. I also don't think motorfaders will be that useful, and would involve even more custom programming. If this is your first SID project, you should probably aim for making the "standard" step C control surface - and maybe initially just connect some encoders and see how they work... get a feel for what your "ideal" control surface should be... Just letting you know it's easier to change the layout of the step C control surface (and add a few tweaks) than rewrite it completely.

I can confirm that a pot in between a SID module's input and output does not blow up the SID ;D and does make some funky sounds. I've also observed that if you lower the SID's resonance then you can tweak this feedback knob to get better (and more!) resonance, to the point of funky self-oscillation squeal. What I plan to do now is hack a pot apart and break the resistor strip near the anticlockwise end... so that end is ground, the wiper goes to input, and the clockwise end goes to output. This will make a sort of switch, so when the knob is fully anticlockwise, the input is tied to ground (less noise), otherwise it will range from 1M to 0 ohms as you turn clockwise.

http://www.midibox.org/forum/index.php?topic=2510.msg16555

What a cool site! It was only the other day that I had a "what if" thought about routing SID output to input... and then someone's done it (and proved it's worth doing!). The mod he did to the SID2SID board to use the audio in of the second SID uses a 100k resistor to ground, which I assume is just copying the C64 schematic? TK's SID module uses a 1nF cap to ground. I'm wondering about the difference and whether the 100k resistor would reduce noise even more... he seems to get some really low noise!

When I did this last, I used some sticky tape to separate the wires into two groups of eight, one for each "row" of the 8x2 header. Do this before you start stripping the wire ends and this will help untangle the mess... you can separate the wires of the cable quite far away so that there's less stress on any one wire at the LCD - i.e. you cut them so they're all about the same length and soldered in place so they're all perpendicular to the LCD PCB. The best solution is to solder a header to the LCD, so you can put connectors at both ends of a ribbon cable with some crossovers in the middle (with some heatshrink tubing over each join). The "K" means cathode, the "A" means anode... so B+ goes to A, B- goes to K.

hehehe me too! Ahhh... that's really good to hear... I think Schaeffer should sponsor TK - he's generated a lot of business for them!

Hey, I get to be the first to congratulate! Nice job, very cool case reuse... I like how you used the case itself as the front panel.