TK.

?? IO???????? ????????? ;) Gruss, Thorsten.

And if it doesn't work, solder a 220 Ohm resistor in parallel 33 || 220 -> ca. 28.5 Ohm Best Regards, Thorsten.

Yes, the EEPROM allows you to assign a different vendor/product ID (VID/PID) + vendor/product names to the device, but unfortunately there is a bug which prevents you from declaring more than 3 IO ports once EEPROM is selected to fetch the descriptors (J1/J2/J3 open) Details are described in the mbhp_usb_gm5_eeprom application, which can be used to program the EEPROM via MBHP_CORE module. In addition, the GM5 driver allows you to define different IO port names. If different port names should be assigned to different interfaces, you have to use EEPROMs to assign different VID/PIDs, so that Windows is able to differ between the devices I already requested this to Ploytec Currently IO port names are not stored in EEPROM, but this could be possible in future. Instead, port names have to be defined in a .ini file, which can be edited with a common text editor. I used the port routing window of MIDI-Ox to demonstrate the possibilities (and the advantage when using IO port names). Probably no other commercial MIDI interface allows you to do change the port names yet - although it is so desirable :) Best Regards, Thorsten.

Gruss, Thorsten.

Teaser for the upcoming GM5 Windows driver (note that the 5 IO ports can be named)

I added some infos about a Windows workaround for affected MIDI interfaces: http://www.ucapps.de/midibox_sid_manual_ed.html (press the reload button of your browser if you don't find the new text) Basically it is recommented to use Miditrix instead of MIDI-Ox to forward events, because this tool defragments the MIDI stream before it will be sent to the physical port. This is doing the trick. Miditrix also allows you to forward multiple MIDI streams, e.g. the one of your MIDI keyboard or sequencer, to the MIDI Out port. Vedge: this solution is more performant than forwarding inside Java! Best Regards, Thorsten.

Yes, it's correct for PIC18F452 and PIC18F4620, but not for PIC18F4685, where 0x60..0x7f and 0xd00..0xf7f are reserved for the ECAN peripheral. Under http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fetc%2Flkr%2F you will find linker scripts which contain a complete list of available memory locations These scripts are automatically selected by the Makefile mechaisms when compiling C programs. Best Regards, Thorsten.

Yes, it could be used. Alternatively, just use MIOS_SRIO_NumberSet(0) to disable SRIO accesses, and set it back to the original value to allow SRIO accesses again Best Regards, Thorsten.

Fine :) Btw: today I sent the remaining paid orders (meanwhile I'm able to prepare ca. 20 mailers per hour ;)) 10 Orders haven't been paid yet, the guys got a reminder; deadline is next monday. Some of you may have noticed, that the postage was lower than expected. The reason is simply, that the weight of some envelopes was lower than 100g. And sometimes the post office lady was so tired of checking the weight, that I got an unexpected discount ;) And another note: at one day it wasn't possible to get the requested injurance, since I sent the mailers from a smaller post office close to where I'm living. What I've also learned: PayPal fee is sometimes higher than expected - and I had to pay it. It's different for national/international payments. However, the saved postage compensated the loss. Here some hints based on my experiences I made in the last days. They could be useful if somebody is planning similar bulk orders in future. By asking the people to send emails with a special syntax in the subject, you can use your email program to trackback orders, money requests, payments and special requests. Also the communication channel is ensured (testing the email filters) Avoid Paypal if possible (e.g. on national money transfers), it saves money. Note that you have to pay the transfer fee! if Paypal is prefered: request the email address registered at Paypal don't provide different tracking/injurance options, this can drive a post office agent crazy... and the people who are waiting in the queue behind you ;) track the orders in a spreadsheet. Use different colours for "order confirmed", "money received", "mailer sent out". By creating cell-references in a second spreadsheet, you can print out the mailer addresses without much effort: However, all these measures saved a lot of time, but they don't completely guarantee that I put the correct quantity of chips and PCBs into the mailer. So, please inform me immediately if you expected more or less parts (my spreadsheet tells me, that the outgoing quantities are still correct) Best Regards, Thorsten.

Yes, so long this is a one-time auction, and nothing is prebuilt, it should be ok. Although I fear that this could quickly escalate once somebody offers prestuffed modules, or a halfbuilt MIDIbox - and at the end complete MIDIboxes :-/ To everbody: please ask me for permission when selling parts of the MBHP, I'm the copyright holder for most of the hardware and software. Selling via forum is prefered, don't send the wrong sign to people who quickly feel animated to make profit by selling even more modules via ebay. And please note, that we can request ebay to remove auctions thanks to the VeRO program Best Regards, Thorsten.

