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

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

mdj wrote:
> On Mar 20, 10:43 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
>
> > > Actually, this isn't strictly true. On a IIe, the $C019 softswitch
> > > will read with the high order bit set during (and only during) the
> > > vertical blanking interval. On a IIc, the same softswitch will read
> > > with the high order bit set if a VBL interrupt has occurred since the
> > > last time it was read.
> >
> > > For practical purposes, being either waiting for VBL to draw, or using
> > > it as a real time event source, software that polls the softswitch
> > > will behave identically on both machines, assuming you read the
> > > softswitch at least every 1/60th of a second.
> >
> > But if you read it *very* often, while polling, you would observe only
> > one instance of the high bit set, right?  And is it only set "if a VBL
> > interrupt has occurred"?  If so, that would be a problem if I don't
> > want VBL interrupts to occur.
>
>
> Well, there's no reason not to have them occur :-)

Actually, they disrupt sound generation...

> > That's actually pretty different behavior, since the normal way to use
> > it is to poll for one state, then poll for the other.  (This is to allow
> > the polling routine to be re-called before the polled-for state ends.)
>
>
> I guess I just can't imagine a use-case for it. Since the transitions
> aren't symmetrical they're not useful as a high(er) resolution timer,
> and calling a routine a potentially arbitrary number of times would
> destroy real-time determinism.

The important case is repeatedly re-calling a frame delay routine
for a certain number of times to obtain a fixed delay.  If you do
this and the routine does not wait for the "triggering" event to
be inactive, then it returns immediately--an incorrect result.

> In order to reliably use the VBL as a timer, you have to act on the
> state-transition, which requires observing it in both states. All
> having it self-reset is going to cause is recognising the 'low' state
> earlier which is potentially an advantage. Since the applications
> output is synchronised to a real-time event, there'd be no discernable
> behavioral difference, even though the underlying hardware is behaving
> quite differently.

I agree--I see we're saying the same thing.

And I now agree that this "one poll" behavior would not cause a
behavioral problem.

> > > The catch is, $C019 is also used to indicate mouse button and movement
> > > activity whilst the mouse firmware is active, so you cannot reliably
> > > poll it on a IIc if your program is also using the mouse.
> >
> > A complication, but one I'd be willing to ignore for my uses...  ;-)
> >
> >
> > > I'm not 100% sure since I don't have a IIc handy that I can test with,
> > > but I also have an inkling that VBL interrupts must be active for this
> > > to work on a IIc ($C05A disable, $C05B enable), and I'm relatively
> > > sure they're disabled by default. Of course, you also have to ensure
> > > (processor) interrupts are disabled or the firmware is going to handle
> > > them for you...
> >
> > Ah, there's the rub.  I really wouldn't want to enable VBL interrupts.
> >
> >
> > > I guess Apple decided that the relatively short amount of time the IIe
> > > spent in the wild before the IIc appeared meant it was OK to change
> > > the behaviour? Most software would have used the floating bus method
> > > to remain II/II+ compatible so the impact on developers was minor.
> >
> > That was my thinking, as well, and why I decided to go with the floating
> > bus approach to detecting video frames.
>
>
> Yeah... I think this approach has the greatest reach on actual
> hardware. Using a VBL interrupt (activated by AppleMouse firmware)
> potentially has greater practical reach, since all IIgs and many IIe
> emulators implement it. And I would imagine the diehards among us
> still using real 8-bit machines have a Mouse card lying around.

Actually, mine is not plugged in, and hasn't been for years.  ;-)

> > > And for the IIgs? I have no idea... Can someone shed some light?
> >
> > > I must admit I am *very* curious about what it is you're trying to
> > > achieve that requires both the possibility of an accelerator being
> > > operational *and* a real time clock source .... ;-)
> >
> > Actually, pretty simple.  I'd like to run an animation at a certain
> > rate independent of processor speed, but get the benefit of any
> > acceleration that may be present when searching the game tree.
>
>
> Sounds cool... Can't wait to see it :-)

Soon, I hope...  ;-)

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