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

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

Michael J. Mahon <mjmahon@aol.com> wrote:

To keep this discussion more concentrated, I'll pick points from all
three postings, and combine them into one.

> Then we should allow the user to decide, because many animations
> were done to run at  exactly  the speed intended by the designer.

Yes, of course. And as most programs don't take accelerated Apples
into account, the user already decides.

> Running them ten times faster makes about as much sense as running
> a movie at 10x speed!

That makes actually a lot of sense. All VCRs have a "fast forward"
button, which you can use to run the movie at a multiple of normal
speed, so you can skip over parts that are not important.

> And trying to make this into a "feature" for editing out "boring"
> material that the author intended hardly seems appropriate.  

But that's how I use the emulator all the time. When I play Apple
games with the emulator, at the beginning I speed up everything so
it loads fast and skips the intro screen. When the real game begins,
I slow down again. If the game happens to be hard, I can also cheat
and let the emulator run slower than 1MHz. 

In other words, I have a speed control, and I want the emulated program
to speed up and down according to my choice. And because most Apple
programs are not aware of acceleration, that's how they behave by default.
Now if a program comes along which behaves differently (I want it
to speed up, but it refuses and renders the animation at the same
rate), then the user would be very confused, because that's inconsistent
with the behaviour of the other programs.

So this should be the *default* behaviour. I'm not against allowing
the user to be able to configure it differently, but the default
behaviour should be consistent.

> (I'd really appreciate adding a spell checker to COUT so that I
> wouldn't have to read so much misspelled text!  ;-)

I'm not really sure what you mean here. If I misspelled too many words,
I apologize -- after all, I'm not a native speaker, and I'm too lazy
to check every word with the dictionary :-)

> Which is exactly when they  must  run at 1MHz to produce the intended
> sound!  And whenever they are not producing sound, they run as fast as
> the emulator can go.  Get it?

The problem with that is that many games are producing sound all the
time, which means you cannot speed them up as outlined above. Wrong
behaviour.

> It means that my programs continue to behave usefully whether
> accelerated or not, and I don't have to keep turning acceleration
> off and on.

If they behave usefully when not accelerated, then one can just
switch to 1MHz to make them "behave as intended", and switch speed
if the user wants to run them faster or slower. 

> It's not just the pitch, its the pace.  Time itself must be slowed down
> to 1MHz if the user is to hear what was intended. 

But the user doesn't want to "hear what was intended", the user (at
least me) wants to speed up the program if he chooses to do so. The
annoying effect here is then that the pitch is wrong. What really
should happen is that just the pace accelerates, the pitch stays the
same. Which is usually the intention behind "speeding up".

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

But we shouldn't design behaviour of the emulator with respect to
prgrams that "might be there". If there are no or very few such programs,
then the emulator should be designed to cater for the available programs.

And if you want to write new programs that are aware of being 
accelerated (which is fine with me), and one would have to change most
emulators anyway to be able to support that (which is also fine with
me), then one can at least choose a more flexible solution than some
clever "hack" which depends on fringe effects of the actual hardware
implementation.

> I'm not writing this code for just an emulator.  I'm writing it for
>  all  Apple II's--many of which do not have a real-time clock of any
> kind--*except* the video generator!  Do you see what I mean?

Yes, I understood perfectly what you mean right from the beginning :-)

> My objective is quite simple:  to provide the best possible experience
> on the widest possible range of Apple II implementations--including
> emulators--that can be achieved with simple methods. 

And that's also my objective. We just have a different opinion about
the "best possible experience". You want the experience to be as the
writer of the program intended it. I want the experience to be what
the user wants it to be, and that includes "fast-forwarding" it if he
feels like that.

