Re: [hatari-devel] Native feature proposal

[Thorsten Otto <admin@xxxxxxxxxxx>]

On Dienstag, 1. Mai 2018 20:59:34 CEST tin@xxxxxxxxx wrote:
> Hi,
> 
> here's a proposal for two very handy NF calls I've patched into my
> Hatari branch for a while now:
> 
> NF_STDERR_NUM: output a number without the need to convert it to a
> string on the ST.

There is already a more general version of something like this: DEBUGPRINTF. 
It takes a printf-like string and a variable number of arguments, just like 
printf. Drawback: since the natfeats interface requires all parameters to be 
longs, you have to be careful that all arguments really fulfill that 
requirement. Not a problem when using GCC, but maybe when using compilers like 
Pure-C with 16-bit ints. Also, floating point is not supported by that 
interface. So i normally take a different approach: provide a wrapper function 
nf_debugprintf(), that prints to a static string, then outputs that using 
NF_STDERR.


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

> 
> Any objections?

Yes. Please don't  forget that there are other emulators around, and that the 
NatFeats interface is meant to be a general enhancements for those. So please 
don't wildly invent NatFeats that won't be documented, especially when they 
duplicate already existing functionality.