Wilba

If MIOS is installed, you should be able to send LCD commands with MIOS Studio, this will test your LCD is OK and MIOS is installed. Otherwise, perhaps MIOS and some app is installed (or half installed?) so you won't get the "Ready"... so try uploading MIOS again, which should validate your MIDI send/receive (i.e. use feedback from core).

Most likely 6mm ALPS tactile switches, shaft length 13mm? If you go to ALPS website you can find the exact part number, and get a 100 piece pack from an ALPS distributor. It is best you plan ahead and make sure you get the right length to suit how far back you mount the board from the panel, and also thickness of the panel. There's a few different types, what type are you after? I like the ALPS 16mm detented encoders (I actually have "clones" made by Electronics China). They're easy to open up and make non-detented and work perfectly for MIDIbox. Ribbon cable like the grey kind for use with IDC connectors? It will do for most uses, even to supply power to LCDs and other modules.

The pin arrangement on the bridge rectifier on that page is different to the ones I use, which has the "~" pins diagonally opposite each other, the "-" and "+" pins in the other corners. Perhaps yours is the same, and you're connecting it wrong, which will short circuit between the AC inputs! Use a multimeter to test the actual diodes in the bridge rectifier.

It looked like Jorge did a cool trick to create the grooved borders around sections... using one piece that goes behind the C64's front panel edge (with cutouts), and then putting smaller pieces on top of that. This not only gets you a front surface that's at the same level as the original case, but it should be stronger where it joins to the original case, and you could use a stronger or thicker material for the rear layer for strength. If you've got heaps of cases spare, reusing bits of a second case is ideal, that stuff is pretty strong plastic... I guess I'm just suggesting to support the new front panel with something that overlaps it and the edge of the original case's cutout. You might want to consider the easier solution of sticking the new plastic panel on top - if you round the edges a bit, and fill gaps with a bit of putty, and spray the lot one colour, it won't be that noticable and a lot easier to make.

Click on the link!

I live in Melbourne, and so does stryd_one... I haven't build an MIDIbox 64 though but can help you out with finding parts. Rockby Electronics have A LOT of good gear at good prices... I went there yesterday and the guy told me about their unadvertised "warehouse" they have next door... it was full of clearance items at ridicuoulsly cheap prices.... stuff that would make a MIDIbox builder drool... all kinds of switches, rotary pots, slide pots... whole tubes of 74HC4051 (like 24 in a tube) for $2.50 (that's what you need for the AIN module!), lots of nice aluminium knobs, screws, rack mount gear, cases, etc. Other good vendors locally are Crest Technologies and Switches Plus, both can give you some of the exotic stuff like encoders and LCDs and PLED displays.

also: http://www.midibox.org/forum/index.php?topic=5047.msg32059#msg32059

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

If the MB-SID wavetable could control all SID regsiters with each step, then you could quite easily turn a subset of the SID register dump into a MB-SID patch, just like HardSID... the only tricky bit would be finding the exact start and end of the desired sound... and even then it might not capture note-relative differences... i.e. maybe the filter cutoff varies with note pitch, etc. Anything that might be different depending on what note is played is not going to be captured correctly. But again this assumes you could play back all SID registers. MB-SID's wavetable can only control three CCs. You could make a very similar sounding MB-SID patch by using envelopes and LFOs to modulate the pitch, pulse width and filter cutoff, but turning a set of discrete register values back into envelopes and LFOs is non-trivial ;) What might be reasonably easy to do is write more perl script converters that can output the data a little more like MB-SID parameters, so the user can at least have a look, and manually set up the LFOs and envelopes. One strange thought though: SID files get played back at ~60 Hz whereas the MB-SID can update at 1220 Hz! So even if you get the envelope and LFO waveforms to match, MB-SID is going to produce smoother modulation - any "sample and hold" artifacts from a ~60 Hz update will be lost, unless you also add in S&H ;) Not too hard, just hard. The SID register dump is in hex and it doesn't expand each SID registers into its component bits, i.e. the column labelled "WF" (short for waveform) shows SID register "Control Reg" (refer to SID datasheet) - the "4" is pulse width waveform bit, the "1" is gate bit. This could be translated into more MB-SID friendly values, I agree ;) But don't wait around for someone to do that for you... check out the SID datasheet which describes all the registers and what they do... learn hex numbers and decypher the "Cobra" sound yourself.

