Re: Apple emulators that support "floating bus" video sensing?

[Dirk Thierbach <dthierbach@usenet.arcornews.de>]

Michael J. Mahon <mjmahon@aol.com> wrote:
> And the requirement for animation is that the updates occur at
> specified points in real time, 

No. The requirement for animation is that it renders frame after
frame correctly. Nobody says that animation must render frames at
the same speed in an emulation. Actually, it's often really convenient
if you can improve the framerate, because on the original hardware
it was just very slow.

> But, in fact, the processor can run at any speed, and animation
> can benefit from this, 

In principle, yes, but most existing Apple programs we're trying to emulate
don't benefit from this, because they are not programmed to take 
acceleration into account.

> as long as the screen updates occur at the appointed times.  A slow
> machine just waits less

The Apple II is so slow that it usually never "waits" during an animation :-)

> And the video generator is the *only* standard real-time reference
> in an Apple II that may be accelerated, unless there is a standard
> way to slow down to 1MHz.  (Several accelerators do implement a
> _de facto_ "standard" method of slowing down for a period of time:
> a reference to a slow slot's /DEVSEL space--for example, slot 6,
> which usually defaults to a "slow" slot.)

So, again, accelerators implement extra hardware that the program
can make use of. That's fine, then just let the emulators also implement
extra hardware (like the real-time clock, which has other uses) if they 
want the program to be aware that it is accelerated).

>> No big deal, but it would break most programs that actually use the
>> vapourlock in the way it was described in the other thread. As these
>> programs would break on an Apple with a hardware-accelerated processor.

> Indeed, and nothing can be done about that. 

But on an emulator, a lot can be done about that: Just sync floating
bus and video updates to cycle count. And presto, everything works.
And you can even run it and every speed you like, and it still works.
Just faster, which is what the user wanted when he pressed the "go
faster" key.

> But if the only need is to provide real-time *pacing* for some
> action, then video sampling works perfectly on all real Apple II's
> regardless of processor speed.

Yes, but I have still to see an existing program that actually makes
use of that feature.

> They keep state regarding which slots are to be run at full speed and
> which are to be run at 1MHz--and they slow down to 1MHz on any /DEVSEL
> reference to a "slow" slot for a specified number of milliseconds
> (typically around 50ms).  A few other "time sensitive" I/O addresses
> can be similarly configured for slowdown, like the paddle trigger and
> the speaker toggle.

That's easy to emulate, if it should be really necessary to do so.

> I'd make a modest suggestion that emulators that run faster than 1MHz
> make the effort to emulate an accelerated Apple II--to obtain similar
> compatibility and configurability.  (For example, if you want your
> emulated 5.25" disk in slot 6 to run fast, configure it to do so.)

Emulators are actually a lot smarter -- they can emulate disk access
at any speed. So I still don't see the advantage of implementing
which is just a hack to get the hardware-accelerator working. If the
user wants 1MHz, he can just choose "1MHz".

> This would allow sound-producing programs to run properly regardless
> of the emulated processor speed.

Actually, no: It would just slow down sound-producing programs to 1MHz,
so they wouldn't run regardless of the processor speed, they would just
always run at 1MHz if they are producing sound.

But sound is interesting. I think a much smarter way would be to use a
library like soundtouch 

http://www.surina.net/soundtouch/ 

to change the pitch of the sound back when the emulator runs faster.
Maybe I'll try to implement this one day :-)

- Dirk