TK.

I'm planning to do a service update for MBSID V1.7 with following bug fixes: patch name editor bugfix for 2x16 displays avoid crash on maximum WT rate Proper handling of SusKey (automatic portamento) when Legato is active at the same time Are there any other imperfections which need to be fixed? Best Regards, Thorsten.

Yesterday I found two new bugs in the current firmware: the slide function doesn't work anymore (length > 24), and the sequencer always switches into the song menu when an MIDI Clock Start event is received from external. The bugs are fixed and I will release a new version this weekend (if no other bugs are discovered until then) Best Regards, Thorsten.

thank you! I've added this card to the list Best Regards, Thorsten.

Just use MIOS Studio, it's the most secure way to upload MIOS - something like a "reset" (or a memory cleanup) is not required Best Regards, Thorsten.

Hi, the unimplemented bits in the configuration sector are always zero when reading them back. Just use the verify function of your programming software to check if the flash content is correct Best Regards, Thorsten.

Hi Christoph, does this help? Patching the .hex file If your PIC programmer doesn't allow to edit the ID field, it's also possible to patch the .hex file instead. Just open the .hex file, and search for the line below ":020000040020DA" which begins with :08000000 The following eight bytes (16 digits) are the ID values in hexadecimal format. The last value is the checksum over these 8 bytes (0 - byte1 - byte2 - ... - byte8) Here some examples: Normal ID field (all 8 bytes are zero) - to-COM disabled, MIOS Device ID = 0x00 :080000000000000000000000F8 to-COM disabled, MIOS Device ID = 0x01 :080000000000000000000001F7 to-COM disabled, MIOS Device ID = 0x02 :080000000000000000000002F6 to-COM disabled, MIOS Device ID = 0x03 :080000000000000000000003F5 to-COM disabled, MIOS Device ID = 0x00, KS0108 GLCD driver (1) :080000000000000000001000E8 to-COM disabled, MIOS Device ID = 0x00, custom LCD driver (7) :08000000000000000000700088 to-COM enabled, MIOS Device ID = 0x00 :080000000000000000000100F7 to-COM enabled, MIOS Device ID = 0x01 :080000000000000000000101F6 to-COM enabled, MIOS Device ID = 0x02 :080000000000000000000102F5 to-COM enabled, MIOS Device ID = 0x03 :080000000000000000000103F4 [/code] Best Regards, Thorsten.

If no other volunteer can be found, then just write me a mail and I will send you my postal address Or you try to contact Nenad, he is also from Serbia and has successfully built a very cool MIDIbox (see the MIDIbox Gallery for his email address) Best Regards, Thorsten.

You wrote that your programmer gets hot - could it be that it is damaged for some reason and fries the PICs? (makes them unusable) What are the results of the IC-Prog hardware checks? (see the MBHP_JDM page for some instructions) I know that you don't use the JDM, but the measuring results should be the same. Moaning doesn't really help you - there are a lot of people who would burn and especially test a PIC18F for free, even SmashTV sells preburned PIC18F452 for just US $9 + complete kits with all the components - and he doesn't do this to earn money, but to give MIDIbox Newbies a smooth start. Best Regards, Thorsten.

Hi Artem, "additional 5V at some pin" sounds very vague, if he read something about the LVP mode, which has to be selected with 5V at RB5, then I can tell you that this pin has to be tied to zero for proper operation. If he forgot the pull-down resistor like documented at the MBHP_JDM page (see http://www.ucapps.de/mbhp/mbhp_jdm_lvp_fix.gif ...then this is definitely the reason for the failing LCD Best Regards, Thorsten.

Addendum: I just remember that RB5 is the low-voltage programming pin. How did you flash the bootloader into the PIC? If you've used a Low-voltage programmer, pin RB5 will be disabled and the LCD won't work Best Regards, Thorsten.

Hi Shar, since you have a scope, it should be very easy to find this out! :) Take the small_skeleton application, open "main.asm" with your favourite text editor, search for "USER_Init" and add following lines: USER_Init clrf TRISB ; enable output drivers of port B USER_Init_Endless_Loop clrwdt ; feed the watchdog comf LATB ; toggle all pins at port B nop ; 400 nS delay nop nop nop comf LATB ; toggle all pins at port B again nop ; nop + rgoto + clrwdt = 400 nS delay rgoto USER_Init_Endless_Loop [/code] compile the code like described under http://www.ucapps.de/howto_tools_mpasm.html (but with MIOS Studio you neither need perl + the hex2syx.pl script, just load the new .hex file directly into MIOS Studio) After the first upload request all pins at Port B should start to toggle with a frequency of ca. 1 MHz You could do similar tests for the other IO pins Note that this endless loop prevents you from uploading new code so long the USER_Init routine is running. If you want to upload new code, you have to reset the PIC - thereafter you can overwrite the endless loop with the first level bootloader Best Regards, Thorsten.

