TK.

I wrote down a draft spec here: http://www.ucapps.de/midibox_808.html Please let me know, if anything is missing, or if you see additional requirements, before I'm starting with the implementation (it will be started soon :)) Best Regards, Thorsten.

Siehe auch Punkt [11] unter http://www.ucapps.de/midibox_sid_manual_ki.html Im Lead Engine Modus siehst Du also die Output-Werte der Modulationspfade. Du kannst ja mal die Geschwindigkeit der LFOs reduzieren, dann sollte die Funktionsweise eigentlich einleuchten. Die meisten Leute bevorzugen jedoch, das Metering im Lead Modus auszuschalten (so wie ich) - es stoert nur. Nuetzlich ist das Metering eigentlich nur im Drum und Multi-Modus, denn hier wird die automatische Stimmen-Zuweisung visualisiert. Gruss, Thorsten.

Short story (what you can't find in the web): my first attempt for a SID synth and tracker was in the late 80s, the result has been published in the C64 magazine (german). A later version was capable of handling MIDI IO, but due to the high processor load, it wasn't working stable enough, so that I stopped further developments. I purchased an Atari ST from the money that I got for the article, started to focus on MIDI synths, and didn't use my beloved C64 for a long time. In 2002, during some nostalgic hours with the good old C64, I tried some "MIDI slave" applications that I found in the web, but they were not powerful enough - they had limited modulation capabilities, and sometimes skipped notes when CCs are sent in parallel (most likely due to the same reasons I encountered years before). So, I considered to build a new MIDI interface for the C64 with large IO buffers to unload the processor, and to prevent data loss. It followed a simple chain of ideas: if somebody needs to build a microcontroller based extension board to get a stable MIDI connection to the SID, why not controlling the SID from the microcontroller directly in order to get rid of all the C64 related issues? -> The idea for MIDIbox SID was born :) Best Regards, Thorsten.

This topic has been moved to Latest News. [iurl]http://www.midibox.org/forum/index.php?topic=10697.0[/iurl]

Hi Greg, probably you forgot to solder the 1k resistor and 1N4148 diode for CAN interface. This is even required, if no slave is connected. See http://www.ucapps.de/midibox_sid_manual_ki.html, topic 3c) for a schematic On MB6582, there could also be a special jumper for the CAN interface? It's important, that the master core is able to listen to itself! Best Regards, Thorsten.

No, this isn't possible. The synth engines have to be disabled while the "sidplay host" controls the SID Best Regards, Thorsten.

Looks fine! :) Best Regards, Thorsten,.

Yes, it's even possible with MIOS Studio (and this is the recommented solution due to robustness) - most of my MIDIboxes are connected to it, and I change firmwares at least once a week ;) A bidirectional connection (MIDI In/Out passed through router) is required, and the router should get a dedicated MIOS Device ID (I'm using 0x7f). The device ID can be modified with the "change_id" application Best Regards, Thorsten,.

