[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cycle By Cycle Emulator



Bryan Parkoff wrote:

<snip DirectX part>

>    Now -- about sound and Disk II.  Michael mentioned that it has nothing
>to do with MPU's cycle that will work with sound and Disk II.  Let says, MPU
>operates at 1 MHz while sound operates at 28Hz.  Would 28Hz be stealing 1
>MHz's time?  It is very difficult to make the frequency to match the sound
>28Hz.  MPU instructions have to spend 1 MHz to make sound works.  Now,
>compare to Disk II.  Disk II must use the same 1 MHz that Disk II must spend
>36 cycles to create one valid byte through LDA C08x,X loop.  If MPU's 1 MHz
>is not fixed, 36 cycles will be wrong in the wrong time.

I'm not sure I understand what your question is here, but will attempt to
correct some impressions--if not of what an emulator does, then what
I said.  ;-)

I said that (given the nature of .dsk and .nib formats) emulators do not
need to keep track of the disk's rotational position, since they either
"scan" the disk image for the desired sector or index into it--both time-
independent actions.

Sound simulation (and I mean the speaker) _is_ dependent on the
exact durations of instruction executions, which must be know to
capture the correct times for speaker toggles

How an emulator uses the toggle times to generate simulated
Apple sound is another, many-spendored question, running all
the way from flipping the PC speaker state to generating a PCM
stream which, when DMAed, produces the Apple sound.  The
latter approach requires some DSP work to correctly resample
the sound for the desired output rate.

My sound playback software DAC uses a 22.05kHz pulse-width-
modulated speaker waveform to produce 5-bit-accurate sound
from 11.025kHz 8-bit samples.  If an emulator doesn't resample
this speaker waveform properly, the sound is distorted in a way
that it is not on a real Apple II.

If it attempts to slow down to 1.0204mHz Apple II speed and just
"plunk" the PC speaker, then it is also distorted, since its ability
to adjust speed to match an Apple can be somewhat irregular,
and this irregularity can be audible.

Creating a smooth flow of simulated Apple time and keeping it
smooth in _real_ time is hard.

-michael

Check out amazing quality sound for 8-bit Apples on my
Home page:  http://members.aol.com/MJMahon/