Re: Cycle by Cycle Problem?

["josephoswaldgg@hotmail.com" <josephoswald@gmail.com>]

Bryan Parkoff wrote:
> "josephoswaldgg@hotmail.com" <josephoswald@gmail.com> wrote in message
> 1135645419.080174.318580@f14g2000cwb.googlegroups.com">news:1135645419.080174.318580@f14g2000cwb.googlegroups.com...
> >
> > Bryan Parkoff wrote:
> > > Real Apple II machine always run 6502 CPU at 1MHz and NTSC at 14MHz at
> > > the same time.  6502 CPU depends on clock system in its own.  Also NTSC
> > > depends on clock system alone.  It means that both 6502 CPU and NTSC
> can't
> > > share the clock system at the same time.  It looks like that there is
> more
> > > than two clock system which they can operate independently at the same
> time.
> >
> > All timing on the Apple (except for a few things run off of 555 timer
> > circuits) is based on the (for NTSC) 14.31818 MHz master crystal. In
> > Apple II lingo, this clock is called 14M. The color burst frequency is
> > 1/4th of that frequency, or 3.579545 MHz. In fact, this is why the
> > crystal frequency was chosen.
> >
> > The 6502 clock on the Apple II is not a constant 1 MHz. It consists of
> > 64 cycles of 14 crystal cycles, followed by a 65th cycle of 16 crystal
> > cycles. That 65 CPU cycle period is one horizontal NTSC scan. The
> > result is an average 6502 cycle rate of approximately 1.020 MHz.
> >
> Joseph Oswaldgg,
>
>     Yes, I know about this what Understanding the Apple //e manual
> explained.  The only way is to count nsec.  6502 CPU can be constantly at 64
> cycles + 1 cycle at 1,020,484 Hz, but 65th cycle has a long duration.  It is
> like 64 cycles have whole cycle, but 65th cycle looks like whole cycle and
> extra 1/4 or 1/2 cycle.
>     Do you think that emulation project can record nsec per cycle to match
> 1MHz and 14MHz freq per second?
>
> Bryan Parkoff

Bryan--

  Anything can be simulated, given enough programming and host CPU
time. However, if you are simulating the display using the host
computer graphics, instead of generating NTSC-compatible waveforms,
there is no detectable difference between the long cycle and the short
cycle that shows up in the Apple II behavior. The timing difference is
completely unnoticeable to the user, unless he uses advanced
instrumentation or expansion hardware to observe the electrical signals
directly.

  The only detectable effects on the ordinary hardware are the
synchronization of the video memory accesses and the CPU memory
transactions, including the softswitches; simulating this level of
detail would be necessary for simulating "Vaporlock" and mixed-video
softswitching. These memory accesses occur at a 2 MHz rate. Similarly
the disk-drive sequencer operates at a roughly 2 MHz rate. Only video
shift registers generating the video data operate at the 14 MHz rate.

  If you are concerned about real-time behavior, I believe it is
unlikely you will get repeatable 140-nsec accuracy in *any* timing on a
mainstream operating system. Given a dedicated real-time system, you
might be able to, although I doubt you could usefully simulate an Apple
II at a 1 MHz event rate, but very few people will be interested in
your simulator.

--Joe