LMAO... I beat you by 45 mins... HA! http://www.midibox.org/forum/index.php?topic=7675.msg52217#msg52217 ;D ;D ;D

SID songs are really just a capture of the SID register changes... they're like the original "game" machine code stripped down to just the SID register update bits... and SID player apps (on the PC side) are basically a mini-C64 emulator. So turning a sequence of SID register changes back into envelope/LFO/wavetable parameters automatically is hard... but there are tools to help you do it manually. You can capture a sequence and play it back, and the HardSID software let you do this, so I go a-hunting and found this for you ;D Mechanicus Guitar Patch Tutorial So if you're clever enough, you can identify which bits are setting the oscillator and filter configuration, and which bits are setting a pitch and gating oscillators (i.e. starting a "note") and then which bits are modulating the modulateable? bits after the gate. If you're up to doing this a bit more manually, check out TK's tutorial on ripping C64 sounds by looking at the SID register changes.

It was probably me ;D

There's nothing wrong with nagging them... 20 days is quite a bit over. Just remember if they start ignoring your emails then get your money back on your credit card ;) toneburst: those pins look right to me too... and while you probably won't rush out and buy a crimping tool, they're well worth the $10 and save a lot of cursing. Just make sure you buy lots of spares as sometimes you make a mess of the crimping and you can't reuse it...

I didn't think it would work, but I just successfully burned a PIC16F88 with my trusty old JDM burner and WinPic800. Haven't actually tried the IIC MIDI app yet, but it verifies OK. I added an 18 pin IC socket to my JDM and wired it up like the adapter published here. I've also burned the PIC18F4620 successfully as well... so if you have a JDM burner that worked fine for PIC18F452 chips, then give it a go with the other ones and you might not need a new burner! btw, WinPic800 is really fast too... I don't know what magic it does, but I've had none of the hassles I had with IC Prog...

No I didn't... ;) I actually bought a whole lot from Futurlec, but alas I've ceased recommending them after the last order was bungled so badly and they stopped replying to my emails and then I got the credit card charge retracted... *evil laugh* It's a pity cos they had good prices for these kinds of things which have such a stupid markup from local distributors.

Thanks for that info, Roter! I'm still not clear about how the SID could get fried. If the audio in is open, the capacitor doesn't have a ground, so how can it charge up? I still believe though that if the audio in was permanently tied to ground, before inserting the SID and turning on, then you would never have a problem. In fact, if you always have the audio in tied to ground, it makes that extra 100K resistor redundant. But if the later C64 schematics have that 100K resistor tying the audio in to ground, then it can't hurt to add it in.

