Egan Ford

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.

Questions:

1. Does anybody know the upper frequency limit of the cassette input
port?
2. What about the iPhone/iPod output frequency limit?
3. The Apple //e does 1.023 (1020484?) cycles/s, excluding PAL, how
variable is that number?

I am still in debugging mode and may just drop this altogether. If I
had to speculate the iPhone will not output 32K tones. I'll continue
my research/troubleshooting around xmas time, but if you have any
thoughts I'd appreciate it.

Thanks.

D Finnigan

Egan Ford 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.
>
> Questions:
>
> 1. Does anybody know the upper frequency limit of the cassette input
> port?

The limitation is the microprocessor frequency, as well as the time it takes
to execute the necessary instructions to address the cassette port.

This post from Mr. Mahon might help too:
http://macgui.com/usenet/?group=1&id=204003

--
]DF$
Mac GUI Vault - A source for retro Apple II and
Macintosh computing.
http://macgui.com/vault/

Egan Ford

On Nov 27, 12:19*pm, dog_...@macgui.com (D Finnigan) wrote:
> Egan Ford 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.
>
> > Questions:
>
> > 1. *Does anybody know the upper frequency limit of the cassette input
> > port?
>
> The limitation is the microprocessor frequency, as well as the time it takes
> to execute the necessary instructions to address the cassette port.

Yes, clearly. Let me restate my question. Is there any obscure HW
limitation not emulated in emulators that would prevent higher
frequencies to be used.

Kevin Dady

On Nov 27, 2:44*pm, Egan Ford <dataj...@gmail.com> wrote:
> On Nov 27, 12:19*pm, dog_...@macgui.com (D Finnigan) wrote:
>
> > Egan Ford 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.
>
> > > Questions:
>
> > > 1. *Does anybody know the upper frequency limit of the cassette input
> > > port?
>
> > The limitation is the microprocessor frequency, as well as the time it takes
> > to execute the necessary instructions to address the cassette port.
>
> Yes, clearly. *Let me restate my question. *Is there any obscure HW
> limitation not emulated in emulators that would prevent higher
> frequencies to be used.

not that I know but you have to keep in mind what emulators are, which
is software implementations of other hardware than what you physically
have .. the apple II does not have 16+ bit sound cards with buffers
while being backed up with gigs of ram and multicore multigigahertz
computers with multitasking operating systems.

On the other side your emulator is not directly tickling bits of
silicon in the sound card, so there is a gap... your linux/windows/osx
os and supporting hardware is taking the data from your sound card
(which probably has more cpu power than the apple II) and is piping it
though many layers of software to the emulator software, where it is
handled once again thought the OS, and then directed to a virtual
machine

Egan Ford

On Nov 27, 5:43*pm, Kevin Dady <ke...@hackaday.com> wrote:
> On Nov 27, 2:44*pm, Egan Ford <dataj...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Nov 27, 12:19*pm, dog_...@macgui.com (D Finnigan) wrote:
>
> > > Egan Ford wrote:
> > > > I just spent my yesterday creating a new cassette input method thatis
> > > > ~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.
>
> > > > Questions:
>
> > > > 1. *Does anybody know the upper frequency limit of the cassette input
> > > > port?
>
> > > The limitation is the microprocessor frequency, as well as the time it takes
> > > to execute the necessary instructions to address the cassette port.
>
> > Yes, clearly. *Let me restate my question. *Is there any obscure HW
> > limitation not emulated in emulators that would prevent higher
> > frequencies to be used.
>
> not that I know but you have to keep in mind what emulators are, which
> is software implementations of other hardware than what you physically
> have .. the apple II does not have 16+ bit sound cards with buffers
> while being backed up with gigs of ram and multicore multigigahertz
> computers with multitasking operating systems.
>
> On the other side your emulator is not directly tickling bits of
> silicon in the sound card, so there is a gap... your linux/windows/osx
> os and supporting hardware is taking the data from your sound card
> (which probably has more cpu power than the apple II) and is piping it
> though many layers of software to the emulator software, where it is
> handled once again thought the OS, and then directed to a virtual
> machine

It's actually simpler than that. Virtual ][ (as does OpenEmulator)
emulates the cassette ports. When simulating a tape load it just
reads the sound file directly. It's just data. You couldn't get any
more perfect world scenario than that.

mwillegal

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

Egan Ford

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.

Michael J. Mahon

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

Marc S. Ressl

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.-

Egan Ford

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.