TK.

No, this cannot be "fixed". Displaying realtime informations from the slaves would produce too much CAN bus traffic. Best Regards, Thorsten.

Congrats! Great Achievement! :) Best Regards, Thorsten.

This will result into the problem, that the IIC specs will be violated for all other IIC slaves connected to the bus. Not only that it wouldn't be possible to access them anymore if the switch is enabled, it could also result into corrupted data transfers if your device is accessed faster than 400 kHz while other slaves should be in passive state (e.g., because they cannot read their address fast enough, and could unintentionally assume, that they have to drive the bus) Accordingly, I strongly recomment you to provide separate functions at module basis, and to use the IIC pins only optionally. In your specific case it could make sense, for other applications it's a killer, as other IIC slaves (especially MBHP_IIC_MIDI) cannot be used in parallel. Best Regards, Thorsten.

Hi, you are trying to upload a MBSID V1 bank - this won't work. The same patches (with stereo support and some additional bassline/drum patches) are part of the MBSID V2 release package. You will find it under presets/v2_vintage_bank.syx Best Regards, Thorsten.

A new MIOS Studio version is available which got a lot of improvements to improve the robustness. -> http://www.ucapps.de/mios_download.html E.g., there was an error in the retry handling which corrupted the flash content under special circumstances. Accordingly, everybody is strongly recommented to use this new version to avoid, that MIOS or even the 1st level bootloader has to be installed again after a failing application upload. Best Regards, Thorsten.

Dito - hope your MP3 player isn't affected by the Z2k bug ;) http://forums.zune.net/403986/ShowPost.aspx Best Regards, Thorsten.

the linker will locate udata sections into BANKED area, and udata_acs sections into ACCESS area Btw.: this seems to be a bug in the mod_skel example, as it locates variables into the udata section w/o taken care of the BSR Short answer: In earlier derivatives like PIC16xx and PIC18F452, RA4 was only available as open drain pin due to compatibilty reasons. All other pins are working in Push Pull Mode Please ask Microchip support for the reasons ;) But this isn't an issue in your particular case (therefore just ignore the comment in the BankStick driver...) You don't use RA4, and if you would need open drain capabilities, you could control this via SW by setting LATx.y to 0 and toggling TRISx.y instead of LATx.y Best Regards, Thorsten.

The mod_skel example is provided by StrydOne, so I can only speak for my SD card driver: In order to allow highest flexibility, I used "movff" here, so that it doesn't matter if _sdcard_address is located in the ACCESS bank or not. I could also set the BSR before doing an "movwf", but prefered movff here (balancing question, mostly subjective and decided within 2 seconds, so please don't ask which method is better ;) In general, using the ACCESS bank speeds up the code, but it also reduces available directly accessible memory (e.g. for temporal variables) - therefore it's expensive and should only be used if it really makes sense. no, but if you would have to set the BSR before transfering the the value into the register, it would result into 2*16 bit/2 cycles as well. In addition, it would destroy the current content of BSR, and it would lead to two code lines instead of one. If destroying the BSR is no issue, I usually decide to use either SET_BSR/movwf ...BANKED or movff depending on the lunar calendar ;) If you are asking for the best solution: allow to locate your variables into the BANKED area so long the functions are taking more than 10 uS execution time (so that one or more additional cycles don't really matter). If more than one BANKED register is accessed and BSR doesn't need to be restored, change the BSR instead of using movff Best Regards, Thorsten.

Hi Braintu, the original schematic is located here: http://svnmios.midibox.org/listing.php?repname=svn.mios&path=%2Ftrunk%2Fschematics%2Fclockbox%2F It has to be edited with xcircuit Best Regards, Thorsten.

Sorry - wrong movie ;) MBCV uses it's own initialisation routine for J5, I still haven't changed it to j5_io.inc Means: for proper initialisation, it's required to change ;; disable the ADC which allocates the analog pins movlw 0x07 movwf ADCON1 [/code] to [code] movlw 0x0f ; all newer PIC18F derivatives (like PIC18F4685) movwf ADCON1 in j5_dout.inc (this change won't be required anymore once I'm using j5_io module in MBCV) Best Regards, Thorsten.

