Re: The Perfect Emulator?

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

Bryan Parkoff asked:

>    Do you think that you will be able to program Apple II Emulator into
>perfection with accuracy?

Accuracy of emulation is relative to the objectives of the emulator.

Most Apple II emulators have the objective of running most Apple II
software unchanged, so that it appears to be running on a real Apple.
They generally achieve this objective well.

>    Many Emulator projects use to add 2, 3, 4, 5, 6, and 7 cycles each
>opcodes.  I don't understand why the programmers are doing their way because
>it is not always accuracy.  It makes me to ponder how MPU can only execute
>one cycle at one time.
>    For example, $A9 for LDA $#XX takes two cycles.  First, MPU executes $A9
>for first one cycle.  Second, MPU should be repeated for $#XX by ignoring to
>execute $A9 because it is done already.  Second one cycle will be taken.
>    Let says...Cycle = Cycle + 1 for $A9 and Cycle = Cycle + 1 for $#XX.
>MPU has to loop twice to take two cycles.  The Emulator project does its own
>way to loop MPU once to take two cycles that looks like Cycle = Cycle + 2.
>The programmers do not want to loop MPU every one cycle because they think
>that it will slow the performance.

Keeping a cycle-by-cycle accurate emulated cycle count is not relevant
to the objective of running practically any Apple II software.

One of the very few examples of a program which would require this
detailed accuracy for correct appearance is a program which uses
software to synchronize with the video refresh in order to perform
synchronous video mode switches.  Although there are a few demo
programs that use this technique, to my knowledge it has never been
used in commercially-released software.

Therefore, providing support for this level of cycle-counting accuracy
would reduce emulator performance for very little practical gain.

>    Phase 0 is already used for $A9 and $#00.  Now, 'A' is at $400 and 'B'
>is at $401 for Text mode.  The 7 pixel in the first row for 'A' is displayed
>in the screen using Phase 1 during $A9.  Another 7 pixel in the first row
>for 'B' is displayed in the screen using Phase 1 during $#00.
>    If it is true what I claim above, Phase 1 will be used for Video Scanner
>and RAM Read or RAM Write.  If 17030 cycles are reached, the complete
>280x192 pixels display in the screen.  I don't know how 7 pixels work in the
>horizontial scan per state.  It should be 7 pixel X 65 state equal 455
>pixel, but how can 560 (double resolution) be used?  Should it be 14 pixel X
>65 state equal 910?  It makes sense that 280 is out of 455 for screen while
>175 is blank for left margin and right margin.  It looks like NTSC has only
>119,210 pixels for TV, but 53,760 pixels are used for Apple II.

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

>    Why don't the programmers want to update 7 pixels each one 6502 cycle
>instead they want the complete screen to be updated every 17030 cycles?
>Have you tried to be done already that you found to be poor performance so
>17030 cycle is the option to update 53,760 pixels instead of 7 pixel each
>one cycle?

The video display of an emulator is actually a function of the host machine
video generation.  The emulator simply maps visible Apple II pixels into the
video memory of the host, and it displays them however it will.

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

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

-michael

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