New opcode for 68000 family

clenched · 07 March 2009, 06:12

I would like a new opcode for the 68000 that would invoke only WinUAE debugger. Maybe it could be $ADEB (for Amiga debugger). It would be nice if it didn't have side-effects i.e. nothing added to stack or changed in SR; just stop like pressing END+F12. Using the cartridge-based debuggers gets annoying after the 20th crash because you always have to tell them after every reboot to catch exceptions.
However, if this idea causes even the least trouble or even the tiniest slowdown, I'd rather make do without it.

BippyM · 07 March 2009, 09:42

What would happen on a real amiga?

clenched · 07 March 2009, 09:53

Most likely Guru w/line-a exception

Leffmann · 07 March 2009, 11:10

Other possibilities could be an existing OP-code with an unused mode, something an assembler or compiler would never produce, to prevent UAE from interfering with any line-A exception handling, or a blank nonsense instruction which changes nothing and makes no sense but is otherwise fully correct on all 68K systems, such as MOVEA.L A7, A7. With the latter you could run the same executable on a real system with ease. In the possibility that the nonsense instruction is found in some code f.ex as a filler and starts to pop the debugger then you would just turn the debug feature off.

StingRay · 07 March 2009, 11:13

What's the problem to stick in a wait for LMB and/or color flash and pressing shift+f12? I don't get it...

Leffmann · 07 March 2009, 11:19

I think the idea is to get a new breakpoint feature that interferes as little as possible with the code both on a source and executable level.

StingRay · 07 March 2009, 11:39

Well, but if a new opcode is requested for that it means code has to be adapted/changed anyway. Which is why I don't really get it. And I rather prefer NOT having the debugger pop up on random occasions.

Leffmann · 07 March 2009, 12:00

I think the idea is to be able to do something like this so that it is minimally intrusive both on source and code level, and find the right OP-code and mode to make sure that the debugger just doesn't pop up unintentionally.

Code:

UAE_DEBUG = 1  ; Remove this to deactivate breakpoints

UAE_BREAK MACRO
          IFD      UAE_DEBUG
          movea.l  a7, a7
          ENDIF
          ENDM

          mulu.w    #10, d0
          add.l     d0, d1
          UAE_BREAK
          bpl       something

StingRay · 07 March 2009, 12:12

My solution:

Code:

ADEB    MACRO
.\@debug
        move.w $dff006,$dff180
        btst    #6,$bfe001
        bne.b   .\@debug
        ; everyone should be able to press shift+f12 at this point...
        ENDM

Really, where's the point in adding an additional opcode for stuff like that? You can't possibly know which opcodes are used for copy protections f.e., just to name one example. It would just break compatibility for something that is really easy to achieve w/o any additional opcodes!

clenched · 07 March 2009, 12:29

In a nutshell, I want WinUAE to trap this instruction before the 68000 then when finished debugging start at the next instruction. Basically an ILLEGAL but exclusive to WinUAE. Of course, you'd no more leave this instruction in the finished program anymore than an ILLEGAL. And for debugging already-compiled code, It would be nice to have a dependable breakpoint without having to chase down where Amiga decided to load this time. That's what I like to see some good ideas and debate PRO and CON. And there is always the venerable enable/disable checkbox.

Leffmann · 07 March 2009, 12:30

That's the problem, finding the right OP-code and mode that just isn't used anywhere

Anyone feel like analyzing the whole Planet Emu and Aminet's worth of object code?

Most likely an existing OP-code with an unused mode would be the best since it wouldn't be produced by an assembler or compiler, or two hands writing copy protection. In any remote case you could just turn the breakpoints and the debug feature in UAE off. The thing with using a word sized blank instruction is that it is as non intrusive as it gets as far as code offset and SR modification goes.

I don't need this feature myself, but I can see how it's useful and I think it's a good idea actually.

EDIT: and sorry for hijacking your post here, Clenched. A bit of brainstorming is always good, but I see your idea now.

Toni Wilen · 07 March 2009, 14:28

