TK.

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.

...is now available for download: http://www.ucapps.de/mios_download.html Most of the requested features of the last months (but also my private wishes) have been implemented (hope that the guys are still reading this forum ) -> http://www.ucapps.de/midibox_seq_changelog.html The remaining feature requests can be found at the bottom of CHANGELOG.txt Best Regards, Thorsten. /Edit: uploaded v3_4 again due to another improvement for the MENU button function

It could be a PSU issue - which voltage do you read between Vss/Vdd, and Vss/WC# of each BankStick? Does Vss/Vdd change while the the BankStick is formatted? Best Regards, Thorsten.

Inspirative! :) This is how I protect my GM5x5x5 from dust - I just mounted it under a table: It's well hidden, but still easily accessible w/o moving the table - an ideal solution for prototyping: Best Regards, Thorsten.

Hi Mike, due to resource limitations of the PIC (RAM/Flash/Timers) it's unlikely that I will be able to provide a better quantisation algorithm for MBSEQ V3. It will be a piece of cake for MBSEQ V4 on the STM32, especially because I already adjusted the programming concepts to simplify the implementation of certain feature requests. Best Regards, Thorsten.

We neither connect 5V directly to the SD Card output, nor we ground the pin. The current drain through the 10k pull-device is (only) ca. 0.5 mA when SD Output=0V, ca. 0.17 mA when SD Output=3.3V, and 0A when SD output in tristate (CS not enabled). I'm writing approximated values, as the voltage level at SD output won't be exactly 3.3V, but a bit higher caused by the pull-up resistor and the output impedance - which is advantageous! Because it shifts the voltage level much higher than PIC's Vih_max=3.0V (@5V supply) - as an effect, faster transfers are possible. If you would use a pull-down, the effective high level could be lower than 3V, the slope on signal changes would be weak, etc... -> slower transfer rates Best Regards, Thorsten.

Maybe an understanding problem: If the SD Card is not connected (not plugged into a SD Card slot), the core should read a static value. It doesn't really matter the core reads 1 or 0 - 1 is the best choice, as the pull-up is already available and accordingly no changes are required on the core module. If you notice a problem with this design measure, please let me know - it works fine at my side :) From your questions I suppose, that SD Card accesses are not working? Or why do you post this in the Troubleshooting section? Could you please describe your observations more concretely? Best Regards, Thorsten.

Block reads < 512 bytes should always work if the CS line is deactivated after the transfer. If you store 64 bytes payload in each 512 byte sector, there shouldn't be a speed disadvantage (in distance: access times are still higher) For writes operations 512 bytes have to be transfered, though. But programming a 512 byte sector is still faster than programming a 64 byte page of a BankStick Best Regards, Thorsten.

Just check the opcodes in the listing (project.lst): SDCARD_1uS_Delay 003ae8 d000 bra 0x3aea bra $+2 003aea d000 bra 0x3aec bra $+2 003aec d000 bra 0x3aee bra $+2 003aee d000 bra 0x3af0 bra $+2 003af0 d000 bra 0x3af2 bra $+2 [/code] Offset is 0 -> PC will jump to +2 location If the assembler would handle labels the way you explained, you would have to write "rcall SDCARD_1uS_Delay-2" instead of "rcall SDCARD_1uS_Delay" Btw.: I changed the function name. Oh - and before you are speculating about delays even more: in fact, calling the 1uS delay function will consume more than 10 cycles, since the call itself + the return instruction will cost +3 cycles (so far I remember) Hope that you don't mind, that I don't change this - it doesn't hurt to clock the SD card a bit slower after power on Best Regards, Thorsten.

It looks like a software issue, but I've no explanation under which circumstances it could fail this way. Ok, only assumption: somewhere MIOS_BOX_CFG0 is overwritten - but I should notice this on my MBLC as well Best Regards, Thorsten.

Note that I'm using a LM317 based voltage regulator to supply the SD card (same circuit as for the MBHP_USB module). Also a LF33 could be used (same circuit as for the MBHP_CORE_STM32 module) to ensure stable power supply. The diode circuit could work at your side (as it worked for Ilmenator), but there is no guarantee I haven't removed this resistor to ensure that the core will read static-1 if no SD card is connected. Yes - with higher resistor values the level conversion will get unstable depending on the input impedance SD card. Best Regards, Thorsten.

What happens if LC_STAT, LC_STAT_GLCD is explicitely set? (just remove btfsc instruction and build a new .hex file) Best Regards, Thorsten.

Thats really strange - MBLC should switch to GLCD mode if the LCD driver notifies that this capability is available: Inside USER_Init (-> main.asm) ;; use LC_STAT.LC_STAT_GLCD as indicator if graphical LCD ;; or character LCD is connected bcf LC_STAT, LC_STAT_GLCD btfsc MIOS_BOX_CFG0, MIOS_BOX_CFG0_USE_GLCD bsf LC_STAT, LC_STAT_GLCD [/code] Accordingly no source code or setup change is required, it should work with the prebuilt .hex files. Especially with setup_midibox_tk.hex, as this is the file I'm using for my own MBLC - when you apply a diff over the setup_*.asm files, you will notice that the only difference is the default value of "TOUCH_SENSOR_MODE"... So - please don't change the source code. Remove your changes (or rename the directory), and start with the original release. Could it be, that you are trying an expired release package which doesn't provide this "GLCD selfdetection" mechanism? And are you using the original pic18f452/midi/mios_v1_9f_pic18f452.hex file, or did you build (and modify) MIOS by yourself? Best Regards, Thorsten.

http://www.midibox.org/forum/index.php/topic,10421.msg78755.html#msg78755

It's my intention to give the new mode a cheesy name! For the case that you haven't noticed it yet: the name "Super-Poly" was already a joke... You can call it SDP mode if you don't like this kind of humor ;) Best Regards, Thorsten.

I already fixed these bugs, the new code is in the repository (see comments in the logs) and will be released very soon. However, there are still situations where the SIDs can go out of sync, e.g. if a huge bulk of SysEx data is received in parallel to MIDI notes (a MIDI IN buffer overrun will happen). A different, more complicated concept is required to solve this failsave (centralised voice assignments handled via CAN). I'm not sure if I will implement this for the PIC based solution, or if it will be only available for a future STM32 based solution (where I'm planning a Super-Duper-Poly Mode with 8 individual voices :)) Best Regards, Thorsten.