Re: [hatari-devel] Native feature proposal

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


Hi,

On 05/01/2018 09:59 PM, tin@xxxxxxxxx wrote:
here's a proposal for two very handy NF calls I've patched into my Hatari branch for a while now:

Thanks, these look good in general.

NF_STDERR_NUM: output a number without the need to convert it to a string on the ST. I often output internal state variables of a running programm using NF_STDERR (e.g. taken frames per render, clock-cycles of specific parts, control variables etc.). This way printing these taking almost no cpu time and the developed programs run-time behaviour isn't changed too much.

Outputting floating point values on machines that have FPU might
also be useful (may need conversion to host float format).

So, I think the function for integer output should have name
reflecting that, maybe NF_STDERR_LONG or NF_STDERR_INT.


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).

What data is put into that buffer may need some feedback
from other people who might want to use it, as e.g. increasing
the buffer size afterwards would be no-no.  Maybe size of
the buffer should be given as argument before the address?

Nicolas, Laurent?

You might also open a thread about it on atari-forum Hatari
section:
	http://www.atari-forum.com/viewforum.php?f=51


Any objections?

Besides above comments, they would need also test/example
code in tests/natfeats/natfeats.c.


	- Eero



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