|Re: [hatari-devel] Native feature proposal|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On Dienstag, 1. Mai 2018 20:59:34 CEST tin@xxxxxxxxx wrote:
> 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_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.