[Coco] Help with speeding up sprite rendering

Glen Hewlett glen.hewlett at sympatico.ca
Fri Mar 17 23:02:39 EDT 2017


Hi Curtis,

Thanks for the tip, I’ll add it to my bag of tricks for optimizing code.  Every cycle I can save helps.

Cheers,
Glen
> On Mar 17, 2017, at 4:02 PM, L. Curtis Boyle <curtisboyle at sasktel.net> wrote:
> 
> Along the same line - if you do need to preserve both CC and DP, and can store them in contiguous memory locations with STD (TFR dp,a / TFR cc,b / STD >saveloc , and then do a LDD > saveloc / TFR a,dp / TFR b,cc  to save some cycles.
> 
> L. Curtis Boyle
> curtisboyle at sasktel.net
> 
> 
> 
>> On Mar 17, 2017, at 1: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
>> 
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco



More information about the Coco mailing list