TK.

Ich bezweifle, dass es am Bootloader liegt. Markus' Problem ist zwar ungeklaert, aber der Loader kommt bereits in vielen MIDIboxen zum Einsatz. Die MIDI Troubleshooting Guide befindet sich hier: http://www.ucapps.de/howto_debug_midi.html Gruss, Thorsten.

This should also work now (step position counter was divided by 4 on incoming song position messages from Logic) -> http://www.ucapps.de/tmp/midibox_seq_v3_0a_rc3.zip Best Regards, Thorsten.

While reviewing the code, I noticed that the song position parser can be realized on a much more robust way by moving it into the NotifyRx handler of MIOS (which will be triggered immediately on received events) For a quick test, I scrubbed over the arrange window of Logic at various BPM rates, and the sequencer always got in sync with Logic again - so I think that it's working stable now :) The release candidate can be downloaded from this location: http://www.ucapps.de/tmp/midibox_seq_v3_0a_rc1.zip Please note: I also added the "x16 loop action", which means, that songs have to be overworked. "jump pos" is shifted to x16 "jump song" is shifted to "jump pos" "mixer map" is shifted to "jump song" So - songs have to be adapted if they are using these actions! Just increment the action by one Best Regards, Thorsten.

Ok, I think I found the location which needs to be improved. Could you please try the following: open seq_core.inc, search for "SEQ_CORE_Reset", and replace all lines between SEQ_CORE_Reset and SEQ_CORE_Reset_NotMaster by: SEQ_CORE_Reset ;; play off events of all tracks call SEQ_CORE_Hlp_PlayAllOffEvnts ;; init the reference counters SET_BSR SEQ_BASE setf SEQ_CLK_TICK_CTR, BANKED setf SEQ_CLK_STEP_CTR, BANKED BIFSET SEQ_CFG0, SEQ_CFG0_BPM_CLK_SLAVE, BANKED, rgoto SEQ_CORE_Reset_NotMaster SEQ_CORE_Reset_Master ;; clear all sequencer requests (i.E. a stop event!) clrf SEQ_REQ, BANKED ;; cancel all requested clocks (only relevant for master mode) clrf SEQ_CLK_REQ_CTR, BANKED movlw 3 movwf SEQ_SENT_CLK_CTR, BANKED SEQ_CORE_Reset_NotMaster [/code] For the slave the "clock counter reset" has to be done at a different place, so that it works in all cases. But for a first try this works ok It would be interesting if this works with your Logic version? (I'm using PC v5.5) Best Regards, Thorsten.

ok, got it! The whole synchronisation is not working properly anymore, seems that I messed up something during the "last quick changes" this week. I will check this and propably release a testing build today Best Regards, Thorsten.

Ich finde es immer wieder erstaunlich, wie sauber man so etwas aufbauen kann! Klasse! :) Wegen des PICs: PM Gruss, Thorsten.

Ok, I received the PIC today and noticed, that a small portion of the bootloader was not programmed into the PIC: :10024000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBE :10025000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFAE :10026000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF9E :10027000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF8E [/code] Thats a 64 byte range between 0x240 and 0x27f. This explains the strange behaviour (upload request, but programming not possible) After reprogramming the PIC (I tried v1.2a and v1.2b) the chip works ok. I also tried the protection mechanisms - uploading a wrong MIOS Version (e.g. 1.8 ) does not overwrite this flash area, this is good! So far I know, the P18 software programs 64 byte blocks, so it could be that one block was missed. But it could also be, that Mike's .hex file was incomplete. Therfore: @Monokinetic - it would be very helpful to get your .hex file! Best Regards, Thorsten.

Hi Ole, in distance to MBSEQ V2, the "Voti/Alps" compatible encoder type "MIOS_ENC_MODE_DETENTED2" is now selected by default, as this fits with the hardware of most users. So, you have to edit the encoder settings at the bottom of setup_mbseq_v3.asm Btw.: I received your PIC today, I will answer in the appr. thread Best Regards, Thorsten.

This is clearly a bug and I will fix this soon. Did you (or anybody else) find other issues which are worth for being fixed in the first "service pack"? Best Regards, Thorsten.

Yes, I'm aware of this issue - the reason is, that for a proper synchronisation the internal song/step and clock divider counters have to be prepared for the next step, so that the correct step is played with the next incoming MIDI clock. Since Logic can send more song positions in addition (e.g. while scrubbing the song position pointer over the arranger window), I found it more useful to prepare, but not to execute the next step, just to save some CPU time and to prevent unnecessary delays (in worst case, a MIDI In buffer overflow could happen) Therefore the LCD and LEDs will show the scenario before the actual selected song position - just waiting for the first clock so that the engine will properly update all variables. Btw.: the receive handler for the song position pointer is not able to recalculate all parameters, especially the progression parameters and the clock dividers - this is too difficult, as there is no simple "formula" which allows to determine exactly such variables based on the song position. You will find a lot of inconsistencies here... :-/ Best Regards, Thorsten.

The slowest setting is required for some PICs because a 100 nF cap is connected between Vss and Vdd This cap is not part of the "Brenner5" schematic from sprut.de, on the other hand: without this cap it isn't possible to program newer PICs like the PIC18F4685 (-> MIDIbox SID V2) I informed Sprut about this imperfection, he has confirmed the difference but he hasn't improved the software (nor Brenner5) yet... So: by removing C7 you could achieve a better performance, but newer PICs cannot be programmed anymore. And to make the confusion perfect: with "WinPIC" (requires special configuration file for MBHP_BURNER) I noticed better results, but there are new - different - issues... so that I would say: good that we only need to program the bootloader, the rest can be uploaded via MIDI :) Best Regards, Thorsten.

