Re: [hatari-devel] Native feature proposal

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

On 05/02/2018 09:49 AM, Thorsten Otto wrote:
On Dienstag, 1. Mai 2018 20:59:34 CEST tin@xxxxxxxxx wrote:
NF_FRAMEPOSITION: copies frame info (nVBLs, nHBL, nScanlinesPerFrame,
nCyclesPerLine and CyclesPerVBL) into a memory area given by the guest
program. This makes it very easy to time code parts cycle-exact at
runtime and do a quick check on optimizations as well as the average
time a code part takes between frames. Also it's easier to check where
exactly a code runs (relative to the frame start).

That would be very Hatari specific.

I don't think that in itself is a problem, as long as API doesn't
overlap with the other NF APIs, or other ways of doing the same.


Note that this could be done with the debugger too, and that way
overhead would be zero cycles for the emulated code.

One can just add a symbol to a place in the code where one
wants these values to be output, and them add tracing
breakpoint for that symbol in the debugger:
	b pc = show_values :quiet :lock

Breakpoint ":lock" option shows the info (that has been "locked"
to be show on debugger entry), without actually stopping:
CPU=$fc1572, VBL=413, FrameCycles=160334, HBL=0, LineCycles=78, DSP=$0


If that's not enough, one can use this instead:
	b pc = show_values :quiet :trace :file show-values.ini

And do the desired outputs in "show-values.ini" file, e.g:
	e VBL
	e HBL
	e LineCycles
	e FrameCycles
	e CycleCounter

If additional emulation state info variables are needed,
adding those isn't a problem.

Output of above isn't very concise though. If that's a problem,
I accept proposals on what to do to improve that. :-)


	- Eero



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/