It sounds like a good idea... I've just finished my new MB-SID front panel PCB and I can give some advice. It's possible to make a PCB footprint that can take the ALPS 16mm encoders or the smaller Bourns or ALPS ones... since the pins aren't overlapping you can add tracks to support the differences in pinouts as well. Some people would be happy with TK's placement of the encoders (they aren't perfectly aligned with the "steps" on the 2x40 LCD) whereas some people (like me) may want to use smaller knobs and place the encoders exactly aligned with the "steps". One of the advantages of getting a PCB made is you aren't restricted to 0.1" (100 mils) alignment so you can align the encoders exactly to the steps. Either way you go on this, you still have to choose a "standard" 2x40 LCD size (they're not all the same!) so that the front panel cutouts are the right size, and the mount holes on the PCB are right. Getting the right knobs is the biggest hassle, I've found... TK's design uses knobs from www.albs.de which are relatively cheap (I think 0,60 EUR?), and the front panel holes are bigger than the knob diameter so they poke through the panel. This I assume makes the construction easier, you can mount encoders, buttons and LEDs all on the one board. Basically if people are going to use a standard PCB and panel, they will also need the right knobs to suit. Same with buttons and button caps. One final point: After seeing Rigo's ingenious use of JB Weld here, I plan to use this technique to mount my PCB to the panel and provide lots of support everywhere... I plan to use threaded metal spacers (looks like a 10mm tall M3 hex nut) and glue these to the panel and then mount the PCB to these. So maybe you don't need to drill mount holes in the front panel - people can use this trick to make mount points where they want them, and this might help accomodate slight differences in LCD dimensions, etc.

You might want to read the thread about Feedback Loop on SID ... the link presented: Commodore C64 Modifications :: Adding A Feedback Loop also discusses the grounding of the input pin for low noise, on the next page. Also, the SID module has a capacitor between the SID input pin and port J4 (the audio in port) and you "ground" the audio in at J4, not at the SID input pin. This is supposed to protect the input pin. Since this is an input pin, I can't see how that pin even if it was tied directly to ground could cause any problems... there would be no current going into the SID, and no current going out. I don't know the specifics of how other people have fried their SIDs... where are these tales of tragedy? Post some links please! I have plugged and unplugged a lot of 8580s and 6582s into my PCBs which have the audio in pins bridged (i.e. always grounded) and have not fried any SIDs because of this. I've even listened to the noise go up and down while grounding/ungrounding the audio input, and still not fried a SID this way. So stop worrying ;D

This is a great idea, Smash! I suggest even putting on a test app that might assist people getting MIDI communication going.... like MIDImon perhaps? That might be a really easy way to prove the PIC is receiving MIDI, with any old MIDI hardware you have... so if you have trouble uploading new apps, you can start the debugging at the PC end instead (i.e. MIOS Studio, MIDI drivers in Java, MIDI interfaces, etc.)

another tip: put the PIC in a spare IC socket (assuming you use the cheap ones, not the expensive machine pin ones)... this makes it easier to insert and remove from the PCB as well as preventing the pins being bent. An old trick from when I was constantly moving PICs between PCB and burner. You should also get an IC removal tool... just a cheap one that looks like a really wide pair of tweezers... I can't believe I went so long without one, cursing every time I had to pull an IC out... if only to give the SID chip some respect, get one ;D

Good to hear! Just to recap: you swapped the two optocouplers around, so now the SmashTV PCB (which previously was giving the frame errors and overrun errors) is WORKING? and the Mike's PCB which was only sending out upload requests is unchanged? You really should swap the optocoupler back and prove it's really the optocoupler (you seemed to think reseating the optocoupler was the cause, highly doubtful, but make sure anyway). Put a big tick on the "good" optocoupler!!! So Mike'S PCB is broken in another way. It's hard to know how, since you had the "good" optocoupler in there, and the PIC which was eventually proved to be good, and the loopback test passed... since it's sending upload requests, the PIC is powered and oscillator is good... maybe it is continually resetting? Check power supply I guess... and all solder joints around the optocoupler, TX, RX pins... The best news is, you now have a working PIC + Core PCB + MIDI connection. This makes debugging the second Core a lot easier... because you know what the bug CAN'T be... Now that you have MIOS on the PIC, when you put it in the other PCB, you should only get ONE upload request, and you have 2 secs to upload a new MIOS, or you can upload an application at any time. What this means is when you put that PIC in the other PCB, if you keep getting upload requests you know the PIC is resetting itself for some reason... I guess you could also try the LCD in the other PCB and check if it's "READY" also...

well in theory, if you receive the upload request, this sort of proves that the PIC is running and its UART is set up with the right baud rate, etc. since your computer is receiving it fine. There are configuration bits burned into the PIC so the bootloader and MIOS know whether to use standard MIDI baud rate or the alternative serial port baud rate (and more recently, whether to use IIC_MIDI instead). What I'm confused about is the frame errors and overrun errors... because I think they imply the PIC is receiving at a different baud rate, or with serious bit errors... but your loopback test proves that at least your MIDI interface sends and receives at the same baud rate without errors... hmmm... I was theorizing about the oscillator... it's definiately working or you would not receive upload requests at all. If I were in your shoes with what you have at hand, I would get one of those experimenter boards, in Australia they're called "Wish boards" (brand name), I guess they're also called breadboards... they're white or cream coloured plastic boards with lots of holes in them that you can insert components into without soldering... then I'd make up a Core board with that... I guess this assumes you have enough spare bits lying around... What you'd end up creating is the bare minimum to get the Core sending and receiving MIDI, which is basically the 5v supply (7805+caps), the crystal and its two caps, the optocoupler bit and the MIDI sockets... and also 100 ohm resistor tying the reset pin to 5v. OK, it's a big ask I guess, if you're not really into electronics or have the extra bits lying around... but if you're keen to keep up the hobby and make more things, one of these experimenter boards are very cool to have around, you can easily whip something up to test circuit ideas etc. or even just test LEDs or chips... Back to the issue of the two boards giving different error messages... Can you swap the optocouplers and see if the error messages stay the same? i.e. if they swap their error messages also... I know both PCBs passed the loopback test but it might be useful to know if one optocoupler produces errors the other doesn't.

well if the loopback works, then I guess it has to be the PIC not working properly... either its oscillator/clock is bad somehow or there's still the chance that the MIDI interface is at fault. You've basically validated the electronics and wiring between PC and PIC... so now it's just a matter of either end being the fault (although there's still the change the PCB is at fault)... At this point, (if it was me) I would be trying that PIC in another known-working Core, and trying a known-working PIC in the non-working PCB... this would identify if it was the PIC or the PCB.

