[Coco] Cassette data format

[Ciaran Anscomb]

"Mark J. Blair" 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 noticed that my converted files sounded higher in pitch than recordings
> created by my CoCos, so I investigated a bit further. [...]
> 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. [...]
> 
> Can any of y'all shed any light on this discrepancy?

Just an artifact of the way the signal is generated: by code explicitly
setting the level to a sequence of values generating a sine wave.
The code doesn't output exactly 1200Hz or 2400Hz.  The read routines
are fairly tolerant, so it's not too big a deal.

The cycle durations actually vary quite a bit depending on where in
the output it is - the first bit of any byte will be slightly longer,
as there's a bit of setup involved, etc.  Conversely, the "ideal" cycle
durations to fall exactly in the middle of the recognition window during
reading vary depending on which bit is being read...  I have some notes
from old code:

/* The "ideal" pulse widths vary according to where they are:
 *
 * Leader cycle:            68 + n0 * 28, 5 + n1 * 28
 * First byte cycle:        81 + n0 * 28, 5 + n1 * 28
 * Subsequent byte cycles: 120 + n0 * 28, 5 + n1 * 28
 * Other bit cycles:        67 + n0 * 28, 5 + n1 * 28
 */

Where the numbers are CPU cycles, and n0/n1 are, IIRC, half the configured
timing parameters (you can alter them in RAM), but don't quote me on that.
I was going to have cas2wav be able to emit the "perfect" waveform in
terms of resilience to tape speed variations, but in the end decided it
was too much work for too little gain.

..ciaran