TK.

I'm using Linux/Solaris computers @work, PC as Tarantella client and for eagle, and Mac for the rest However, before it gets more off-topic, I splitted the thread and moved this to the misc section ;) Best Regards, Thorsten.

Hi, this is a frequently asked question, and the answer is unfortunately still the same: no there is no programming example for recording MIDI streams. Best Regards, Thorsten.

Vielleicht hast Du die Encoder-Pins falsch angeschlossen? Falls das Datenblatt nicht weiterhilft: es gibt nur drei moegliche Verdrahtungsmoeglichkeiten - probiere mal die beiden uebrigen aus :) Gruss, Thorsten.

Hallo, der microQ sendet aber nicht einen neu selektierten Patch, die Parametersend-Funktion ist hauptsaechlich zur Automatisierung gedacht. Zum Parsen (und senden) von geraetespezifischen SysEx-Strings muesste man sich eine eigene Applikation schreiben. Gruss, Thorsten.

Too much speed optimisation... right half will be cleared again in the next release Best Regards, Thorsten.

This beautiful MIDIbox SID V2 has been built by Kevin aka. Subatomic Don't miss his construction blog: http://www.subatomicglue.com/sidl0g/ :)

This MIDIbox FM has been built by Markus - he confirmed, that it can perfectly built by electronic novices when you just take your time! :)

I'm using the evaluation board from Ploytec... 1) we've to wait until the PCB layout is ready 2) thereafter I've to ask Ploytec for a confirmation, that they handle the PCB order for us 3) thereafter I can tell you the exact prices (+ taxes and shipping) 4) thereafter I need the final quantity numbers for GM5/PCBs from your side 5) I will collect the money and order the chips and PCBs (maybe in parallel, if most people prepayed fast enough) 6) I (and maybe also Screaming_Rabbit) will send you chips/PCBs once they are available It can be assumed, that we will order 500 chips. Everybody who is already in the list will get the requested quantity Note that we have to order n x 100 PCBs! Best Regards, Thorsten.

Please offer it here in the forum, and not at EBay Best Regards, Thorsten.

Yes, just have a look into existing modules. You can get write access to the repository if you want. This allows you to publish your modules Best Regards, Thorsten.

Yes, in the Repository Meanwhile we are using precompiled libraries, the derivative is defined in the Makefile (PROCESSOR variable), the appr. files are selected automatically. Best Regards, Thorsten.

Yes, RGB handling can be easily done in C. If much more should be handled in parallel, assembly code would be better (therefore I mostly write my own modules in assembly) Template: currently I reorganize the whole MIOS project structure for better re-use. E.g., the BLM matrix is now seperated in a special directory (modules/blm), and the application directory only contains the actual source files (see this directory). And to make the confusion complete: when I release an application, all these directories are copied again into a single directory ;) However, what I want to say: if you want to develop this application future-proven, I recomment the new approach. I will give you access to the programmer section of this forum, so that you can read more about the details. LCD messages: you could realize this the same way like in the Motormix application Best Regards, Thorsten.

Surprise ;) I quickly soldered a prototype board, and uploaded the example application for a "mass storage device" (AN1003). The C code which accesses the SD card looks simple. However, the challenge will be to make the code small enough, so that it fits into existing applications (w/o USB support of course). It also makes sense to use the bitbanging method instead of SPI peripheral for higher GPIO flexibility (speed doesn't really matter, considered that a SD card is already much faster than a IIC EEPROM) I think, that it can be easily re-written in assembly, and provided as a MIOS Module Best Regards, Thorsten.

I only see the difficulity to handle the FAT file system when adding files, I guess that it requires a lot of code and probably a lot of RAM. On the other hand: it should be easy to prepare directory structures for different purposes. E.g. MBSID: just prepare bank A/B/...G in different directories, and put 128 files with a size of 512 bytes into each, which are the "slots" for 8*128 patches This would also simplify the patch exchange between MBSID and your computer :) Best Regards, Thorsten.

Yes, it works great! I'm using it on a Mac since more than one week (e.g. while creating the MBSID Bassline Demo) and haven't noticed any failure :) The Windows driver is not ready yet, therefore I haven't got the chance to check, if it works better than the Microsoft Driver. Another good news: Ploytec offered the possibility to layout our own PCB, Nils is working on it. :) The PCB should have the same size like the original Ploytec evaluation board, otherwise we would have to pay more money for additional area - therefore the focus is to make it more DIY friendly (e.g. replacing SMD resistor/caps by through-hole parts) Best Regards, Thorsten.

This is indeed a great project - don't miss the promotion videos ;) http://nl.youtube.com/watch?v=YEjF9uvv1gM This reminds me, that replacing BankStick by SD/MMC is still on my ToDo list (meanwhile I got some cheap card sockets :)) Best Regards, Thorsten.