It took me 10 minutes to move your posting to a location where the interesting information doesn't get lost! It took me 10 seconds to convert the macros (converter works only under Linux/MacOS, the result sometimes requires manual editing - therefore it isn't public...) CS_MENU_BUTTON_Row_Inc ;; do nothing if button has been depressed btfsc MIOS_PARAMETER2, 0 return movlw 0x06 cpfsgt CS_MENU_SELECTED_ROW, ACCESS goto CS_MENU_BUTTON_Row_Inc_DoIt clrf CS_MENU_SELECTED_ROW goto CS_MENU_BUTTON_Row_ChangeMenu CS_MENU_BUTTON_Row_Inc_DoIt incf CS_MENU_SELECTED_ROW, F goto CS_MENU_BUTTON_Row_ChangeMenu CS_MENU_BUTTON_Row_Dec ;; do nothing if button has been depressed btfsc MIOS_PARAMETER2, 0 return movlw 0x01 cpfslt CS_MENU_SELECTED_ROW, ACCESS goto CS_MENU_BUTTON_Row_Dec_DoIt movlw 0x07 movwf CS_MENU_SELECTED_ROW goto CS_MENU_BUTTON_Row_ChangeMenu CS_MENU_BUTTON_Row_Dec_DoIt decf CS_MENU_SELECTED_ROW, F goto CS_MENU_BUTTON_Row_ChangeMenu CS_MENU_BUTTON_Row_ChangeMenu ;; update TMP6 for easy menu switching movf CS_MENU_SELECTED_ROW, W call MIOS_HLP_GetBitORMask movwf TMP6 ;; menu display movlw 0x00 ; cursor pos movwf MIOS_PARAMETER1 movlw 0x00 ; page offset movwf MIOS_PARAMETER2 movlw CS_MENU_FIL ; menu structure btfsc TMP6, 0 movlw CS_MENU_OSC btfsc TMP6, 1 movlw CS_MENU_OSC btfsc TMP6, 2 movlw CS_MENU_OSC btfsc TMP6, 3 movlw CS_MENU_ENV btfsc TMP6, 4 movlw CS_MENU_ENV btfsc TMP6, 5 movlw CS_MENU_FIL btfsc TMP6, 6 movlw CS_MENU_LFO GOTO_IFSET TMP6, 7, ACCESS, CS_MENU_BUTTON_DisplayUpdateReq goto CS_MENU_BUTTON_Hlp_MenuChangeOk CS_MENU_BUTTON_MatrixRow_Inc ;; do nothing if button has been depressed btfsc MIOS_PARAMETER2, 0 return ;; just show menu if not already on the LCD movlw CS_MENU_MOD cpfseq CS_MENU, ACCESS rgoto CS_MENU_BUTTON_Hlp_MenuChangeOk movlw 0x00 ; cursor pos movwf MIOS_PARAMETER1 movlw 0x00 ; page offset movwf MIOS_PARAMETER2 movlw CS_MENU_MOD ; menu structure goto CS_MENU_ButtonInc CS_MENU_BUTTON_MatrixRow_Dec ;; do nothing if button has been depressed btfsc MIOS_PARAMETER2, 0 return ;; just show menu if not already on the LCD movlw CS_MENU_MOD cpfseq CS_MENU, ACCESS rgoto CS_MENU_BUTTON_Hlp_MenuChangeOk movlw 0x00 ; cursor pos movwf MIOS_PARAMETER1 movlw 0x00 ; page offset movwf MIOS_PARAMETER2 movlw CS_MENU_MOD ; menu structure goto CS_MENU_ButtonDec ;; ------------------------------------------------------------------ CS_MENU_BUTTON_General1 btfsc MIOS_PARAMETER2, 0 return BRA_IFSET TMP6, 0, ACCESS, CS_MENU_BUTTON_Osc_Sel ;; IFSET TMP6, 1, rgoto ;; IFSET TMP6, 2, rgoto BRA_IFSET TMP6, 3, ACCESS, CS_MENU_BUTTON_Env_Sel ;; IFSET TMP6, 4, rgoto BRA_IFSET TMP6, 5, ACCESS, CS_MENU_BUTTON_Fil_Sel BRA_IFSET TMP6, 6, ACCESS, CS_MENU_BUTTON_LFO_Sel ;; IFSET TMP6, 7, rgoto return CS_MENU_BUTTON_General2 btfsc MIOS_PARAMETER2, 0 return BRA_IFSET TMP6, 0, ACCESS, CS_MENU_BUTTON_Osc_Wav ;; IFSET TMP6, 1, rgoto ;; IFSET TMP6, 2, rgoto BRA_IFSET TMP6, 3, ACCESS, CS_MENU_BUTTON_Env_Curve ;; IFSET TMP6, 4, rgoto BRA_IFSET TMP6, 5, ACCESS, CS_MENU_BUTTON_Fil_Mod BRA_IFSET TMP6, 6, ACCESS, CS_MENU_BUTTON_LFO_Wav ;; IFSET TMP6, 7, rgoto return CS_MENU_BUTTON_General3 btfsc MIOS_PARAMETER2, 0 return BRA_IFSET TMP6, 0, ACCESS, CS_MENU_BUTTON_Osc_RS ;; IFSET TMP6, 1, rgoto ;; IFSET TMP6, 2, rgoto ;; IFSET TMP6, 3, rgoto ;; IFSET TMP6, 4, rgoto ;; IFSET TMP6, 5, rgoto ;; IFSET TMP6, 6, rgoto ;; IFSET TMP6, 7, rgoto return [/code] Best Regards, Thorsten.

