TK.

Does it work better when you burn the code without "verify during programming"? I've heard that this flag doesn't work properly with a PIC16F877A (maybe due to an IC-Prog bug...) Another reason could be that you have to reconfigure your COM port for a lower baud rate (don't ask why, a user reported that IC-Prog was working after this change) Best Regards, Thorsten.

Well, this shows again that visual control of connections sometimes doesn't really help. I guess that it was a bad junction which caused the trouble, and the fastest method to fix it is just to add some solder w/o checking if it is necessary or not. Who knows, maybe another reason was that you never uploaded the complete OS... Fine that this issue finally has been fixed. :) Best Regards, Thorsten.

Hi Steve, thanks a lot for this useful list! I've set the "sticky" flag so that it will stay on the top of this board. In future please post JDM issues here! Best Regards, Thorsten.

The push buttons are also very usefull if you want to visualize the value which is assigned to the knob without changing the value. Maybe I will build such a function into the MBSID application (although I'm using encoders without integrated knobs) because it improves the handling. Currently you have to change the layer to achieve this. Another usecase is already support by this application: you can add 5 rotary encoders to StepA if you want to change the values which are currently visible in the menu (StepC users: change to the Assign layer in the ENV section). Integrated knobs would save 5 menu buttons Best Regards, Thorsten.

Hallo, meine Meinung zum Thema "MBHP_PSU" (oder man es auch nennen mag), findest Du hier: http://www.midibox.org/cgi-bin/yabb/YaBB.cgi?board=german;action=display;num=1045851749;start=2#2 Mit hohen Spannungen ist nicht zu spassen - selbst E-Technik Studenten laesst man nicht ohne Beaufsichtigung an der Netzspannung werkeln, und das aus gutem Grund. Gruss, Thorsten.

Hi John, I plan to upload the source code of MIOS to sourceforge.net in some months when I feel pleased with the implementation. However, the seperate MIDI merger project is a standalone device. It uses a second, software-implemented UART input which relies on a minimum interrupt latency and consumes a lot of CPU power, therefore it doesn't make sense to integrate a similar function into MIOS (the OS wouldn't be useable to handle any other task if the realtime behaviour of the UART has to be ensured). The MIOS merger is similar to the routine which can be found in the MIDIfilter/processor project (both sources are available) Yes, the MIDI interface will be initialized during startup (in fact: also by the first level bootstrap loader). The MIDI In/Out is buffered and interrupt driven in order to reduce the system load. To integrate a user driver for the UART, a seperate IRQ hook would be required. But: so far as I remember DMX needs some RAM, since MIDI messages are repeated perodically. This would mean that huge applications and the DMX driver couldn't run in parallel due to memory conflicts. From my point of view it would make sense to implement a seperate DMX module (which fits with the MBHP :)) and works with a cheap PIC like the 16F628. In this case everything would be in your hands, and the module could also be used with other MIDI controllers. Best Regards, Thorsten.

;-) For the case that you would take a look into the current implementation: a snapshot can be found here: http://www.ucapps.de/tmp/mb64seq_snapshot.zip The seq_core is functional and bugfree, only some minor features are not available yet, and especially the user interface has to be completed. But for your sequencer you need to change the cs_* anyhow, so the current state is a better starting point (it will get more complex in the future) I haven't continued on this code since a month (biggest blocking point: the intensive heatwave here in Europe, last week we had a new temperature record in germany with more than 40 °C :P - under these conditions programming doesn't make fun ;-) Best Regards, Thorsten.

