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

[Egan Ford <datajerk@gmail.com>]

On Dec 3, 5:04 pm, Michael J. Mahon <mjma...@aol.com> wrote:
> Egan Ford <dataj...@gmail.com> wrote:
> > On Nov 27, 11:36 am, Egan Ford <dataj...@gmail.com> wrote:
> >> I just spent my yesterday creating a new cassette input method that is
> >> ~11x faster than the original (I loaded moon patrol in 10 sec vs.
> >> 109), and while it works with Virtual ][, it fails on the real thing.
>
> > Update.
>
> > My initial method used 16 frequencies (1, 3, 5, etc... pulses).  I
> > used positive pulses for the MSN (nibble) and negative pulses for the
> > LSN.  Then 4 pulses to write to memory.  Pulses were 1/64000 seconds.
> > This gave me an effective baud rate of 1777 with 14216 bps.
>
> > This worked consistently well with Virtual ][, however with my //e,
> > not so good.
>
> > Two problems:
>
> > 1.  The (my) //e can not measure a single 1/64000 pulse, but it can
> > measure 2 @ 1/64000 or 3 @ 1/96000.
> > 2.  The iPhone cannot output above 20000 Hz.
>
> > So, I changed my max frequent to 16000, recomputing my ranges.  Tried
> > 64K and 96K with my Mac connected to my //e, and while not 100%, it's
> > close, however with the iPhone, garbage.  I was able to get the iPhone
> > to reliably send data if using a full symmetrical cycle.
>
> > Moving forward:
>
> > 1.  I need to use full symmetrical cycles.
> > 2.  More pulses/cycle.
> > 3.  Try for 5x improvement.  10x with data compression.
>
> Zero crossings are what is sensed, so preserving symmetry preserves the DC
> level, making the zero crossings accurate.
>
> If you are sensing the crossings in a counted loop, then your limiting
> timing resolution is the total time for a loop iteration.
>
> Once synchronization has been achieved, you can poll more efficiently than
> a loop.
>
> -michael - NadaNet 3.1 and AppleCrate II:http://home.comcast.net/~mjmahon

Reverting back to KISS, I have been able to get a ~6x (~8000 bps vs
~1333 bps) improvement over the native cassette loader using 12000 and
6000 Hz tones for the 0's and 1's.  And, I think I found the another
source of my iPhone vs Mac output problems.  The iPhone appears to
perform better with full cycle smooth (vs. square) tones and depending
on the player you do need a leader (I am using 1/10 second of 2000
Hz).  There are other annoyance as well, such as mail alerts, etc...
that corrupt the stream.

I am using Moon Patrol as my benchmark.  After removing the headers I
get 1406 bps (105 sec) with the native method and 8204 (18 sec) with
my improved version.  Tested on a //e.

Next weekend, 2x compression to get me to 16000 bps.