Re: The Perfect Emulator?

[Sheldon Simms <sheldonsimms@yahoo.com>]

On Tue, 30 Sep 2003 07:29:58 +0000, Michael J. Mahon wrote:

> Sheldon Simms replied:
> 
>>Basically, writes to video memory cause the appropriate pixels to be
>>written into offscreen buffers. After every instruction, the amount
>>of raster beam advance (in units of 14Mhz cycles) is calculated and
>>that number of dots (what you might consider DHGR pixels) is copied
>>into the output window at appropriate locations from the offscreen
>>buffer corresponding to the current video mode.
> 
> Very nice!
> 
> Do you use this precise timing to return the correct "phantom"
> byte from the video refresh when the CPU does a load from a
> non-driven location (to support "vapor lock" software)?

At the moment, reading $C070 returns the byte at the last
location read by video refresh. I'm not sure this is completely
correct but it worked for whatever program I was trying to get
to run at the time.

>>This process is sped up considerably by skipping as much of the work
>>described above as possible when the result would look the same as
>>whatever was already in the output window. It ends up being quite
>>a bit faster than a real Apple II on my PC** even when the screen
>>is being changed a lot.
> 
> I have no doubt that it is faster than a real Apple--but do you
> know how much faster it would be without this video handling?
> Put another way, can you emulate a 60MHz Apple, like some
> emulators on your hardware?

The fastest I have seen is around 45Mhz with a (mostly) static
screen. When the screen is being very rapidly updated, it slows
to around 10Mhz. I have pretty much always traded off speed for
code simplicity when the result was "fast enough". Obviously
"fast enough" is subjective and dependant on the emulation
platform.