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

[Michael J. Mahon <mjmahon@aol.com>]

Egan Ford <datajerk@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