Next Generation Emulation banner

Debugging Options/Features

7K views 10 replies 4 participants last post by  abystus 
#1 · (Edited)
I would love to see trace to file and trace to screen options in all your emulators (they seem to share a common layout). I'd say trace to window could display that last 2000 or so instructions executed before a breakpoint, and the file could support everything until the breakpoint. What I would like to see in such a file is below:

Code:
Address  Bytes  Instruction Literal  (optional register values)
Also; if possible, could you have it classify loop executions into single entries with a numeric representation of the execution count above (see MESS trace logs)? You have a very rich debugger outside of these missing features (this is in my opinion one of the basic features a debugger should contain), and they are sorely missed at the moment by hacking communities (especially for NDS).

The last feature would be a way to search the memory in most if not all your emulators. Currently we have to attach an external application that will resolve memory addresses within your emulator for cheat use, or use another emulator entirely (which results in the loss of the debugger). It would be nice to have such basic features built into a future release if you have time to implement it. Keep up the great work!
 
See less See more
#2 ·
Worked on tracelog feature for no$sns last week. It's optionally logging main CPU or sound CPU address/opcode/registers to the "TTY" debug message window. It isn't yet released, but if it turns out to be useful, I'll probably add it to other emus, too.

I've been quite afraid of the huge amounts of data, even the 3.58 MHz SNES can spit out around 80Mbytes of log data per second. But I've more or less solved it by allowing to select a 1MB/10MB/100MB buffer limit, optionally either stopping logging, or overwriting old data when reaching that limit. And, on the SNES at least, it might be even fast enough to keep the emulation run at full speed (on modern PCs that are 3-4 faster than my old Pentium 3).

For the PSX, showing all cpu registers won't work out, but it should be very easy to extract the used register numbers from the MIPS opcodes, so the tracelog could automatically show the relevant/used registers for each opcode. I haven't seen MESS trace logs - how does that loop execution stuff look like, can post an example? It sounds like a nice idea (although probably more difficult to implement).

Yes, I should add better memory search functions, too.
 
#3 · (Edited)
Very nice to see you working on some sort of trace log implementation (hopefully you choose to implement a "to window" as an option as well). As far as MESS/MAME are concerned, their logs show loops as follows:

Code:
...
8802C6B8: andi  $t5,$t5,$0421
8802C6BC: addu  $t3,$t3,$t4
8802C6C0: or    $t3,$t3,$t5
8802C6C4: bne    $v0,$t2,$8802c698
8802C6C8: sh    $t3,$27e($v0)

  (loops for 4134 instructions)

8802C6CC: addiu  $a1,$a1,-$1
8802C6D0: bne    $a1,$0,$8802c690
8802C6D4: addu  $v0,$v0,$a3
8802C690: sll    $a2,$a0,2
8802C694: addu  $t2,$v0,$a2

  (loops for 4160 instructions)

8802C6CC: addiu  $a1,$a1,-$1
8802C6D0: bne    $a1,$0,$8802c690
8802C6D4: addu  $v0,$v0,$a3

  (loops for 487305 instructions)

8802C6D8: addu  $t2,$v0,$a2
8802C6DC: lh    $t3,$0($v0)
8802C6E0: addiu  $v0,$v0,$2
8802C6E4: bne    $v0,$t2,$8802c6dc
8802C6E8: sh    $t3,$27e($v0)
8802C6DC: lh    $t3,$0($v0)
8802C6E0: addiu  $v0,$v0,$2
8802C6E4: bne    $v0,$t2,$8802c6dc
8802C6E8: sh    $t3,$27e($v0)

  (loops for 1272 instructions)

8802C6EC: jr    $ra
8802C6F0: nop
88026C88: jal    $8802b18c
88026C8C: nop
8802B18C: addiu  $sp,$sp,-$8
8802B190: lui    $gp,$8810
8802B194: sw    $ra,$0($sp)
...
I'm sure the source is freely available for how they are doing that since both are open source type projects. Do note that MESS/MAME unfortunately do not show the bytes that make up the instruction in any system they log, though I do hope you plan to include it within your implementation.

