|Re: [hatari-devel] Natfeats doc?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 7.9.2021 18.14, Troed Sångberg wrote:
On Tue, Sep 7, 2021 at 16:27, Thorsten Otto <admin@xxxxxxxxxxx> wrote:
On Dienstag, 7. September 2021 15:50:56 CEST Troed Sångberg wrote:
I don't see "trigger debugger" in the Aranym Natfeats doc)
That's because that NatFeat is only implemented by Hatari, but not by Aranym.
The principle is the same as with other natfeats:
- get the ID of the function, by executing the NATFEAD_ID opcode, passing it "NF_DEBUGGER" as function name. If that opcode does not throw an illegal exception, and D0 after the call contains some other value as zero, the feature is supported.
- or in the subfunction number. In your case, the feature does not have any subfunctions.
- pass that value to nf_call, along with any arguments (if any)
tests/natfeats/natfeats.c in Hatari has some example code, as well as the various nf_*.c files in mintlib.
And there are also examples for doing NF detection
in 3 different assembler dialects:
(Example for getting the IDs after NF detection
is just in C, but translating those few lines to
asm is trivial for anybody who actually uses m68k
With assembler developers in mind, I'd like to voice my support for the simple move.b trigger as added by Tat (which is the same as in Steem if I understood things correctly). When doing demo development having to care for changes to registers etc when just wanting to trigger the debugger is very cumbersome.
Is using stack (register) a problem in demos?
After your demo init fetches the relevant NF IDs,
I think invoking e.g. debugger is just:
Where nf_call is:
; call native feature by its ID
And if you don't want nf_call to branch
elsewhere, you add assembler macro to inline
that functionality... Right?
I agree about not needing lots of duplicate functionality - so let's remove the already deprecated Xbios call when adding it?
Natfeats is a bit more targeted towards high level development, imho.