First the good news: the AIN driver is working correctly. You changed the setting from "muxed" to "unmuxed", but you are using 4051 multiplexers, thats the reason for the strange behaviour of the application. In your hardware setup, only the number of pots should be changed, the multiplexers should stay enabled (MIOS_AIN_Muxed) To the LCD: still unexplainable behaviour. Since you are now able to upload code, maybe following simple test helps you to verify the bus connections to the LCD module. Example: With bsf LATB, 0 you can set Pin RB0 to logic-1 (==5V) with bcf LATB, 0 you can set it to logic-0 (==0V) The addresses of all LCD pins: RB0 (-> LCD D0) LATB, 0 RB1 (-> LCD D1) LATB, 1 RB2 (-> LCD D2) LATB, 2 RB3 (-> LCD D3) LATB, 3 RB4 (-> LCD D4) LATB, 4 RB5 (-> LCD D5) LATB, 5 RB6 (-> LCD D6) LATB, 6 RB7 (-> LCD D7) LATB, 7 RD5 (-> LCD RS) LATD, 5 RD6 (-> LCD RW) LATD, 6 RD7 (-> LCD E) LATD, 7 How to test all the pins easily without a scope: Add following code below the USER_Init lable USER_Init Endless_Loop clrwdt ; feed the watchdog bsf LATB, 0 ; RB0 = 5V movlw 250 ; wait for 250 ms call MIOS_Delay bcf LATB, 0 ; RB0 = 0V clrwdt ; feed the watchdog bsf LATB, 1 ; RB1 = 5V movlw 250 ; wait for 250 ms call MIOS_Delay bcf LATB, 1 ; RB1 = 0V clrwdt ; feed the watchdog bsf LATB, 2 ; RB2 = 5V movlw 250 ; wait for 250 ms call MIOS_Delay bcf LATB, 2 ; RB2 = 0V clrwdt ; feed the watchdog bsf LATB, 3 ; RB3 = 5V movlw 250 ; wait for 250 ms call MIOS_Delay bcf LATB, 3 ; RB3 = 0V clrwdt ; feed the watchdog bsf LATB, 4 ; RB4 = 5V movlw 250 ; wait for 250 ms call MIOS_Delay bcf LATB, 4 ; RB4 = 0V clrwdt ; feed the watchdog bsf LATB, 5 ; RB5 = 5V movlw 250 ; wait for 250 ms call MIOS_Delay bcf LATB, 5 ; RB5 = 0V clrwdt ; feed the watchdog bsf LATB, 6 ; RB6 = 5V movlw 250 ; wait for 250 ms call MIOS_Delay bcf LATB, 6 ; RB6 = 0V clrwdt ; feed the watchdog bsf LATB, 7 ; RB7 = 5V movlw 250 ; wait for 250 ms call MIOS_Delay bcf LATB, 7 ; RB7 = 0V clrwdt ; feed the watchdog bsf LATD, 5 ; RD5 = 5V movlw 250 ; wait for 250 ms call MIOS_Delay bcf LATD, 5 ; RD5 = 0V clrwdt ; feed the watchdog setf TRISB ; IMPORTANT: for the RW pin PORTB has to be tristated to avoid a short bsf LATD, 6 ; RD6 = 5V movlw 250 ; wait for 250 ms call MIOS_Delay bcf LATD, 6 ; RD6 = 0V clrf TRISB ; enable output drivers again clrwdt ; feed the watchdog bsf LATD, 7 ; RD7 = 5V movlw 250 ; wait for 250 ms call MIOS_Delay bcf LATD, 7 ; RD7 = 0V rgoto Endless_Loop This will toggle all pins in an endless loop. The delay of 250 mS is high enough to visualize the pin status with a LED+resistor directly at the PIC and (more interesting) at the LCD. (Note1: the maximum value of MIOS_Delay is 255, if you want to wait for a longer time, use MIOS_Delay multiple times) (Note2: the clrwdt instruction ensures that the PIC will not be reset due to a watchdog timeout which happens when this instruction hasn't been executed in between 2-3 seconds) (Note3: it's important to disable/enable the bus driver of Port B when changing the RW pin) (Note4: don't forget the space or tab character before every instruction. Only the labels like Endless_Loop should begin at the first column) (Note5: this code is untested) If all pins are ok, you could have mixed the connections. In this case try the same loop with a single pin only Best Regards, Thorsten.

The LC7940 is only a dot driver, but no LCD controller. This means that it isn't usable for MIOS (unless somebody would implement an interface based on a second uC which makes the LCD compatible to KS0108 ) Best Regards, Thorsten.

Hi Richard, thanks a lot for the input! Could it be possible to re-use such rubber membranes which can also be found in common (ASCII) keyboards, or are those membranes used for musical instruments special constructions which provide a higher resistance range (as function of the pressure)? Best Regards, Thorsten.

Alright, "F0 00 00 7E 40 00 0F 00 02 F7" (especially the 02) means that the LCD has been initialized and that the PIC is able to communicate with the HD44780 (reads/writes over the 8-bit bus are working). The contrast is ok. It's totally unclear to me why you don't see any character on the screen. Sorry, but this case never happened before (in the last 4 years...) - I don't have an answer :-/ Best Regards, Thorsten.

Are you sure that MIOS returned exactly the same SysEx string? I don't think so... the MIDI-Ox monitor displays the output and input string, possibly you mixed them up? Or did you receive nothing? Check the MIDI Devices setup: MIDI In/Out has to be highlighted, in the port mapping you have to ensure that the input isn't mapped to the output You are writing the you get a black line on initialization. This means that you don't have the same problem like Seb (your contrast pot is ok and you don't need a negative voltage). Some time ago you wrote that the black line vanishes after 2 seconds. This is an important hint - is this still the case or not? Best Regards, Thorsten.