die ersten beiden Seiten, die von Martin uebersetzt wurden, sind nun online: http://www.ucapps.de/midibox_seq_de.html http://www.ucapps.de/midibox_seq_options_de.html besten dank! :) Gruss, Thorsten.

Durch den MCLR# Pin fliesst ein vernachlaessigbar kleiner Strom - Vpp wird lediglich zur Aktivierung des Programmiermodus hergenommen - deshalb faellt die Spannung hauptsaechlich am 1k Widerstand ab. Welchen LM317 verwendest Du genau? Das Pinning ist je nach Gehaeusetyp unterschiedlich. Hier gibt es das Datasheet: http://www.national.com/pf/LM/LM317.html Gruss, Thorsten.

Just for the case that you want to feel more confident with the crystal - exactly this type was successfully tested by Preben_Friis, see: http://69.56.171.55/~midibox/forum/index.php?topic=1338.0 Best Regards, Thorsten.

I'm not sure about the configuration, it could be that all bits which don't exists are zeroed (so that the implemented bitfields are setuped correctly) - if the verify function says ok, then it should be ok If pin 25 (the Tx pin) is not +5V, the PIC is not running (and therefore hasn't enabled the serial transmitter). Now you've either a problem with the new crystal (again), or with the connections between crystal and PIC (check for shorts and broken tracks), or a new problem anywhere else? Hard to say over this distance Best Regards, Thorsten.

Hierfuer eignet sich IIC ganz gut - ich nehme mal an, dass Du nicht mit FPGAs arbeiten moechtest, so nimm einfach ein paar (guenstigere) Atmel Chips mit 2 USARTs fuer jeweils 2 MIDI IOs. Gib jedem Atmel eine eigene IIC Slave Adresse, so dass ein IIC Master die MIDI-Daten ueber den Bus verteilen kann. Selbst wenn der IIC Bus mit einem relaxten Timing von 400 kbit getaktet wird (1 MBit sollte auf Boardlevel ebenfalls moeglich sein), koenntest Du damit locker 10..12 MIDI Ports mit voller MIDI-Bandbreite versorgen. Und das ist der Worst-Case - solange nur Steuerdaten (also keine laengeren SysEx Dumps) an alle MIDI Ports gleichzeitig verteilt werden, haut das hin. Dir ist bewusst, was Du da angehen moechtest? ;-) Das AOUT Modul arbeitet mit 12bit, ein LSB macht also 1/4096 * u_max aus, das sind bei 10V Maximalspannung ca. 2.4 mV --- ich moechte mal einen analogen Synthesizer sehen, dessen Grundrauschen (an den Steuerleitungen) kleiner als 5 mV ist jep, auch ein analoges Drum Modul waere nichts anderes als ein weiterer IIC Slave :) (Allgemeiner Tip zum Thema Drum Module: du kennst Hallucinogen's Seite? http://xlargex.xl.funpic.de/) Theoretisch mit einem Atmel machbar, wird aber ziemlich tricky bei dieser Bitrate (ein einzelner 8bit uC wird da schon ziemlich ausgelastet sein, 32bit waere besser geeignet) Somit wird die Anzahl der Tracks durch die Performance der "Master MCU" und des Bussystems beschraenkt - bin mir nicht sicher, ob es nicht einfacher waere, alles von einem AT Mega zu verwaltet, der Programmieraufwand ist geringer, und mit entsprechend grossen Memory sollten 128...256 Tracks machbar sein. Das klingt machbar, die MBSEQ arbeitet bspw, mit der gleichen Aufloesung (96 ppqn = 384 clocks pro Takt) und kann 48 (Drum) Tracks ohne Timingschwierigkeiten verwalten. Hier ist das Nadeloehr in der Tat die langsame MIDI Schnittstelle, doch zwei MBSEQ lassen sich schliesslich auch parallel betreiben ;-) Doch MBSEQ arbeitet auch nur mit 7bit Events, mit einer hoeheren Aufloesung wuerde es nicht mehr so glatt laufen. Eine Verzoegerung laesst sich am einfachsten erreichen, indem man die Events entsprechend dem internen Taktraster verzoegert (also: "ticks" abzaehlen und dann das Event abfeuern). Hierfuer ist ein normaler MIDI Port ausreichend --- bei der Synchronisation kommt es vor allem auf Timingstabilitaet an, also einen geringen Jitter. Wenn Du ganz penipel vorgehen moechtest (denn auch der IIC koennte mal unguenstig blockiert sein), wuerde ich empfehlen, aus den MIDI Clock Events, die an einem der MIDI Ins eintreffen, direkt ein Clock Signal zu erzeugen, und dieses an einen Interrupt Eingang des "Master Controllers" (oder den Sequenzern) anzuschliessen, so dass die Latenz zwischen MIDI In und Sequencer im Worst Case < 10 uS betraegt. Auf diese Weise waere Deine Hardware auch kompatibel zu analogen Sequenzern ;-) Gruss, Thorsten.

Hier wird der serielle Datenstrom von jedem Core weitergeleitet. Stichwort "MIDIbox Link" Siehe auch http://www.ucapps.de/midibox_link.html Gruss, Thorsten.

Hallo, suche im Forum mal nach "digital pot", es gibt ein paar Leute, die damit schon herumexperimentiert haben (bspw. Pilo soweit ich mich erinnern kann) Gruss, Thorsten.

Hallo, leider nicht - MIDI ist eine Point-to-Point Verbindung und kein Bussystem. Die seriellen Datenstroeme lassen sich nicht einfach elektrisch zusammenfuehren, sie muessen bspw. von einem Mikrocontroller "gemerged" werden Gruss, Thorsten.

Mit der Beschreibung alleine ist schon das meiste getan, die englische Uebersetzung koennen auch andere ins Reine bringen :) Gruss, Thorsten.

