TK.

MIDIbox SEQ V2.2c can now be downloaded from http://www.ucapps.de/mios_download.html Fixed bugs: the slide function is working again when the gatelength is >24 and a note is followed by another note the sequencer doesn't switch to the song menu anymore when an MIDI Clock Start event is received from external. Best Regards, Thorsten.

Hallo, die Firmware war nach einer Stunde fertig programmiert (basierend auf dem CDC Framework von Microchip), doch dann bin ich leider auf einen Silicon Bug gestossen, der den EUSART betrifft. Im Endeffekt bedeutet es, dass mit dem PIC18Fxx5x keine zuverlaessigen Transfers ueber die serielle Schnittstelle moeglich sind (hin und wieder werden nullen in den Stream eingefuegt) Naehere details: http://forum.microchip.com/tm.asp?m=85120 Nun stehe ich also vor dem Problem, dass es zwar einen Driver gibt, jedoch keine funktionierende Hardware. Und es kann wohl auch noch ein paar Wochen dauern, bis Microchip reagiert, eine neue Revision erstellt und es diese dann auch zu kaufen gibt (ich vermute mal, dass bspw. Reichelt noch Jahre die Rev3 fuehren wird) RS232 Treiberprogrammierung: da gibt es eigentlich nichts zu entwickeln, das CDC Framework, welches man von der Microchip Homepage downloaden kann, bietet bereits eine USB->COM Schnittstelle. Sie verwendet das Legacy-COM Protokoll, das von allen gaengigen Betriebsystemen unterstuetzt wird. Gruss, Thorsten.

Hi Jeff, first of all: this won't be a trivial job because the MBFM firmware is not written in a trivial way. Main focus on the cs_menu handler is not a newbie friendly programming interface, but a powerful UI which consumes so less as memory as possible. Therefore the parameter handling is not easy to understand, and it is spreaded over several files (they all begin with cs_*) I can only say: read the comments in these files, start to draw diagrams about the program flow (starting point: USER_DISPLAY_Tick in main.asm), take especially a look into cs_menu_tables.inc --- this should help. Another note: the user memory of the MBFM has nearly reached its limit (there are about 128 bytes free), you will propably not be able to integrate the VFD driver into the application itself. Instead you have to hack this directly into MIOS (you could write the code directly into mios_clcd.inc, this means: just remove the common LCD driver) Best Regards, Thorsten.

Hi Robin, yes, thats exactly the right way. Best Regards, Thorsten.

oh great, people are buying stuff an begging me for a solution regardless of the effort from my side... do I really have to answer to each posting, or wouldn't it be better to give me my time to complete unfinished plans (wouldn't this even more benefit for the community?) Joystick driver: beside of the link given by TL you should take a look into this posting http://69.56.171.55/~midibox/forum/index.php?topic=1783.0 And a general statement: if the community is not able to create a proper documentation of such "quick hacks", my motivation to publish even more solutions will go down more and more. Because I've the impression that each time I'm doing this I'll have more effort in advance than I really want. The situation could be much better if you wouldn't only "consume" such contributions, but would also give something back. We have a Wiki, we have a lot of webspace at the midibox server (e.g. for diagrams and pictures), nothing prevents you from writing docs. Best Regards, Thorsten.

Hi Ludo, I don't think that this is a bug in the sequencer. Could it be that you've selected a mono voice in your synth? Best Regards, Thorsten.

Hallo, 1.1k passt schon Gruss, Thorsten.

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.