Orchestra-90 CC

[pser1]

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.

Good point, Robert
you're right.
Now I doubt the correctness of the block 'header' I have seen in the CAS files:
55,55,55,3C,01,FF
Assuming the first $55 is the trailing byte of previous block ...
There is an extra $55 if the header of data blocks has only a lead $55 byte, or am I wrong?
But there are 90% of files that despite that extra $55 are well loaded into Orchestra90cc
Now that is fooling me!

Acording to this data structure, a block consists of 255 bytes + 6 extra bytes
So the distance between the beginning of consecutive blocks must be:
$FF + 6 = $105 bytes
But if you look at the CAS files generated by the perl script, the blocks are extacly $106 bytes apart
that is to say 105 plus the extra $55 byte ...
Should I believe that the data input routine wil skip any byte untill it finds the synchronisation byte $3C?
This is the only explanation I can find to this numbers difference.
Anyway, even if the CRC is well calculated, the data in the example I chose is missinterpreted ...
This needs a whole revision of that file from the beginning
I think that I am going to verify it with a Java app, because manually is annoying for such an amount of bytes.

thanks a lot
cheers
pere

[robcfg]

Yes, the leading bytes should be skipped until the 0x3C byte.

There can be any number of 0x55 bytes before the block start, and one at the end. If there are more at the end, then there's one trailing byte and the leading bytes of next block.

[pser1]

that's right.
Now it seems that I could plan to 'verify' the converted CAS files with a small java app.
Or maybe better, try to learn perl and see what does Tony's script.
I don't need the WAV files immediately, it was just a step to get them converted into
ORC files and saved onto DSK in my CoCo, so I can wait the needed time to learn
this language.

thanks a bunch!
cheers
pere

[tjewell]

Gosh, I go offline for a couple days and suddenly there's a 40 new posts on this thread to read!

I think I've got a fix for my script - it's one of those annoying fixes that seems to work, but I don't understand *why*. It's something to do with Perl's file IO, and I worry it might not work on non-Unix systems. It certainly seems to load and play the files you've marked as being problematic.

Let me re-read all your new posts, and I'll hopefully post my findings tomorrow! Currently grooving out to a remarkably good rendition of Jean Michel Jarre's Oxygene here - I'd love to get hold of a real card soon, come on eBay!

Cheers, Tony

[pser1]

Hi Tony,
glad to know you have a patch that solves the 'problematic files'
I am doing my firts steps on Perl, fortunately it is a very C-like language, but it has
some tricks related to I/O and search/substitute strings that need some internet help!
Honestly, after reading your script some hundred times, I was unable to find the place
where the $0A that affects 13 files is added, shame on me!

Waiting for your news.
Thanks a lot for helping

cheers
pere

[tjewell]

Okay! My current script has had a 100% success rate reading those difficult files. If it still doesn't work for you, I wonder if there's a strange file IO problem. So, along with the new script, I've also included two .CAS files that successfully load. If the files you generate don't load, perhaps we could work out what the differences are!

One major change to the script - you now specify the input and output files on the command line. So do this:

./asc2cas-v1-2.pl apache2.asc apache2.cas
** NOT this ** ./asc2cas-v1-2.pl apache2.asc > apache2.cas

(I did that to give myself a little more control over how the output was created). I've also increased the length of the leader to 80 chars instead of 16, so hopefully you'll get better .WAV files now. Oh, and a few other little tweaks.

Let me know how you get on!

[pser1]

Hi Tony,
I have tested the two cas you uploaded and work well in XRoar with Orchestra.
Then I used the new script to convert AAODDS.ASC that had given 'header' problems and now it is well converted
and plays nice too.
So, congrats! You got it!
I like the idea of widening the header with 80 chars $55.

Now I will convert the 'problematic' files I had isolated in separated folders, not too much work
Hopefully all of them will work OK now

Will tell you how it goes. Once converted into WAV files, I could load them both in my Dragon or in my CoCo
That's more test to do ...

cheers
pere

[pser1]

You could use XRoar for this maybe (yeah yeah I'm a one-trick pony...):

Code: Select all

xroar -nodos -tape-rewrite -tape-write filename.wav -type 'SKIPF\n' -timeout-motoroff 1 filename.cas

Edit: except... there seems to be a bug

Hi Ciaran,
no good news, sorry.
I didn't use any of the created WAV files nor did I have a look at its length. I just converted the 2448 files
Unfortunately they are too short, not real WAV files. In fact they are much the same as the input CAS file.
The only difference seems to be in the header.
The WAV file has 256 lead $55 bytes as opposed to the 16 of the CAS file.
After the data in the header, the WAV has another lot of 256 bytes $55 while the CAS has only 3.
But the other bytes are all the same and, of course, the generated WAV is not recognized
as a playable file for Windows. So what is wrong with that command?

Code: Select all

xroar -machine dragon64 -extbas ..\..\..\XRoar\ROMs\d64rom1.rom -altbas ..\..\..\XRoar\ROMs\d64rom2.rom -nodos -tape-rewrite -tape-write %1.wav -type "SKIPF\n" -timeout-motoroff 1 %1.cas

I remember I had created WAV files many time ago, but this doesn't seem to be the right command.
Any advice to get a working command would be highly appreciated

cheers
pere

[pser1]

Hi Ciaran,
disregard previous post.
It was my own fault, sorry

I was using this command

Code: Select all

for %%a in (*.cas) do (
   ..\..\xroar -machine dragon64 -extbas ..\..\..\XRoar\ROMs\d64rom1.rom -altbas ..\..\..\XRoar\ROMs\d64rom2.rom -nodos -tape-rewrite -tape-write %%a2wav -type "SKIPF\n" -timeout-motoroff 1 %%a
)
ren *.cas2wav *.wav
del *.rom

I did use %%a2wav to make it easier to rename all the files one shot ... but this creates the problem
The correct command is simply

Code: Select all

for %%a in (*.cas) do (
   ..\..\xroar -machine dragon64 -extbas ..\..\..\XRoar\ROMs\d64rom1.rom -altbas ..\..\..\XRoar\ROMs\d64rom2.rom -nodos -tape-rewrite -tape-write %%a.wav -type "SKIPF\n" -timeout-motoroff 1 %%a
)
del *.rom

That way it creates long correct WAV files!

cheers
pere

[pser1]

Hello,
I am in the process of converting the 2448 ASC files into WAV files ...
I have found an I/O Error when loading a file into XRoar
It is the JMPMFL.ASC that converts silently into JMPMFL.CAS and then
while converting to WAV with XRoar shows for a small moment the I/O ERROR message
and immediately the batch gets next file in the folder to be processed.

So, I am not sure if I have 'detected' all the files that could have had this error.
XRoar creates a file anyway. I was reading while the PC was working, so who knows?
I attach here a zip containing the three formats for if this could help.

@Ciaran
I have your CAS2WAV.EXE program too, do you think it could be used instead XRoar?
It seems to be much faster as it doesn't have to be closing and openning windows ...
Maybe I should have to put some special parameters to get a good WAV out of it,
any advice will be very appreciated.

cheers
pere