I build the second core for my MBSID. Than (as described) I burned the Bootstrap Loader with Device ID 1 (the master core is on ID 0).
Opened MIDIOX and tried to get MIOS on there. The programm is sending the code absolutely fine, but the PIC is not sending any MIDI Strings during the programming. After that the Dump Request rolls over the screen again.
Reprogrammed the master core, just to check if everything else is fine. It functioned without problems.
What do I have to do, to programm IDs higher than 1?
The .syx file contains blocks which are assigned to a dedicated device ID. The only way to switch to another ID is to replace the appr. entry in the SysEx stream by the new ID, or to generate a new .syx file with the hex2syx.pl script (-device_id <id>).
The “mios_upload.pl” script allows to change the device ID on the fly so that no new .syx file has to be generated. But this script runs only under Linux
The planned Java GUI which will also run under Windows will provide the same possibilities
MIOS itself has not been released for Device ID 0, as the the Java GUI will allow to change the device ID on the fly.
If somebody want’s to help me, he is free to program this Java GUI for us, because I’m not sure how long it can take until I will find the time for this task.
Temporary solution: I could give you the mios_v1_3.hex file which allows you to convert .syx files for different device IDs. Alternatively you could change the device ID manually in the mios_v1_3.syx file (for every code block which begins with F0!). The main.hex file of the SID application is already available in the .zip archive.
Now you will find the .hex file in the official mios_v1_3.zip package. I’m a little bit carefull with this file as the “.hex” extension implies for an unexperienced user (who normaly never reads a README) that this OS release has to be burned directly into the PIC. But thats not the case - never use IC-Prog to upload the OS, since this would remove the first level bootstrap loader.
Regarding the device ID: I’m not sure, but maybe you don’t know that the device ID of the MIDIbox SID application has to be changed in order to get the multisetup running.
The MIOS device ID is a different value which is mainly used for firmware uploads.
In other words: the MIOS device ID identifies the core module, the MIDIbox SID device ID identifies the SID
The reason why others didn’t notify this “problem” is possibly that they are using a PIC16F for the slaves… the PIC16F solution doesn’t provide a specific device ID
The .syx file contains blocks which are assigned to a dedicated device ID. The only way to switch to another ID is to replace the appr. entry in the SysEx stream by the new ID, or to generate a new .syx file with the hex2syx.pl script (-device_id <id>).
Hi TK!
Everything fine now (I think). Also I didnt try all out up to now. But everything looks just fine (App is loading now at last).
But: You have to make the file with the hex2syx, cause otherwise the checksum will be wrong. I tried out both ways. Only the hex2syx way functioned. With changing the values by hand it did not at all.