> (And by that, I mean not doing seven different things based on the
> machine it's running on.  ;-)

But you are already have to do something to distinguish between two
type of machines: "Normal" Apples without acceleration, and
hardware-accelerated Apples. And you're doing it using a somewhat
obscure "feature" of the hardware. (BTW, would it work correctly
for European Apples with PAL?). Then it's not so much effort to
just check for a real-time clock and use those values instead,
isn't it? Especially if the emulator writers can sit down together
and agree on a spec. Such a thing is much easier to implement than
something related to video update, because that's one of the more 
tricky in an emulator. And much more fragile.

It's just a sound engineering principle: KISS. Instead of a clever
hack, provide the information that is *really* behind the whole idea.

And supposing for a moment the emulator which sync the floating bus
to the real-time framerate. Now which framerate? Always 60Hz?
Maybe 50Hz for PAL Apples? Or the real framerate of the monitor,
which would today be over 100Hz? Or the rate with which it updates
the image from the Apple's framebuffer?

No matter which you choose, there'll be always some program that
wants to use a different choice for that information. So why not
provide the real information to the program that it is after? (which
is, in this case, emulation speed)

> But there is no standard implementation of a real-time clock with
> reasonable (frame-rate) resolution.

Then all the more important to get together and make one.

> I'd bet that there are more emulators that emulate floating bus
> video sensing than implement such a clock.

So far we found out that AppleWin implements floating bus, but
not synchronized video update. The apple emulator for linux I have
here in front of me already has this RTC. I guess it's deuce :-)
BTW, the author of that RTC writes:

: I'd like to develop a standard for benchmarking timer support across
: 8-bit emulators, including ID bytes so that this virtual "card" can
: be detected automatically.  This feature is only a prototype, and I
: may alter it significantly on suggestion from others.

> And besides, the real issue is running on  real  machines--that may
> be accelerated (in fact a larger fraction of them are, these days).

If you're mainly interested in real machines, anyway, then I'd say
just go ahead and implement the way you want it :-) As long as you
provide a default fallback to "unaccelerated" when you cannot sense
a floating bus, it should work fine on all emulators -- with the 
limitation that unless the imitate floating bus behaviour the way
it is on an accelerated Apple, it will just run at 1MHz in the 
emulator. This may not be what you intended, but it will work :-)

> But that's really beside the point.  I'm suggesting that there was
> already, long before practical emulators, a fine model of how to
> speed up a processor without disrupting real-time activities (like
> sound), and that this model has been disregarded by emulator writers.

I can't speak for "emulator writers", but personally, I don't think it
is a fine model. It's a bad model, which was necessary to make the
accelerator work at all. In this model, I cannot do what *I* want
(speed up or slow down the emulated program as I like it). The
accelerator make some assumptions about at which time I would want
which speed, and just acts on it. But these assumptions don't match
what I really want. So the accelerator tries to outsmart be, and
guesses wrong. And that's very annoying.

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

I do see the benefit of (2), but I also see the disadvantages
of using some "clever hack" instead of doing it "properly". And I
especially don't like if some program assumes it is smarter then me
and tells me what I should want. If I want to "fast-forward" it, 
and it refuses, then I'm not going to like it. 

> Rather than looking for "reasons why emulators are perfect", 

I'm not looking for reasons why emulators are perfect. They are not.
I'm looking for ways to implement *my* wishes so it does what *I*
want :-)

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

That's fine. Then do it properly, and allow the program to do a precise
and simple measurement of the current acceleration state. By a RTC
or otherwise. "Acceleration" is an extra piece of hardware, so it should
be treated like an extra piece of hardware of the program wants to be
aware of it.

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

But the emulator *pretends" it emulates an unaccelerated Apple. That's
the point.

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

So far I'd see that all programs that habe been mentioned which make
use of the vapour lock (split screen, tear free update) would break
under your model (as they do under a hardware accelerator, unless it
slows down to 1MHz), while your program wouldn't break under my model
(it would just run as it would on a 1Mhz Apple, with the option for
the user to "fast-forward" it). True, it wouldn't behave as intended
(use the extra speed for its own means), but that is different
from breaking.

Again, I'm not against giving programs the opportunity to learn that
they run faster than 1Mhz, it's just that I think the first concern 
and the default behaviour should be correctness.

- Dirk