I'll have to get part of the manual through. I'm not sure I want the whole thing, I'd really need just the bit with all the technical midi stuff.
I've got the manuals for my own Yamaha MU90r, which may or not help.
If your setup will send a midi file, you might find things easier to create a midi file containing your sysex string, rather than have to re-enter the sort of data you're doing. May be easier to try small adjustments? But that's your choice.
I note that you show two strings, one that works, another that doesn't. But the headers are different? I would have expected that for strings of the sort you're trying, the first three data bytes (after the F0H for systex) should be the same, i.e. 43H for Yamaha, nnH for device number, nnH for Model ID. Your examples show two bytes matching, the third is not. Is this correct?
For my MU90r, the CHK is required where there is a variable ## of bytes data. If the Dump Request is asking for a defined block (i.e. a specific and invariable ## of bytes) then a CHK is not required.
Do you have any midi files that include sysex for your device? This may give some hints as to the exact structure of the sysex. I have quite a few Yamaha XG specific files for the MU devices, and these work on my MU90r as well.
Page 74 of the manual seems to be key, and shows the skeleton of the dump request sysex I'm trying to send. As you point out, the structure of this message is different from all the others. A couple of notes on this page are particularly gnomic:
1) "Data is correctly processed if the Dump request receive address corresponds with the Start Address and the Dump Requests' byte count is correct". I don't know quite what this means, but I assume that asking for the 10 bytes from 30 00 00, which is what the manually initiated dump sends in its first message, should be valid. This coresponds to 30 00 00 00 01 02 in the 6 bytes of start address and byte count.
2) "The check sum's lowest 7-bit value is zero after adding the Start Address, Data and check sum" This surely means that the sum of the 3 address bytes, the 3 byte count bytes and the checksum must be 0 mod 7F, and 30 + 01 + 02 + 4D = 80 = 0 mod 7F.
You say - the TG100 remains silent. What does that mean?
When you send the command that works, what does the TG100 do then. Does it say something, do you get something back, or have you determined otherwise that the command DID work?
With this new command, I'd expect that you should get data back (which you did not before?). Is the console command set to receive as well as send, should it display, or do what, with anything coming back? The low level process for sending data is different to the process for receiving.
I think your little pic showed that midi OUT of the TG was connected to midi IN of your computer, to get something back.
I mean that even with the corrected dump request the TG100 does not output anything.
The hardware configuration remains as shown in http://ncvp.co.uk/tg100/hware_01.jpg
I use amidi in Linux and Cakewalk in Windows 10.
Pressing the appropriate buttons on the TG100 generates the same "dump all" file in Linux and Windows.
Playing midi files in Linux and Windows works normally.
Sending F0 43 10 27 30 35 06 00 15 F7 (4.1.9 All Parameters Reset, page 73) works in Linux and Windows.
Derek on the Yamaha Musicians Forum suggested setting the device number to 20 rather than 10.
This caused the TG100 to burst into life and issue dump messages.
The message I received in response to:
F0 43 20 7A 4C 4D 20 20 30 30 36 38 52 51
30 00 00 00 00 0A
00 00 00 00 00 00 00 00 00 46 F7
exactly matched the first in the "dump all" output here http://ncvp.co.uk/tg100/tg100_dump_all.txt
I hadn't picked up that 20 in the device number specified a dump request and 10 a dump reply. (I still haven't found it anywhere in the manual)
Just to confirm, I sent:
F0 43 20 7A 4C 4D 20 20 30 30 36 38 52 51
30 02 00 00 00 18
00 00 00 00 00 00 00 00 00 36 F7
requesting the 24 bytes of Multipart 11, and the TG100 responded with:
F0 43 10 27 30 02 00 38 00 0A 01 08 00 40 64 08 08 00 7F 04 40 40 40 40 40 02 0F 00 40 00 00 3B F7
which again matched the appropriate message in the "dump all" response.