TK.

Please update the diagrams later - they are great, and they are definitely useful for newbies! :) Best Regards, Thorsten. P.S.: I hope, that after the upcoming changes no additional changes have to be expected anymore

Should work again Best Regards, Thorsten.

Once the SVN server is up&running, a modular structure will be available where code modules can be easily shared between projects. So - once it is available, I will program a relocatable j5_dout module for you, that should be easily integratable. Best Regards, Thorsten.

This topic has been moved to MIDIbox of the Week. [iurl]http://www.midibox.org/forum/index.php?topic=9808.0[/iurl]

This topic has been moved to MIDIbox of the Week. [iurl]http://www.midibox.org/forum/index.php?topic=10585.0[/iurl]

I would recomment the usage of SSM2044 instead of CEM chips (we had some discussions about this topic many times, use the forum search function) Seppoman has created a nice PCB for stereo configuration, which will be available soon. :) Best Regards, Thorsten.

The direct execution of "gpasm" is not recommented, instead just type "make" to process the Makefile. There are some applications, which got additional parameters in this file. Another point is, that I'm planning to change the file structure of applications soon (uniformed structure, hostet on a SVN server, include files like "mios.h" or "mios_vectors.inc" won't be located in the application main directory anymore) So, please wait a little bit with such docs, they will be expired once the update has been done. Best Regards, Thorsten.

So, you don't want to sell it, right? In such cases, it isn't required to ask me in the Sale Requests section of the forum. Best Regards, Thorsten.

No, this kind of scrambling isn't used by MIOS, instead the bits are packed without de-positioning. You will find two useful perl scripts, which include the algorithms, in the MIOS source code package under tools/hex2syx.pl and tools/syx2asm.pl Best Regards, Thorsten.

Hi NAS, It was my assumption as you wrote this: I've following proposal: - I would grant permission to use the MIOS bootloader for their project. This would allow everybody to upload the original HyperSID firmware into a MIDIbox via MIDI, but it would also be an advantage for people who built the original HyperSID hardware (no PIC programmer required for updates) - I would give them the routine which allows to access MBHP_SID This would increase the number of potential users for the Plug-In dramatically. In return I would like to know the CC implementation, so that I'm able to integrate a compatibility mode into the MBSID firmware without re-engineering the plug-in Best Regards, Thorsten.

NAS: would anybody be "pissed off" if I would build a CC mapping function into MBSID, which allows to control it from the HyperSID plug-in? Or is it licensed for exclusive use with the HyperSID hardware only? Can you provide a link to the forum article? Best Regards, Thorsten.

The preset (which is stored in internal EEPROM) should have all instruments pre-assigned to individual notes. I don't remember them exactly... but you could use the JSynthLib based MBFM editor to visualize (and change) them. You can also change them on the Control Surface (if already available) Best Regards, Thorsten.

