TK.

Hi Wilba, like already mentioned somewhere else in the forum, the AOUT circuit is stable, I will maybe add some caps (although they are not really required, but just to improve the quality), and I will add an additional port to the upcoming AOUT_MUX module before starting with the layout (AOUT_MUX won't be supported by MIDIbox SID!) > How do you get the +12v/-12v supply? I'm using the same one like for the LFOs: http://www.ucapps.de/midibox_ext/lfo/lfo_powersupply.pdf I guess it makes no sense to use a voltage converter for the negative voltage, you definitely want to have stable (and not pumping) signals Best Regards, Thorsten.

Hi *, Due to requests I've decided to release an alpha version of MIDIbox SID V1.6, which is now available in the download section in parallel to the old (and stable) V1.5c. See http://www.ucapps.de/midibox_sid_changelog.html The final v1.6 will be released in some weeks or months... Please report bugs here! Best Regards, Thorsten.

Hallo, sieht doch gut aus! Am Master musst Du nichts aendern, fuer den ersten Slave DEVICE_DEFAULT_ID auf 0x01 setzen und CS_ENABLED auf 0. Nach dem Start noch den Link aktivieren (den entsprechenden Button druecken), und schon kannst Du auf dem Slave ein paar Noten spielen. Gruss, Thorsten.

Not really, now you know that the problem must be located somewhere around IC8. Sorry, I cannot give you much more suggestions anymore... but I hope that you've learned from this session how to detect shorts in a circuit when visual control doesn't help anymore Best Regards, Thorsten.

Hi Wilba, you are absolutely correct - I've fixed this in the posting above Best Regards, Thorsten.

Thats simple: now cut the track near by IC8, Pin 12/13 (so that is has no connecection to the rest of the PCB blabla), and solder a cable from the TxD0 pin directly to those pins - results? Best Regards, Thorsten.

So, there is no connection between the TxD0 pin and the first MIDI Out anymore (see question (1)), but it sends MIDI Data? In this case I will give you some new instructions ;-) Best Regards, Thorsten.

Ok, once again, step by step, please answer every question: 1) cut the track near by the TxD0 pin of the Cypress chip, so that this output hasn't a connection to the rest of the PCB anymore, ok? 2) cut the track near by the RxD0 pin of the Cypress chip, so that this input hasn't a connection to the rest of the PCB anymore, ok? 3) cut the track near by the optocoupler output of the first MIDI In port (IC4, Pin 6), so that this output hasn't a connection to the rest of the PCB, ok? 4) now connect an external 1.2k resistor to pin 6 of IC4, ok? 5) solder a wire between IC4, pin 6 and the RxD0 input of the Cypress chip. Note: a direct connection, not via any PCB track! Does the MIDI In receive proper MIDI events now? 6) if not: connect the RxD0 pin with IC5, pin 6 instead and send some events to MIDI Port 2, does MIDI-Ox display proper events? Best Regards, Thorsten. P.S.: connection to 3.3V was just a test to ensure that the RxD0 pin is not floating. With 3.3V you should receive *no* MIDI event

...and you are receiving also invalid MIDI events when the Rx line is connected with 3.3V or with the output of the second optocoupler? This would mean that your wire is not soldered correctly... Best Regards, Thorsten.

...means you are receiving any (but invalid) MIDI events in MIDI-Ox from the first MIDI In port? What is the exact status now? (I'm also confused ;-) ) Best Regards, Thorsten.

Great! :) Did you create the PCBs by yourself? I just noticed that the .gif contains the wrong snapshot, but the layout data in .brd is correct once you enter the "ratsnest" command - I will fix this. Best Regards, Thorsten.

Hi, so long as the MIOS ID of the slaves is different from the MIOS ID of the master core, you can program the chips through the master (MB Link has to be enabled). Note that this requires also a different "-device_id" when using the hex2syx.pl script. The SID slave IDs have to be different anyhow. Best Regards, Thorsten.

