TK.

Have fun! ;-) I just have added some programming specifics to the webpage in the hope that they don't confuse newbies that much. This module is just a nice toy and has a lot of potential for future enhancements :) Best Regards, Thorsten.

A FPGA cannot beat the real SID, because the original chip contains some analog circurity which cannot be emulated with digital logic. The FPGA project can be compared with software emulators like the SIDPLAY library - no benefit at all, just a nice alternative solution... Best Regards, Thorsten.

It's described here: http://www.ucapps.de/midibox_seq_options.html Best Regards, Thorsten.

Hi, the firmware controls this particular LED in the following way: (1) LFO6->Filter off: J5:D0=0V and J6:D1=0V (LED off because both pins are at the same level) (2) LFO6->Filter on: J5:D0=5V and J6:D1=0V (LED on because of right direction -> anode connected to J5:D0) But: all LED lines are time multiplexed. J6:D1 is only 0V for a short moment, in 6/7 of the multiplex cycle J6:D1 is held to 5V This means: so long the LED line is not selected, we have: (3) LFO6->Filter off: J5:D0=0V and J6:D1=5V (LED off because of wrong polarity) (4) LFO6->Filter on: J5:D0=5V and J6:D1=5V (LED off because of same level at both pins) If you connect the LED in the wrong direction (cathode connected to J5:D0), it will light in 6/7 of the update period because of case (3). You can doublecheck this by turning on the modulation for LFO6->Filter in the MOD menu - the LED should turn off. If you've connected the LED in the right direction, it should turn on. Hope that this answers your question... Best Regards, Thorsten.

no further update - the firmware is running stable, but there is no more documentation available yet than this forum article and this tutorial http://www.ucapps.de/howto_sid_wavetables_1.html Best Regards, Thorsten.

This is a really beautiful synth/sequencer combination made by Alex :) He wrote: check also his website for more details: http://enmusic.by.ru/

The files (>700k, very good picture quality) can now be downloaded here: http://www.midibox.org/users/freaksomnia/PICT0002.JPG http://www.midibox.org/users/freaksomnia/PICT0003.JPG http://www.midibox.org/users/freaksomnia/PICT0005.JPG http://www.midibox.org/users/freaksomnia/PICT0010.JPG Here some smaller versions with remarks: 1: the core module has some bad solderings (loose connections), which could lead to failures. There are also missing solderings (e.g. 33pF cap below crystal). I would propose to solder each pad again, the soldering guide in the Wiki gives some useful tips 2: the legs of the caps should be cutted, otherwise they can cause a short circuit which can damage the PIC! 3: this seems to be a bad ground connection directly at the 78xx - it can lead to the wrong voltage. Here the same: just solder the pads again, it will help And also cut the long cap legs, the danger for shorts is too high Best Regards, Thorsten. P.S.: I don't want to bother you, but do you allow me to bring the two pictures into the wiki in order to explain other newbies, for what they have to take care about?

Ah - thanks, now I also remember this effect. It should be documented at the MBHP pages Best Regards, Thorsten.

Hallo, nein, den Takt kann man nicht erhoehen, es gibt in der Slave Firmware einen kritischen Pfad, der eingehalten werden muss (Delay zwischen zwei empfangenen Bytes) - wenn der Master also zwei Bytes schneller sendet, als der Slave sie weiterverarbeiten kann, kommt es zu einem Not-Acknowledge, und somit zu einem Retry. Die Performance wuerde darunter leiden. kannst Du doch machen... ;-) Gruss, Thorsten.

I think, that this is not an electrical, but a conceptional issue. Computer keyboards are usually polled with a rate of 50 times per second (-> 20 mS), this is not fast enough for your project. With the sm_example2 project you could do the same at a rate of 12500 times per second (-> 80 uS) Best Regards, Thorsten.

the reason for this issue would be really interesting, because I also have no explanation, why another adapter should lead to higher voltages behind the 7805. There could be a short at the bottom of the PCB, therefore it would be helpful if you could post a photo of the front- and bottom side of your board (you can send me the pictures, I will put them on the server) Best Regards, Thorsten.

just compare the C code above with the assembly version within the MIDIbox SEQ package (midi_evnt.inc, MIDI_EVNT_PrintNote) There are two versions, one iterative, one table based (which is disabled). The iterative version works fast enough. The loop which determines the octave takes ca. 13 uS in worst case (highest octave), thats appr. the same time it takes to print a character on LCD, and this is the point: The LCD always needs some time to print a character. MIOS polls for the busy flag before (and not after) a new character is transfered to the display. This has the advantage, that the CPU can do something else during the busy state without loosing performance. Best Regards, Thorsten.

this picture shows, how to measure the voltages:

