Re: [hatari-devel] Native feature proposal

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

On 05/02/2018 12:26 PM, Thorsten Otto wrote:
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.

Btw. Only NatFeats APIs used in Aranym for which I've found any
documentation are basic ones:
- NF_NAME
- NF_VERSION
- NF_STDERR
- NF_SHUTDOWN

Documented here:
	https://github.com/aranym/aranym/wiki/natfeats-proposal

Both Hatari & Aranym also implement NF_SCSIDRV, as Uwe contributed
it to both.  His documentation is here:
https://hg.tuxfamily.org/mercurialroot/hatari/hatari/raw-file/tip/doc/scsi-driver.txt


For rest of Aranym NF APIs I haven't found API documentation, so
for me they don't seem to be intended as any kind of standard,
just Aranym specific extensions.


FYI: current Hatari specific NF APIs are:
* NF_EXIT (unlike NF_SHUTDOWN, one can give emulator exit code)
* NF_DEBUGGER (invoke debugger, for assert() replacements)
* NF_FASTFORWARD (enable/disable fast forward)

They're pretty simple so one could consider these to be documentation:
* implementation: https://hg.tuxfamily.org/mercurialroot/hatari/hatari/raw-file/tip/src/debug/natfeats.c * test-cases: https://hg.tuxfamily.org/mercurialroot/hatari/hatari/raw-file/tip/tests/natfeats/natfeats.c


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

Before Hatari, Aranym was the only thing supporting NatFeats.

API having just one implementation, cannot be called a standard,
so maybe it could be said that Hatari "standardized" the APIs
common between them. ;-)


And even Hatari, when run in fast-forward mode, may
not be able to provide accurate information this way.

As long as one doesn't use RTC (i.e. host clock), it's accurate.


	- Eero

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



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/