This has to be configurable, too easy to break compatibility. (but it won't be GUI option)

Leffmann · 07 March 2009, 20:00

Any ideas on what instruction to use as a breakpoint?

I was thinking TRAPF since it's nonsensical enough, or TRAPF.W #$ADEB or something if you want to make it even more unique. Something that speaks in favor of TRAPF is that it has, unlike ILLEGAL, no effect whatsoever should you happen to execute it when the debug feature is not turned on.

A command in the debugger to run until the next breakpoint could be useful as well, so you don't have to use command x and have the debugger close and open repeatedly.

Toni Wilen · 12 April 2009, 10:50

Quote:

Originally Posted by Leffmann

Any ideas on what instruction to use as a breakpoint?

I was thinking TRAPF since it's nonsensical enough, or TRAPF.W #$ADEB or something if you want to make it even more unique. Something that speaks in favor of TRAPF is that it has, unlike ILLEGAL, no effect whatsoever should you happen to execute it when the debug feature is not turned on.

A command in the debugger to run until the next breakpoint could be useful as well, so you don't have to use command x and have the debugger close and open repeatedly.

Perhaps new debugger command that enables opcode breakpoints? (default would be "illegal" but with extra parameter it would be possible to accept any opcode)

clenched · 13 April 2009, 20:22

Quote:

Originally Posted by Toni Wilen

Perhaps new debugger command that enables opcode breakpoints? (default would be "illegal" but with extra parameter it would be possible to accept any opcode)

That pretty much describes the existing "fi <opcode> Step forward until PC points to <opcode>". If that command could be modified to fi <opcodeA><opcodeB> so that rather than executing A and crashing; A gets overwritten by B (original) and program continues like it had never been patched then that would be great. Also fi looks like a one-shot deal i.e. needs to be re-issued each time it is used. As it stands now, fi will stop a program where I need it stopped but I must manually advance program counter past crash opcode. Wait and see what Leffmann has to say because he did a better job of describing what I want than I did.

Leffmann · 14 April 2009, 15:02

Wall of text warning!

I'm not sure exactly what you wanted, Clenched, but I can explain how I would like to use a feature like this. Maybe you and Toni think some of these ideas are good:

I would want to insert TRAPF.W #x into my code. I can set x to different numbers if I want to differentiate between types of breakpoints.

In the debugger I would want a command, f.ex "bp", that runs until the next TRAPF.W. It should also skip the TRAPF.W so the CPU emulator doesn't fetch and execute it, because the user insists that the TRAPF.W is just a breakpoint.

I would want to type f.ex "bp 4" to run until it reaches TRAPF.W #4. This way I can use different breakpoints and f.ex type "bp 5" to study each iteration of a loop, type "bp 6" to run through the loop and break at the end, or "bp 10" to just run to some later point I'm interested in. This makes for very flexible stepping through the program.

The "bp x" command must fetch and execute all unrelated TRAPF.W in the remote case that someone actually uses them for something like weird timing delays or a homemade debugging feature using the trace exception.

With ILLEGAL or some other crashing OP-code you would constantly have to assemble a different version for testing on a real Amiga or without debugging. I suggested TRAPF.W because it does nothing and is safe to run, which will make developing easier.

If the TRAPF.W fails for some reason then an option to set a specific OP-code as breakpoint would be useful.

Some related functions that aren't really important but could be useful if you think they're quick to implement:
Run for x scanlines. Run until scanline x is reached. Run until the beginning of the next frame. Run for SS.MMMM.UUUU seconds, milliseconds and microseconds. Microseconds sound extreme but 1 millisecond is very inexact for some things even on a slow Amiga.

07 March 2009, 12:00	#8
Leffmann Join Date: Jul 2008 Location: Sweden Posts: 2,269	I think the idea is to be able to do something like this so that it is minimally intrusive both on source and code level, and find the right OP-code and mode to make sure that the debugger just doesn't pop up unintentionally. Code: UAE_DEBUG = 1 ; Remove this to deactivate breakpoints UAE_BREAK MACRO IFD UAE_DEBUG movea.l a7, a7 ENDIF ENDM mulu.w #10, d0 add.l d0, d1 UAE_BREAK bpl something

07 March 2009, 12:12	#9
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,863	My solution: Code: ADEB MACRO .\@debug move.w $dff006,$dff180 btst #6,$bfe001 bne.b .\@debug ; everyone should be able to press shift+f12 at this point... ENDM Really, where's the point in adding an additional opcode for stuff like that? You can't possibly know which opcodes are used for copy protections f.e., just to name one example. It would just break compatibility for something that is really easy to achieve w/o any additional opcodes!

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
The Addams Family Demo	Kitty	request.Demos	11	13 July 2023 15:45
Giving up family collection	emdxxxx	MarketPlace	14	30 July 2007 08:37
Hidden Amiga 68000 opcode?	pmc	Coders. General	20	14 May 2007 09:10
Looking to sell family collection	emdxxxx	MarketPlace	5	24 February 2007 15:02
New Classic in the Family	Pete	Retrogaming General Discussion	34	02 August 2002 21:37

07 March 2009, 06:12	#1
clenched Registered User Join Date: Sep 2008 Location: Gainesville U.S.A. Posts: 771	New opcode for 68000 family I would like a new opcode for the 68000 that would invoke only WinUAE debugger. Maybe it could be $ADEB (for Amiga debugger). It would be nice if it didn't have side-effects i.e. nothing added to stack or changed in SR; just stop like pressing END+F12. Using the cartridge-based debuggers gets annoying after the 20th crash because you always have to tell them after every reboot to catch exceptions. However, if this idea causes even the least trouble or even the tiniest slowdown, I'd rather make do without it. Last edited by clenched; 07 March 2009 at 11:46.

07 March 2009, 09:42	#2
BippyM Global Moderator Join Date: Nov 2001 Location: Derby, UK Age: 48 Posts: 9,355	What would happen on a real amiga?

07 March 2009, 09:53	#3
clenched Registered User Join Date: Sep 2008 Location: Gainesville U.S.A. Posts: 771	Most likely Guru w/line-a exception

07 March 2009, 11:10	#4
Leffmann Join Date: Jul 2008 Location: Sweden Posts: 2,269	Other possibilities could be an existing OP-code with an unused mode, something an assembler or compiler would never produce, to prevent UAE from interfering with any line-A exception handling, or a blank nonsense instruction which changes nothing and makes no sense but is otherwise fully correct on all 68K systems, such as MOVEA.L A7, A7. With the latter you could run the same executable on a real system with ease. In the possibility that the nonsense instruction is found in some code f.ex as a filler and starts to pop the debugger then you would just turn the debug feature off.

07 March 2009, 11:13	#5
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,863	What's the problem to stick in a wait for LMB and/or color flash and pressing shift+f12? I don't get it...

07 March 2009, 11:19	#6
Leffmann Join Date: Jul 2008 Location: Sweden Posts: 2,269	I think the idea is to get a new breakpoint feature that interferes as little as possible with the code both on a source and executable level.

07 March 2009, 11:39	#7
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,863	Well, but if a new opcode is requested for that it means code has to be adapted/changed anyway. Which is why I don't really get it. And I rather prefer NOT having the debugger pop up on random occasions.

07 March 2009, 12:29	#10
clenched Registered User Join Date: Sep 2008 Location: Gainesville U.S.A. Posts: 771	In a nutshell, I want WinUAE to trap this instruction before the 68000 then when finished debugging start at the next instruction. Basically an ILLEGAL but exclusive to WinUAE. Of course, you'd no more leave this instruction in the finished program anymore than an ILLEGAL. And for debugging already-compiled code, It would be nice to have a dependable breakpoint without having to chase down where Amiga decided to load this time. That's what I like to see some good ideas and debate PRO and CON. And there is always the venerable enable/disable checkbox.

07 March 2009, 12:30	#11
Leffmann Join Date: Jul 2008 Location: Sweden Posts: 2,269	That's the problem, finding the right OP-code and mode that just isn't used anywhere Anyone feel like analyzing the whole Planet Emu and Aminet's worth of object code? Most likely an existing OP-code with an unused mode would be the best since it wouldn't be produced by an assembler or compiler, or two hands writing copy protection. In any remote case you could just turn the breakpoints and the debug feature in UAE off. The thing with using a word sized blank instruction is that it is as non intrusive as it gets as far as code offset and SR modification goes. I don't need this feature myself, but I can see how it's useful and I think it's a good idea actually. EDIT: and sorry for hijacking your post here, Clenched. A bit of brainstorming is always good, but I see your idea now.

07 March 2009, 14:28	#12
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,534	This has to be configurable, too easy to break compatibility. (but it won't be GUI option)

07 March 2009, 20:00	#13
Leffmann Join Date: Jul 2008 Location: Sweden Posts: 2,269	Any ideas on what instruction to use as a breakpoint? I was thinking TRAPF since it's nonsensical enough, or TRAPF.W #$ADEB or something if you want to make it even more unique. Something that speaks in favor of TRAPF is that it has, unlike ILLEGAL, no effect whatsoever should you happen to execute it when the debug feature is not turned on. A command in the debugger to run until the next breakpoint could be useful as well, so you don't have to use command x and have the debugger close and open repeatedly.

14 April 2009, 15:02	#16
Leffmann Join Date: Jul 2008 Location: Sweden Posts: 2,269	Wall of text warning! I'm not sure exactly what you wanted, Clenched, but I can explain how I would like to use a feature like this. Maybe you and Toni think some of these ideas are good: I would want to insert TRAPF.W #x into my code. I can set x to different numbers if I want to differentiate between types of breakpoints. In the debugger I would want a command, f.ex "bp", that runs until the next TRAPF.W. It should also skip the TRAPF.W so the CPU emulator doesn't fetch and execute it, because the user insists that the TRAPF.W is just a breakpoint. I would want to type f.ex "bp 4" to run until it reaches TRAPF.W #4. This way I can use different breakpoints and f.ex type "bp 5" to study each iteration of a loop, type "bp 6" to run through the loop and break at the end, or "bp 10" to just run to some later point I'm interested in. This makes for very flexible stepping through the program. The "bp x" command must fetch and execute all unrelated TRAPF.W in the remote case that someone actually uses them for something like weird timing delays or a homemade debugging feature using the trace exception. With ILLEGAL or some other crashing OP-code you would constantly have to assemble a different version for testing on a real Amiga or without debugging. I suggested TRAPF.W because it does nothing and is safe to run, which will make developing easier. If the TRAPF.W fails for some reason then an option to set a specific OP-code as breakpoint would be useful. Some related functions that aren't really important but could be useful if you think they're quick to implement: Run for x scanlines. Run until scanline x is reached. Run until the beginning of the next frame. Run for SS.MMMM.UUUU seconds, milliseconds and microseconds. Microseconds sound extreme but 1 millisecond is very inexact for some things even on a slow Amiga.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)