Sebo is right, but the versions he speaks of are out by one :-) In a multi-SID box (V1) you can have each SID on its own MIDI channel. For a single SID, I think TK said once that you can assign each of the three oscillators its own MIDI channel, but this was only configurable from SysEx, not from control surface, and I can't find out how to do this from the documentation. In V2, it is planned that you can do this a lot easier, and one SID can have three single-oscillator "mini" patches for a C64-like sound.

You've copied the MIDI output log in the first post, not the MIDI input log... OK so the last log from SmashTV's PCB... I assume you're using MIDI sockets soldered directly to the PCB? That would eliminate any MIDI socket wiring mistake perhaps, leaving just the issue of soldering joints, optocoupler or PIC... the fact that you're getting frame errors and overrun errors indicates that the PIC is receiving something, otherwise you would ONLY receive upload requests. NOTE ALSO that the bootloader will reset after each frame error or overrun error, and so you will receive another upload request after each error. Try this test again: http://www.ucapps.de/howtodebug/mbhp_core_extract_io_loopback.gif What you're looking for here is an echo back of what you send... TAKE THE PIC OUT OF THE SOCKET and short the TX and RX pins (just shove a bit of wire into the IC socket!) In MIOS Studio, if you compare the MIDI In and MIDI Out windows while trying to do an upload (you will have to start the upload manually!) then they should be the same. This will validate the optocoupler, the MIDI In and MIDI Out wiring, and hopefully your MIDI interface. You should try this with both PCBs and see if you get the same results. Don't assume that since you've done this before that you don't need to do it again! GET NEW RESULTS! Oh, and unplug that LCD and everything else, just power the Core PCB... OK so assuming you get good loopback, then you can basically assume that the PCBs, optocoupler and MIDI wires, cables, etc. are all good, and move on to debugging if it is the PIC itself that is the problem or the UARTs on either end not talking nicely (i.e. the PIC's oscillator is not right, it's UART not set up correctly somehow, bad configuration bits burned on the PIC)... Did you burn the PIC yourself? It's definately a PIC18F452? Is the SmashTV PCB built completely from a SmashTV kit? Just checking ;-) ANYWAY from what you've just posted, the fact that the two PCBs do different things implies that there's more than one error... i.e. each PCB might have a different soldering fault, or one has a soldering fault and the PIC is also faulty, etc. Do tests on both to see what is different... as this can highlight specific issues with the PCBs perhaps...