Re: [hatari-devel] Native feature proposal

[ Thread Index | Date Index | More Archives ]

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.

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.

Mail converted by MHonArc 2.6.19+