TK.

Ich konnte die Fehlerursache nun an meinem Board reproduzieren: der Effekt tritt bei einem Kurzschluss zwischen dem Rx und Tx Pin auf. Abhilfe: die beiden Rx/Tx Leiterbahnen zwischen J11 und den Pins verfolgen, irgendwo muessen sie miteinander verbunden sein. (die Troubleshooting Guide habe ich um diesen Hinweis erweitert) Gruss, Thorsten.

Cool! I will move this link to the tips&tricks section Best Regards, Thorsten.

Hi Shar, most people who reported problems with the bankstick just forgot to update their hardware to MIOS V1.7 - see also mios_v1_7_hardware_mods.html To which pin did you connect the J4:SC wire? > Will try to replace flash chip with another one. note that this is an EEPROM and not a Flash > How MIOS detects there is no BankStick connected? If there is no response from the EEPROM on a read, it will be assumed that it is not connected. > What sould be checked ? Schematic vs. your board, see http://www.ucapps.de/mbhp/mbhp_core.pdf > I want to increase delay between button pressing. Contact bounce is really annoying. Where should I change the delay value ? Which application are you using? Best Regards, Thorsten.

Hi, the LC app is useless without a full size display. Not sure, maybe the mios_vectors.inc and user_vectors.inc file of the MB64E package are not up-to-date, just copy them from the migration/ directory of MIOS V1.7 into your application directory and build a new .hex file Best Regards, Thorsten.

Funny, I had a similar idea (except for the donation requirements) - a new forum section for sell requests (regardless if somebody wants to sell a box via Ebay, to friends or "customers"), open discussions and an offical "go" from my side, so that it is clear under which conditions I accept this, and under which not. (Please understand that I don't want to discuss all the details here, a) I've currently other things to do, b) this is low-priority, c) this is something which has to be well thought out - no fast-shots!) Best Regards, Thorsten.

RET sounds ok, it's just the short form of REseT I just remember that d2k sent me a 2-segment KS0108 display some time ago which had inverted chip select lines. The effects were very similar - inverted pixels and displaced characters. Therefore I integrated an option into the driver which allows to change the CS polarity, it's bit #0 of option 1 Try the following: open app_init.inc and change following lines: movlw 0x01 ; if 0: non-inverted CS, if 1: inverted CS# movwf MIOS_PARAMETER1 [/code] Thereafter build a new .hex file and upload it with MIOS studio (or hex2syx.pl -> main.syx via MIDI-Ox) If this helps, you can select the same option with the standard GLCD0 driver in MIOS, you only have to add following lines to the USER_Init routine of the application you are using: [code] ;; select LCD type #7 (custom LCD driver, hooks in app_lcd.inc will be used) movlw 0x01 ; if 0: non-inverted CS, if 1: inverted CS# movwf MIOS_PARAMETER1 movlw 0x00 ; here you could forward an additional parameter movwf MIOS_PARAMETER2 movlw 0x01 ; selecting the KS0107/KS0108 driver call MIOS_LCD_TypeSet USER_Init can mostly be found in the main.asm file (the driver example is an exception, maybe I should change this) Best Regards, Thorsten.

Hallo Costa, es liegt wohl an Deinem MIDI Interface (oder doch irgendwie an Windows): der Upload Request kommt wie gewohnt alle 2 Sekunden, der Code Upload funktioniert. Ich habe schonmal MIOS V1.7 aufgespielt, welche Applikation moechtest Du haben? Gruss, Thorsten.

No, in the meantime I think that the best place for the change is propably in seq_core.inc, function SEQ_CORE_Clk_Reference You will find following line: movlw (4*6)-1 ; we are working with 4 times resolution for BPM/2 it must be: movlw (2*4*6)-1 ; we are working with 4 times resolution and BPM/2 so, it's just a IFSET instruction, let's assume that flag 0 of your new register which controls the BPM contains the current state (BPM or BPM/2), then write: movlw (4*6)-1 ; we are working with 4 times resolution IFSET MOXI_REGISTER, 0, movlw (2*4*6)-1 ; we are working with 4 times resolution and BPM/2 Here you also know when a new step will be started (search for "increment step counter"). For a proper synchronization: you need three flags: one which requests a change, one which contains the new state (BPM or BPM/2), one which contains the current state (BPM or BPM/2) So, additional change before ";; increment step counter": ;; handle BPM change request IFCLR MOXI_REGISTER, 2, rgoto SEQ_CORE_Clk_Reference_NoBPMC bcf MOXI_REGISTER, 2 bcf MOXI_REGISTER, 0 btfsc MOXI_REGISTER, 1 bsf MOXI_REGISTER, 0 SEQ_CORE_Clk_Reference_NoBPMC ;; increment step counter Note: if your MOXI_REGISTER is located between 0x100-0x1ff (SEQ_BASE), use BIFSET/BIFCLR instead of IFSET/IFCLR and add BANKED after each register access Note also: I've no idea if this really works, but this was the information I was able to give you within 30 minutes of digging through the code and thinking about possible solutions... Best Regards, Thorsten.

