MB64 Mios & "to com"

Testing/Troubleshooting
1

Hi

I have been busy trying to get my MB’s upgraded to 18F’s and the new Mios & firmware.

I may have found a potential bug or maybe I am doing something wrong?

Whenever I set the midi config to MBLINK ForwardPoint or EndPoint and “To Com=Yes” and then afer I turn the box off & on again it has lost the setting for “To-Com=Yes”  ???

It always reverts back to Off! it seems to keep all other settings

I have have tried this with & without a bankstick; no diff!

Could someone else please confirm this behaviour?

Cheer

LO

Edit: I am using MB64 2.1 & Mios 1.4b (also happens in the MB_MF new firmware?)

2

See the comments in the cs_m_midicfg.inc file:

;; --------------------------------------------------------------------------

;;  Menu Exit routine is called when the exec button has been pressed

;; --------------------------------------------------------------------------

CS_M_MIDICFG_Exit

       ;; Note: the “to-COM” flag will not be saved, since this would

       ;; also affect the first-level bootstrap loader. If a user doesn’t

       ;; take care for a proper configuration, he would propably never

       ;; be able to update MIOS or an application if he don’t own a

       ;; PIC programmer…

       goto    MB64_DUMP_StoreGlobal; (save CFG0 and CFG1)

So, if you want to switch on the to-COM option permanently (if this should be the default state), you could either burn the PIC again with changed ID header, or you could use the change_id application, or you could modify the source code of your MIDIbox so that to-COM is enabled in USER_Init

Best Regards, Thorsten.

3

OK thanks

Makes sense!

While Im on the topic of MB Link

Should it be possible to send sysex or applications

ie MB_MF to the Second/last core in the chain without removing the first core?

I have gone in to the sysex dump menu and changed the first core to device ID 1 and the second to device ID 2

When I attempt to send sysex via vmidibox I can get the first core to recieve the dump but when I change the device ID to 2 and resend the second core does not receive the dump.

Thanks

LO

4

Hi LO,

the MIOS device ID is not the same like the application specific device ID which can be selected in the SysEx menu.

So - it would be important that your second core has a different value in the ID header (if not-> use the change_id application). Thereafter the upload to the second core should work.

Best Regards, Thorsten.

5

this also makes good sense

Thank-you  8)

6

OK Some minor probs

I tried using the ID change program but with no luck

So I re-burnt the PIC with a header of :…00000112 (also tried …000142)

for “to com” = ON

and device ID = 0x12

No luck when attempting to upload MIOS

So I tried going back to my standard midi interface

with a header of …00000012

for “to com” = off

device ID = 0x12

And still no luck Mios will not upload when ever I change the PIC header; I am changing the 00000000 number in the bottom right corner of IC-prog is this the right place?

But its fine when I leave it with all zero’s in the header!

Do I need to change something in Midi-OX to send the data to the correct core now that it has a different ID?

Also how do I learn what 0x12 means in normal numbers ie I want one core to have a device ID of 1 and the other 2 what do I enter in IC-prog?

Help! :o

7

Hi LO,

the first core should be assigned to device ID “00”, the second to “01”, etc…

Why doesn’t your core regognize the incoming SysEx blocks if it’s assigned to another device ID: because the SysEx blocks are assigned to device ID 00 by default. So long as the Java GUI is not available, this means that you’ve to generate a new .syx file with the correct ID.

See also: http://www.ucapps.de/mios_bootstrap.html

Topic “Converting .hex to .syx”,

the last two snapshots

For changing the device ID of mios_v1_4b.syx: see the README.txt file which is included in the .zip archive

Best Regards, Thorsten.

8

mmmm OK good more things to try  8)

Thanks