Zamuel_a wrote:Will Hatari support palette changes, video address updates between each VBL in the future or will it take to much CPU power?
For small fragments of code, use a timing harness. You can write one, or wait until I post the source for mine
It's easy enough to write though if you just want to plug in your own instruction sequences. The one I wrote is more general for timing different kinds of thing (like blitter or DSP) so its a bit more complicated than you need.
The harness just runs a fragment of code in a loop of size X, and calls the fragment Y times, so you have several seconds of execution in total (X * Y iterations), long enough to get accurate timing.
You then count Timer C events, and divide into the total events and clock speed of the machine. This gives you the number of cycles per loop iteration (including the loop overhead). With this you can figure out a great deal, and you can get very accurate results. Small changes to instruction ordering, loop overhead and cache hits can all be tested this way. You will not get this information from Hatari - the emulation cores are still not accurate (but improve with each release).
You can find the timing for the fragment MINUS loop overhead, by executing an empty version of the loop (or an unrolled version with only 1 unroll, subtracted from an unrolled version with, say 5 unrolls, and divide by 4 to get the time per unroll fragment). This gives extremely accurate results if you're careful - to the cycle.
For optimizing a big program with lots of different routines (like a game or demo), use Hatari's profiler. It's a lot better for that kind of thing than anything you'll be able to write yourself.
Timing harness = tiny fragments, cpu-specific optimizations
Hatari profiler = big picture, algorithm and large code optimizations