On Aug 29, 2:59=A0pm, David Schmenk  wrote:
> Thanks again to Tom for trying this out. =A0Maybe I can convince him to
> try this one out:
>
> http://schmenk.is-a-geek.com/tarfiles/VM02ALPHA3.DSK.zip
>
> I also discovered a couple of other issues now fixed. =A0Certain ROM
> routines will disable interrupts. =A0Some of my sample classes that call
> ROM routines for low res and hi res graphics all of the sudden stopped
> responding to interrupts. =A0I now re-enable interrupts after every nativ=
e
> method. =A0I also discovered that my comparison opcodes would adjust the
> stack pointer, then compare the values that were now above the stack.
> Tsk, tsk. =A0When an interrupt would occur during the comparison, the
> values would get trashed.
>
> Glen Bredon wrote a nifty little TSR style program that would hook the
> VBL interrupt to keep time. =A0His notes mentioned problems with various
> IIc models. =A0He actually didn't bother calling the mouse firmware to
> service the interrupt on a IIc. =A0The VBL interrupt would continue
> interrupting anyway. =A0So I now look to see if any hardware claimed the
> interrupt. =A0If not, I assume it's the VBL interrupt. =A0Hope this works=
,

I wasn't aware of any ROM routine that disabled interrupts without re-
enabling them. At least in a //c, the ROM routines should follow the

PLP
SEI
...
PHP

idiom for interrupt handling to avoid re-enabling in the case where
they were already disabled. If there is one, that counts as a bug
IMO...

Also, re the mouse, there's a particular mouse mode you can call
SETMOUSE in which doesn't require that the requests be handled with a
SERVMOUSE.

It's looking good! Works flawlessly on my IIe (4Mhz Zip Chip on or
off). I'm eagerly awaiting STARTUP protocol support so I can launch
apps via a program selector (and graceful quits of course) :-)

Matt
--- SBBSecho 2.12-Win32