|Re: [hatari-devel] Natfeats doc?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 08/09/2021 à 19:13, Thorsten Otto a écrit :
On Mittwoch, 8. September 2021 18:34:19 CEST Eero Tamminen wrote:
> Should it also clear out the parsed parameters
> from stack (i.e. in NF_DEBUGGER case increase
> A7 by 4)?
My idea was that this opcode does not use any parameters, nor modifies
any registers (not even D0)
>In that case, I think it would be better to use
>already existing instruction / opcode for that,
>- "illegal" ($4afc), or
>- "bkpt" ($4848 + vector)
BKPT is an 68020 only opcode, IIRC. "illegal" is often used by native
Atari debuggers to set breakpoints. Using any of these may conflict with
from the discussion, I understand that having to deal with input values
and/or stack after return can be a little too "complicated" and also can
alter cpu states.
Even a simple bsr will alter the stack and can even create a crash if A7
has a special content and doesn't point to valid memory (think about
some very optimised game/demo routines where all regs need to be used).
So, IMO a specific opcode would be a better alternative solution to
trigger the debugger :
- it doesn't require any regs
- it won't alter stack or A7
- we can decide that this specific opcode takes 0 cpu cycle, which
means you can even include some debugger calls from a fullscreen routine
and when you come back from the debugger the video sync is still OK.
Pretty handy if you want to debug fullscreen effects :)
As for the opcode itself, it should be one that is invalid for all the
680xx CPU family.
It should be disabled by default (because some game/demo protection
might rely on this opcode to trigger some illegal instruction exception
as part of the protection)
One could have for example a '--debugger-opcode' option ; set to no/off
by default. If set to yes/on it would intercept the specific opcode to
call the debugger instead of doing an illegal instruction exception.
And we could even provide an hexa value to choose our own debugger
opcode (eg --debugger-opcode ba98 to intercept opcode 0xba98)