Re: [hatari-devel] Native feature proposal

[Thorsten Otto <admin@xxxxxxxxxxx>]

On Mittwoch, 2. Mai 2018 10:28:16 CEST tin@xxxxxxxxx wrote:

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

> side?

 

Yes. If you are concerned about doing the decimal->ascii conversion on the client side, then you can use the (already existing) DEBUGPRINTF interface. So instead of your NF_STDERR_NUM feature, just use something like this:

 

...

nf_debug = nf_id("DEBUGPRINTF")

...

nf_call(nf_debug, "%u", (unsigned long)(my_variable))

 

Only thing you need then is to implement DEBUGPRINTF in Hatari, maybe using the Aranym sources as an example.

 

The reason why i normally do it on the client side, is that a) i usually really only use it for debugging output, and am not concerned about additional time taken, b) doing it on the client side allows me do use it like normal printf, including format string checking by gcc, and without using ugly casts.

 

>Hatari: it is (afaik) the only emulator that is cycle accurate AND sees >NatFeats as a potential for developers.

 

But it's not the only emulator providing NatFeats (actually it does not provide them by default). And even Hatari, when run in fast-forward mode, may not be able to provide accurate information this way.

 

Other than that, i agree to what Eero said. Be careful when designing new features, once the structure is designed, and is used by applications, you cannot easily change it. So do some thoughts about possible future enhancements *now*, otherwise you risk incompatibilities when applications use a different structure than the emulator. Maybe in this case passing the size of the structure (either as an additional argument to the function, or as part of the structure itself) will be good enough.

 

> I currently don't see how a program that has tight timing constrictions and >no OS present, can output decimals to the hosts console.

 

See above.

 

>we need at least a way to have the emulator say "I don't know"

 

That is no problem. You always have to obtain the function number first from the emulator, and all that functions are optional. Just make sure you don't use it when it is not available.

 

Thorsten

 

PS.: i orgininally thought that DBEUGPRINTF is part of the "basic" NatFeats that should always be implemented, but isn't. You can find some Documentation about NatFeats in general in the aranym wiki