It was too late for the first order, but you will get the chance to buy some of the remaining, unpaid chips at 25-08-2008, 8 p.m. CET (see http://www.midibox.org/forum/index.php/topic,11387.msg97347.html#msg97347) I will start a second order once we reach 250 (or 500) pieces again Best Regards, Thorsten.

ok, fixed The driver is still not available for public, but it won't take so long anymore :) Best Regards, Thorsten.

Thanks - fixed Best Regards, Thorsten.

This seems to be a copy&paste error, in this variant: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fapps%2Fexamples%2Fsm_c_example2%2Fsm_fast.asm the debounce counters are cleared instead I think, that the second loop can be savely removed - could you please doublecheck this? I could give you write access to the repository, so that your additional comments won't get lost Best Regards, Thorsten.

The workaround for "dash" (which is used as default shell instead of bash) are already in the repository There is a new environment variable which has to be set by Ubuntu users: export MIOS_SHELL=/bin/bash For the case that you haven't downloaded the repository yet, just type: svn co svn://svnmios.midibox.org/mios Best Regards, Thorsten. P.S.: the applications will be re-released once the modifications has been tested well enough on different operating systems.

Great!!! :) I documented this requirement in the README Best Regards, Thorsten.

Im Prinzip sind die Ideen nicht schlecht, doch es mangel wie so oft an verfuegbaren Speicher. Im Bootloader-Bereich sind bspw. nur noch 22 bytes frei, da passen also nur noch 11 Assembler Befehle rein. Das reicht nicht. Deshalb muss man sich damit zufrieden geben, fuer einen Funktionstest eine LED an den MIDI Tx Pin anzuschliessen. Damit werden zwar nicht alle Fehlerfaelle abgedeckt, doch die LED sendet immerhin ein "Sign of Life" IMHO reichen zwei Tests aus, um die Funktion des Cores in wenigen Sekunden festzustellen: TEST_OUT1 und TEST_INOUT1 - wenn die nicht funktionieren, beginnt die Fehlersuche - und hierbei wuerde ein erweiterter Bootloader nicht weiterhelfen. Stattdessen muss man nach wie vor die bereits dokumentierten Testreihe durcharbeiten. Gruss, Thorsten.

Thanks, this was helpful. :) The corrupted part of the file neither contains the original content, nor it contains the intended values. Instead, all the upper sectors contain the same pattern: 00004000: f8ff ffff 0300 ffff 0500 ffff 0700 ffff ................ 00004010: 0900 ffff 0b00 ffff 0d00 ffff 0f00 ffff ................ 00004020: 1100 ffff 1300 ffff 1500 ffff 1700 ffff ................ 00004030: 1900 ffff 1b00 ffff 1d00 ffff 1f00 ffff ................ 00004040: 2100 ffff 2300 ffff 2500 ffff 2700 ffff !...#...%...'... 00004050: 2900 ffff 2b00 ffff 2d00 ffff 2f00 ffff )...+...-.../... 00004060: 3100 ffff 3300 ffff 0000 0000 0000 0000 1...3........... 00004070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004080: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004090: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000040a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000040b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000040c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000040d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000040e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000040f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004100: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004110: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004120: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004130: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004140: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004150: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004160: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004170: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004180: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00004190: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000041a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000041b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000041c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000041d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000041e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000041f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ [/code] Looks like a FAT Oh damned! It [b]is[/b] the FAT! ;-) So, here the solution: use SDCARD_FILE_Seek() before copying the SRAM content into sdcard_buffer_p0/sdcard_buffer_p1, because the seek function overwrites this buffer during FAT readouts This explains all observed effects. Best Regards, Thorsten.

Did you also check your core module? Note the "flying wires" (see http://www.ucapps.de/mbhp/mbhp_core_v3.gif) which are required if you don't use a PCB from Smash Best Regards, Thorsten.

This is due to a known bug in PBrennerNG (I already informed Sprut): unix style files without carriage-return control chars won't be read correctly. Workaround: open the file with wordpad, do a dummy-modification (e.g. insert/delete a space), and store it again. Wordpad will store the file in DOS style Best Regards, Thorsten.

Thank you, I fixed this Best Regards, Thorsten.

Hi, thank you! This was probably the oldest bug ever. It seems that not that much MIDI devices are using the song select message... The bugfix is available in the repository: http://svnmios.midibox.org/filedetails.php?repname=svn.mios&path=%2Ftrunk%2Fmios%2Fmios_isr.inc Best Regards, Thorsten.

MIDIO128 would be better, as ain64_din128_dout128 sends random events when pins at J5 are not grounded. Details: http://www.midibox.org/dokuwiki/din_module Are the buttons working with this application? LEDs connected to J5: there was a bug in the j5_io driver under modules/j5_io - MBSID V1 hasn't been rereleased yet, so that you have to download the new j5_io.inc file from this location Best Regards, Thorsten.

Alright - do you already have a binary file which contains the expected SRAM content? Could you please post it together with the file read from SD-Card? Best Regards, Thorsten.

Yes, we were talking about both methods See detailed description in README.txt Yes You could use an external IIC EEPROM ("BankStick") to store and restore your presets. Up to 128 presets can be stored in a single device. No PC required to replace data. The example shows, how to handle this Best Regards, Thorsten.