ilmenator

Hi KJH, you may try using a different PSU with lower output voltage, like 9Volts. If that's not an option you could place another regulator in row, like 7809 --> 7805. But there is not really much space on the core board, so you might use a separate vector board with all the components of the power regulating part of the core. Thinking about it again, it might actually be far more elegant plain using a different PSU... :-/ Regards, ilmenator

I'd like to jump in here... They are not the same - I once tried to use the 6mm caps with a 1/4" shaft. Not a chance... But you might be able to fix them using some kind of glue - though that might be a decision for life ;) Regards, ilmenator

As far as I get it, it should not be okay. One line is 5V, the other is 9V. You could surely damage the PIC when applying 9V directly to it - unless you have a 7805 voltage regulator on each core coard. Regards, ilmenator

From the pictures I've seen of the MBSID (http://www.ucapps.de/midibox_sid/midibox_sid_cs2.jpg) I think that TK used the original C64 switch, which then should be a "double" switch - one mechanical switch interrupting two separated "power" lines. ilmenator

You could choose the 512, which also works. Or you go for the SMD version of the 256, which is a bit tricky to solder but fits nicely for an external bankstick. Take 3 of everything. You can easily fry one of the PICs, then it's good to have a spare part... or you might want more of these MIOS applications ;D ilmenator

Okay, though I find it not very bright to answer my own posting, here goes: The PIC was dead as can be. Luckily I have a spare one (thanks go to Microchip ;) ). I have no idea what it was that I did wrong, but apparently this was the reason behind all my problems. The new PIC is working okay. Regarding the button problem I mentioned earlier: it's not a problem with the button but with the LEDs on DOUT. The problem I was having is that in CS_MENU_DOUT_TABLE in the cs_menu_io_tables file the pins are counted from left to right; the pdf counts from right to left by naming the pins D0...D7. I got confused over that. So if anybody wants to know: Pin# 0 = D7 Pin# 1 = D6 ... Pin# 7 = D0 Thanks again, ilmenator

It looks like I fried the PIC or something :( In fact, I reburned the bootstrap loader but the symptoms are just the same. Now I think it's time to get out the multimeter again... Best regards, ilmenator

Thanks Thorsten! Actually, the only modifications I did to the application was that I changed the DIN ports for some of the buttons in cs_menu_io_tables. There still seems to be some problem with one of the buttons, but this is something I will have to dig a bit deeper tonight. Then I commented out all of the encoder definitions in mios_tables, as I have only one encoder connected. For that one I changed the encoder mode to MIOS_ENC_MODE_DETENTED, because ...DETENTED2 did not work properly with my encoder. That's about it... I guess that CS_ENABLED 1 in main.asm is correct as long as there is some buttons and encoders connected to the PIC, right? This thread is probably more and more likely to be moving into the MIOS Programming area :) Best regards, ilmenator

Hi all, yesterday night I finally got my MBSID working. After tweaking around a bit with the menus and on-board control (I have a 2x40 LCD, 10 buttons beneath and one encoder apart from Menu, Edit, CC and Link buttons) I tried JSynth. After sending some sysex message to the PIC it suddenly kind of died. When I switch it on, I just see the upper row of the LCD completely black, the lower row not displaying anything. I cannot upload any app via sysex anymore, I just get the regular (each sec or so) sysex string from the PIC. Nothing else. Tonight I will try to reburn the bootstrap loader into the PIC, I hope that the PIC itself hasn't died. But I'm curious: is it possible at all that I destroyed the part of memory where the bootstrap loader is located by sending weird sysex messages via MIDI ??? Best regards, ilmenator

Thorsten, I think that this was the reason, I have been uploading a number of applications, and I have always gotten a "Rebooting MIOS" message now. I am a bit relieved that there is nothing wrong with my hardware :) Regards, ilmenator

Fantastic! I hope there is still some space left on the PIC for that portion of code!! ;) Best, ilmenator

Hey Thorsten, I didn't mean to ask for you to implement this ;) - I just thought that there might be an easy way to achieve this, but apparently there is none. I will look into the code and then decide whether it's possible for me or not. Anyway, I did not think of memory limitations, so this might be a serious "contra" for me as well. Thanks, ilmenator

Boy, what a professionally looking case! :o Congratulations!!! ilmenator

Great! Though this surely would not be limited to J5, any DOUT should do, right (regarding the necessary routines)?? Best, ilmenator

