[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Apple emulators that support "floating bus" video sensing?
Dirk Thierbach wrote:
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.
Then we should allow the user to decide, because many animations
were done to run at *exactly* the speed intended by the designer.
Running them ten times faster makes about as much sense as running
a movie at 10x speed!
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.
Correct. That's an advantage that we have now, since all the cards
have already been dealt.
And I'm sure that there were at least some programs that were designed
to take advantage of acceleration without running their whole opening
animation less than a second. Admittedly, those would have been late
arrivals on the scene, and so limited in number.
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 :-)
Again, that's simply a truism for any program that doesn't sense
real-time, since all pacing is simply processor execution.
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).
But there is no standard implementation of a real-time clock with
reasonable (frame-rate) resolution. I'd bet that there are more
emulators that emulate floating bus video sensing than implement
such a clock.
And besides, the real issue is running on *real* machines--that may
be accelerated (in fact a larger fraction of them are, these days).
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.
I didn't say it couldn't be configurable--in fact I think I said
it should!
Think about how many programs use sound that are unusable under
emulation. Now think about how all these programs would now work
(and sound) fine, regardless of the "emulated speed".
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.
Any program that used VBL for animation sync would be an example.
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.
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 agree.
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".
And by that you mean choose 1MHz as the constant, global speed,
regardless of whether a particular program behavior is occurring.
Not so smart, I'd say.
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.
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?
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.
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 :-)
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. That's why the Zip
Chip keeps running slow for 5ms after the last speaker reference--so
that as long as speaker references are occuring "often enough", the
speed stays slow and constant. And 5ms after the last speaker
reference, the processor is blasting ahead again.
-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."