On Mar 20, 10:43 am, "Michael J. Mahon"  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 :-)

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

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.

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

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

Matt
--- SBBSecho 2.12-Win32