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

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

Sorry for taking longer to respond than usual, but I'm "on the road"
and getting time to access csa2 is a bit trickier.  I'm also
constrained
to using Google Groups to respond, so bear with any formatting
problems.  ;-)

A real benefit to the delay is that I have had a couple of days to
consider your reply, and it has allowed me to see that we have been
arguing at cross purposes--not too surprising, I suppose, since I
tend to think that reasonable people can come to agreement when the
objectives and means are clear.  ;-)

I also note that several of my impromptu responses to your earlier
posts were not helpful, often generating more heat than light.  ;-)
I'd like to retract those below...

On Mar 21, 2:01 am, Dirk Thierbach <dthierb...@usenet.arcornews.de>
wrote:
> Michael J. Mahon <mjma...@aol.com> wrote:
>
> To keep this discussion more concentrated, I'll pick points from all
> three postings, and combine them into one.

I appreciate that, Dirk, and will try to keep our conversation better
organized, too.  ;-)

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

My injection of the "designer's intent" was something of a red
herring,
since you clearly are discussing what you like to do after you have
already experienced that intent at least once ;-) and are simply
speeding things up for pragmatic reasons, which I fully support.

I, too, am a frequent user of fast-forward and rewind, and I would not
be without them!

Therefore, nothing I would propose would affect our capability to
adjust the rate of emulated time passing as we see fit.

> > (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 :-)

That wa not directed to you at all, but to the many programmers who
incorporate misspelled words (or even homophones) into messages they
display on the screen--not that I'd ever want to tamper with "All your
base are belong to us!"  ;-)

I was just making a joke about putting in-line spelling correction
into COUT to correct programmer's misspellings.

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

Good point.

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

Actually, my concern is that most users of accelerated Apples do not
or cannot easily change speed while within a game.  They must usually
pick a speed and stay with it throughout the program.  In this case,
unless the speed is automatically controlled, any content requiring
1MHz speed would also require that the rest of the program be run
without benefit of acceleration--which in some cases would be quite
a significant sacrifice.

The alternative of running the program once to see its "aesthetic
effects"
and then again to allow convenient use, is bad enough to make me want
to
not provide any introductory animation at all.

So I started down this path of trying to find a way to render both
the animation and sounds at a chosen rate and the game play at
whatever
degree of acceleration was available.

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

I understand your point.

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

Here we come to my real objective:  to make it possible to write new
programs which are cognizant of the current prevalence of
acceleration,
whether by hardware add-ons to real machines or by emulation.

When an emulator is running in its current (default?) mode, I agree
that
it is not emulating an accelerated Apple, but is emulating a 1MHz
Apple
running faster than real time.  I have no objection to this mode, nor
to
it's being a default.

What I would like is a selectable mode in which real time *is* able to
be sensed.  I understand and agree with you that a standard real-time
clock would be a very clean way to achieve this.

But there is a problem:  real Apples do not have such a "clean" real-
time
clock.  There are lots of machines out there that have one or another
type of real-time clock, and lots that have none at all, and it is not
possible to retroactively standardize a hardware component that is not
in the base machine.

In fact, it is probably not possible to standardize such a mechanism
even
in the majority of emulators, though that would be a good thing.

Instead, the only guaranteed, universally available mechanism for
sensing
real-time in any Apple II is the floating bus hack.  The fact that it
always works, even though sometimes it runs at 50Hz and sometimes at
60Hz,
takes it out of the "flaky" category and puts it into the "exotic but
reliable" category.

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

Again, I fully support this mode, despite whatever impressions I may
have given.

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

Well, it seems that implementing floating bus video with real-time
timing is not so difficult--it's synchronizing it with frame buffer
rendering that is hard.

That's actually OK, since very few emulators seem to handle "vapor
lock" screen splits anyway, but giving an Apple program the ability
to sense real-time on an emulator in the same way that it does on
a real Apple would actually be fairly easy and robust.

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

Ah, yes--but in this case the problem includes working on the earliest
Apple II's, which are already designed.  This "backward compatibility"
constraint is a real part of the problem if you want to encourage new
programs to be written for the broadest possible set of users.

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

I've already noted that the first-order purpose of a new emulator
mechanism is to permit a program to sense the passage of real-time
at an *approximately* standard rate (50Hz/60Hz is not a big problem).

If someone wishes to extend the mechanism to synchronize with video
rendering, that would be great, but certainly not necessary for the
most significant benefit, which is not splitting the screen in real-
time, but transparently gaining the benefit of any available
acceleration
without distorting the time scale for human interactions too much.

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

;-)  But here we'd have to change the past.  ;-)

Since I'm committed to supporting real Apples first, I must use
the only mechanism that works on them.  If the same mechanism
worked on a few emulators, then there would be a clear path for
programmers who desired to explicitly support acclerated machines.

If we design a beautiful interface for emulators, then we will have
at best two different ways to do things, which would be unfortunate.

(BTW, I have no issue with *also* implementing a high-resolution
real-time timer for emulators, or even making it available as an
optional card for real Apples.  My only problem is *requiring* it
to run my program!  ;-)

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

The "natural" implementation is one that times out when it fails to
sense floating bus data--but to work reliably on accelerated machines,
that timeout must be chosen for an acceleration rate higher than any
likely to be encountered.  The result is that if floating video data
is not sensed, the delays are considerably longer than 1/60th second.

I have prototyped other, more adaptive schemes, and may need to
return to them if there is no other solution.

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

I certainly agree that the constraints imposed by full backward
compatibility lead to less than straightforward solutions.  But they
do work.

As I've said, I support your desire for a "faster than real-time
1MHz Apple II emulator", but I'd also very much like to see an
emulator
mode for a "Zip Chip accelerated Apple II".  (The Zip Chip approach
has
a special status because it was chosen as the native architecture of
the
Apple IIc+.)

-michael