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

[Egan Ford <datajerk@gmail.com>]

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

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.