[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Charlie wrote:
"mdj" <mdj.mdj@gmail.com> wrote in message 4c0d6218-3524-4319-9039-264c24a8bede@d62g2000hsf.googlegroups.com">news:4c0d6218-3524-4319-9039-264c24a8bede@d62g2000hsf.googlegroups.com... 


On Mar 18, 5:20 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:



The objective is not to do something sophisticated, like avoid tearing
of the animation (though that would be nice), but simply to cause it to
run at its intended speed, regardless of the speed of the processor
(emulated or real).

Polling VBL works on an Apple //e, but *only* on a //e, since later
machines de-implemented VBL polling in favor of VBL interrupts.


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.

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.

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

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.

And for the IIgs? I have no idea... Can someone shed some light?
Apple's technical people seem to have been confused about this. In my copy of the Firmware reference it says for $C019; "bit 7 = 1 if not VBL". 

And this is my experience on the //e.  A better name for the high bit
would have been "/VBL".


In Apple IIgs Technical Note #40 it says:
"On the IIGS, the screen is blanked when the most significant bit of $C019 is high (greater than 127 or $7F), while on the IIe, the screen is blanked when the bit is low (less than 128 or $80)."
So from that I get that, you *can* read bit 7 of $C019 on a IIGS to poll the VBL. I'm just unsure whether the bit should be high or low :-) 

So on the IIgs it is a "VBL" level on the high bit.

This could be a result of the mis-naming of the bit on the //e,
coupled with insufficient curiosity/motivation on the part of
the implementor.

Of course, my VBL pacing routine would work either way, with only
the "phase" upon return being different.  That would "tune" my
animation updates for maximum visibilty on the IIgs--not that it
matters.  ;-)
There is also a VBL interrupt available on the IIGS (in the Miscellaneous Tool Set or the mouse firmware). 

On the IIGS the VBL begins on scan line 192 regardless of the display mode.


Hmmm--yet another indication of marginal motivation...  ;-)

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