|Re: [hatari-devel] [PATCH] Add some NVDI function names|
[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]
On Mittwoch, 30. September 2020 17:26:14 CEST Eero Tamminen wrote:
> You could add an extra parameter to
> VDI_Opcode2Name() for the component name (e.g.
> "NVDI vX.XX"). By default it would be empty
Theoretically that could be done, but some calls are not only implemented by NVDI. I took the comments from tos.hyp, but for example fVDI also implements some of them, and also FSM-GDOS and SpeedoGDOS.
>As those are all for
>opcodes >=170, the array should be named like
The intention was to later integrate the opcode5 and opcode11 tables there too, so they don't have to be treated specially.
>as now the whole array would
>be scanned also for unrecognized opcodes/subcodes
Hm, yes theoretically. But the array now contains all known VDI opcodes, so that would only matter if there actually is an unknown opcode, which is really unlikely. And in that case, you have to scan the table, anyway.
>the final return value for the unknown opcodes
>should now be something else than "GDOS?"...
Ok, that should then just be changed to "???", like in other table entries. But most likely, it will still be some GDOS call which is not yet documented anywhere.
>Unconditionally skipping them isn't OK, and that functionality should be
>in a separate patch.
Oops. I added that for testing, it was not meant to be part of the patch. Just drop that part from the patch for now.
>However, I'm not yet sure what would be best way
>to do that.
Maybe that could be placed into something like if (callers pc in ROM), but that may also fail if ROM has for example been copied to TT-RAM, or when using emutos.prg. The cleanest would maybe to have -trace recognize also the individual function names, so you can disable it with -trace -vq_key_s etc. (i think none of them conflicts with other trace options)
BTW, that check for the subcode *cannot* be made for all opcodes. During tracing i saw lots of output like
VDI call 129/ 1 (vs_clip)
Subcode 1 is not defined for vs_clip(). The reason is IMHO an incorrect binding in some libraries, which do not always clear the subcode field and use static arrays (like in PCGEMLIB). In that case, it will just pass the subcode from some previous call.
|Mail converted by MHonArc 2.6.19+||http://listengine.tuxfamily.org/|