Lall

Hi, Yes, you absolutely need that eeprom as the EZ-USB code is stored in there. (Well to be 100% correct, you may not use it but then you have to use the download tools to download the EZ-USB firmware every time you power on the board...). It looks like you can for some things use a 24LC65 instead of a 64 but some other things don't work apparently : http://www.dontronics.com/simmstick_old_messages/0451-0480.html. Let's put it that way, if you have a 24LC65 at hand, it won't hurt to give it a try. If you have to order something then order a 24LC64... Best regards, Lall

Excellent news ! Have fun with your brand new MBHP USB-MIDI interface :) Best regards, Lall

Hey great news, congratulations :) Good luck for the following steps... Best regards, Lall

Hi, That's really really strange. Well indeed there's a direction. The ~ should be connected towards the J1 and the + - towards the big capacitor. When I look at the picture you've posted, it looks like you could have swapped ~ and +/-. Best regards, Lall

Hi all, To add to the MidiBox Bloopers list, I've fried a PIC and a LCD controller with a custom made PSU that had a slightly desoldered regulator (actually copper traces were a bit taken off because I never put the PSU in a box) that gave the input voltage at its output... Luckily enough my PIC was unmounted at that moment :) I'm currently working on a SEQ and I'll put in some protections against overvoltages, shorts and voltage inversions. For the SEQ it's maybe less severe because it's just components you can still find easily in shops but for the SID and FM, I think it's definitely more than worth it. Best regards, Lall

Hi, Getting nothing at ~ and 9V at + - does not make sense. It's impossible to have something at the output if you have nothing at the input... Are you sure you've set your multimeter in AC mode when measuring ~? Have you set your multimeter in DC mode when measuring + -? If so, then I would say that the rectifier is working OK. Then you could proceed with step3 as described by Doc. Maybe it's the regulator that has gotten fried by the short made with the board holder. Best regards, Lall

Hi, Nice job you've made there. Best regards, Lall

Hi, I prefer looking at the Core schematic for the front/rear: http://www.ucapps.de/mbhp/mbhp_core_v3.pdf. In that one, it's clearly explained and still every time I had to solder wires on a MIDI connector, I had to think twice... There are no numbers on the pins of the MIDI connector but by comparing both documents, you'll be able to derive them. For the output buffers and even if lots of midiboxes around here are working so indeed they are not that needed, I still prefer putting one and that's what I'll do in the SEQ I'm currently working on. These inverter chips costs really nothing and having them will not hurt at worse and may help at best... Best regards, Lall

Hi, As you can see from the Core diagrams, these inverters are not used. My understanding is that these two inverters are used as a kind of buffer that act as a protection because the micro-controller is not directly connected to the MIDI port and also as a driver that makes sure that the MIDI out will be strong enough to drive the other end when maybe the UART output wouldn't be strong enough. You can use inverters like 74HC04 or 74HC14, they should be strong and fast enough for MIDI. I've also seen gameport-MIDI adapters made with simple transistors. Maybe a stupid point, but have you double-checked the pinning on the MIDI plug itself? This rear vs front view can be a cause of error sometimes. Best regards, Lall

Salut Kikok, Côté boitier, tu trouveras peut-être ton bonheur chez Hammond: http://www.hammondmfg.com/. Ils font des boitiers métal assez bien résistants, il faut voir si tu trouves la forme et dimensions qui t'intéressent. Pour les switches, tu peux faire une recherche sur "bulgin anti-vandal" chez Farnell: http://www.farnell.com. Tu trouveras des boutons à la comme ça: http://be.farnell.com/jsp/Electrical/Switches+&+Accessories/BULGIN/MP0037/2/displayProduct.jsp?sku=3114648 Normalement, ça ne devrait pas poser de probleme à l'utilisation au pied. Bon faut ptet pas sauter à pieds joints dessus non plus mais bon ;D Nous on s'est servi de ce genre de matos pour notre pédale multi-effet: http://www.axoris.be/MissParker/pics/PCB_inbox.jpg et ça convient bien je trouve, à part le fait que la couleur du boitier n'est pas des plus sexy... ;) A+ Lall

Hey, I would definitely advise you to add a heatsink or use the metal case as heatsink as mentioned by Lyle. As you have a 9V DC input and an 5V DC regulated output, the regulator will see a difference of 4V at its pins. When you draw 580mA from the regulator, it has to dissipate 4V * 580mA which is 2.32 Watts. If you look for example at the datasheet of the KEC 7805 on this page: http://www.datasheetcatalog.net/datasheets_pdf/7/8/0/5/7805.shtml it says that the regulator can handle 2Watts without heatsink. Such information is not always available (in these terms at least) from datasheet but I believe 2.32Watts is too much for a 7805 without a heatsink so I would go for one or for Lyle's solution. Best regards, Lall

Hi Drew, I think it would be wise to take a look at the datasheet of the LCDs you have. The ones I have consume 560mA which is a hell of a lot. When you take two of them, you already consume about 1A for the backlight... If yours are consuming a lot as well, you may consider changing your ac/dc adapter for a more powerful one because 500mA at 9V is not so strong. Best regards, Lall

Yes, you can solder it in the empty holes left from the 7805. Just watch out to choose the two right ones and much more important the right polarity. That would be a pity to burn the FM chip because of an inversed polarity. Remember, there's no protection at all when you power the core+fm from J2. Best regards, Lall