Good luck! :) next time give them following link: http://www.tla.co.nz/xtal1.html Best Regards, Thorsten.

D7 is a data input/output pin of the LCD - see also the schematic http://www.ucapps.de/mbhp/mbhp_lcd.pdf of course, if you are not sure if MIOS has been uploaded correctly, this could be one of the reasons - so long this isn't clear, it doesn't make sense to talk about possible hardware problems. I can only mention the following: even people who thought that they have super proper connections to the LCD, noticed a broken wire or a short sooner or later. Just search in this troubleshooting section for reports, it gives you a lot of inspirations what can go wrong. this is really strange! Could it be that a short is anywhere else which causes a brown-out reset? Data is sent to the LCD, thereafter the RB port is switched to input mode and the LCD driver polls the busy flag at D7. There is a timeout loop which ensures that the LCD driver will be completely disabled if the busy bit never goes zero (0V) - this covers the case that no LCD is connected. But if anything else drives the input (RB7) with a non-static and "strong" signal (stronger than the internal pull-up), then the timeout loop will stop sooner and later and the next character will be transmitted. If multiple characters are sent to the LCD, and the erroronous, non-static signal enlarges the timeout-loop very often, so that it takes more than 2 seconds to display a string, the watchdog (malfunction detection) will reset the chip. However, as mentioned above: so long you haven't ensured that MIOS hasn't been uploaded correctly, such thoughts are only from theoretical nature. My suggestion: use the new MIOS Studio to upload MIOS. It notifies errors which are reported by the core module, so only with MIOS Studio it is guaranteed that the code upload was complete. Just load the mios_v1_7.hex file, enable the "wait for upload request" option and press the start button. Another important point regarding software configuration: are you sure that the right display type is selected? Which LCD option did you specify in the ID header? Hopefully 0? If you are not sure, or if you are sure that it is != 0, then do the following: disconnect the LCD, upload MIOS, upload the change ID application. This will reset the ID to 0000000000000000 Best Regards, Thorsten.

