Re: [hatari-devel] Native feature proposal

[tin@xxxxxxxxx]

Hi,

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.

Can you elaborate? Do you mean implement nf_debugprintf() on the client side?

That would be very Hatari specific. 

I strongly disagree. Every emulator handling cycle accuracy has this information in some form (e.g. Winuae) - this presentation is probably universal.
I see your point of course, we need at least a way to have the emulator say "I don't know". IIRC nf_scsidrv handles this by simply not recognizing this command, right?
And as Eero said: the struct definition itself should be either immutable or versioned somehow.

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.

Of course you are right. But it's not about "wildly inventing" as you put it, but about a strong suit of Hatari: it is (afaik) the only emulator that is cycle accurate AND sees NatFeats as a potential for developers.
Regarding duplicate functionality: I currently don't see how a program that has tight timing constrictions and no OS present, can output decimals to the hosts console. I did go the "roll your own printf route" and this is just changing the program under observation too much (code and timing wise). This NatFeat would help developers alot, IMHO.

That said: since I should write tests for whatever NatFeats get accepted, I would like to add an "examples" package in C and ASM to show users its usage (and greatness) and give them some code wrappers to use in their own projects. Do any of you see any chance to provide sth like this included into the release packages?