If you have already 5V stabilized power supply, you can connect it directly to J2 instead of J1 on the core. To be safer, you should un-solder the 7805 regulator but you can leave C3 and C4 for correct decoupling. Please note that you should be absolutely sure of what you're doing as from J2 there's NO protection at all agains overvoltage, ... When you connect a power supply to J1, the regulator is playing the role of the protection which is safer. In other words, you run the risk of burning PICs, optocouplers, whatever connected to your core if somethings goes wrong when you use the J2 option. As Lyle proposes, the best is to keep the Core rectifier and regulator and find out another PSU with higher output voltage. If you really feel safe with using J2 then that's a second option... Best regards, Lall

Well if one of the value is only 0 or 1 then I believe the following would be the best: if (j == 0) { switch (i) { case 0: ... case 1: ... ... } } else { switch (i) { case 0: ... case 1: ... ... } } Best regards, Lall

Hello Jeb, I'm ~99% sure that the dual switch stuff is not allowed. You could for example put a switch block or "if/else if/.../else" into a case of a switch. Another way is for example to create a 16-bits value "tmp" out of the two 8-bits values "i" and "j" and then to the case stuff on tmp: uint16 tmp; uint8 i, j; tmp = (((uint16)i) << 8) + j; case 0x0100: //-> corresponding to i = 1, j = 0 ... case 0x0201: //-> corresponding to i = 2, j = 1 On an 8-bit processor, it will certainly be cycle and memory consuming so if i and j are in the range of [0 ... 15] then you could even code the combination on one byte by doing only a shift of 4 on i. This would be much better. Actually any combination which would lead to a tmp coded on 8 bits would be better. Best regards, Lall

Hi Jeb, I've never used TK's varian lib so I'm a bit guessing in the dark but when I look at the library files from TK, I can't see any mention of sprintf. I believe that this function is not part of TK's variant which is maybe the root of the problem as the sprintf is actually in this library. The problem is that the library that you must include for MIOS compatiblity does not contain this function so you're a bit stuck. What I'm a bit surprised about though is the error that you get here. It really looks like you've not included stdio.h in which sprintf is defined. At least let's say the error you get is the kind of error that a C compiler should generate in that case. If the function is defined but it cannot find it because it's not in a lib or in a source file then the linker should complain about an "unreference symbol" error as it's most of the time called. Do I understand correctly that you have the same error with the original sdcclib.lib and with TK's one? If so then I would really not understand if it would not be a problem of include files. Best regards, Lall

Hi Jeb, Here's just a bit of explanation of C from the "theoretical" standpoint, maybe you already know that but ok let's give it a try... Normally, it is .h that you should include in your c files, not .c. The header file (.h) contains the definition of the function i.e. its name, parameters, ... The source code file (.c) contains the actual function with its code. When compiled the .c becomes an object file (.obj) and linking all the .obj files together leads to the executable. You can also find libraries (.lib) that put together a collection of object files. It's an easy way to add several files in one shot. Usually, functions like printf are grouped in a library stdlib.lib and the definitions are contained in some common headers like stdio.h, stdlib.h, ... The header files must be included in your code and the lib files added to your project/link_script/... so that the linker can find them. Note that this was about C in general, you should of course follow the advice of audiocommander for the current error you have. Best regards, Lall

Hello, I think that this way of intializing arrays is only valid when it's used while defining the variable. I don't think it's allowed to be used as this in the body of a function. You could indeed use a pointer instead, have a collection of the constant tables as you shown and have the pointer to point on one of the constant tables. Othewise, you can also define constant tables and use a memcpy like function to copy the constant table within your array. Best regards, Lall

I've seen a friend of mine using that kind of hardware to solder such components and he used to call it in french to solder "à la cuillère" but I'm not sure it's the real "technical term". That technique is working amazingly well, when I saw him do it I thought it would be full of shortcuts everywhere but no everything goes in place naturally and solder nicely... Best regards, Lall

Hi Cimo, Very nice demo, I'm curious to see it integrated in its final guitar. That seems to be really a pretty handy solution to change effect and sound on the fly. Stryd, I guess you've missed the following topic http://www.midibox.org/forum/index.php?topic=8679.15. In this thread, Cimo gave a link to his website (http://www.io-sound.org/Guitars/guitars.html) where he shows the incredible things he does to his guitars. Best regards, Lall

Yeap and on top of that the SEQ and FM user interfaces have similarities but are also quite different. FM has a LED/button matrix while SED does not. LEDs in the SEQ and FM are not used for the same purposes. ... All in all, I think that by merging both you would end up with a very strange beast that would most probably be contra-intuitive. Most probably the double function buttons/Leds/encoders would also lead to a pretty messy marking on the front panel. What could potentially be done but I don't know if it would give any gain on the total budget is litteraly to put the two SEQ and FM in one and only box but a bigger one then. You could then maybe reduce a bit on the price of the box, have only one power supply, reduce the number of MIDI connectors by doing internal cabling but on the other hand you would loose in flexibility for a gain that may not be really significant... Best regards, Lall

Salut Pilo, A un moment, on se demandait si on allait pas faire de kit effectivement ou/et alors carrement fournir l'appareil complet mais finalement par faute de temps, on a jamais sauté le pas. A+ Lall

Hello Goule, Lately a velocity converter has been discussed and developped in this thread: http://www.midibox.org/forum/index.php?topic=8585.0 I believe that making preset mappings should be kind of similar in its philosophy to mapping velocities. Maybe you can get inspiration from that code... Best regards, Lall

Hey, My wonderful, super high-tech, veeeery expensive-cased first SID in a shoebox is there too ;D Best regards, Lall