PS.: i orgininally thought that DBEUGPRINTF is
part of the "basic"
NatFeats that should always be implemented, but isn't.
Ah, that explains alot - I did ofc look in Aranyms Natfeat proposal
before implementing any of those, and as Eero said, only the basic ones
are documented. Also, there was no DEBUGPRINTF to be seen in Hatari.
Wasn't aware that Aranyms implementation is the reference documentation.
Only thing you need then is to implement
DEBUGPRINTF in Hatari, maybe using the Aranym sources as an example.
Yes, this seems to be the best way to do this, if licenses allow this. I
for my part simply would macro away the needed "%x" string in my
respective call implementation - and pushing another long to the stack
isn't that problematic even for my timing sensible use cases.
I reckon it's not very sensible to just pipe DEBUGPRINTFs parameters
through sprintf (not all printf format markers wanting longs, malloc
overhead, security etc.)? I am ofc happy to convert Aranyms
implemntation as-is.
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.
Well not every guest PRG has the luxury of having a libc or even c :)
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.
Absolutely.
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.
That might not be enough, if an emulator has settings to
disable/influence cycle accuracy, as you pointed out. And unless the
guest PRG rerequest the ID every call (it probably won't), it doesn't
know if the values are OK or not. One could add a "valid" flag for
completeness.
|