[Coco] Cassette data format

[Arthur Flexser]

Could it be that the output routine used by CSAVEM doesn't disable
interrupts?  Seems unlikely, but....

Anyway, I suppose you could test this by seeing if it makes any
difference if you disable interrupts with a POKE before doing the
CSAVEM.  If I remember correctly (and it's been a long time, so no
guarantees), the relevant poke is POKE&HFF03,&H34.

Art

On Sun, Aug 25, 2013 at 3:33 AM, Mark J. Blair <nf6x at nf6x.net> wrote:
> The documentation I've found indicates that the cassette save routines encode each zero bit as a single cycle of 1200 Hz, and each one bit as a single cycle of 2400 Hz. I've written a python script which converts .cas files to .wav files using those parameters, and my CoCos can load files from the resulting audio waveforms. I generated square waves instead of sine waves, and the CoCos didn't seem to care since they just look for the zero crossings when loading.
>
> I noticed that my converted files sounded higher in pitch than recordings created by my CoCos, so I investigated a bit further. I wrote a quick little program that does a couple of CSAVEM commands, one saving 256 bytes of ones and the other saving 256 bytes of zeros. After I isolated the data from header bytes and analyzed it in both Audacity and Baudline, I found that zeros produced a 1093 Hz tone and ones produced a 2032 Hz tone. Not only are these tones 9%-15% lower in pitch than the documented tones, but they aren't in a 1:2 frequency ratio as I expected them to be. There's probably some small error in those measurements due to wow and flutter from my CCR-81; I didn't get clean signals when I tried to digitize directly from the cassette cable, so I recorded the test files on my CCR-81 and then played them back into my computer's line input.
>
> Can any of y'all shed any light on this discrepancy?
>
>
>
>
> --
> Mark J. Blair, NF6X <nf6x at nf6x.net>
> http://www.nf6x.net/
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco