TK.

Hi Steve, I can confirm this - the byte count always corresponds with the "bytes per packet" definition, which has been made in the OUT endpoint descriptor. I guess that the actual package size is full under control of the USB host, so it might be a windows specific issue. I believe that the unused buffer area will always be patted with 0x00, because I never noticed something else (e.g. artefacts from previous transfers) In my own class driver, zero packages will be simply ignored: ; -------------------------------------------------------------------------- ; IN: expecting pointer to Tx packet in FSR2 ; OUT: request retry if ZERO flag set! USBCLS_MIDISend movf INDF2, W ; ignore zero packages andlw 0x0f bnz USBCLS_MIDISend_Ok [/code] However, I see the point, that it makes CIN=0 packages useless for future extensions. Best Regards, Thorsten.

Hi, the compile procedure has been simplified - we are not using MPASMWIN anymore, but GPASM So, after you installed GPUTILS, just doubleclick on the "make.bat" file, that is part of the release package. More infos: http://www.midibox.org/forum/index.php/topic,10552.0.html http://www.ucapps.de/howto_tools_gpasm.html README.txt of the release package Best Regards, Thorsten.

Could you please try the "testtone" application in the attachment? It should only output a 1kHz wave at the right channel, the left channel should be silent Can you confirm this? Best Regards, Thorsten.

Individual access to the second (right channel) MBHP_SID module is only possible, when the MBHP_SID::J2:SO input is connected to J14 of the core module. See also http://www.ucapps.de/mbhp/mbhp_8xsid_c64_psu_optimized.pdf, green wires Best Regards, Thorsten.

There is a Java based scrambling routine in the MIOS Studio package - but it doesn't descramble. Unfortunately Java is not like e, where you can easily define a bitvector with unlimited length, pack the 8bit value array into this vector, and unpack a 7bit value array from the vector. Thats basically the approach. In "e" a single line of code, in Java/C... hm... perhaps some more. Best Regards, Thorsten.

Since it isn't the first time you forgot to mention such important details, here a reminder: - when reporting an issue, always check it with the latest firmware (currently: RC17) - if you are not able to use the latest firmware for any reason, please mention this in your posting - please describe the effects you've noticed in a way, which makes it easy for somebody to reproduce the issue If it's too difficult in english, just write in the german section, thats ok from my side. Best Regards, Thorsten. RIOFAQMARKER

How did you measure the RC (=LD) line, with a multimeter, or with a scope? Because the RC signal is a very short pulse, which toggles each mS Here the link to the troubleshooting guide: http://www.midibox.org/dokuwiki/din_module?s=dinx4 The srio_interconnection_test allows you to check, if the signals are still available at the 74HC165, or if there are shorts. Also the midio128 check could make sense - just to ensure that there isn't a usage issue with MBCV Best Regards, Thorsten.

Yes, this should be easy to integrate A new version can be expected in ca. 2-3 weeks :) Best Regards, Thorsten.

Works fine at my side, which engine are you using? Best Regards, Thorsten.

P.S.: so long the module is not available, you can control J5 outputs the following way from C: Add ADCON1 = 0x07; TRISA &= 0xd0; TRISE &= 0xf8; to the Init() hook Now you can toggle the pins with PORTAbits.RA0 = ... PORTAbits.RA1 = ... PORTAbits.RA2 = ... PORTAbits.RA3 = ... PORTAbits.RA5 = ... // no typo! RA4 is allocated by IIC PORTEbits.RE0 = ... PORTEbits.RE1 = ... PORTEbits.RE2 = ... Please let me know if it works (it's untested) Best Regards, Thorsten.

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.