Hi Moxi, open seq_core.inc, search for "SEQ_CORE_Clk_OnEvent_ChkDrumSolo", and remove the code between this and the "SEQ_CORE_Clk_OnEvent_NoDrumSolo" lable The possibility to select multiple layers at once would be easier (same behaviour like for the track buttons) - but "easier" doesn't mean that the implementation is easy ;-) Best Regards, Thorsten.

d0 und d1 sind eigentlich ideal, weil es mit dem Pin-Out der MIDIbox SEQ matcht, andererseits liegen hier Select und Exec auf dem zweiten Shift Register, deshalb stehst Du nun vor einer schwierigen Entscheidung: entweder stellst Du die MBCV so ein, dass das Pinning einer MB64 oder MB64E entspricht, oder so, dass es einer MBSEQ entspricht. Oder Du pfeifst auf die Hardwarekompatibilitaet und stellst das Pinning so ein, wie Du die Kabel gerade angeloetet hast. (s'ist schon schwierig, wenn man als Programmierer eine solch hohe Flexibilitaet erlaubt ;-) Ok, bleiben wir bei der MB64/MB64E Kompatibilitaet, weil Du hier nur ein einziges Shift Register benoetigst. Der Encoder sollte auf Pin 4/5 liegen: ENC_ENTRY 1, 4, MIOS_ENC_MODE_DETENTED ; Data Wheel [/code] Und die restlichen Pins: [code] #define DEFAULT_ENC_DATAWHEEL 0 ;; wir nehmen den ersten Encoder Eintrag ; ; DIN pin numbers of menu buttons #if DEFAULT_ENC_DATAWHEEL == -1 #define DEFAULT_DIN_MENU_EXEC 7 ; wird nicht genommen, da DEFAULT_ENC_DATAWHEEL != -1 #define DEFAULT_DIN_MENU_RIGHT 6 ; wird nicht genommen, da DEFAULT_ENC_DATAWHEEL != -1 #define DEFAULT_DIN_MENU_LEFT 5 ; wird nicht genommen, da DEFAULT_ENC_DATAWHEEL != -1 #define DEFAULT_DIN_MENU_SELECT 4 ; wird nicht genommen, da DEFAULT_ENC_DATAWHEEL != -1 #else #define DEFAULT_DIN_MENU_EXEC 7 ; Exec Button an D7 #define DEFAULT_DIN_MENU_SELECT 6 ; Select Button an D6 #define DEFAULT_DIN_MENU_RIGHT 5 ; nicht relevant, hier kann irgendein Wert stehen #define DEFAULT_DIN_MENU_LEFT 4 ; nicht relevant, hier kann irgendein Wert stehen #endif die hatte ich kurz vor der Release mal schnell eingetragen, doch vergessen, sie wieder zu entfernen. Ich habe die MBCV damals an meiner MBSEQ entwickelt... Was bedeutet die 8: damit verlagerst Du den Pin auf ein anderes Shift Register. Man koennte statt 5+8 auch einfach 13 eintragen, und welchem Pin das entspricht, erfaehrt man aus dieser Liste: http://www.ucapps.de/mios/mios_din_dout_pin_numbers.txt (eigentlich ist doch alles sauber dokumentiert, oder? ;-) Gruss, Thorsten.

Hi, The internal pull-ups are enabled at Port B, so that external resistors are not required. The signal at RB7 could be the reason - the timeout mechanism won't work properly if the signal level at RB7 is not stable, e.g. if you've swapped D7 with another LCD pin Best Regards, Thorsten.