| Re: [hatari-devel] [PATCH] Add some NVDI function names |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Hi,
Sorry for the late reply.
On 10/1/20 5:38 PM, Thorsten Otto wrote:
On Donnerstag, 1. Oktober 2020 01:34:12 CEST Eero Tamminen wrote:
attached is the revised patch. I've moved already the special-cased opcode5_98
to the larger table, because all those calls are also GDOS related.
Thanks, I've pushed your change to repo!
Things not handled yet:
- there are some calls which can only be distinguised by looking at contents
of the intin[] array (v_bez_qual for example)
- v_bez_on is not yet distinguished from v_bez_off, because it uses an unusal
calling convention (just the number of ptsin parameters differs, but contents
of ptsin are irrelevant)
- "vdi info 1" to print the opcodes list is not updated yet. To get that right
would need lots of more work, which i don't think is worth it
BIOS/XBIOS/GEMDOS/AES/VDI opcode lists are
intended mainly as help when setting breakpoints
on them in Hatari debugger, potentially when not
having internet or any extra docs at hand.
=> It's enough, and I think even preferable, to
show function numbers only for things which can
be determined with plain opcode.
(eg. already in
the current implementation it does not print the function names for v_bar
etc.). It's also a bit confusing because the numbers there are printed in hex,
while later in the trace they are printed in decimal.
Hm. BIOS, XBIOS & GEMDOS trace calls show the function number as hex,
AES & VDI as decimals.
All of them show the opcode lists in hex.
=> for consistency, VDI & AES trace output
function numbers should be changed to hex
> Maybe that info should just be dropped, and
> a link to https://freemint.github.io/tos.hyp/en/
> vdi_functions.html printed instead ;)
Adding a link to docs is a good idea in any case.
If it's a noticeable performance problem for you,
make sure you've built Hatari with optimizations
and aren't saving the log to a floppy. :-)
I would still prefer to not generate that info. For example i would also find
it useful to not only print the names, but also the contents of the intin[]
and ptsin[] arrays. But those should go to a separate line, and then you
cannot filter them out using grep.
You can already do that for the VDI functions you want, by using
conditional breakpoints, which I
think is the correct way to implement it.
I would also suggest using breakpoints to automate
when tracing (causing a lot of output) is enabled
and disabled.
(VDI functions you were concerned about are called
only when application is idling, but I've found
idling to be rarely an interesting use-case to
debug...)
Atari applications themselves can control tracing
using the deprecated Hatari XBios(255) call.
Maybe there should be also a specific NatFeats
API for controlling tracing?
>> THAT would make such a generic tracing feature
>> very annoying & invasive to implement.
>
> Ok, but thats beyond the scope of this patch ;)
Btw. Using breakpoints for this is currently
pretty awkward because VDI_Info() relies on
variables set only after VDI opcode is processed
by Hatari, but breakpoints are triggered before
trap opcodes are processed by Hatari.
Therefore one needs to do it like this:
------ vdi-opcode.ini ----------
# set breakpoint for VDI call of interest,
# which chains to next breakpoint
b VdiOpcode = $8 :quiet :trace :file next-pc.ini
# show VDI info on entering debugger
lock vdi
--------------------------------
------ next-pc.ini [1] ---------
# show info on next instruction, before removing breakpoint
b pc ! "pc" :quiet :lock :once
--------------------------------
With resulting output like this:
--------------------------------
Reading debugger commands from 'next-pc.ini'...
- 'pc' -> $e66ace
> b pc ! $e66ace :once :quiet :lock
Latest VDI Parameter block:
- Opcode/Subcode: 8/0 (v_gtext)
- Device handle: 1
- Control: 0xc728
- Ptsin: 0xc600, 1 coordinate word pairs
- Ptsout: 0xc80e, 0 coordinate word pairs
- Intin: 0xc628, 1 words
- Intout: 0xc826, 1 words
Reading debugger commands from 'next-pc.ini'...
- 'pc' -> $e66ace
> b pc ! $e66ace :once :quiet :lock
Latest VDI Parameter block:
- Opcode/Subcode: 8/0 (v_gtext)
- Device handle: 1
- Control: 0xc728
- Ptsin: 0xc600, 1 coordinate word pairs
- Ptsout: 0xc80e, 0 coordinate word pairs
- Intin: 0xc628, 3 words
- Intout: 0xc826, 1 words
--------------------------------
I think better approach would be to simplify this,
so that something like this would be enough:
--------------------------------
b VdiOpcode = $64 :quiet :trace :info vdi_opcode
--------------------------------
(Where ":info" doesn't require changing debugger
entry information, and "vdi_opcode" calls a
function that:
- barfs if PC is not at VDI opcode
- unlike VDI_Info(), works when execution is *at*
the opcode, not after it
(I.e. it gets VDI control info from the m68k regs
& memory instead of stored Hatari variables, and
doesn't have the extra info of what "pc" is.)
- Eero
[1] if you don't want to change info shown
when entering debugger, this can be used
instead:
------ next-pc.ini -------------
# set breakpoint for next instruction
# (in this case, after VDI opcode)
# and remove it after parsing show-vdi.ini
b pc ! "pc" :once :quiet :trace :file show-vdi.ini
--------------------------------
------- show-vdi.ini ----------
info vdi
--------------------------------