mdj wrote:
On Aug 29, 2:59 pm, David Schmenk <dschm...@YUCH.gmail.com> 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...