Re: [hatari-devel] Natfeats doc?

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

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,
>
>  >either:
>
>  >- "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 
> those debuggers.

Hi

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)

Nicolas