Hi all, I am building an MBSID with the basic control surface, but I have a 2x40 character display connected to the first core. I know that I can display more menu entries at once (10 instead of 5), but I would like to exchange that feature for longer strings (like "play" instead of "ply", "jump" instead of "jmp", "legato" instead of "leg" - you get the picture). So basically I would stick to the 5 buttons under the display, but have longer strings displayed. I guess that I would have to change the cs_menu_print.inc file for the strings that are displayed, but is there any easy way to tell MIOS that menu entries in general should have a length of 8 instead of 4 characters? Something like an "offset" value to tell MIOS where to place the next string? I hope I made myself clear. Thanks for any ideas, ilmenator

Hi all, here http://www.ucapps.de/midibox_sid_cs/2x20_enc_multi_w_j5.pdf a spare LED connection on J5 of the core module for the MBSID "basic setup" is mentioned. Would it be possible to use it as a MIDI in indicator? What would have to be done software-wise to allow this? Thanks, ilmenator

I will do so as soon as possible - will probably take until tomorrow night, though. Thanks, ilmenator

I see. So kind of the opposite problem to mine - the system does not reboot after receiving a new app via sysex. Well, it's not so bad because the basic functionality is there - it's just that I have to switch off and on again to have the new app up and running. Still, I guess it's a minor problem :) Regards, ilmenator

Hi Thorsten, I think that the problem is solved :D I have a stable "ENC_example_x" application as long as MIDI data received from the PIC isn't sent back to it. Apparently, the fact that the core does not reboot itself after receiving a new app via sysex does not have to do anything with the problems I had! Still I'm a bit worried, since most people seem to get this message... I see why there is no feedback detection. As I will be using the MIDI link feature in the future, I should have thought about that :-/ Well, nobody's perfect :P Thanks guys, I guess this topic can be closed now :) Regards, ilmenator

It apparently is a MIDI feedback problem. I'm kind of astonished, as I would think that the PIC should be able to handle incoming MIDI data, even if it's the same as the one it sends itself. Is this due to the fact that there is only limited functionality in the test applications (enc_example...)? I should think so. Thanks again, ilmenator

Did some more testing. Problem seems to have something to do with MIDI In :o As long as no MIDI-Ox is connected, everything runs smooth. When the PC running MIDI-Ox is running (so I can upload different apps), then the strange behaviour described above starts to show... I wonder if this has something to do with the LCD resistor that Sephult describes?? What exactly did you do there? Best, ilmenator

Hi all, It does, so there's no problem with ground. The problem now does not only happen with the last encoder. More testing showed that it might happen on any encoder. Interestingly, when I first switched on the core today, I was not able to reproduce the error. Only after uploading an application the error ocurred again. (I was switching between enc_test 2 and enc_test 3). I still get a "Reboot MIOS" message only sporadically, say like in 5-10% of the uploads. In the last few hours I had no such message at all. I suspect that this might be one of the points to dig deeper... All the bridges are there (though I only count 14 on Thorsten's board), all the resistors are there. The power supply is stable, and the 7805 doesn't get hot at all. Thanks, ilmenator

Hi all, after resolving the first problem with my encoders connected via DIN board, I seem to be running into the second one. Here's the story: I connected 4 encoders to the first shift register - everything was working fine. What a surprise ;) Then I decided I wanted to have a fifth encoder which I connected to pin 0 of the second shift register. Now if I turn the encoder, "enc_example_3_v1_3" sometimes gives me feedback, sometimes the app just hangs. Then I have to reboot the PIC by switching off/on. Interestingly, the app only starts to hang if I turn this encoder... I did connect ground to the corresponding pin on the first shift register only, on the encoder board all grounds are connected together. I think that there is a ground connection on the DIN board already, so that the second shift register is grounded and should work - though I am not sure about this. Anybody who is better in interpreting the schematic of the DIN board?? Thanks, ilmenator

Thorsten, you are my HERO! Your analysis was so right - pin 22 of the PIC wasn't connected to SC on J4 but to SD. Therefore I did not have any SC signal on J9 either. Excellent! ;D I feel a bit like a goof, though; actually all of my core boards did have that mistake, because the first boards were built for the MIDI filter project without any DIN or DOUT, and the error slipped through unnoticed. The other boards were just "copied" from those first. Thanks again to Thorsten and Sephult - long live the spirit of this forum ;D ;D ;D ilmenator

Bei Reichelt z.B. ist die Mehrwertsteuer auch schon drin. Da liegt der PIC irgendwo bei 12 Euro, wenn ich mich recht erinnere... ilmenator