sorry Robert,
the APACHE file is one of the failed files, so disregard it ...
or simply use it to compare with the good ones
cheers
pere
Orchestra-90 CC
Re: Orchestra-90 CC
@Tony, Robert
I have found a strange coincidence with all of the 'bad' files that didn't load in XRoar
and hanged with the inverted 'S' searching for the header.
In the CAS format they have at char number 29-33 (after the filename)
01 FF 00 0D 0A
It seems to me that the two-three last bytes should contain the length of the file,
maybe I am wrong, but the well converted ones seem have that info here.
So maybe looking for the point in the perl script that processes the name and possible length
you could find something about these cases ...
cheers
pere
I have found a strange coincidence with all of the 'bad' files that didn't load in XRoar
and hanged with the inverted 'S' searching for the header.
In the CAS format they have at char number 29-33 (after the filename)
01 FF 00 0D 0A
It seems to me that the two-three last bytes should contain the length of the file,
maybe I am wrong, but the well converted ones seem have that info here.
So maybe looking for the point in the perl script that processes the name and possible length
you could find something about these cases ...
cheers
pere
Re: Orchestra-90 CC
Hi,
it's me again
Looking deep into the good and bad ones, I think that the problem is that the BAD ones have added an 0D
in front of the load address:
the bytes I said in last message were:
01 FF 00 0D 0A xx
But the bytes 0A and next one would have been the right value. So I am going to try to delete the 0D
in that bloc and try to load the modified file into XRoar
more to come ...
cheers
pere
it's me again
Looking deep into the good and bad ones, I think that the problem is that the BAD ones have added an 0D
in front of the load address:
the bytes I said in last message were:
01 FF 00 0D 0A xx
But the bytes 0A and next one would have been the right value. So I am going to try to delete the 0D
in that bloc and try to load the modified file into XRoar
more to come ...
cheers
pere
Re: Orchestra-90 CC
hello,
I am listening to APACHE, one of the BAD files.
I have just deleted the offending 0D with an hex editor ... and now works flawlessly, good!
So, Tony, if you could find the point in which your perl script adds
the length or whatever it means after the filename, and you could
add there a control to avoid a 0D to be inserted ... then this problem
will be solved.
Now the other kind of problem ... the files that load into XRoar partially.
They suddenly give the I/O error. Will have a peek at them (only three)
cheers
pere
I am listening to APACHE, one of the BAD files.
I have just deleted the offending 0D with an hex editor ... and now works flawlessly, good!
So, Tony, if you could find the point in which your perl script adds
the length or whatever it means after the filename, and you could
add there a control to avoid a 0D to be inserted ... then this problem
will be solved.
Now the other kind of problem ... the files that load into XRoar partially.
They suddenly give the I/O error. Will have a peek at them (only three)
cheers
pere
Re: Orchestra-90 CC
That's an encoding issue, more specifically line endings.
Some systems use only 0xD or 0XA as line endings, and others use the sequence 0XD 0XA. So I guess the script waits for a kind of line ending and has trouble if it finds extra bytes.
Some systems use only 0xD or 0XA as line endings, and others use the sequence 0XD 0XA. So I guess the script waits for a kind of line ending and has trouble if it finds extra bytes.
Re: Orchestra-90 CC
Hi Robert,
most probably.
I hope that Tony could have a peek at his perl script and he will find out the part of code
that creates the header and so he could avoid this situations ...
Later I will have a look at the partially loaded files.
I can see the loaded part in Orchestra, but as it is coded it makes it more difficult to
compare to the CAS file that failed ... I just need to find the last loaded byte to detect
the byte that created the loading problem
cheers
pere
most probably.
I hope that Tony could have a peek at his perl script and he will find out the part of code
that creates the header and so he could avoid this situations ...
Later I will have a look at the partially loaded files.
I can see the loaded part in Orchestra, but as it is coded it makes it more difficult to
compare to the CAS file that failed ... I just need to find the last loaded byte to detect
the byte that created the loading problem
cheers
pere
Last edited by pser1 on Thu Sep 24, 2015 3:10 pm, edited 1 time in total.
Re: Orchestra-90 CC
Hi Tony ... HELP!
I think that I have found the other problem, the one that gets an I/O error when loading into Orchestra in XRoar.
This happens when a line of code (orchestra command) is broken due to getting to the end of a block (256 bytes)
The file I have been analyzing is ALLERG and if you have a look at the CAS file at byte $1189, there is a $B2 value that I
cannot understand where it comes from. The correct one would be $41
Original Orchestra command = M V1*QB;A
The right sequence of converted data for that command should be:
CD 60 D6 71 6A 51 42 7B 41 being that last one substituted by the $B2 and immediately comes a new bloc header:
55 55 55 3C 01 FF
This one surprisingly has next to the FF the expected value $41, so the command has been splitted and the final part
comes in next data block. But for some unexpected reason a false byte ($B2) was added to the end of previuos block.
Now the question is ... how could we detect this situations in order to avoid them in the perl script?
For sure this is happening for most of the commands then it is going to be pure luck if one of them ends exactly at
the last byte of a block. This means that the problem is well solved most of the cases by the script, but sometimes
it 'adds' a not needed byte that spoils the party!
I will try to find the point where the other two cases broke, so that you could have more test cases to debug the
perl script ... not in a hurry. The script performs quite fast and efficiently, if you could get around these two problems
it would be simply ... perfect
Thanks in advance
cheers
pere
I think that I have found the other problem, the one that gets an I/O error when loading into Orchestra in XRoar.
This happens when a line of code (orchestra command) is broken due to getting to the end of a block (256 bytes)
The file I have been analyzing is ALLERG and if you have a look at the CAS file at byte $1189, there is a $B2 value that I
cannot understand where it comes from. The correct one would be $41
Original Orchestra command = M V1*QB;A
The right sequence of converted data for that command should be:
CD 60 D6 71 6A 51 42 7B 41 being that last one substituted by the $B2 and immediately comes a new bloc header:
55 55 55 3C 01 FF
This one surprisingly has next to the FF the expected value $41, so the command has been splitted and the final part
comes in next data block. But for some unexpected reason a false byte ($B2) was added to the end of previuos block.
Now the question is ... how could we detect this situations in order to avoid them in the perl script?
For sure this is happening for most of the commands then it is going to be pure luck if one of them ends exactly at
the last byte of a block. This means that the problem is well solved most of the cases by the script, but sometimes
it 'adds' a not needed byte that spoils the party!
I will try to find the point where the other two cases broke, so that you could have more test cases to debug the
perl script ... not in a hurry. The script performs quite fast and efficiently, if you could get around these two problems
it would be simply ... perfect
Thanks in advance
cheers
pere
Re: Orchestra-90 CC
HI,
I have found that after the crash, when loading one of the 'bad' CAS files, you can enter E command
and so you see what has been loaded.
Exiting edit mode (Break), you can List the loaded part (in XRoar) and this should be identical
to the original ASC file, but there are a lot of lines more in the ASC format due to splitting long lines.
Anyway you compare the commands.
With ALLERG, I have gone to the beginning by typing Break to quit edit mode and then T (top)
Once there I have searched for "END", doing /END twice to get to the point I wanted to go to.
Looking at the printed file an dat the ASC file besides the XRoar session.
If you compare the ASC original file with the printed one, you will see that from that point on
there are quite a lot of errors (not detected by the program) that would affect when playing
the score. Probably it is again an end of block issue, but needs verification.
All in all, I just wanted to say that we can list the loaded part and compare it to the original
before conversion ASC file. Any difference, points to a part of the program that doesn't
work as desired.
cheers
pere
I have found that after the crash, when loading one of the 'bad' CAS files, you can enter E command
and so you see what has been loaded.
Exiting edit mode (Break), you can List the loaded part (in XRoar) and this should be identical
to the original ASC file, but there are a lot of lines more in the ASC format due to splitting long lines.
Anyway you compare the commands.
With ALLERG, I have gone to the beginning by typing Break to quit edit mode and then T (top)
Once there I have searched for "END", doing /END twice to get to the point I wanted to go to.
Looking at the printed file an dat the ASC file besides the XRoar session.
If you compare the ASC original file with the printed one, you will see that from that point on
there are quite a lot of errors (not detected by the program) that would affect when playing
the score. Probably it is again an end of block issue, but needs verification.
All in all, I just wanted to say that we can list the loaded part and compare it to the original
before conversion ASC file. Any difference, points to a part of the program that doesn't
work as desired.
cheers
pere
Re: Orchestra-90 CC
alright now.
It is clear that, at the end of some blocks, it is added an 'unwanted' extra byte ... that by now I cannot figure where it comes from.
The file ALLERG.ASC has this long command:
M V1*H$Q9&;IA;7v2*H$Q9 which translated (coded) should be:
CD 60 D6 71 6A 48 64 51 79 66 7B 49 41 7B 77 D6 72 6A 48 64 51 79
It begins in the CAS file at byte $1077
Well, after the 7B 49 we can see a $35 in the CAS at position $1083 exactly the last of its block, but it had to be a $41 instead!!
After that wrong byte, comes the header block 55 55 55 01 FF and next the rest of the command: 41 7B 77 D6 72 6A 48 64 51 79
But unluckily the $35 has fooled the command converter in the Orchestra loading function so garbage entered.
I hope this could help, Tony.
Unfortunately I have no idea about Perl, sorry.
I will try to look at that code, but don't know if I will be able to understand what it is doing ...
cheers
pere
It is clear that, at the end of some blocks, it is added an 'unwanted' extra byte ... that by now I cannot figure where it comes from.
The file ALLERG.ASC has this long command:
M V1*H$Q9&;IA;7v2*H$Q9 which translated (coded) should be:
CD 60 D6 71 6A 48 64 51 79 66 7B 49 41 7B 77 D6 72 6A 48 64 51 79
It begins in the CAS file at byte $1077
Well, after the 7B 49 we can see a $35 in the CAS at position $1083 exactly the last of its block, but it had to be a $41 instead!!
After that wrong byte, comes the header block 55 55 55 01 FF and next the rest of the command: 41 7B 77 D6 72 6A 48 64 51 79
But unluckily the $35 has fooled the command converter in the Orchestra loading function so garbage entered.
I hope this could help, Tony.
Unfortunately I have no idea about Perl, sorry.
I will try to look at that code, but don't know if I will be able to understand what it is doing ...
cheers
pere
Re: Orchestra-90 CC
The last byte in the block is the CRC of the block.
The structure is as follows:
0x55 Lead
0x3C Block Begin
0x?? Block Type
0x?? Block size
Size bytes of data
0x?? CRC
0x55 Trailing byte
So, most probably, the script isn't counting on the CRC byte and does mistake it for a data byte.
The structure is as follows:
0x55 Lead
0x3C Block Begin
0x?? Block Type
0x?? Block size
Size bytes of data
0x?? CRC
0x55 Trailing byte
So, most probably, the script isn't counting on the CRC byte and does mistake it for a data byte.