[Coco] Help with speeding up sprite rendering

[Glen Hewlett]

Hi William,

You Rock!  You were totally correct that MAME was having trouble when I disabled the GIME IRQ and then disabled the IRQ.  I tried it as you described and only disabled the GIME IRQ and reading $FF92 and it now works fine with MAME.  I’m really glad to have the code running on MAME again.  :)

I’l also add in the optimizing ideas you suggested, they will definitely help too.

Thanks again for your all your help!
Glen


> On Mar 17, 2017, at 3:57 PM, William Astle <lost at l-w.ca> wrote:
> 
> On 2017-03-17 01:35 PM, Glen Hewlett wrote:
>> The code below doesn’t work on the latest MAME (0.183) but it does work on a real CoCo3.  I have a feeling that MAME doesn’t handle turning off all the interrupts very well.  Maybe it’s me, I’ll have to investigate this more as I’ve been using MAME to test my code for the last six months and this is the first time I’ve had an issue with it.
> 
> I don't see any issues with your code.
> 
> It might be that you're getting a spurious interrupt in MAME after disabling the GIME IRQ. Reading FF92 immediately after disabling everything would clear that.
> 
> I have a couple of suggestions that may improve the routine speed.
> 
> You shouldn't need to clear FF92. It should also remember which interrupt flags are enabled when you re-enable the IRQ in FF90. You might want to try that on the real CC3. It will shave a few cycles off the routine if you don't have to set FF92.
> 
> Also, you don't need to save CC unless you need to preserve the carry flag for some reason. Everything else that actually matters is clobbered by LDA and STA on the way out anyway, or can simply be set explicitly on the way out. You said this was during your IRQ handler? In that case, you can just do an "orcc #$10" before you reset FF90 to make sure IRQ is disabled. No need to do the save/load dance with CC. (load/store + TFR is quite slow compared to orcc or andcc) If you do need to restore the state of the interrupt flags to an unknown state at the end, then the load/store business makes sense. Otherwise, it's using up CPU time for no real benefit.
> 
> Also, is DP always the same when that code runs? If so, you can just reset it directly instead of the save/load dance. That means only one "load + TFR" to reset DP. If DP changes unpredictably, then what you're doing does make sense.
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco