Re: The Perfect Emulator?

[mjmahon@aol.com (Michael J. Mahon)]

Bryan Parkoff replied:

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

Yes, this is the idea (I'd have to check the exact cycle counts).

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

No, I'm saying that most animation is well-rendered by making
frame-level updates.  The monitor only shows each pixel every
1/60th of a second, regardless of the rate or time at which it is
updated.

Many regard page-flipping animation synchronized to VBL as
the smoothest form of animation, since each frame is static
during the time that it is being displayed, and is only updated
while it is invisible.

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

No, I mean that the display displays each pixel only once per 1/60th
of a second, regardless of how many times it is updated.

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

There is much more to implementing fractional tracks than keeping
track of the current rotational position of the simulated disk, though
that would be required as well (but certainly not to sub-instruction
time resolution).  Keeping an accurate cycle count does not imply
keeping it at a resolution of one cycle.  By definition, software does
not see anything at a resolution under one instruction execution.

-michael

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