Re: cassette interface data format?

[mjmahon@aol.com (Michael J. Mahon)]

Jayson Smith wrote:
>
>"Benjamin Ketcham" <bketcham@drizzle.com> wrote in message
>news:1097056634.892700@yasure...
>> Michael J. Mahon <mjmahon@aol.com> wrote:
>> >
>> > The best "documentation" of cassette format is in the monitor
>> > listing for the code that creates and decodes cassettes.  The
>> > listing is in virtually all early Apple II Reference Manuals.
>>
>> Yes, I'd like to get my hands on a manual (again).  I had started
>> to trace the monitor code, but the info you gave below sure saves
>> me a lot of time and uncertainty.
>>
>> > There is a lead-in tone of 3.5 seconds of 770Hz, followed by
>> > a 1-cycle "start" mark with two 400 microsecond half-periods.
>> > Then data follows, most significant bit first, with two 250
>> > microsecond half-periods for a "0" and two 500 microsecond
>> > half-periods for a "1".  Following the data, there is a single
>> > checksum byte, which is the EOR of all data bytes, seeded
>> > with $FF.
>> >
>> > Applesoft BASIC files are preceded by a short record with
>> > the length of the program and an "auto run" flag byte.
>>
>> Thank you very much for this info!  If it is available on the
>> Web anywhere, I was unable to find it with my search attempts.
>> I'd suggest that those who maintain Apple II FAQs (there seem
>> to be more than one active FAQ) might want to include this
>> info -- though I guess if I'm the only one who asked, it's
>> not a very FA Q.
>
>Hey, with this info, I bet somebody could write a Win/Linux program to take
>any standard file and convert it to a .wav of a valid Apple II cassette dump
>of that file.  That way you could transfer, say, ADT to an Apple via the
>tape interface.  Or any other binary for that matter.  DOS, even?
>I couldn't do it, but somebody probably could!  What would be the best
>sample rate for such a wav?  What kind of frequency response does the
>cassette hardware require?

Such a transfer method could certainly work, and could be a useful
addition to the "bootstrapping" repertoire.

The cassette interface is not a fast data interface (!), transferring
data at an average rate of 1500 bps, or less than 200 bytes per second.

At this rate, a full, uncompressed disk image could require about
12 minutes to transfer.  Of course, it could not be transferred in a
single "record" because of memory limitations, but reliability would
probably also dictate several smaller segments.

DOS could certainly be transferred, after which a program could
combine "segments" of an image to produce a complete disk.

The waveform sent by the Apple to a cassette recorder is, of course,
a square wave.  The "polarity" of the square wave is indeterminate, since
the Apple cannot control whether the waveform is high or low, but can
only "toggle" it from one to the other.

A typical cassette recorder has a record/playback frequency response
of 10kHz or so, so the recorded square wave is decidedly less square
when it is replayed.  To allow for this, the Apple cassette input senses
only the zero crossings of the signal, to recover the approximate timings
of the original transitions.

I haven't timed out the cassette read routines to determine exact margins,
but I would expect that timing deviations resulting from discrete sampling
would be tolerated up to +/-50 microseconds (since inexpensive cassette
recorders can exhibit significant flutter, too).  If this is so, it would
suggest
that 22kHz sampling would be quite sufficient for accurate reproduction,
and experiment might verify that even 11kHz would work reasonably reliably.

Note that popular lossy compression schemes, such as MP3, may not
preserve the critical zero crossing timing, even though the recordings may
"sound" to a human like the originals, so .wav files are a good starting point.

-michael

Check out parallel computing for 8-bit Apples on my
Home page:  http://members.aol.com/MJMahon/