mdj wrote:
> On Aug 29, 2:59 pm, David Schmenk  wrote:
>> Thanks again to Tom for trying this out.  Maybe 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.  Certain ROM
>> routines will disable interrupts.  Some of my sample classes that call
>> ROM routines for low res and hi res graphics all of the sudden stopped
>> responding to interrupts.  I now re-enable interrupts after every native
>> method.  I also discovered that my comparison opcodes would adjust the
>> stack pointer, then compare the values that were now above the stack.
>> Tsk, tsk.  When 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.  His notes mentioned problems with various
>> IIc models.  He actually didn't bother calling the mouse firmware to
>> service the interrupt on a IIc.  The VBL interrupt would continue
>> interrupting anyway.  So I now look to see if any hardware claimed the
>> interrupt.  If not, I assume it's the VBL interrupt.  Hope 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...

I am a little puzzled by this as well.  The routines in question are the 
AppleSoft hires plotting routines and some lo-res routines.  Perhaps 
there is something else going on here.  Issuing a CLI after calling 
these routines allowed VBL interrupts to continue, otherwise the ints 
stopped.  Weird.

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

There is a mode (transparent) that automatically updates the screen 
holes with the current mouse coordinates.  This uses the default 
interrupt handler in the system to call SERVEMOUSE as opposed to having 
a user installed interrupt handler call SERVEMOUSE.  This was for BASIC 
support.

I need SERVEMOUSE to tell me if the cause of the interrupt was for a 
move or VBL or non of the above.  Apparently VBL interrupts don't 
require any re-triggering.  There might be some timing issue with VBLs 
where the mouse firmware won't claim it if the VBL signal goes inactive 
before SERVMOUSE is called.  Trying to second guess the firmware if 
nobody claimed the interrupt seems to be the only option - although this 
doesn't appear to work on Tom's machine.

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

Thanks, I'll look more into the STARTUP protocol.  Which program 
selector do you use that implements it?  I already parse command line 
arguments at the "main class:" prompt, so it shouldn't be a stretch.  As 
for quits, I'm being a little conservative since I blow away the ProDOS 
quit code for my own uses.  It will get worse when I use more reserved 
ProDOS memory on a 128K machine ;-)  Not sure how well ProDOS will 
recover after my mucking about.

Dave...
--- SBBSecho 2.12-Win32