It seems that your PSU has some kind of thermal fuse which don't need to be exchanged - fine! :) Best Regards, Thorsten.

I don't see a problem, you only have to store the events in the BankStick. The data structure should be defined in a way which simplifies the addressing of several "patches". Most easy solution would be to reserve 256 bytes for every patch, makes 128 patches per BankStick. The data could either be downloaded via MIDI with a tool like JSynth, it could be recorded with a MIDI learn function, or it could be entered via a user interface. All three methods require some knowledge about MIDI events and MIOS itself of course. The programming effort should be about 2-3 months... Best Regards, Thorsten.

1: The MIDIbox SID firmware already comes with a 3 track 32 step sequencer with very powerfull functions (especially the combination between this sequencer and the arpeggiator makes a lot of fun). You have to modify the source code if you want to have another user interface like dedicated buttons for the sequencer, more LEDs or whatever 2: the MIOS based MB64SEQ is nearly finished, you can try to combine the applications after the release if you want To both questions: due to lack of sparetime I'm currently not able to give explicit programming hints, this is your job Best Regards, Thorsten.

A perfect style to add some additional MB64SEQ :) Best Regards, Thorsten.

For myself the "USB chapter" is finished... regarding the philips chip: see http://www.findchips.com --- the availability is nearly zero, so: wasted effort... Best Regards, Thorsten.

Maybe there is somebody of the experiences programmers who want to write an example? Sephult, how about you? :) Best Regards, Thorsten.

The socket for the fuse can be found at the backside: Switch: no I don't have a picture, but a switch is a switch is a switch... Best Regards, Thorsten.

Hi Dan, Pictures wouldn't really help, because I guess that you just have blown the fuse during the tinkering work. This can happen from time to time if you don't take care for short circuits before powering the unit. Some hints: exchange the fuse. Don't do it without - if you don't have a replacement yet, just buy it anywhere (DIY market or wherever), they are cheap and save the PSU from damage find out the 5VDC and 9VAC pins by using a multimeter. connect the 5VDC output directly with the core modules. Connect also the power LED like shown in the schematic. Check if the core module is working before you go on build the 9V regulator circuit and connect it like shown in the schematic at last you can try to integrate the switch. The correct contacts can be measured with a multimeter - it's a double-pole-toggle-switch (nice word ;-)) with 2*3 pins, but you only need 2*2 of them: the middle and one outer pin of each pole. Ensure that one pole doesn't get in contact with the other pole, although you will definitely get a short Best Regards, Thorsten.

Does this problem also occur after some time when the DIN chain is disconnected from your MIDIbox? In this case I would say that there are bad solderings in the encoder/button section. Best Regards, Thorsten.

MIDIbox16E: nothing by default, but you've the possibility to add anything you want by enhancing the source code (programming skills required). Best Regards, Thorsten.

Following demo is a remix of "Auf Wiedersehen Monty", one of the most famous C64 tunes of the 80s, composed by Rob Hubbard and Ben Daglish. It was the final test I made for firmware v1.5b ;-) http://www.midibox.org/midibox_sid/Auf_Wiedersehen_Monty_(MIDIbox_SID_Remix).mp3 All sounds of this remix except for the drums are made with MIDIbox SID, recorded via overdubbing, enriched with internal effects of Logic Audio: Fat EQ, Stereo Delay, Stereo Spread, Compressor, Limiter, Phaser (for the Strings in Background), , Bitrusher+Autofilter as AddOn to the internal SID filter for the TB303 like sound. Have fun! :) Best Regards, Thorsten.

They are soldered to the copper pads on the opposite side: Best Regards, Thorsten.

Alright, this explains everything :) Your BankStick has not been formatted yet, the firmware tries to do this - a "beep" can be heared after every formatted patch, so you have to wait for 128 "beeps" until the BankStick is ready for use. It takes about 3 minutes. During the formatting procedure all other SID functions are disabled. When you interrupt the formatting (by removing the BankStick or Power-Off), the firmware will try it again so long until it has been completed. Best Regards, Thorsten.