TK.

In order to understand the schematic better, I have to ask a question first: why did you pull Rx to low-level (Vss)? The SN75176 is powered by the Tx line - if a frame is transmitted by the PIC, the chip will loose power, Rx will "see" Vss, and the UART will detect a start bit. Accordingly RCIF will be set after short time. Probably RCSTA.FERR will be set as well (frame error) if Rx pin is not in idle state during stop bit phase. Best Regards, Thorsten.

Instead of military service, I served in a school for physically handicapped pupils. Beside of some supporting jobs, I gave computer and music lessons. I also developed some dedicated sensors for replacing a mouse or computer keyboard, etc - was really a great time, that I don't want to miss. So, thats really a contrast to military service ;) Best Regards, Thorsten.

The problem is, that the Wiki configuration tool doesn't display the access group name. So, instead of comfortably enabling "Delete" permission for "Frequent Writer" group, I get "Group 1", "Group 2", "Group 3", ... "Group 9" presented, and can only make a guess if you are in the appr. group or not... I changed this now for "Group 9" - please check. If it doesn't work, we need to test other groups. Best Regards, Thorsten.

You could use the 4x16 Button/Duo-LED application: http://www.midibox.org/forum/index.php/topic,10476.0.html It's designed for much more control elements, but nothing prevents you from connecting a smaller button matrix (even without LEDs) Best Regards, Thorsten.

This is a programming example for sending data over IIC: http://www.ucapps.de/cmios_fun.html#MIOS_IIC_ByteSend The IIC slaves have to be connected to J4 of the core module Best Regards, Thorsten.

A Tap-Tempo function is planned for MB808, the same routine will be integrated into MBSEQ later Best Regards, Thorsten.

yes yes - you can use it in an original C64 as well, it should even work with other SID synths like HardSID I cancled this quick idea, and designed the firmware for 4 stereo pairs only. You could use two MBSID stuffed with 16 SIDs - it would require two control surfaces, and multi poly wouldn't work over two boxes. However, do you really think that you need so many SIDs? Just waiting for the guy who demands for a 32 SID option, but only to have some soldering fun instead of making music. And the next guy, who thinks that 64 SIDs would be even more cool, because he likes the supersaw sound ;) Best Regards, Thorsten.

The HardSID synth engine runs only on a PC, and not inside the HardSID device - so thats how the "MIDI/Audio chain" would look like: [pre]Mac ~~~~ USB/Firewire/Card -> MIDI Out -> MIDI In -> USB/Firewire/Card ~~~~ PC ~~~~ VST Host ~~~~ VSTi ~~~~ USB ~~~~ HardSID -> Audio Out -> Audio In ~~~~ Mac [/pre] You can consider, that each "~~~~" adds a delay (no issue, can be compensated), but also Jitter (very ugly, cannot be compensated) For comparison: the MIDI/Audio chain of MBSID: [pre]Mac ~~~~ USB/Firewire/Card -> MIDI Out -> MIDI In ~ MIDIbox SID -> Audio Out -> Audio In ~~~~ Mac [/pre] Note that the effective Jitter/Delay can be easily measured with a scope the following way: periodically play a short test tone from the Mac through a soundcard, and another with the SID. Compare the offset and the jitter between the two waveforms. Alternatively you can use the record function of your DAW (but delay measurement wouldn't work reliable enough, if there is an inbuilt latency compensation - however, you should be able to measure the jitter) Best Regards, Thorsten.

Hallo Tobsen, wie lang sind eigentlich die Kabel zu (und zwischen) den einzelnen Modulen? Encoder-Problem: hast Du schonmal einen zusaetzlichen R+C am Ende der DIN-Kette ausprobiert? Gruss, Thorsten. P.S.: weitere Erfahrungsberichte wuerden mich sehr interessieren

Yes, according to http://www.ucapps.de/midibox_sid_manual_up.html you only need to add the additional 1k pull-up resistor (R12) Best Regards, Thorsten.

HardSID is cool, yeah! It provides many features which can never been realized with a MIDIbox SID, especially now where the update rate has been dramatically increased. But from the concept point of view, there aren't big changes compared to the previous HardSID versions, therefore I'm a little bit surprised about the hype around this product update. you still need a PC to access the SIDs (I guess that the main reason, why they provide a USB version now is, that many musicians are working with notebooks meanwhile). the device itself is "stupid", it relies on the host software which is handling the "synth engine". too bad, if the soft- or hardware is not working anymore on future Windows versions, and the company discontinues support software runs on Windows only, no Linux or MacOS support even if the Linux community starts to develop a driver like they did for HardSID PCI: it will only play .sid tunes, or maybe give you simple MIDI access to SID registers - but thats all (developing a performant engine can take years) SID audio outputs are still not sampled internally, you still need a soundcard to feedback the audio to your PC (don't expect an integration like known from Virus TI) - so, all they did was replacing PCI by USB we all know, that USB is not good for audio, no? ;) no hardware control surface - beside of the real SID sound, you won't notice a big difference between a SID emulation and the HardSID. You are totally focused on your computer (mouse/keyboard), and no generic MIDI controller can ever give you the same human-machine interaction like a real SID synth no support for analog extensions (e.g. analog filters) - seems that this is still one of many unique features of MBSID :) Not that I will be mistaken again (like on my statements about HyperSID some days ago) - I'm writing about my first impressions. There is definitely no "MBSID + the rest of the world" fight, or any need to drag down other projects. Every SID solution has its advantages and disadvantages, and it's good (and a little bit surprising) that still so many developers are working on different approaches. :) Best Regards, Thorsten.

Hi Scube, shortest Pot/Fader conversion latency was always in focus during MIOS development. Basically analog inputs are converted faster than events can be transmitted via MIDI. There is a "dynamic priority" feature, which converts the two last moved faders/pots more often than the others; this improves latency even more. So, you can expect a latency of ca. 1 mS (or 640 uS if the application gets use of the "running status" feature) on the two last moved pots/faders. And this is caused by the transmission time of a MIDI event. If you move more faders the same time, it mainly depends on the number of scanned analog inputs, but even in worst case (64 pots) the latency isn't higher than 12 mS, which you won't really notice, as the transmission of 64 MIDI events takes ca. 64 mS... My tip: open the UC-33E case, and replace the microcontroller board by a MBHP_CORE :) Best Regards, Thorsten.

:)

The perl script mk_midio128_syx.pl converts a MIDIO128 .ini file into a .syx (SysEx) file which can be transfered to the Device via MIDI-OX or any other SysEx Loader -------------------------------------------------------------------------------- Step by Step ~~~~~~~~~~~~ -> customize the .ini file for your needs -> start the script -> transfer the .syx file to your MIDIO128 How to start the script? ~~~~~~~~~~~~~~~~~~~~~~~~ o UNIX Perl comes with the most UNIX systems like Linux, BSD, Solaris, ... - if you own such an OS, just start the script with (example) ./mk_midio128_syx.pl midio128.ini -> the resulting syx file is named "midio128.syx" o DOS/Windows Users should install ActivePerl, which is available at the following site: http://aspn.activestate.com/ASPN/Downloads/ActivePerl/index/ Get the .msi package and follow the installation instructions (Win98 users have to install the Microsoft Windows Install 1.1+, too) To start the script just open a command window and type (i.e.) perl mk_midio128_syx.pl midio128.ini -> the resulting syx file is named "midio128.syx"

It was (and is) just simply love! :) Best Regards, Thorsten.

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.