Re: 64/65 Cycle Rule?

["Bryan Parkoff" <spam>]

Eric,

    Are you saying that half 6502 cycle access to RAM and another half 6502
cycle access to Video Circuitry?  It is why Video must update 560x192 pixels
every 6502 cycle.  Correct?

Bryan Parkoff

"Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message
qhsmnqaez5.fsf@ruckus.brouhaha.com">news:qhsmnqaez5.fsf@ruckus.brouhaha.com...
> "Bryan Parkoff" <spam> writes:
> >     For all Apple II family, 64 out of 65 cycles only process inside
6502
> > CPU until it reaches 65 out of 65 cycles before it starts to process
ouside
> > 6502 CPU such as RAM and Video Scanner.
>
> Wrong.  Of every CPU clock cycle (slightly less than one microsecond),
> the video circuitry gets one memory access, and the CPU gets one memory
> access.
>
> One out of every 65 clock cycles is stretched slightly in order to keep
> the color subcarrier phase constant from one line to the next, rather
> than the normal NTSC timing in which the subcarrier phases shifts by
> 180 degrees on successive lines.
>
> The stretched 65th cycle has NOTHING to do with what the CPU processes.
>
> > It is what I understand that half
> > 6502 cycle, one instruction can be fetched and executed until half 6502
> > cycle goes high from low before data in the data bus is being stored
into
> > RAM during Video Scanner is being processed.
> >     The step by step such as serial can't be done in turn by turn.
Parallel
> > must be done such as data parallel at the same time.  6502 CPU, RAM, and
> > Video should be in parallel lines so the process can be done at the same
> > time.  The problem is that Emulator has to use serial instead of
parallel so
> > 6502 CPU must be executed first before Video must be executed second at
> > another time so they can't be done at same time.
> >     Have someone tried to use MMX or SIMD Technology that will help
Emulator
> > to run faster without needing to have turn by turn between 6502 CPU and
> > Video.
>
> Simulators don't need to alternate processing CPU and video cycles,
because
> they don't have any hard-real-time constraint on when the video is
updated.
> MMX, SSE, and other SIMD extensions are generally not helpful for this.