Re: cassette interface data format?

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

Benjamin Ketcham wrote:

>Jayson Smith <nospamratguyspambegone@nospamplease.bellsouth.ihatespam.net>
>wrote:
>> 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?
>> Jayson.
>
>Well, this is basically what I'm trying to do.  Except I am using
>a PIC microprocessor as an intermediary, so that the Linux system
>sees a plain RS-232 interface (thus other devices such as a Palm
>Pilot, etc., could also talk to this).
>
>However, if you are willing to bang on the parallel port and don't
>care about portability to non-PC platforms, then as far
>as I can tell, it would suffice to directly connect one of the port
>signal lines to the Apple cassette input (and also connect the grounds
>of the two systems).  I have found empirically that no resistor
>divider or other analogue circuitry is needed, the cassette input can
>handle raw TTL, as produced by a PIC -- or PC parallel port.

There is a problem with bit-banging on Windows machines--multitasking
and interrupts.  In order to produce precisely timed waveforms, it is
necessary to gain complete control of the processor.  And, for any
"modern" cached processor, it is usually necessary to control a timer,
since instruction execution times are not constant (depending on cache
misses, etc.).

For something slow, like the cassette signal, where 50 microsecond
accuracy is sufficient, things are a bit easier, but a task switch would
still mess up the timing and cause the "record" to be in error.

>I.e., no need to convert to WAV and send with a sound card (although
>that should work, too).  To answer your question, a pretty
>low sample rate should suffice, the highest *fundamental* frequency
>in the cassette signal is 2kHz.

But the timing accuracy required is still the critical issue.

>I have seen someone else's project, sending data from PC parallel port
>into the Apple via a joystick input.  This would potentially give a much
>higher transfer rate, but the downside is that there is no ROM support
>so you have to enter machine code to make the Apple receive data this
>way.  With the cassette interface, of course, the advantage is that
>the Apple already knows how to receive data through that channel.

Data transfer using a pushbutton input and an annunciator output
has the great advantages of 1) being full-duplex, and 2) allowing for
handshaking, so that interrupts and task switches need not cause
any problem.  A consequence of this is that it can use higher signalling
speeds reliably.

Apple II Oasis is an excellent example of using an Apple connected
as described as a "disk server" to a PC.

>The work that I am doing, as usual, is open-source, so I will make
>my results available (is it appropriate to post such notices in
>this group?).
>
>What fun, working on the Apple II again after 20 years!

Hear, hear!

-michael

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