yes! A public release of your project would be very interesting for other people Best Regards, Thorsten.

everything is possible when you know the right places for modifications ;-) You could create a flag which modifies the behaviour of SEQ_EVNT_Transpose (seq_evnt.inc) This is the only function which transposes "notelike" events Best Regards, Thorsten.

I've no idea how to realize something like this so that it can be controlled in an intuitive way In general I fear that there won't be enough code space anymore for such very very individual extensions. Just have a look into the main.lst file, at the end you will find a graphical (ASCII) memory map. The code should not exceed 0x7c00 Even if it seems that there is enough memory free (currently the last instruction is at ca. 0x7a00), keep in mind that I'm planning to complete my TODO list sooner or later. This means, that you possible won't be able to update to a new release. Best Regards, Thorsten.

I hope that you don't wait for an official statement from my side - I won't give it until all consequences are clear. There are background discussions running since some weeks which should clarify the official "terms and conditions" - it isn't really easy to find a solution which help to seperate the "good guys" from the "bad guys" Best Regards, Thorsten.

Isn't there a mechanical way to fix this? However, the software solution is to multiply the value by 2, and the easiest way to realize this is to left-shift the 16bit value which is stored in MIOS_PARAMETER[23] - search for USER_AIN_NotifyChange (which is mostly located in main.asm) and add: USER_AIN_NotifyChange clrc rlf MIOS_PARAMETER2, F rlf MIOS_PARAMETER3, F [/code] this will do the trick. Best Regards, Thorsten.

Hi Weasel, it's not trivial to combine such a large application like MIDIbox64 with C code, I would say it isn't worth the effort. For your project only a very small number of MB64 features are required, it mainly relies on functions which are already provided by MIOS. This means: the easiest solution is to write this from scratch by using the MIOS C wrapper. Just download the C skeleton and SDCC, and start to play with the code. Keep in mind that all functions which are described here: http://www.ucapps.de/mios_fun.html are also available in C, this saves you from reinventing the wheel :) Once you got some experiences how the MIOS concept is working, you will notice that it is very easy to realize your plans (especially when you already have C skills :) Best Regards, Thorsten.

Hi Moxi, it's better to build such a change into seq_bpm.inc You will find a detailed description about how BPM is handled in Master and Slave mode And you will find out that the timer is clocked four times faster than a common MIDI clock tick This means that you only have to divide the multiplier by 2 If you want to switch between normal BPM and BPM/2 during runtime, you have to think about a proper synchronization, so that the frequency won't be switched "at the wrong moment" (e.g. during the second or fourth sub-tick) Best Regards, Thorsten.

For the records: this was the solution

One thing which isn't a problem is the number of CS lines - MIOS tries to access the KS0108 chips seperately and detects automatically how much segments are connected. It seems that the display cursor is not set correctly, but I'm not sure under which circumstances this can happen. Maybe two data lines are swapped? Is the display content always the same, or do you notice random effects? What is the display output when you upload the http://www.ucapps.de/mios/lcd7_ks0108.zip application? (please make a picture) Best Regards, Thorsten.

This is not required, Wise The internal ADC of the PIC doesn't measure the resistance of the pot, but a voltage at the slider ("middle pin"). Regardless if you are using a 1k, 5k or 10k pot, the voltage at the slider is always within the 0V - 5V range, and this is ok for the PIC. Resistances between 1k and 10k are ok. Lower resistances will consume too much power Higher resistances will lead to jittering output values Best Regards, Thorsten.

