Tom Greene wrote:
> On Aug 29, 12:59 am, 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,
>>
>> Dave...
> 
> Sure thing... alas I didn't get any better results, it still runs fine
> on the IIc+ but freezes on the other two ROMs.
> 
> One thing I notice with both versions is that keyboard input seems to
> extend the run time a bit. That is to say, if I start the helloworld
> program and just let it run without touching anything, it runs for
> about 30 seconds before freezing. If I start the program and then
> pound on the keyboard continuously, it runs about 35 to 40 seconds.
> 
> Tom

Hi Tom-

Last time you said it continued to buzz after it stopped responding. 
Does it still do this?  I thought I caught all cases, unless the mouse 
firmware is lying about about the VBL interupt source.  Thanks,

Dave...
--- SBBSecho 2.12-Win32