P.S.: Nachteil dieser Loesung: Poti-Sweep nicht linear. Der Eingangswiderstand der Offsetschaltung betraegt ca. 22k, deshalb solltest Du vielleicht erstmal ein 1k Poti ausprobieren, so wuerden sich die 22k nicht so stark auf den Kurvenverlauf auswirken - ich kenne nun nicht den Ausgangswiderstand des DACs auswendig, aber es koennte so zufriedenstellend funktionieren. Falls nicht, hat vielleicht noch jemand anderes eine bessere Idee aus der Praxis ;) Gruss, Thorsten.

Stimmt, das SSM Modul ist auf eine bipolare CV ausgelegt. Das kriegt man aber trotzdem in Griff, schalte das Poti einfach zwischen dem DAC Ausgang und der Offset-Schaltung. Beispiel fuer den ersten Kanal (vergleiche mit AOUT_NG Schaltplan): [tt] Masse o---/\/\/\/\---o JP1:2 ^ | o JP1:1 [/tt] Zum Mitdenken: - JP1:2 (DAC Ausgang) auf Maximalwert: Poti erlaubt Sweep ueber gesamten Spannungsbereich - Poti auf Vollanschlag (rechts): JP1:1 direkt mit JP1:2 verbunden Gruss, Thorsten.

Just have a look into the sidplay code :) (I guess, it's hosted at sourceforge) Best Regards, Thorsten.

Yes, I was confused by the code you quoted Best Regards, Thorsten.

Moin, ich wuerde Dir Loesung 2 empfehlen, aber nicht mit Encodern, sondern mit normalen Potis. Schalte sie einfach als Spannungsteiler zwischen AOUT Ausgang und Masse (Modularsynth-Freaks nennen die Schaltung auch "Abschwaecher"). Wenn Du die CV mit dem Poti ueber den gesamten Spannungsbereich einstellen moechtest, muss die MBCV den Maximalwert ausgeben (dafuer kannst Du Dir einen speziellen Snapshot erstellen) Und wenn MBCV die Spannung steuern soll, muss das Poti auf Maximalwert gestellt werden. Und als zusaetzliches Feature bietet Dir diese primitive Schaltung auch noch den Vorteil, dass Du bequem den Gain einstellen kannst :) Gruss, Thorsten.

No, because if the polling starts while RC2 is already 1, you would miss the edge and shift the strobe With interrupts you wouldn't be able to achieve the strict timings. Btw.: interrupts should be disabled while the polling loop is processed. Just study the pictures ;) There is a D FF between the input pin and the data bus. I believe, that these are in fact two FFs (common design rule to prevent metastabilities), because I measured a delay of 3 clock cycles. The third FF stage is in the CPU pipeline So, you've an huge external memory which contains the SID register traces. I guess that preloading this memory will take very long... so, why not emulating a 6502 with the PIC, and process the player code (which is embedded in the .sid file) directly? You would need an external RAM (64k), so that the whole address space of a C64 is available, and a CPU emulation routine which processes the SID player code. Since this routine is normaly clocked at 50 Hz, you've 20 mS to decode the CPU instructions - this should be possible. I would also propose to connect the SID pins directly to the PIC, and not via serial interface, because your application doesn't require so many different external components like a MBSID. This would give you more CPU time for the emulation. Best Regards, Thorsten.

It isn't required to connect such a clock output to another IO pin, just read the port input register of the output pin. For the case you don't know - the source code is located here, and this is the code which strobes the write: ;; synchronize with rising edge of SID clock to avoid setup or hold violation ;; note: due to pipeline effects, the "bcf" will be executed 3 instruction cycles after ;; the polling loop. Therefore we are waiting for the falling edge btfss PORTC, 2; wait for falling clock edge bra $-2 btfsc PORTC, 2 bra $-2 bcf SID_SR_LAT_WR, SID_SR_PIN_WR ; enable write (MBHP_SID: chip select) bra $+2 ; to ensure compatibility with on-board oscillator, bra $+2 ; wait for 1.2 uS (> one SID clock cycle) bra $+2 bra $+2 bra $+2 bra $+2 bsf SID_SR_LAT_WR, SID_SR_PIN_WR ; disable write (MBHP_SID: chip select) [/code] It depends on how the address/data bus is connected to the SID(s). I don't know which method you are using exactly, therefore I cannot answer this question. Best Regards, Thorsten.

We often use this tag in the admin section ;) Best Regards, Thorsten.

This was the case in an early firmware version, but I found out, that the clock phase has to be considered when writing into SID registers to avoid unintended OSC gate triggers. So far I remember, I descriped the failure scenario in the article where you found the image The firmware reads the PWM pin, and waits until it is 1, thereafter it waits until it is 0. This synchronizes the firmware to a falling edge of the SID clock. The range marked with "pipeline delay" means, that I've considered, that the input pin of the PIC goes through two internal FF stages (see datasheet), which adds a delay of 200 nS (if PIC is clocked at 40 MHz) The routine ensures that: - CS# is set to 0 before the rising edge of the SID clock to avoid a setup/hold violation - data is registered only once during a falling edge of the SID clock - CS# is set back to 1 after the next rising edge of the SID clock to avoid a setup/hold violation (again) Best Regards, Thorsten.