Sorry, habe gerade keine Zeit, Deine Fragen im Detail zu beantworten. Ich wollte eigentlich nur mal kurz auskundschaften, ob Du zumindest die grundlegenden Dinge beachtet hast, die unter http://www.ucapps.de/midibox_sid_manual_ki.html beschrieben sind. CAN: vertraue bitte einfach dem Schaltplan. Bei CAN uebertraegt jeder Teilnehmer Daten ueber die gleiche Signalleitung, es gibt eine Kollisionskontrolle, das passt schon. Ohne den Pull-Up haengt sich die Firmware unter Umstaenden auf. Je nach Firmware-Variante kann sich das Verhalten unterscheiden, das schrieb ich ja bereits... mit Pull-Up laeuft sie dann superstabil (CAN ist sehr zuverlaessig, wenn man die Grundregeln beachtet). Du musst keinen Slave anschliessen, damit das LCD laeuft... Bevor nun weiter spekuliert wird: schliesse doch bitte zumindest den Pull-Up und die Diode an, und berichte, wie es dann funktioniert! Wenn das LCD sich dann immer noch seltsam verhaelt, helfe ich Dir natuerlich weiter. Natuerlich unter der Vorraussetzung, dass Du nicht jeden gut gemeinten Tip anzweifelst, sondern mir einfach beschreibst, was sich geaendert hat. Ich muss halt erstmal herausfinden, wie weit Du schon gekommen bist, und welche grundlegenden Dinge noch fehlen, um mir ein genaues Bild ueber das eigentliche Problem zu machen. Wie oft kommt es vor, dass Anwender irgendwelche Effekte voellig falsch interpretieren - da hilft es wirklich nicht weiter, wenn sie sich auf ihre falschen Annahmen versteifen (es macht dann einfach keinen Spass, ihnen zu helfen!) Gruss, Thorsten.

Hast Du die D0..D3 Pins nicht angeschlossen? (Sie duerfen beim PIC18F4685 nicht angeschlossen werden, es wird nur ueber das 4-pin Interface kommuniziert). Ausserdem solltest Du schonmal den Pull-Up und die Diode fuer das CAN Interface anschliessen, ansonsten koennte der Core abstuerzen (und die Wahrscheinlichkeit fuer den Absturz haengt von der verwendeten Firmware Variante ab...) Gruss, Thorsten.

Was passiert, wenn Du das DIN Modul abklemmst? Du musst uebrigens nicht alle 5 Leitungen von Core:J9 abloeten, es reicht Core:J9:DI (Dateneingang) Gruss, Thorsten.

Hi, MIDI Router is a C based application. I guess that you want to indicate the beat based on the received MIDI Clock, right? So, just do the modifications in router.c: hook the code into the ROUTER_Rx_xxx function of the MIDI In Port which receives the MIDI Clock. Add a counter which is incremented on each incoming MIDI clock event (evnt0 == 0xf8) Reset this counter on each incoming MIDI clock start event (evnt0 == 0xfa) or once the counter is >= 24 (-> 24 MIDI clocks = 1 beat) Assumed, that you connect the LED to PIC Pin RC0, you can turn the LED on with PORTCbits.RC0 = 1, and turn it off with PORTCbits.RC0=0 So, turn it on whenever the counter is 0, and turn it off whenever the counter is != 0 Best Regards, Thorsten

you are right! On the other hand: when the encoder is moved, the CS handler will jump into the appr. menu page as well. It isn't a perfect handling for jumping between different menu pages (as values are slightly changed), but in practice it doesn't really hurt (especially because CutOff/Resonance/LFO Depth/Rate are high-resolution values) Best Regards, Thorsten.

Very good work! I should add a special page to the user manual to introduce such layout ideas, because many thoughts went into such designs which should be highlighted. I would prefer such a centered arrangement as well, so that the 5 encoders directly correlate with the displayed values. This would be especially important for the "display" layer. Coding: changes have to be made in cs_menu_enc.inc, cs_menu_enc_table.inc, cs_menu_buttons.inc and cs_menu_leds.inc I would propose to play a little bit with the existing code (e.g. change the order of encoders) to get a feeling about how difficult it is. There is no 1-2-3 documentation available, sorry. Best Regards, Thorsten.

I wrote down my thoughts on the MB808 firmware. Since it's mainly directed to people who already own a MB808 PCB, the discussion is started in the eight-oh-eight forum: http://eight-oh-eight.org/phpbb2/viewtopic.php?p=2047 Note that this application will be useful as low-cost and easy-to-built MIDI drum machine as well! But primary focus is to get the max out of the beautiful MB808 :) (I locked this "link article" to avoid multiple threads about the same topic) Unlocked article, since v1.0 has been reached Best Regards, Thorsten.

