[hatari-devel] Blitter interrupt CPU usage (was: Timer-D CPU usage in latest Hatari)

[Eero Tamminen]

Hi,

On Sunday 19 July 2009, Matthias Arndt wrote:
> Am Sonntag, den 19.07.2009, 13:06 +0300 schrieb Eero Tamminen:
> > Btw. Would there be any chance of / would it make any sense to have
> > an option for a "dummy" STE Blitter similarly to DSP?  (As I don't see
> > how we could optimize the interrupt handling more than by couple of %
> > while making the code less readable without somehow minimizing the
> > number of interrupts that need to be handled)
>
> I think this does not make much sense.

Ok.


> An STE with Blitter disabled is no STE anymore.

Well, there's still the larger palette and DMA sound. :-)


> Better make the emulation code more speedier. 

The problem is that I don't see how Hatari interrupt handling (which is
currently the largest performance bottleneck by far if one forgets about
the Falcon DSP) could be speeded up more.

Using pointers instead of array to access to the interrupt table gives only
a 1-2 percent speedup while making the code less readable.  Anything
else / more clever I could think of & have tested just made the interrupt
processing slower.


If you know something about blitter, please look into the Hatari code to see
whether there's something that can be done to significantly decrease
the number of generated Blitter interrupts within the emulation...

(For example Timer-D patch thingly works just fine.)


> Also the timing of the Blitter emulation is not accurate according to
> the Paradox boys (and they are heavy Blitter abusers on their STE
> productions).

The Hatari compatibility.html page lists couple of demos where the blitter
timing isn't yet accurate enough.


	- Eero