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

["Michael J. Mahon" <mjmahon@aol.com>]

Dirk Thierbach wrote:
> Michael J. Mahon <mjmahon@aol.com> wrote:
>
> > Well, the consequence is that any program using animation needs
> > to run at 1MHz emulated speed.  This is not the case for an
> > accelerated machine.
>
>
> No. The consequence is that any program using animation needs to
> *think* that it runs on 1MHz speed. Because most, if not all Apple
> programs do. There's no hardware I know of in the original Apple that
> would allow it to check if it runs on an accelerated processor.

Just the video generator.

And the requirement for animation is that the updates occur at
specified points in real time, so if that's what you mean by
a program *thinking* that it's running at 1MHz, OK,

But, in fact, the processor can run at any speed, and animation
can benefit from this, as long as the screen updates occur at the
appointed times.  A slow machine just waits less--or misses the
update times and runs the animation slower,

> But if there happen to be such programs, and the did indeed use a
> video-refresh cycle vs. internal speed check to find out at which speed
> they ran on an accelerated machine, then one could of course cater
> for these programs in the emulator and just let the frame-buffer
> refresh and floating bus run at 30Hz relative to real-time. 

(That would be 60Hz...)

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

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

> > Oh, well--I hoped I had found a way to combine fast game computation
> > with correct-speed animation and delays.  Apparently not for emulators.
>
>
> > Most accelerators went to some lengths to achieve implementation of
> > processor acceleration combined with standard speed sound and (if
> > needed) disk access.  
>
>
> So how did they do that?

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.

The effect of these rather simple mechanisms is that virtually all
programs run both accelerated and properly with no other attention
from the user or the programmer (who typically didn't know his program
would ever run under acceleration).

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

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

-michael

NadaPong: Network game demo for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."