Hi Todd, both - I'm planning to port even more applications to C in order to simplify the customization. One thing what I want to realize sooner or later is a generic "MIDI controller template" for all kind of control elements (and LCD output formats), which can be easily adapted to the host application - it's the "MIDIbox NG" idea, just in a different form - no graphical GUI or sysex dump for configuration, but C code which can be modified and enhanced easily. I'm happy that more people are now starting to program apps by themself, so this seems to be the right path. My long term strategy is to have some apps ready in a (more or less) processor independent language, so that the migration to another microcontroller will be easier. But this is a plan for the next 3 years, in short time the PIC18F4620 will do the job for "next generation MIDIboxes" (MBSID V2, MBSEQ V3). And if Microchip should release another pin compatible uC in the next years, it will be the successor for the MBHP as well. I would propose to start the sequencer in C. On performance issues, you can replace parts of the core functions by assembly code. If you run into greater performance (or code size) problems, then you need to write the whole app in ASM, but this will be easier, since you've propably already tried out the "general concepts" in C (rapid prototyping is faster) For MBSEQ/MBSID/MBFM I will stay on ASM Best Regards, Thorsten.

The function overview of MIOS has been overworked - there is an alternative page now which shows declarations and examples in C style: http://www.ucapps.de/cmios_fun.html Best Regards, Thorsten.

Hi Geert, very good that you are measuring the voltages before stuffing the chips - otherwise you would have a dead PIC and SID now! the 104 is a 100nF as well. no, only wrongly mounted the voltage regulators could be the reason Best Regards, Thorsten.

Hi Sam, the serial connections from the DIN/DOUT module to the board should be as short as possible. If the two boxes are very close together (ca. 30 cm maximum), you could build the modules into the second box. Use a shielded cable to protect the signals against influences from other gear! The cable must have 6 wires (Vs/Vd/SI/SO/SC/RC) and the shield to ground If you decide to build the modules into the first box, the cables to the button/LEDs can be very long (> 1 m or more), and EMC isn't a big issue here Best Regards, Thorsten.

die Anzahl der Buffer, sowie die Puffergroesse habe ich flexibel gehalten. Ich habe verschiedene Konfigurationen ausprobiert, momentan verwende ich folgende Einstellungen (in usbcls.asm) o 4 IN Buffer je 64 Bytes, Transferlaenge 64 Bytes o 2 OUT Buffer je 64 Bytes, Transferlaenge jedoch nur 8 Bytes Die Buffer koennen noch waehrend eines laufenden Transfers vorbereitet/abgearbeitet werden - das steigert vor allem auf der IN Seite die Performance. Die Pufferadresse wird von der Software gesteuert (kein Ping Pong Modus) Die Transferlaenge (welche im Endpoint Descriptor definiert ist -> usbdsc.c) habe ich reduziert, da hiermit der besagte Effekt im Loopback seltener auftritt (ich habe es einfach mal ausprobiert) Die Zahl habe ich nicht mehr im Kopf, doch ich kann sie bei gelegenheit ermitteln. USB MIDI unterstuetzt nur Bulk Transfers Denke schon, Windows ist nicht so mein Thema. ;-) das klingt interessant! Gibt es unter Windows so etwas wie /var/log/messages unter Unix, also ein systemweites Logfile, in dem solche Ereignisse hinterlegt werden? Das wuerde mich wundern, denn mit dem EZ-USB funktioniert diese Konfiguration problemlos. Steht das irgendwo in der USB Spec? Vor ein paar Tagen hatte ich mal temporaer die Konfiguration "IN auf EP1, OUT auf EP2" ausprobiert, der IN Buffer wurde weiterhin sporadisch (ohne erkennbares Schema) blockiert. Ich habe mal einen aktuellen Snapshot nach http://www.ucapps.de/tmp/mbhp_usb_pic_snapshot.zip gelegt. Der interessante Code steht unter usbcls.asm und usbdsc.c Ich sehe die UOWN Bits als Semaphore fuer den RAM Bereich: wenn beim OUT Buffer UOWN geloescht ist, weiss man, dass ein neues Packet angekommen ist. Man holt es sich ab, und setzt das Flag wieder (+ DTS Handshake). Beim IN Buffer geht man davon aus, dass er beschrieben werden darf, solange UOWN geloescht ist. Die SIE wird solange nicht darauf zugreifen, bis man UOWN wieder setzt. Solange man also die Regeln einhaelt, auf den Memory Bereich niemals zu schreiben, wenn UOWN gesetzt ist, und UOWN niemals via Software zu loeschen, kann nichts schieflaufen. Scheinbar, ansonsten wuerde die Uebertragung ueber einen anderen EP funktionieren. Es ist immer gut, wenn man mal darueber spricht :) Gruss, Thorsten.

Today AVR should be the first choice, it has a modern architecture, and is easier to program. Unrelated to your question I would like to mention, why I still stick to the PICs: it wouldn't take much time to port MIOS and most of the applications to AVR, but the support effort would be much higher (supporting two different architectures is a mess), and benefit wouldn't be that high. The only candidate which could be used for the MBHP is ATMEGA644 (64k flash, 40 pin DIP), but it's hard to get (as Wise mentioned), and the datasheet says "not recommended for new designs". All newer devices with more than 32k flash are only available in a TQFP package - if I ever take the risk to provide a core module with SMD devices, I would prefer a much more advanced 16bit or 32bit microcontroller. Especially an option for fast accesses to external flash/SRAMs would be very appreciated for a more flexible graphical LCD handling. Best Regards, Thorsten.

