TK.

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.

Seems that the DIN is not working Link to the troubleshooting guide: http://www.midibox.org/dokuwiki/din_module Best Regards, Thorsten.

I think, it's a great idea to try it with a PIC24F, it's especially a nice learning project. And I must say, that I still prefer external merging and routing (in my case: with the MIDIbox Router) for the same reasons like you. Routing through a computer would add some additional latency and especially unwanted jitter. Best Regards, Thorsten.

Only difference between V2 and V3 is, that V3 supports a Start/Stop signal. What happens, if this signal is not connected (Pin RC1)? Best Regards, Thorsten.

It's still unclear to me, how your frontpanel(s) will look like, therefore it's hard to say, if two sets of groups buttons could really be useful for your design. Best Regards, Thorsten.

If ADCON1.PCFG is set to 0xd instead of 0x6 (see PIC18F4685 datasheet), this should work. But I don't know, how much additional noise will be added to the analog inputs - the pots could start to jitter. Best Regards, Thorsten.

No, MBHP_IIC_MIDI is no option, as this module is not supported by the firmware. It is possible to connect the USB IOs directly to the core module (Port J11), but for a synth this isn't recommented, as this will result into a ground loop between the Audio and USB lines. Instead, I would isolate the MIDI INs with optocouplers, and don't connect the grounds together - as usual Best Regards, Thorsten.

Ok - but this is just the lead engine! Left and right channel settings can be edited indidually, you only need to decide by yourself, how to partitionate the available LFOs and ENVs. Merge the two audio channels, and you are done. I assumed, that you are asking for something more advanced - and the answer is: explore the multi engine in conjunction with some clever ensemble settings ;) Best Regards, Thorsten. P.S.: for the case that this hint is hidden in the user manual too well enough: press SHIFT+Select button #1 in order to edit sound parameters of both channels, L or R only (3 options are available: LR, L-, -R)

As you already noticed, the old programming examples are obsolete. The usage of up to 8 pots (or 4 joysticks) is natively supported by the V2 CS; each pot can be assigned to two parameters with a definable min/max range. The information is stored in a patch, which means: for each patch you can optimize the parameter mapping and range for best live usage. Unfortunately, your exact usecase isn't natively supported. There isn't a button which allows you to switch between parameter sets (this would be difficult to realize with the current code, too many places which need to be changed), but maybe you like the already implemented solution much more? Parameter assignments can be easily changed in the Knobs menu. Best Regards, Thorsten.

This can be done with the Multi Engine. It gives you individual access to the 6 voices, and when you disable Poly mode and assign the voices to specific oscillators, you can create very complex layer sounds (more complex than with the lead engine, as each voice has it's own LFO/ENV). Or you can assign the voices to different keyboard zones/channels to create C64ish tunes... Best Regards, Thorsten.

Seppoman asked me for a SSM2044 demo, so here it is: -> http://www.ucapps.de/mp3/midibox_sid/mbsidv2_bassline_demo4.mp3 This is the first jam session I recorded with Logic8 - not everything is under my control yet (especially the distortions ;)) I especially love the part, where the SSM filter is routed through a guitar amp Fx. It starts at 1:39 :) Best Regards, Thorsten.