The LCD output is controlled by the host (DAW) software. Once it found your "Mackie Control", you should see some meaningful messages. Best Regards, Thorsten.

Bei der MBSEQ sind die Encoder auch so nah beieinander - hier musste ich ebenfalls einen Kompromiss eingehen, und das passt schon irgendwie. Ja, die Laschen bei den Pollin-Gehaeusen sind wirklich aergerlich! :-/ Gruss, Thorsten.

It's really a riddle... Just to get some more hints: could you please do some continuity checks with your multimeter (if it has a "beeper" for such checks, it would be perfect). For such a check, the SID chips and the PIC should be removed from the sockets (not required for the other chips). Don't check on the J15/J10, but put the probers directly into the empty socket holes. - check that the continuity between PIC Pin RD4 and (Right-)SID Pin CS# - thereafter the continuity between PIC Pin RC5 and (Left-)SID Pin CS# Thereafter check that there is no continuity between: - PIC Pin RD4 and ground (Vs) - PIC Pin RD4 and +5V (Vd) - PIC Pin RC5 and ground (Vs) - PIC Pin RC5 and +5V (Vd) - PIC Pin RD4 and RD4 - SID Pin CS#and ground (Vs) (check on both SIDs) - SID Pin CS# and +5V (Vd) (check on both SIDs) - Between the two SID Pin CS# This test should ensure: - that the CS# line is connected correctly (no open wire) - that there are no shorts between PIC and SID Pins against each other or Ground/+5V Best Regards, Thorsten.

In such a case, it wouldn't play any sound at all. The CS# line is triggered whenever a SID register should be changed. No CS# connection -> no register change CS# lines connected to the same output pin of the PIC -> each SID will get the same register changes You mentioned, that with the modified testtone application the volume level is lower. It would be lower, if the audio outputs of both MBHP_SID modules are merged (-> mono), and one SID doesn't play anymore - like in the modified testtone application. Your issue is really strange, I don't have an explanation for this (yet) From where did you get the PCBs? Or is the circuit built on a prototyping board? And just to ensure: did you already check the power supply voltages (0V/5V) at each 74HC595 and the SID? Just to ensure, that they are supplied correctly. If this wouldn't be the case, and if they would get their power from somewhere else (e.g. from the data lines), a lot of strange things could happen ;) Best Regards, Thorsten.

Ok, so now we know that it is probably not a problem at the digital side. Could you please describe, how you are testing the audio outputs? Are they connected to a mixer? Best Regards, Thorsten.

Ok, now a version I tested on my own MBSID testtone_only_r_channel.zip testtone_only_r_channel.zip

Sorry, I overlooked that the CS# lines are low-active Please try the new .hex

I tried different buffer sizes, but finally I decided to use 64 bytes because of following reasons: - in chapter 5.8.3 of USB2 spec it's stated, that "The USB defines the allowable maximum bulk data payload sizes to be only 8, 16, 32, or 64 bytes for full-speed endpoints and 512 bytes for high-speed endpoints" This is a weak requirement, as they don't specify the minimum package size, but to be at the secure side, at least 8 bytes should be prefered as maximum size . 64 bytes are used in the the USB midi spec descriptor example, and it cannot be excluded that any OS gets use of this possibility in order to gain bandwith. So, why reducing the USB slave capabilities? - it cannot be excluded, that the legacy driver wants to send more than one MIDI event package, if it is directed to multiple "midi cables" (= MIDI Out Ports), or if MIDI events are sent to more than one "cable" concurrently for best synchronous timing (e.g. MIDI Clock distributed to multiple devices). Same question: why reducing the USB slave capabilities? Since the transmission of 64 bytes doesn't really hurt (in distance: it could improve performance), I don't see a reason for reducing the EP buffer size Best Regards, Thorsten.

With Java (where memory consumption doesn't matter), you could maybe also do it the following way: convert the decimal value of each 8bit byte into binary strings, and concatenate them one after another to a long, new string. Thereafter split the string into chunks of 7 characters, and convert back binary->decimal to get the 7bit value. Pseudo code: string := "" foreach byte string := string + decimal_to_binary(byte) while lenth(string) && (length(string) >= 7) { SendMIDI(binary_to_decimal(string[0:6])) string := string[7:end] } (this is no official programming language, I only want to demonstrate the algorithm...) Best Regards, Thorsten.