The biggest problem is, that I get new layouts without prewarning ca. all 2-3 months, and people don't see the effort on my side (the latest DOUX2 bug shows, what can happen when I don't pay enough attention for such layout changes). The funniest thing was last year, where somebody replaced all ICs by SMD parts, changed the routings, changed the copyright notice, and told me that the layout is "much better now" and expected that I have to check the new layouts and replace my old ones. He used an cracked version of eagle so that I was not able to open the .brd files... it took some emails to explain him, what is wrong with these layouts - and all this at a time where I wanted to do something else than discussing about PCBs... However, I've created a new Wiki page which allows everybody to share improved layouts: http://www.midibox.org/dokuwiki/doku.php?id=layout_improvements Best Regards, Thorsten.

Alex, I just came from holidays, was busy with sorting the forum postings, and haven't found the time yet to go through my emails. There are so many people who are asking me "important questions", so please let me some days to find some time for your email! I especially don't like it, when people assume, that I'm ignoring their emails when I have replied some other postings in the meantime. I cannot reply to everbody in zero-time! Best Regards, Thorsten.

FAQMARKER

Hallo Claudio, "pipes" sind die logischen Datenpfade zwischen USB host und slave, jeder "Endpoint" bietet zwei Pipes, eine fuer eingehende, eine andere fuer ausgehende Daten. es koennte sich hier um den gleichen Effekt handeln, er hat jedoch nichts mit Interrupts zu tun - ich habe die USB Firmware ja mittlerweile komplett in Assembler programmiert, nicht zuletzt, um vom C18 loszukommen (dessen Demo-Lizenz nach 3 Monaten ausgelaufen war), und natuerlich um die Performance zu verbessern. Nach wie vor koennen jedoch Daten verloren gehen, wenn die OUT pipe nicht sofort bedient wird, und etwas durch die IN pipe geschickt werden soll. Die IN pipe ist manchmal (schlecht reproduzierbar) fuer > 40 mS blockiert, dies fuehrt dann zu einem Buffer Overrun auf der Empfangsseite der MIDI Schnittstelle. Das alles laesst sich sehr einfach mit einem Oszilloskop debuggen, wenn man die EP*B*.UOWN flags auf IO pins legt, und sich eine Triggerbedingung schafft (Buffer Full) - dadurch kann ich auch einen Softwarefehler ausschliessen. Leider tritt der Effekt auch dann auf, wenn OUT und IN pipe auf verschiedene Endpoints liegen. Ob es mit dem Ping Pong Modus besser funktioniert, weiss ich nicht (ist mir zu umstaendlich, und hilft wahrscheinlich nicht weiter). Der einzige Workaround, der mir bisher eingefallen ist, waere die Programmierung eines neuen USB MIDI Drivers fuer Windows, der dieses Szenario vermeidet, und hierum kuemmert sich gerade Synapsys. Ich bin mir nicht 100% sicher (da ich auch nicht unnoetig viel Aufwand ins Debuggen stecken moechte), aber es koennte sich hierbei entweder um ein undokumentiertes Performance Problem handeln, oder gar um einen weiteren Silicon Bug im USB Peripheral. Mit der EZ-USB basierenden MBHP_USB Firmware tritt dieses Problem naemlich nicht auf, selbst wenn die Buffer fuer die seriellen Schnittstellen nur 8 byte gross sind! Hast Du die SysEx Transfers nun mal mit Deiner Firmware ausprobiert? Gruss, Thorsten.

Hallo, ja, es gibt einen Blackboxtest, doch der ist IMHO aufwaendiger zu realisieren, als den Core zu debuggen: http://www.midibox.org/users/willy/frattest.png Alternativ kannst Du die Verbindungen zu den DOUT/DIN Modulen mit dem srio_interconnection_test ueberpruefen (Anleitung steht in main.asm) Gruss, Thorsten.

Es ist gar nicht so abwegig, diese Applikation unter MIOS aufzubauen, doch ich wuerde Dir empfehlen, sie in C zu programmieren, das geht normalerweise schneller, und ist besser wartbar. Die zeitkritischen Dinge wie LCD Ausgabe und Timer getriggerte AD Konvertierung sind ja bereits Teil von MIOS und assembleroptimiert, der Rest ist eigentlich nur noch data processing und User Interaktion. Ein C Template fuer die von der MB64/64E/MF/CV/SEQ bekannten Menuesteuerung steht bereits auf meiner ToDo Liste - es sollte nicht so aufwaendig sein. Die Assembler basierte Version besteht im wesentlichen aus einer Tabelle (cs_menu_tables.inc), und einigen Routinen in cs_menu.inc, die diese Tabelleneintraege je nach gewaehlter Menueposition verarbeiten. Gruss, Thorsten.