There was an incompatibility to PIC18F4685, caused by direct accesses to the GATES variable, which is located in a range which is reserved for CAN on this special derivative. I fixed this in cv_map.inc Best Regards, Thorsten.

According to my records, I sent you the small parcel on 21th november, more than one month ago. If you don't get it in the next 3 weeks, please write me a PM and we will try to solve this Best Regards, Thorsten.

Drivers are called "modules" PIC based MIOS: (see this directory) it doesn't matter if you program them in C or assembly. I prefer assembly to achieve best performance on the PIC MIOS32: (see this directory) only C to improve portability Best Regards, Thorsten.

You are using MIOS Studio to upload MIOS and the MIDIO128 application (both provided as .hex file) This is like you are installing Windows and any other program, which gets use of Windows functions After installation you will already be able to control DIN and DOUT pins with predefined Note and CC events, they are matching with the MIDI events predefined under tools/mk_midio128_syx/midio128.ini If you want to change predefined events *after installation* of MIDIO128, just follow the instructions under tools/mk_midio128_syx/README.txt The described approach allows you to customize the events w/o creating a new .hex file and installing the MIDIO128 application again. If you prefer to modify the program directly, edit src/midio_presets.inc, build a new .hex file (your own MIDIO128 variant) and upload it with MIOS Studio Sorry for all the confusion, but I tried to provide a simple and more flexible approach - it seems that this only leads to unnecessary complexity Best Regards, Thorsten.

If you find the location and calculate a new checksum for the appr. line, it could work - but it's error prone. For details, how to build a new .hex file, see http://www.midibox.org/dokuwiki/application_development However, I re-uploaded the .zip package with changed version number. Best Regards, Thorsten.

Yes, version number isn't incremented this time Some precompiled setups are part of this package: o setup_6581.hex (MBSID stuffed with 6581) o setup_8580.hex (MBSID stuffed with 8580) o setup_tk.hex (TK's Setup) o setup_mb6582.hex (MB-6582 Setup)[/code] To check the difference, type: diff setup_8580.asm setup_mb6582.asm Best Regards, Thorsten.

sure - do you expect a changelog entry for such minor fixes? ;) Best Regards, Thorsten.

During a play session I noticed, that F1 button behaviour is currently inconsistent to the overworked F3/F4. Questions to users: would it be ok for you if F1 button behaves like the new F3/F4 button function in future: Utility page only visible so long F1 button pressed, and jump back to previous page when F1 button is released? Or is it important for you, that only one finger (instead of two) is required to select a utility function? Best Regards, Thorsten.

testing robustness of MIOS32 by writing different example applications and drivers implementing USB/MIDI Bootloader for STM32 releasing virtual MBSEQ for MacOS implementing MBSEQ V4 writing documentation about new hardware and programming concepts teasing you with the new features public rollout of MBHP_CORE_STM32 module starting with MIOS32 based MBSID V3 and MBFM V2 emulating MBSID by coupling it with resid making music

Songs created after a break are mostly the best - have a nice vacation! :) Best Regards, Thorsten.

Sollte es nicht, solange Du die 1k Pull-Up Widerstaende R2 und R12 nicht vergessen hast? Ansonsten koennte sich die Applikation auch aufhaengen (und darauf deutet die Meldung hin), wenn Pin #17 (verfuegbar an J7:SO und J10:PWM) kurzgeschlossen ist. Gruss, Thorsten.

Alright, this relaxes the situation - chips won't be fried by lower voltages, but of course - the EEPROMs won't work properly. So - now you should know where to search for the issue? Best Regards, Thorsten.

Mehr details bitte - mit diesen Angaben kann Dir niemand helfen. Es gibt keine "loading cs" meldung, was meinst Du damit genau? Welches setup_*.hex File hast Du ausprobiert? Und hat es mit einer aelteren Version schonmal funktioniert? Gruss, Thorsten.

Wow, 5.8V? This is out of spec, it doesn't wonder me why the EEPROMs are not working stable (hopefully you haven't fried them...) You should read ca. 5V +/- 0.1V Please remove all ICs from the sockets (including PIC and SIDs) and check your PSU! Best Regards, Thorsten.

RC26 is available now. It contains some improvements for Super Poly mode and SysEx distribution via CAN Best Regards, Thorsten.