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

[claudiosassou@gmail.com]

Hello there,

I had been thinking about this for some time, and what I found seems
to agree with what you say. In AppleIIGo I'm using a "base speed" (1
MHz) reference for measuring time for video, paddles and speaker
events. This is similar to what kegs does. However, the base speed
changes a little, depending on PAL or NTSC timing.

I've also been thinking about adding intra-line display mode changes,
and it shouldn't be too hard at all. Right now I'm doing it on a line-
per-line basis.

Best wishes,

Marc.-

On Mar 19, 8:28 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
> Dirk Thierbach wrote:
> > Michael J. Mahon <mjma...@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."