Aside from the trace log, you say that you want to implement a "better" memory search functionality, though I have yet to find anything of the sort implemented previously in your debug enabled releases. Am I missing something? Thanks for the reply.
 
#4 ·
I agree with Abystus on the trace log and memory search implementation. Coming from an avid NO$GBA user, it's sometimes a pain to manually trace the code and I tend to go back and forth between emulators (Desmume for searching and testing Action Replay Codes, NO$GBA Debugger for debugging) or attach an external application (Emucheat, Renegade, etc.) to search the memory for NO$GBA.

The standalone emulator (NO$GBA, not the Debugger), has a great cheat engine; it's just lacking in the Debugger. Also, we have to use an external application (eNDryptS Advanced) to encrypt newly released games, then run the game in GBA BIOS mode for it to work in NO$GBA.

I would appreciate it if you can implement these features.
 
#5 ·
abystus, please explain that tracelog! I don't understand that loop feature at all! Those "(loops for nnnn instructions)" lines seem to be placed just at random locations!?
Sometimes they are placed after branch-delays which makes sense, but sometimes they show up elsewhere (namely after 8802C694, but there seem to be a lot opcodes missing between 8802C694 and 8802C6CC, so maybe the confusion is just caused by that missing opcodes).

Showing the opcodes as hex numbers isn't planned, what would that be good for? I think it would be mainly wasting memory, and tracelogs are huge enough anyways. Showing register values would make more sense to me (but that might be problematic for that loop feature, since registers are changing in each loop cycle).

Searching works more or less in the CODE window, and very crappy in DATA window. In CODE window: It's doing a string comparision on your input vs disassembled code (downside is that it's insisting on exactly same space padding between opcode and operands) (on the upside: you also search for snippets like "NNNN" instead of "jmp NNNN" or "call NNNN"). The DATA window is working the same way: It's "disassembling" a 16-byte line, and then comparing it to your input, which is total crap since it can't find bytes/text that crosses 16-byte boundaries. Aside from that issue, there is no "cheat-search" feature for doing things like "search all bytes that have incremented since last time".

A bit offtopic: I am not aware of any encryption issues in current no$gba version, and the cheat feature is implemented in no$gba debug version for quite a while, too.
 
#6 · (Edited)
A bit offtopic: I am not aware of any encryption issues in current no$gba version, and the cheat feature is implemented in no$gba debug version for quite a while, too.
Yeah, sorry for going a little off topic, but where is it located? I've never seen the cheat feature in the debug version of NO$GBA. It isn't under "Utility" like it is in the non-debugger version.

Edit: I forgot to mention that a save/load state feature for all NO$ emulators would be nice as well.

Text Line Font Office equipment Paper product
Text Line Font Diagram
 
#8 ·
I hope all Nocash programs (Gameboy, GBA, DS, PSX etc...) will have search memory (or search the codes) features just likes other emulator soon. Normally, finding the codes was using external programs likes EmuHaste, Cheat Engine etc... :)
 
#9 · (Edited)
Any update on the status of the "Trace Logging" feature you were attempting to implement when we last spoke? Also, going off-topic, I have another idea that you may or may not have already attempted to implement previously. The idea is a "Dissect Data Structure" type option similar to Cheat Engine where you could input several structure base addresses, and compare the similarities and differences between two or more (can add new groups at runtime) similar structures by offset (color coded). Pointers located at certain offsets would become their own structure breakdown (again by offset), and could be expanded in a further comparison between all structures present. The value of these offset locations can also be manually updated on the fly through this screen. A picture of this feature can be found below (Google image result):



Such a tool would be useful for easily breaking down shared routines that are common among games that interface with similar object types (Player/Enemies), and allow hackers to easily target or exclude specific objects within their hacks by value of object offsets passing through said shared routine. Do you think this is something you may be able to implement in the future?
 
#10 ·
Any update on the status of the "Trace Logging" feature you were attempting to implement when we last spoke?
Yes, it should be included in no$psx v1.9 (since May 2014), as part of the "TTY Window", supporting both the MIPS cpu, and the HC05 cpu (as selected in the window's "Enable" option). It's just logging all opcodes, without trying to resolve loops or such trickery.
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top