Hi Ludo, for myself the ALL button is very important, especially when I want to configure a certain mode (e.g. arpeggiator mode) I made this change on a request from somebody who wanted to use the sequencer with minimal hardware requirements: one display, four menu navigations buttons and one rotary encoder. The "start/stop via select button" feature in the main menu is the only way for him to start the sequencer If you don't like this behaviour (I implemented this to make somebody happy and not to confuse anybody) then you can replace SEQ_BUTTON_StartStop by CS_M_NOP in cs_menu_tables.inc Are there other oppinions? Best Regards, Thorsten.

More informations about the filter that I've used in the first example can be found here: http://69.56.171.55/~midibox/forum/index.php?topic=2821.0 A "filter box" would be a great idea, not only for the MBSID, but also for MBFM - I would build one! But unfortunately I'm not an analog expert, therefore such a project should be driven by somebody with experiences in this area. Twin-X: I will send you a snapshot this evening. Yes, you can mix the firmwares like you want - sooner or later I will change the TB303 feature to a soft-selectable option, which means that you can use the same firmware for both engines Best Regards, Thorsten. P.S.: currently I'm thinking of an optional TB303-like keyboard for better editing capabilities. I hope that there is enough space in the flash for this useful feature, if not this option will only be available when anything else is disabled (e.g. some menu items which are not related to the typical TB303 sound) P.P.S.: maybe I should mention here that Matze (the creator of the acidcode.de box) gave me a lot of useful hints about the TB303 behaviour and the schematics :-)

Hi Robin, yes, thats correct - MIOS_AIN_Pin7Get returns the same pot value converted to 7bit Best Regards, Thorsten.

Hallo, unter "Latest News" hat jemand von genau dem gleichen Problem berichtet. Ich kann es mir nicht erklaeren und benoetige mehr Input. Waere es moeglich, dass Du mir das Board sowie den PIC mal zuschickst? (bei Moeglichkeit nicht per Paeckchen, sondern in einem gefuetterten Umschlag) Gruss, Thorsten.

Hallo Costa, unter diesen Umstaenden kann ich mir das Fehlverhalten nicht erklaeren. Mir fallen eigentlich nur noch drei Moeglichkeiten ein: die Reset-Leitung am MCLR# Pin ist nicht sauber verbunden. Du kannst das nachmessen, die Spannung sollte an diesem Pin (#1) ca. 5V betragen die Versorgungsspannung am PIC ist so niedrig, dass ein sog. "Brown Out" Reset ausgeloest wird, dieser koennte sich ab einer bestimmten Spannung staendig wiederholen. Die Troubleshooting Guide hast Du ja bereits abgearbeitet, vielleicht solltest Du aber trotzdem nochmal nachmessen, ob die Spannung zwischen den Vss/Vdd pins > 4.5V ist der Bootstrap Loader wurde nicht richtig geflashed. Soviel ich weiss, kann Michael den Chip nicht testen, deshalb ist die Wahrscheinlichkeit gar nicht mal so gering Wenn die beideren oberen Punkte zu keinem Ergebnis fuehren, wuerde ich vorschlagen, dass Du mir den PIC mal zuschickst (die Adresse erfaehrst Du aus dem ucapps.de Impressum). Ich wuerde das Flash dann erstmal auslesen und dabei nach mismatches suchen, vielleicht hilft das weiter. Danach kann ich den BSL neu flashen und den PIC testen, bevor ich ihn Dir zurueckschicke Gruss, Thorsten.

Hallo Costa, ja, der Snapshot hilft! MIDI-Ox ist richtig eingestellt, trotzdem siehst Du einen Effekt, der eigentlich nur bei einer softwaremaessigen Feedback Loop auftreten kann. MIDI-Ox sendet die eingehenden Daten nicht weiter, doch vielleicht irgend ein anderes Programm? Entferne das Kabel am MIDI In Port des Core Moduls - sieht der Upload Request nun immer noch so seltsam aus, oder kommt er nun alle zwei Sekunden? Falls es so funktioniert, muesstest Du sicherstellen, dass keine MIDI Programme im Hintergrund laufen (evtl. sind die daran schuld). Hast Du vielleicht mal am Microsoft MIDI Mapper herumgespielt, und dort eine direkte Weiterleitung von IN nach OUT eingestellt? Welches MIDI Interface verwendest Du genau? Gruss, Thorsten.

Great! :) Did you build MBHP_BURNER or another one? Best Regards, Thorsten.