Re: The Perfect Emulator?

["Bryan Parkoff" <nospam@nospam.com>]

Michael,
> This reflects a misunderstanding of the way that video is generated on
> the Apple II.  Visible pixels are displayed during only 40 of the 65
cycles
> that comprise each line. (This choice was made to allow a TV set to be
> used for a monitor, since TVs typically "overscan" so that the edges of
the
> picture are not visible.) 40 x 7 = 280, the base hi-res resolution.
Double
> hi-res reads two bytes per cycle (one from the main memory bank and one
> from the auxillary memory bank) and displays 14 pixels per active video
> cycle, for 40 x 14 = 560 pixels.  Although the video refresh generator
> accesses memory during the 25 blanked cycles per line, there is no
> visible video output.  (Since there is no "extra cost" for continuing to
> access memory during the blanked cycles, this is a design simplification.)
    Lets say, first 1-40 cycles displays one line of 280 pixels and second
41-65 cycles displays 175 pixels that looks like horizontial blanking.  Does
it mean that first 1-12 cycles do HBL for left margin before second 13-53
cycles do one line of 280 pixels before third 54-65 cycles do HBL for right
margin.  Is it correct?

> Although there might be subtle animation effects that would benefit from
> a more faithful evolution of displayed pixels in time, that complication
is
> generally not needed (since most Apple II programs at most synchronize
> video memory updates with VBL, and are otherwise not precisely synched
> to the video refresh cycle).
    Are you saying that animation is not needed?  What about Dazzle Draw
that has animation?  It may need HBL while VBL is used for Nintendo 8-bit
(For example).

>
> >    MPU should be looped each one cycle.  Phase 0 does the job for MPU
and
> >Phase 1 does the job for RAM and Video Sscanner.  I think that Phase 0
and
> >Phase 1 should be executed together in the MPU loop each one cycle so it
> >will make Apple II Emulator to be perfect like real electronic timing.
>
> As noted, it would be difficult to justify this level of precision, since
it
> would
> be invisible for almost all software, barely detectible for a tiny
percentage
> of
> software, and necessary only for a few demonstration programs.

    What do you mean invisible for almost all software?  Does it look like
that humans can't detect by watching the display while screen is ploting at
current speed?  You claim invisible -- does it mean that screen is too fast
for us to notice?

    If it is done cycle by cycle, it will make Disk II to work perfect for
copy protection using 1/2 and 1/4 tracks, but emulators don't use copy
protection scheme like NIB does.

Bryan Parkoff