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:
>
> > Perhaps, but I think that any program spending its time maintaining
> > a "split" would not be doing anything that required acceleration
> > in any case.  
>
>
> Nothing "requires" acceleration. But it's nice to have, because you
> can for example speed up a game during animations that are always the
> same, and hence boring.

Well, I don't want to rule out the possibility of programs that
are designed to run with acceleration--I expect there are some.

And trying to make this into a "feature" for editing out "boring"
material that the author intended hardly seems appropriate.  (I'd
really appreciate adding a spell checker to COUT so that I wouldn't
have to read so much misspelled text!  ;-)

As an aside, it seems that whatever else programmers were doing,
it wasn't studying their spelling lists.  ;-)

In any case, all of this should be configurable, just as the constant
emulated clock speed is now on most emulators.  So bored users can
make the intro go faster than they can see.  ;-)

> > And if it were doing something useful besides splitting
> > the screen, it would likely be animation, which should be run at 1MHz
> > to obtain the original intent.
>
>
> The problem is not the original intent (if that would be the goal,
> then the simples thing is to always run at 1MHz). The problem is user
> experience, which is greatly enhanced if he can speed up things from
> time to time, under his control. Speed up as in "everything suddenly
> is faster, because it was too slow before". And that includes framerates.
> At least that's how *I* use this feature of emulators :-)

So you should be able to press a key or click an icon and do that.
What I'm suggesting is a way to get faithful rendering of the author's
intent while also obtaining the benefits of acceleration, as appropriate
(but switching much faster than I could press a button).

> > It would be a lot nicer to run the computation at full-bore, but
> > have a simple way to slow down the screen updates and waits so that
> > what is intended for a human to watch would run at constant speed.
>
>
> In other words, you want to something that ordinary Apple II's couldn't
> do, namely have a program that is aware if acceleration.

Nonsense!  I've already described how ordinary Apples can do this!

> That's fine,
> but then you need not restrict yourself to what ordinary Apples could
> do. Acceleration is an extra piece of hardware not found in an ordinary
> Apple, so there's nothing wrong with assuming that you have extra 
> "pseudo-hardware" in an emulator like a real-time clock.

Actually, it's always in "ordinary" Apple IIc+'s and IIgs's, and is
found in a relatively large fraction of other Apple II's today.

You seem to be fixated on emulators.  I'm trying to find a way to
write a program for 1) all real Apple II's, with or without
acceleration, and 2) at least a few popular emulators--just so
their users won't be left out.

I'm satisfied that I've accomplished 1), and a bit frustrated that
you don't see the benefit of 2)!

Rather than looking for "reasons why emulators are perfect", how
about looking at how they might be better, by enabling the goal
of user-speed interaction running on both real Apples and emulators,
while delivering the benefit of higher-speed execution?

> > As I've said, I found a way to do this for all real Apple II's,
> > with or without acceleration, but emulation seems not to be equivalent.
>
>
> If there are no programs using it, and if the programs actually using
> the vapour-lock would behave incorrectly, why should the emulator
> be geared towrads "wrong" behavior? The emulator should work correctly
> with respect to an ordinary Apple (without acceleration), and for
> anything else, it should do what's most convenient. Breaking existing
> programs just because those programs would break down in the same
> way on an Apple with hardware acceleration is not particularly
> convenient.

But the emulator is *not* an unaccelerated Apple--it is usually grossly
accelerated.

I put it to you that there are far fewer programs that would break under
the model I'm suggesting than are already broken by the model you are
supporting.

Any program using sound is an example.  They work fine on my accelerated
Apple //e, and on my unaccelerated Apples, but don't work on an emulator
unless I set it to 1MHz.

Admittedly, most programs that use a programmed "wait" time wait "fast"
under acceleration--but that's only because their programmers didn't
account for the possiblity of acceleration (by using floating bus data).

Now that the proportion of "Apples" (emulated or not) with acceleration
is much higher, it makes sense today to write programs to be cognizant
of acceleration, without requiring new mechanisms like real-time clocks
that would be unlikely on real Apple II's.  Ironically, emulators have
not made respecting real-time possible, though real Apples always have.

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