Meanwhile I understand what you are trying to do. I must admit, that I was focused on the code you posted, and not on your intention. The scale_7bit() function only scales down, but you want to scale up... here the "mulwf" trick (which is extremely performant, but hard to understand if you don't know how the assembler instruction is working) won't work. Audiocommander has an nice example for scaling up in his http://www.midibox.org/dokuwiki/acsensorizer_04 application (see also the comment at the end of this page) On the other hand: 75-43 means a value range of a little bit more than 32 (in 7bit range; in 10bit range: 256) You might think "cool, 0..255 is 8bit value range, so I can scale down again" - but the other side of the story is, that you will have to reduce the AIN deadband as well, and therefore notice additional jitter if the cables are not short enough, and if you are not using a high-quality pot. It's like a reduced dynamic range in audio world: you will notice a lot of noise, therefore try to make it "louder". Maybe a small transistor based amplifier after the pot could help Best Regards, Thorsten.

Hallo Christian, die Diode ist notwendig, ansonsten werden sporatisch CAN Uebertragungsfehler angezeigt, wenn der Master versucht, auf einen (nicht angeschlossenen) Slave zuzugreifen. Es ist wichtig, dass er sich dabei "selbst hoert" (deshalb die Rueckkopplung Tx->Rx) Gruss, Thorsten.

Thanks for the input, Mike - I added the link to the GPASM page. The remaining assembly based applications have been re-released now: j5_din_v1_3a.zip j5_dout_v1_3c.zip jitter_mon_v1_3a.zip lcd7_clcd_v1_9a.zip lcd7_iic_v1_9a.zip lcd7_ks0108_v1_9a.zip lcd7_pcd8544_v1_9a.zip lcd7_t6963c_h_v1_9a.zip lcd7_t6963c_v_v1_9a.zip lcd_benchmark_v1a.zip lcd_interconnection_test_v1a.zip led_digits1_v1_3a.zip led_digits2_v1_3a.zip led_digits_clk_v1_3a.zip led_digits_mtc_v1_3a.zip mbfm_interconnection_test_v1a.zip mbfm_testtone_v1a.zip mbsid_interconnection_test_v1a.zip mbsid_led_matrix_test_v1a.zip mbsid_testtone_v3a.zip mf_calibration_v1_4a.zip mf_direct_control_v1_1a.zip revision_id_v1a.zip sm_example1_v2a.zip sm_example2_v1a.zip srio_interconnection_test_v1a.zip And there is a new MBSEQ V3 version with a fix for J5 gate outputs, and support for AOUT_NG module: midibox_seq_v3_2c.zip Best Regards, Thorsten.

You don't really know what is going on, hm? GPUTILS is a 470k package and easier to install than MPLAB. Yes, you can still use MPASM, some files have to be converted so that they contain the DOS style linefeeds again. You also need to specify the target processor explicitely now, and sometimes you have to add an include path. If you don't know how to do this, just click on this link: https://sourceforge.net/project/showfiles.php?group_id=41924, and download the gputils-win32 package. It really doesn't hurt! Best Regards, Thorsten.

It remembers me on HardSID, but there is only one SID, the ready-built hardware is more expensive. Compared to MBSID you will mainly miss the polyphony, dedicated sound engines, modulation capabilities, wavetables, arpeggiators, live-sequencers, etc... etc... From the feature list: these are the SID internal functions, you will find them on any SID based synth Only two LFOs? Interesting, 2 ENVs I see 4 modulation sources Fits nice into the CC range Natively supported by the VST host Nice starting point Means: the filter is not self-oscillating. How about an automatic real time synchronisation between human and hardware? As workaround for PC based Logic Audio Thats the killer argument today! Sorry, couldn't resist ;) Just compare with the MBSID feature list, and consider that HyperSID is based on exactly the same hardware as MBSID V1! So, there is even no cost advantage. And we have a VST plugin as well: http://www.midibox.org/forum/index.php/topic,5116.0.html, so where is the innovation? Best Regards, Thorsten.

Fine that you solved this! :) Could it be, that he supply voltage of the PIC is not clean enough? (is there a big el-cap between 5V and ground?) Because a cap between +5V and Rx input normaly "worsens" the signal Best Regards, Thorsten.

Yes, the appr. label is named "MIDI_EVNT_Send_Int" Best Regards, Thorsten.

Ooops! Thanks for the input, it's a programming error in j5_dout.inc You need to replace ;; disable the ADC which allocates the analog pins movlw 0x07 movwf ADCON1 [/code] by: [code] ;; disable the ADC which allocates the analog pins #if PIC_DERIVATIVE_NEW_ADC == 0 ; PIC18F452 movlw 0x07 #else movlw 0x0f ; all newer PIC18F derivatives (like PIC18F4685) #endif movwf ADCON1 It will be fixed in the next release Best Regards, Thorsten.

So, you tried it but it doesn't work? I think that this code is ok. It's simple math: scaled_value = (min + (unscaled_value*2 * (max-min+1))) / 256; Best Regards, Thorsten.

Ok, conversion for these particular applications already done: http://www.ucapps.de/mios/sm_example1_v2a.zip http://www.ucapps.de/mios/sm_example2_v1a.zip Best Regards, Thorsten.

You don't need to do this, Stryd - I'm planning an official re-release of these applications as well - very soon (not today, as I got too many emails due to other issues... :-/) Best Regards, Thorsten.

Thats very difficult, because the 3 bits which are reserved for MIDI ports are already allocated: ;; o WREG == 0: Default port (depends in MIOS Interface Definition) ;; o WREG == 1: Internal port ;; o WREG == 2..5: IIC0..IIC3 ;; o WREG == 6: Loopback to Sequencer MIDI Engine ;; o WREG == 7: AOUT [/code] you would need to restructure a lot of things - it isn't really worth the effort. Maybe it would be easier to (mis-)use an existing port instead, e.g. IIC4 (if no 4th IIC module is connected) Thank you for the nice words! :) Best Regards, Thorsten.

You can use PortB as input when the appr. TRISB flags are set (Tristate driver - means: pin is not driving) However, the best choice for output pins which are not used by any other resources are RC0, RC1 and RC3. The best choice for an input pin which is not used by any other resource is RC2 (it already has an pull-up, which is perfect to prevent random values if the pin is open) By using these pins, you don't need to modify the TRISx configuration, just use (for example) PORTCbits.RC0 = 1; to set the pin to 5V, and PORTCbits.RC0 = 0; to set the pin to 0V Same for RC1: PORTCbits.RC1 = 1; // 5V PORTCbits.RC1 = 0; // 0V And don't touch anything related to the LCD Port B Hope that this answers your question? Or do you need even more input/output pins? There are special solutions for J5 and LCD port, but they require additional configuration... and you need to warn the end-users to disconnect the LCD, or disconnect pots (of J5 used as output) to prevent short-circuits. Best Regards, Thorsten.