07 March 2009, 06:12 | #1 |
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 |
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 |
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 |
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 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,865
|
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 |
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 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,865
|
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:00 | #8 |
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 |
move.l #$c0ff33,throat
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,865
|
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 |
07 March 2009, 12:29 | #10 |
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 |
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 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,575
|
This has to be configurable, too easy to break compatibility. (but it won't be GUI option)
|
07 March 2009, 20:00 | #13 |
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. |
12 April 2009, 10:50 | #14 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,575
|
Quote:
|
|
13 April 2009, 20:22 | #15 |
Registered User
Join Date: Sep 2008
Location: Gainesville U.S.A.
Posts: 771
|
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.
|
14 April 2009, 15:02 | #16 |
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) | |
Thread Tools | |
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 |
|
|