|Re: [hatari-devel] Native feature proposal
[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]
Can you elaborate? Do you mean implement nf_debugprintf() on the client side?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.
I strongly disagree. Every emulator handling cycle accuracy has this information in some form (e.g. Winuae) - this presentation is probably universal.That would be very Hatari specific.
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.
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.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.
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?
|Mail converted by MHonArc 2.6.19+