|Re: [hatari-devel] [PATCH] Add some NVDI function names|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On 9/30/20 12:41 PM, Thorsten Otto wrote:
The attached patch adds some vdi function names used by NVDI/SpeedoGDOS, for
use by the trace feature.
Trace functionality did intentionally output
numbers for OS calls that were not limited by TOS
itself, so that user has some indication which
functions need something extra to work.
For the other calls, I would expect trace call
to show for which extra component that OS call
is for. You could add an extra parameter to
VDI_Opcode2Name() for the component name (e.g.
"NVDI vX.XX"). By default it would be empty
You added support for showing misc subopcode
function call names. As those are all for
opcodes >=170, the array should be named like
"names_opcode170". Also, it should be within
suitable if check, as now the whole array would
be scanned also for unrecognized opcodes/subcodes
Finally, with names added for GDOS functions,
the final return value for the unknown opcodes
should now be something else than "GDOS?"...
It might also be useful to be able to disable certain calls when tracing. Eg.
the builtin AES in all TOS versions (including EmuTOS) regularly calls
vrq_string (opcode 31), vsin_mode (opcode 33) and vq_key_s (opcode 128). These
are usually of not much interest, and just fill up the trace file quickly.
Unconditionally skipping them isn't OK, and that functionality should be
in a separate patch.
However, I'm not yet sure what would be best way
to do that.
In case of GEMDOS, there's the "os_base" trace
option which enables just xconout output to
console, and few basic GEMDOS calls.
I.e. one option would be to have a separate
"vdi_base" trace option, but I'm not sure which
calls that should then track...
Another possibility would be to have an option
Usage: --no-trace-opcodes <subsystem>:<opcodes>
Accepted subsystem values are:
That would skip tracing of given opcodes for
given OS subsystem. Besides the few VDI
functions, skipping few low level BIOS functions
would be nice when using:
However, all that would require significant amount
of changes, and complicate each of the trace
function calls for the supported subsystems a lot.
I think in the end best may be just to pipe
Hatari trace output through something like:
| fgrep -v -e vrq_string -e vsin_mode ..
I did not change the "vdi info" command to print the names there, too. Dunno
whether that is useful, it would need a bit of work (only subcode 0 is printed
there), and would just print a lot of more names.
I think it's fine to skip subcodes for "vdi info",
but you could change it either to show all now
known opcodes, or show only TOS VDI opcodes and
state that. And please skip unused opcode ranges
to save screen space.