Re: The Perfect Emulator?

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

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

>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?  (It sounds like the additional cost
is about a dozen or less PC instructions per Apple instruction
most of the time.)

Of course, such extreme "acceleration" could be viewed as
"ludicrous speed", and therefore of little marginal value.  As
hardware speeds continue to increase, approximations to
improve emulation performance (and indeed any kind of
optimization) may well become irrelevant.  ;-)

-michael

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