Hi Chriss, You've to start jsynth with "java JSynthLib" from the command shell. The .jar file doesn't contain the MBSID driver. MIDI related issues: the developers of jsynth have prepared a new release v0.18 which provides proper MIDI drivers based on the new MIDI engine of Java v1.4.2 Unfortunately it hasn't been released yet, so you have to download the sources from the CVS view and compile it by yourself (requires Java JDK): http://sourceforge.net/cvs/?group_id=41208 The CVS package already contains the MIDIbox SID driver (will be part of v0.18 ) Best Regards, Thorsten. Btw.: great to hear that MBHP_USB is running under Mac OSX! :-)

You are doing this to ensure that there is no "invisible" short between the Tx and Rx track. Some days ago a user sent me his core module since he assumed a mysterious problem with the PIC (it went into reset during programming via MIDI). It turned out that there was an invisible, parasitic resistance (maybe flux) between the MCLR# pin and ground which caused the reset once the power consumption was too high during programming. Such errors can only be detected by cutting tracks and bypassing the connections. Based on your descriptions I expect a similar problem Best Regards, Thorsten.

ok, so add an external resistor. Alternatively you could connect the Rx pin directly with the output of the second (working) optocoupler, just to check if the receiver works Best Regards, Thorsten.

P.S.: the 1.2k pull-up resistor between the optocoupler output and +5V is still required Best Regards, Thorsten.

So, now do the same with the Rx track, but cut it near by the Cypress chip and near by the optocoupler. Use a cable to connect the optocoupler directly with the chip - results? Best Regards, Thorsten.

alright, and what does happen when you rip up the track to TxD0 (pin #15) very near by the Cypress chip? This is just a simple test to ensure that there isn't a short between Rx and Tx, later you can patch this connection with a short piece of cable Best Regards, Thorsten.

Well done, Smash! :-) Now the users are able to publish and maintain their own content, this is a big step into the direction of a "self-governing" community. I noticed the same problem like PayC, the link to the new portal site via http://www.midibox.org doesn't work, it leads to the old portal instead. Best Regards, Thorsten.

Hi Dan, do you see two Audio devices in MIDI-Ox or only one? How did you connect your core module to the MBHP_USB? via MIDIbox Link or via optocouplers? Best Regards, Thorsten.

Your Chip is working and it's normal that the vendor request hangs up when the vend_ax.hex firmware is not loaded. Once the MBHP_USB firmware is running, the control panel will report, that no Cypress device is detected... so it seems that the firmware is not loaded from EEPROM during power-on. I guess that there is a problem between the EEPROM and the cypress chip, could you please measure the voltages at pin 1 & 8 (-> 3.3V against Vss) and 2, 3, 4, 7 (-> -3.3V against Vdd) first? The voltages at Pin 5 & 6 should also be 3.3V against Vss (the EEPROM will only be accessed during the first miliseconds after reset) See also: http://www.ucapps.de/mbhp/mbhp_usb.pdf Best Regards, Thorsten.

Es koennte sein, dass der Trackball keine sauberen digitale Signale liefert. Du muesstest also nochmal einen Schmitt Trigger zwischenschalten, bspw. 4093 Siehe auch: http://www.doctronics.co.uk/chuckles.htm Gruss, Thorsten.

I've now uploaded a new package version of MBHP_USB which contains a .syx file with the V1.1 firmware Just follow the instructions which are given in the README.txt http://www.ucapps.de/mbhp/mbhp_usb_v1_1b.zip Best Regards, Thorsten.

I don't know the ELV programmer, if it can ready .hex, then use the .hex file, if it allows to upload a binary, then use the .iic file However, I've now uploaded a new package version of MBHP_USB which contains a .syx file with the V1.1 firmware Just follow the instructions which are given in the README.txt http://www.ucapps.de/mbhp/mbhp_usb_v1_1b.zip Best Regards, Thorsten.

Hi Doc, very interesting. Yes, you can burn the EEPROM with any programmer, it could also be programmed via a MIOS core like a BankStick (which would solve D2k's problem), but for this I've to prepare a special .syx file Best Regards, Thorsten.