This nice looking MIDIbox64 has been created by Alientom - it's propably the first MIDIbox made in Japan! :)

Hey, ich habe meine allerste MIDIbox (anno 1998) in ein Sat-Receiver-Gehaeuse eingebaut, und die Potis stammen aus einer defekten Orgel. Den PIC (sowie das dazugehoerige Programmiergeraet) hatte ich bei einem Programmierwettbewerb gewonnen, und den externen ADC (der damals noch notwendig war) erhielt ich als kostenloses Sample. Im Grunde musste ich fuer meine MIDIbox nur die rote Klebefolie aus dem Baumarkt bezahlen - Beschriftung: der wasserfeste Edding war zu der Zeit noch nicht ausgetrocknet ;-) Zu den Fadern und Potis: ueberpruefe mal, ob die auch eine lineare Spannung ausgeben. In einem Audio-Mixer sind normalerweise logarithmische Fader eingebaut, und die sind ungeeignet. Gruss, Thorsten.

Why not uploading MIDIO128 as proposed in the Wiki? (-> http://www.midibox.org/dokuwiki/doku.php?id=din_module) It's easier for debugging Best Regards, Thorsten.

So far I remember - but I could be wrong - the feedback path between Data In->Data Out is used to detect the burner. This means: if the voltage level of the data pin is changed between 0V and 5V, but "data out" (see schematic!) doesn't toggle, the burner won't be detected Best Regards, Thorsten.

The voltages are ok. I think that you are just mixing "DO" (for Data-Out) with "D0" (for Dataline Zero) On the DINX4 board, the D0 line is an input, which is pulled up via 10k to +5V. So, the measured voltage level is as expected, and the module interconnections are ok. Best Regards, Thorsten.

thanks for the input! The warning level of the "positive version" is too low - it's like if you are saying "smoking can cause heart disease" - some people will smoke anyhow. So, I've changed the sentence to: Never plug a PIC into the socket if you haven't done the initial hardware checks. Also, do not plug in a PIC if the RED or YELLOW LED lits up, because the PIC could be destroyed if the pins are getting in touch with an active Vdd/Vpp level before the Vss pins are connected to ground! Could somebody please translate this to proper english? (I don't mean this sarcastically, I'm happy when somebody informs me about unclear or wrong sentences on my website) Best Regards, Thorsten.

Yes, please! This allows me to compare the contents between both failing PICs - great that you thought about this! :) Best Regards, Thorsten.

Hi Chris, if the core sends a lot of MIDI data all the time, you propably forgot to connect all unusued analog pins to ground (-> the AUAIMBCTG rule, see also http://www.ucapps.de/mbhp/auaimbctg.pdf) Yes, such a permanent data stream can lead to a hang up in MIOS Studio - this is java related, the data traffic is just too high for Java Best Regards, Thorsten.

Thank you! I've uploaded the new version to my webpage Best Regards, Thorsten.

These are very strange measuring results, especially the different reference points (Vdd/Vss) irritate me. E.g. for the SC check I'm not sure, if voltages are measured against Vdd or Vss, or if you mixed the reference points so that you always get ca. 5V... Please only measure against Vss (ground) And do this check with and without connected DOUT/DIN modules (without the modules only the selected line should be at ca. 5V, all other lines should be 0V) Best Regards, Thorsten.

The "object file" switch has to be disabled like shown in this picture: http://www.ucapps.de/howto_tools/mpasm4.gif Best Regards, Thorsten.

Scheinbar stehen heute die Sterne besser ;-) An solchen sporatischen Aussetzern sein meistens Programme schuld, die im Hintergrund den Druckerport scannen. Bei mir macht das bspw. der "Dell Network Manager" (war standardmaessig installiert). Es hat mich Tage gekostet, bis ich auf die Idee kam, dass dieses unscheinbare Programm evtl. waehrend des Brennens auf den Druckerport zugreift... :-( Frueher (unter DOS) war alles einfacher! Gruss, Thorsten.

Ich bin mir nicht sicher, ob man die SMDs Chips bspw. durch Ueberhitzung schrotten kann. Bei mir hat es eigentlich ganz gut geklappt, obwohl ich ziemlich unbedarft - und vor allem mit einem untemperierten Loetkolben - an die Sache herangegangen bin (ok, ich hatte mir sicherheitshalber auch gleich 3 alte Soundkarten besorgt...) Das Problem an diesen Chips ist, dass man eigentlich nur mit einem Oszilloskop erkennen kann, ob und was sich noch tut. Deshalb bin ich etwas ratlos, wie man bspw. mit einem Multimeter weitertesten koennte. :-/ Vielleicht solltest Du einfach nochmal ein oder zwei weitere Soundkarten auftreiben, und dann beim Entloeten noch vorsichtiger sein. Ein zweiter YAC512 macht sowieso Sinn. Gruss, Thorsten.

Suche mal in mb64e_midi.inc nach "MB64E_MIDI_SendEncEvent_M3". Hier wird bereits zwischen zwei Werten unterschieden. Ich weiss momentan nicht, ob der Meta Handler ueberhaupt Relative Events erhaelt... wenn der richtige Encoder Modus aktiviert ist, eigentlich schon, aber ich kann es nicht garantieren... Im Notfall einfach den Code unter MB64E_MIDI_SendEncEvent_M3 abaendern, und den 4. Encodermodus (40 +/- 1) aktivieren Gruss, Thorsten.