cas2wav update

[sixxie]

Someone just linked to their online CAS to WAV converter.

It seems to be based on the tiny Perl script I cobbled together a while back, though I think it might also intelligently pull the CAS apart to insert silence etc.

Anyway, I thought I'd upload my current version written in C that does varying samplerates and all that jazz. Still not intelligent at all, just bits to waves, but maybe they're slightly nicer waves.

Here!

[robcfg]

Nice update!

Regarding the silence, I think the .CAS format is lacking data so even if you have a dump from a protected game, you will have to do some tricks to generate a wav version that works unmodified.

Would it be time to update the CAS format itself?

[zephyr]

Thanks Ciaran! I have just uploaded a Windows compile to the Uploads section.

[sixxie]

I have just uploaded a Windows compile to the Uploads section.

Cool!

[sixxie]

Regarding the silence, I think the .CAS format is lacking data so even if you have a dump from a protected game, you will have to do some tricks to generate a wav version that works unmodified.

Would it be time to update the CAS format itself?

Oh yes, very true. Both Pedro and Cosmic Cruiser have to have a particular gap between the loader and the first title screen (or have the header stripped from the first screen).

I've wondered about updating CAS before, so I've just put this together - how reasonable does it sound? Obviously it's all a bit glossed over, but I think the gist should be there...

http://www.6809.org.uk/tmp/da/cas-proposal.shtml

Comments welcome, especially any that would reduce the complexity!

[robcfg]

Hi!

I was talking with a friend on the subject and told me to take a look at the pzx file format for spectrum tapes, as it was designed to be simpler than the tzx file format, while retaining all the features.

I think it's worth taking a look. Link here.

I'll be reading your prototype spec and the pzx one this weekend.

Regards,
Rob

[sixxie]

Hm, I quite like the look of that. Quite similar of course - I think the only conceptual difference is that each specification of pulse widths occurs at the head of a data block. Maybe just redefine timings as being in units of 1/28636360s (twice the SAM clock, == the GIME clock on a CoCo 3) and away we go... Edit: ok maybe scale that down a bit and make it a more reasonable 1/3579545s - that's still twice the maximum CPU clock speed...

The only annoying thing about it is these Z80 types' insistence on little-endian numbers! Ptchah! *spit*, etc.

Oh and I do think a raw audio block type would be useful and not too hard to implement. Call it ARAW or something.

Edit: noticed another difference. In our format, data should be read out least significant bit first, to reflect the data order the ROM tends to generate, so it stays "readable".

[sixxie]

Using the PZX format as a reference, I rejigged my proposal a bit... Ditched the fun "compatibility" stuff to magically turn old formats into the new as there's not much use in it. Instead, how about the "Passable Dragon/CoCo Tape format"?

http://www.6809.org.uk/tmp/da/pdct-proposal.shtml

[Dantyr]

Someone just linked to their online CAS to WAV converter.

That it's the work of Robson França a brazilian friend and the author of CoCOTLA.

Daniel

[Sarah]

Oh yes, very true. Both Pedro and Cosmic Cruiser have to have a particular gap between the loader and the first title screen (or have the header stripped from the first screen).

IIRC what those Imagine games do is seek the leader for supplementary files, but don't bother actually loading the header block, since they don't need to care about it. So it simply gets skipped by the seek routine being called again, although an extended leader would throw out the timing and likewise an emulator wouldn't normally just skip data in the way their loader expects.