[Coco] High(Er) speed cassette loading.

Ciaran Anscomb cocomalt at 6809.org.uk
Wed Dec 30 18:13:02 EST 2020

John Kowalski wrote:
> On 12/30/20, Allen Huffman <alsplace at pobox.com> wrote:
> > This sounds like a DTMF decoded routine. I suppose the test would be to see
> > how many tones the CoCo could reliable distinguish, and how fast. Audio
> > Spectrum Analyzer showed it could generally detect many. Interesting.
> It's not even that complicated, it'd just be a refinement of the
> existing way cassette loading/saving works.    Think of it as
> different patterns representing bits - instead of just two patterns
> //////\\\\\\ representing 1  and ///\\\ representing 0,
> more patterns could be used  //////\\\ to represent 10, ///\\\\\\
> representing 01...
> and if we add even more lengths of / and \ to the mix we could
> represent 3 bits or more in a single waveform.

I always figured the conservative full wave = one bit was to account for
crappy tape decks that might have some sort of DC offset or similar.  ie,
a short "high" pulse might actually just be the result of problematic
playback, accounted for by a longer "low" pulse - measure two zero
crossings and that sort of thing averages out.

FWIW, it's perfectly possible to save the waves out about 30% faster
than usual and adjust some low RAM BASIC variables to have the standard
ROM routines read them just fine (no FAST/AD mode necessary).  I did a
lot of testing of this and it's still pretty resilient (Dunjunz does it,
for example - and more generally, bin2cas.pl will generate autoloaders
using it).


More information about the Coco mailing list