Bootstrapping higher Device IDs??

[pay_c]

Hi again!

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?

[TK.]

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.

Best Regards, Thorsten.

[pay_c]

Would be cool, if you could send me those .syx files. Perhaps you could also post them on ucapps.de.

Or perhaps just the .syx files (MIOS) of the first four IDs (cause of the SID - more people will need that...).

Am I the only one with this problem? I mean, other people are building the 4xSID, too, aren´t they? So why didn´t I hear anything from them? Weird...

Stupid question: Is it really neccesary to count those IDs up? (Do think so though...)

Anyway: Thnx !!

/edit: Just sent you my email

[TK.]

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

Best Regards, Thorsten.

[pay_c]

Oh, I get it. I only used the 18Fs.

OK, thnx again TK, hope I´ll get some good sound!  :)

[pay_c]

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.

Just to let you know. Thnx again!

[TK.]

Hi Pay,

a different device ID doesn't change the checksum. But ok, you found your solution :)

Best Regards, Thorsten.