Re: Cassette port input frequency range? And CPU MHz ranges.

["Marc S. Ressl" <mressl@gmail.com>]

On Nov 28, 2:09 am, Michael J. Mahon <mjma...@aol.com> wrote:
> Egan Ford <dataj...@gmail.com> wrote:
> > On Nov 27, 7:04 pm, mwillegal <m...@willegal.net> wrote:
> >> Take a look at the sync signal used on the stock Apple 1 and Apple II
> >> cassette interface on this page.
>
> >>http://www.willegal.net/appleii/aci.htm
>
> >> Though the circuit works as a zero crossing detector, there are clear
> >> limits as to speed capability due to the relatively slow signal
> >> transition times on the comparitor side of the input capacitor.
>
> >> You may get a bit more out of it, by using a digital music player which
> >> eliminates some the analog jitter involved with a real cassette player,
> >> but I'd be surprised if you could get 10x improvement.
>
> >> Regards,
> >> Mike Willegal
>
> > Thanks Mike, that is what I was afraid of.  I'll run some tests in a
> > week or two and try to measure the peak effective frequency for my //
> > e.
>
> > Right now I have an effective baud rate of 1777 @ 8 bits giving me
> > ~10x.  But that requires a sampling rate of 64K and a range of
> > frequencies from 1032 to 32K.  It works in emulation, but not in the
> > real world.
>
> Exactly. And it wouldn't work in emulation either if it were a real
> emulation!
>
> The parameters for the Apple II cassette interface were chosen to
> approximately optimize the speed for real-world audio recorders and tapes.
>
> If one presumed that users had 200kHz instrumentation recorders, different
> choices could have been made.
>
> As was pointed out, the "wow" of the tape transport is the primary
> limitation on timing margins.  With a crystal-controlled time base (but
> still asynchronous with the Apple clock), it would be possible to use a
> byte-synchronous coding like NadaNet, and get 117k bits/sec.
>
> If timing variations are wider, it is necessary to synchronize more
> frequently than once per byte, resulting in lower speed.
>
> All of this assumes that the data recovery is being done by code running at
> 1MHz on the Apple.
>
> -michael - NadaNet 3.1 and AppleCrate II:http://home.comcast.net/~mjmahon

Hi Egan and everyone:

there is one more thing. If I'm not mistaken, there is a low-pass
filter in the Apple II cassette circuitry, which effectively limits
the maximum frequency that passes to the outside world. It would be
interesting to measure the actual frequency response of Apple II's, if
there is anybody who cares about that. How to do it? Take an Apple II
and generate a swept frequency square wave. Record the file, you
should notice that as the frequency goes higher, the signal gets
fainter. One must be very careful with the timing here.

Of course the cassette input circuitry is important as well, it would
be interesting to produce a program that samples the signal I just
described above, and attempts to record it to memory as fast as
possible (thus sampling it). It would be interesting to see what comes
out. I honestly don't have the time nor motivation to do this, but I
hope it helps.

One last thing, in OpenEmulator I'm emulating the output low-pass
filter :-). If you care to look at the XML description file, there is
a low-pass filter frequency and a high-pass filter frequency in the
audioCodec component. The high-pass filter one is the DC blocking
frequency and the low-pass one is for avoiding aliasing (so there are
no frequency components past half the sound card sampling rate). It
find it very intriguing that you also could use these filters for
accurately modeling the frequency response of real Apple II computers.

With the best wishes,

Marc.-